PPTS de Ing Software

INTRODUCCIÓN A LA
INGENIERÍA DE SOFTWARE
Ing. Lourdes Roxana Díaz Amaya

INGENIERÍA DE
SOFTWARE
Definición de Ingeniería de Software
La Ingeniería del Software se podría definir como el establecimiento

y aplicación de principios de la Ingeniería para obtener software.
Teniendo en cuenta factores tan importantes como el costo
económico, la fiabilidad del sistema y un funcionamiento eficiente
que satisfaga las necesidades del usuario.
Definición de Ingeniería de Software
La Ingeniería de Software es un proceso multicapa, formado

por un proceso, métodos, herramientas apoyadas por u
enfoque de calidad.
Herramientas
Métodos
Proceso
Un Enfoque de Calidad
Capas de la Ingeniería de Software
Define un marco de Trabajo para el

desarrollo de Software en sus áreas
Proceso
claves., que van a formar la base
del control de proyectos del
software.
Indica como construir teóricamente

Métodos
el software, Incluyen análisis de
requisitos, análisis, diseño,
construcción de programas,
pruebas y mantenimiento.
Capas de la Ingeniería de Software
Es el software que se utiliza para

desarrollar e integrar los métodos
Herramientas y el proceso. Actualmente existen
los CASE (Software asistida por
computadora).
Un Enfoque de Calidad
Es la correcta aplicación de los
métodos y técnicas, se establecen
hitos que aseguren la calidad y el
cambio se gestiona
adecuadamente.
El Proceso del Software
Un conjunto coherente de
políticas, estructuras organizacionales, tecnologías,
procedimientos y artefactos que son
necesarios para concebir, desarrollar,
instalar y mantener un producto software
Elementos del Proceso de Software
El Proceso del Software
Es un marco de desarrollo, donde se definen un numero determinado

de actividades, que son aplicables a todos los proyectos de software,
con independencia de su tamaño y complejidad
Marco de Trabajo
Actividades del Marco común
Conjunto de Tareas
Hitos
Entregas
PROCESO DE INGENIERIA DE
SOFTWARE
PROCESO DE INGENIERIA DE
SOFTWARE
El proceso de ingeniería de software se define como "un conjunto de etapas
parcialmente ordenadas con la intención de logra un objetivo, en este caso, la
obtención de un producto de software de calidad".
El proceso de desarrollo de software "es aquel en que las necesidades del

usuario son traducidas en requerimientos de software, estos requerimientos
transformados en diseño y el diseño implementado en código, el código es
probado, documentado y certificado para su uso operativo". Concretamente
"define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto
objetivo".
Proceso de Desarrollo de Software
PROCESO DE DESARROLLO DE SOFTWARE
- Proceso y Ciclo de Vida
- Modelos de Desarrollo
IINGENIERIA DE SOFTWARE
- Ingeniería de Requerimientos
- Modelado de Análisis
- Ingeniería de Diseño
- Diseño de Arquitecturas
- Estrategias y técnicas de pruebas
- Ingeniería de Software Basada en Componentes
-
Métricas
- Estimación ADMINISTRACION
- Planificación DE PROYECTOS
- Administración de Riesgos
- Administración de la calidad
- Administración del cambio
GESTION DE PROYECTOS DE
SOFTWARE
Es una actividad muy necesaria, cuando se construyen productos y sistemas para ser
utilizados por la computadora
Implica la planificación, supervisión, y control de personal del proceso y de los eventos que
ocurren mientras evoluciona el software, desde la fase preliminar, implementación al hasta
la implantación.
Comprende las cuatro P’s

1. Personal
2. Producto
3. Proceso
4. Proyecto
GESTION DE PROYECTOS DE
SOFTWARE
Personal Organizarse en equipos eficaces, motivados
para realizar un software de calidad y
coordinados para alcanzar una comunicación
efectiva.
Proceso
El Proceso debe de adaptarse al personal y al

problema, Se selecciona una estructura
común de proceso
Producto
Debe definirse los objetivos y

requerimientos de producto.
Proyecto
El Proyecto debe planificarse,
estimando el esfuerzo y el tiempo para
cumplir las tareas, estableciendo
puntos de control de calidad.
Planificación de Proyectos de Software
Para una correcta gestión de proyecto, necesita una buena planificación del proyecto.
La Planificación implica la estimación del trabajo, cuanto dinero, esfuerzo, recursos y tiempo
supondrá construir u sistema o producto especifico de software.
Es importante conocer el costo, tiempo que utilizará el proyecto antes de empezar el proyecto.
Planificación del Tiempo
Perspectiva histórica del Desarrollo de Software
Década 1950-60: Década 1990-00
▪ “Software como un añadido” ▪ Generalización POO
▪ Aplicaciones sencillas ▪ Programación visual
▪ Desarrollo artesanal, a medida ▪ Tecnología de componentes
▪ Lenguajes de bajo nivel ▪ Interoperabilidad (CORBA)
Década 1960-70: ▪ Nuevas plataformas (Java, .NET)
▪ Primeras aplicaciones complejas ▪ Análisis/Diseño OO -“Guerra de los métodos” UML 1997
▪ Década lenguajes y compilación ▪ Patrones
▪ “Crisis del software” ▪ Tecnología CASE (2ª generación)
▪ Popularización de Internet
Década 1970-80:
Década 2000-2020
▪ Programación estructurada ▪ Generalización comercio electrónico
▪ Modelo relacional
▪ Web 2.0
▪ Primeras etapas Ingeniería del Software
▪ Desarrollo web
▪ Primeros métodos estructurados
▪ Seguridad
▪ Modelado de datos
▪ Arquitecturas basadas en servicios (SOA)
Década 1980-90: ▪ Arquitecturas de Capas, MVC, etc.
▪ Programación OO ▪ Métodos ágiles XP, ICONIX, SCRUM, etc.
▪ 4GLs ▪ Desarrollo opensource
▪ Cliente /Servidor ▪ Desarrollo Movil
▪ Tecnología de SGBDs, Sos ▪ Software de AI,
▪ Métodos estructurados ▪Aplicaciones Web progresivas. (web+Movil)
▪ Tecnología CASE (1ª generación)
Situación actual de la Ingeniería de Software
✓ Se ha establecido UML (Lenguaje Unificado de Modelado) como una notación estándar de análisis y
diseño OO.
✓ Aparecen métodos ágiles como Extreme Programming.
✓ SWEBOK(Guide to theSoftware EngineeringBodyofKnowledge) (2001).
✓ Algunas universidades han comenzado a ofrecer un título en isw.
✓ Comités CSAB (ComputerScienceAccreditationBoard) y
✓ABET (AccreditationBoardforEngineeringandTechnology).
✓ CMMI (CapabilityMaturityModelIntegration) del SEI (Software Engineering Institute) y la familia de
estándares ISO 9000 son usados para valorar la capacidad de una organización de ISW.
✓ En EE UU, el Colegio de Ingenieros Profesionales de Texas (Texas BoardofProfessionalsEngineers) ha
comenzado a licenciar ingenieros del software.
✓ ACM e IEEE-CS han desarrollado y adoptado conjuntamente un Código de Ética para Profesionales en
Ingeniería del Software.
Tecnología de Desarrollo de Software
Proceso de Desarrollo Lenguaje de

Implementación
Tecnología
Notación
Gestor de BD
Herramienta Case
Ingeniería de Software
Es la disciplina o área de la informática que ofrece métodos y técnicas para desarrollar y mantener
software de calidad.
Tecnología Desarrollo
Proceso de Desarrollo Requerimientos
Notación Análisis y Diseño
Herramientas Case Implementación
Lenguaje de Desarrollo Pruebas
Arquitectura Implantación
Despliegue de Hardware y
comunicaciones
Ingeniería de
Software
Aseguramiento Gestión
de la calidad
Proyecto
CMMI Personal
Producto
Moprosoft
22
Cuando los stakeholder Cliente indican
✓ No cumple con los procedimientos del Negocio

✓ No cumple con los requerimientos
✓ No han cumplido con el desarrollo de todos los
requerimientos definidos
✓ El tiempo de desarrollo se ha extendido demasiado
✓ El uso del software es demasiado complicado
✓ Los costos de desarrollo implantación son excesivos.
✓ Confiabilidad cuestionable de los cálculos u resultados de
algunos procedimientos.
Que indican los stakeholder Desarrollador
✓ No se definió bien el problema ni se preciso el alcance (Magnitud del proyecto)
✓ Los procedimientos de la empresa no están estandarizados.
✓ La complejidad del software se incrementa
✓ Los analista no definieron bien los requerimientos
✓ Los usuarios, administrativos no tienen claro los requerimientos, cambian
continuamente
✓ Incremento del numero de usuarios de los sistemas de software
✓ Tipos de usuarios no homogéneos
✓ Los usuarios no asisten a la capacitación en el uso del sistema
✓ Los usuarios no tienen tiempo para verificar los resultados y pruebas del sistema.
✓ No se preciso los cambios en el entorno
✓ Todos los integrantes del equipo de desarrollo no están preparados para asumir este
proyecto.
Como, solucionar estos problemas?
• Definir bien el problema, la solución y precisar el alcance
• Establecer la viabilidad económica, social, ética del proyecto.
• Monitoreo constante al proyecto.
• Definir objetivos y gestionar riesgos de desarrollo de software
• Hacer un contrato que involucre tiempos, holguras, costos y penalidades.
• Mantenerse al corriente de cualquier cambio o problema procedimental
• Establecer una lenguaje común entre los integrantes del equipo
desarrollador
• Establecer medidas de contingencia coherentes sin bajar la calidad al
producto para los problemas que se presenten
APLICAR LA INGENIERÍA DE SOFTWARE
Tecnología de Desarrollo de Software
Proceso de Desarrollo
Tecnología Lenguaje de
Implementación
y Calidad
Notación
Herramienta Case Gestor de BD
Normas de calidad de software
Tecnología de gestión de Proyectos de Software
Industria del Software en el Perú
• Una de las industrias que tiene inmensas oportunidades es la del software, cuyo
mercado mundial asciende a los $ 1,500 billones.
• El Perú es un actor que tiene significativas ventajas para obtener parte del
consumo internacional, ya que cuenta con un activo en capital humano (30,000
programadores) y con la presencia de aproximadamente 300 empresas (90%
pequeñas y microempresas), que en su mayoría no superan una década de
funcionamiento.
Sector de las Tecnologías de Información cada vez cobra

mas importancia, por ser:
✓ Países latinoamericanos han tomado la iniciativa de apoyar sus

industrias informáticas, considerándolas “sector de interés nacional”
✓ En nuestro país, la industria del software tiene un expectante
potencial de crecimiento:
✓Da empleo directo e indirecto altamente calificado a más de 6000
peruanos.
✓ Pese a lo comentado, la industria informática dista aún de estar
consolidada. “La informalidad es un cáncer para nuestra actividad
porque disipa el esfuerzo de las empresas formales”, comenta Amau.
✓ Se reclama una política gubernamental para incentivar la
formalización del sector, que acelere el desarrollo de los centros
informáticos
Año Ventas Incremento Exportación

(millones de (millones de
dólares) dólares)
2008 160 - 16
2009 171 7.0 18
2010 182 6.4 19
2011 205 12.6 21
2012 240 17,0 25
2015 438 82,5 45
2016 50
2017 51
17
36
Las limitaciones del sector de TI
• Las principales limitaciones para el desarrollo del sector son:

• Carencia de fuentes de financiamiento para proyectos tecnológicos.
• Insuficiente infraestructura tecnológica (hardware y conexiones a costo
internacional)
• Presencia real y significativa de la piratería del software. Según BSA es
de 61%.
¡ Es necesario implementar políticas de fomento para el sector

tecnológico!
Planes de la industria del Software para los próximos 5 años
• Programa BID de apoyo a la industria de software: Sostenibilidad de la

Capacitación en CMMI (Capability Maturity Model Integration), de los Ingenieros de
Software, laboratorio de testeado, estudios, eventos, etc.
• Fomento a las exportaciones de software.
• Esquema descentralizado de capacitación especializada (provincias
componente importante)
• Centro de arbitraje tecnológico.
• Centro de incubación de empresas de base tecnológica.
• Certificación de competencias laborales IT-CARD.
Preguntas ?
Modelos de Software
Objetivos:
✓ Comprender los conceptos principales relacionados con el proceso

de ingeniería de software y el ciclo de vida del software.
✓ Conocer los procesos, métodos y modelos que se aplican

actualmente en la Ingeniería de software
✓ Conocer los principales ciclos de vida del software.

La aplicación de un enfoque sistemático, disciplinado y

cuantificable al desarrollo, operación(funcionamiento) y
mantenimiento del software; es decir, la aplicación de
Ingeniería al software [IEEE, 1993].
Enfoque de Calidad
Cualquier disciplina de ingeniería (incluida la ingeniería del software)

debe descansar sobre un esfuerzo de organización de calidad. La gestión
total de la calidad y las filosofías similares fomentan una cultura continua
de mejoras de procesos que conduce al desarrollo de enfoques cada vez
más robustos para la ingeniería del software.
Proceso de Software
Un conjunto coherente de
políticas, estructuras organizacionales,
tecnologías,
procedimientos y artefactos que son
necesarios para concebir, desarrollar,
instalar y mantener un producto software.
Mario Platini
Proceso de Software
Es un marco de desarrollo, donde se definen un numero determinado de
actividades, que son aplicables a todos los proyectos de software, con
independencia de su tamaño y complejidad
Marco de Trabajo
Actividades del Marco común
Conjunto de Tareas
Hitos
Entregas
Proceso de Software
Qué es un proceso de Software?
Es un conjunto estructurado de actividades para:

• Especificar
• Diseñar
• Implementar
• Probar
• Mantener Software.
Proceso de Software
Tiene Sub Tiene Salida Tiene Sub
Actividad Tiene Intermedio Producto/

Entregable
Tiene Entrada
Stakeholder Utiliza Herramienta

/Desarrollador Obedece
Necesita
Tiene Sub
Rol
Tiene Norma
Tipos de Elementos para representar un proceso de Software

Proceso de Ingeniería de Software
El proceso de Ingeniería de Software se basa en modelos, métodos y

herramientas que sirven como una guía para los ingenieros de Software durante
el proceso de desarrollo, con la finalidad de mejorar la calidad de los proyectos,
procesos y productos mediante la evaluación y medición de los mismos
Ciclo de Vida del Software
Un concepto dado por ISO 12207 “ Es un marco de referencia que contiene los
procesos las actividades y las tareas involucradas en el desarrollo, la explotación y
el mantenimiento de un producto de software, abarcando la vida del sistema desde
la definición de los requisitos hasta la finalización de su uso”
Modelos del ciclo de vida del software
Existen varios modelos del ciclo de vida del software, sin embargo los mas
utilizados son: Cascada, Incremental, Evolutivo y Espiral.
Modelo Cascada -Secuencial
Definición de
Requerimientos
Diseño del Software

y del Sistema
Implementación y
Prueba de unidades
Integración y Prueba
del Sistema
Operación y
Mantenimiento
Modelo Cascada
Se puede hacer uso de este modelo cuando se presenten las siguientes

condiciones:
• Cuando los requisitos del problema se entienden razonablemente.
• Para hacer adaptaciones o mejorías bien definidas a un sistema existente.
• Limitadamente en proyectos nuevos, solo cuando los requisitos están muy bien
definidos y estables en forma razonable.
El modelo en cascada sugiere un enfoque sistemático, secuencial hacia el
desarrollo del software.
Problemas que se presentan al aplicar el modelo en
cascada
Es raro que los proyectos reales solo sigan el flujo secuencial que propone el
modelo. El modelo tiene iteraciones indirectas, lo cual confunde al equipo
desarrollador.
Con frecuencia es difícil para el cliente establecer todos los requisitos de manera
explicita. El modelo lo requiere desde un principio.
El Cliente debe tener paciencia. Una versión funcionando estará lista cuando el
proyecto este muy avanzado.
Modelo Cascada -Retroalimentación
Definición de
Requerimientos
Diseño del Software

y del Sistema
Implementación y
Prueba de unidades
Integración y Prueba
del Sistema
Operación y
Mantenimiento
MODELOS DE PROCESOS INCREMENTALES
Cuando hay una necesidad imperiosa de producir de manera rápida un conjunto

limitado de funcionalidad para el usuario y después refinarla y expandirla en entregas
posteriores de software. En estos casos se elige un modelo de proceso diseñado para
producir el software de manera incremental.
➢ El modelo incremental combina elementos del modelo en cascada aplicado en

forma iterativa.
➢ Combina elementos del modelo lineal con la filosofía de creación de prototipos
➢ El primer incremento a menudo es un producto esencial (núcleo)
➢ A partir de la evaluación se planea el siguiente incremento y así sucesivamente
➢ Es interactivo por naturaleza
➢ Aseguramiento de la calidad
➢ Es útil cuando el personal no es suficiente para la implementación completa
Ventajas:
Se puede financiar el proyecto por partes
Apropiado para proyectos grandes de larga duración
No se necesita tanto personal al principio como para una implementación completa
Desventajas:
Se necesitan pruebas de regresión (Bugs):
ón: Son pruebas que descubren las causas de errores. Errores de Funcionalidad o
nales, etc.Pueden aumentar el coste debido a las pruebas
MODELOS DE DESARROLLO EVOLUTIVO
Actividades Concurrentes
Versión
Especificación
Inicial
Descripción Desarrollo/ Versiones

del sistema Implementación Intermedias
Validación Versión
Final
MODELOS DE DESARROLLO EVOLUTIVO
Conlleva el refinamiento sucesivo de una arquitectura OO, por el cual se aplica la

experiencia y resultados de cada versión a la siguiente iteración del análisis y el
diseño.
Ventajas:
Es ideal para sistemas que no tienen bien definidos los requerimientos.
Los desarrolladores ven más rápido el resultado de su trabajo.
Desventajas :
Es difícil distinguirlo del proceso “codifica y corrige”
El Modelo en Espiral
Evalúe alternativas,
Determine objetivos identifique y resuelva
alternativas y Análisis de riesgos
restricciones Riesgos
Análisis de
Riesgos
Análisis de
Riesgos Prototipo
Prototipo Operacional
Análisis Prototipo
de
REVISIÓN Prototipo
Riesgos
Simulaciones, modelos y benchmarks

Plan de requerimientos
Concepto de
Plan del ciclo de vida
Operación Requeri
mientos de Diseño Diseño
SW del Detallado
Plan de Validación de Producto Codificación
Desarrollo Requerimientos
Prueba de
Plan de Integración Diseño Unidades
Prueba de
y Prueba V &V
Prueba de Integración Desarrolla y verifica
Planea la Aceptación el siguiente nivel
siguiente fase Servicio del producto
Ventajas
Centra su atención en la reutilización de componentes y eliminación de errores en
información descubierta en fases iniciales.
Los objetivos de calidad son el primer objetivo.
Integra desarrollo con mantenimiento.
Provee un marco de desarrollo de hardware/software.
Los desarrolladores observan los resultados de sus trabajos más rápidamente.
Puede modificar algunos requerimientos durante el desarrollo.
Desventajas
▪Es un modelo amplio y necesita de personal con experiencia, sino podría fracasar
el modelo.
▪Se debe aplicar a proyectos grandes.
Preguntas ?
UNT. INGENIERIA
INDUSTRIAL
Tecnología orientado a objetos

Tecnología orientada a objetos
La “Orientación a objetos” es la más importante tecnología que se ha difundido

recién en los años 90s. Se basa en la concepción del mundo real. Esto es lo que
hace que la tecnología a Objetos sea vista como la herramienta del presente y
del futuro. El ser humano por naturaleza piensa en objetos. La TO no se limita a
los Sistemas de Información, sino de cualquier tipo. Ejemplo. Sistema de
comunicación, redes neurales, ingeniería de organización y métodos y
ingeniería de productos.
Abstracción
El Mundo esta formado por objetos
3.15 + 8.7i
Linux
Conceptos Fundamentales
Objeto: Entidad del mundo real, puede ser real o abstracto, que exhibe
propiedades (atributos) , con unos comportamientos (métodos)
particulares.
Métodos: Especifican la forma que se controlan las propiedades de un

Objeto.
Atributos + Métodos = Objeto

Los objetos tienen atributos que los distinguen de otros
y son capaces de hacer un conjunto de tareas
estadoCandado
colorPelota tipoManuscrito
cerrarCandado( ) estadoTaza( ) nombreChica
abrirCandado( ) lanzarPelota( ) hacerseInvisible( ) autorManuscrito
llenarTaza( )
hacerseVisible( )
marcaJugo 3.15 + 8.7i marcaGaseosa

saborJugo tipoDiagrama parteReal precioGaseosa
tomarJugo( ) colorDiagrama parteImaginaria tomarGaseosa( )
dibujarDiagrama( ) leerComplejo( ) enfriarGaseosa( ) marcaLeche
mostrarComplejo( ) tamañoLeche
abrirLataLeche( )
empresa tipoSerMitologico
tomarLeche( )
tipoOrganigrama tipoComputadora volarSerMitologico( )
tipoEcuacion
añadirNivel( ) tipoDisco
resolverEcuacion( )
tipoProcesador tipoVentana
prenderComputadora( ) abrirVentana( )
nombreObra tipoAvion
autorObra cerrarVentana( )
annioFabAvion
lugarObra tipoPescado volarAvion( )
nombreSO
restaurarObra( ) nadaPescado( ) aterrizarAvion( )
versionSO
comePescado( ) cargarSO( )
exponerObra( )
Linux
apagarSO( )
Objeto
Tipo de objeto
Tipo de Objeto: Es un grupo de objetos que tiene atributos particulares.
Ejemplo: Empleados, estudiantes, clientes, proveedores.
Clase : Agrupación de tipos de Objetos, especifica una estructura de datos y métodos
que se aplican a cada uno de sus objetos.
Ejemplos: Clase : Persona
Tipos de Objeto: Estudiante, profesor, trabajador.
Clase : Documentos
Tipos de Objeto: Orden De Compra, Pedido, Factura, Guías de Remisión, etc.
Clase: Producto
Tipos de Objeto: Productos en Proceso, Productos Terminados, Activos, Materiales.
…En programación
¿Qué es una Clase?
Es un molde a partir del cual podemos construir variables (llamadas objetos).
Dentro de ese molde se incluyen atributos (variables miembro) y funciones (funciones
miembro o métodos).
¿Qué es un objeto?
Es una variable de una clase.
En la terminología de objetos se dice “un objeto es una instancia de una clase”
La Clase es simplemente una declaración, un nuevo “tipo de dato” que contiene atributos
y métodos, formas para ocultar sus partes internas y formas predefinidas para accederlas
desde el exterior.
Si declaramos una variable de alguno de los tipos base simplemente será una variable,
pero si declaramos una variable de una clase, entonces ésta variable se llamara objeto.
Objetos
La Caricatura de César Liza
El auto Fantástico
La Fórmula de Einstein
La Letra A
El Superhéroe Superman La Vía Láctea
En el mundo real un objeto es cualquier cosa que exista en el universo
11
Clase La Clase Fórmula La Clase Caricatura
La Clase Auto
mM
F = G -------
R2
La Clase SuperHéroe
La Clase Letra
La Clase Galaxia
En el mundo real una clase es una agrupación de objetos que tienen iguales 12
características y comportamiento
Encapsulado
Encapsulado : Es el resultado de ocultar los detalles de implementación de
un objeto respecto a su usuario.
Ejemplo:
Cuando se realiza un préstamo, los usuarios no saben exactamente como
se calculan los intereses.
Mensajes: Es una solicitud que hace que se produzca una operación (método).
Herencia
Herencia : Es la propiedad mediante la cual una superclase hereda sus propiedades,
y métodos, etc. a una subclase. Ejemplo
La superclase Persona hereda a la Subclase estudiante, atributos como Nombre,

sexo, dirección, etc.
Instancia: Es la mínima expresión de un Objeto

Ejemplos:
Carlos es una instancia del Subtipo Empleado y de la Clase persona
Lola es instancia del Subtipo vaca marron
Instancia
Polimorfismo : Los métodos son distintos pero tienen el mismo efecto.

Ejemplo : Retiro de un Empleado, el método para retirar a un Ejecutivo es
diferente que para un empleado común.
Evento : Es algún suceso que puede causar un cambio de estado a un objeto.

Ejemplo: Click, cancelación , solicita un café
Polimorfismo
Auto
Acelera
Frena
Cohete
Acelera
Frena
Transporte
Acelera Caballo
Acelera
Frena
Frena
19
SCRUM
INTRODUCCIÓN
A SCRUM
HISTORIA SCRUM
La historia de Scrum se puede Durante sus investigaciones. se

rastrear desde 1986 en un dieron cuenta que dichas
artículo de Harvard Business empresas compartían seis
Review características
Jeff Sutherlond y Ken

Schwober.
Marco de trabajo a través del
cual las personas pueden
abordar problemas complejos
No es un proceso. una
DEFINICIÓN técnica, o método definitivo.
SCRUM 2
Muestra la eficacia relativa
de las técnicas de gestión
de producto y de trabajo
3
Burndown
01 chart
02 Framework
Product
03
Backlog
Product
04
Owner
ANGLICISMOS
05 Scrum Board
06 Scrum Master
07 Sprint
Sprint
08
Backlog
ESTRUCTURA DE LA GUÍA DEL SCRUM
USOS DEL SCRUM
01 Investigar e identificar mercados

viables, tecnologías. y capacidades.
02 Desarrollo de mejoras a productos ya

existentes.
Desarrollo de productos que requieren

03 lanzamientos diariamente o tantas
veces como sea posible.
Desarrollo y mantenimiento en la Nube y

04 otros entornos operacionales de
desarrollo para el uso de productos.
05 Mantenimiento y renovación de
productos.
¿Scrum se implementa o se
adopta?
EQUIPO
SCRUM
El Equipo Scrum ha demostrado ser
incrementalmente efectivo en diferentes contextos
y para cualquier trabajo complejo.
Participar en las reuniones de
01 apertura y cierre del proyecto.
Gestionar los riesgos globales

02 del proyecto.
Presentar informes del proyecto al

03 cliente u otras partes interesadas.
Aprobar cambios en el
04 proyecto.
Asegurar que se administran

05 correctamente los recursos
financieros del proyecto.
Es la única persona responsable

06 de gestionar el Product Backlog
Es la única persona responsable de gestionar el
06 Product Backlog
● Expresar claramente los elementos del Product

Backlog.
● Ordenar los elementos en el Product Backlog para
alcanzar los objetivos Y las misiones de la mejor
manera posible.
● Garantizar que el Product Backlog sea visible.
transparente y clara para todos y que muestre. lo que el
equipo trabajará a continuación.
● Asegurar que el Equipo de Desarrollo entienda los
elementos del Product Backlog a nivel necesario.
Se compone de profesionales que realizan el trabajo de
entregar un incremento de producto "Terminado".
Nadie fuera del SM y el PO puede
pedir al Equipo de Desarrollo que
01 trabaje en un conjunto diferente
de requisitos.
Son multifuncionales. con todos
02 las habilidades necesarias para
crear un incremento de producto.
Scrum no reconoce títulos para

03 los miembros de un Equipo de
Desarrollo
No reconoce sub-equipos en
04 los Equipos de Desarrollo.
Los miembros del Equipo pueden

05 tener habilidades especializadas y
áreas en las que estén más enfocadas
Responsable de promocionar y apoyar
al Equipo Scrum.
Su principal responsabilidad entonces

es garantizar que todos conocen y
aplican correctamente la teoría de
Scrum.
Es un líder Ayuda a las personas Ayuda a todos a

sirviente que externas al Equipo modificar estas
Scrum a entender interacciones para
está al servicio
quéEquipo
interacciones
de maximizar el valor
del Equipo
con el Equipo Scrum
Desarrollo creado por el Equipo
Scrum. pueden ser útiles y
& Scrum Scrum
cuáles
Masterno.
EVENTOS EN SCRUM
Daily Scrum
Reunión de Reunión de
Planificación Revisión del
del Sprint Sprint
03
02 04
01 05
SPRINT Reunión de
Corazón del Scrum. Retrospectiva
del Sprint
DURACIÓN
SPRINT
CANCELACIÓN
REUNIÓN DE PLANIFICACIÓN DEL SPRINT
Duración Participantes Acciones
2 horas por cada Product Backlog

semana de Equipo Scrum Actividades
Sprint Sprint Backlog
Daily Scrum
Equipo de ¿Que hice hoy?

15 minutos Desarrollo & ¿Que haré mañana?
Scrum Master ¿Impedimentos?
Reunión de Revisión del Sprint
Presentación
Aciertos/Errores
Equipo Scrum
1 hora por cada Dificultades
semana de Aprobación
Invitados de
Sprint
Product Owner
New Product
Backlog
Reunión de Retrospectiva del Sprint
Inspección 365 de Last

1 hora por cada Equipo de Sprint
semana de Desarrollo &
Sprint Scrum Master Ident. Posibles Mejores
Plan de Implementación
ARTEFACTOS DE SCRUM
Product Backlog Registro de Obstaculos

Necesidades,
características,
funcionalidades,etc.
Sprint Backlog Registro de Lecciones

Roles
Elementos del Product Aprendidas
Backlog para 1 Sprint. SCRUM
Emisores de
Información Portafolio de
Scrum Board
Burndown chart del Sprint
Proyectos
Diagrama de Flujo SCRUM
Acumulado
Product Backlog
Product
01 Todo lo que podría ser necesario en
el producto. Owner
02 Dinámico, siempre cambia conforme

se modifica el producto y su entorno. Dinámico
03 Caracteristicas, funcionalidades,
requisitos, mejores y correcciones. Enumera
04 Descripción, Orden, Estimación,

Criterios de aceptación.
Ordenado
El Product Backlog es interminable,

05 siempre hay retroalimentación del
mercado
Infinito
Sprint Backlog
Character 3
Character 1 Character 2 Character 4 Character 5
SCRUM BOARD
Emisores de
1
BURNDOWN CHART
Información 2
DIAGRAMA DE FLUJO
ACUMULADO
3
SCRUM BOARD
Burndonw Chart
Diagrama de
Flujo Acumulado
OBSTACULOS
Registros LECCIONES
APRENDIDAS
2
PORTAFOLIO DE
PROYECTOS
3
PRINCIPIOS DE SCRUM
TRANSPARENCIA
1. CONTROL 1
EMPÍRICO DE INSPECCIÓN
PROCESOS
2
SCRUM se basa en el control empírico
de los procesos o empirismo ADAPTACIÓN
3
2. AUTO ORGANIZACIÓN
Los miembros del equipo quienes eligen

3. SIMPLICIDAD Se intenta reducir al máximo la
burocracia en sus prácticas
DISEÑO SIMPLE
1
USO DE
HERRAMIENTAS
SOFTWARE
2
4. CENTRADO EN EL VALOR PARA EL CLIENTE
5. CUMPLIMIENTO
Bloques de Reglas de
tiempo equipo
Se alistan reglas
Los equipos establecen
esenciales que deben
sus propias reglas
ser cumplidas
6. DESARROLLO ITERATIVO
6. DESARROLLO ITERATIVO
CONSIDERACIONES PARA LA GESTIÓN DEL PROYECTO
1. CONTRATACIÓN
Contratación del equipo - consideraciones
Roles del proyecto
COMPROMETIDOS PRODUCT OWNER SCRUM MASTER EQUIPO DE DESA.

El Product Owner INVOLUCRADOS
- Experto en Scrum - Experto en Scrum
El Scrum Master - Conocimiento básico
- Amplia experiencia - Capacidad para
El Equipo de de Scrum
del negocio resolver problemas
Desarrollo - Expertos técnicos
- Buen negociador - Habilidades de
Despite being - Multifuncionales
INVOLUCRADOS - Organizado coordinación - Proactivos
- red, Mars is a
Experiencia en - Líder servicial
Clientes cold place
dirección de
Usuarios proyectos
Proveedores - Líder servicial
Habilidades para un mejor desempeño
01 02
Habilidades Técnicas Habilidades esenciales
Diseño - Desarrollo de Habilidades blandas, permiten
Software - Conocimiento de lograr la empatía y buenas
una herramienta específica relaciones
SCRUM
04 Process 03
Herramientas Procesos y prácticas
App’s, Tableros Scrum, Conocer los entregables,
Softwares, metodologías eventos, o herramientas a usar
adicionales. dentro del proyecto Scrum
2. FINANZAS
01 02 03 04
Inicio del Proyecto Ejecución del Proy. Cierre del Proyecto Retorno de la inver.
Reporte final que Cálculo de las

Presupuesto inicial Al final de cada Sprint,
describa los costos utilidades (o valor
del proyecto, que debe realizarse
del proyecto, en financiero) generado
permitirá evaluar la seguimiento y control
relación al por un proyecto
viabilidad de iniciar financiero del proyecto,
presupuesto
un proyecto para así evitar posibles
solicitado
problemas.
Identificar posibles Responsable: Responsable: APMO

riesgos financieros. Product Owner.
3. SEGUIMIENTO Y CONTROL El Product Owner hace seguimiento deL
trabajo restante total al menos en cada
La Oficina de Gestión de Proyectos Ágiles Revisión de Sprint.
(APMO), tiene la responsabilidad de : De esta manera evaluar el progreso hacia
la finalización del trabajo proyectado en el
tiempo deseado para el objetivo.
Actividades de calidad
Control de que se realizan a los
incrementos del
Calidad producto y al final sobre
el mismo producto
Evaluación de los
procesos y normas que Aseguramiento
están definidos en el
Ciclo de vida de un de la Calidad
proyecto Scrum
4. GESTIÓN DE RIESGOS
01 02 03 04
IDENTIFICACIÓN EVALUACIÓN PRIORIZACIÓN MITIGACIÓN DEL

DEL RIESGO DEL RIESGO DEL RIESGO RIESGO
COMUNICACIÓN DEL RIESGO

5. GESTIÓN DE CAMBIOS
Manifiesto ágil: “Aceptamos que los requisitos cambien, incluso en etapas tardías del
desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja
competitiva al cliente”.
¿Por qué?
ÁGIL = CAMBIO ¿Quién solicita el
Formato para Solicitud de Cambios – cambio? ¿Para qué necesitamos
RFC (Request For Change)
¿Para cuándo se hacerlo?
necesita?
¿Qué tan
importante es? ¿Quién lo va a
El Product Owner es el rol
responsable de ¿Qué pasa si no se ejecutar?
aprobar/rechazar los realizara/aprobara
cambios
el cambio?
¿Qué necesita?
6. GESTIÓN DE PRODUCTO
Producto mínimo viable: Primera
versión del producto se construye tan
pronto como sea posible. El Producto
Mínimo Viable se define entre el
Cliente y el Product Owner.
Etapa 1
SCRUM Modelo Lean Canvas (adaptado de
Business Model Canvas): es el de
Etapas previas al proyecto como la identificar la viabilidad de un producto
concepción, prototipado y diseño del o servicio y así disminuir el riesgo y
producto no siempre se explican al los posibles obstáculos.
detalle, siendo altamente importantes Etapa 2
para el buen desarrollo del proyecto.
Algunos de los conceptos que se deben

considerar en esta etapa son:
Cuando se realiza el diseño de productos

innovadores, se pueden considerar 9 principios
que forman parte de la arquitectura del
producto
CICLO DE VIDA
EN UN PROYECTO
SCRUM
6 Etapas | 17 Prácticas
- Etapa 1 -
INICIO DEL PROYECTO
DEFINIR LA VISIÓN DEL PROYECTO (2)
Triángulo de
Hierro
FORMAR EL EQUIPO SCRUM (2)
Modelo de Desarrollo de Equipos
Dr. Bruce Tuckman

FORMAR EL EQUIPO SCRUM (2)
Modelo de Desarrollo de
Habilidades de Dreyfus
PRIORIZAR EL BACKLOK (4)
Priorización por
Urgencia
PRIORIZAR EL BACKLOK (4)
Visual Story
Mapping
DEFINIR EL CRONOGRAMA DE ENTREGA (5)
Calendario del
Proyecto
DEFINIR ARQUITECTURA DEL PROYECTO (6)
- Etapa 2 -
PLANIFICACIÓN
DEL SPRINT
ESCRIBIR HISTORIAS DE USUARIO Y TAREAS (7)
- Etapa 3 -
DESARROLLO DEL
SPRINT
DESARROLLAR LOS ENTREGABLES (10)
SCRUM DIARIO (11)
- Etapa 4 -
REVISIÓN DEL
SPRINT
Equipo de desarrollo: Alto

REUNIÓN DE RETROSPECTIVA SPRINT (13)
Índice de felicidad del equipo

REUNIÓN DE RETROSPECTIVA SPRINT (13)
4L’s
- Etapa 5 -
DESARROLLO DEL
SPRINT
PLANIFICACIÓN DE LA IMPLEMENTACIÓN (14)
- Etapa 6 -
CIERRE DEL Cierre del proyecto (16)
Reunión de retrospectiva
del proyecto (17)
PROYECTO
BIBLIOGRAFÍA
CERTMIND
Scrum - An Agile Approach to Manage Successful Projects, 2020.
Alexander Menzinsky, Gertrudis López, Juan Palacio, 2019.

SCRUM MANAGER: Temario Troncal I
Versión 2.6.1
Alaimo, Diego Martín

Proyectos ágiles con Scrum : flexibilidad, aprendizaje, innovación y colaboración
en contextos complejos . - 1a ed. - Ciudad Autónoma de Buenos Aires : Kleer,
2013. EBook.
Gestión de la
calidad del
diseño de
software.
Integrantes
Calderón Rodríguez María Teresa
Gil Blas Mauricio Del Piero
Guzman Robles Karen Paola
Maldonado Saldaña Augusto
Rodriguez Narcizo Carlos Alberto
Vásquez Castañeda Miryan
OBJETIVOS
Conocer y entender los procesos de Gestión de la calidad,

control y planificación de un software.
Entenderla importancia de los estándares en el proceso de

gestión de la calidad
Entender como las mediciones pueden ser útiles en el cálculo

de los atributos de calidad de software.
2 INGENIERIA
INDUSTRIAL
PROBLEMAS PRESENTES EN EL PROCESO
DE LA CALIDAD DE UN SOFTWARE:
• En las especificaciones no se organizan ni describen los requerimientos que son

necesarios para conocer en el diseño de un software
1
• No se sabe cómo especificar ciertas características de calidad (por ejemplo,

mantenimiento) de una forma ambigua.
2
• Es muy difícil redactar especificaciones concretas de software. Por lo tanto,
aunque un producto se ajuste a su especificación, los usuarios no lo consideran
3 un producto de alta calidad debido a que no responde a sus expectativas.
3 INGENIERIA
INDUSTRIAL
ESTRUCTURA DE LA GESTIÓN DE LA
CALIDAD
Es el establecimiento de un marco de trabajo de

La selección de procedimientos y estándares organizacionales
GARANTIÍA DE LA
procedimientos y CALIDAD
que se conduce a software de alta calidad.
estándares adecuados
a partir de este marco
de trabajo y la
adaptación de estos PLANIFICACIÓN
DE LA CALIDAD
para un proyecto de
software específico.
CONTROL DE LA CALIDAD Procesos que garanticen que los
procedimientos y estándares para la
calidad del proyecto son seguidos por
el equipo y desarrollo del software.
4 INGENIERIA
INDUSTRIAL
LA GESTIÓN DEL PROCESO IMPLICA
Definir
estándares de
proceso, como
las revisiones a
realizar, cuando
llévalas a cabo,
etc.
GESTIÓN
DE LA
CALIDAD
Hacer informes Supervisar el
del proceso para proceso de
el gestor del desarrollo para
proyecto y para el asegurar que se
comprador del sigan los
software estándares
5 INGENIERIA
INDUSTRIAL
¿QUÉ ES LA GARANTIA DE CALIDAD?
Es el proceso que define como lograr la

calidad del software y como la organización de
desarrollo conoce el nivel de calidad requerido
en el software.
El proceso QA se ocupa ante todo de definir o
seleccionar los estandares que deben ser
aplicados al proceso de desarrollo software o
al producto software.
6 INGENIERIA
INDUSTRIAL
Tipos de estándares como parte del
proceso de garantía de calidad.
Estándares de
producto Estándares de proceso
• Se aplican sobre el • Definen los procesos que

producto software que deben seguirse durante
se inicia a desarrollar. el desarrollo de software.
22 de julio
de 2021
7 INGENIERIA
INDUSTRIAL
Importancia de los estándares de
software
Conocimiento Marco de trabajo Continuidad
• Los estandares captan • Aseguran que todos

el conocimiento (el • Proveen un marco los ingenieros de una
mejor) que es de valor de trabajo organización adopten
para la empresa, el cual alrededor del cual las mismas practicas.
se adquiere después de se implementa el Se reduce el esfuerzo
un proceso de prueba y proceso de garantía de aprendizaje cuando
error, lo que evita la de la calidad. Se se comienza un nuevo
repetición de errores. captan las mejores trabajo.
practicas.
22 de julio
de 2021
8 INGENIERIA
INDUSTRIAL
Los gestores de la calidad deben tomar las
siguientes consideraciones:
Paso 1 Paso 2 Paso 3
Involucrar a los ingenieros de Revisar y modificar los Proveer Herramientas de
software estándares software
• En el desarrollo de • De forma regular con el fin • Para apoyar los

los estándares del de reflejar los cambios en la estandares donde
proyecto. Así tecnología. Cuando se sea necesario. Los
comprenderán la desarrollan, tienden a estandares
necesidad de diseñar plasmarse en un manual de burocráticos son la
los estándares y se estandares de la compañía, causa de muchas
comprometerán con el cual debe evolucionar de quejas debido al
ellos. acuerdo con las trabajo tedioso que
circunstancias y la se requiere para
INGENIERIA
tecnología existentes. implementarlos.
9
INDUSTRIAL
Los estándares
puedes causar
problemas …
Diferentes tipos de software requieren distintos
procesos de desarrollo.
Cada gestor de proyecto tiene la facultad de
modificar los estandares de proceso de acuerdo con
circunstancias particulares. Sin embargo, los
estandares relacionados con la calidad del producto
y del proceso posterior a la entrega solo deben
cambiarse después de cuidadosas consideraciones.
El gestor del proyecto y el gestor de calidad deben
decidir cuales son los estandares del manual que
utilizaran sin cambio alguno, cuales se modificaran y
cuales se dejaran de lado. Pueden tener que crearse
nuevos estandares para un requerimiento particular.
10 INGENIERIA
INDUSTRIAL
¿Dónde pueden aplicarse?
¿Qué es?
Desde las organizaciones de
Un conjunto de estandares que
manufactura hasta la de
se pueden utilizar en eld
servicios.
esarrollo de un sistema de
gestión de calidad en todas la
sindustrias.
ISO
9000
Uno de los estándares
¿Qué hace? generales…
Describe los fundamentos de los
sistemas de gestión de la calidad
y especifica la terminología para ISO 9001
los sistemas de gestión de la
calidad.
11 INGENIERIA
INDUSTRIAL
ISO
9001
Se aplica en organizaciones interesadas en el

proceso de calidad de diseño, desarrollo y
mantenimiento de productos.
No es un estándar especifico para desarrollo

de software, pero define principios
generales que pueden aplicarse al software.
Describe varios aspectos del proceso de calidad

y define que estandares y procedimientos deben
existir en una organización. Estos deben
documentarse en un manual de calidad
organizacional.
12 INGENIERIA
INDUSTRIAL
13 INGENIERIA
INDUSTRIAL
Los procesos de garantía de calidad en una
organización se documentan en un manual de
calidad que define el proceso de calidad.
En algunos países, autoridades acreditadas certifican

que el proceso de calidad está reflejado en el manual
de calidad y es conforme al estándar ISO 9001.
Algunos personas piensan que la certificación ISO

9000 significa que la calidad del software producido
por las compañías certificadas sera mejor que la de
las compañías no certificadas.
El estándar ISO 9000 se refiere a la definición de los

procedimientos que son utilizados en la compañía y
la documentación asociada que muestre que los
procesos han sido seguidos.
INGENIERIA
14 INDUSTRIAL
ESTÁNDARES DE DOCUMENTACIÓN
Existen 3 clases de estándares de documentación:
Estándares del proceso de Estándares para el intercambio de

Estándares del documento:
documentación: define el proceso documentos: aseguran que todas
gobiernan la estructur y
a seguir para la producción del las copias electrónicas de los
presentación de los documentos.
documento. documentos sean compatibles.
INGENIERIA
15 INDUSTRIAL
ALGUNOS EJEMPLOS DE ESTÁNDARES DE
DOCUMENTOS A DESARROLLAR SON:
1. Estándares de identificación de documentos.
2. Estándares de la estructura del documento.
3. Estándares de presentación de documentos.
INGENIERIA
4. Estándares para actualizar los documentos.
16 INDUSTRIAL
PLANIFICACIÓN DE LA CALIDAD
• Es el proceso en el cual se desarrolla un plan de calidad para un proyecto.

• El plan de calidad define la calidad del software deseado y describe como
valorar esta.
Por lo tanto, se define lo que es software de “alta

calidad”.
INGENIERIA
17
INDUSTRIAL
Estructura para el plan de calidad
• Contiene la descripción del producto, el mercado al que se
INTRODUCION
DEL PRODUCTO
dirige y las expectativas de calidad.
• Contiene las fechas de terminación del producto y las

PLANES DE
PRODUCTO
responsabilidades importantes.
• Contiene los procesos de desarrollo y de servicio a utilizar

DESCRIPCIONES
DEL PROCESO
para el desarrollo y administración del producto.
• Contiene las metas y planes de calidad para el producto

METAS DE
CALIDAD
(incluye identificación y justificación de atributos)
• Contiene los riesgos clase que podrían afectar a la calidad

RIESGOS Y
GESTION DE
RIESGOS
de riesgo del producto y acciones para abordarlos.
18 INGENIERIA
INDUSTRIAL
CONTROL DE CALIDAD
El control de calidad implica vigilar el proceso de desarrollo de software
para asegurar que se siguen los procedimientos y estándares que
garanticen la calidad.
Revisiones Valoración automática
• EL software, su documentación • El software y los documentos

y los procesos utilizados para producidos se procesan por
el desarrollo son revisados por algún programa y se comparan
un grupo de personas. con los estándares que se
aplican a su desarrollo.
19 INGENIERIA
INDUSTRIAL
REVISIONES DE LA CALIDAD
Las revisiones son el método mas utilizado para validar la calidad de un proceso o de
un producto.
Las revisiones Equipo de Responsabilidades

revisiones • El autor: sigue el
• Involucran a un grupo • El equipo de revisiones documento junto con el
de personas que debe tener un núcleo de equipo de revisión.
examinan todo o parte tres o cuatro personas.
del rpoceso. • Un miembro preside y otro
• Uno debe ser el registra formalmente las
• Las conclusiones de la diseñador principal. revisiones.
revisión se registran
formalmente y se pasan • Los revisores • El presidente: es
al responsable de principales pueden responsable que se
corregir los problemas. invitar a otros miembros consideren todos los
del proyecto a colaborar. comentarios.
22 de julio • Al final el responsable de la
revisión firmara el registro
de 2021 para luego pasarlo a la
20 INGENIERIA documentación formal del
INDUSTRIAL proyecto.
MEDICION Y METRICAS DEL SOFTWARE
Las revisiones son caras, consumen tiempo e inevitablemente retrasan
la entrega del software.
21 INGENIERIA
INDUSTRIAL
• La medición del software se refiere a derivar un valor numérico desde algún atributo del
software o del proceso. Comparando estos valores entre si y con los estándares aplicados
en la organización, es posible sacar conclusiones de la calidad del software o de los
procesos del desarrollo.
Las mediciones sirven para:
Mediante las
HACER PREDICCIONES GENERALEA Haciendo mediciones
mediciones podemos
de las características de
IDENTIFICAR COMPONENTES
identificar los
los componentes del
componentes que se
ACERCA DEL SISTEMA
sistema reuniendo
salgan de control. Por
estas podemos derivar
ejemplo, podemos
una estimación general
ANOMALOS
medir los componentes
de algunos atributos del
para identificar los de
sistema, como el
complejidades mas
numero de fallos.
altas.
22 INGENIERIA
INDUSTRIAL
METRICAS
Ambas pueden influir
CONTROL en la toma de PREDICCION
decisiones de gestión.
Las métricas de
Estas métricas suelen
predicción por otro
estar asociadas con
lado estas asociadas a
los procesos.
los productos.
EJEMPLO: El esfuerzo y
EJEMPLO: La
el tiempo promedio
complejidad
requeridos para
ciclomatica de un
reparar los defectos
modulo.
encontrados.
23 INGENIERIA
INDUSTRIAL
FRECUENTEMENTE …
• Es imposible medir los atributos de calidad

del software directamente. Los atributos de
calidad son externos, y nos dicen como ven
el software los desarrolladores y los
usuarios. Estos se ven afectados por
diversos factores y no existe un camino
simple para medirlos. Mas bien es necesario
medir atributos internos del software y
suponer que existe una relación clara y
valida entre los atributos internos y externos
del software.
INGENIERIA
24
INDUSTRIAL
RELACIONES ENTRE LOS ATRIBUTOS EXTERNOS E
INTERNOS DEL SOFTWARE
El diagrama sugiere que existe una relación entre
los atributos externos e internos, pero no dice que
relación es. Para que la medida del atributo
interno sea un indicador útil de las características
externa, se deben cumplir tres condiciones:
• El atributo interno debe medirse de forma

precisa.
• Debe existir una relación entre lo que se puede
medir y el atributo de comportamiento externo.
• Esta relación se comprende, ha sido validada y
se puede expresar en términos de una formula o
modelo,
25 INGENIERIA
INDUSTRIAL
EL PROCESO DE
MEDICIÓN
• La figura nos muestra el proceso de

medición del software dentro de un
proceso de control de calidad. Cada
uno de los componentes del
sistema se analiza por separado y
los diversos valores de las métricas
se comparan entre sí y, quizás, con
los datos históricos de medición
recogidos en los proyectos previos.
26 INGENIERIA
INDUSTRIAL
Pasos claves en este proceso
Seleccionar las medidas a Seleccionar los Medir las características de
realizar componentes a evaluar los componentes
• Se debe formular las • No es necesario o • Se miden los

preguntas que la deseable estimar los componentes
medición intenta
responder y definir las valores de las seleccionados y se
mediciones requeridas métricas de todos los calculan los valores de
para resolver estas componentes de un las métricas
preguntas.
sistema de software.
27 INGENIERIA
INDUSTRIAL
Pasos claves en este proceso
Identificar las mediciones Analizar los componentes
anómalas anómalos Finalmente
• Una vez que se obtienen • Una vez identificados los

las mediciones de los • Los datos recogidos se
componentes con
componentes, se valores anómales para mantienen como un
comparan entre sí y con las métricas recurso organizacional y
las mediciones previas particulares, se deben conservarse
registradas en una base examinan estos registros históricos de
componentes para
de datos de mediciones. decidir si los valores de todos los proyectos aun
• Se debe examinar los la métrica indican que la cuando los datos no se
valores masl ato y los calidad del componente hayan utilizado durante
tenga una calidad
mas bajos de cada deficiente, en un proyecto en
métrica. particular.
28 INGENIERIA
INDUSTRIAL
MÉTRICAS DE PRODUCTO:
¿QUE ES? CARÁCTERÍSTICAS: CLASIFICACIÓN:
• Las métricas de producto se • Las relaciones varían dependiendo 1. Las métricas dinámicas, que son
refieren a las características del de los procesos, la tecnología y el recogidas por las mediciones
software mismo. tipo de sistemas a desarrollar. hechas en un programa en
ejecución.
• Desafortunadamente, las • Las organizaciones interesadas en
características del software que se 2. Las métricas estáticas, que son
la medición tienen que construir
miden fácilmente, como el tamaño recogidas por las mediciones
una base de datos históricos.
y la complejidad ciclomática, no hechas en las representaciones
Después, ésta se puede utilizar
tienen una relación clara y del sistema como el diseño, el
para descubrir cómo se relacionan
consistente con los atributos de programa o la documentación.
los atributos del producto de
calidad como la compresión y la software con la calidad en la que
mantenibilidad. está interesada la organización.
29 INGENIERIA
INDUSTRIAL
METRICAS ESTADISTICAS
Fan-in es una medida del número de funciones o métodos que llaman a otra función o método (por
Fan-in / Fa-out
ejemplo, X). Fan-out es el número de funciones que son llamadas por una función X.
Ésta es una medida del tamaño del programa. Generalmente, cuanto m6s grande sea el tamaño del
código de un componente, más complejo y susceptible de errores ser6 el componente. La longitud del
Longitud del código
código ha mostrado ser la métrica m6s fiable para predecir errores en los componentes.
• Ésta es una medida de la complejidad del control de un programa.
Complejidad ciclomática • Esta complejidad del control está relacionada con la comprensión del programa.
• Es una medida de la longitud promedio de los diferentes identificadores en un programa.
Longitud de los indicadores • Cuanto más grande sea la longitud de los identificadores, más probable será que tengan significado;
por lo tanto, el programa será más comprensible.
Ésta es una medida de la profundidad de anidamiento de las instrucciones condicionales “if” en un

Profundidad del anidamiento de las
programa. Muchas condiciones anidadas son difíciles de comprender y son potencialmente susceptibles
condiciones de errores.
Ésta es una medida de la longitud promedio de las palabras y las frases en los documentos.
Y EL Índice de Fog
Cuanto más grande sea el Índice de Fog. el documento será más difícil de comprender.
30 INGENIERIA
INDUSTRIAL
METRICAS ORIENTAS A OBJETOS
Ésta representa el número de niveles discretos en el árbol de herencia donde las subclases heredan
Profundidad del árbol de atributos y operaciones (métodos) de las superclases. Cuanto más profundo sea el árbol de
herencia herencia, más complejo será el diseño. Muchas clases de objetos distintas tienen que
comprenderse para conocer las clases de objetos en las hojas del Árbol.
Está directamente relacionada fan-in y fan-out, como se describió antes, y significa esencialmente lo
Método Fan-in/Fan-out mismo. Sin embargo. es conveniente hacer una distinción entre las llamadas provenientes de otros
métodos dentro del objeto y las llamadas provenientes de los métodos externos.
Métodos pesados por clase Los objetos complejos tienden a ser más difíciles de comprender. No son lógicamente cohesivos.
por lo que no se pueden reutilizar efectivamente como superdases en un árbol de herencia.
Número de operaciones Éste es el número de operaciones en una superclase que se anulan en una subclase. Un valor alto
sobrescritas para esta métrica indica que la superclase utilizada no es una madre adecuada para la subclase.
31 INGENIERIA
INDUSTRIAL
Un gestor decide supervisar el
Las mediciones se deben
número de peticiones de
analizar cuidadosamente para
cambios solicitados por los
comprender lo que realmente
clientes basándose en la
significan.
suposición de que existe una
relación entre estas peticiones
de cambios y la utilidad y
conveniencia del producto. .
ANÁLISIS
DE LAS
MEDICIONES
Procesar las peticiones de Los cambios en el proceso
cambios y cambiar el software comienzan involucrando más al
es costoso. Por lo tanto, la cliente en el proceso de diseño de
organización decide modificar software. Se introducen las
su proceso para incrementar la pruebas beta para todos los
satisfacción del cliente y, al productos, y las modificaciones
mismo tiempo, reducir los solicitadas por los clientes se
costes del cambio. incorporan en el producto a
entregar.
32 INGENIERIA
INDUSTRIAL
CONCLUSIONES
• La gestión de la calidad del software permite señalar si éste tiene un escaso
número de defectos y si alcanza los estándares requeridos de mantenibilidad,
1 fiabilidad, portabilidad.
• Un manual de calidad organizacional debe documentar un conjunto de

procedimientos de garantía de la calidad. Éste puede basarse en los modelos
2 genéricos sugeridos en los estándares ISO 9000.
• El proceso de control de calidad implica comprobar que el proceso del software

y el software a desarrollar concuerdan con estos estándares.
3
INGENIERIA
33 INDUSTRIAL
CONCLUSIONES
• Las mediciones de software se utilizan para recoger datos cuantitativos acerca del
software y sus procesos.
4
• Las métricas de calidad del producto son de gran valor para resaltar los
componentes anómalos que tienen problemas de calidad. Estos componentes se
5 deberán analizar con más detalle.
• No existen métricas de software estandarizadas y aplicables universalmente. Las

organizaciones deben seleccionar métricas y analizar mediciones basadas en el
6 conocimiento y circunstancias locales.
34 INGENIERIA
INDUSTRIAL
Gracias
INGENIERÍA
WEB
Universidad Nacional de Trujillo
INTEGRANTES
Grupo 3
+Arteaga Cotrina Josselin
+Bermudez Reyes Emily
+Flores Rodriguez Ana
+Gonzales García Estefany
+Marquina Bardales Liseth
+Medina Alvarez Herbert
INGENIERÍA WEB
La ingeniería web propone un

marco de trabajo ágil, pero
disciplinado, para construir
aplicaciones web de calidad
industrial.
La Ingeniería Web incorpora

nuevas aproximaciones,
metodologías, técnicas y guías
para cumplir los requisitos de
los sistemas web
01
CARACTERISTICAS
CARACTERÍSTICAS
Intensidad de la red Concurrencia

Toda aplicación web reside Un gran número de usuarios
en una red y debe atender puede acceder a la WebApp
las necesidades de una al mismo tiempo
comunidad de clientes
diversa.
CARACTERÍSTICAS
Carga imprevisible Rendimiento

El número de usuarios de la Si un usuario de una
WebApp puede variar en aplicación web tiene que
órdenes de magnitud de un esperar demasiado tiempo,
día a otro. puede decidir irse a otro
sitio.
CARACTERÍSTICAS
Disponibilidad Manejo de los datos

La aplicación web debe estar La función principal de
disponible en todo momento. muchas WebApps es utilizar
hipermedia para presentar
contenidos de texto, gráficos,
audio y vídeo al usuario final
CARACTERÍSTICAS
Sensible a los contenidos Evolución continua

La calidad y la estética del Las WebApps
contenido siguen siendo evolucionan continuamente
un determinante importante
de la calidad de una
aplicación web.
CARACTERÍSTICAS
Seguridad Estética
Para proteger el contenido Una parte innegable del
sensible y proporcionar atractivo de una aplicación
modos seguros de web es su aspecto y la
transmisión de datos, deben sensación.
adoptarse fuertes medidas
de seguridad
02
LENGUAJES
HTML
ASP
INGENIERÍA
WEB JAVASCRIPT
PHP
JSP
Lenguaje HTML
Estático Sintaxis
Desarrollado por
Word Wide Web
Dar formato al
contenido
Comienzo
<etiqueta>
Final
</etiqueta>
Lenguaje JAVASCRIPT
Pequeño programa Sintaxis
Navegador lo
compila
Lenguaje
seguro
Lenguaje PHP
Sintaxis
Páginas web dinámicas
Lenguaje sencillo
de aprender
Conecta con
distintos
dispositivos
Lenguaje ASP
Sintaxis
Páginas web dinámicas
Lenguaje sencillo
de aprender
Conecta con
distintos
dispositivos
Lenguaje JSP
Sintaxis
Lenguaje multiplataforma
Código HTML/XML
y SCRIPT
Se escribe en Java
03
FRAMEWORK
Definición:
- Conjunto de componentes de software
que los programadores pueden usar,
extender, o personalizar para una
determinada aplicación.
- Es un mecanismo de reutilización
orientado a objetos que permite al
desarrollador descomponer una aplicación
en un conjunto de objetos que interactúan
entre sí.
https://pirhua.udep.edu.pe/bitstream/handle/11042/2054/ING_495.pdf?sequence=1&isAllowed=y
Patrón MVC
Model 2
Características del Framework:
Acceso a datos Controladores

Abstracción de Incluyen las Los implementa para
URLs y sesiones herramientas e gestionar eventos.
interfaces.
Autentificación y Separación entre

control de acceso diseño y
Incluyen mecanismo Internacionalización contenido
para la identificación de
usuarios.
http://www.lsi.us.es/~javierj/investigacion_ficheros/Framework.pdf
Tipos de Framework:
De aplicación De dominio De clase

Forman una estructura Los marcos de dominio Framework son una
básica de programador crean la estructura de combinación de clases y
para ciertos tipos de programación para un métodos que se pueden
aplicaciones área problemática utilizar para una amplia
particular gama de aplicaciones
Tipos de Framework:
De componentes De coordinación De prueba De web

Proporcionan la
Proporcionan un
capacidad de configurar Se utiliza Diseñados para el
entorno para el para probar desarrollo de webs
interacciones de
desarrollo e integración dinámicas y
dispositivos y sirven para software
de componentes de aplicaciones web.
garantizar una desarrollado.
software
compatibilidad perfecta
Beneficios:
Facilita el trabajo de los La programación consistente, menos

desarrolladores cuando es errores, y aplicaciones más flexibles,
necesario usar tecnologías generalmente siguiendo patrones de
complejas. diseño
Permite la agrupación de muchos

Facilita la ejecución de pruebas y
objetos/componentes discretos en
la depuración de código
algo más útil
Ejemplos de Framework
➢ .Net
➢ Symphony
➢ Zend Framework
➢ Laravel
➢ Django
➢ Ruby on Rails
➢ Angular
04
HERRAMIENTAS
Entorno de Entorno de Servidor de
desarrollo desarrollo aplicaciones
Compilar y ejecutar
integrado IDE
Seguridad del
aplicaciones
Editor de código fuente desarrollo
Automatización de
compilaciones locales
Depurador
Es un software que provee
herramientas de
desarrollo para la creación
de programas en Java.
Es un entorno de desarrollo
integrado libre, hecho
principalmente para el
lenguaje de programación
Java.
Es un producto libre y
Netbeans gratuito sin restricciones
de uso.
Es un servidor de código
abierto para la plataforma
Java.
05
PATRONES DE
ARQUITECTURA
Arquitectura web
Concepto
Es un conjunto de componentes, que

siguiendo una serie de reglas y procesos,
permiten usar una gran variedad de
servicios informáticos que serán
utilizados por una organización o empresa
para un mejor rendimientos
www...
Internet
Evoluciona
Aparece en los Años 80
años 50 ante la Gracias al capitalismo,
necesidad de a los sistemas de Llega la arquitectura
comunicación e transporte y de internet World
interacción entre comercialización de Wide Web o Red
seres humanos. ordenadores informática mundial
Loss Entonces
Mars is actually Aparecen las
a cold place redes LAN o redes
de área local, la
más utilizada
Ethernet
PROBLEM VS. SOLUTION
Transferir información ...
Para transferir la información desde un servidor web hacia un

cliente web se utiliza un protocolo llamado HTTP. Este
protocolo es el más utilizado en internet su siglas provienen
del inglés Hipertext Transfer Protocol, tiene como misión
principal la de transferir datos a través de la red de internet.
Elementos de arquitectura cliente/servidor
06
DESPLIEGUE
de una Aplicación Web
DESPLIEGUE DE UN SOFTWARE
¿Prueba? Características
Verificación de errores y Seguridad, fiabilidad,
confiabilidad del formalidad, estética,
software entrega al cliente
¿Qué es? Dinamismo

Si la entrada es la Corrección de errores,
URL, la salida es lo actualizaciones,
mostrado en el distintas versiones
navegador
PRINCIPIOS DE UN DESPLIEGUE
Ensamblaje y Capacitación
prueba
Expectativas Apoyo al Corrección

del cliente cliente
ERRORES COMUNES EN EL DESPLIEGUE
CASO: FALLA DEL SISTEMA

EN AERONAVE
● Error o equivocación
humana
● Falla en el desarrollo del
sistema
● Error del sistema
● Caída del sistema
GRACIAS!
CREDITS: This presentation template was created
by Slidesgo, including icons by Flaticon,
infographics & images by Freepik and
illustrations by Stories
REFERENCIAS BIBLIOGRÁFICAS
Sommerville, I. 2011. Ingeniería de Software. 9ed. Mexico. Pearson
Berenguel, J.(2016), Desarrollo de aplicaciones Web en el entorno servidor. Ediciones Paraninfo. Recuperado de:
https://books.google.com.pe/books?id=gVGACwAAQBAJ&pg=PA127&dq=arquitectura+web&hl=es&sa=X&ved=2ahUKEwilp7_d2d
7xAhW7K7kGHfH_D6oQ6AF6BAgEEAI#v=onepage&q=arquitectura%20web&f=false
Red Hat Summit. (s.f.). Middleware Concepto de IDE. Red Hat. Recuperado de https://www.redhat.com/es/topics/middleware/what-is-ide
García, A. (2015). Modelo de programación web y base de datos. Editorial Elearning S.L. Recuperado de:
https://books.google.com.pe/books?id=Q1lWDwAAQBAJ&printsec=frontcover&hl=es#v=onepage&q&f=false
Genos. (2020).Glassfish. Genos Cloud service. Recuperado de https://www.genos.es/glassfish/
Pressman, R. S., & Lowe, D. (2009). Web engineering (1.a ed.). McGraw-Hill. Recuperado de :
https://es.scribd.com/document/438721423/McGrawHill-Web-Engineering-A-practioner-s-approach-2009-Roger-S-Pressman-David-Lowe-pdf
Ruiz, J. (2011). Comparativa entre el desarrollo Web usando el Framework Jboss Seam y el desarrollo tradicional. Tesis de
pregrado no publicado en Ingeniería Industrial y de Sistemas. Universidad de Piura. Facultad de Ingeniería. Programa Académico
de Ingeniería Industrial y de Sistemas. Piura, Perú. Recuperado de
https://pirhua.udep.edu.pe/bitstream/handle/11042/2054/ING_495.pdf?sequence=1&isAllowed=y
RIESGOS
EN
PROYECTOS INGENIERÍA DE SOFTWARE
INTEGRANTES
Acevedo Ávila, Alicia
Carranza Aldana, Cristhian
Lázaro Saavedra, Dhan
Medina Zavaleta, Danner
Verde Haro, Sandra
Yesán Luján, José
INTRODUCCIÓN
Según Peter Drucker “Mientras que es inútil intentar eliminar el
riesgo y cuestionable el poder minimizarlo, es esencial que los
riesgos que se tomen sean los riesgos adecuados”.
ÓN
es importante poder identificar todos los riesgos que sean obvios a
jefes de proyectos y profesionales del software.
CI La Identificación de Riesgos en proyectos de software consiste en la

UC
determinación de elementos de riesgos potenciales mediante la
utilización de algún método consistente y estructurado;
OD
El paso más importante entre todos aquellos que componen las

actividades de Administración de Riesgos no es posible desarrollar e
TR
implementar anticipadamente respuestas apropiadas a los problemas

que puedan surgir en el proyecto.
IN
El resultado de la identificación de riesgos es una lista conteniendo

los riesgos que se han identificados y su categoría correspondiente.
DEFINICIÓN
Riesgos en
Proyectos de Son riesgos de tipo técnico.
Software Los riesgos técnicos amenazan la calidad y temporalidad del

software que se va a producir.
Si un riesgo técnico se vuelve una realidad, la implementación

puede volverse difícil o imposible.
Los riesgos técnicos identifican potenciales problemas de

diseño, implementación, interfaz verificación y mantenimiento.
Riesgos en
Empresariales Amenazan la viabilidad del software que se va a construir y con
frecuencia ponen en peligro el proyecto o el producto.
Los candidatos para los cinco principales riesgos empresariales

son:
Riesgo de mercado
Riesgo estratégico
Riesgo de ventas
Riesgo administrativo
Riesgos presupuestales
Administración
de Riesgos en El análisis y la administración del riesgo son acciones que
Software
ayudan al equipo de software a entender y manejar la
incertidumbre.
Muchos problemas pueden plagar un proyecto de software.
Un riesgo es un problema potencial: puede ocurrir, puede no

ocurrir.
IMPORTANCIA
El software es una empresa difícil.
Muchas cosas pueden salir mal y, francamente, muchas con

frecuencia lo hacen.
comprender los riesgos y tomar medidas proactivas para

evitarlos o manejarlos son elementos clave de una buena
administración de proyecto de software.
CARACTERÍSTICAS
El Software Engineering Institute (SEI) (www.sei.cmu. edu) identifica siete características que
“ofrecen un marco conceptual para lograr una administración de riesgo efectiva”:
CARACTERÍSTICA Nº01 Ver los riesgos del software dentro del contexto de un sistema
Mantener una perspectiva donde el riesgo es un componente y el problema empresarial que
global se pretende resolver.
CARACTERÍSTICA Nº02 Pensar en los riesgos que pueden surgir en el futuro y establecer
Tomar una visión de planes de contingencia de modo que los eventos futuros sean
previsión manejables.
Si alguien enuncia un riesgo potencial, no lo ignore. Si un

CARACTERÍSTICA Nº03
riesgo se propone de manera informal, considérelo. Aliente
Alentar la comunicación
a todos los participantes y usuarios a sugerir riesgos en
abierta
cualquier momento.
CARACTERÍSTICA Nº04 Una consideración de riesgo debe integrarse en el proceso del
Integrar software.
CARACTERÍSTICA Nº05 El equipo debe vigilar a lo largo del proceso de software, modificar
Enfatizar un proceso los riesgos identificados conforme se conozca más información y
continuo agregar unos nuevos conformes se logre mejor comprensión.
CARACTERÍSTICA Nº06
si todos los participantes comparten la misma visión del software,
Desarrollar una visión de
es probable que haya mejor identificación y valoración del riesgo.
producto compartida
GESTIÓN DE
RIESGO DE
SOFTWARE
DEFINICIÓN
Aplicación sistemática de políticas de gestión, procedimientos y
prácticas con el fin de identificar, analizar, evaluar, tratar y realizar el
seguimiento del riesgo”.
Trata de formalizar conocimiento orientado a la minimización o
evitación de riesgos en proyectos de desarrollo de software
CARACTERÍSTICAS
Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no

puede ocurrir.
Pérdida: si el riesgo se convierte en una realidad, ocurrirán
consecuencias no deseadas o pérdidas.
RIESGOS MÁS COMUNES EN LOS PROYECTOS
El desconocimiento de lo que se ha comprado.
R. DERIVADOS DEL Las expectativas poco realistas o la falta de colaboración de los
CLIENTE
empleados.
R. DERIVADOS DE LA
EMPRESA Si el personal no tiene los conocimientos y experiencia suficientes,
SUMINISTRADORA DE subcontrata partes del proyecto a terceros que no responden
SERVICIOS
Si la planificación no es metódica y constante, el riesgo se vuelve muy
R. DERIVADOS DE LA real.
PLANIFICACIÓN Uno de los ejemplos más típicos derivados de la falta de planificación
es no establecer claramente quién debe realizar cada una de las fases
del plan.
R. DERIVADOS DEL Existe una gran variedad de riesgos derivados del propio producto
PRODUCTO a implantar.
Es evidente que se necesita analizar y realizar un plan de gestión
de riesgos en la implantación de software.
RIESGOS MÁS COMUNES EN LOS PROYECTOS
El desconocimiento de lo que se ha comprado.

R. DERIVADOS DEL
Las expectativas poco realistas o la falta de colaboración de los
PRODUCTO
empleados.
R. DERIVADOS DE LA
EMPRESA Si el personal no tiene los conocimientos y experiencia suficientes,
SUMINISTRADORA DE subcontrata partes del proyecto a terceros que no responden
SERVICIOS
Si la planificación no es metódica y constante, el riesgo se vuelve muy
R. DERIVADOS DE LA real.
PLANIFICACIÓN Uno de los ejemplos más típicos derivados de la falta de planificación
es no establecer claramente quién debe realizar cada una de las fases
del plan.
ESTRATEGIAS FRENTE AL RIESGO
REACTIVAS PROACTIVAS
Cuyo método es evaluar las consecuencias Aplican el método de evaluación previa y

del riesgo cuando este ya se ha producido. sistemática de los riesgos y sus posibles
Actuar en consecuencia. consecuencias.
Acarrea consecuencias negativas, al poner Conforman planes de contingencias para
el proyecto en peligro. evitar y minimizar las consecuencias.
Permite lograr un menor tiempo de reacción
ante la aparición de riesgos impredecibles.
Primero Planificar la gestión de riesgos.
Segundo Identificar los riesgos.
Proceso de Gestión
Tercero
de Riesgos en
Analizar los riesgos.
Proyectos de Cuarto Definir y aplicar actividades para la

resolución de eventualidades:
Desarrollo de
Quinto
Sistemas de
Comunicar los riesgos.
Información Sexto Controlar los riesgos.
Evaluar y aprender del proceso de

Séptimo gestión de riesgos.
TIPOS DE RIESGOS
EN LA GESTIÓN DE
RIESGOS DE PROYECTOS
DE SOFTWARE
TIPOS DE RIESGOS
Para cuantificar el nivel de incertidumbre y el grado de pérdidas asociado con cada riesgo se consideran
diferentes tipos de riesgos:
Riesgos del Proyecto Riesgos Técnicos Riesgos del Negocio

Afectan a la planificación temporal Amenazan la calidad y la Amenazan la viabilidad del software
y al coste del proyecto planificación temporal del software
que hay que producir.
Riesgos Conocidos Riesgos Predecibles Riesgos Impredecibles

Pueden predecir después de una Se extrapolan de la experiencia de Pueden ocurrir, pero es
evaluación del plan del proyecto, proyectos anteriores. extremadamente difícil
del entorno técnico y otras fuentes identificarlos por adelantado.
de información fiables.
ELEMENTOS
ESTIMACIÓN DE RIESGOS
Identificación de Análisis de riesgo Priorización de riesgos Control de riesgos

riesgos medición de la probabilidad y el Amenazan la viabilidad del
Lista de riesgos capaces de impacto de cada riesgo, y los software
romper la planificación del niveles de riesgo de los métodos
proyecto. alternativos.
Monitorización de riesgos
Planificación de la Resolución de riesgos
gestión de riesgos Comprobación del progreso
Ejecución del plan.
Plan para tratar cada riesgo del control de un riesgo e
significativo. identificación de la aparición
de nuevos riesgos.
ELEMENTOS
IDENTIFICACIÓN DE RIESGOS
Constituye un Un método para
Las incertidumbres
intento sistemático identificar los riesgos
Para especificar las amenazas Sobre diferentes características Es crear una lista de
al plan del proyecto. del proyecto se transforman en comprobación de elementos de
riesgos que pueden ser descritos riesgo que debe contener dos
y medidos. categorías de riesgos:
Riesgos específicos del
producto.
Riesgos genéricos.
ELEMENTOS
ANÁLISIS DE RIESGOS
Es el proceso de examinar los riesgos en detalle para determinar su extensión, sus interrelaciones y su
importancia.
Impacto Probabilidad Marco de Tiempo
Pérdida que ocasiona el riesgo. Probabilidad de que ocurra el Periodo de tiempo en el que es
riesgo. posible mitigar el riesgo.
CASO APLICATIVO
DE GESTIÓN DE
RIESGOS
DEFINICIÓN DEL CONTEXTO DEL PROBLEMA
La empresa de software y automatización “INTECH SAC” actualmente cuenta con un sistema de gestión de proyectos
relativamente joven en su implementación y en la administración de sus proyectos son reactivos a los acontecimientos
que van surgiendo, toda vez que no se tienen las herramientas, procesos o metodologías que busquen la prevención de
eventos que puedan afectar los objetivos de sus proyectos.
Asimismo, la información sobre las causas que ocasionaron el impacto o desviación negativa en el cumplimiento del
tiempo no se encuentra documentada, en las entrevistas realizadas a los directores de proyectos se encuentran como
detonantes de este periodo de desfase del termino de los proyectos, factores externos principalmente relacionados con
los clientes tales como:
Los componentes suministrados por el cliente no son adecuados para el producto que se está desarrollando, por lo
que se tiene que hacer un trabajo extra de diseño e integración.
Los componentes suministrados por el cliente tienen poca calidad, por lo que tienen que hacerse trabajos extra de
comprobación, diseño e integración.
Las herramientas de soporte y entornos impuestos por el cliente son incompatibles, tienen un bajo rendimiento o no
funcionan de forma adecuada, con lo que se reduce la productividad
Ante estas desviaciones que se obtuvieron en los indicadores de costo y calidad, surge la necesidad de analizar el
sistema de gestión de proyectos actual con el objetivo de proponer un modelo de gestión de riesgos que se ajuste a las
necesidades de la empresa, y que permita estar preparados para lo que pueda suceder.
JUSTIFICACIÓN
Contar con un modelo que permita Gestionar los Riesgos puede constituir
un panorama importante para la administración de proyectos al estar
preparados proactivamente para enfrentar las amenazas que afecten el
resultado final de los proyectos en un entorno de software, teniendo en
cuenta que el propósito principal es proteger los intereses de la empresa
y de los clientes.
OBJETIVOS
OBJETIVO
GENERAL Diseñar, gestionar e implementar la propuesta de un modelo práctico y
efectivo para la Gestión de Riesgos en proyectos de software para
INTECH SAC con el propósito de afrontar de manera proactiva a los
posibles eventos que afecten los objetivos de los proyectos.
OBJETIVOS Proponer un modelo de Gestión de Riesgos basado en las mejores

prácticas y metodologías de gestión de proyectos internacionales.
ESPECÍFICOS
Estructurar y determinar un modelo que permita optimizar los
resultados de los objetivos de tiempo, costo y calidad de los
proyectos.
Contribuir a la creación de una cultura preventiva para gestión de
proyectos dentro de la empresa.
HIPÓTESIS
El establecimiento de un modelo de Gestión del Riesgo, puede aumentar
significativamente el éxito en el desarrollo de los proyectos de software
de una organización a través de la identificación, evaluación, respuesta y
control de los efectos que puedan impactar el cumplimiento de los
objetivos del proyecto en tiempo, costo y calidad.
MODELO DE GESTIÓN DE RIESGOS PROPUESTO
Los 4 procesos se definieron teniendo en cuenta las necesidades de la
organización de contar con una estructura ágil y sencilla para incluirla en
su sistema de gestión de proyectos, alineado a las buenas practicas
sugeridas por los estándares internacionales.
MODELO DE GESTIÓN DE RIESGOS PROPUESTO
Presenta interacción con los procesos que marcan los momentos de decisión en el ciclo
de vida del proyecto y forman parte de la cadena de valor de la empresa como la
siguiente representación gráfica:
MODELO DE GESTIÓN DE RIESGOS
PROPUESTO
ESTIMACIÓN
Propósito de determinar si la organización tiene la capacidad operativa, tecnológica, de recursos, entre otros
para dar respuesta a los requerimientos de los clientes.
PROPUESTO
COTIZACIÓN
Establecer las actividades correspondientes a la documentación final de la cotización con los resultados del
proceso de análisis de riesgos y revisión con expertos, para el posterior envío al cliente.
Teniendo en cuenta la
definición de categorías
propuesto por la guía PMBOK,
se encontró alineación a las
categorías que pudieran
ajustarse a los eventos que
afectan a los proyectos de
software.
PROPUESTO
EJECUCIÓN
Propone desarrollar la gestión de
riesgos que incluye tener en cuenta
los análisis anteriores de riesgos en el
proceso de Cotización y detallar más
aspectos técnicos y administrativos
para la ejecución del proyecto que
puedan afectar los objetivos del
mismo.
PROPUESTO
A) IDENTIFICACIÓN
Generar una lista de riesgos con base en aquellos eventos que podrían impactar el logro de los
objetivos del proyecto de tiempo, costo y calidad.
Categorías de Riesgos
Lecciones aprendidas de otros proyectos
Matriz de riesgos inherentes
Banco de Proyectos.
Documentos del Proyecto: Plan de Trabajo, Presupuesto, Cotización, RFQ, entre otros
Herramientas a utilizar para la identificación de eventos:
Fecha Consecuencias
ID Riesgo Causas
Detección Integrar las posibles
Código que se asigna Eventos que, si Identificar la(s) causa(s) raíz consecuencias del riesgo de
para la identificación Fecha en qué se ocurrieran, afectarían los del riesgo, potencial(es) o
acuerdo al impacto que genera
del riesgo detectó el riesgo objetivos del proyecto de ya identificada(s) en los objetivos del proyecto
forma negativa o positiva. históricamente. en tiempo, costo, calidad.
PROPUESTO
B) ANÁLISIS Y EVALUACIÓN
A continuación: Escalas de Impacto
PROPUESTO
C) PLAN DE RESPUESTA
involucra la selección de una
o más opciones para
modificar los riesgos y la
implementación de tales
opciones.
PROPUESTO
D) SEGUIMIENTO Y CONTROL
Mediante el proceso de monitoreo o control se implementan
los planes de respuesta a los riesgos y se da seguimiento a
los riesgos identificados, se identifican nuevos riesgos y se
evalúa la efectividad del proceso de gestión de los riesgos a
través del proyecto.
Al finalizar la fase de ingeniería se realiza nuevamente análisis de riesgos en

la reunión de empalme donde se liberan los entregables de programación e
instalación de la arquitectura del software, los nuevos riesgos identificados
deberán documentarse en la plantilla de Gestión de Riesgos
GRACIAS
PROGRAMACIÓN EXTREMA
GRUPO 6
¿QUÉ ES UNA METODOLOGÍA AGIL?
En un proceso de software existen numerosas propuestas

metodológicas que inciden en distintas dimensiones del transcurso
de desarrollo.
Las Metodologías Ágiles resuelven los problemas surgidos,
posteriormente, a la masificación del uso del computador personal,
dado que las expectativas y necesidades por parte de los usuarios
se hicieron más urgentes y frecuentes.
Fue así como al comienzo de los 90 surgieron propuestas
metodológicas para lograr resultados más rápidos en el desarrollo
del software sin disminuir su calidad.
 PROGRAMACIÓN EXTREMA (XP)
 SCRUM
 CRYSTAL METODOLOGÍAS
 ADAPTIVE SOFWARE DEVELOPMENT (ASD)
 PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE
 DYNAMIC SYSTEMS DEVELOPMENT METHOD
PRINCIPALES METODOLOGÍAS ÁGILES

¿QUÉ ES LA PROGRAMACIÓN EXTREMA?
 La programación extrema es una metodología de

desarrollo ágil que tiene como principal objetivo
aumentar la productividad a la hora de desarrollar un
proyecto software.
 XP se basa en realimentación continua entre el cliente y el equipo de desarrollo.
 Simplicidad .en las soluciones implementadas y coraje para enfrentar los cambios.
CARACTERÍSTICAS DE LA
CARACTERÍSTICAS DE LA PROGRAMACIÓN EXTREMA
 Desarrollo iterativo e incremental

 Pruebas unitarias
 Programación en parejas
 El usuario es parte del equipo.
 Corregir antes de avanzar
 Re factorizar el código
 El código es de todos.
HERRAMIENTAS DE LA
HERRAMIENTAS DE LA PROGRAMACIÓN EXTREMA
 HISTORIAS DE
USUARIO
 TAREAS DE INGENIERÍA (TASK CARDS)

 PRUEBAS DE
ACEPTACIÓN
 TARJETAS CRC (CLASE - RESPONSABILIDAD – COLABORADORES)

PRINCIPIOS DE LA PROGRAMACIÓN EXTREMA
PRINCIPIO 1: RETROALIMENTACIÓN / FEEDABACK
PRINCIPIO DE CLIENTE IN PAIR PROGRAMMING

PRUEBAS PLANIFICACIÓN SITU
PRINCIPIO 2: PROCESO CONTINUO EN LUGAR DE BLOQUES
INTEGRACIÓN CONTINUA. REFACTORIZACIÓN. ENTREGAS PEQUEÑAS

PRINCIPIO 3: PROPIEDAD INTELECTUAL COMPARTIDA
 La programación se realiza en grupos de trabajo. De esta forma, nos aseguramos que se realice un código
con un enfoque colectivo para evitar errores.
PRINCIPIO 4: ENTENDIMIENTO COMPARTIDO
01 02
DISEÑO SIMPLE METÁFORA
03 04
PROPIEDAD COLECTIVA ESTÁNDAR DE PROGRAMACIÓN

ROLES DE LA PROGRAMACIÓN EXTREMA
I. EL PROGRAMADOR
II. EL CLIENTE
III. ENCARGADO DE PRUEBAS (TESTER)
IV. ENCARGADO DE SEGUIMIENTO (TRACKER)
(TESTER) (TRACKER)
V. ENTRENADOR (COACH)
VI. CONSULTOR
(COACH) (CONSULTOR)
VII. GESTOR (BIG BOSS)
FASES DE LA PROGRAMACIÓN EXTREMA
FASE 1: PLANIFICACIÓN
La programación en parejas
Definir las historias de usuario Se crea un plan de publicaciones. incrementa la productividad y
con el cliente. El tiempo de Luego el proyecto se divide en calidad del software
desarrollo es entre 1 y 3 iteraciones de aprox. 3 semanas desarrollado. Y es necesario
semanas. de duración. reuniones diarias.
FASE 2: DISEÑO
Glosario de
Diseños términos Riesgos Funcionalidad Tarjetas
Simples Extra C.R.C.
FASE 3: CODIFICACIÓN
 La programación aquí se hace en parejas, en frente del mismo ordenador. De esta forma, nos aseguramos que se realice un
código más universal, con el que cualquier otro programador podría trabajar y entender. Así se conseguirá una programación
organizada y planificada.
FASE 4: PRUEBAS
01 02
Uso de test para comprobar el Crear test que no tengan ninguna
funcionamiento de los códigos que se dependencia del código. Crear los test
implementan. abstrayéndose del futuro código.
03
Crear test de aceptación. Estos test son

creados y usados por los clientes para
comprobar que las distintas historias de
usuario cumplen su cometido.
FASE 5: LANZAMIENTO
Imagen 01. Fases de la programación extrema.

PRÁCTICAS
DE LA
METODOLOGÍA
XP
 COMUNICACIÓN: Conversación continúa entre el equipo de
desarrollo y el cliente, para implementar cambios lo antes posible.
 ENTREGAS PEQUEÑAS: Entrega en versiones operativas.
 DISEÑO SIMPLE: Diseñar lo más posible, pero con la funcionalidad

requerida.
 PRUEBAS: Se realizan pruebas unitarias por parte de los programadores

y pruebas de aceptación por parte del cliente.
 REFACTORIZACIÓN (REFACTORING): Remover código duplicado

para facilitar los posteriores cambios.
 PROGRAMACIÓN EN PAREJAS: Se realiza para contar con menor

tasa de errores, mejor diseño y mayor satisfacción de los programadores.
 INTEGRACIÓN CONTINÚA: Cuando un fragmento de código esté
listo, puede ser integrado al sistema.
 CLIENTE IN-SITU: El Cliente debe estar presente y disponible para el

equipo de desarrollo.
 ESTÁNDARES DE PROGRAMACIÓN: Normas definidas por los

desarrolladores para tener un código legible.
 JUEGO DE LA PLANIFICACIÓN: Desde el comienzo del desarrollo

se requiere que el grupo y el cliente tengan una visión general del proyecto.
En el transcurso del mismo se realizan diferentes reuniones, con el fin de
organizar las tareas e ideas que surgen tanto por parte del cliente como del
equipo.
 PROPIEDAD COLECTIVA DEL CÓDIGO: El Código no es conocido
por una sola persona del grupo del trabajo, esto facilita implementar
cambios al programa por parte de otros integrantes del grupo.
 UTILIZACIÓN DE METÁFORAS DEL SISTEMA: Para mejorar el

entendimiento de los elementos del sistema por parte del equipo de
desarrollo se acude a la utilización de metáforas, como una forma de
universalizar el lenguaje del sistema.
 TEST DEL CLIENTE: El Cliente con la ayuda de los desarrolladores,

propone sus propias pruebas para validar las mini-versiones.
 40 HORAS POR SEMANA: Se debe de trabajar un máximo de 40 horas

por semana.
CASO DE APLICACIÓN
CASO REAL: REPO MARGINING SYSTEM
Este es un ejemplo de un proyecto de estas características.

 La aplicación permitiría el comercio electrónico a través del navegador y mantener informadas a las dos partes del
trato.Además capturaría las ofertas que se hiciesen y las mostraría en un lugar dedicado para ello.
 El equipo estaría formado por 7 integrantes.
 El espacio laboral estaría habilitado para favorecer la comunicación entre los componentes.
 Se empezaría desarrollando (utilizando el lenguaje de programación JAVA) las clases, para poder realizar las
pruebas y posteriormente permitir el refactoring.
 Todo el trabajo no se tendría que empezar desde cero, puesto que el equipo contaba con código de otros trabajos
previos y que podrían reutilizar.
GRACIAS
GRUPO 6:
 ARGOMEDO RANGEL JIMENA
 CELIS ESPARZA DEINER
 REYES LÁZARO JOHEL
 RIVAS CRUZADO BRAYAN
 RODRÍGUEZ CHUP STEFANO
 SEGOVIA BENITES RICK
REFERENCIAS BIBLIOGRÁFICAS
 https://repositorio.unan.edu.ni/1365/1/62161.pdf
 https://formiik.com/publicacion/xp-programacion-extrema
 https://geekytheory.com/programacion-extrema-que-es-y-principios-basicos
 https://www.gestion.uco.es/gestion/aplicaciones/docs/NormasyEstandares.pdf
 https://www.indecopi.gob.pe/documents/20182/143803/GDA_CreadoresDeSoftware.pdf
 https://programacionextrema.tripod.com/fases.htm
 https://www.sinnaps.com/blog-gestion-proyectos/metodologia-xp
 http://ingenieriadesoftware.mex.tl/images/18149/PROGRAMACI%C3%93N%20EXTREMA.pdf
 https://iswugaps2extremeprogramming.wordpress.com/2015/09/14/caso-real-implementado-que-se-haya-
utilizadoimpacto/
SCRUM
INTEGRANTES:
 Asmat de la Cruz, Benjamín.
 Bravo Fustamante, Luis.
 Campuzano Guevara, Angélica.
 Dávila García, Diego.
 Huailla Chaupe, Carlos.
 Malaver Segura, Carlos.
 Moreno Varas, Diego.
¿Qué es SCRUM?
• Scrum es un marco de trabajo que define un conjunto de eventos, prácticas y
roles, y que puede tomarse como conjunto base para definir el proceso de
producción que usará un equipo de trabajo o dentro de un proyecto.
Principales Características de Scrum:
- Gestión regular de las expectativas del cliente, resultados anticipados,
flexibilidad y adaptación, retorno de inversión, mitigación de riesgos,
productividad y calidad, o, equipo motivado.
- Se hace uso de equipos autodirigidos y autoorganizados.
- Se realiza a diario una reunión de Scrum, que es una reunión de avance diaria
que no dura más de 15 minutos con el objetivo de obtener realimentación sobre
las tareas del equipo y los obstáculos que se presentan.
¿Porque Debemos
Utilizar Scrum?
Porque es un enfoque de gestión ágil que facilita la administración de proyectos, programas y
portafolios de cualquier tamaño y complejidad, facilitando
el flujo de información, la comunicación entre el equipo de trabajo y la entrega de valor con
oportunidad a los interesados de la organización.
Algunas de las principales ventajas de utilizar SCRUM son:
Adaptabilidad: Transparencia:
El control empírico de los procesos y las entregas continuas Todos las fuentes de información del proyecto tales como el
hacen que los proyectos sean adaptables y abiertos a la Scrumboard y el Sprint Burndown Chart son compartidos, lo que lleva a
incorporación del cambio. un ambiente de trabajo abierto.
Entrega Continúa de Valor
Los procesos iterativos permiten la entrega
continua de valor tan frecuentemente como el
cliente lo requiera. Lo que permite continuar por
el mismo camino o corregir el rumbo si fuera
necesario
Mejora Continua
Retroalimentación Continua Los entregables se mejoran progresivamente
A través de reuniones de seguimiento diario y Sprint por Sprint a través de un proceso de
reuniones para mostrar y validar los definición y priorización de entregables y sus
entregables, se proporciona retroalimentación características (Groom Prioritized Product
continua al cliente. (Conduct Daily Standup Backlog).
yDemonstrate and Validate Sprint).
Ritmo de trabajo sostenible
Los procesos Scrum están diseñados de tal
manera que las personas involucradas
pueden trabajar a un ritmo de trabajo
cómodo, (Sustainable Pace), y ayudan a que
este ritmo de trabajo continúe
indefinidamente.
Entrega Anticipada de Alto Valor Proceso de Desarrollo Eficiente

Scrum cuenta con procesos que aseguran que El definir periodos específicos de trabajo y
los requisitos de mayor valor al cliente sean los reducir al mínimo de trabajo que no es esencial
primeros en ser satisfechos. Este proceso se conduce a mayores niveles de eficiencia (Time
llama (Create Prioritized Product Backlog) Boxing).
Roles
Scrum
PRODUCT OWNER
• Toma las decisiones del cliente. Conoce perfectamente el negocio
• Por simplicidad, este tol es único
• Es propietario del producto backlog y decide prioridades
• Acepta o rechaza el sprint
SCRUM MASTER
• Aboga porque se respeten las reglas de scrum
• Es la conexión entre el producto owner y quipo
• Parte de su trabajo consiste en ayudar tanto a producto owner
como equipo
• También trabaja como uno más del equipo
SCRUM MASTER
• Revisión pila de producto
• Moderación de las reuniones
• Soluciona posibles problemas durante el sprint para garantizar su
desarrollo
• Gestión de grupo
EQUIPO
• Formado por las personas que desarrolla cada sprint
• >=3 & <=9 ( sin contar SM y PO)
• Equipo multifuncional
• El propio equipo se autoorganiza y coordina las tareas
EQUIPO
• Todos conocen la visión del PO
• Participan en la elaboración de la pila de producto
• Todos participan en las decisiones
• Se respetan opiniones de todos
• Todos conocen scrum
Artefactos
Scrum
PRODUCT BACKLOG
SPRINT BACKLOG
INCREMENTO
 Lista de requerimientos que se necesita
implementar en el producto.
 Cada ítem del Product Backlog se denomina PB.
 Nunca está completa, va modificándose según lo

hace el entorno.
Prioridad alta
 Es gestionado por el PRODUCT OWNER.
Ítems o elementos
 Se construye de mayor a menor con respecto a del backlog
los elementos que más valor aporten al producto.
 Si la lista no contiene elementos detallados, se

debe realizar un “refinamiento”. Prioridad baja
REFINAMIENTO  Proceso mediante el cual

agregamos detalle a los
elementos del Producto Backlog.
 Conjunto de elementos del Product Backlog
seleccionados para ser ejecutados durante el Sprint.
 Según se trabaja sobre el producto, aparece un nuevo

trabajo que el Equipo de Desarrollo va incorporando al
sprint backlog.
EQUIPO DE  Sus miembros son los únicos

DESARROLLO responsables de modificarlos o
eliminarlos.
 Es la suma de todos los elementos del Sprint Backlog
“Terminados” más los Incrementos de Sprints
anteriores.
Eventos en
Scrum
 Scrum es una de las metodologías más utilizadas en la creación ágil
de software.
 Para llevarla correctamente a cabo, Scrum cuenta con 5 eventos que
permiten llevar un registro y analizar el proceso de principio a fin.
EVENTO
S DEL
SCRUM
SPRINT DAILY SPRINT SPRINT

SPRINT PLANNING RETROSPECTIVE
SCRUM REVIEW
SPRINT PLANNING SCRUM REVIEW RETROSPECTIV
E
Un Sprint puede durar El objetivo es dar al cliente

entre 2 semanas y 2 un incremento del producto
meses, aunque lo habitual o entregable.
es 2 o 4 semanas.
El Sprint lo realiza el
Se entrega un incremento Equipo Scrum al completo,
del producto utilizable y y se añaden los
potencialmente liberable. takeholders en el resto de
eventos.
E
Se responden dos
Se estima que hay que invertir
dos horas por cada semana preguntas
que dure el sprint.
¿ Qué se va a construir ?
Reunión
estratégica
¿ Cómo se va a realizar?
Reunión táctica
E
ENTRADA PARTICIPANTES SALIDAS

S
Product Scrum Master

Product Owner Sprint
Backlog
Team Development Backlog
E
El objetivo es Ordenar e Permite resolver

informar al equipo sobre las impedimentos que
tareas realizadas y por tenga el Team
realizar. Development para
cumplir con el Sprint
Goal.
Su duración es de 15 Pueden participar

minutos y ayuda al también el Scrum
equipo a sincronizarse. Master y el Product
Owner.
E
El objetivo es compartir el
incremento realizado entre
Se realiza siempre al
todos los involucrados en el
Software y tomar las decisiones finalizar el Sprint.
oportunas.
El Product Backlog
Se planifica una hora por puede tener ajustes
cada semana del sprint, para enfocarse en
pero suele durar entre 2 y
nuevas
3 horas.
oportunidades.
SPRINT PLANNING SCRUM REVIEW RETROSPEC
TIVE
ENTRADA PARTICIPANTES SALIDAS

S
Feedback
Scrum Master
Incremento Product Owner
Producto Team Development
Stakeholders Product Backlog
E
En la retrospectiva se
analiza el último sprint y Como salida de este
se valoran mejoras para evento, el equipo
los siguientes. contará con un plan de
mejoras concreto.
Este evento dura entre 1 Pueden participar

y 3 horas dependiendo aparte del Team
de las semanas de Sprint. Development, el Scrum
Master y el Product
Owner.
Herramientas
Scrum
Características más destacadas:
 Tableros de Scrum personalizables.
 Informes de progreso en el desarrollo del
proyecto.
 Rastreador de errores y problemas.
 Filtros personalizados
 Gestión de usuarios.
 Registro del tiempo.
 Cuadro de mandos personalizable.
 Reportes en tiempo real
 Numerosas integraciones de aplicaciones de
terceros
 Gestión de recursos.
 Supervisa el progreso de las iniciativas clave en
tiempo real.
 Automatización de procesos para reducir los
errores.
 Acceso a una lista de pendientes para
capturar cada paso del trabajo en tu proyecto.
 Consulta las actividades en un calendario para
detectar huecos libres o superposiciones.
 División del trabajo en elementos gestionables.
 Sincronización de tareas en todos los
proyectos.
 Sistema de trabajo colaborativo.
 Asignación de tareas a cada uno de los miembros
del equipo de trabajo..
 Es posible personalizar la apariencia de cada uno
de los tableros que se tengan.
 Organizar tareas con etiquetas.
 Es posible aplicar fecha de vencimiento a las
tareas.
 Cuenta con un diseño minimalista, que gracias a
su simplicidad es muy intuitivo y fácil de usar.
 La información se encuentra sincronizada en la
nube.
Scrum en la ingeniería de
software
HISTORIA
 Ken Schwaber y Jeff Sutherland desarrollaron el
concepto de Scrum y su aplicabilidad al desarrollo de
software durante una presentación en la Conferencia
internacional sobre programación, lenguajes y
aplicaciones orientadas a objetos (llamada en inglés
Object-Oriented Programming, Systems, Languages &
Applications, o OOPSLA) en 1995 en Austin, Texas.
 Desde entonces, varios practicantes, expertos y
autores de Scrum han seguido perfeccionando la
conceptualización y metodología de Scrum. En los
últimos años, Scrum ha aumentado en popularidad, y
hoy en día es la metodología de desarrollo de
proyectos predilecta de muchas organizaciones a nivel
mundial
SCRUM Y SU RELACIÓN CON SOFTWARE
 Según la definición del IEEE, citada por [Lewis 1994] "software es la suma total de los programas de
computadora, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un
sistema de cómputo". Según el mismo autor, "un producto de software es un producto diseñado para un
usuario" En base a este concepto, la Ingeniería de Software es la rama de la ingeniería que provee un
enfoque sistemático disciplinado y cuantificable al desarrollo, operación y posterior mantenimiento del
software, con el fin de obtener un resultado final o producto que sea eficaz, eficiente y que pueda ser
pagado.
 Se realiza la adaptación de la metodología Scrum en el proyecto de grado debido a que ésta se realiza
como un marco del trabajo mediante la cual se puede asignar varios procesos y técnicas, éste modelo
está diseñado para ser flexible y adaptable a cualquier proyecto a corto y mediano plazo.
RECOMENDACIONES
 El mercado actual es altamente competitivo y cambiante. En ese contexto el desarrollo del software busca básicamente
rapidez, calidad y reducción de costos en la ejecución de sus proyectos; para asumir estos retos es necesario tener
agilidad y flexibilidad. Estas características se constituyen en el fundamento mismo de las metodologías ágiles de
desarrollo.
 En el ámbito de las metodologías de desarrollo de software existe un gran número de alternativas y los responsables
de cada proyecto tienen la difícil tarea de seleccionar la alternativa que mejor se ajuste a sus necesidades y recursos.
 La ejecución y culminación de un proyecto de software perite establecer una metodología basada en scrum,
complementada con otros métodos. El resultado es un producto de software funcional, en cuyo desarrollo se pudo
demostrar la validez de Scrum aplicado a los proyectos de software de mediano tamaño, en entornos cambiantes, con
grupos de trabajo pequeños que involucran permanentemente al dueño del producto.
CONCLUSIONES
 Es necesario aclarar que Scrum, más que una metodología de desarrollo de software, es un método de
gestión de proyectos, el cual puede adaptarse a cualquier tipo de proyecto y no únicamente a los de desarrollo
de software. Aplicada al desarrollo de software, está basado en el modelo de las metodologías ágile,
incrementales, basadas en iteraciones y revisiones continuas.
 El objetivo principal es elevar al máximo la productividad del equipo de desarrollo. Reduce el máximo de
actividades no orientadas a producir software funcional y produce resultados en periodos cortos de tiempo.
 Como método, enfatiza valores y prácticas de gestión, sin pronunciarse sobre requerimientos, prácticas de
desarrollo, implementación y demás cuestiones técnicas. Mas bien delega completamente al equipo la
responsabilidad de decidir la mejor manera de trabajar para ser lo más productivos posibles. Es esta
característica hizo que, durante la ejecución del proyecto se complementará la filosofía del método Scrum con
herramientas, métodos y procedimientos utilizados en otras metodologías, tanto ágiles como tradicionales.
BIBLIOGRAFÍA
 Cabsa. (23 de Octubre de 2020). Obtenido de https://www.cabsa.es/blog/5-eventos-scrum-y-sus-
claves
 Deloitte. (2020). Obtenido de
https://www2.deloitte.com/es/es/pages/technology/articles/ceremonias-scrum.html
 Diaz Ortiz, J., & Romero Suarez, M. (2017). Desarrollo e implementación de un aplicativo web,
utilizando la metodología Scrum, para mejorar el proceso de atención al cliente en la empreza Z
aditivos S.A. Lima.
 Florez Perez, H. E., & Ardila Puentes, D. N. (2014). Diseño e Implementación De un Sistema de
Información. Medellin.
 Muradas Y. (06 de agosto de 2020). Obtenido de https://openwebinars.net/blog/que-es-jira/
 Muradas Y. (27 de febrero de 2020). Obtenido de https://openwebinars.net/blog/que-es-asana/
 Requena A. (23 de diciembre de 2018). Obtenido de https://openwebinars.net/blog/trello-
herramienta-scrum/
 Saraclip. (31 de Octubre de 2017). Obtenido de https://www.saraclip.com/eventos-en-scrum/
 TFC. (s.f.). Gestión de proyectos Informáticos.
 Urteaga Pecharromán, A. (2015). Aplicación de la metodología de desarrollo ágil Scum para el
desarrollo de un sistema de gestión de empresas. Madrid.
GRUPO 8
ADMINISTRACIÓN DE
PROYECTOS DE SOFTWARE
INTEGRANTES:
Castañeda Ávila, Luis.
Gálvez Rodas, James.
Lázaro Rodriguez Joel.
Lozada Gaytán, Maricielo.
Martos Chávez Adriana.
Plasencia Tarrillo, Ronaldo.
Se enfoca en las cuatro P:
Personal - El gerente que olvida que el trabajo de
la ingeniería del software es una empresa
intensamente humana.
Producto - Un gerente que fracase en alentar una
comunicación comprensiva con los participantes
durante las primeras etapas de la evolución de un
producto se arriesga a construir una solución.
Proceso - El gerente que presta poca atención al
proceso corre el riesgo de insertar métodos y
herramientas técnicos competentes pero en el
vacío.
Proyecto - Aquel gerente que inicia el proyecto sin
un plan sólido poniendo en peligro el éxito.
01
PERSONA
L
Participantes Pueden organizarse en alguna de las siguientes áreas:
Gerentes ejecutivos: Definen temas empresariales que con frecuencia
1 tienen una influencia sobre el proyecto.
Gerentes de proyecto: Se encargan de planificar, motivar, organizar y

2 controlar a los profesionales que hacen el trabajo de software.
Profesionales: Aportan habilidades técnicas que se necesitan para

3 someter a ingeniería un producto.
4 Clientes: Especifican los requerimientos para el software que se va a

fabricar.
5 Usuarios finales: Interactúan con el software una vez que se libera para
su uso productivo.
Líderes de trabajo
La administración del proyecto es una actividad que implica mucho trato con la gente;
por esta razón, los profesionales competentes tienen con frecuencia pobre desempeño
como líderes de equipo.
Según Jerry Weinberg, los líderes de proyectos exitosos aplican un estilo de gestión de
resolución de problemas. Motivación
Organizació
n
Además, propone que para lograr un buen liderazgo se usa el modelo de MOI :
Ideas e Innovación
Caracteristicas:
– Habilidades administrativas
– Incentivos por logros
– Influencia y construcción de espíritu de equipo
Según Edgemon J. las características que definen a
un gerente de proyecto enfatiza cuatro rasgos
claves:
Comprensión de las
Confianza para asumir el señales verbales - no
control y permitir que el verbales, y reacción ante
personal técnica siga sus las necesidades.
instintos.
Resolución Identidad Influencia y

Logr
de Administrativ construcción
problemas a
o del equipo
Diagnóstico de los Recompensa de la

conflictos técnicos y iniciativa y el logro para
organizativos, y optimizar la
estructura una solución o productividad.
motiva a otros
profesionales para
desarrollarla.
El equipo de
software
La “mejor” estructura de
Depende:
equipo
0 Estilo administrativo de la
1 organización.
0 Número de personas que

2 formarán el equipo.
0 Niveles de habilidad del

3 equipo.
Factores de
Paradigmas
proyecto
Mantei organizacionales
·Dificultad del problema que se va a
Constantine
resolver.
1. Un paradigma cerrado.
•“Tamaño” del programa resultante en
líneas de código o puntos de función. 2. Un paradigma aleatorio.
•Tiempo que el equipo permanecerá 3. Un paradigma abierto.

unido (vida del equipo).
4. Un paradigma síncrono.
•Grado en el que puede dividirse en
módulos el problema.
•Calidad y confiabilidad requeridas

por el sistema que se va a construir.
• Rigidez de la fecha de entrega.
•Grado de sociabilidad
(comunicación) requerido para el
La meta central de una organización de
ingeniería de software es lograr un equipo
de alto rendimiento.
¿Qué se debe hacer para

lograr un equipo de alto ?
● rendimiento
Los miembros del equipo deben tenerse
confianza entre sí.
● La distribución de las habilidades debe ser
adecuada para el problema.
● Es posible que deba excluirse del equipo a los
inconformes.
DeMarco y Lister sostienen que los miembros de los equipos cuajados son significativamente
más productivos y más motivados que el promedio. Comparten una meta común, una cultura
común y en muchos casos un “sentido de élite” que los hace únicos
OJO No todos los equipos cuajan. De hecho, muchos equipos sufren de lo que Jackman llama
“toxicidad de equipo”. Por ello, se definen los
5 factores que “fomentan un ambiente de equipo

potencialmente tóxico”
1) Una atmósfera de trabajo frenético.
2) alta frustración que causa fricción entre los miembros del equipo.
3) Un proceso de software “fragmentado o pobremente coordinado”,
4) Una definición poco clara de los roles en el equipo de software.
5) Continua y repetida exposición al fracaso.
Equipos ágiles
Adopta la mayoría de Evita muchas de las Subraya la

las características de toxinas que crean competencia
los equipos de problemas individual (miembro
proyecto de software de equipo)
exitosos.
Ejemplo SCRUM
Los equipos ágiles
son autoorganizados Dan al equipo ágil significativa
autonomía para tomar las
decisiones administrativas y
técnicas del proyecto
necesarias para hacer que el
trabajo se cumpla.
Conflictos de coordinación y
comunicación
La escala de muchos esfuerzos de desarrollo es grande, lo que conduce a complejidad,
confusión y dificultades significativas en la coordinación de los miembros del equipo.
Para resolver estos problemas se debe establecer mecanismos para la comunicación formal
e informal entre los miembros del equipo y entre los distintos equipos.
Comunicación Comunicación
formal informal
Se consigue mediante Los miembros de un equipo de
“comunicación escrita, reuniones software comparten ideas sobre una
estructuradas y otros canales de base ad hoc, piden ayuda cuando
comunicación relativamente no surgen problemas e interactúan unos
interactivos e impersonales con otros diariamente.
02
PRODUCT
O
Al comienzo de un proyecto se requieren estimaciones
cuantitativas y un plan organizado, debido a ello el gerente
debe examinar el producto y lo más pronto posible
establecer y acotar el ámbito del producto.
Recuerda:
El ámbito del proyecto de
software no debe tener
Ámbito del Software ambigüedades y debe acotar
0 Contexto
el enunciado del ámbito .
1 0
¿Cómo encaja en un sistema, producto o contexto
empresarial más grande el software que se va a
construir y qué restricciones se imponen como
resultado del contexto? Objetivos de información
0 2 ¿Qué objetos de datos visibles para el

cliente se producen como salida del
software?.¿Qué objetos de datos se
requieren como entrada?
Función y
3 desempeño
¿Qué función realiza el software para
transformar los datos de entrada en
salida?
Descomposición del
problema
Se utiliza la
estrategia de dividir
un problema
complejo en . Las funciones del software,
Es una actividad problemas más descritas en el enunciado del
que se asienta en pequeños ámbito, se evalúan y refinan para
el centro del proporcionar más detalle antes
análisis de de comenzar la estimación.De la
requerimientos misma manera con los
principales objetos de contenido
del software
o datos
03
EL
PROCESO
Proceso de Software
Las actividades del marco conceptual que
caracterizan al proceso de software son aplicables
a todos los proyectos de software.
El equipo debe decidir qué modelo de proceso es

más adecuado para:
● los clientes que solicitaron el producto y el
personal que hará el trabajo
● las características del producto
● el entorno de proyecto donde trabaja el
equipo de software
Cuando se selecciona un modelo de proceso, el equipo define
entonces un plan de proyecto preliminar con base en el conjunto
de actividades del marco conceptual del proceso.
Fusión de producto y proceso
Cada función que se va a someter a ingeniería por parte del equipo
debe pasar a través del conjunto de actividades de marco conceptual
que defina la organización de software.
Comunicació Planificació Modelad

n n o
Planifi
cación
Construcció
Despliegue
n
45K
Descomposición del
Proceso
Un equipo de software debe

tener un grado significativo de
flexibilidad al elegir el modelo
de proceso de software que es
mejor para el proyecto y las
tareas de la ingeniería de
software que pueblen el modelo
de proceso una vez elegido
La descomposición del proceso comienza cuando el gerente de
proyecto pregunta
¿Cómo logramos esta actividad del marco

conceptual?
❏ Desarrollar lista de clarificación de conflictos.

❏ Reunirse con los participantes para abordar la clarificación de
conflictos.
❏ Desarrollar en conjunto un enunciado del ámbito.
❏ Revisar el enunciado del ámbito con todos los interesados.
❏ Modificar el enunciado del ámbito según se requiera
04
EL PROYECTO
¿Cuáles son las señales de que
un proyecto de software está en ?
peligro
● El personal del software no entiende las
necesidades del cliente.
● El ámbito del producto está pobremente
definido.
● Los cambios se gestionan pobremente.
● Cambia la tecnología elegida.
● Las necesidades empresariales cambian (o
están mal definidas).
¿Cuáles son las señales de que
un proyecto de software está en ?
peligro
● Las fechas límite son irreales.
● Los usuarios son resistentes.
● Pérdida de patrocinio (o nunca obtenido
adecuadamente).
● El equipo del proyecto carece de personal con
habilidades adecuadas.
● Los gerentes (y profesionales) evitan mejores
prácticas y lecciones aprendidas.
¿Cómo actúa un gerente para
evitar los problemas recién ?
0
Comenzar con el pie
anotados
1 derecho.
0
Mantener la cantidad de movimiento
2
0 Siga la pista al
3 progreso.
0
Tome decisiones
inteligente 4
0
Realice un análisis
5 postmortem.
05
EL PRINCIPIO
W5HH
¿Cómo se define las
características clave del
proyecto?
WHY WHAT WHEN WHO
¿Por qué se ¿Qué se hará? ¿Cuándo se hará? ¿Quién es
desarrollará el responsable de cada
sistema? función?
WHERE HOW HOW MUCH

¿Dónde se ¿Cómo se hará el ¿Cuánto se
ubicarán en la trabajo? necesita de cada
organización? recurso?
La administración de proyectos de
0
1
software es una actividad sombrilla Conclusiones
dentro de la ingeniería de software.
Cuatro P tienen influencia sustancial

0
sobre la administración del proyecto
2 de software: personal, producto,
proceso y proyecto
0 El elemento esencial en todos los
3 proyectos de software es el
personal.
La actividad de administración
0 del proyecto abarca medición y
4 métricas, estimación y
calendarización, análisis de
riesgos, rastreo y control
Bibliografía
Roger S. Pressman, Ph.D.(2002).Ingenieria del
Software. Un enfoque práctico. Séptima
Edición. Publicado por McGraw-Hill, a business
unit of The McGraw-Hill Companies, Inc.
Thanks!
CREDITS: This presentation template was created by Slidesgo,
including icons by Flaticon, infographics & images by Freepik
and illustrations by Stories
"Año del Bicentenario del Perú: 200 años de Independencia"
UNIVERSIDAD NACIONAL UNIVERSIDAD NACIONAL DE TRUJILLO
DE TRUJILLO
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA INDUSTRIAL
CICLO:
IX
SECCIÓN:
“B”
GRUPO: 9
DOCENTE:
Díaz Amaya Lourdes Roxana
¿QUÉ ES LA PROGRAMACIÓN EXTREMA XP?
• Es una metodología ágil y flexible

utilizada para la gestión de
proyectos.
• Se centra en potenciar las

relaciones interpersonales del
equipo de desarrollo como clave
del éxito mediante el trabajo en
equipo, el aprendizaje continuo y el
buen clima de trabajo.
ACERCA DE XP
• La programación extrema usa un
enfoque orientado a objetos como
paradigma preferido de desarrollo, y
engloba un conjunto de reglas y
prácticas que ocurren en el
contexto de cuatro actividades
estructurales: Planeación, diseño,
codificación y pruebas.
• XP inicia cerca de 1980 escrito por
Kent Beck y es la variante más
utilizada en el mundo ágil, existen
otras como IXP llamada XP
Industrial orientado para
organizaciones grandes.
OBJETIVOS DE XP
La Satisfacción Potenciar el Costo, tiempo,

del Cliente trabajo en grupo calidad y alcance
CARACTERÍSTICAS DE LA PROGRAMACIÓN EXTREMA
1. Metodología basada en prueba y error, para obtener

un software que funcione realmente.
2. Fundamentada en principios.
3. Está orientada hacia quien produce y usa software,
el cliente participa activamente.
4. Reduce el costo del cambio en todas las etapas del
ciclo de vida del sistema.
5. Cambia las que han demostrado ser las mejores
prácticas para desarrollar software y las lleva al
extremo.
6. Cliente bien definido.
7. Los requisitos pueden cambiar.
8. Grupo pequeño y muy integrado de 2 a 12 personas.
9. Equipo con formación elevada y con capacidad de
aprender.
VALORES DE LA PROGRAMACIÓN EXTREMA
• LA COMUNICACIÓN: La XP ayuda mediante
sus practicas a la comunicación entre los
integrantes del grupo de trabajo, jefe del
proyecto, clientes y desarrolladores.
• SENCILLEZ: Los programas deben ser los más
sencillos posibles y tener la funcionalidad
necesaria que se indican en los requisitos, no
hay que añadir algo que no se necesita hoy.
• RETROALIMENTACIÓN: Las pruebas que se le
realizan al software nos mantienen
informados del grado de fiabilidad del
sistema.
• VALENTÍA: Asumir retos, ser valientes ante los
problemas y afrontarlos e intentar mejorar
algo que ya funciona, aunque gracias a las
pruebas unitarias no existe el riesgo de
malograr algo.
• RESPETO: Los miembros del equipo respetan
el trabajo del resto no siendo menos a otros.
PLANEACIÓN
• También llamada juego de
planeación (empieza escuchando).
• Se da la creación de historia de
usuario.
• Historia es escrita por el cliente y se
ubica en una tarjeta indizada con un
valor.
• El equipo evalúa las historias y le
asignan un costo (tiempo).
• Las historias muy costosas deben ser
descompuestas.
• Entre usuarios y el equipo agrupan las
historias de la siguiente entrega
compromiso.
• Luego de la primera entrega se
puede calcular la velocidad del
proyecto.
DISEÑO
• Sigue rigurosamente el principio MS,
mantenerse sencillo.
• Un diseño sencillo por sobre una
representación más compleja.
• Guía la implementación de una
historia, no el diseño funcional.
• Tarjetas CRC: (Clase, responsabilidad,
colaborador) Software orientado a
objetos.
• Historias de usuario con diseños
difíciles = prototipo operativo solución
en punta.
• Rediseño: Proceso mediante el cual
se cambia un sistema de software en
forma tal que no se altere el
comportamiento externo del código,
pero si mejore la estructura externa.
CODIFICACIÓN
• No se inicia directo con la
codificación sino a pruebas unitarias.
• Programación orientada a pruebas.
• La prueba garantiza
retroalimentación inmediata.
• Programación por parejas: dos
personas trabajen juntas en una
estación de trabajo con el objeto de
crear código para una historia.
• A medida que las parejas de
programadores terminen su trabajo,
el código que desarrollan se integra
con el trabajo de los demás,
integración continua.
PRUEBAS
• Creación de pruebas unitarias antes
de que comience la codificación.
• Pruebas con estructura que permita
automatizarlas (de modo que
pueden ejecutarse en repetidas
veces y con facilidad) estrategia de
pruebas de regresión.
• A medida que se organizan las
pruebas unitarias individuales en un
“grupo de prueba universal” las
pruebas de integración y validación
del sistema pueden efectuarse a
diario.
• Las pruebas de aceptación XP,
también llamadas pruebas del
cliente, son especificadas por el
cliente y se centran en las
características y funcionalidades
generales del sistema que son visibles
y revisables por parte del cliente.
ACTORES Y RESPONSABILIDADES DE XP
1. Programador (Programmer)
• Responsable de decisiones
técnicas.
• Responsable de construir el
sistema.
• Sin distinción entre analistas,
diseñadores o codificadores.
• En XP, los programadores
diseñan, programan y realizan las
pruebas.
2. Cliente (Customer)
• Es parte del equipo.
• Determina qué construir y

cuando.
• Escribe test funcionales para

determinar cuándo está
completo un determinado
aspecto.
3. Entrenador (Coach)
• Es el líder del equipo, toma las

decisiones importantes.
• Principal responsable del

proceso.
• Tiende a estar en un segundo

plano a medida que el
equipo madura.
4. Rastreador (Tracker)
• Es el hombre métrico.
• Observa sin molestar.
• Conserva datos históricos.

5. Probador (Tester)
• Ayuda al cliente con las

pruebas funcionales.
• Se asegura de que los test

funcionales se ejecuten.
ACTIVIDADES DE XP
1. Codificar 2. Hacer pruebas
3. Escuchar 4. Diseñar
PRÁCTICAS BÁSICAS DE XP
1.El Juego de la Planificación

(Planning Game):
El objetivo del juego es

maximizar el valor del software
producido. La estrategia es
poner en producción las
características más importantes
lo antes posible.
2. Versiones Pequeñas
(Short Releases):
Un sistema simple se pone
rápidamente en acción .
Periódicamente, se producen
nuevas versiones agregando
en cada iteración aquellas
funciones consideradas
valiosas para el cliente.
3. Metáfora del Sistema
(Metaphor):
Cada proyecto es guiado
por una historia simple de
como funciona el sistema en
general. Reemplaza a la
arquitectura y debe estar en
lenguaje común, entendible
para todos.
4. Diseño Simple (Simple
Design):
El sistema se diseña con la

máxima simplicidad posible,
no se implementan
características que no son
necesarias. Con esta técnica,
las clases descubiertas
durante el análisis pueden ser
filtradas.
5. Pruebas continuas (Testing):
Los casos de prueba se

escriben antes que el código.
Los desarrolladores escriben

pruebas unitarias y los
clientes especifican pruebas
funcionales.
6. Refactorización (Refactoring):
Es posible reestructurar el
sistema sin cambiar su
comportamiento, por ejemplo,
eliminando código duplicado,
simplificando funciones,
mejorando el código
constantemente.
7. Programación por Parejas
(Pair Programming):
El código es escrito por dos
personas trabajando en el
mismo computador.
“Una máquina, con un

teclado y un mouse”.
8. Posesión colectiva del Código
(Collective Code Ownership):
Nadie es dueño de un módulo,
cualquier programador puede
cambiar cualquier parte del
sistema en cualquier momento.
Siempre se utilizan estándares y

se excluyen los comentarios.
9. Integración Continua
(Continuous Integration):
Todos los casos de prueba se
deben pasar antes y después
de la integración.
Se dispone de una maquina

para la integración y se
realizan test funcionales en
donde participa el cliente.
10.Semana Laboral de 40 horas
(40-Hour Week):
Cada trabajador trabaja no

más de 40 horas por
semana. Si fuera necesario
hacer horas extra, esto no
debería hacerse dos
semanas consecutivas.
11.Cliente en el sitio
(On Site Customer):
El equipo de desarrollo tiene

acceso todo el tiempo al
cliente, el cual esta disponible
para responder preguntas, fijar
prioridades, etc.
“Lo ideal es un Cliente Analista”.

12.Estándares de Codificación
(Coding Standard):
Todo el código debe estar

escrito de acuerdo a un
estándar de codificación.
VENTAJAS Y DESVENTAJAS DE XP
VENTAJAS DESVENTAJAS
• Fomenta la comunicación entre • Dificultad para documentar.
los clientes y los trabajadores.
• Es recomendable emplearlo solo
• Permite ahorrar mucho tiempo y, en proyectos a corto plazo y
por lo tanto, dinero. simples.
• Mejora continua de los procesos • Fuerte dependencia de las

y el equipo de desarrollo. personas.
• Posibles “roces” con el cliente.

EJEMPLO (ESCENIFICACIÓN)
https://www.youtube.com/watch?v=2IeZuifjlWs&t=650s
INTEGRANTES:
• ANTICONA RODRIGUEZ EDINSSON JOEL
• MENDOZA VÁSQUEZ ALEXIS ADAN
• ORBEGOSO VARE DIEGO ALEXIS
• RAMOS VELASQUEZ ANGHELO PEDRITO
• SARACHAGA GRADOS ANGEL LEDWIN
• TORRES CORNELIO RONY ALEXIS
• URCIA LUJAN RANDOLPH MACKYVER

GRACIAS
• https://geekytheory.com/programacion-extrema-que-es-y-principios-basicos
• https://www.diegocalvo.es/metodologia-xp-programacion-extrema-metodologia-agil/
• https://www.sinnaps.com/blog-gestion-proyectos/metodologia-xp
• https://www.youtube.com/watch?v=tCl33R9jHBk
• https://www.youtube.com/watch?v=TY9KYW4UQPs
• https://formiik.com/publicacion/xp-programacion-extrema

PPTS de Ing Software

Cargado por

Copyright:

Formatos disponibles

PPTS de Ing Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PPTS de Ing Software

Cargado por

Copyright:

Formatos disponibles

INTRODUCCIÓN A LA

Ing. Lourdes Roxana Díaz Amaya

La Ingeniería del Software se podría definir como el establecimiento

La Ingeniería de Software es un proceso multicapa, formado

Define un marco de Trabajo para el

Indica como construir teóricamente

Es el software que se utiliza para

Es un marco de desarrollo, donde se definen un numero determinado

El proceso de desarrollo de software "es aquel en que las necesidades del

Comprende las cuatro P’s

El Proceso debe de adaptarse al personal y al

Debe definirse los objetivos y

Proceso de Desarrollo Lenguaje de

✓ No cumple con los procedimientos del Negocio

Sector de las Tecnologías de Información cada vez cobra

✓ Países latinoamericanos han tomado la iniciativa de apoyar sus

Año Ventas Incremento Exportación

• Las principales limitaciones para el desarrollo del sector son:

¡ Es necesario implementar políticas de fomento para el sector

• Programa BID de apoyo a la industria de software: Sostenibilidad de la

✓ Comprender los conceptos principales relacionados con el proceso

✓ Conocer los procesos, métodos y modelos que se aplican

✓ Conocer los principales ciclos de vida del software.

La aplicación de un enfoque sistemático, disciplinado y

Cualquier disciplina de ingeniería (incluida la ingeniería del software)

Qué es un proceso de Software?

Es un conjunto estructurado de actividades para:

Tiene Sub Tiene Salida Tiene Sub

Actividad Tiene Intermedio Producto/

Stakeholder Utiliza Herramienta

Tipos de Elementos para representar un proceso de Software

El proceso de Ingeniería de Software se basa en modelos, métodos y

Diseño del Software

Se puede hacer uso de este modelo cuando se presenten las siguientes

Diseño del Software

Cuando hay una necesidad imperiosa de producir de manera rápida un conjunto

➢ El modelo incremental combina elementos del modelo en cascada aplicado en

Descripción Desarrollo/ Versiones

Conlleva el refinamiento sucesivo de una arquitectura OO, por el cual se aplica la

Simulaciones, modelos y benchmarks

Tecnología orientado a objetos

Ing. Lourdes Roxana Díaz Amaya

La “Orientación a objetos” es la más importante tecnología que se ha difundido

Métodos: Especifican la forma que se controlan las propiedades de un

Atributos + Métodos = Objeto

marcaJugo 3.15 + 8.7i marcaGaseosa

En el mundo real un objeto es cualquier cosa que exista en el universo

La superclase Persona hereda a la Subclase estudiante, atributos como Nombre,

Instancia: Es la mínima expresión de un Objeto

Polimorfismo : Los métodos son distintos pero tienen el mismo efecto.

Evento : Es algún suceso que puede causar un cambio de estado a un objeto.

La historia de Scrum se puede Durante sus investigaciones. se

Jeff Sutherlond y Ken

01 Investigar e identiﬁcar mercados

02 Desarrollo de mejoras a productos ya

Desarrollo de productos que requieren

Desarrollo y mantenimiento en la Nube y

Gestionar los riesgos globales

Presentar informes del proyecto al