Plan de desarrollo del software

Actividades para el análisis de requerimientos y diseño de la arquitectura del

3.2.1
software

3.2.2 Actividades para la programación

3.2.3 Actividades para las pruebas e implementación

3.2.4 Actividades para el despliegue y mantenimiento

3.2.5 Documentación
Plan de desarrollo
del software
Fases principales

ANÁLISIS

DISEÑO

CODIFICACIÓN

PRUEBAS

MANTENIMIENTO
ANÁLISIS
Se determina y define claramente las necesidades del
cliente y se especifica los requisitos que debe cumplir el
so5ware a desarrollar.
La especificación de requisitos debe:
• Ser completa y sin omisiones
• Ser concisa y sin trivialidades
• Evitar ambigüedades. U@lizar lenguaje formal.
• Evitar detalles de diseño o implementación
• Ser entendible por el cliente
• Separar requisitos funcionales y no funcionales
• Dividir y jerarquizar el modelo
• Fijar criterios de validación
DISEÑO

Se descompone y organiza el
sistema en elementos
componentes que pueden ser
desarrollados por separado.
Las actividades habituales son
Diseño arquitectónico
las siguientes:

Diseño detallado Diseño de datos Diseño de interfaz de usuario

CODIFICACIÓN
• Se escribe el código fuente de cada componente.

PRUEBAS
• El principal objetivo de las pruebas debe ser
conseguir que el programa funcione incorrectamente y
que se descubran defectos.
MANTENIMIENTO
• Durante la explotación del sistema software es necesario
realizar cambios ocasionales.
Tipos de mantenimiento:

• Correctivo: se corrigen defectos.

• Perfectivo: se mejora la funcionalidad.
• Evolutivo: se añade funcionalidades nuevas.
• Adaptativo: se adapta a nuevos entornos.
Elementos integran el plan de
desarrollo del software
• Diseño del sistema: Cómo se
Alcance del proyecto: Qué • Requisitos del sistema:
• Objetivos del proyecto: implementarán los requisitos del
se incluirá y qué no se Características y
Resultados que se esperan sistema y cómo se integrará el
incluirá en el proyecto de funcionalidades que el
alcanzar. software con otras aplicaciones o
software. software debe tener.
sistemas.

• Plan de mantenimiento:
• Plan de implementación: Cómo se Cómo se llevará a cabo el
• Plan de pruebas: Cómo se validará que mantenimiento y
desplegará el software en producción y
el soHware cumple con los requisitos y
cómo se realizará la transición del actualización del software
está libre de errores.
antiguo sistema al nuevo. una vez que se ha
implementado.

• Presupuesto: describe los

• Cronograma: describe el
• Plan de gestión del proyecto: describe costos asociados al
calendario de actividades y
cómo se llevará a cabo la gestión del proyecto, incluyendo el
tareas necesarias para
proyecto, incluyendo la asignación de tiempo y los recursos
completar el proyecto de
tareas y el seguimiento del progreso. necesarios para completar
software.
cada tarea.
• El análisis de requerimientos es el proceso de identificar y
definir los requisitos del sistema que se deben cumplir para
poder desarrollar un software de calidad y que satisfaga las
necesidades del usuario. El análisis de requerimientos es una
etapa importante en el proceso de desarrollo de software, ya
que permite a los desarrolladores entender las necesidades y
expectativas de los usuarios y asegurar que el software cumpla
con ellas.
 Requisitos Requisitos no Requisitos de Requisitos de
funcionales: funcionales: negocio: usuario:

describen qué debe describen las describen cómo el describen cómo los
hacer el so1ware y características y software debe apoyar a usuarios interactúan con
cómo debe hacerlo. atributos del software la organización en sus el software y qué
que no tienen una operaciones y objetivos esperan de él.
función específica, pero de negocio.
son importantes para el
correcto
funcionamiento del
sistema. Algunos
ejemplos de requisitos
no funcionales incluyen
la confiabilidad, la
escalabilidad y la
usabilidad.
• El análisis de requerimientos es un proceso iterativo que
implica reunir y validar los requisitos del sistema con el usuario
y otros interesados. Se utilizan diferentes técnicas para
recopilar y analizar los requisitos, como entrevistas, grupos
focales, análisis de documentación y análisis de casos de uso.
Características de un buen análisis de
requerimientos
Completo: Preciso: Verificables: Modificables:

• debe incluir • los requisitos • deben ser • deben ser

todos los deben ser fáciles de flexibles y
requisitos claros y probar y adaptables
relevantes para específicos verificar para para permiBr
el proyecto de para evitar asegurar que cambios y
software, tanto confusiones y se cumplen. actualizaciones
funcionales errores. en el futuro.
como no
funcionales.
Características de un buen análisis de
requerimientos

Orientados al
Coherentes: Trackeables: Consistentes: Priorizados:
usuario:
• deben estar bien • deben ser • deben estar • deben ser • deben estar
integrados y no fáciles de basados en las consistentes con ordenados en
contradictorios rastrear y necesidades y los objetivos del función de su
entre sí. monitorear para expectativas de proyecto y con la importancia y
hacer los usuarios para estrategia de la urgencia para
seguimiento al asegurar que el organización. permitir una
progreso y el software cumpla implementación
cumplimiento de con ellas. efectiva y
los requisitos. eficiente.
¿Cuáles son las técnicas para analizar requerimientos
de software y qué herramientas utiliza?

Entrevistas: consisten en conversar con los usuarios, los interesados y otros stakeholders para
recopilar información sobre sus necesidades y expectativas.

Grupos focales: consisten en reunir a un grupo de personas para discutir y analizar los requisitos
del sistema.

Análisis de documentación: consiste en examinar documentos relevantes, como manuales de

usuario o especificaciones técnicas, para identificar los requisitos del sistema.

Análisis de casos de uso: consiste en describir cómo los usuarios interactúan con el sistema y
qué funcionalidades necesitan para llevar a cabo sus tareas.

Prototipado: consiste en crear una versión básica del sistema para que los usuarios puedan
probarlo y proporcionar retroalimentación.
Para llevar a
cabo el análisis
Hojas de cálculo: se pueden utilizar para recopilar y
organizar los requisitos de manera sencilla.

de Herramientas de gestión de requisitos: existen herramientas

requerimientos, especializadas que facilitan el análisis y seguimiento de los

requisitos, como Jama Software o ReQtest.

se pueden Herramientas de modelado de requisitos: permiten

visualizar y representar los requisitos de manera gráfica,
utilizar como Balsamiq o Visio.

herramientas Herramientas de prototipado: permiten crear prototipos de

alta fidelidad para probar y validar los requisitos del sistema,

como: como InVision o Figma.

 Requerimientos
Requerimientos Funcionales
• son declaraciones de los servicios
que prestará el sistema, en la forma
en que reaccionará a determinados
insumos. Define lo que el sistema
debe hacer para satisfacer las
necesidades o expectativas del
usuario. Pueden ser interacciones
con otros sistemas, respuestas
automáticas, procesos predefinidos.
Requisitos no funcionales
• Se trata de requisitos que no se
refieren directamente a las
funciones específicas suministradas
por el sistema (características de
usuario), sino a las propiedades del
sistema: rendimiento, seguridad,
disponibilidad.
Los requerimientos Funcionales a su
vez se clasifican de la siguiente manera:
REQUERIMIENTOS DE REQUERIMIENTOS REQUERIMIENTOS REQUERIMIENTOS DE
PRODUCTO: ORGANIZACIONALES: EXTERNOS: DOMINIO:
• Estos requerimientos • Estos requerimientos se • Estos requerimientos se • Son requerimientos que
especifican el derivan de políXcas y derivan de políticas y provienen del dominio
comportamiento del procedimientos procedimientos de aplicación del
producto. Dentro de existentes en la existentes en la sistema y que reflejan
estos encontramos lo organización del cliente organización del cliente las características y
referente a y en la del y en la del restricciones de ese
Rendimiento del desarrollador. Un desarrollador. En esta dominio. Pueden ser
sistema (memoria, ejemplo de este Xpo de clasificación de funcionales o no
rapidez, etc.) Y requerimientos podría requerimientos funcionales.
Fiabilidad (tasa de fallos ser el Xempo solicitado encontramos los que
aceptable). de entrega a la tienen que ver con
empresa. Requerimientos
Legislativos,
Requerimientos Éticos,
etc.
1. El requisito funcional lo especifica el usuario, mientras que el requisito no
funcional lo especifica personal técnico como Arquitecto, líderes técnicos y
desarrolladores de software.
2. El requisito funcional es también la actividad que debe realizar el sistema;
por otro lado, los no funcionales dependen de la criticidad de la aplicación.
Por ejemplo, si su aplicación no es crítica y puede vivir con tiempo de
inactividad, es posible que no necesite desarrollar un código complejo de
recuperación ante desastres y conmutación por error, lo que reduce el
tiempo total de desarrollo de su aplicación.
3. Los requisitos funcionales definen la funcionalidad de un software, es
decir, qué pueden hacer, mientras que los requisitos no funcionales definen,
otras cosas que no son requeridas por el usuario, pero requeridas por un
proveedor de servicios o el software en sí, como el registro, es un requisito
no funcional para respaldar una aplicación, no utilizada directamente por el
usuario, pero esencial para solucionar cualquier problema en un entorno de
producción.
4. Los requisitos no funcionales también pueden describir aspectos del
sistema que no se relacionan con su ejecución, sino más bien con su
evolución en el tiempo (como mantenibilidad, extensibilidad,
documentación, etc.).
Regla de negocio

Una empresa funciona mediante procesos que, a su vez, están

conformados por actividades relacionadas entre sí. Las funciones de
las áreas de compras, inventario, logística, finanzas, ventas y
marketing, por ejemplo, conforman un proceso para suministrar un
producto al cliente.
¿Por qué tener reglas de negocio?

Además de garantizar el funcionamiento de los procesos, estas reglas:

• Estandarizan y ayudan a que los procesos fluyan más rápido, de forma
automatizada, sin necesidad de interferencia manual de los empleados. Así, se
gana enormemente en agilidad, calidad y eficiencia, a partir de la eliminación de
etapas repetitivas o prescindibles y de pérdidas de tiempo y recursos, reduciendo
también los costes.
• Ayudan a controlar los procesos, porque si algo va en contra de las reglas, el fallo
puede detectarse y corregirse rápidamente.
• Ayudan a la toma de decisiones y al cumplimiento de las estrategias
preestablecidas.
 Tipos de reglas de negocio

1. Definiciones
Estos son los términos precisos, las frases y el lenguaje utilizado para expresar la
regla de negocios en particular. Puedes incluirlos en el manual de trabajo.
2. Hechos
Estos son los puntos de partida para implementar un conjunto de reglas de
negocio. Puedes clasificar los hechos según sus relaciones, cualidades y
estructuras.
 Tipos de reglas de negocio

3. Restricciones
Puedes usar reglas para establecer límites en ciertos aspectos de un negocio.
Por ejemplo, una empresa puede requerir que los clientes tengan al menos
$10,000 en su cuenta para solicitar una línea de crédito.
4. Derivaciones
Las reglas de negocio también pueden explicar cómo obtener conocimiento de
una fuente en particular. Por ejemplo, una empresa puede tener una regla sobre
cómo los miembros de un equipo pueden recopilar comentarios de los clientes y
convertirlos en informes.
 1. Establece los procesos de tu empresa
Para aplicar las reglas de negocio se necesita un excelente
análisis de los procesos que la empresa tenga.
2. Define las reglas de negocio
Una buena práctica es definirlas desde la planeación
¿Cómo estratégica para aumentar la posibilidad de alcanzar los
objetivos.
aplicar las 3. Alinea las reglas de negocio con los objetivos

reglas de Las reglas de negocio deben estar alineadas con los

objetivos y las políticas de la empresa, con el fin de
negocio? fortalecer las estrategias del negocio.
4. Mejora con agilismo las reglas de negocio
El uso de la tecnología ha cambiado nuestra manera de
trabajar y, cada vez más, las empresas adoptan diferentes
soluciones tecnológicas dentro de sus reglas de negocio.
 La arquitectura del software es una fase
de planificación crítica a la hora de
comenzar cualquier proyecto para
cualquier pieza de software, ya que nos
¿Qué es la proporciona una hoja de ruta clara sobre
el camino a seguir en el desarrollo.
arquitectura
de Es una estructura general de un sistema de
software que incluye los componentes que
so1ware? los componen, sus relaciones y cómo se
distribuyen entre ellos. Proporciona un marco
de referencia para la planificación, diseño y
desarrollo de un sistema de software.
 • Proporcionar una visión general del sistema.
Los objetivos • Identificar los requisitos y restricciones que
deben tenerse en cuenta al diseñar
de esta elsistema
arquitectura • Establecer una estructura de alto nivel que
sea fácil de entender y mantener
son: • Hacer que el sistema sea más escalable,
mantenible y fácil de modificar.
Diseño de software

Diseño de software se refiere al proceso de creación de una especificación de

artefacto de software que ayudará a los desarrolladores a implementar el
software. Consiste en diseñar módulos/componentes individuales.

Es responsable del esqueleto y la infraestructura de alto nivel de un software,

el diseño de software es responsable del diseño de nivel de código, como lo
que está haciendo cada módulo, el alcance de las clases y los propósitos de
las funciones, etc.

En una palabra, el nivel de diseño de software es la implementación.

Arquitectura de software

Arquitectura de software es el proceso de convertir características de software como

flexibilidad, escalabilidad, viabilidad, reutilización y seguridad en una solución
estructurada que cumple con las expectativas técnicas y comerciales.
Es un plan que restringe el diseño del software para evitar errores conocidos y logra
la estrategia comercial y tecnológica de una organización.
En una palabra, el nivel de la arquitectura de software es la estructura.
En general la arquitectura de software es la estructura general de un sistema de
software, mientras que el diseño de software es el proceso de crear una solución
técnica a un problema de negocio a través de la definición de componentes,
interfaces y relaciones entre ellos.
¿Cuáles son los patrones de
arquitectura de so3ware?
1. Patrón de arquitectura en capas

• La arquitectura en capas se trata de un modelo tradicional para desarrollar software que sigue un enfoque
por niveles. Bajo este modelo, cada uno de esos niveles presta servicios al siguiente nivel superior. Se trata
de un patrón ampliamente utilizado por la industria porque es fácil de desarrollar y, en general, muchas
aplicaciones comerciales almacenan su información en tablas. Por ejemplo, uno de los modelos más
comunes que utilizan este tipo de patrón es el MVC (Model-View-Controller) o, en español, Modelo-Vista-
Controlador, que sigue un enfoque de tres capas. La primera capa se encuentra encima de las bases de
datos y contiene la capa de modelo, que guarda información sobre los tipos de datos de la base de
información. En la segunda capa se encuentra el nivel visual, a menudo formado por CSS, HTML y
JavaScript. Por último, en la tercera capa tenemos el controlador que, como indica su nombre, maneja
como se transforman los datos que se mueven entre la vista y el modelo. Se puede considerar utilizar la
arquitectura de capas en los siguientes escenarios: En aplicaciones empresariales que necesitan adoptar
procesos y estructuras de tecnología de la información tradicionales; Cuando el objetivo es diseñar una
aplicación o sitio web rápidamente y con la cantidad mínima de desarrolladores; En sitios web de
comercio electrónico
2. Patrón de arquitectura por eventos

El patrón anterior funciona traspasando los datos de una capa a otra en una secuencia
predeterminada. En este caso, los programas que utilizan este patrón pasan la mayor parte
del tiempo “esperando a que ocurra algo”, es decir, a que suceda un evento. Un evento
puede ser el clic del ratón, presionar una tecla o el desplazamiento de una barra. El patrón
arquitectónico de eventos se puede utilizar en los siguientes casos: Para la creación de
aplicaciones complejas que tienen sistemas de datos asíncronos; Para aplicaciones
escalables que requieran un flujo de datos sin interrupciones; Interfaces de usuario de todo
tipo.
3. Patrón de arquitectura basada en el espacio

• Otro de los patrones de arquitectura de software más utilizados es el arquetipo basado en

el espacio que está diseñado para resolver problemas de escalabilidad y concurrencia.
Imagina un sitio web que tiene demasiados usuarios simultáneos, haciendo que la base
de datos alcance su capacidad máxima y colapse. 8 Es aquí donde entra en juego el
concepto conocido como “espacio de tuplas” en el que se basa este patrón de
arquitectura, el cual está diseñado para evitar un colapso funcional al dividir el
almacenamiento y el procesamiento en varios servidores.Este tipo de patrón es más útil
en los siguientes escenarios: Aplicaciones o sitios web que albergan una gran cantidad de
usuarios que acceden a la base de datos de forma simultánea; E-commerce con un gran
volumen de usuarios; Útiles para redes sociales.
4. Patrón de arquitectura de microkernel

También conocido como arquitectura de plug-in, este patrón permite crear aplicaciones
extensibles a las que se puede agregar funcionalidades y elementos nuevos a través de
módulos o complementos. Este arqueQpo Qene dos componentes principales: el sistema
central (core) y los módulos (plugins). El sistema central conQene los elementos
fundamentales para que la aplicación funcione como se Qene pensado, mientras que los
plugins añaden caracterísQcas adicionales que se instalan al core. Entendiendo esto, solo
puede haber un sistema central al que se le pueden agregar muchos plugins. El patrón de
microkernel es especialmente úQl para: Aplicaciones y si4os web empresariales, ya que
proporciona escalabilidad, portabilidad y extensibilidad; Aplicaciones conectadas o que
requieren una relación entre funciones de bajo nivel y nivel superior.
5. Patrón de arquitectura de microservicios

La arquitectura de microservicios cambia la idea de un programa grande e incontrolable, por

una gran cantidad de pequeños programas diferentes que funcionan libremente. Por
ejemplo, cada una de las interfaces de Netflix son servicios separados, por ejemplo: tu lista
de favoritos, las calificaciones de las películas, los sitios individuales de cada película o
serie… Todos son docenas de programas que funcionan de forma separada pero que se
presentan al usuario como un todo. Los arquetipos de microservicios son atractivos para:
aplicaciones y sitios web con sistemas de datos gigantescos de rápido crecimiento; equipos
de expertos de desarrollo que se encuentran dispersos, a menudo internacionalmente;sitios
web con componentes pequeños; equipos de desarrolladores que quieran cambiar una
aplicación o web monolítica a una más sostenible en el tiempo.
 ¿Cuántas capas deben tener las aplicaciones?

1) Capa de presentación: esta capa es

2) Capa de aplicación: esta capa es la
la interfaz del usuario y se encarga de
lógica del sistema y se encarga de
recibir las entradas del usuario y
realizar tareas esenciales del sistema.
mostrar la salida del sistema.

4) Capa de infraestructura: esta capa

proporciona los servicios básicos
3) Capa de datos: esta capa se
necesarios para que el resto del
encarga del almacenamiento y
sistema funcione como, por ejemplo:
acceso a los datos del sistema.
la gestión de la conectividad a la red
y el acceso a los recursos del sistema.
 Ventajas
• Capacidad de testeo. Al tener cada capa
por separado la implementación del
testing es muy elevada respecto a otros
patrones, ya que es posible realizar tests
sobre cada capa de manera separada.
• Facilidad de desarrollo. Debido a la alta
distribución es mucho más sencillo
coordina un equipo para su desarrollo, ya
que cada miembro o equipo tiene claro el
objetivo de cada capa y sólo es necesario
crear una interfaz clara de comunicación
entre ellas
Desventajas
• Rendimiento. Debido a que cada
funcionalidad está en una capa diferente
normalmente este patrón sufre de menor
rendimiento que otros debido a que
cualquier petición debe de atravesar de
forma individual cada capa de diseño.
• Escalabilidad. Debido a que cada capa
depende de la anterior y de la interfaz
entre ellas, modificar un software que
utilice este patrón puede ser tedioso y
costoso ya que para modificar cualquiera
de las capas es necesario hacer cambios en
todas las anteriores, esto puede
solucionarse subdividiendo las capas en
módulos, pero de cualquier manera
implica mayor esfuerzo respecto a otros
patrones.
¿Cómo debe ser el escalado: horizontal
o vertical?
La escala horizontal implica aumentar el número de máquinas
en su reserva de recursos para ejecutar el sistema.

El escalado vertical implica aumentar el rendimiento de una

sola máquina (por ejemplo, más CPU, RAM). Este tipo de
escalado es más sencillo que la horizontal, pero puede ser más
costoso y ese puede tener un límite.
En el mundo de las bases de datos, el escalado horizontal a
menudo se basa en la partición de los datos, es decir, cada nodo
contiene solo una parte de los datos, en el escalado vertical, los
datos residen en un solo nodo y el escalado se realiza a través
de múltiples núcleos, es decir, distribuyendo la carga. Entre los
recursos de CPU y RAM de esa máquina.
Por lo tanto, el escalado horizontal es más adecuado para
sistemas que tienen un alto grado de paralelismo y pueden
distribuir el trabajo entre máquinas adicionales de manera
eficiente, mientras que el escalado vertical es más adecuado
para sistemas que tienen un alto grado de dependencia de una
sola máquina y que pueden mejorar su rendimiento mediante
laadición de recursos a la máquina.
¿Qué es y cuándo se debe usar la
arquitectura monolítica o de
microservicios?
• Las arquitecturas monolíAcas están diseñadas para hacer posible que
diferentes Apos de empresas desarrollen sus acAvidades comerciales
coAdianas con todos los componentes necesarios para ello en una
sola aplicación y de manera que sea lógica en cada caso.

Este Apo de arquitectura se caracteriza por:

• Los programas son fáciles de desarrollar.
• El despliegue y la ejecución del soFware son muy sencillos.
• El costo de desarrollo es bajo en comparación con otras arquitecturas.
Los problemas de este tipo de arquitectura:
• Necesitan entender todo el código de la aplicación
• Con el tiempo, los componentes monolíticos se acoplan y enredan
estrechamente.
Arquitectura de microservicios
Es un enfoque para la construcción de sistemas de
software basado en la división del sistema en
pequeños servicios independientes que se
comunican entre sí a través de una interfaz de
programación de aplicaciones (API). Cada servicio
se centra en una tarea específica y se puede
desarrollar, probar, implementar y escalar de
manera independiente.
• Se debe de usar cuando se desea un alto grado
de flexibilidad y escalabilidad en el sistema, esto
se hace con el fin de que sea más fácil de
agregar nuevas funcionalidades y modificar las
existentes sin tener que rehacer todo el sistema.
Los problemas de este tipo de
arquitectura:
• Puede ser más difícil integrar y
probar el sistema completo.
• Es más complicado gestionar y
monitorear el rendimiento de un
gran número de servicios
independientes.
¿Cuándo usar una base de datos NoSQL o SQL?

Las bases de datos SQL son indicadas cuando la cantidad de datos no son extremadamente
grandes, mientras que las NoSQL son ideales para manejar grandes volúmenes de datos.

Las bases de datos NoSQL son escalables por lo que se pueden aumentar su capacidad fácilmente,
sin embargo, las SQL pueden ser escalables, pero con un costo económico más elevado. Las bases
de datos NoSQL utilizan un escalado horizontal (aumentar el número de servidores) mientras que
las SQL utilizan un escalado vertical (aumentar los recursos de un servidor).
¿Cuándo usar una base de datos
NoSQL o SQL?

Elegir el tipo de base de datos a utilizar en un proyecto es

importante ya que influye en el rendimiento y en desarrollo del
mismo. Decantarse por una base de datos relacional o no
relacional puede hacer que un proyecto se encuentre con
problemas que impidan su correcta ejecución, añadan mucho
esfuerzo o incluso aumente los costos previstos.
Estructura de Descomposición del Trabajo
(EDT/WBS)
Definir las actividades consiste en identificar las acciones que deben ser
llevadas a cabo para conseguir los entregables del proyecto. Después de
crear la EDT, obtenemos el nivel más bajo de esta descomposición, el
cual denominamos Paquetes de trabajo. La descomposición de éstos, en
componentes más pequeños nos proporciona las Actividades necesarias
para ejecutar los paquetes de trabajo.
Secuenciar las actividades del proyecto, consiste en determinar las
dependencias entre actividades, es decir, qué relación de ejecución
existe entre ella, en qué secuencia se ejecutan. Cada una de las
actividades o hitos del cronograma tiene al menos una actividad
sucesora o predecesora, a excepción de la primera y la última.
Es habitual establecer como primera actividad un hito de comienzo y
como última actividad un hito de finalización. De esta manera, todas las
actividades de nuestro cronograma quedarán relacionadas entre sí.
• La Estructura de Descomposición del Trabajo (EDT), también conocida
como Work Breakdown Structure (WBS) en inglés, es una herramienta
fundamental en la gestión de proyectos que descompone el alcance
del trabajo en elementos más pequeños y manejables. Aquí te
muestro cómo se estructura:

Nivel 1 - Fase del Proyecto:
1.Nivel 1 - Fase del Proyecto:
Esta es la fase más alta de la
EDT y representa las
grandes etapas o fases del
proyecto, que suelen estar
alineadas con el ciclo de
vida del proyecto. Por
ejemplo:
1.Inicio
2.Planificación
3.Ejecución
4.Seguimiento y Control
5.Cierre
Nivel 2 - Entregables
Principales:
• Cada fase del proyecto se
desglosa en entregables
principales o productos que
deben ser producidos o
completados como parte de
esa fase. Estos entregables
son claramente
idenVficables y
mensurables. Por ejemplo:
• Plan de Proyecto
• Diseño del Sistema
• Desarrollo de SoYware
• Pruebas y Validación
• Documentación
Nivel 3 - Tareas y
Actividades:
• Cada entregable principal se
descompone aún más en
tareas y actividades más
específicas y manejables.
Estas representan las
actividades concretas que
deben llevarse a cabo para
completar el entregable. Por
ejemplo:
• Reuniones de planificación
• Investigación de requisitos
• Diseño de interfaz de
usuario
• Codificación de funciones
• Pruebas unitarias
• Documentación técnica

Nivel 4 y Subniveles Posteriores:
• Dependiendo de la complejidad del
proyecto, la EDT puede continuar
descomponiendo las actividades en
niveles adicionales, ofreciendo un
detalle aún más granular del trabajo
necesario para completar el proyecto.
Estos niveles inferiores pueden ser
subactividades, subtareas o incluso
elementos de trabajo individuales.
La EDT proporciona una estructura
jerárquica que ayuda a los gerentes de
proyecto y equipos a comprender y
gestionar el alcance del trabajo de manera
efectiva. Cada elemento de la EDT debe ser
claramente definido, tener una duración
estimada y estar asociado con los recursos y
responsabilidades necesarios. Esto facilita la
asignación de recursos, la programación y el
seguimiento del progreso del proyecto.
 1.Plan de Gestión del Cronograma: El cual
determina el nivel de detalle que es necesario
para gestionar el trabajo del Proyecto.
2.Línea base del Alcance: Entregables, restricciones
y supuestos del proyecto. La Estructura de
Descomposición del Trabajo (EDT/WBS) y el
diccionario de la EDT/WBS es la entrada principal
Entradas de la definición de las actividades del
Cronograma.
3.Activos de los procesos de la Organización:
Políticas, procedimientos, alineamientos y
procedimientos. Lecciones aprendidas.
4.Factores Ambientales: Sistema de información de
la gestión de proyectos (PMIS).
Herramientas y Técnicas

Descomposición (EDT/WBS): Consiste en subdividir los paquetes de trabajo en componentes

más pequeños y fáciles de manejar. Estos componentes son las actividades del proyecto. Por lo
que, este proceso requiere de la participación de los miembros del equipo.

Planificación gradual: Elaboración gradual. El trabajo que debe desarrollarse a corto plazo se
planifica en detalle, y el trabajo más a largo plazo se planifica a un nivel superior de la EDT.

Juicio de expertos: Participación en el proceso de miembros del equipo u otros expertos con
experiencia y habilidad en el desarrollo de cronogramas del Proyecto.
Salidas

Lista de actividades: Lista

exhaustiva que abarca
todas las actividades del
cronograma necesarias
Atributos de la ac@vidad:
para el proyecto. Así
Amplían la descripción de
como, el identificador de
la ac@vidad. Por ejemplo, Listado de hitos: Punto de
la actividad y una
código EDT, Nombre, verificación o evento
descripción del alcance
ac@vidades predecesoras importante dentro del
del trabajo para cada
y sucesoras, restricciones, Proyecto.
actividad, con el nivel de
relaciones lógicas,
detalle suficiente para que
responsables, etc.
los miembros del equipo
del proyecto comprendan
el trabajo que deben
realizar.
 • La estructura de desglose de trabajo (EDT)
o Work Breakdown Structure (WBS), es una
herramienta que se utiliza para describir
el alcance de un proyecto según sus
Estructura entregables. Los cuales dividiremos en
componentes lo suficientemente
de desglose pequeños y manejables que nos permita
de trabajo planificar de manera fácil el proyecto.
Estos componentes del último nivel de
(EDT) descomposición se denominan Paquetes
de Trabajo. Los cuales podrán
programarse, supervisarse, controlarse,
estimar sus costes y asignar un único
responsable de su ejecución.
 Se trata de un elemento organizativo jerarquizado que
Estructura de representa el proyecto al completo. Así mismo, se utiliza
desglose de como base para realizar la planificación del proyecto.
Y sirve para determinar quién es el responsable de cada
trabajo (EDT) uno de los trabajos necesarios para alcanzar los objetivos.
De manera que cada tarea o trabajo que se deba llevar a
cabo, tiene que quedar representado en la EDT/WBS.
 La EDT /WBS se elabora durante la fase
de planificación del proyecto.
Inmediatamente después de la definición
del alcance del mismo, antes que el
cronograma, sin intentar identificar la
secuencia de las actividades. Ya que la
EDT /WBS EDT/WBS es un instrumento para facilitar
la estimación de los recursos y el cálculo
del tiempo y el coste. Hasta que no se
hayan definido todas las actividades o
tareas a ejecutar no será posible
planificarlas.
• Idealmente, su realización, será llevada a cabo por el equipo que
lleve a cabo el desarrollo del proyecto. Si es preciso, en
colaboración con el área funcional de planificación y control. Este
equipo deberá buscar un equilibrio entre los niveles de
planificación. Ya que por un lado, una descomposición excesiva
puede originar un esfuerzo de gestión no productivo, un uso
ineficiente de recursos y una menor eficiencia en la realización del
trabajo. Y por otro lado, a medida que descomponemos el trabajo
con más detalle, se mejoran las capacidades de planificación,
dirigir y controlar el trabajo.
La descomposición de todo el trabajo del proyecto
generalmente implica las siguientes actividades:

• Identificar los entregables y el trabajo relacionado. Exige analizar el enunciado del alcance
del proyecto detallado y este análisis a su vez. Además, exige un juicio experto para
identificar todo el trabajo, incluidos los productos entregables exigidos por contrato.
• Estructurar y organizar la EDT/WBS. Es una técnica analítica que puede realizarse mediante
el uso de una plantilla de EDT/WBS. La estructura resultante puede adoptar varias formas
de organización, tales como:
• Principales productos entregables y subproyectos como el primer nivel de
descomposición.
• Fases del ciclo de vida del proyecto como el primer nivel de descomposición,
insertando los productos entregables del proyecto en el segundo nivel.
• Usar diferentes enfoques en cada rama de la EDT/WBS, por ejemplo en cada
subproyecto.
La descomposición de todo el trabajo del proyecto
generalmente implica las siguientes actividades:

• Descomponer los niveles superiores de la EDT/WBS. En componentes

detallados de nivel inferior. Exige subdividir el trabajo correspondiente
en sus componentes fundamentales en función de cómo se ejecutará y
controlará realmente el trabajo del proyecto. Cada componente debe
definirse y asignarse clara y completamente a una unidad ejecutante
específica de la organización que asuma la responsabilidad de la
conclusión del componente de la EDT/WBS.
• Asignar cuentas de control. De forma paralela a la creación del desglose
de tareas, se realiza el desglose de costes del proyecto. Asignando,
según la definición de paquete de trabajo, una cuenta de control
asociada a cada elemento del nivel de mayor desglose de la EDT/WBS,
la cual recoge el coste de este. Proporciona una jerarquía de cuentas de
control idéntica a la de la EDT/WBS.
• Desarrollar y asignar códigos de identificación a los componentes de la
EDT/WBS. Un código es un método abreviado, preciso e inequívoco, para
transmitir información acerca de un artículo. Debe servir por tanto como
identificador, y describir el artículo al que está referido, de la manera
más sencilla posible.
• Verificar que el grado de descomposición del trabajo es necesario y
suficiente. Exige determinar que los componentes del nivel inferior de la
EDT/WBS son necesarios y suficientes para completar los productos.
• El diccionario de la
EDT/WBS es un
documento generado
durante este proceso,
cuya función es
respaldar la EDT/WBS.
El diccionario
proporciona
una descripción más
detallada de los
componentes de la
EDT/WBS, incluyendo
los paquetes de
trabajo y las cuentas
de control.
Línea base del Alcance.
• Cuando el Enunciado del Alcance del
Proyecto, la Estructura de
Descomposición del Trabajo (EDT/WBS)
y el Diccionario de la EDT/WBS quedan
aprobados, constituyen la Línea Base del
Alcance del Proyecto. Se trata de la
referencia de alcance con la que hay
que comparar el alcance conseguido, a
la hora de verificar el cumplimiento del
trabajo realizado y controlar su grado de
rendimiento.
Actividades para las
pruebas e
implementación
Plan de pruebas
obtenga la siguiente
información del
proyecto:
• ObjeAvos de
negocio que Aene
que cumplir el
soFware
• Calendario del
proyecto
• Metodología de
desarrollo
 1. OBJETIVOS DE NEGOCIO QUE TIENE QUE
CUMPLIR EL SOFTWARE
• Tener en claro los objetivos de negocios nos
permite crear un plan organizado que aporte
valor al proyecto y a los equipos y que esté
orientado al cumplimiento de resultados.
Cada prueba que se realice tiene que estar
alineada a uno o más objetivos de negocio.
CALENDARIO DEL PROYECTO
• Conocer las fechas del proyecto es
importante para planificar cuándo podrás
realizar los diferentes tipos de pruebas. Por
ejemplo, al inicio del proyecto es importante
enfocar el esfuerzo de pruebas en los
requerimientos, validar que los mismos sean
claros, entendibles y que se puedan diseñar
pruebas para comprobar su cumplimiento. En
las siguientes fases, el foco deberá ir
cambiando hacia las pruebas funcionales y
pruebas de UX mientras se comienzan a
planificar las pruebas no funcionales, como
son las de rendimiento. Para esto es
importante coordinar con desarrollo el
momento en que los componentes críticos de
la arquitectura del sistema estén
implementados para medir lo antes posible
su respuesta frente a carga.
 Metodología de desarrollo

• Conocer la metodología que utilizará el equipo de desarrollo es

importante para acoplar las instancias de pruebas a los hitos del
proyecto de desarrollo. En proyectos con metodologías ágiles el
foco principal estará en desarrollar pruebas que validen las historias
de usuario aprobadas para el sprint, sin embargo, también hay que
tener en cuenta que pueden considerarse otro tipo de pruebas a
realizar que aporten valor, como por ejemplo cuándo aplicar
pruebas de rendimiento para validar que la arquitectura del sistema
responde correctamente o pruebas de seguridad para validar que
no se introducen vulnerabilidades tanto a nivel de la aplicación
como en la infraestructura que la soporta.
Elaboración del plan de pruebas
• 1. Planificación orientada a los objetivos del negocio

Definir el alcance
• En esta fase, es importante
diseñar una planificación
adaptada a las necesidades
del proyecto, sin perder de
vista los objetivos del
negocio. Debes revisar que
no hayas dejado objetivos
fuera del alcance, todos
deben estar cubiertos.
Determinar tipos y niveles de
Determinar la estrategia
pruebas
• Cada plan de pruebas debe • Para validar cada objetivo del
definir qué tipos de pruebas negocio podremos utilizar
implementará para cumplir diferentes tipos de pruebas:
con el alcance establecido.
Los estándares y
metodologías son
establecidos a nivel de la
organización y para cada plan
debe reflejarse cuales serán
utilizados para llevar a cabo
las pruebas de acuerdo con
las necesidades de cada
proyecto.
Tipos y niveles de pruebas
funcionales
Teniendo en cuenta la metodología de desarrollo
y las iteraciones o fases diseñadas deberás
planificar las pruebas a realizar en cada iteración.
En metodologías ágiles, esta planificación se irá
ajustando al inicio de cada sprint, sin embargo,
es bueno dejar ya establecido de forma macro
los recursos que serán necesarios para
implementar las pruebas, tanto en términos de
personas como equipos y dispositivos.
Regresión
A medida que avance el proyecto, las tareas de
pruebas aumentan su carga, por eso deberás
planificar cómo ir cubriendo las necesidades de
pruebas de regresión sin que esto signifique
aumentar los recursos. Dos técnicas principales
para lograr esto, son la priorización en base a los
objetivos del negocio y el camino crítico de la
aplicación y la AUTOMATIZACIÓN de pruebas.
Tipos y niveles de pruebas

Rendimiento y seguridad
En base a los objetivos del negocio, deberás definir y planificar si se realizarán este tipo de pruebas.
Si la aplicación estará expuesta en la nube, deberás planificar pruebas de rendimiento que permitan
validar que la arquitectura responde de forma adecuada a procesos de alta demanda.
Si la información gestionada por la aplicación es confidencial o su abuso puede tener consecuencias
graves, deberás incluir en tu planificación pruebas de seguridad y validar que no se exponen
vulnerabilidades. Esta definición es recomendable que sea tomada a nivel del proyecto, tanto para
adoptar prácticas seguras de desarrollo como para realizar pruebas de detección de vulnerabilidades
de forma continua.
 • Usualmente los sistemas no viven en solitario, sino que interactúan con otros sistemas

Integración existentes tanto internos como externos. Planifica pruebas de integración de forma
adecuada a lo largo del proyecto para validar cuanto antes las interfaces con otros
sistemas.

Extremo a • Validar que los flujos críticos del sistema funcionan correctamente, simulando el uso
de la aplicación más utilizada por los usuarios es una estrategia que asegura
tranquilidad antes de un despliegue. Incluye este tipo de prueba en cada fase del

extremo proyecto, aumentando el alcance de los flujos. Estas pruebas son excelentes
candidatas para ser automatizadas, lo que asegurará mayor capacidad de ejecución.
Identificar herramientas
Cada proyecto debe definir con cuáles herramientas apoyará: la gestión del proyecto, la
definición de las pruebas, el reporte de anomalías detectadas y su seguimiento y la
automatización de pruebas. La identificación de estas herramientas puede ir desde lo más
básico como definir un lugar compartido para almacenar los documentos y los formatos en que
se registrará el plan, los casos y los resultados, hasta la selección de plataformas como MS
Azure DevOps o JIRA para la gestión del proyecto.

En los casos de herramientas de automatización es importante seleccionar aquellas que están

pensadas para los equipos de pruebas y que no sean herramientas exclusivamente para
desarrolladores. En todos los casos, es importante socializar sobre las soluciones y planificar con
los equipos los tiempos de implementación, para que todos los involucrados conozcan las
herramientas que serán utilizadas en el proyecto.
2. Detallar
los casos
de prueba
 Planificar pensando en los cambios

Todos sabemos que los proyectos son dinámicos. Cambian las prioridades, hay actividades que se
demoran y surgen contingencias y nuevos requerimientos que se agregan.

Una planificación adecuada nos permitirá realizar cambios de forma preventiva y no de forma
reactiva, así puedes tener el control cuando la presión aumenta y los tiempos son escasos.

Una vez se definan los casos y suite de pruebas, así como los tiempos que estos pueden llevar en
función del método de prueba, es decir si son manuales o automatizadas, recomendamos ajustar
nuestro plan a la realidad cambiante, para ello ten en cuenta los siguientes pasos:
Priorizar casos de prueba y actividades
Al tener priorizadas las actividades por objetivo y nivel de importancia, podrás ajustar la
planificación en los casos en que el calendario se reduzca o se recorten los presupuestos.
Tu plan tiene que ser la herramienta que te permita contestar estas preguntas:
• ¿Qué sucede si se retrasa el desarrollo con las entregas a pruebas?
• ¿Qué sucede si se posterga la fecha de puesta en producción?
Planificar en base a expectativas.
Los proyectos tienen muchos integrantes y no siempre se produce el software de la
misma forma. Hay equipos que cambian, requerimientos más complejos o tecnologías
nuevas que el equipo desconoce. Tomar en cuenta esos aspectos y reforzar las pruebas
de esos requerimientos especiales es un factor de éxito.
3. Ajuste al plan de pruebas
Una vez ejecutado el plan de pruebas, se procede con las actividades
de ajuste y replanificación en caso que sea necesario. Esta actividad es
fundamental, a fin de optimizar tanto el plan como los recursos para
las siguientes etapas y así lograr los resultados esperados. Para ello
proponemos:
 Hacer un seguimiento activo del
proyecto de desarrollo, ajustando la
planificación de forma acorde.
En proyectos ágiles, el seguimiento
activo se realiza en las reuniones de Ajustar en base a resultados.
planificación de sprint, pero en otro Los datos mandan. Ajusta la
tipo de proyectos es necesario que el planificación para reforzar las pruebas
analista de QA esté al tanto de los de los objetivos que presentan más
avances y contratiempos del fallas y libera recursos de aquellos que
desarrollo y mantenga una estrecha presentan menores niveles de fallos.
comunicación con los encargados del
desarrollo, para poder ajustar la
planificación de pruebas y actuar
preventivamente.
Actividades para el despliegue y
mantenimiento

Para el despliegue y mantenimiento de un proyecto de tecnologías de la

información (TI), es crucial seguir un plan detallado que incluya una serie de
actividades específicas. Aquí tienes algunas actividades clave para el despliegue
y mantenimiento exitoso de un proyecto de TI:
 Despliegue:
Planificación del Despliegue:
Establecer un calendario para el
despliegue, considerando los plazos, la
disponibilidad de recursos y el impacto
en los usuarios.
Designar un equipo responsable del
despliegue y definir roles y
responsabilidades.
Preparación del Entorno:
Configurar la infraestructura necesaria,
incluyendo servidores, redes y sistemas
de almacenamiento.
Realizar pruebas de integración y
rendimiento en un entorno de
preproducción para asegurar que el
sistema funcione correctamente antes
del despliegue.
Empaquetado y Distribución:
Empaquetar el software y los
componentes necesarios en una versión
lista para ser desplegada.
Establecer un proceso de distribución
controlado para garantizar que la
versión correcta del software se
despliegue en los entornos adecuados.
4. Ejecución del Despliegue:
Realizar el despliegue del software siguiendo un
plan detallado y coordinado.
Realizar pruebas post-despliegue para asegurar
que todas las funcionalidades estén disponibles y
funcionando correctamente.
5. Formación de Usuarios:
Proporcionar formación y materiales de apoyo
para los usuarios finales sobre cómo utilizar el
nuevo sistema.
Establecer un proceso para recopilar
comentarios de los usuarios y abordar cualquier
problema o pregunta que surja durante el
despliegue
 Mantenimiento:
Actualizaciones y Parches:
Monitorear regularmente las actualizaciones y
parches de seguridad disponibles para el
software y aplicarlos según sea necesario.
Establecer un proceso de gestión de cambios
para planificar y coordinar actualizaciones de
software y cambios en la infraestructura.
Soporte Técnico:
Establecer un sistema de soporte técnico para
responder a consultas y resolver problemas
técnicos de los usuarios finales.
Proporcionar documentación y recursos de
autoayuda para facilitar la resolución de
problemas por parte de los usuarios.
Monitoreo y Mantenimiento
Preventivo:
Implementar herramientas de monitoreo para
supervisar el rendimiento del sistema y detectar
posibles problemas antes de que afecten a los
usuarios finales.
Realizar mantenimiento preventivo regular,
como la limpieza de registros y la optimización
de bases de datos, para garantizar un
rendimiento óptimo del sistema.
 Mantenimiento:

4. Gestión de Incidentes y Problemas: 5. Evaluación y Mejora Continua:

Establecer un proceso de gestión de incidentes y
problemas para registrar, investigar y resolver
problemas reportados por los usuarios finales.
Realizar análisis de causa raíz para identificar y
abordar las causas subyacentes de los problemas
recurrentes.
Realizar evaluaciones periódicas del desempeño del
sistema y recopilar comentarios de los usuarios
finales para identificar áreas de mejora.
Implementar cambios y mejoras basados en los
resultados de las evaluaciones para garantizar que
el sistema siga cumpliendo con los requisitos y
expectativas del negocio.

Al seguir estas actividades de manera sistemática y proactiva, se puede garantizar un despliegue exitoso y un
mantenimiento eficiente del proyecto de tecnologías de la información a lo largo de su ciclo de vida.
Documentación