1
Índice
SEMANA 12 – PLAN DE PRUEBAS
I. El validador……………………………….…………………………………. 5
II. El plan………………………………………...………………………………. 6
III. III. Fuentes bibliográficas …………………………………………………….. 9
Fuentes bibliográficas …………………………………………………….. 80
1.3. Estado del arte…………………………………....………………….
1.4. Estructura de un Paper …………………………………………….. 14
1.5. Entendiendo a los Papers ………..………………………………. 16
1.6. Selección y validación de los Papers ……………….………….. 17
II. Análisis de la Propuesta ………………………………………………….. 17
III. VIABILIDAD DEL PROYECTO DE TESIS ………………………………….. 19
III. Fuentes bibliográficas …………………………………………………….. 20
Fuentes de Información ………………………………………………….. 21
6.2. Diseño de Modelos de Negocio 38
6.3. Patrones de diseño de modelos de negocio 43
Fuentes de Información 52
3
SEMANA 12
PLAN DE PRUEBAS
Para poder identificar más fácilmente quién es nuestro usuario, podemos
hacernos preguntas como:
¿Para qué usuario estamos trabajando?
¿Qué hace el usuario y en qué trabaja?
¿Cómo y dónde trabaja, qué rango de edades tienen?
¿Qué tecnologías sabe usar?
¿Le será fácil aprender?
¿Para qué quiere la solución?
¿Qué problemas se le presentan actualmente para resolver su
necesidad?
No se usan técnicas para el tamaño y selección de la muestra, pero su uso
no es excluyente. Se concluye con la aceptación de la solución que cumple
con los objetivos del negocio.
El plan de pruebas debe contener todas las actividades en un cronograma
cuyo objetivo es acercar a las personas que validarán en el futuro la propuesta
de solución.
En esta semana usted va a proponer un plan de pruebas inicial en la
semana 13, podrá presentar el mismo plan de pruebas, pero ajustado, ya listo
para que sea ejecutado en la semana 14 por parte de los Stakeholders de su
proyecto.
I. EL VALIDADOR
Este rol debe ser cubierto, como sugerencia, por un experto en el tema
relacionado con el componente de innovación tecnológico de la solución e
Business y además de uno de los usuarios o Stakeholders principales
relacionados con el problema.
El experto debe tener una experiencia laboral relacionada al componente
tecnológico de la solución, sin excluir la experiencia que tiene en el sector al
que pertenece la empresa u organización en estudio. Ambas capacidades
deben ser valoradas por ustedes a la hora de seleccionar al experto. Para este
5
rol, deben identificar y preparar los criterios de validación; criterios que el
experto deberá valorar con respecto a la propuesta de solución que están
haciendo. Estos criterios de validación deben estar asociados a demostrar que
los componentes del modelo solucionan el problema, permiten que la solución
sea escalable en el tiempo, que permita entender que la solución no es
cortoplacista, que es seguro y confiable; y sobre todo, que es innovador.
Ustedes podrán elaborar con él estos criterios, para que aseguren que su
modelo de propuesta de solución cumple con la valoración del experto.
Por otro lado, los usuarios o los principales interesados en la solución
deberán contar con historias de usuario u otros artefactos que les permitan
validar que los requerimientos funcionales y no funcionales serán atendidos por
la propuesta de solución. Del mismo modo, los requerimientos no funcionales
deben ser validados. A diferencia de los funcionales que expresan la
funcionalidad que debe tener la solución para resolver el problema, los no
funcionales se encuentran en el orden de las capacidades técnicas que debe
tener la solución. Ejemplo, seguridad, tiempo de respuesta, escalabilidad, alta
disponibilidad, tolerancia a fallos, redundancia, entre otros.
II. EL PLAN
Debe estar representado en un cronograma. Todos los conceptos
aplicados en el desarrollo del cronograma en el plan de tesis aplican para el
plan de pruebas, solo que el objetivo es validar que la solución resolverá el
problema identificado. A continuación, se presentan los pasos para la
elaboración del plan (cronograma):
Definir las actividades: para definirlas, debe tener la línea base del
alcance del proyecto y a los Stakeholders identificados, para definirlas
con precisión. Hay que tener cautela con planificar al mínimo detalle,
pero si es recomendable planificar por lo menos a un nivel general de
detalle. Los hitos son eventos significativos dentro del cronograma, no
son actividades del trabajo. En este caso, los alumnos podrán definirlos,
según corresponda. Sirven para demarcar logros parciales y
evidenciar el avance del proyecto (ver semana 1, estructura de los
módulos del curso).
Secuenciar las actividades: Para esto, se toman las actividades e
hitos y se comienza a secuenciarlas según cómo se realizará el trabajo.
El resultado de esta actividad es contar con un diagrama de red, tal y
como se muestra en la figura.
Estimar los recursos de las actividades: Luego de tener las
actividades secuenciadas, se debe determinar el tipo y la cantidad de
recursos que serán necesarios. Estos pueden ser personas, equipos y
materiales. Estos recursos deben estar planificados para evitar que
falten, etc.
Estimar la duración de las actividades: Esto quiere decir que van a
estimar la cantidad de tiempo que puede tomar cada actividad. Para
tener una buena estimación, el alumno necesitará saber los recursos,
fechas calendario de los recursos y Stakeholders, y factores
ambientales de la empresa. Las estimaciones de tiempos y de
cualquier otra información recopilada durante la estimación, también
se pueden utilizar para identificar posibles riesgos, como, por ejemplo,
la continuidad de la pandemia, etc. Las siguientes son algunas
técnicas para la estimación de la duración de las actividades:
o Estimaciones puntuales
o Estimación por analogía
o Estimación paramétrica (regresión y curva)
o Heurística
o Estimación por tres valores (PERT).
Desarrollar el cronograma: Toda la información recopilada en los
7
pasos anteriores, se deben juntar y poner en un cronograma. La
diferencia entre la estimación del tiempo y el cronograma es que e
cronograma está basado en un calendario.
Controlar el cronograma: Controlar el proyecto sobre la base de
indicadores o hitos, según como mejor convenga a los alumnos.
Esta semana deben terminar la primera versión de su plan de prueba. Y
recuerden que la semana 13 deberán presentarlo ajustado, luego de las
observaciones que se den al respecto.
FUENTES DE INFORMACIÓN
A Guide to the Business Analysis Body of Nkowledge (BABOK Guide) 2.0, Version
2.0 published 2009. Second Printing.
Project Management Institute, Sixth Edition, Newtown square, Pennsylvania, PMI
Inc, 2017.
Administración exitosa de proyectos, Jack Gido, James P Clemens, 5ª Ed, México
D.F., Cengage Learning 2012.
Project management : a systems approach to planning, scheduling, and
controlling / Harold Kerzner, Ph. D. Senior Executive Director for Project
Management, the International Institute for Learning, New York, New
York, Kerzner, Harold, 11th ed., Hoboken, New Jersey, 2013.
Cloud computing : concepts, technology, & architecture / Thomas Erl, Zaigham
Mahmood and Richardo Puttini, Erl, Thomas, Mahmood, Zaigham, 2013.
Enterprise architecture at work : modelling, communication and analysis, Marc
Lankhorst, 3a ed, 2013.
The complete project management office handbook (pp. 1-139), Gerard M. Hill,
3rd ed, Boca Raton, Florida, 2014.
Análisis y diseño de sistemas, Kenneth E. Kendall 1948-, Jule E. Kendall 1952-, 8a
ed, Naucalpan de Juárez, México, 2011
Sun, Z., Zou, H., & Strang, K. (2015, October). Big data analytics as a service for
business intelligence. In Conference on e-Business, e-Services and e-
Society (pp. 200-211). Springer, Cham.
Anagnostopoulos, C. (2020, 2 septiembre). Efficient Scalable Accurate
Regression Queries in In-DBMS Analytics. CORE Reader.
[Link]
Parenteau, J., Sallam, R. L., Howson, C., Tapadinhas, J., Schlegel, K., & Oestreich,
T. W. (2016). Magic quadrant for business intelligence and analytics
platforms. Recuperado de [Link] gartner. com/doc/reprints. .
9
Consultado el 02 de setiembre del 2020 del sitio web:
[Link]
A framework for analytics governance. (s. f.). SAS.
[Link]
[Link]
11
