Ingeniería de Software I

Introducción al Análisis
de Sistemas
L I C E N C I AT U R A E N S I S T E M A S D E I N F O R M A C I Ó N

A N A L I S TA E N S I S T E M A S D E C O M P U TA C I O N

FA C U LTA D D E C I E N C I A S E X A C TA S Q U I M I C A S Y N AT U R A L E S

UNIVERSIDAD NACIONAL DE MISIONES

1.Normas de Presentación de
Trabajos Prácticos:
Formato Presentación
Word, Odt o PDF con permisos de lectura y escritura (para las observaciones y correcciones).
Times New Roman 12 ó Arial 10, interlineado sencillo.
Extensión (se aprecia la calidad, no cantidad): Máximo 10 hojas.
Carátula Identificando:
Materia, Docentes, Grupo, Integrante y tema desarrollado.
Nombre del Archivo que se subirá al aula virtual.
Grupo, Práctico en la forma: Grupo ## TP##.extensión.  Ejemplo: Grupo 1 TP1.doc

LOS COLORES Y FORMATOS ELEGIDOS POR CADA GRUPO SE DEBEN

MANTENER A LO LARGO DE TODAS LAS PRESENTACIONES COMO
DISTINTIVOS Y REPRESENTATIVOS DE SU IDENTIDAD COMO GRUPO

1
 Trabajo Práctico 4:
Estimación y Factibilidad
UNIDAD IV

Análisis de necesidades y estudio de viabilidad. Inicio de proyecto. Estudio de viabilidad. Técnicas de

relevamiento de información: entrevistas, JAD, prototipado. Análisis de sistemas. Enfoque estructurado.
Enfoque OO. Características de los paradigmas. Introducción al análisis de requisitos. Especificación de
requisitos: Características, evolución, estructura, requisitos de interfaces. Técnicas de especificación: según
forma de representación, según enfoque de modelización. Modelo ER y diagrama de estructura de datos:
elementos, construcción. Técnicas de especificación de control. Comprobaciones a efectuar entre modelos
de análisis.

Estudio de Factibilidad
El estudio de factibilidad de un proyecto, también conocido como estudio de viabilidad, tiene la función de
ayudar a decidir de manera objetiva si debe procederse con un proyecto propuesto.

Por lo tanto, el estudio de factibilidad debe considerar factores como las limitaciones tecnológicas, el
mercado, estrategia de mercadeo, requerimientos de personal, cronograma de ejecución y las
proyecciones económicas.

2
 Factibilidad
Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas
señaladas.

Generalmente la factibilidad se determina sobre un proyecto. Estos resultados se entregan a la gerencia,

quienes son los que aprueban la realización del sistema informático.

Viabilidad
Viabilidad se refiere a la probabilidad que existe de llevar aquello que se pretende o planea a cabo, de
concretarlo efectivamente.

Factibilidad y viabilidad son sinónimos, es decir, podemos hablar de un Estudio de Factibilidad y de un

Estudio de Viabilidad como documentos que cumplen la misma función en la Gerencia de Proyectos.

3
 Estudio de Factibilidad
El Modelo de Estudio de Factibilidad de un Proyecto, se divide en las siguientes secciones:

 Resumen ejecutivo: Probablemente será la única parte que leerán las personas que mayor influencia y
poder de decisión tienen sobre el proyecto. Por lo tanto, debe ser conciso, abarcando un resumen de
todo el estudio.

 Antecedentes del proyecto: En esta sección se presenta una introducción de la visión del proyecto y sus
orígenes.

 Descripción del proyecto y su contexto: Describe el propósito principal del proyecto y sus principales
entregables. También describe el contexto organizacional y cultural en el cual se desenvuelve el
proyecto, así como los entes externos interesados.

Estudio de Factibilidad
 Alcance del estudio de factibilidad: Resultados que se esperan del estudio de factibilidad, actividades
principales y procedimiento de aprobación.

 Factibilidad técnica: Consideraciones de orden tecnológico que deba realizar la organización. Se enfoca 
en obtener un entendimiento de los recursos tecnológicos disponibles actualmente y su aplicabilidad a 
las necesidades que se espera tenga el proyecto. En el caso de tecnología informática esto implica una 
evaluación del hardware y software.

 Factibilidad económica: El propósito del estudio de viabilidad económica, es determinar los beneficios 
económicos  del  proyecto  o  sistema  propuesto  para  la  organización,  en  contraposición  con  los 
costos.  Generalmente  incluye  un  análisis  costo  beneficio,  el  cual  se  prepara  como  parte  del  caso  de 
negocio de un proyecto.

4
 Estudio de Factibilidad
 Factibilidad legal: Aquí se determina si existe conflicto del proyecto con algún requerimiento legal. Si es 
aceptable para la ley y si cumple con las regulaciones sectoriales.

 Factibilidad de recursos: Tipo y cantidad de recursos materiales y humanos que se necesitan para
ejecutar el proyecto. Cantidad de personal que debe contratarse, incrementando el personal de la
organización, y si ésto es factible.

 Factibilidad de mercado: En esta sección se describe el mercado existente actualmente para los
productos y servicios que está considerando la organización. Además, establece la estrategia que se
usará para abordar a los consumidores potenciales.

Estudio de Factibilidad
 Factibilidad  operacional:  Se  enfoca  en  el  grado  con  el  cual  este  encaja  con  el  entorno  de  negocios 
existentes  y  objetivos  estratégicos,  respecto  al  cronograma,  fecha  de  entrega,  cultura  organizacional  y 
procesos de negocio.

 Factibilidad de tiempo: Un proyecto puede fracasar si tarda mucho tiempo en completarse. Por ende,
debe estimarse cuanto tiempo tomará el sistema o proyecto en construirse y si sus beneficios podrán
realizarse cuando esté completado.

 Recomendaciones y aprobación: Se explica y justifica si es recomendable ejecutar el proyecto o no

según el estudio de factibilidad realizado.

10

5
 Modelo de
Estudio de Factibilidad de un Proyecto

>> Descargar el Modelo de estudio de factibilidad de un proyecto

11

Estimación y Factibilidad
Cuestiones como el tiempo de duración del proyecto, los recursos involucrados y su disponibilidad, y los costos
que ello implica son factores determinantes para un informe de Factibilidad del Proyecto.

Hemos visto en unidades anteriores cómo realizar las estimaciones de tiempo por métodos de planificación de
proyectos como Gantt y Camino Crítico.

Estas pueden ser muy útiles al asignarle recursos a cada tarea y determinar los costos involucrados en cada
recurso, pudiendo identificar no solamente el tiempo que lleva una tarea si no también sus costos.

Herramientas como Gantt Project vistas en clases permiten realizar estas asignaciones de recursos a las tareas y
cabe destacar que existen herramientas más elaboradas para la planificación estratégica de proyectos que se
pueden integrar al entorno de desarrollo. Por ejemplo. ORACLE Primavera P6 Project Management.

Como así otras metodologías estratégicas para la gestión de proyectos como: Kanban ha pasado a formar parte
de las llamadas metodologías ágiles.

12

6
 Estimación
Cuando la gerencia te pregunte cuánto dinero necesitás para desarrollar tu próximo proyecto de software,
es conveniente que cuentes con ejemplos de estimación de costos de un proyecto de software, los cuales
puedas usar como referencia y guía.

Para realizar una estimación de costos de un proyecto de software necesitarás dos cosas, en primer lugar
determinar el tamaño del software que vas a desarrollar, utilizando alguna unidad de medida, luego,
necesitarás saber cuántas unidades de dicha medida puede desarrollar tu equipo de trabajo, a un
determinado costo.

13

Estimación
La determinamos identificando cuales son los requerimientos funcionales para medir, cual es el propósito
de la medición y quiénes son los usuarios funcionales.

La guía del Business Analysis Body of Knowledge (BABOK) en su versión 3, proporciona la siguiente
definición para los requerimientos funcionales de una solución:

“Los requerimientos funcionales son las descripciones explícitas del comportamiento que debe tener una
solución de software y qué información debe manejar.”

14

7
 Estimación y RF
Por lo tanto, los requerimientos funcionales:

 Expresan las capacidades o cualidades que debe tener la solución

para satisfacer los requerimientos de los interesados de proyecto
(stakeholders).

 Se expresan en términos de cuál debe ser el comportamiento de

la solución y qué información debe manejar.

 Deben proporcionar una descripción lo suficientemente detallada

para permitir el desarrollo e implementación de la solución.

 Son los que más influyen en si la solución será aceptada o no por

los usuarios.

15

Ejemplo de Estimación por RF

Propósito de la medición

Realizar la estimación funcional de la mejora al sistema de administración, comprendida por los requisitos
de lista de pedidos pendiente, facturación de pedidos y envío de email al facturar el pedido.

Usuarios

El principal usuario funcional del sistema es el Analista del departamento de facturación y cuentas por
cobrar.

16

8
 Ejemplo de Estimación por RF
Requerimientos funcionales del proyecto
Lista de pedidos pendiente de facturación

La facturación de pedidos de venta se realizará en lotes, por medio de una pantalla de pedidos pendientes de
facturación, la cual mostrará los pedidos no facturados. Estos pedidos se podrán consultar por fecha de inicio y
fecha fin, o por cliente. La lista de pedidos de venta pendientes se podrá imprimir o exportar a un archivo Excel.

Facturación de pedidos

Desde la pantalla de pedidos pendientes, el usuario podrá seleccionar uno o varios pedidos para ser facturados.
Se podrá facturar un pedido individual o un lote de pedidos. El usuario podrá escoger entre emitir una factura por
pedido o unificar las facturas por cliente. Una vez facturado, se cambiará el estatus del pedido a “facturado”, de
esta forma, al refrescar la lista de pedidos pendientes este no será mostrado.

17

Ejemplo de Estimación por RF

Mapeo y medición

En el método COSMIC (ISO/IEC 19761) describe los principios, reglas y procesos para medir de manera
estándar el tamaño funcional de una pieza de software, utilizamos la ingeniería de software de nuestro
proyecto para determinar cuáles son los procesos funcionales y movimientos de datos que lo componen.
Posteriormente, asignamos un punto de función COSMIC por cada movimiento de datos identificado.
El método puede ser utilizado para medir los requerimientos funcionales de usuario (FUR) de un software:

 A cualquier nivel de descomposición, toda la pieza o componentes.

 En alguna capa o en multicapas.

 En cualquier parte del ciclo de vida del software.

18

9
 Ejemplo de Estimación por RF
Un “proceso funcional” es un componente
elemental de un conjunto de requerimientos de
usuario, que consolidan un conjunto único,
cohesivo e independientemente ejecutable de
movimientos de datos. Es iniciado por un
movimiento de datos y es completado cuando se
han realizado todos los movimientos de datos
necesarios para completar la acción en
respuesta al evento disparador.

El tamaño de una pieza de software es definido

por el número de “movimientos de datos” que
se presentan en un “proceso funcional”.

19

Ejemplo de Estimación por RF

 Entrada – E (Entry). Es un movimiento de datos que mueve un grupo de datos desde el usuario funcional
a través de la frontera hacia el proceso funcional que lo requiere.

 Salida – X (Exit). Es un movimiento de datos que mueve un grupo de datos desde el proceso funcional a
través de la frontera hacia el usuario funcional que lo requiere.

 Lectura – R (Read). Es un movimiento de datos que mueve un grupo de datos del almacenamiento
persistente hacia el proceso funcional que lo requiere.

 Escritura – W (Write). Es un movimiento de datos que mueve un grupo de datos que está en el proceso
funcional hacia el almacenamiento persistente.

20

10
 Ejemplo de
Estimación
por RF
El tamaño de la pieza de
software, se obtiene sumando
los movimientos de datos
(componente básico de
funcionalidad) de todos los
procesos funcionales. Un
ejemplo de una medición
utilizando este método se
muestra en la figura siguiente:

21

Ejemplo de Estimación por RF

Proceso funcional: Mostrar lista de pedidos pendientes de facturación.
Movimientos de datos:
1. Entrada: Seleccionar en el menú la opción lista de pedidos pendientes.
2. Lectura: Obtener todos los pedidos de venta pendientes.
3. Salida: Mostrar en pantalla todos los pedidos de venta pendientes.
4. Entrada: Especificar fecha inicial y final de pedido.
5. Entrada: Especificar cliente de pedido.
6. Lectura: Obtener pedidos de venta filtrados según parámetros de búsqueda.
7. Salida: Mostrar en pantalla lista de pedidos pendientes según criterios de filtrado.
8. Salida: Imprimir lista de pedidos.
9. Salida: Exportar lista de pedidos a Excel.

Puntos de función COSMIC: 9 CFP.

22

11
 Ejemplo de Estimación por RF
Proceso funcional: Facturar pedidos pendientes.
Movimientos de datos:
1. Entrada: Seleccionar pedido a facturar.
2. Entrada: Seleccionar facturación agrupada por cliente o individual por pedido.
3. Entrada: Iniciar proceso de facturación por medio de botón.
4. Lectura: Leer de la base de datos los datos de pedidos seleccionados para facturación.
5. Lectura: Leer las líneas de pedido.
6. Escritura: Crear un registro de factura para cada pedido (Facturación individual).
7. Escritura: Crear registro de líneas de factura individual.
8. Escritura: Agrupar pedidos de un mismo cliente y crear registro de factura (Facturación por cliente).
9. Escritura: Crear registro de líneas de factura por cliente.
10. Escritura: Cambiar el estatus de pedido a facturado.

Puntos de función COSMIC: 10 CFP.

23

Ejemplo de Estimación por RF

De esta forma, hemos determinado que nuestro proyecto tiene una medición de:

19 puntos de función COSMIC (19 CFP).

⦁ Costo del equipo de trabajo de desarrollo de software

Para determinar el costo de desarrollo de una unidad de medida del tamaño del software, necesitamos
valernos de la información de proyectos pasados que tenga la organización. También podemos usar
información de otras fuentes, otras organizaciones y bases de datos de Benchmark.

24

12
 Ejemplo de Estimación por RF
Supongamos que tenemos un equipo de desarrollo de software y sabemos que su costo mensual es de
120,000 Pesos (3 personas un Analista Programador, Un Programador y Diseñador y Un DevOp, con
sueldos de 40.000 pesos cada uno).

Para determinar este costo, debemos considerar el número de personas, cual es la remuneración de cada
rol, por ejemplo, desarrollador, analista de prueba, diseñador, líder de proyecto, etc. Además, debemos
considerar otros gastos del personal como lo son beneficios de fin de año, seguros, y también el costo
administrativo de cada persona, por ejemplo la infraestructura donde trabaja, gastos de gerencia y
administración, entre otros.

Si estamos haciendo este proyecto para un tercero y estamos elaborando la estimación de costos de un
proyecto de software, tenemos que agregar además el margen de ganancia que esperamos obtener.

25

Ejemplo de Estimación por RF

Unidades de medida que puede desarrollar el equipo de trabajo en un tiempo determinado

Ahora, supongamos que examinando la información histórica de la organización, podemos determinar que 
en los últimos 12 meses, el equipo de trabajo ha producido un promedio de 23 puntos de función COSMIC 
mensuales.

Para que esta medición sea exacta, debemos considerar que un punto de función está desarrollado 
solamente cuando está completamente listo e instalado en ambiente de producción. Si una funcionalidad 
se desarrolló pero aún está en pruebas o aún no ha pasado a producción no debe contar para el cálculo del 
promedio de los puntos de función desarrollados en el mes.

26

13
 Ejemplo de Estimación por RF
⦁ Determinar el costo por unidad de medida

Para determinar cuánto cuenta desarrollar cada punto de función se utiliza la siguiente formula:

Costo por punto de función = Costo mes del equipo de trabajo / puntos de función del mes

Retomando nuestro ejemplo:

Equipo 120,000 pesos + gastos administrativos 40,000 pesos + 25% ganancia = 200,000 pesos

Costo por punto de función = 200,000 pesos/ 23 puntos de función 

= 8696 Pesos/ Punto de función

27

Ejemplo de Estimación por RF

⦁ Ejemplo de estimación de costos de un proyecto de software

Una vez que contamos con la medición del tamaño del software y el costo por unidad de medida, podemos determinar el costo 
del proyecto de software usando la siguiente formula:

Costo de un proyecto de software = Tamaño del software x Costo por punto de función

En nuestro ejemplo de estimación de costos de un proyecto de software lo determinamos de la siguiente forma:

Costo del proyecto de software = 19 CFP x 8.696 pesos

Costo del proyecto de software = 165.224 pesos

28

14
 Ejemplo de Estimación por RF
Tiempo que durará el proyecto de desarrollo de software
Los puntos de función COSMIC los podemos utilizar también para determinar cuánto tiempo durará el proyecto de software.

En nuestro ejemplo, sabemos que el equipo de desarrollo de software produce 31 puntos de función al mes y sabemos también
que el software que vamos a desarrollar está estimado en x puntos de función. Si dividimos el tamaño funcional del software
entre el número de puntos de función mes podemos determinar el número de meses que durará el proyecto.

Duración del proyecto = 19 puntos de función COSMIC / 23 puntos de función COSMIC mes

Duración del proyecto = 0,83 meses

Conclusión

De esta forma hemos determinado que nuestro proyecto de software:

Durará 0,83 meses en desarrollarse (Poco menos de un mes)
Costará 165,224 pesos

29

Puntos de Función
PF

30

15
 Ejemplo basado en PF
IFPUG es una organización no lucrativa, organización gobernada miembro que respalda dos tipos de
metodología estándar para el dimensionamiento de software.

Una de las normas se define en el punto de función Prácticas conteo manual (CPM), el estándar
industrial reconocido para el Análisis de Puntos de Función (FPA). Proporciona un foro para la creación
de redes y el intercambio de información que promueve y fomenta el uso de métricas de productos de
software y de procesos Esta norma es la norma ISO certificada. ('ISO/IEC 14143-1:1998', revisado en
'ISO/IEC 14143-1:2007’. )

El otro estándar son un estándar de la industria en evolución definido en el proceso de evaluación del
software no funcionales (Manual de prácticas de evaluación de SNAP (APM).

Fuente: https://www.ifpug.org

31

Ejemplo basado en PF
PF: Fue definida por Allan Albrecht, de IBM, en 1979 ("Measuring Application Development Productivity") Análisis
de Puntos de Función (FPA) es una medida de tamaño de la significación de negocio claro. La técnica de FPA
cuantifica las funciones contenidas en el software en términos que sean significativos para los usuarios de
software.

SNAP: SNAP es el proceso de evaluación de software no funcionales.

Mientras que los puntos de función miden los requisitos funcionales dimensionando los datos de fluir a través de
una aplicación de software, SNAP mide los requisitos no funcionales. Por tanto, es complementario a FPA.

El modelo SNAP consiste en cuatro categorías y catorce sub-categorías para medir los requisitos no funcionales.
requisito no funcional se asignan a las subcategorías pertinentes. está dimensionado de cada subcategoría, y el
tamaño de un requisito es la suma de los tamaños de sus subcategorías.

Fuente: Albrecht A. ("Measuring Application Development Productivity")

http://fattocs.com/files/pt/artigos/MeasuringAplicationDevelopmentProductivity.pdf
32

16
 Ejemplo basado en PF
El método IFPUG-FPA (Function Point Analisys) establece los siguientes pasos:
1. Determinar el tipo de recuento: puede tratarse de un proyecto, una mejora a una aplicación o
refactoring de una aplicación ya instalada. Según el tipo se incluirán funciones de conversión,
modificación y baja de funcionalidad.
2. Identificar el alcance del recuento y los límites de la aplicación: se delimita el alcance de lo que se va a
medir.
3. Contar las funciones de datos: se realiza un inventario de los ficheros lógicos utilizados (vistos como
un usuario) tanto internos de la aplicación como mantenidos por otra aplicación. Para cada uno de
ellos se recuenta el número de datos y de registros lógicos. En función de este número se calcula para
cada fichero un índice de complejidad y posteriormente una contribución en puntos función.

Fuente: International function point user group

https://web.archive.org/web/20041010044613/http://www.ifpug.org/about/bibliography.htm

33

Ejemplo basado en PF
4. Contar las funciones transaccionales: de modo similar se realiza un inventario de los procesos
elementales del sistema, distinguiendo los procesos de entrada, salida y consulta. Según el
número de ficheros lógicos y datos que maneja cada proceso y de su naturaleza, se calcula su
índice de complejidad y su contribución en puntos función.

5. Calcular el recuento bruto de puntos función: partir de los recuentos anteriores se calcula un
recuento total bruto (unadjusted).

6. Determinar el factor de ajuste: en función de 14 "características generales del sistema" que se

valoran de 0 a 5 en función de su grado de influencia, se calcula un factor de ajuste al recuento.
Estas características tienen que ver con la arquitectura de la aplicación, sus requisitos de carga y
rendimiento, complejidad de cálculos, etc.

7. Calcular el recuento ajustado: aplicando el factor de ajuste al recuento bruto se obtiene el recuento
final.

34

17
 Ejemplo basado en PF

TABLA I - Tabla de total de función sin ajustar (TUFP)

35

ESTATUS SENSORES
MENSAJES
SENSOR DE
CONTRASEÑA PRUEBA SENSORES

CONSULTA ZONA
FUNCION E CONFIG. DE ZONA
INTERACCIÓN
USUARIO CONSULTA DE USUARIO EN
SENSORES HOGAR SEGURO ACTIVAR/DESACTIVAR

ACTIVAR/DESACTIVAR

BOTON PANICO SUBSITEMA DE

MONITOREO

DATOS DE ALERTA DE ALARMA

CONFIGURACION DEL
SISTEMA CONTRASEÑA, SENSORES, …

Diagrama de Contexto de ejemplo

36

18
 Ejemplo basado en PF
Valor del dominio de la inf. Conteo Factor Subtotal

Simple Promedio Complejo

Entradas externas (EE) 3 3 4 6 9

Salidas externas (SE) 2 4 5 7 8
Consultas externas (CE) 2 3 4 6 6
Archivos de lógica interna 1 7 10 15 7
(ALI)
Archivos de Interfaz externa 4 5 7 10 20
AIE)
50

Calculo PF

37

Ejemplo basado en PF
1. Respaldo y recuperación: El sistema requiere respaldo y recuperación confiable?
2. Comunicaciones de datos: Se requiere comunicación de datos especializada para transferir información a la aplicación u obtenerla de
ella?
3. Procesamiento distribuido: Hay funciones distribuidas de procesamiento?
4. Desempeño crítico: el desempeño crítico?
5. Entorno operativo existente: el sistema se ejecutará en un entorno existente que tiene un uso pesado de operaciones?
6. Entrada de datos en línea: el sistema requiere entrada de datos en línea?
7. Transacción de entrada sobre pantallas múltiples: la entrada de datos en línea requiere que la transacción de entrada se construya en
varias pantallas u operaciones?
8. ILF actualizado en línea: Los ALI se actualizan en línea?
9. Complejo de valores de dominio de información: las entradas , las salidas, los archivos o las consultas son complejos?
10. Complejo de procesamiento interno: es complejo el procesamiento interno?
11. Código diseñado para reutilización: el código diseñado será reutilizable?
12. Conversión/instalación en diseño: se incluyen la conversión e instalación en el diseño?
13. Instalaciones múltiples: esta diseñado el sistema para instalaciones múltiples en diferentes organizaciones?
14. Aplicación diseñada para cambio: la aplicación esta diseñada para facilitar el cambio y para que el usuario lo utilice fácilmente?
Factor de Ajuste de Valor: suma de 0 a 5 por cada ítem

38

19
 Ejemplo basado en PF

LOC por PF por lenguaje

39

Ejemplo basado en PF
PF = conteo total x (0.65+0.01 x ∑ (Fi))
Para el ejemplo
PF= 50 x (0.65+(0.01 x 46))
Supóngase que los datos históricos dicen que un PF equivale a 60 LOC y que se
producen 12 PF por cada persona-mes.
Supóngase también que en proyectos anteriores se han encontrado en promedio
tres errores por punto de función durante la revisión de análisis y diseño.
Los PF también pueden calcularse a partir de diagramas UML de clases y
secuencias.
Factor de Ajuste de Valor

40

20
 Tabla de E/S 50
Sum Fi 46
PF: =50*(0,65+(0,01*46)) 55,5
LOC x PF: dato de productividad 60
LOC Totales: (55,5*60) 3330

PF persona-mes: dato de productividad 12

personas – mes: (55,5/12) 4,625

costo persona –mes: dato del mercado $ 40.000,00

cant personas disponibles: dato de la
empresa 3
Meses: estimación de tiempo 2
Costo total
$ 240.000,00

Factor de Ajuste de Valor

41

Trabajo Práctico 4:
Estimación y Factibilidad
1. ¿Cómo y para qué se utiliza el estudio de factibilidad?

2. ¿Qué agregaría o quitaría del modelo de estudio de factibilidad de un proyecto?

3. ¿Cuál método de estimación de costos de proyectos de software le parece mejor?

4. ¿Qué ventajas y desventajas ve para este método?

5. Para el escenario planteado en el ejercicio anterior y que se replica a continuación, determinar los
siguientes tres tipos de factibilidad: técnica, económica y operativa y proponer y fundamentar si
considera necesario determinar alguna de las demás factibilidades vistas en clases o presentes en la
bibliografía.

42

21
 Bibliografía
1. Somerville Ian 7 Edición. Ingeniería de Software. Editorial Prentice Hall. Disponible en: 
https://books.google.com.ar/books?id=gQWd49zSut4C&lpg=PP1&dq=sommerville%20ingenieria%20de%20software&hl=es&pg=PP1#v=onepa
ge&q=sommerville%20ingenieria%20de%20software&f=false
2. Kendall y Kendall 6 Edición Análisis y Diseño de Sistemas. Editorial Prentice Hall. Disponible en: https://books.google.com.ar/books?id=5‐
rZA0FggusC&lpg=PA107&ots=1F0IICD‐
x5&dq=cuestionarios%20condescendencia&pg=PP1#v=onepage&q=cuestionarios%20condescendencia&f=false

Lecturas recomendadas en Gerencia de proyectos
 A Guide to the Project Management Body of Knowledge (PMBOK® Guide)–Sixth Edition (SPANISH) (Spanish Edition) (Español) Pasta blanda –
diciembre 1, 2017 
 Garriga Rodriguez, Albert. Guía práctica en gestión de proyectos: Aprende a aplicar las técnicas de gestión de proyectos a proyectos reales 
(Spanish Edition) Edición Kindle 
Sitios
 http://www.pmoinformatica.com/
 http://www.the‐aba.com/administrator/components/com_event/uploads/59014e456ca677.92343092BABOK_Guide_v3_Member.pdf
 https://www.iso.org/standard/54849.html
 https://www.iso.org/obp/ui/#iso:std:iso‐iec:19761:ed‐2:v1:en
 https://www.ecured.cu/COCOMO_II
 https://csse.usc.edu/tools/COCOMOII.php
 https://csse.usc.edu/csse/research/COCOMOII/cocomo_downloads.htm

43

22