EVALUACIÓN PRACTICA

INGENIERIA DE SOFTWARE

ESTUDIANTE: ELKIN JAVIER ARROYO FIGUEROA

CÓDIGO: 2254627

T.I: 1007211109

DOCENTE: PABLO EMILIO CUENCA RIVERA

UNIVERSIDAD SANTO TOMÁS VICERRECTORÍA DE UNIVERSIDAD

ABIERTA Y A DISTANCIA

INGENIERIA EN INFORMATICA

CENTRO DE ATENCIÓN UNIVERSITARIO (CAU) MONTERIA

(MONTERIA) 10/10/ 2020
INTRODUCCIÓN
La ingeniería comprende todos aquellos procesos de forma sistemática el cual involucra los
métodos y términos en el que se deben comprender los lenguajes programáticos, los
sistemas de identificación en las materias de interdisciplinariedad que permite la
comprensión de los propósitos a implementar los sistemas complejos. Las principales
fuentes de ingeniería comprenden a su vez la aplicabilidad de las matemáticas (lenguaje
lógico) y la física de circuitos integrados a dichos sistemas que dirigen las fuerzas
dinámicas que contribuyen a la navegabilidad a sitios web en los entes de sociabilidad
conforme a la interacción interdisciplinaria.

OBJETIVOS
GENERAL:

Conocer los diferentes estándares por los cuales se rige el desarrollo del software para
desarrollar esta actividad de manera eficaz.

ESPECIFICOS

 Investigar los distintos requerimientos funcionales y no funcionales de los diversos

usuarios que quieran obtener un producto software.
 Conocer los diversos conceptos que encierra el modelo matemático COCOMO II.
 Estudiar cada concepto visto en el material principal.
 Analizar si la actividad queda interiorizada para nuestro diario vivir

ACTIVIDADES A DESARROLLAR
Actividad 1.

Una institución educativa desea implementar un sistema de información que incluya un

producto software que le permita cambiar la forma de tener contacto con sus egresados.
Entre el conglomerado de datos, los más importantes están los datos personales, familiares,
laborales y oferta de eventos académicos.

En el marco de la ingeniería de software, Ud. debe presentar una propuesta de

determinación de los requerimientos funcionales, no funcionales, de los usuarios, del
sistema y de la interfaz para los siguientes procesos que solicita el programa académico:
Consultar la información del egresado, información de la empresa y cargo que desempeña
el egresado actualmente, enviar mensajes masivos de la oferta académica de educación
continua y eventos académicos orientados a los egresados. Teniendo en cuenta este caso
simulado, cuál sería lo mejor que usted. le ofrecería a la institución educativa en el estudio
de levantamiento de requerimientos para iniciar la solicitud del producto software? En
algunos casos tendrá que tomar posición de usuario. Con su actitud investigativa podrá
complementar el planteamiento de la situación a resolver y/o complementar detalles del
problema de base descrito anteriormente.

SOLUCION

En primera instancia se debe realizar el estudio para indicar cuál es el software más
adecuado que cumpla con los objetivos que desea la institución. Lo siguiente es realizar el
análisis de los requerimientos por parte de la institución que desea que se implemente en el
desarrollo del software, para así poder definir el adecuado desempeño del producto
software en cuanto al sistema, las correspondientes funcionalidades y sus debidas
restricciones con los usuarios.

Teniendo toda la información requerida por parte de los usuarios que utilizarían nuestro
producto, se encierran los diferentes enfoques o puntos de vista que tienen los usuarios del
sistema, o que esperan que tenga el producto software, existen varios puntos de vista, el
directo, el cual lo conforman los usuarios directamente involucradas, en este caso serían
las personas de la institución, esta también el indirecto, que lo conformaría los usuarios que
no utilizarían el sistema por ellos mismos, y por último los puntos de vista de dominio que
incluyan los requerimientos y estructurado del producto software.
Con esta información obtenida, sobre los puntos de vista se escogen los más importantes y
se procede a especificar los respectivos requerimientos y luego se determina la validación
de estos mismos, para prevenir los posibles errores y durante dicha validación.

Los procesos para la validación son: verificación de validez, constancia, integridad,

realismo y verificabilidad.

De esta manera se procede a la implementación del software para esta institución, el cual va
a ser un software web diseñado bajo una base de datos robusta, esto por lo que en uns
institución se maneja bastante información, y se necesitaría contar con el espacio suficiente
para guardar la información año tras año, esta permitiría guardar toda la información de los
egresados, crear un vínculo, interfaz o conector a los correos de los egresados, y de esta
forma el sistema les notifique de todas actividades de la institución, envié mensajes
masivos de la oferta académica de educación continua y eventos académicos por parte de la
institución, también permita egresados la opción de actualización de su información sobre
la empresa en la que labora, cargo que ocupa actualmente y logros profesionales, no todos
los datos serian codificables por los egresados.

Requerimientos funcionales:

El sistema debe permitir el ingreso de la información de los egresados por el personal

encargado en la institución, permitir y visualizar la información actualizada hecho por los
egresados, actualizar los datos de los egresados.

Requerimientos no funcionales:

El sistema debe permitir ingresar a las bases de datos, ingresar en las tablas de diseño,
ingresar los formularios de diseño del sistema, ingresar a la codificación del sistema.

Mediante los siguientes diagramas como son, de caso de uso y diagrama de clase daremos
una perspectiva de su funcionamiento.
Casos de uso

Fuente: elaboración propia

Fuente: elaboración propia

Diagrama de clase

Fuente: elaboración propia

Este sería el diseño preliminar del software de la institución

Fuente: elaboración propia

Actividad 2.

En la planeación de proyectos de software es conveniente contar con un modelo

matemático que ayude a evitar el desvío sobre los objetivos planteados, proporcionando así
seguridad en el diseño del software. Para ello, existe entre otros, COCOMO II, que es la
métrica para la estimación de proyectos de software. Investigue sobre este modelo y
presente en forma resumida

SOLUCION

 Concepto básico

El Modelo Constructivo de estimación de costes (Constructive Cost Model) fue

desarrollado por B. W. Boehm a finales de los 70 y comienzos de los 80, exponiéndolo

detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981).

COCOMO es una jerarquía de modelos de estimación de costes software que incluye

submodelos básico, intermedio y detallado.

COCOMO II es un modelo algoritmo que permite estimar el coste, esfuerzo y tiempo

cuando se planifica una nueva actividad de desarrollo del software. Está compuesto por tres

modelos denominados: Composición de Aplicación, Diseño Temprano y Post-Arquitectura

 Composición de Aplicación: es el modelo de estimación utilizado en los proyectos

de software que se construyen a partir de componentes pre-empaquetadas.

 Modelo para Diseño Temprano (EDM) : se emplea en desarrollos de software

durante la etapa de prototipación

  Post-Arquitectura: se aplica en la etapa de desarrollo propiamente dicho, después

que se define la arquitectura del sistema, y en la etapa de mantenimiento

 Parámetros del COCOMO II

El parámetro principal para la estimación de costo es “Software Lines of Code”, La

estimación cubre únicamente un conjunto definido de fases

 Incepción

 Elaboración

 Construcción

 Transición

Incluye todos los costos directos del proyecto, pero no los indirectos

 El esfuerzo se mide en “Person-Month”; 1 PM = 19 persona-días = 152 persona -

horas

 Nombre del módulo deseado

 Número de líneas de código fuente (SLOC).

 Ecuación de COCOMO II y sus componentes

PM=NOP /PROD

Donde:

NOP (nuevos puntos Objeto): tamaño del nuevo software a desarrollar expresado en Puntos

Objeto y se calcula de la siguiente manera:

NOP= OP *-8100 -% reuso)/100.

OP (Puntos Objeto): tamaño del software a desarrollar expresado en Puntos Objeto

% reuso: porcentaje de rehúso que se espera lograr en el proyecto

PROD: es la productividad promedio determinada a partir del análisis de datos de

proyectos.

E=a ¿

D=c ¿

P=E /D

C = P* salario

Donde:

E: es el esfuerzo aplicado en personas – mes

D: es el tiempo de desarrollo en meses

KLOC: el número de líneas estimadas para el proyecto (en miles de kilos).

P: el número de personas necesarias para el proyecto.

C: costo del proyecto (p* salario medio) entre los programadores y analistas.

Los coeficientes a, b, c y d se obtienen de la siguiente tabla.

Tipo de proyecto a b c d
Orgánico 2.4 1.05 2.5 0.38
Medio 3.0 1.12 2.5 0.35
Embebido 3.6 1.20 2.5 0.32

 Concepto de Backfiring
Este método consiste en derivar el número de puntos de función de la aplicación a partir de

su tamaño físico. Se miden las líneas de código (LOC), utilizando un factor de conversión

constante dependiente del lenguaje de programación. Una vez que el cálculo de líneas de

código es hecho a través de herramientas automáticas, el número de puntos de función

podría ser derivado de inmediato. Por ejemplo, utilizando un factor de conversión de 80

LOC/PF y una aplicación con 80.000 líneas de código Java, da como resultado 1.000

puntos de función para esa misma aplicación. Por otro lado, muchos modelos de estimación

de software, como el COCOMO II, utilizan como datos de entrada el tamaño en líneas de

código. En esos casos, es común realizar el inverso: obtener el número de líneas de código

a partir del tamaño en puntos de función, debido a que en las fases iniciales de un proyecto

de software es más fácil estimar o medir su tamaño en puntos de función. Las

consideraciones anteriores sobre Backfiring también son válidas en estos casos.

 Escenario What-If

El análisis What If consiste en:

Simular resultados en función de hipótesis de variables de negocio.

Calcular valores de negocio posibles en base a drivers.

Comparar multidimensionalmente los diferentes escenarios simulados.

Es un método inductivo que utiliza información específica de un proceso para generar una

serie de preguntas que son pertinentes durante el tiempo de vida de una instalación, así

como cuando se introducen cambios al proceso o a los procedimientos de operación.

Consiste en definir tendencias, formular preguntas, desarrollar respuestas y evaluarlas,

incluyendo la más amplia gama de consecuencias posibles. No requiere métodos

cuantitativos especiales o una planeación extensiva.

El método utiliza información específica de un proceso como los DFP´s (Diagramas de

Proceso), DTI´s (Diagramas de Tubería e Instrumentación) para generar una especie de

preguntas de lista de verificación. Un equipo especial realiza una lista de planteamientos

empleando las preguntas ¿Qué pasa sí?, las cuales son contestadas colectivamente por el

grupo de trabajo y resumidas en forma tabular.

Esta técnica es ampliamente utilizada durante las etapas de diseño del proceso, así como

durante el tiempo de vida o de operación de una instalación, así mismo cuando se

introducen cambios al proceso o a los procedimientos de operación.

Ejemplo de COCOMOII.

La empresa “PARTY INGENIO” se dedica a la organización de fiestas informales a

domicilio, y le ha solicitado la realización de un sistema informático que les ayude en su
administración y control registrando en plantilla una serie de animadores, cada uno con
diferentes especialidades, que son: esculturas con globos, títeres, canciones, bailes,
imitaciones y magia. Los clientes de la empresa realizan peticiones de fiestas, que se
recogen en un formulario. Este recoge la fecha y la hora, duración, nombre y dirección, tipo
de fiesta (cumpleaños, comunión, otros), promedio de edad y cantidad de los asistentes,
número de animadores que se desean, junto con la especialidad de cada uno, así como
consideraciones especiales.

Una vez realizada la solicitud, los clientes reciben un presupuesto, si es posible realizar una
fiesta con las características indicadas. En caso de que la fiesta no se pueda realizar (por
problemas de fechas o disponibilidad de animadores), los clientes reciben una propuesta
alternativa. El cliente entonces puede confirmar el presupuesto o la propuesta recibida.

El encargado de la empresa puede consultar por un lado las características de los

animadores en plantilla, y por otro las fiestas pendientes. Además tiene que asignar
animadores a cada una de las fiestas. Los animadores por su parte, pueden realizar una
consulta con las fiestas que les han sido asignadas. Además, después de cada fiesta,
rellenarán un formulario con un parte de actividad, indicando la especialidad y la cantidad
de horas trabajadas.

Se pide:

a) Calcule razonadamente los puntos de función sin ajustar, suponiendo todos los elementos
de complejidad media.

b) Estime las líneas de código Java que tendrá la aplicación. Tenga en cuenta que SEGÚN
DATOS DE LA EMPRESA, son necesarios alrededor de 100 líneas de código por cada
Punto de Función.

c) Usando el modelo COCOMO estime el tiempo y esfuerzo necesarios para realizar la

aplicación. Nota: Para determinar cuál modo (tipo de proyecto) elegir, se sabe que todo el
personal de su empresa tiene gran experiencia en este tipo de aplicaciones.

SOLUCIÓN:
a) Calcule razonadamente los puntos de función sin ajustar, suponiendo todos los elementos
de complejidad

MEDIA.

Salidas: Presupuesto + Propuesta = 2 x 5 = 10

Entradas: Peticiones + Confirmación + Asignación de animadores + parte actividad = 4 x 4

= 16

Consultas: Características de animadores + fiestas pendientes + fiestas asignadas = 3 x 5 =

15

Ficheros lógicos internos: Personal + Fiestas = 2 x 10 = 20

Archivos externos: NO HAY.

Total: 61 PF (sin ajustar)

b) Estime las líneas de código Java que tendrá la aplicación. Tenga en cuenta que SEGÚN
DATOS DE LA EMPRESA, son necesarios alrededor de 100 líneas de código por cada
Punto de Función.

61 PF * 100 (LDC Java/ PF) = 6100 LDC Java

c) Usando el modelo COCOMO estime el tiempo y esfuerzo necesarios para realizar la

aplicación. Nota: Para determinar cuál modo (tipo de proyecto) elegir, se sabe que todo el
personal de su empresa tiene gran experiencia en este tipo de aplicaciones.

Como la empresa tiene gran experiencia y los requerimientos no tiene mayor dificultad, se
puede utilizar el modelo Orgánico. No tenemos datos sobre complejidades adicionales, o
sobre las características de nuestro equipo de desarrollo, así que usamos el COCOMO
BÁSICO:

b
E=a∗(KLDC )
 d
D=c∗( E)

1.05
E=2.4∗(6.1) =2.4∗6.67723=16.02535 p−m

d 0.38
D=c∗( E) =2.5∗( 16.02535 ) =2.5∗2.86964=7.1741 meses
 CONCLUSION

Esta actividad practica ha dejado un gran aporte en mis conocimientos, ya que, son
significativos e impulsan los objetivos que nos llevan a poder desarrollar las actividades de
una manera eficaz y efectiva, llevándonos al desarrollo de las mismas, permitiéndonos
aplicar los conceptos aquí aprendidos en nuestro diario vivir lo cual era uno de los objetivos
específicos.

Se debe tener en cuenta al momento de darle la correspondiente solución, realizar las

respectivas planificaciones a través de los modelos que requiere el diseño del producto,
conocer cuál sería el más adecuado a implementar es de suma importancia para que el
software presente los más mínimos errores.

Conociendo y comprendiendo la importancia de la ingeniería de software al momento del

diseño y creación de un producto software en nuestro entorno, podremos darle solución a
los casos más complejos que se nos presenten a nivel profesional o en el campo donde
laboremos más adelante.
 BIBLIOGRAFIA

Pressman, R. S. (2010). Ingeniería de software. En R. S. Pressman, Ingeniería de

software. Un enfoque práctico. mexico: Séptima edición. McGraw-Hill.

Sagrera, J. C. (2013). ebookcentral. Obtenido de ebookcentral:

https://ebookcentral.proquest.com/lib/bibliotecaustasp/reader.action?
docID=3219169&query=ingenieria+de+software