DISEÑO DE SOFTWARE 2

TALLER DISEÑO DE SOFTWARE 2

PROFESOR
ORALIA CORTES GRAJALES

VALOR 10%

FUNDACIÓN UNIVERSITARIA CATÓLICA DEL NORTE.

1. DATOS GENERALES

Nombre de los estudiantes

Julio Cesar Torres
Sadid Monsalve Valencia
Duración del trabajo: Plazo 1 semana.

2. INSTRUCCIONES PARA EL DILIGENCIAMIENTO

Solucione cada uno de los siguientes puntos teniendo presente:

1. ¿Qué es una prueba de software?.

“la prueba del software es un elemento critico para la garantía de

calidad del software y representa una revisión final de las
especificaciones, del diseño y de la codificación”.

No es raro que una empresa de desarrollo de software emplee entre el

30 y 40 por ciento del esfuerzo total de un proyecto en la prueba.
 
Fundamentos de la prueba del software
 
 La prueba es uno de los pasos de la Ingeniería de
Software que se puede ver como destructivo en lugar de
constructivo.

 La gente que desarrolla el software es por

naturaleza  constructiva.

 La prueba requiere que se descarten ideas preconcebidas

sobre la «corrección» del software que se acaba de
desarrollar y se supere cualquier conflicto de intereses que
aparezcan cuando se descubren errores.
 
Objetivos de la Prueba
 
 La prueba es un proceso de ejecución de un programa con la
intención de descubrir un error.
  Un buen caso de prueba es aquel que tiene una alta
probabilidad de mostrar un error no descubierto hasta entonces
 Una prueba tiene éxito si descubre un error no detectado hasta
entonces.
 
La prueba no puede asegurar  la ausencia de defectos, sólo puede
demostrar que existen defectos en el software..

https://sg.com.mx/revista/4/fundamentos-prueba-software-conceptos-
justificacion-y-alcance

https://a11337-1708606.cluster44.canvas-user-
content.com/courses/11337~3471/files/11337~1708606/course
%20files/documentos/u3_contenido1.htm

2. ¿Qué se entiende por principios de la Prueba?

Las pruebas se rigen por una serie de principios, una buena

comprensión de estos facilitará el posterior uso de los métodos en un
efectivo diseño de casos de prueba. A continuación se citan:

 A todas las pruebas se les debería de poder hacer un

seguimiento hasta los requisitos del cliente.
 Las pruebas deberían planificarse mucho antes de que
empiecen
 El principio de Pareto es aplicable a la prueba del software: “El
80 por ciento de todos los errores descubiertos durante las
pruebas surgen al hacer un seguimiento de sólo el 20 por
ciento de todos los módulos del programa”.
 Las pruebas deberían empezar por “lo pequeño” y progresar
hacia “lo grande”.
 No son posibles las pruebas exhaustivas

Para ser más efectivas las pruebas deberían ser conducidas por un
equipo independiente.

lo que podemos sacar de este principio es que, por mas que probemos un
aplicacion nunca podemos decir que el sistema se encuentra al 100% en
 su calidad de software, y esto lo decimos es porque no podemos estar
seguros de que la aplicación ya no tiene defectos.

En condiciones reales, se utilizan generalmente una prueba de una

muestra. Probar todas las combinaciones posibles de entradas y
precondiciones sólo es económicamente viable en casos triviales

Por más efectivas nos referimos a pruebas con la más alta probabilidad de
encontrar errores.

3. ¿Qué es una prueba de caja negra?

Las pruebas de caja negra, es una técnica de pruebas de software en

la cual la funcionalidad se verifica sin tomar en cuenta la estructura
interna de código, detalles de implementación o escenarios de
ejecución internos en el software.

En las pruebas de caja negra, nos enfocamos solamente en las

entradas y salidas del sistema, sin preocuparnos en tener conocimiento
de la estructura interna del programa de software. Para obtener el
detalle de cuáles deben ser esas entradas y salidas, nos basamos
únicamente en los requerimientos de software y especificaciones
funcionales.

En este artículo, te presentamos ejemplos de cómo definir pruebas de

caja negra, para esto, usaremos casos tanto de requerimientos
funcionales y como no funcionales de software.

PMO Informática presenta: Ejemplos de pruebas de caja negra.

Las técnicas de pruebas de caja negra

Tal como vimos en nuestro artículo sobre la definición de pruebas de

caja negra según el ISTQB, existen distintas técnicas para realizar
pruebas de caja negra de software, te sugerimos revisar el artículo
para obtener información general sobre que son las pruebas de caja
negra.

http://www.pmoinformatica.com/2017/02/pruebas-de-caja-negra-
ejemplos.html
4. ¿Para que se utilizan las métricas técnicas de software?

Las Métricas de Calidad proporcionan una indicación de cómo se

ajusta el software, a los requerimientos implícitos y explícitos del
cliente.

El objetivo principal de la ingeniería del software es producir un

producto de alta calidad. Para lograr este objetivo, los ingenieros del
software deben utilizar mediciones que evalúen la calidad del análisis
y los modelos de desafío, el código fuente, y los casos de prueba que
se han creado al aplicar la ingeniería del software. Para lograr esta
evaluación de la calidad en tiempo real, el ingeniero debe utilizar
medidas técnicas que evalúan la calidad con objetividad, no con
subjetividad.

El primer objetivo del equipo de proyecto es medir errores y defectos.

Las métricas que provienen de estas medidas proporcionan una
indicación de la efectividad de las actividades de control y de la
garantía de calidad.

Importancia de las métricas

Las métricas de software se utilizan para propósitos estratégicos y son

utilizadas en el proyecto para minimizar la planificación de desarrollo
haciendo los ajustes necesarios que eviten retrasos y reduzcan
problemas y riesgos potenciales, son utilizadas también para evaluar
la calidad de los productos en el momento actual y cuando sea
necesario, modificando el enfoque técnico que mejore la calidad. Para
establecer objetivos de mejora durante el proceso de desarrollo de
software, se debe comprender el estado actual del desarrollo del
software. Si no se mide, no hay una forma real de determinar si se
está mejorando y si no se está mejorando, se está perdido.

https://www.ecured.cu/Metricas_para_la_calidad_del_software
5. ¿Qué se entiende por principios de medición?

Roche sugiere un proceso de medición que puede caracterizarse

mediante cinco actividades:

 Formulación. La derivación de medidas y métricas de software

apropiadas para la representación del software que se está
construyendo.

 Recolección. Mecanismo que se usa para acumular datos

requeridos para derivar las métricas formuladas.

 Análisis. El cálculo de métricas y la aplicación de herramientas

matemáticas.

 Interpretación. Evaluación de las métricas resultantes para

comprender la calidad de la representación.

 Retroalimentación. Recomendaciones derivadas de la

interpretación de las métricas del producto, transmitidas al
equipo de software.

Las métricas de software serán útiles sólo si se caracterizan

efectivamente y si se validan de manera adecuada. Los siguientes
principios son representativos de muchos que pueden proponerse para
la caracterización y validación de métricas:

 Una métrica debe tener propiedades matemáticas deseables, es

decir, el valor de la métrica debe estar en un rango significativo
(por ejemplo, 0 a 1, donde 0 realmente significa ausencia, 1
indica el valor máximo y 0.5 representa el “punto medio”).
Además, una métrica que intente estar en una escala racional
no debe constituirse con componentes que sólo se miden en
una escala ordinal.

 Cuando una métrica representa una característica de software

que aumenta cuando ocurren rasgos positivos o que disminuye
cuando se encuentran rasgos indeseables, el valor de la métrica
debe aumentar o disminuir en la misma forma.
  Cada métrica debe validarse de manera empírica en una gran
variedad de contextos antes de publicarse o utilizarse para
tomar decisiones. Una métrica debe medir el factor de interés,
independientemente de otros factores. Debe “escalar” a
sistemas más grandes y funcionar en varios lenguajes de
programación y dominios de sistema.

https://calidaddesoftwareutp.wordpress.com/principios-de-medicion/

6. ¿cuáles son los factores de calidad de McCall?

Este modelo de calidad fue presentado en 1977 y propone una serie de

factores de calidad conocidos como factores de McCall, Richards, &
Walters (1977), la idea del modelo es la descomposición del concepto
genérico de calidad en tres capacidades importantes para un producto
software, todo desde la mirada del usuario. A su vez cada capacidad
se descompone en un conjunto de factores y finalmente se definen
criterios para evaluar el factor a través de métricas que indican en qué
medida el sistema posee una característica dada.

Según McCall, encontramos: Operación, transición y revisión, todo esto

desde la mirada del usuario. Y a su vez las capacidades se
descomponen en factores como: Corrección, Confiabilidad, Usabilidad,
Integridad o Seguridad, Eficiencia o Performance, Portabilidad,
Reusabilidad, Interoperabilidad, Facilidad Mantenimiento, Flexibilidad,
Facilidad de Prueba. Y finalmente se encuentran algunos criterios para
evaluar el factor a través de métricas que miden las características del
sistema dentro de ellas encontramos: Auto documentación, Capacidad
de expansión, Compleción de las funciones, Complejidad, Concisión,
Consistencia, Eficiencia de ejecución, Estandarización de
comunicaciones, Estandarización de datos y estructuras, Exactitud de
cálculo y de control Facilidad de auditoría, Independencia del
hardware, Independencia del software, Instrumentación, Modularidad,
Operatividad, Seguridad, Simplicidad, Tolerancia a errores,
Trazabilidad.

McCall propone algunas los factores de calidad que métricas

comúnmente utilizadas para evaluar la calidad del software.
 McCall, Presenta la relación entre algunos de los factores de calidad y
algunas métricas comúnmente utilizadas para evaluar la calidad del
software.

https://modelos-de-evaluacion-de-
rd.fandom.com/es/wiki/Modelo_de_calidad_de_McCall

7. ¿Por qué tener en cuenta la calidad del software?

Los Productos Software, sistemas y/o aplicaciones son creadas,

desarrolladas e implementadas por seres humanos y por ende en
cualquiera de sus etapas de creación se puede presentar una
equivocación, al generarse esa “Equivocación” se puede conllevar a
un defecto en el software, por ejemplo mala digitación, distracción al
codificar, mala elaboración de un documento entre otras. Si no se ha
identificado ese defecto y el software o la aplicación se ejecuta, hay un
alto riesgo de que la aplicación no haga lo que debería hacer o el
objeto para lo cual fue creada, es decir se genera un fallo o
desperfecto, lo que podría generar una catástrofe como las que se han
mencionado en este documento y muchas otras más, es importante
conocer que los fallos también se pueden presentar por situaciones del
entorno, como la radiación, descarga eléctrica, contaminación,
inundaciones, Húmeda, Fuego, etc.

Los Ingenieros de sistemas entonces deben estar en la capacidad de

conocer y aplicar las diferentes normas, procesos y procedimientos
para garantizar la calidad de los productos software, aplicando las
pruebas de calidad de software necesarias para que con ellas se
pueda ayudar a reducir los riesgos en las aplicaciones, logrando que
se identifiquen los defectos antes de que se ejecuten, así de forma
proactiva tomar decisiones que permitan hacer las actividades
necesarias para mejorar las condiciones del software y ofertar un
producto que satisfaga las necesidades del cliente.

https://www.ucc.edu.co/prensa/2015/Paginas/la-importancia-del-
proceso-de-pruebas-de-calidad-de-software-en-la-formacion-de-los-
ingenieros-de-sistemas.aspx
8. ¿Qué es la gestión de un proyecto?

La gestión de proyectos es un conjunto de metodologías para planificar

y dirigir los procesos de un proyecto. Un proyecto comprende un
cúmulo específico de operaciones diseñadas para lograr un objetivo
con un alcance, recursos, inicio y final establecidos. Los objetivos de la
gestión de proyectos son:

Gestionar el inicio y la evolución de un proyecto;

Controlar y responder ante problemas que surjan durante un proyecto;
Facilitar la finalización y aprobación del proyecto.
Los proyectos son independientes de la actividad diaria empresarial,
por lo que se requiere que se organicen una serie de reuniones para
ver cuáles son los objetivos específicos del proyecto. Para que el
proyecto tenga éxito es esencial que se realice un trabajo en equipo
eficiente. La manera en la que la gestión de proyectos dirigirá el trabajo
depende de varios factores, entre ellos: la escalabilidad (la posibilidad
de que el proyecto crezca), la importancia y la complejidad de las
tareas.

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) u objetivos
estratégicos (como duplicar el rendimiento corporativo en tres años).

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. El alcance es importante para
especificar todos los pasos del desarrollo del proyecto. Por otra parte,
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. Sin
embargo, 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
depende 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.

La norma ISO que establece unos estándares para la dirección y

gestión de proyectos es la norma ISO 21500. Esta normativa tiene
como objetivo principal conseguir dar una orientación a las
organizaciones en su gestión. En ella se describen los diferentes
conceptos y procesos dentro de una compañía para estabilizar y
sistematizar las tareas, así como la homogeneización de las
actividades. Es decir, pretende que el resultado de un proceso sea el
mismo independientemente de la persona que lo realiza. La estructura
de la norma ISO 21500 continúa con las directrices del PMBOK, uno
de los certificados del Project Management Institute (PMI) o instituto de
gestión de proyectos.

«Las operaciones mantienen las luces encendidas, la estrategia

proporciona una luz al final del túnel, pero la gestión del proyecto es el
motor del tren que hace avanzar a la organización.» – Joy Gumz,
especialista TIC que trabaja para ISAO Standards Organization y
NASA Appel.
https://www.ticportal.es/glosario-tic/gestion-proyectos
9. ¿Cuál cree usted que son los principales problemas en la gestión
de un proyecto?

 Ignorar el proceso de planificación

 Cambios en el alcance
 Superar el presupuesto
 Falta de comunicación
 Cambios en los plazos
 No empoderarse del proyecto
 Información descentralizada

 Ignorar el proceso de planificación

Si eres un buen project manager, sabes que la
planificación es una de las etapas más importantes en
cualquier proceso de gestión de proyectos. Sin
embargo, a veces los gerentes de proyectos no pasan el
tiempo suficiente en esta etapa y tratan de pasar de
inmediato a la solución del problema, en lugar de dar un
paso atrás, planificar y diseñar las estrategias más
efectivas para resolver el problema.

Una mejor planificación permite tener un mayor control

sobre el proyecto. Por lo tanto, nunca debes iniciar un
proyecto sin antes analizar el problema, echar un vistazo
a las posibles soluciones, proponer la mejor solución al
problema y planificar todas las actividades y los recursos
necesarios para resolverlo. Siempre ten en cuenta los
riesgos que podrían afectar el proyecto y propón
soluciones alternativas.

Y recuerda, los proyectos a largo plazo requieren una

planificación más detallada. A corto plazo, por otro lado,
se necesita un enfoque más práctico y rápido.

 cambios en el alcance
Es muy importante tener un alcance claro y definido antes
de comenzar a ejecutar el proyecto. Pero incluso con un
 gran proceso de planificación, el alcance puede cambiar
durante la ejecución. Los cambios en el alcance son
peligrosos porque pueden hacer que el proyecto se
desvíe y se pierdan las fechas límite.

Cuando esto suceda, primero enfócate en los objetivos y

en la necesidad real: ¿cambiaron los objetivos? ¿Fue por
la planificación o la ejecución? ¿Es realmente necesario
cambiar el alcance? Si la respuesta es sí, el patrocinador
del proyecto debe tener una reunión con todos los
involucrados para que juntos puedan encontrar la
solución más fácil y práctica. Tómate el tiempo para re
orientar el proyecto, re asignar los recursos, crear nuevas
tareas, reprogramarlas y contarles a todos lo que
sucedió. La documentación del proyecto debe
actualizarse para que todos los miembros de los equipos
trabajen bajo los mismos términos.

 Exceder el presupuesto
Planificaste el proyecto, definiste los recursos necesarios
y, por lo tanto, el presupuesto final para el proyecto.
Entonces, si hiciste una buena planificación, ¿por qué
estás excediendo el presupuesto?

Usualmente esto ocurre por 3 razones: no hubo un buen

proceso de planificación, no hubo un buen proceso de
monitoreo y control durante la etapa de ejecución, o el
proyecto se vio afectado por fuentes externas (entorno,
cambio de divisas, etc.).

Cuando tu proyecto excede el presupuesto, debes

entender qué sucedió e intentar reasignar los recursos
restantes para que pueda mantener los mismos gastos.
Recuerda, una buena práctica al planificar el proyecto es
definir un presupuesto para sorpresas ("colchón"), es
decir, tener una reserva en caso de que surjan algunas
contingencias fuera de tu control.
 Falta de comunicación
La mala comunicación lleva a conflictos no resueltos, que
pueden tener un efecto adverso en el proyecto. Un
proyecto es ejecutado por un equipo, en el cual cada
miembro es responsable de algunas tareas y fechas
límite. Si una persona no está alineada y el resto del
equipo no se entera, es seguro que el proyecto tendrá
retrasos (y algunos problemas mayores si el asunto
continúa).

Tener reuniones recurrentes, actas de estas reuniones y

comités primarios, entre otros, es una gran idea para
mantener a todos a bordo y conectados.

 Plazos de cambio
En un proyecto, las tareas dependen de otras tareas.
Algunas de ellas no se pueden iniciar si no se ha
completado una tarea anterior. Entonces, básicamente,
una fecha límite incumplida podría convertirse en 1.000
fechas límites incumplidas y, en última instancia, en una
entrega tardía del resultado final del proyecto. Es por eso
que la administración del tiempo es crucial en un
proyecto.

Cuando tengas retrasos en el proyecto, primero analiza si

la tarea vencida es parte de la ruta crítica. Si no es así,
busca otras tareas que se pueda adelantar y re asigna
recursos para que puedas mantener la misma fecha final.
Si la tarea hace parte de la ruta crítica, busca nuevos
recursos que puedan agregarse al proyecto sin tener un
gran impacto en el presupuesto.

 No empoderarse del proyecto

Una vez escuché "Cuando hay dos responsables, no hay
ningún responsable". Esto significa que cada tarea
necesita un único responsable: una persona que se
 encarga de una tarea específica y todo lo que se necesita
para su finalización.

Un gerente de proyecto necesita definir claramente las

responsabilidades y el poder de toma de decisiones de
cada miembro del equipo, y al mismo tiempo, las
expectativas de los interesados o stakeholders.

 Información descentralizada
Es crucial mantener a todos los miembros del equipo
actualizados sobre el estado del proyecto en todo
momento. No tener información accesible, disponible y
veraz conduce a errores y retrasos en el proyecto. Varias
versiones del cronograma, diferentes carpetas para
documentos, muchos correos electrónicos pueden llevar
a información descentralizada que confunde a todos en el
equipo.

Una solución para este problema es tener un software

que ayude a coordinar a los empleados en múltiples
ubicaciones y zonas horarias. Un software de Project
Management centraliza toda la información del proyecto
en un único lugar al que todos los miembros del equipo
pueden acceder en tiempo real.

10. ¿Cuáles son las fases de un proyecto?

Las etapas de un proyecto suelen completarse secuencialmente,

aunque en algunos momentos puntuales pueden coexistir.
Habitualmente se suelen distinguir cuatro principales, aunque según la
naturaleza de tu proyecto puedes añadir o eliminar fases. Lo
importante es que la estructura en etapas te ayude a la gestión.

Inicio: implica las tareas de definición del proyecto, que consisten en

acotar su alcance y realizar los procedimientos necesarios a nivel
administrativo para abrir el proyecto de forma oficial dentro de la
compañía.
Planificación: consiste en establecer las acciones que se llevarán a
cabo durante el proyecto y su calendarización en el tiempo, así como
los objetivos que se pretenden conseguir y los recursos de los que se
dispone, tanto humanos como materiales. Lo más común es realizar
una matriz en la que para cada acción que hay que realizar se
establece un responsable y una fecha en la que dicha acción debe
estar finalizada. De esta manera, durante la siguiente etapa de
ejecución se puede realizar el seguimiento del proyecto de forma
sencilla.

Ejecución y monitorización: una vez el proyecto está planificado, la

ejecución consiste en que cada miembro del equipo tomará la matriz
definida y realizará las tareas que le han sido asignadas. La misión del
gestor aquí es doble; por un lado vigilar que la planificación se cumple
con la mayor precisión posible, tanto en tiempo como en esfuerzo (para
que no aumenten los costes), por otro, coordinar al equipo y facilitar la
solución a los problemas que vayan surgiendo al equipo para
desatascar posibles cuellos de botella. Como gestor, irás realizando
modificaciones en tu planificación para reajustarla, adelantándote a los
riesgos y comunicando el estado del proyecto a tus interlocutores (jefes
y clientes).

Cierre del proyecto: esta fase es meramente administrativa pero muy

importante. Implica concluir oficialmente el proyecto, de manera que
todos los implicados entienden que las tareas planificadas se han
ejecutado y se puede realizar una valoración final del éxito del
proyecto.
 https://www.obs-edu.com/int/blog-project-management/etapas-de-un-
proyecto/conoces-cuales-son-las-etapas-de-un-proyecto

https://upcommons.upc.edu/bitstream/handle/2117/1979/3%20Anexo
%20Masarnau%20y%20Puig.pdf

El trabajo se soluciona en este mismo archivo, es en equipo y el envío lo

hace sólo un estudiante del equipo.

La actividad se puede presentar en los equipos que ya vienen conformados

para los entregables.

Instrucciones

Después de leer los contenidos correspondientes del curso y con la ayuda de

Internet, Conteste las siguientes preguntas:

Criterios de valoración:

Items de Valoración Cumple No

cumple
Desarrolla cada respuesta de la pregunta
propuesta.
Evidencia trabajo en equipo.

Entrega de manera puntual la actividad.

Entrega la actividad con buena presentación.

Registra otras fuentes de consulta.

¡Muchos éxitos!