Guia Gestion de Software

Instituto Tecnológico Superior Compu Sur
ITSCS
Tecnología en Desarrollo de Software
Guía Didáctica
Gestión de Software
Quinto Semestre
Tlga. Adriana Calderón
Octubre 2020 – Marzo 2021

INSTITUTO TECNOLÓGICO SUPERIOR COMPU SUR
ITSCS
TECNOLOGÍA EN DESARROLLO DE SOFTWARE GESTION DE SOFTWARE
Introducción
Hay una serie de paquetes de software y soluciones dedicados a abordar el problema
de cómo administrar documentos de manera eficiente y efectiva en un entorno digital.
Algunos ofrecen un conjunto simple de funciones que se adaptan a una o dos necesidades
específicas, mientras que otros ofrecen una gama más completa de herramientas, que
combina la gestión de documentos con capacidades adicionales como parte de un conjunto
más amplio de software. Debido a estas diferencias, comparar el Software de Gestión
Documental es crucial para las organizaciones que buscan adoptar la plataforma más
rentable y práctica. Y el precio debe considerarse, junto con otros factores, como la forma
en que se implementa el software y los sistemas con los que es compatible.
Por ejemplo, algunas soluciones pueden instalarse localmente en ordenadores o
servidores internos, mientras que otras funcionan únicamente en la nube. También existen
aquellos que proporcionan un híbrido de estos dos enfoques, introduciendo una ventaja
adicional de flexibilidad.
1
ITSCS
Semana I
Contenido
Lunes – Semana I 3
La gestión de Proyectos 3
Martes – Semana I 5
Restricción de un Proyecto 5
Miércoles - Semana I 7
Etapas de la gestión de proyectos 7
Beneficios de la gestión de proyectos 8
Importancia de la gestión de proyectos 9
Jueves – Semana I 10
Espectro de gestión 10
Personal 10
Producto 11
Proceso 12
Proyecto 12
2
ITSCS
Lunes – Semana I
(Concepto.de)
La gestión de Proyectos
La gestión de proyectos es una disciplina de la administración de empresas, cuyo
objeto de estudio abarca la planificación, organización, motivación y el control de los
recursos necesarios para alcanzar un fin determinado de antemano, o sea, cumplir con un
objetivo.
En este sentido, se define “proyecto” como un emprendimiento dotado de principio
y fin determinados, cuyo objetivo es producir un único producto, servicio o resultado, es
decir, dotado de objetivos únicos y que, al cumplirse, agregará valor a la cadena productiva
o logrará algún tipo de cambio positivo.
Así, la gestión de proyectos puede entenderse como un conjunto de acciones
determinadas que garantizan el cumplimiento de un objetivo dentro de unos plazos de
tiempo específicos, durante los cuales se da uso a recursos, herramientas y talentos. Este
tipo de estudios permiten evaluar, gestionar y controlar procesos de muy diversa naturaleza,
aplicando para ello metodologías, razonamientos y conceptos.
En el mundo empresarial de hoy es sumamente frecuente el enfoque desde la
gestión de proyectos, sin importar las dimensiones o los objetivos de una organización, ya
que prácticamente todas sus operaciones pueden ser comprendidas como proyectos: desde
la elaboración de un producto o de un servicio importantes, o el cumplimiento de objetivos
3
ITSCS
secundarios, hasta el mejoramiento de los procesos internos de la misma organización
productiva.
La gestión del proyecto está esencialmente dirigida a conseguir los objetivos
preestablecidos para proporcionar un beneficio a la organización.
Los objetivos pueden expresarse en términos de:
● Resultados (como la creación de una nueva sede central)
● Consecuencias (como la reubicación de los empleados a nueva sede);
● Beneficios (reducción de costes de cheques de comida, del mantenimiento de las
máquinas o instalaciones)
● Objetivos estratégicos (como duplicar el rendimiento corporativo en tres años).
4
ITSCS
Martes – Semana I
Restricción de un Proyecto
Hay muchas restricciones a la hora de desarrollar un proyecto. Sin embargo, las tres
más comunes son el tiempo, el coste y el alcance.
Estas restricciones forman parte de todos los proyectos y juntas forman el Triángulo de
Gestión de Proyectos, en donde:
● El alcance.- es importante para especificar todos los pasos del desarrollo del
proyecto.
● El tiempo.- es un recurso invaluable. Si bien podemos controlar los procesos, no
podemos controlar el tiempo. Por lo que es un verdadero desafío poder utilizar el
tiempo de manera eficiente, mantener el proyecto dentro del cronograma y alcanzar
los objetivos deseados
● El coste está compuesto por un presupuesto establecido en la etapa inicial del
proyecto. Después, éste se compara con la cifra que se propuso inicialmente.
Las tres restricciones están interconectadas y dependen mucho la una de la otra. Una
vez que se reduce el tiempo asignado para el proyecto, el costo aumenta. Además, el
alcance del proyecto dicta el ritmo y una serie de recursos necesarios para realizar y
completar con éxito el proyecto.
5
ITSCS
Figura 1 Triangulo de calidad
Fuente. Tic.portal
6
ITSCS
Miércoles - Semana I
(Concepto.de)
Etapas de la gestión de proyectos
Las etapas o fases de la gestión de proyectos son las siguientes:
● Análisis de viabilidad. El paso inicial consiste en determinar qué tan viable o
conveniente es el proyecto, o sea, qué implica llevarlo adelante en términos
financieros, logísticos y de rentabilidad. Si la inversión en un proyecto supera por
mucho su rentabilidad, deberá haber otras razones de peso para llevarlo adelante.
● Planificación del trabajo. Luego se procede a enumerar y detallar las distintas
tareas que llevar adelante el proyecto implicará, o sea, los pasos que habrá que
seguir, sin perder de vista los recursos que cada paso requerirá y las estimaciones en
coste, esfuerzo y tiempo necesarios.
● Ejecución del proyecto. En esta etapa se llevan a cabo las tareas planificadas y se
levanta un informe de cómo ocurren, es decir, qué tropiezos encuentran, qué
resultados arrojan y toda la información necesaria para alimentar la etapa de control.
Esta es la etapa en que se despliega todo lo planificado.
● Seguimiento y control. En este paso se debe vigilar que el proceso esté arrojando
los resultados esperados, y se deben extraer las conclusiones pertinentes a partir de
la información recabada durante la ejecución. En base a dichas conclusiones se
7
ITSCS
podrán modificar estrategias, tomar correctivos y dirigir el proceso hacia un
resultado ideal.
● Cierre del proyecto. La finalización de un proyecto es también muy importante, ya
que en esta etapa se evalúa el proceso completo en retrospectiva, tomando nota de
los fallos, los accidentes, los imprevistos y levantando un informe que sirva para la
planificación y ejecución de proyectos futuros. Esta es la etapa del aprendizaje. Si
los proyectos son exitosos, es aquí donde se realiza el backup o respaldo de lo
logrado.
Beneficios de la gestión de proyectos
Una eficiente gestión de proyectos garantiza mayores márgenes de aprendizaje.
No son pocos los beneficios que arroja una eficiente gestión de proyectos:
● Disposición eficaz de los recursos y del tiempo. Evitando el derroche, la escasez y
otros tropiezos que disminuirían la rentabilidad del proyecto.
● Mayor control sobre el destino de la organización. Ya que se pueden visualizar y
organizar (priorizar, jerarquizar, por ejemplo) los proyectos a emprender.
● Mayor garantía de éxito. Dado que los proyectos no planificados están a merced
de lo que pueda salir mal, sin consciencia de lo que implican o simplemente se dan
de modo desorganizado.
8
ITSCS
● Mayores márgenes de aprendizaje. Puesto que la gestión de proyectos arroja,
finalmente, informes valiosos respecto al proceder de la organización y sus virtudes
y desventajas en la ejecución de proyectos.
Importancia de la gestión de proyectos
La formalización del campo de la gestión de proyectos le otorga el rigor de una
disciplina científica, la meticulosidad y la capacidad de generar información,
experiencia y aprendizaje. En ese sentido, se trata de un saber vital para la
administración empresarial y para la planificación organizacional, que actualmente se
lleva a cabo mediante diversas herramientas de software para sacar provecho a las
ventajas tecnológicas de la época. Sin la gestión de proyectos, no sería posible una
estandarización de este tipo de información empresarial.
9
ITSCS
Jueves – Semana I
Espectro de gestión
La gestión eficaz de un proyecto de software se centra en las cuatro P’s: personal,
producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el
trabajo de ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la
gestión de proyectos.
Personal
La necesidad de contar con personal para el desarrollo del software altamente
preparado y motivado se viene discutiendo desde los años 60 (por ejemplo, [COUSO,
WíT94, DEM981). De hecho, el factor humano es tan importante que el Instituto de
Ingeniería del Software ha desarrollado un Modelo de madurez de la capacidad de gestión
de personal (MMCGP) «para aumentar la preparación de organizaciones del software para
llevar a cabo las cada vez más complicadas aplicaciones ayudando a atraer, aumentar,
motivar, desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de
software» [CUR94].
El modelo de madurez de gestión de personal define las siguientes áreas clave
prácticas para el personal que desarrolla software: reclutamiento, selección, gestión de
rendimiento, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización
y del trabajo y desarrollo cultural y de espíritu de equipo.
El MMCGP es compañero del modelo de madurez de la capacidad software que
guía a las organizaciones en la creación de un proceso de software maduro.

10
ITSCS
Producto
Antes de poder planificar un proyecto, se deberían establecer los objetivos y el
ámbito del producto‘, se deberían considerar soluciones alternativas e identificar las
dificultades técnicas y de gestión. Sin esta información, es imposible definir unas
estimaciones razonables (y exactas) del coste; una valoración efectiva del riesgo, una
subdivisión realista de las tareas del proyecto o una planificación del proyecto asequible
que proporcione una indicación fiable del progreso.
El desarrollador de software y el cliente deben reunirse para definir los objetivos del
producto y su ámbito. En muchos casos, esta actividad empieza como parte del proceso de
ingeniería del sistema o del negocio y continúa como el primer paso en el análisis de los
requisitos del software Los objetivos identifican las metas generales del proyecto sin
considerar cómo se conseguirán (desde el punto de vista del cliente).
El ámbito identifica los datos primarios, funciones y comportamientos que
caracterizan al producto, y, más importante, intenta abordar estas características de una
manera cuantitativa.
Una vez que se han entendido los objetivos y el ámbito del producto, se consideran
soluciones alternativas.
Proceso
Un proceso de software proporciona la estructura desde la que se puede establecer
un detallado plan para el desarrollo del software. Un pequeño número de actividades
estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su
11
ITSCS
tamaño o complejidad. Diferentes conjuntos de tareas -tareas, hitos, productos del trabajo y
puntos de garantía de calidad- permiten a las actividades estructurales adaptarse a las
características del proyecto de software y a los requisitos del equipo del proyecto.
Finalmente, las actividades protectoras -tales como garantía de calidad del software, gestión
de la configuración del software y medición- cubren el modelo de proceso.
Las actividades protectoras son independientes de las estructurales y tienen lugar a
lo largo del proceso.
Proyecto
Dirigimos los proyectos de software planificados y controlados por una razón
principal -es la Única manera conocida de gestionar la complejidad-. Y todavía seguimos
esforzándonos. En 1998, los datos de la industria del software indicaron que el 26 por 100
de proyectos de software fallaron completamente y que el 46 por 100 experimentaron un
desbordamiento en la planificación y en el coste [REE99]. Aunque la proporción de éxito
para los proyectos de software ha mejorado un poco, nuestra proporción de fracaso de
proyecto permanece más alto del que debería ser.
Para evitar el fracaso del proyecto, un gestor de proyectos de software y los
ingenieros de software que construyeron el producto deben eludir un conjunto de señales de
peligro comunes; comprender los factores del éxito críticos que conducen a la gestión
correcta del proyecto y desarrollar un enfoque de sentido común para planificar, supervisar
y controlar el proyecto.
12
ITSCS
Actividades – Semana I
Actividad 1
Investigue que es la gestión de proyectos.
Actividad 2
Con la investigación anterior realice una presentación en PowerPoint (mínimo 10
diapositivas)
Actividad 3
Mediante un mapa conceptual explique cuáles son las fases de la gestión de proyectos.
Actividad 4
Utilizando un mapa conceptual explique cuáles son las restricciones que debe tener un
proyecto.
Actividad 5
Consulte de qué se trata la norma ISO 21500.
Actividad 6
Realice un resumen (mínimo250 palabras) de la fase de ejecución de un proyecto en la
gestión de proyectos.
Actividad 7
Explique cada uno de los componentes del triángulo de calidad mediante un ejemplo.
13
ITSCS
Actividad 8
Con la utilización de lluvias de ideas explique que es el espectro de la gestión de
proyectos.
Actividad 9
Realice un resumen (mínimo250 palabras) con la materia vista hasta el día de hoy.
Actividad 10
Investigue cual es el ciclo de vida de un software.
14
ITSCS
Recursos – Semana I
Videos
● Gestión de Proyectos
https://slideplayer.es/slide/5461458/
● Restricción de un proyecto
https://www.youtube.com/watch?v=b3ZZSwd72ow
● Las fases de la gestión de proyectos
https://canal.uned.es/video/5a6f1739b1111f35718b45ab
● El espectro de la gestión de proyectos
https://www.youtube.com/watch?v=ZNVfDDVFHVA
Presentaciones
https://es.slideshare.net/DELQUIS/gestion-de-proyectos-2390454?qid=ec176499-c
0d5-4ade-92f5-de7974999610&v=&b=&from_search=7
https://es.slideshare.net/AndreaVeraVilatua/restricciones-y-proyectos-69747640
https://es.slideshare.net/licenol/mapa-conceptual-oll?qid=5c54d4f4-281a-4852-920e
-bc514c47a74c&v=&b=&from_search=12
15
ITSCS
Lectura Complementaria
https://blogs.imf-formacion.com/blog/mba/restricciones-direccion-de-proyectos/
https://blogs.imf-formacion.com/blog/mba/restricciones-direccion-de-proyectos/
https://gerens.pe/blog/fases-ciclo-vida-gestion-proyectos/
http://heyssellopez.blogspot.com/2010/10/el-espectro-de-gestion.html
16
ITSCS
Semana II
Contenido
Lunes – Semana II 19
Proceso del software 19
Ciclo de vida del software 19
ISO 12207-1 19
Martes – Semana II 22
Tipos de ciclos de vida de un software 22
Ciclo de vida lineal 22
Ciclo de vida en cascada puro 23
Ciclo de vida en V 23
Miércoles - Semana II 25
Estimación de Proyectos de Software 25
Estimar el tamaño del producto 25
Estimar la carga de trabajo 25
Estimar la programación 25
Estimar los costos 26
El proceso de estimación 26
Jueves – Semana II 27
Factores que afectan el costo del software 27
Capacidad del programador 27
Complejidad del producto 28
Tamaño del producto 28
Tiempo disponible 28
Nivel de confiabilidad requerido 29
17
ITSCS
Lunes – Semana II
Proceso del software
Ciclo de vida del software
Es el proceso que se sigue para construir, entregar y hacer evolucionar el software,
desde la concepción de una idea hasta la entrega y retiro del sistema. Se definen las
distintas fases intermedias que se requieren para validar el desarrollo de un software, es
decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación
de los procedimientos de desarrollo, se asegura de que los métodos utilizados son
apropiados.
ISO 12207-1
"Un marco de referencia que contiene los procesos, las actividades y las tareas
involucradas en el desarrollo, la explotación y el mantenimiento de un producto de
software, abarcando la vida del sistema desde la definición de los requisitos hasta la
finalización de su uso."
El ciclo de vida básico de un software consta de los siguientes procedimientos:
Definición de objetivos: define la finalidad del proyecto y su papel en la estrategia
global.
Análisis de los requisitos y su viabilidad: recopila, examina y formula los
requisitos del cliente y examina cualquier restricción que se pueda aplicar.

18
ITSCS
Diseño general: requisitos generales de la arquitectura de la aplicación.
Diseño en detalle: definición precisa de cada subconjunto de la aplicación
Programación (programación e implementación): implementación de un lenguaje
de programación para crear las funciones definidas durante la etapa de diseño.
Prueba de unidad: prueba individual de cada subconjunto de la aplicación para
garantizar que se implementaron de acuerdo con las especificaciones.
Integración: garantiza que los diferentes módulos se integren con la aplicación.
Este es el propósito de la prueba de integración que está cuidadosamente
documentada.
Prueba beta (o validación): garantiza que el software cumple con las
especificaciones originales.
Documentación: sirve para documentar información necesaria para los usuarios
del software y para desarrollos futuros.
Implementación
19
ITSCS
Mantenimiento: comprende todos los procedimientos correctivos (mantenimiento
correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).
El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de
una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el
cliente y el equipo de desarrolladores.
figura 2. Ciclo de vida del Software
20
ITSCS
Martes – Semana II
Tipos de ciclos de vida de un software
Ciclo de vida lineal
Es el más sencillo de todos los modelos. Consiste en descomponer la actividad
global del proyecto en etapas separadas que son realizadas de manera lineal, es decir, cada
etapa se realiza una sola vez, a continuación de la etapa anterior y antes de la etapa
siguiente.
Con un ciclo de vida lineal es muy fácil dividir las tareas, y prever los tiempos
(sumando linealmente los de cada etapa).Las actividades de cada una de las etapas
mencionadas deben ser independientes entre sí, es decir, que es condición primordial que
no haya retroalimentación entre ellas, aunque sí pueden admitirse ciertos supuestos de
realimentación correctiva.
Desde el punto de vista de la gestión, requiere también que se conozca desde el
primer momento, con excesiva rigidez, lo que va a ocurrir en cada una de las distintas
etapas antes de comenzarla. Esto último minimiza, también, las posibilidades de errores
durante la codificación y reduce al mínimo la necesidad de requerir información del cliente
o del usuario.
21
ITSCS
Ciclo de vida en cascada puro
Este modelo de ciclo de vida fue propuesto por Winston Royce en el a-o 1970. Es
un ciclo de vida que admite iteraciones, contrariamente a la creencia de que es un ciclo de
vida secuencial como el lineal. Después de cada etapa se realiza una o varias revisiones
para comprobar si se puede pasar a la siguiente. Es un modelo rígido, poco flexible, y con
muchas restricciones. Aunque fue uno de los primeros, y sirvió de base para el resto de los
modelos de ciclo de vida.
Figura 3. Modelo en Cascada
Ciclo de vida en V
Este ciclo fue diseñado por Alan Davis, y contiene las mismas etapas que el ciclo de
vida en cascada puro. A diferencia de aquél, a éste se le agregaron dos subetapas de
22
ITSCS
retroalimentación entre las etapas de análisis y mantenimiento, y entre las de diseño y
debugging.
Figura 4. Modelo en V
23
ITSCS
Miércoles - Semana II
Estimación de Proyectos de Software
Una estimación exitosa requiere una ardua investigación, la cual, comúnmente, se
divide en cuatro etapas básicas:
Estimar el tamaño del producto
El primer paso para estimar un proyecto, casi siempre es el más complicado, y se
trata de estimar el tamaño del mismo. Para poder producir una estimación lo más certera
posible, el manager de proyectos necesita tener una visión de la estructura de dicho
proyecto, así como los posibles riesgos, obstáculos y entre otras complicaciones que puedan
presentarse en el proceso.
Estimar la carga de trabajo
Al entender los requerimientos del proyecto, se procede a realizar las estimaciones del
esfuerzo de completar el trabajo.
Respecto al ámbito de desarrollo de software las estimaciones se obtienen a través de la
experiencia previa en conjunto con el consejo y la opinión directa de los profesionales a
cargo de esa labor, pero este es sólo el principio para la composición del proyecto.
Estimar la programación
Ya completados el tamaño y la carga de trabajo, proseguimos a establecer el
programa que se utilizará en nuestro proyecto. Se necesita tener en cuenta cuantas personas
24
ITSCS
conformarán el equipo y así como también, la cantidad de horas semanales que le dedicarán
al proyecto.
Estimar los costos
Son diferentes variables las que se incluyen dentro del costo del proyecto, entre
ellas, la mano de obra, el hardware y software, gastos de oficina, entrenamiento, he incluso
la metodología que será utilizada para llevar todo esto a cabo.
El proceso de estimación
1. Estimar el tamaño del producto(en numero de líneas del código fuente o puntos de
función)
2. Estimar el esfuerzo(personas - mes)
3. Estimar el plan (meses)
Figura 5 proceso de estimación de costos
25
ITSCS
Jueves – Semana II
Factores que afectan el costo del software
La estimación de lo que costará el desarrollo de un software es una de las
actividades de planeación que reviste especial importancia, ya que una de las características
que debe tener un producto de software es que su costo sea adecuado, de lo contrario el
proyecto puede fracasar.
Muchas organizaciones utilizan una serie de estimaciones de costos parciales antes
de emitir el costo definitivo. Se hace una estimación durante el estudio preliminar del
problema y se revisa durante el análisis de factibilidad del proyecto. Una estimación
mejorada se presenta durante las especificaciones del software y la estimación final durante
la revisión del diseño.
Los factores que principalmente afectan el costo del software son:
● Capacidad del programador
● Complejidad del producto
● Tamaño del programa
● Tiempo disponible
● Confiabilidad requerida
Capacidad del programador
La producción de productos de programación son tareas laboriosas, por lo que la
productividad es función directa de la capacidad individual. Los programadores que se
26
ITSCS
muestran competentes en el procesamiento de datos, suelen no serlo en áreas científicas y
de igual forma, un buen programador científico no es, forzosamente, un buen programador
de sistemas. Por tanto, la falta de familiaridad con el área de aplicación puede implicar baja
productividad y por ende mayor costo y esfuerzo.
Complejidad del producto
● Procesamiento de Datos
● Programas de Aplicación
● Programas Científicos
● Categorías de Compiladores
● Productos de Programas de Apoyo
● Programación Ligadores
● Sistemas de Bases de Datos
● Programas de Sistemas Sistemas Operativos
● Sistemas de Tiempo Real
● Complejidad
Tamaño del producto
Costo del Producto
Tiempo disponible
El esfuerzo total del proyecto se relaciona con el calendario de trabajo asignado para
la terminación del proyecto.
27
ITSCS
Los proyectos de programación requieren más esfuerzo si el tiempo de desarrollo se
reduce.
Nivel de confiabilidad requerido
La confiabilidad puede expresarse en términos de exactitud, firmeza, cobertura y
consistencia del código fuente.
Existe un costo asociado con el aumento del nivel de análisis, diseño, codificación y
esfuerzo de verificación y validación que debe aportarse para asegurar alta confiabilidad.
El nivel de confiabilidad debe establecerse durante la fase de planeación al
considerar el costo de las fallas del programa, en algunos casos, las fallas pueden causar al
usuario pequeñas inconveniencias, mientras que en otros tipos de productos pueden
generarse gran pérdida financiera e incluso poner una vida en peligro.
28
ITSCS
Actividades – Semana II
Actividad 1
Realice una explicación breve del ciclo de vida del software.
Actividad 2
Realizar la estimación del costo para un proyecto de software que tiene 14 instrucciones.
Actividad 3
Explique cada proceso que realizo en la tarea anterior.
Actividad 4
Plantee un ejercicio en el que pueda estimar el costo de un software.
Actividad 5
Actividad 6
Mediante un ejemplo realice el proceso de ciclo de vida de un software.
Actividad 7
Actividad 8
Consulte que es una métrica.
Actividad 9
Mediante mapas conceptuales realice un resumen con la consulta métricas.
29
ITSCS
Actividad 10
Consulte de qué se trata el modelo DROMEY gráficamente.
30
ITSCS
Recursos – Semana II
Videos
● Proceso del software
https://www.youtube.com/watch?v=C6ynhRZRieI
● Ciclo de vida del software
https://www.youtube.com/watch?v=4D1nhygWOKw
● Modelos del ciclo de vida del software
https://www.youtube.com/watch?v=V05gm73c5ds
● Estimación de proyectos de software
https://www.youtube.com/watch?v=FF9kmShan5Y
● Factores que afectan el costo del software
● https://www.youtube.com/watch?v=Q1JFHri9KdA
Presentaciones
https://es.slideshare.net/leo_ruth/proceso-del-software
https://es.slideshare.net/edimor72/ciclo-de-vida-del-software-12538356?qid=cfe005
59-dc30-44e0-9b5e-2aefd5b7d4f3&v=&b=&from_search=2
https://es.slideshare.net/guest37183b/modelos-del-ciclo-de-vida-del-software?qid=b
9cd904a-ae06-4b37-b651-ead58cf124f2&v=&b=&from_search=2
31
ITSCS
https://es.slideshare.net/dlaco/estimacin-de-proyectos-de-software-10269330?qid=0
ac1cbda-3ae3-436e-9a7a-096d01483f7a&v=&b=&from_search=4
https://es.slideshare.net/dlaco/estimacin-de-proyectos-de-software-10269330?qid=0
ac1cbda-3ae3-436e-9a7a-096d01483f7a&v=&b=&from_search=4
Lectura complementaria
https://sg.com.mx/revista/1/procesos-software
https://es.ccm.net/contents/223-ciclo-de-vida-del-software
https://es.ccm.net/contents/223-ciclo-de-vida-del-software
http://www.pmoinformatica.com/2018/08/tecnicas-estimacion-software.html
http://factoresenelcostodelsoftware.blogspot.com/2017/04/costo-de-desarrollo-de-un
-software_26.html
32
ITSCS
Semana III
Contenido
Lunes – Semana III 34

Técnicas de estimación de costo de software 34
Juicio Experto 34
Ventajas 35
Desventajas 35
Martes – Semana III 36
Técnica DELPHI 36
Método histórico 37
Miércoles – Semana III 38
Modelo de Costos COCOMO 38
Jueves – Semana III 42
Ecuación de primer orden de jones 42
33
ITSCS
Lunes – Semana III
Técnicas de estimación de costo de software
Juicio Experto
La técnica más utilizada para la estimación de costos es el uso del juicio experto. El
juicio experto se basa en la experiencia, en el conocimiento anterior y en el sentido
comercial de uno o más individuos dentro de la organización.
El experto, por ejemplo, puede hacer una estimación de costos razonando de la
siguiente manera:
● El sistema que se va a desarrollar es muy similar a uno que se desarrolló
anteriormente y que costó $ 8,000.00 y tardó 4 meses.
● Se puede reutilizar la base del proyecto anterior.
● Se utilizará el mismo equipo de cómputo y a muchos de los programadores que
participaron en el proyecto anterior, por lo que la estimación se puede reducir en un
20 %.
● Mucho código y rutinas comunes se podrán reusar por lo que el esfuerzo se reduce
otro 20%.
● Por lo tanto el nuevo proyecto puede ser un 20% más económico que el anterior.
Ventajas
1. Se obtiene una estimación en corto tiempo.
34
ITSCS
Desventajas
1 El experto puede confiarse y olvidar algunos factores importantes del nuevo
proyecto, creyendo que es casi igual al anterior.
2 El experto puede no tener familiaridad con el área del proyecto.
Para compensar las desventajas se forma un grupo de expertos que en consenso determinen
o estimen el costo. La desventaja es que algunos miembros del grupo pueden ser inocentes
con respecto a la presencia de una alta autoridad o al dominio de un miembro del grupo con
fuerte personalidad. También se pueden suscitar discusiones fuertes por no lograr un
acuerdo entre los miembros del grupo.
35
ITSCS
Martes – Semana III
Técnica DELPHI
Se desarrolló en la corporación Rand en 1948, con el fin de lograr un acuerdo de un
grupo de expertos sin contar con los efectos negativos de las reuniones de grupos. La
técnica se lleva a cabo de la siguiente manera:
1. Un coordinador proporciona a cada experto la documentación con la Definición del
Sistema y una papeleta para que escriba su estimación.
2. Cada experto estudia la definición y determina su estimación en forma anónima; los
expertos pueden consultar al coordinador, pero no entre ellos.
3. El coordinador prepara y distribuye un resumen de las estimaciones efectuadas,
incluyendo cualquier razonamiento extraño efectuado por alguno de los expertos.
4. Los expertos realizan una segunda ronda de estimaciones, otra vez anónimamente,
utilizando los resultados de la estimación anterior. En los casos en que una
estimación difiera mucho de las demás, se podrá solicitar que también en forma
anónima el experto justifique su estimación.
5. El proceso se repite tantas veces como se juzgue necesario, impidiendo una
discusión grupal durante el proceso.
Ejemplo de papeleta para la estimación:
36
ITSCS
Figura 6 Modelo DELPHI
Método histórico
Este método se basa en registros cuidadosos que se mantienen de esfuerzos de desarrollo
previos. Los registros indican las características del programa o proyecto, la asignación de
tareas, los requerimientos de tiempo del personal y cualquier acontecimiento o problema
poco común. Cuando se proponen nuevos proyectos, se comparan con los registros que se
llevan en el archivo y se iguala a lo planeado con trabajos anteriores para estimar el tiempo
de desarrollo esperado.
37
ITSCS
Miércoles – Semana III
Modelo de Costos COCOMO
El modelo de costos COCOMO (Modelo Constructivo de Costos), se basa en el uso
de ecuaciones que se utilizan de acuerdo a la complejidad del sistema a desarrollar:
Las ecuaciones son de la forma:
PM = a * ( KDSI ) b ; TDEV = c * ( PM ) d
Dónde:
KDSI es el número de miles de líneas de código fuente esperadas.
PM es el esfuerzo en meses de programador
TDEV es el tiempo de desarrollo en meses
Programas de Aplicación: PM = 2.4 * ( KDSI ) 1.05; TDEV = 2.5 * ( PM ) 0.38
Programas de Apoyo: PM = 3.0 * ( KDSI ) 1.12; TDEV = 2.5 * ( PM ) 0.35
Programas de Sistemas: PM = 3.6 * ( KDSI ) 1.20; TDEV = 2.5 * ( PM ) 0.32
Las ecuaciones proporcionan los valores nominales de la estimación de meses de
programador (PM) y del calendario de desarrollo ( TDEV ) para cada unidad de trabajo,
basándose en el número de instrucciones de código fuente entregadas ( DSI ) de cada
unidad; después se utilizan factores multiplicadores ( FM ) para ajustar la estimación de
38
ITSCS
acuerdo con los atributos del producto, de la computadora, del personal dedicado y del
proyecto. Cada factor multiplicador se evalúa y califica con un valor, ese valor representa el
peso que tiene dicho factor en el desarrollo del proyecto, luego se multiplican todos los
factores para obtener el factor multiplicador global:
FM = fm1 * fm2 * fm3 * ...... * fmi
Las ecuaciones de cálculo de esfuerzo aplicando los factores multiplicadores
quedarían de la forma:
PM = a * ( KDSI ) b * FM;
Tabla de Factores Multiplicadores de Esfuerzo en COCOMO
39
ITSCS
Figura 7 Modelo COCOMO
Es muy importante considerar este método con sus correspondientes reservas, ya
que el estudio realizado para obtener las ecuaciones incorpora ciertas suposiciones
importantes, además de que su uso está basado en estimar primeramente el número de
líneas de código fuente (DSI) de que podrá constar el producto, estimación ciertamente
difícil de efectuar.
Las suposiciones que el modelo COCOMO incorpora hace que las ecuaciones por
ejemplo, para los programas de aplicación se usen solo en las siguientes situaciones:
40
ITSCS
● Desde programas pequeños hasta medianos (de 2K a 32 KDSI).
● En un área de aplicación conocida
● Con un sistema operativo y plataforma conocida.
Las estimaciones por esta técnica cubren desde el diseño hasta las pruebas de
aceptación del programa.
Las estimaciones excluyen los costos de planeación, análisis, instalación y
entrenamiento, así como los costos de secretarias, personal de limpieza y operadores del
equipo de cómputo.
41
ITSCS
Jueves – Semana III
Ecuación de primer orden de jones
● Carpers Jones propone una ecuación derivada del análisis de su base de datos de
cientos de proyectos.
● Este es también un modelo empírico de estimación.
● Con la suma total de puntos de función , se puede realizar a partir de ellos un
cálculo aproximado de la planificación.
La ecuación de Jones tiene la forma:
TDEV = # PFn
Donde
TDEV = Tiempo de planificación (meses)
#PF = No. de Puntos de Función
n = Exponente según la tabla siguiente
42
ITSCS
Figura 8 Ecuación Jones
Ejemplo: Si #PF = 350 en un proyecto de software de Aplicación:
TDEV = 350 0.42 = 12 meses aprox. Estimación Nominal
Si el equipo de desarrollo fuera sumamente organizado, están motivados, conocen y
se apegan a las metodologías de ingeniería para el desarrollo, etc. entonces podría
considerar lograr un menor tiempo, si aplica el Mejor Caso:
TDEV = 350 0.39 = 10 meses aprox. Estimación Mejor Caso
Este no es el mejor método de estimación de la planificación, pero ayuda o obtener
una aproximación, lo cual es mejor que hacerlo a ojo de buen cubero. Si cree que puede
desarrollar un proyecto de software de Aplicación de los mismos 350 puntos de función en
7 meses, tendría que pensarlo muy bien. Como se vio anteriormente la planificación en el
mejor de los casos es de 10 meses.
43
ITSCS
Actividades – Semana III
Actividad 1
Mediante un mapa conceptual realice una explicación dela estimación del costo de un
software.
Actividad 2
Realice una presentación en PowerPoint con el tema método DELPHI de la estimación del
costo (mínimo 10 diapositivas).
Actividad 3
Investigue que es una métrica.
Actividad 4
Con la consulta anterior realice un mapa conceptual con los componentes principales.
Actividad 5
Amplié su conocimiento sobre el método histórico con respecto a la estimación del costo de
un software.
Actividad 6
Con el tema anterior realice una presentación en PowerPoint (mínimo 10 diapositivas).
Actividad 7
Mediante un ejemplo propuesto realice la estimación del costo de un software utilizando el
método COCOMO.
44
ITSCS
Actividad 8
Realice una presentación con el tema Método COCOMO (mínimo 10 diapositivas).
Actividad 9
Realice un resumen con la materia vista en esta semana (mínimo 250 palabras).
Actividad 10
Con el resumen anterior realice una presentación en PowerPoint (mínimo 10 diapositivas).
45
ITSCS
Recursos – Semana III
Videos
● Técnicas de estimación de costo de software
https://www.youtube.com/watch?v=FF9kmShan5Y
● Técnica Delphi
https://www.youtube.com/watch?v=ezDpenQ48hg
● Modelo de costo COCOMO
https://www.youtube.com/watch?v=SMjUcTqrIUk
Presentaciones
● Técnica Delfi
● https://slideplayer.es/slide/2260941/
https://aprendercompartiendo.com/10-maneras-estimar-costes-de-proyecto/
● Técnica Delfi
https://www.researchgate.net/publication/319016088_Aplicacion_del_metodo_Delp
hi_para_establecer_un_modelo_conceptual_de_estimacion_de_costos_de_software
46
ITSCS
http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm
47
ITSCS
Semana IV
Contenido
Lunes – Semana IV 49
Norma ISO 9126 49
Características norma ISO 9126 50
Subcaracterísticas: 50
Martes – Semana IV 53
Métricas para evaluar la calidad del Software 53
Miércoles – Semana IV 56
Métricas - Tipos 56
Características de la métrica: 56
Razones para medir: 57
Utilidades 57
Tipos de métricas de calidad de software 58
Clasificación de las Métricas 58
Factores que determinan la calidad del Software 59
Jueves – Semana IV 61
Modelos de evaluación de la calidad del software 61
Modelo de calidad Furps 61
48
ITSCS
Lunes – Semana IV
Norma ISO 9126
Estándar internacional para la evaluación de la calidad de un software.
La normativa define seis características de la aplicación, estas seis características
son dividas en un número de sub- características, las cuales representan un modelo
detallado para la evaluación de cualquier sistema informático.
Características norma ISO 9126
El modelo establece diez características, seis que son comunes a las vistas interna y
externa y cuatro que son propias de la vista en uso, a continuación se detallan:
1. Funcionalidad: capacidad del software de proveer los servicios necesarios para
cumplir con los requisitos funcionales.
Subcaracterísticas:
Idoneidad.- Hace referencia a que si el software desempeña las tareas para las
cuales fue desarrollado.
Exactitud.- Evalúa el resultado final que obtiene el software y si tiene consistencia
a lo que se espera de él.
Interoperabilidad.- Consiste en revisar si el sistema puede interactuar con otro
sistema independiente.
Seguridad.- Verifica si el sistema puede impedir el acceso a personal no autorizado.
49
ITSCS
2. Fiabilidad: capacidad del software de mantener las prestaciones requeridas del
sistema, durante un tiempo establecido y bajo un conjunto de condiciones definidas.
Madurez.- Se debe verificar las fallas del sistema y si muchas de estas han sido
eliminadas durante el tiempo de pruebas o uso del sistema.
Recuperabilidad.- Verificar si el software puede reasumir el funcionamiento y
restaurar datos perdidos después de un fallo ocasional.
Tolerancia a fallos.- Evalúa si la aplicación desarrollada es capaz de manejar
errores.
3. Usabilidad: esfuerzo requerido por el usuario para utilizar el producto
satisfactoriamente.
Aprendizaje.- Determina que tan fácil es para el usuario aprender a utilizar el
sistema.
Comprensión.- Evalúa que tan fácil es para el usuario comprender el
funcionamiento del sistema
Operatividad.- Determina si el usuario puede utilizar el sistema sin mucho
esfuerzo.
Atractividad.- Verifica que tan atractiva se ve la interfaz de la aplicación.
50
ITSCS
4. Eficiencia: relación entre las prestaciones del software y los requisitos necesarios
para su utilización.
Comportamiento en el tiempo.- Verifica la rapidez en que responde el sistema
Comportamiento de recursos.- Determina si el sistema utiliza los recursos de
manera eficiente
5. Mantenibilidad: esfuerzo necesario para adaptarse a las nuevas especificaciones y
requisitos del software.
Estabilidad.- Verifica si el sistema puede mantener su funcionamiento a pesar de
realizar cambios.
Facilidad de análisis.- Determina si la estructura de desarrollo es funcional con el
objetivo de diagnosticar fácilmente las fallas.
Facilidad de cambio.- Verifica si el sistema puede ser fácilmente modificado
Facilidad de pruebas.- .- Evalúa si el sistema puede ser probado fácilmente
6. Portabilidad: capacidad del software ser transferido de un entorno a otro.
Capacidad de instalación.- Verifica si el software se puede instalar fácilmente
51
ITSCS
Capacidad de reemplazamiento.- Determina la facilidad con la que el software
puede remplazar otro software similar.
Adaptabilidad.- El software se puede trasladar a otros ambientes
Co-Existencia.- El software puede funcionar con otros sistemas
Cada una de las características debe ser evaluada dentro del software basándonos
en pruebas de funcionamiento, medición de rendimiento y pruebas con usuarios que harán
uso del sistema.
Figura 9 ISO 9126
52
ITSCS
Martes – Semana IV
Métricas para evaluar la calidad del Software
La mala calidad de la información y de software impacta negativamente en el negocio a
diferentes niveles:
• Disminuye ingresos y aumenta el gasto.
• Incrementa el riesgo.
• Provoca una reducción de la confianza, tanto dentro como fuera de la organización.
Los efectos positivos empiezan a notarse y sus beneficios aumentan en un ciclo de
mejora continua propiciado por el control de las métricas de calidad de software.
Esta monitorización facilita el evaluar:
• La calidad del producto.
• El rendimiento del equipo de desarrollo.
• La justificación del uso de nuevas herramientas o soluciones.
• Los resultados obtenidos a partir de la incorporación del software a los procesos y
operaciones.
Para conseguir llegar al nivel de evaluación, es preciso contar con datos relevantes,
precisos y actualizados sobre diferentes áreas, que faciliten una perspectiva global de la
solución.
53
ITSCS
Así, las métricas de calidad de software pueden aplicarse a diferentes contextos, como:
• El proyecto: son las que facilitan la gestión del riesgo permitiendo tomar el pulso a
la iniciativa de desarrollo desde su inicio.
• El producto: están enfocadas a medir las características del software y todos los
entregables que lo acompañan, fruto del proyecto de desarrollo, como modelos,
componentes adicionales y documentación.
• El proceso: tienen por objeto identificar mejores prácticas para su exportación a
futuros proyectos y, para conseguirlo, recopilan datos de distintas iniciativas a lo
largo de un periodo de tiempo determinado.
54
ITSCS
Miércoles – Semana IV
Métricas - Tipos
Es cualquier medida o conjunto de medidas destinadas a conocer o estimar el
tamaño u otra característica de un software o un sistema de información, generalmente para
realizar comparativas o para la planificación de proyectos de desarrollo.
La aplicación continúa de mediciones basadas en técnicas para el proceso de desarrollo
del software y sus productos.
● Formulación: La obtención de medidas y métricas del software apropiadas para la
representación de software en cuestión
● Colección: El mecanismo empleado para acumular datos necesarios para obtener
las métricas formuladas.
● Análisis: El cálculo de las métricas y la aplicación de herramientas matemáticas.
● Interpretación: La evaluación de los resultados de las métricas en un esfuerzo por
conseguir una visión interna de la calidad de la representación.
● Retroalimentación: Recomendaciones obtenidas de la interpretación de métricas
técnicas trasmitidas al equipo de software.
Características de la métrica:
● Simple y fácil de calcular
● Cuantificables, deben basarse en hechos, no en opiniones.
55
ITSCS
● Independientes, los recursos no deben poder ser alterados por los miembros que las
apliquen o utilicen.
● Explicable, debe documentarse información acerca de la métrica y de su uso.
● Precisas, debe de conocerse un nivel de tolerancia permitido cuando se mide
● Un mecanismo eficaz para la realimentación de calidad
Razones para medir:
● Para indicar la calidad del producto.
● Para evaluar la productividad de la gente que desarrolla el producto.
● Para establecer una línea de base para la estimación.
● Para ayudar a justificar el uso de nuevas herramientas o de formación adicional.
● Para evaluar los beneficios derivados del uso de nuevos métodos y herramientas de
la ingeniería de software.
Utilidades
● Estimar Casos de prueba.
● Entender rangos de productividad.
● Entender el crecimiento del proyecto.
● Calcular el costo real del Software.
56
ITSCS
● Estimar el costo del Proyecto, la programación y el esfuerzo.
● Entender los costos de mantenimiento.
● Ayuda a las negociaciones de contrato.
Tipos de métricas de calidad de software
● De Complejidad: Métricas que definen la medición de la complejidad: volumen,
tamaño, anidaciones, y configuración.
● De Competencia: Métricas que definen la calidad del software: exactitud,
estructuración o modularidad, pruebas, mantenimiento.
● Estilizadas: Métricas que intentan valorar o medir las actividades de productividad
de los programadores con respecto a su certeza, rapidez, eficiencia y competencia
● De Desempeño: Métricas que miden la conducta de módulos y sistemas de un
software, bajo la supervisión del SO o hardware.
● De Calidad: Métricas de experimentación y de preferencia: estilo de código,
convenciones, limitaciones.
Clasificación de las Métricas
● Métricas de proceso
● Se recopilan de todos los proyectos, y durante un largo periodo de tiempo
● Caracterizados por: Control y ejecución del proyecto.
57
ITSCS
● Medición de tiempos de las fases.
● Métricas de proyecto
● Permiten evaluar el estado del proyecto.
● Permiten seguir la pista de los riesgos.
● Métricas de producto
● Se centran en las características del software y no en cómo fue producido.
● También son productos los artefactos, documentos, modelos, y componentes
que conforman el software.
● Se miden cosas como el tamaño, la calidad, la totalidad, la volatilidad, y el
esfuerzo.
Factores que determinan la calidad del Software
● Operaciones del Producto
● Corrección
● Fiabilidad
● Eficiencia
● Integridad
● Facilidad de Uso
58
ITSCS
● Transición de Producto
● Portabilidad
● Reusabilidad
● Interoperabilidad
59
ITSCS
Jueves – Semana IV
Modelos de evaluación de la calidad del software
Modelo factores/criterios/métricas (McCall, 1977)
Descompone el concepto de calidad en tres capacidades importantes a observar en
un producto de software:
● operación (facilidad de uso, integridad, eficiencia, corrección o exactitud y
fiabilidad)
● revisión (facilidad de prueba, facilidad de mantenimiento y flexibilidad)
● transición (reusabilidad, portabilidad e interoperabilidad).
Modelo de calidad Furps
Modelo presentado por Hewlett- Packard (HP) en 1987, donde se desarrolla un
conjunto de factores de calidad software, bajo el acrónimo FURPS.
Estos factores de calidad, junto a sus atributos son usados para establecer métricas de
calidad en las actividades del proceso del desarrollo del software.
El modelo FURPS+ establece cinco características como factores de calidad que son los
que le dan nombre:
● Functionality (Funcionalidad).
● Usability (Usabilidad).
● Reliability (Confiabilidad).
60
ITSCS
● Perfomance (Prestación) y
● Supportability (Soporte).
El modelo FURPS incluye, además de los factores de calidad y los atributos,
restricciones de diseño y requerimientos de implementación, físicos y de interfaz. Una
limitación de este modelo de calidad es que no tiene en cuenta la portabilidad de los
productos software que se estén considerando, factor digno de consideración en función
de las exigencias actuales que recaen sobre el proceso de desarrollo del software.
La funcionalidad: hace referencia a los requerimientos específicos de lo que debería
realizar el sistema, se valora evaluando los siguientes atributos:
● Características y capacidades del programa
● Generalidades de las funciones
● Capacidades
● Seguridad del sistema
Los requerimientos de usabilidad hace referencia a la facilidad de uso del producto,
mide el esfuerzo que invierte el usuario para utilizar el sistema, se valora evaluando los
siguientes atributos: pueden incluir subcategorías tales como:
● Factores humanos.
● Estética.
61
ITSCS
● Consistencia.
● Documentación.
La confiabilidad agrupa los requerimientos que tiene que ver con la solidez y
robustez de un sistema durante su ejecución. Incluye:
● Recuperabilidad.
● Precisión.
● Predicción.
Performance (rendimiento – Prestación): hace referencia a la velocidad del sistema y su
eficiencia en utilización de recursos.
● Velocidad de procesamiento
● Eficiencia
● Consumo de recurso.
● Rendimiento efectivo total.
● Productividad.
● Tiempo de respuesta.
Soporte: se relaciona a factores que se dan durante y después de la implementación del
sistema SW.
● Adaptabilidad.
● Extensibilidad.
● Mantenibilidad.
62
ITSCS
● Compatibilidad.
● Configurabilidad.
● Capacidad de configuración
● Requisitos de instalación.
63
ITSCS
Actividades – Semana IV
Actividad 1
Investigue que es una métrica, medición e indicador, realice la utilización de gráficas.
Actividad 2
Consulte que es un software educativo
Actividad 3
Con la consulta anterior realice una presentación en PowerPoint.
Actividad 4
Investigue cuales son los modelos que evalúan la calidad de un software educativo.
Actividad 5
Mediante un ejemplo realice la explicación de un software que evalúa su calidad.
Actividad 6
Realice un resumen con el tema modelo de calidad Dromey.
Actividad 7
Con el resumen anterior realice un mapa conceptual con los puntos más importantes.
Actividad 8
Complemente con una consulta el modelo de calidad Furps.
64
ITSCS
Actividad 9
Realice un resumen con la materia vista en esta semana (mínimo 250 palabras).
Actividad 10
Con el resumen anterior realice una presentación en PowerPoint (mínimo 10 diapositivas).
65
ITSCS
Recursos – Semana IV
Videos
● Norma ISO 9126
https://www.youtube.com/watch?v=UzwBL7usUn8
● Métricas para evaluar la calidad del software
https://www.youtube.com/watch?v=kh7tIcXOB1E
● Tipos de métricas para evaluar la calidad del software.
https://www.youtube.com/watch?v=54iFQGs3d84
● Modelos para evaluar la calidad del software
https://www.youtube.com/watch?v=54iFQGs3d84
Presentaciones
● Norma ISO 9126
● Norma ISO 9126
66
ITSCS
https://lecasabe.com/que-es-la-norma-iso-9126/
http://blog.desafiolatam.com/metricas-de-calidad-de-software/
https://es.slideshare.net/Edwingelviz/estndares-y-modelos-de-calidad-del-software
67
ITSCS
Semana V
Contenido
Lunes
● Métricas en el proceso y dominio del proyecto Pág. 69
● Métricas orientadas al tamaño Pág. 70
Martes
● Métricas orientadas a la función Pág. 71
Miércoles
● Lenguaje unificado de modelado (UML) Pág. 73
● Diagramas UML Pág. 74
Jueves
● Proceso Racional Unificado( RUP) Pág.78
● Fases del RUP Pág. 80
Viernes
● Revisión de temas atrasados
68
ITSCS
Lunes – Semana V
Indicador
Un indicador es una métrica o una combinación de métricas que proporcionan una
visión profunda del proceso del software, del proyecto de software o del producto en sí.
Un indicador proporciona una visión profunda que permite al gestor de proyectos o
a los ingenieros de software ajustar el producto, el proyecto o el proceso para que las cosas
salgan mejor.
Métricas en el proceso y dominio del proyecto
Se mide el consumo de energía, el peso, las dimensiones físicas, la temperatura, el
voltaje, la relación señal-ruido, la lista es casi interminable. Por desgracia, la medición es
mucho menos común en el mundo de la ingeniería del software.
Las métricas del proceso se recopilan de todos los proyectos y durante un largo
período de tiempo. Su intento es proporcionar indicadores que lleven a mejoras de los
procesos de software a largo plazo.
Los indicadores de proyecto permiten al gestor de proyectos del software:
● Evaluar el estado del proyecto en curso;
● Seguir la pista de los riesgos potenciales;
● Detectar las áreas de problemas antes de que se conviertan en «críticas»;
● Ajustar el flujo y las tareas del trabajo, y
69
ITSCS
● Evaluar la habilidad del equipo del proyecto en controlar la calidad de los
productos de trabajo del software.
Métricas orientadas al tamaño
Las métricas del software orientadas al tamaño provienen de la normalización de las
medidas de calidad y/o productividad considerando el «tamaño» del software que se haya
producido.
Si una organización de software mantiene registros sencillos, se puede crear una
tabla de datos orientados al tamaño.
Figura 10 Métricas orientadas al tamaño
70
ITSCS
Martes – Semana V
Métricas orientadas a la función
Las métricas del software orientadas a la función utilizan una medida de la
funcionalidad entregada por la aplicación como un valor de normalización. Ya que la
«funcionalidad>>no se puede medir directamente, se debe derivar indirectamente mediante
otras medidas directas.
Las medidas que se deben analizar son las siguientes:
• Número de entradas de usuario
• Número de salidas de usuario.
• Número de peticiones de usuario
• Número de archivos
• Número de interfaces externas
Una vez que se han recopilado los datos anteriores, a la cuenta se asocia un valor de
complejidad. Para calcular puntos de función (PF), se utiliza la relación siguiente:
71
ITSCS
Figura 11 Cálculo de puntos de función
72
ITSCS
Miércoles – Semana V
Lenguaje Unificado de Modelado (UML)
Se trata de un lenguaje gráfico para construir, documentar, visualizar y especificar
un sistema de software. Entre otras palabras, UML se utiliza para definir un sistema de
software.
Posee la riqueza suficiente como para crear un modelo del sistema, pudiendo
modelar los procesos de negocios, funciones, esquemas de bases de datos, expresiones de
lenguajes de programación, etc. Para ello utiliza varios tipos diferentes de diagramas.
73
ITSCS
Figura 12 Diagramas UML
Diagramas UML
Diagramas estructurales
Los diagramas estructurales muestran la estructura estática del sistema y sus partes
en diferentes niveles de abstracción. Existen un total de siete tipos de diagramas de
estructura:
Diagrama de clases
Muestra la estructura del sistema, subsistema o componente utilizando clases con
sus características, restricciones y relaciones: asociaciones, generalizaciones, dependencias,
etc.
Diagrama de componentes
Muestra componentes y dependencias entre ellos. Este tipo de diagramas se utiliza
para el desarrollo basado en componentes (CDB), para describir sistemas con arquitectura
orientada a servicios (SOA).
Diagrama de despliegue
Muestra la arquitectura del sistema como despliegue (distribución) de artefactos de
software.
74
ITSCS
Diagrama de objetos
Un gráfico de instancias, incluyendo objetos y valores de datos. Un diagrama de
objeto estático es una instancia de un diagrama de clase; muestra una instantánea del estado
detallado de un sistema en un punto en el tiempo.
Diagrama de paquetes
Muestra los paquetes y las relaciones entre los paquetes.
Diagrama de perfiles
Diagrama UML auxiliar que permite definir estereotipos personalizados, valores
etiquetados y restricciones como un mecanismo de extensión ligero al estándar UML. Los
perfiles permiten adaptar el metamodelo UML para diferentes plataformas o dominios.
Diagrama de estructura compuesta
Muestra la estructura interna (incluidas las partes y los conectores) de un
clasificador estructurado.
Diagramas de comportamiento
A diferencia de los diagramas estructurales, muestran como se comporta un sistema
de información de forma dinámica. Es decir, describe los cambios que sufre un sistema a
través del tiempo cuando está en ejecución. Hay un total de siete diagramas de
comportamiento, clasificados de la siguiente forma:
75
ITSCS
Diagrama de actividades
Muestra la secuencia y las condiciones para coordinar los comportamientos de nivel
inferior, en lugar de los clasificadores que poseen esos comportamientos. Estos son
comúnmente llamados modelos de flujo de control y flujo de objetos.
Diagrama de casos de uso
Describe un conjunto de acciones (casos de uso) que algunos sistemas o sistemas
(sujetos) deben o pueden realizar en colaboración con uno o más usuarios externos del
sistema (actores) para proporcionar algunos resultados observables y valiosos a los actores
u otros interesados del sistema(s).
Diagrama de máquina de estados
Se utiliza para modelar el comportamiento discreto a través de transiciones de
estados finitos. Además de expresar el comportamiento de una parte del sistema, las
máquinas de estado también se pueden usar para expresar el protocolo de uso de parte de un
sistema.
Diagramas de interacción.
Es un subconjunto de los diagramas de comportamiento. Comprende los siguientes
diagramas:
Diagrama de secuencia
Es el tipo más común de diagramas de interacción y se centra en el intercambio de
mensajes entre líneas de vida (objetos).
76
ITSCS
Diagrama de comunicación
Se enfoca en la interacción entre líneas de vida donde la arquitectura de la estructura
interna y cómo esto se corresponde con el paso del mensaje es fundamental. La secuencia
de mensajes se da a través de una numeración.
Diagrama de tiempos
Se centran en las condiciones que cambian dentro y entre las líneas de vida a lo
largo de un eje de tiempo lineal.
Diagrama global de interacciones
Los diagramas globales de interacciones brindan una descripción general del flujo
de control donde los nodos del flujo son interacciones o usos de interacción.
77
ITSCS
Jueves – Semana V
Proceso Racional Unificado (RUP)
El Proceso Unificado Racional (Rational Unified Process en inglés, habitualmente
resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje
Unificado de Modelado UML, constituye la metodología estándar más utilizada para el
análisis, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologías adaptables al contexto y necesidades de cada organización.
También se conoce por este nombre al software desarrollado por Rational, hoy propiedad
de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de
las diversas actividades. Está incluido en el Rational Method Composer (RMC), que
permite la personalización de acuerdo a necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y
una especificación más detallada, el Rational Unified Process, que se vendiera como
producto independiente.
Principios de desarrollo
El RUP está basado en 5 principios clave que son:
78
ITSCS
Adaptar el proceso
El proceso deberá adaptarse a las características propias del proyecto u
organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen,
influirán en su diseño específico. También se deberá tener en cuenta el alcance del
proyecto.
Equilibrar prioridades
Los requerimientos de los diversos participantes pueden ser diferentes,
contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que
satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que
surjan en el futuro.
Demostrar valor interactivamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En
cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto,
y se refina la dirección del proyecto así como también los riesgos involucrados
Colaboración entre equipos
El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe
haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones,
planes, resultados,etc. tambien esta metodolgia esta basada en 2 punto 1,2
Elevar el nivel de abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales como patrón
del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos.
79
ITSCS
Ciclo de vida
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las
tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en
número variable según el proyecto y en las que se hace un mayor o menor hincapié en las
distintas actividades
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la
comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la
eliminación de los riesgos críticos, y al establecimiento de una baseline (Linea Base) de la
arquitectura.
Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de
modelado del negocio y de requerimientos.
En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de
la arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios
(refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la
arquitectura. En la fase de construcción, se lleva a cabo la construcción del producto por
medio de una serie de iteraciones.
80
ITSCS
Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y
diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para
cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación de la
nueva versión del producto.
En la fase de transición se pretende garantizar que se tiene un producto preparado
para su entrega a la comunidad de usuarios. Como se puede observar en cada fase
participan todas las disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una
disciplina varía.
Principales características
● Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y
cómo)
● Pretende implementar las mejores prácticas en Ingeniería de Software
● Desarrollo iterativo
81
ITSCS
● Administración de requisitos
● Uso de arquitectura basada en componentes
● Control de cambios
● Modelado visual del software
● Verificación de la calidad del software
82
ITSCS
Actividades - Semana V
Actividad 1
Con el tema métricas en el proceso y dominio del proyecto realizar un mapa conceptual en
el que explique las características principales.
Actividad 2
Con la tarea anterior realice una presentación en PowerPoint (mínimo 10 diapositivas).
Actividad 3
Amplié el tema métricas orientadas a la función mediante una investigación.
Actividad 4
Explique gráficamente la tarea anterior utilice mapas conceptuales.
Actividad 5
Mediante un gráfico explique que son las métricas orientadas al tamaño.
Actividad 6
Consulte que es una métrica, un indicador y una medición puede presentar la tarea
utilizando lluvia de ideas.
Actividad 7
Consulte que es Lenguaje Unificado de Modelado (UML)
83
ITSCS
Actividad 8
Con la consulta anterior realice una exposición utilice el material o el programa que usted
desee.
Actividad 9
Realizar un resumen del tema RUP (mínimo 250 palabras).
Actividad 10
Realice un resumen con la materia vista en la semana (mínimo 250 palabras).
84
ITSCS
Recursos – Semana V
Videos
● Métricas en el proceso y dominio del proyecto
https://www.youtube.com/watch?v=zN-RBp8UoE0
● Lenguaje unificado de modelado (UML)
https://www.youtube.com/watch?v=-OWd0tJAK10
● Proceso Racional Unificado( RUP)
https://www.youtube.com/watch?v=bV8MgbfOO5g
Presentaciones
https://es.slideshare.net/sergiolimachi/uml-presentacion-69777655
https://es.slideshare.net/dersteppenwolf/la-ingeniera-de-software-y-rup?qid=f044dfe
8-56b9-40e0-8ff8-6908b778c979&v=&b=&from_search=1
Lectura complementaria
https://ingenieriasoft.webcindario.com/gestion-y-planificacion-de-proyectos/el-proc
eso-de-software-y-metricas-del-proyecto/metricas-en-el-proceso-y-dominios-del-pr
oyecto.html
85
ITSCS
https://www.lucidchart.com/pages/es/que-es-el-lenguaje-unificado-de-modelado-um
https://softwarerecopilation.wordpress.com/modelo-rup/
86
ITSCS
Referencias
Concepto.de. (04 de 04 de 2005). gestion de proyectos. Recuperado el 01 de 05 de 2020, de

https://concepto.de/gestion-de-proyectos/
87

Guia Gestion de Software

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 Gestion de Software

Cargado por

Copyright:

Formatos disponibles

Instituto Tecnológico Superior Compu Sur

Tecnología en Desarrollo de Software

Tlga. Adriana Calderón

Octubre 2020 – Marzo 2021

TECNOLOGÍA EN DESARROLLO DE SOFTWARE GESTION DE SOFTWARE

Hay una serie de paquetes de software y soluciones dedicados a abordar el problema

de cómo administrar documentos de manera eficiente y efectiva en un entorno digital.

combina la gestión de documentos con capacidades adicionales como parte de un conjunto

más amplio de software. Debido a estas diferencias, comparar el Software de Gestión

en que se implementa el software y los sistemas con los que es compatible.

Por ejemplo, algunas soluciones pueden instalarse localmente en ordenadores o

TECNOLOGÍA EN DESARROLLO DE SOFTWARE GESTION DE SOFTWARE

TECNOLOGÍA EN DESARROLLO DE SOFTWARE GESTION DE SOFTWARE

La gestión de proyectos es una disciplina de la administración de empresas, cuyo

objeto de estudio abarca la planificación, organización, motivación y el control de los

recursos necesarios para alcanzar un fin determinado de antemano, o sea, cumplir con un

En este sentido, se define “proyecto” como un emprendimiento dotado de principio

y fin determinados, cuyo objetivo es producir un único producto, servicio o resultado, es

o logrará algún tipo de cambio positivo.

Así, la gestión de proyectos puede entenderse como un conjunto de acciones

determinadas que garantizan el cumplimiento de un objetivo dentro de unos plazos de

aplicando para ello metodologías, razonamientos y conceptos.

En el mundo empresarial de hoy es sumamente frecuente el enfoque desde la

gestión de proyectos, sin importar las dimensiones o los objetivos de una organización, ya

la elaboración de un producto o de un servicio importantes, o el cumplimiento de objetivos

TECNOLOGÍA EN DESARROLLO DE SOFTWARE GESTION DE SOFTWARE

secundarios, hasta el mejoramiento de los procesos internos de la misma organización

La gestión del proyecto está esencialmente dirigida a conseguir los objetivos

preestablecidos para proporcionar un beneficio a la organización.

Los objetivos pueden expresarse en términos de:

● Resultados (como la creación de una nueva sede central)

● Consecuencias (como la reubicación de los empleados a nueva sede);

● Beneficios (reducción de costes de cheques de comida, del mantenimiento de las

● Objetivos estratégicos (como duplicar el rendimiento corporativo en tres años).

TECNOLOGÍA EN DESARROLLO DE SOFTWARE GESTION DE SOFTWARE

más comunes son el tiempo, el coste y el alcance.

Gestión de Proyectos, en donde:

● El tiempo.- es un recurso invaluable. Si bien podemos controlar los procesos, no

podemos controlar el tiempo. Por lo que es un verdadero desafío poder utilizar el

tiempo de manera eficiente, mantener el proyecto dentro del cronograma y alcanzar

los objetivos deseados

● El coste está compuesto por un presupuesto establecido en la etapa inicial del

proyecto. Después, éste se compara con la cifra que se propuso inicialmente.

Las tres restricciones están interconectadas y dependen mucho la una de la otra. Una

completar con éxito el proyecto.

TECNOLOGÍA EN DESARROLLO DE SOFTWARE GESTION DE SOFTWARE

Figura 1 Triangulo de calidad

TECNOLOGÍA EN DESARROLLO DE SOFTWARE GESTION DE SOFTWARE

Etapas de la gestión de proyectos

Las etapas o fases de la gestión de proyectos son las siguientes:

● Análisis de viabilidad. El paso inicial consiste en determinar qué tan viable o

conveniente es el proyecto, o sea, qué implica llevarlo adelante en términos

financieros, logísticos y de rentabilidad. Si la inversión en un proyecto supera por

● Planificación del trabajo. Luego se procede a enumerar y detallar las distintas

coste, esfuerzo y tiempo necesarios.

levanta un informe de cómo ocurren, es decir, qué tropiezos encuentran, qué

resultados arrojan y toda la información necesaria para alimentar la etapa de control.

Esta es la etapa en que se despliega todo lo planificado.

los resultados esperados, y se deben extraer las conclusiones pertinentes a partir de

la información recabada durante la ejecución. En base a dichas conclusiones se

TECNOLOGÍA EN DESARROLLO DE SOFTWARE GESTION DE SOFTWARE

podrán modificar estrategias, tomar correctivos y dirigir el proceso hacia un