Unidad 1

Unidad 1 – Introducción a la IS
Temario:
●
La evolución del software
●
Mitos del software
●
Ingeniería de software
●
Ingeniería de Software Asistida por Computadora
●
Modelado del proceso y del ciclo de vida
●
Modelos de proceso
Pasos para resolver un problema:

1. Identificar el problema
2. Definir y representar el problema
3. Explorar las posibles estrategias
4. Aplicar y mejorar las estrategias
5. Mirar atrás y evaluar los resultados
IS - Unidad 1 - Luis Nieto - 2022 2

●
Simplificación del proceso anterior:
1.Decidir qué hacer (cuál es el problema)
2.Decidir cómo hacerlo
3.Hacerlo
4.Probar el resultado
5.Usar el resultado

Resumiendo:
●
Se comienza con la afirmación de una necesidad
(qué)
●
Luego se convierte la necesidad en un diseño,
basado en los requisitos y en la experiencia (cómo)
●
Luego se analiza, simula y se realiza el diseño
(pruebas)
●
Cuantos más conocimientos se tengan para
comprobar el diseño, más confianza habrá en que
esté correcto

El software como artesanía

●
En los comienzos:
●
pocos métodos sistemáticos
●
ninguna planificación
●
el HW era muy importante
●
el mismo desarrollador lo utilizaba después
●
ninguna documentación
●
pocos métodos formales
●
la construcción de SW era impredecible y
dependiente del autor
●
Grandes cambios:
●
mejoras en el rendimiento del HW
●
grandes cambios de arquitecturas
●
aumentos de memoria y capacidad de
almacenamiento
●
gran variedad de opciones de E/S

●
1950 – 1965 aprox.
●
Orientación por lotes (batch)
●
Distribución limitada
●
SW a medida

●
1965 - 1975 aprox.
●
Sistemas multiusuario y en tiempo real
●
Sistemas de Bases de Datos (BD)
●
SW independiente del HW -> mantenimiento del
SW con versiones

●
1975-1985 aprox.
●
Sistemas distribuidos
●
HW de bajo costo (microprocesador)
●
Impacto en el consumo

●
1985-2000 aprox.
●
Sistemas personales potentes
●
Tecnologías OO
●
Redes de computadoras
●
Computación en paralelo

●
2000 - ?
●
Presencia de la Web
●
Reutilización de la información
●
Componentes SW reutilizables

Problemas persistentes en la evolución:

●
El SW no explota las posibilidades plenas del HW
●
El desarrollo de SW no acompaña la demanda
●
Sociedad dependiente del SW
●
SW no escalable ni mantenible debido a diseños
pobres y recursos inadecuados

●
Preguntas al día de hoy:
●
¿Por qué tarda tanto tiempo terminar un SW?
●
¿Por qué es tan caro el costo de desarrollo?
●
¿Por qué no se encuentran todos los errores?
●
¿Por qué es difícil medir el avance durante el
desarrollo?

Características del SW:

●
Cuando se construye HW el proceso creativo se
traduce en algo físico
●
El SW es una parte (lógica) de un sistema
●
Conclusión: el SW tiene sus propias características

●
El SW se desarrolla, no se fabrica
●
La construcción de HW y de SW depende de las
personas, pero la relación entre las mismas y el
trabajo realizado es muy diferente en ambos casos
(Brooks)

●
El SW no se "estropea", pero se deteriora
●
El HW presenta muchos fallos al principio de su
vida, los cuales se deben normalmente a defectos
del diseño o de la fabricación
●
Una vez corregidos los defectos, la tasa de fallos
disminuye durante un cierto tiempo, tras el cual el
HW empieza a desgastarse, incrementándose
nuevamente la tasa de fallos


●
El SW no se "estropea", pero se deteriora:
●
El SW no es susceptible a los males del entorno
que hacen que el HW se estropee
●
Los defectos no detectados hacen que el SW falle
al principio
●
Una vez corregidos (suponiendo que no aparecen
nuevos errores) la curva tendría que mostrar
pocos defectos en el tiempo


●
El SW no se "estropea", pero se deteriora:
●
Durante su vida, el SW sufre cambios
(mantenimiento)
●
Conforme se hacen los cambios, es muy probable
que se introduzcan nuevos defectos, haciendo que
la curva de fallos tenga picos
●
El SW se va deteriorando debido a los cambios


●
La mayoría del SW se construye a medida:
●
En el desarrollo de HW, la reutilización de
componentes es lo habitual:
– Se construye un esquema del circuito
– Se hace un análisis del circuito
– Se seleccionan los componentes digitales
– Se compran los componentes

●
La mayoría del SW se construye a medida:
●
En el desarrollo de SW la reutilización es
relativamente nueva:
– En los 60 las librerías reutilizaban algoritmos
bien definidos, pero con un dominio de
aplicación limitado
– Actualmente se agregaron también datos (los

componentes reutilizables encapsulan datos y
procesos)

Mitos del software
●
Los mitos del SW pueden clasificarse en las
siguientes categorías:
●
Gestión
●
Cliente
●
Desarrolladores

Mitos del software
Mito de gestión: "Se tiene un libro lleno de estándares

y procedimientos. ¿No es suficiente?"
●
¿Se usa el libro? ¿Lo conocen las personas?
●
¿Refleja prácticas modernas de desarrollo de SW?
●
¿Es completo?
●
¿Está diseñado para mejorar el tiempo de entrega
conservando calidad?
Mitos del software
Mito de gestión: “Se cuenta con las herramientas de

desarrollo más avanzadas: las máquinas más
modernas”
●
Se necesita algo más que el último HW para
desarrollar SW de calidad
●
Las herramientas CASE son más importantes que el
HW para conseguir buena calidad y productividad

Mitos del software
Mito de gestión: “Si falla la planificación, se puede

agregar más gente y adelantar el tiempo perdido”
●
El desarrollo de SW no es un proceso mecánico
●
Según Brooks: “agregar gente a un proyecto de SW
retrasado lo retrasa aún más”
●
La necesidad de aprender y comunicarse de la gente
reduce la cantidad de tiempo productivo

Mitos del software
Mito del cliente: “Una declaración general de los

objetivos es suficiente, pudiendo dejar los detalles para
más adelante”
●
Una mala definición inicial es la principal causa del
retrabajo en el SW
●
Es esencial una descripción formal y detallada del
ámbito de la información, funciones,
comportamiento, rendimiento, interfaces, criterios
de validación, etc

Mitos del software
Mito del cliente: “Los cambios en los requisitos se

pueden acomodar fácilmente porque el SW es flexible”
●
El impacto del cambio varía según el momento en
que se introduzca

Mitos del software

Mitos del software
Mito del desarrollador: “El trabajo termina cuando el

SW funciona y se entrega”
●
Entre el 60% y el 80% de todo el esfuerzo dedicado
al desarrollo se realiza después de la entrega al
cliente

Mitos del software
Mito del desarrollador: “La calidad se mide sobre el

SW en ejecución”
●
Durante todo el proyecto se puede aplicar un
mecanismo efectivo para garantizar la calidad del
SW: Revisión Técnica Formal
●
Las revisiones de SW son filtros de calidad más
efectivos que las pruebas

Mitos del software
Mito del desarrollador: “Lo único que se entrega es

el SW funcionando”
●
El SW es sólo una parte de una configuración que
incluye muchos elementos

●
Si se considera al SW formado sólo por programas:
●
Se asocia productividad con líneas de código por
unidad de tiempo (error más común)
●
Se tienen montañas de código que no se pueden
integrar a trabajar como un sistema, sistemas que
no satisfacen las necesidades de los usuarios , etc

●
El SW es más que programas: es parte de un sistema
P r o c e d im
ie n to s
D ocum en H ardw ar
to s e
S is te
E n tr a d S a lid a
a m a
B a se d e S o ftw a r e
D a to s
G e n te

●
El SW es:
●
Conocimiento sobre un área de aplicación
●
Colección de programas y datos necesarios para
convertir a una computadora (de propósito
general) en una máquina de propósito especial
diseñada para una aplicación particular
●
Información (documentación) producida durante el
desarrollo de un sistema

●
El SW incluye:
●
Programas
●
Diseños detallados
●
Diseños de arquitectura
●
Especificaciones
●
Requerimientos del sistema
●
Toda información relativa al desarrollo

●
Software (IEEE): parte de un sistema que se puede
codificar para ejecutarse en una computadora como
un conjunto de instrucciones. Incluye la
documentación asociada necesaria para comprender,
transformar y usar esa solución

●
¿Por qué el SW es único?
●
Es intangible
●
De un alto contenido intelectual
●
No se lo reconoce como un activo contable
●
Su proceso de desarrollo es mano de obra
intensivo y basado en equipos
●
Potencialmente modificable hasta el infinito

●
Cualidades del software:
●
Corrección funcional
●
Confiabilidad
●
Robustez
●
Rendimiento
●
Amigabilidad
●
Verificabilidad
●
Mantenibilidad
●
Reusabilidad

●
En ingeniería, el proceso de construcción de algo es:
●
Predecible
●
Controlado
●
Independiente del autor
●
La ingeniería de SW es una disciplina de la ingeniería
cuya meta es el desarrollo costeable de SW

●
Definición 1: la ingeniería de SW es una disciplina
de la ingeniería que comprende todos los aspectos
de la producción de SW desde las etapas iniciales de
la especificación del sistema hasta el mantenimiento
de éste después que se utiliza

●
Definición 2: la ingeniería de SW es el
establecimiento y uso de principios robustos de la
ingeniería a fin de obtener económicamente SW que
sea fiable y que funcione eficientemente sobre
máquinas reales

●
Definición 3 (IEEE): la ingeniería de SW es: (1) la
aplicación de un enfoque sistemático, disciplinado y
cuantificable hacia el desarrollo, operación y
mantenimiento de software. (2) el estudio de
enfoques relacionados con (1)

●
Definición 4: conjunto de métodos, herramientas y
procedimientos para obtener un producto SW de alta
calidad en forma productiva
●
Métodos: indican cómo construir el SW
●
Herramientas: proporcionan un enfoque
(semi)automático para el proceso y los métodos
●
Procedimientos: definen la secuencia en la que se
aplican los métodos, las entregas, los controles,
etc

Principios básicos de la IS:

●
Rigor y formalidad
●
Sin rigor es imposible reproducir el diseño, y difícil
mantener el sistema
●
La formalidad implica rigor (el grado más alto de
rigor es la formalidad)
●
La formalidad requiere lenguajes formales, y es
muy difícil trabajar con éstos

●
Separación de intereses
●
Permite tratar con aspectos individuales del
problema
●
Debe aplicarse a la IS para controlar su
complejidad


●
Modularidad
●
Un sistema complejo debe ser dividido en partes.
Permite aplicar el principio anterior en 2 fases:
– Los detalles de cada parte sin tomar en cuenta
las restantes (cohesión)
– Las relaciones entre partes sin tomar en cuenta

los detalles (acoplamiento)


●
Abstracción
●
Proceso a través del cual se observa lo
importante, y lo trivial se deja de lado


●
Anticipación al cambio (flexibilidad)
●
El SW sufre cambios permanentemente, con lo
cual se requiere de una visualización de su
evolución
●
Se debe realizar un esfuerzo especial en las fases
iniciales para anticipar cómo y dónde será
probable que se den los cambios


●
Generalidad (facilidad de generalizar)
●
Toda vez que se necesite resolver un problema,
hay que tratar de focalizar la atención en el
descubrimiento de un problema más general
●
La generalidad es una forma de anticiparse al
cambio


●
Incrementabilidad
●
Si se pueden agregar nuevas funcionalidades al
SW, el mismo está construido bajo el principio de
la incrementabilidad
●
Es importante la documentación en cada paso


●
Rastreabilidad (trazabilidad)
●
Es necesario conocer el porqué de una solución en
particular. Permite “navegar” el proceso de
desarrollo

●
El trabajo asociado a la IS se puede dividir en 3 fases
genéricas:
●
Definición
●
Desarrollo
●
Mantenimiento

●
La fase de definición se centra en el qué:
●
Para definir un sistema correcto se identifica:
●
la información a procesar
●
el rendimiento deseado
●
el comportamiento del sistema
●
las interfaces
●
las restricciones
●
los criterios de validación

●
En la definición tienen lugar 3 tareas principales:
●
Análisis del sistema
●
Planificación del proyecto de SW
●
Análisis de los requisitos

●
La fase de desarrollo se centra en el cómo:
●
Se define:
– cómo se diseñarán las estructuras de datos
– cómo se implementarán los detalles
procedimentales
– cómo se caracterizarán las interfaces
– cómo se traducirá el diseño en un lenguaje de
programación
– cómo se realizarán las pruebas

●
En el desarrollo tienen lugar 3 tareas principales:
●
Diseño del SW
●
Generación de código
●
Pruebas del SW

●
La fase de mantenimiento se centra en el cambio
que va asociado a la corrección de errores:
●
Razones por las que se producen cambios:
– Corrección
– Adaptación
– Mejora
– Prevención

●
Corrección: cambia el SW para corregir los defectos
●
Adaptación: cambia el SW para acomodarlo a los
cambios de su entorno externo
●
Mejora: lleva al SW más allá de sus requisitos
funcionales originales
●
Prevención: cambia el SW para que se pueda
corregir, adaptar y mejorar más fácilmente

●
La construcción de SW tiene 2 objetivos:
●
Dada una necesidad, pretende satisfacerla
mediante una solución tratable por computadora:
Problema -> Proceso SW -> SW
●
El mantenimiento del SW producido hasta el final
de su vida útil (modelo del iceberg)

●
Proceso Software: conjunto de actividades, y sus
resultados asociados, que comienza con la
identificación de una necesidad y concluye con el
retiro del SW que satisface dicha necesidad

●
La solución de un problema mediante IS es una
actividad de modelización:
●
Comienza con el desarrollo de modelos
conceptuales (no formales)
●
Convierte los modelos conceptuales en formales,
que son los productos implementados

●
Modelos conceptuales:
●
punto de vista de las personas
●
son descriptivos pero no operativos
●
Ejemplo: diagrama ER
●
Modelos formales:
●
punto de vista de las computadoras
●
son computables por la máquina
●
Ejemplo: modelo físico relacional

●
Estos 2 modelos trabajan a niveles distintos:
●
Modelo conceptual: a nivel del problema o
necesidad
●
Modelo formal: a nivel de la solución,
implementada sobre computadora

●
Planteada la construcción de SW como una actividad
de resolución de problemas, existe un proceso de
resolución que se corresponde con el proceso básico
de resolución de problemas:
●
Qué: Análisis y Especificación de Requisitos
●
Cómo: Diseño del sistema Software
●
Realización del cómo: Implementación
●
Luego el sistema se somete a Pruebas
●
Finalmente la solución debe ser usada (o
instalada o implantada)

●
Cuando las soluciones a los problemas no son
puntuales, sino que permanecen en el tiempo, al
proceso anterior se le debe agregar una última etapa
de Mantenimiento
●
De ahí la necesidad del segundo objetivo antes
mencionado

●
Proceso mínimo necesario para construir un sistema
SW:
●
1. Obtener los requisitos
●
2. Diseñar
●
3. Implementar
●
4. Realizar pruebas
●
5. Instalar
●
6. Mantener y ampliar

●
1. Obtener los requisitos
●
Incluye el análisis del problema y concluye con
una especificación completa del comportamiento
externo que debería tener el sistema a construir

●
2. Diseñar
●
Alto nivel: se descompone el sistema SW en sus
componentes principales, éstos a su vez en
componentes más pequeños hasta que los mismos
puedan ser tratados en el diseño detallado
●
Bajo nivel: se definen y documentan los
algoritmos que llevarán a cabo la función a
realizar por cada módulo

●
3. Implementar
●
Consiste en transformar los algoritmos definidos
durante el diseño de bajo nivel en un lenguaje
comprensible para una computadora

●
4. Realizar pruebas
●
Pruebas unitarias: comprueban cada módulo
implementado en busca de errores
●
Pruebas de integración: conectan grupos de
módulos asegurándose que el todo se comporta
correctamente
●
Pruebas del sistema: pretenden asegurar que la
totalidad del sistema se comporte de acuerdo con
la especificación de requisitos
5. Instalar
●
Tras las pruebas, el sistema SW y su entorno HW
pasan a la fase operativa
6. Mantener y ampliar
●
Incluye la detección continua de errores y su
reparación (mantenimiento correctivo) y la
ampliación (mantenimiento perfectivo)

●
Se selecciona un modelo de proceso según:
●
la naturaleza del proyecto y de la aplicación
●
los métodos y las herramientas a utilizarse
●
los controles y entregas que se requieren
●
el conocimiento de los miembros del equipo

Modelos de proceso
●
Modelo Cascada
●
Sugiere un enfoque secuencial para el desarrollo
de SW

Modelos de proceso
●
Desventajas del modelo cascada:
●
No admite tomar decisiones que den lugar a
diferentes alternativas
●
Requiere que el cliente exponga explícitamente
todos los requisitos (congelamiento)
●
Tiene dificultades a la hora de acomodar la
incertidumbre natural al comienzo
●
El cliente debe tener paciencia

Modelos de proceso
●
Ventajas del modelo cascada:
●
Las etapas están organizadas de un modo lógico
●
Proporciona una plantilla en la que se encuentran
métodos para análisis, diseño, codificación,
pruebas y mantenimiento

Modelos de proceso
●
Modelos de construcción de prototipos
●
Prototipo: sistema a escala que tiene menos
características que el sistema real
●
Este modelo tiene como objetivo contrarrestar las
limitaciones del modelo en cascada:
– La idea básica es que el prototipo ayude a
comprender los requerimientos del usuario

Modelos de proceso
●
Características:
●
Permite construir rápidamente versiones
primitivas a evaluar por los usuarios
●
Las evaluaciones del usuario realimentan el
proceso para refinar el diseño y especificación
●
El sistema completo puede desarrollarse a través
de un proceso continuo de revisión y refinamiento
●
Siempre se tiene una versión del sistema
trabajando

Modelos de proceso

Modelos de proceso
●
Modificación del ciclo de vida en cascada:
●
Análisis preliminar y especificación de
requisitos
– Se hace un primer análisis de las necesidades
del usuario, especificaciones generales del
sistema y estudio de viabilidad

Modelos de proceso
●
●
Diseño, desarrollo e implantación del
prototipo
– La implantación del prototipo debe ser rápida y
su costo de desarrollo bajo (poner énfasis en la
interfaz de usuario, desarrollar el prototipo con
un equipo chico, buscar las herramientas
adecuadas para un desarrollo rápido, etc)

Modelos de proceso
●
●
Prueba del prototipo
– Se deben extraer conclusiones de los usuarios
en el uso del prototipo (asignar el tiempo
suficiente para que los usuarios prueben el
prototipo e informen sus experiencias, etc)

Modelos de proceso
●
●
Refinamiento del prototipo
– Con la información proporcionada por los
usuarios, se modifica rápidamente el prototipo
para que pueda ser probado nuevamente por
los mismos
– Este refinamiento continúa hasta alcanzar un
estado donde los beneficios de mejorar más el
prototipo sean menores que el tiempo y el costo
requeridos para tales modificaciones

Modelos de proceso
●
●
Diseño e implantación del sistema de
producción
– Se puede seguir con el modelo de procesos
clásico, al cual se habrá aportado una gran
intuición acerca de cómo se debería desarrollar
el sistema real

Modelos de proceso
●
Existen distintos modelos de prototipos:
●
Prototipos desechables
– Ayudan al cliente a identificar los requisitos de
un nuevo sistema
– En el prototipo se implantan sólo aquellos
aspectos del sistema que se entienden mal o
son desconocidos
– TODOS los elementos del prototipo serán
posteriormente desechados

Modelos de proceso
●
Existen distintos modelos de prototipos:
●
Prototipos evolutivos
– Una vez definidos todos los requisitos,
evolucionarán hacia el sistema final
– Se implantan primero aquellos requisitos y

necesidades que son claramente entendidos

Modelos de proceso
●
Desventajas de los prototipos:
●
El cliente ve lo que "parece ser una versión de
trabajo", sin saber que con el apuro de hacer que
funcione no se ha tenido en cuenta la calidad
global o la facilidad de mantenimiento a largo
plazo

Modelos de proceso
●
Modelo incremental
●
Combina elementos del modelo cascada
(aplicados repetidamente) con la filosofía
interactiva de construcción de prototipos
●
Aplica secuencias lineales de forma escalonada
conforme avanza el tiempo
●
Cada secuencia lineal produce un "incremento" del
SW

Modelos de proceso
●
Modelo incremental
●
Este proceso se repite hasta que se elabora el
producto completo
●
Este modelo, al igual que la construcción de
prototipos, es iterativo, pero se centra en la
entrega de un producto operacional con cada
incremento

Modelos de proceso

Modelos de proceso
●
Modelo en espiral
●
Propuesto originalmente por Boehm en 1986, es
un modelo de proceso evolutivo que combina lo
iterativo de la construcción de prototipos con los
aspectos controlados y sistemáticos del modelo
cascada

Modelos de proceso

Modelos de proceso
●
Comunicación con el cliente
●
Establecer la comunicación entre el desarrollador
y el cliente
●
Planificación
●
Definir recursos, tiempo y otra información
relacionada con el proyecto
●
Análisis de riesgos
●
Evaluar riesgos técnicos y de gestión. Resulta en
una decisión de “seguir o no seguir”

Modelos de proceso
●
Ingeniería
●
Construir una o más representaciones de la
aplicación
●
Construcción y acción
●
Construir, probar, instalar y proporcionar soporte
al usuario
●
Evaluación del cliente
●
Obtener la reacción del cliente

Modelos de proceso
●
El modelo en espiral demanda una consideración
directa de los riesgos técnicos en todas las etapas
del proyecto, debiendo reducir los riesgos antes que
se conviertan en problemáticos

Modelos de proceso
●
Desventajas del modelo en espiral:
●
Resulta difícil convencer a grandes clientes que el
enfoque evolutivo es controlable
●
Requiere una considerable habilidad para la
evaluación del riesgo, y depende de ésta para el
éxito

Modelos de proceso
●
RUP (Rational Unified Process)
●
Enfocado en la producción de sistemas de calidad
de forma repetible y predecible
●
Es iterativo, está centrado en la arquitectura y es
guiado por los casos de uso
●
Define quién es responsable de qué, cómo se
hacen las cosas y cuándo

Modelos de proceso
●
Principios fundamentales de RUP:
●
Atacar los principales riesgos en forma temprana y
de manera continua
●
Mantener el foco en el SW ejecutable
●
Acomodarse a los cambios en el proyecto
●
Establecer una arquitectura en forma temprana
●
Construir el sistema con componentes
●
Que todos trabajen como un equipo

Modelos de proceso
●
El proceso tiene 2 dimensiones:
●
Tiempo (eje horizontal): representa el aspecto
dinámico del proceso a medida que el mismo se
desarrolla, y se expresa en términos de ciclos,
fases, iteraciones y metas
●
Disciplinas fundamentales del proceso (eje
vertical): representa el aspecto estático del
proceso: su descripción en términos de los
componentes del proceso, actividades, disciplinas,
artefactos y roles

Modelos de proceso

Modelos de proceso
●
Scrum
●
Modelo de proceso iterativo e incremental.
●
Reduce la burocracia y actividades no orientadas a
producir SW que funcione, y produce resultados en
períodos breves de tiempo por medio de
iteraciones o Sprints.

Modelos de proceso
●
Comienza con la visión general del producto,
especificando las funcionalidades más prioritarias
que pueden llevarse a cabo en un período de tiempo
breve
●
Cada uno de estos períodos de desarrollo es una
iteración que finaliza con la producción de un
incremento operativo del producto
●
Scrum gestiona la evolución de estas iteraciones
mediante reuniones diarias (scrums diarios) donde
todo el equipo revisa el trabajo realizado el día
anterior y el previsto para el día siguiente

Modelos de proceso
●
Scrum controla, de forma empírica y adaptable, la
evolución del proyecto empleando las siguientes
prácticas:
●
Revisión de las iteraciones
●
Desarrollo incremental
●
Desarrollo evolutivo
●
Autoorganización
●
Colaboración

Modelos de proceso
●
Revisión de las iteraciones
●
Al finalizar cada iteración (normalmente 30 días)
se lleva a cabo una revisión con todas las
personas implicadas en el proyecto
●
Este es el período máximo que se tarda en
reconducir una desviación en el proyecto

Modelos de proceso
●
Desarrollo incremental
●
Durante el proyecto, las personas implicadas no
trabajan con diseños o abstracciones
●
El desarrollo incremental implica que al final de
cada iteración se dispone de una parte del
producto operativa que se puede inspeccionar y
evaluar

Modelos de proceso
●
●
Los modelos ágiles se emplean para trabajar en
entornos de incertidumbre e inestabilidad de
requisitos
●
Intentar predecir en las fases iniciales cómo será
el producto final, y sobre dicha predicción
desarrollar el diseño y la arquitectura del producto
no es realista

Modelos de proceso
●
●
En Scrum se toma a la inestabilidad como una
premisa, y se adoptan técnicas de trabajo para
permitir esa evolución sin degradar la calidad de
la arquitectura que se irá generando durante el
desarrollo
●
Scrum va generando el diseño y la arquitectura
final de forma evolutiva durante todo el proyecto
(no es un desarrollo en fases)

Modelos de proceso
●
Autoorganización
●
Durante el desarrollo de un proyecto son muchos
los factores impredecibles que surgen en todas las
áreas y niveles
●
La gestión predictiva confía la responsabilidad de
su resolución al gestor de proyectos
●
En Scrum los equipos son autoorganizados (no
autodirigidos), con margen de decisión suficiente
para tomar las decisiones que consideren
oportunas

Modelos de proceso
●
Colaboración
●
Las prácticas ágiles facilitan la colaboración del
equipo, necesaria porque para que funcione la
autoorganización como un control eficaz, cada
miembro del equipo debe colaborar de forma
abierta con los demás, según sus capacidades y
no según su rol o puesto

Modelos de proceso
●
Scrum denomina “Sprint” a cada iteración de
desarrollo y recomienda realizarlas con duraciones
de 30 días
●
El sprint es, por lo tanto, el núcleo central que
proporciona la base de desarrollo iterativo e
incremental

Modelos de proceso

Modelos de proceso
●
Planificación de los Sprints
●
Es una jornada de trabajo previa al inicio de cada
sprint en la que se determina cuál va a ser el
trabajo y los objetivos que se deben cumplir en
esa iteración
●
La planificación del sprint es una reunión crítica,
probablemente la más importante de Scrum

Modelos de proceso
●
Planificación de los Sprints
●
El propósito de la planificación del Sprint es
proporcionar al equipo suficiente información
como para que puedan trabajar sin interrupciones
durante unas pocas semanas, y para ofrecerles a
los interesados en el producto la suficiente
confianza

Modelos de proceso
●
Una planificación de Sprint produce:
●
Un objetivo del Sprint
●
Una lista de miembros (y su nivel de dedicación, si
no es del 100%)
●
Una pila de Sprint (lista de historias incluidas en el
Sprint)
●
Una fecha concreta para la demo del Sprint
●
Un lugar y momento definidos para el Scrum diario

Modelos de proceso
●
Es muy importante que durante la planificación de
los Sprints, los interesados asistan conjuntamente
con el equipo de desarrollo, ya que cada historia
contiene 3 variables que son muy dependientes
entre sí:
●
Estimación
●
Alcance
●
Importancia

Modelos de proceso
●
Scrums diarios:
●
Son breves revisiones del equipo sobre el trabajo
realizado, donde se trata todo lo que se hizo el día
anterior y lo que se hará ese mismo día
●
Suelen durar 15-20 minutos
●
Se “actualiza el pizarrón con las cosas que se
fueron cumpliendo”

Modelos de proceso
●
Demo del Sprint:
●
Es un análisis y revisión del incremento generado:
– El equipo obtiene reconocimiento por sus logros
– Otras personas se enteran de lo que está
haciendo el equipo
– La demo consigue realimentación vital de los
interesados

Modelos de proceso
●
Pila de Producto (Product Backlog):
●
Lista de requisitos que se origina con la visión
inicial del producto y va creciendo y evolucionando
durante el desarrollo
●
Es, básicamente, una lista priorizada de requisitos
o funcionalidades (cosas que el cliente quiere,
descritas usando la terminología del cliente)
●
A estas “cosas” se las suele llamar historias o
elementos de la pila

Modelos de proceso
●
Las historias suelen incluir:
●
Un identificador
●
Un nombre
●
Importancia
●
Estimación inicial
●
Forma de probarla (descripción en alto nivel sobre
cómo se demostrará esta historia en la demo al
final del sprint)

Modelos de proceso
●
Pila de Sprint (Sprint Backlog)
●
Lista de los trabajos que debe realizar el equipo
durante el sprint para generar el incremento
previsto
●
Se registran los trabajos que están pendientes, los
que están en curso y los que están terminados

Modelos de proceso
●
Incremento
●
Son los resultados que se obtienen de cada Sprint

Modelos de proceso
●
Roles
●
Scrum clasifica a todas las personas que
intervienen o tienen interés en el desarrollo del
proyecto en 4 grupos:
– Propietario del producto
– Equipo
– Gestor de Scrum
– Otros interesados

Modelos de proceso
Conclusiones
●
No existe un único modelo de proceso
●
Un modelo de proceso SW debe:
●
Determinar el orden de las fases
●
Establecer los criterios de transición para pasar de
una fase a la siguiente

Modelos de proceso
●
Cada proyecto debe seleccionar el modelo de
proceso más adecuado en base a:
●
La cultura de la organización
●
El deseo de asumir riesgos
●
El área de aplicación
●
La volatilidad de los requisitos
●
La comprensibilidad de los requisitos
●
Experiencia del equipo de desarrollo

Modelos de proceso

Modelos de proceso
●
Sobre el equipo de desarrollo, interesa la calidad del
mismo, dada por:
●
Idoneidad técnica
●
Experiencia en la tecnología
●
Experiencia en el dominio específico

Modelos de proceso
●
La complejidad del problema está dada por:
●
El problema en sí mismo
●
Su comunicación (definición y comprensión)
●
El grado de volatilidad (tiempo que dura una
necesidad)

Modelos de proceso
●
Un proyecto sin estructura es un proyecto
inmanejable:
●
No puede ser planificado
●
No puede ser estimado
●
No puede alcanzar un compromiso de costos o
tiempos

Modelos de proceso
●
Muchos proyectos han terminado mal porque las
fases de desarrollo se han realizado en un orden
erróneo
●
Por lo tanto, al comienzo de un proyecto software, se
debe elegir el modelo de proceso que seguirá el
producto a construir

Modelos de proceso
●
Una vez conseguido un proceso software concreto
para el proyecto en cuestión, se está preparado para:
●
Planificar los plazos del proyecto
●
Asignar las personas a las distintas tareas
●
Presupuestar los costos del proyecto

Modelos de proceso
●
Selección de un modelo de proceso SW:
●
http://www.agiledata.org/essays/
differentStrategies.html
●
http://ecomputernotes.com/software-engineering/
criteria-for-selecting-software-process-models
●
https://melsatar.wordpress.com/2012/03/21/
choosing-the-right-software-development-life-
cycle-model/

Resumen
●
Evolución del software
●
Mitos del software
●
●
●
Modelos de proceso

Unidad 1

Cargado por

Información del documento

Descripción original:

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

Unidad 1

Cargado por

Copyright:

Formatos disponibles

Unidad 1 – Introducción a la IS

Pasos para resolver un problema:

IS - Unidad 1 - Luis Nieto - 2022 2

IS - Unidad 1 - Luis Nieto - 2022 3

IS - Unidad 1 - Luis Nieto - 2022 4

El software como artesanía

IS - Unidad 1 - Luis Nieto - 2022 6

IS - Unidad 1 - Luis Nieto - 2022 7

IS - Unidad 1 - Luis Nieto - 2022 8

IS - Unidad 1 - Luis Nieto - 2022 9

IS - Unidad 1 - Luis Nieto - 2022 10

IS - Unidad 1 - Luis Nieto - 2022 11

Problemas persistentes en la evolución:

IS - Unidad 1 - Luis Nieto - 2022 12

IS - Unidad 1 - Luis Nieto - 2022 13

Características del SW:

IS - Unidad 1 - Luis Nieto - 2022 14

IS - Unidad 1 - Luis Nieto - 2022 15

IS - Unidad 1 - Luis Nieto - 2022 16

IS - Unidad 1 - Luis Nieto - 2022 17

IS - Unidad 1 - Luis Nieto - 2022 18

IS - Unidad 1 - Luis Nieto - 2022 19

IS - Unidad 1 - Luis Nieto - 2022 20

IS - Unidad 1 - Luis Nieto - 2022 21

– Se hace un análisis del circuito

– Se seleccionan los componentes digitales

– Se compran los componentes

– Actualmente se agregaron también datos (los

IS - Unidad 1 - Luis Nieto - 2022 23

IS - Unidad 1 - Luis Nieto - 2022 24

Mito de gestión: "Se tiene un libro lleno de estándares

Mito de gestión: “Se cuenta con las herramientas de

IS - Unidad 1 - Luis Nieto - 2022 26

Mito de gestión: “Si falla la planificación, se puede

IS - Unidad 1 - Luis Nieto - 2022 27

Mito del cliente: “Una declaración general de los

IS - Unidad 1 - Luis Nieto - 2022 28

Mito del cliente: “Los cambios en los requisitos se

IS - Unidad 1 - Luis Nieto - 2022 29

IS - Unidad 1 - Luis Nieto - 2022 30

Mito del desarrollador: “El trabajo termina cuando el

IS - Unidad 1 - Luis Nieto - 2022 31

Mito del desarrollador: “La calidad se mide sobre el

IS - Unidad 1 - Luis Nieto - 2022 32

Mito del desarrollador: “Lo único que se entrega es

IS - Unidad 1 - Luis Nieto - 2022 33

IS - Unidad 1 - Luis Nieto - 2022 34

IS - Unidad 1 - Luis Nieto - 2022 35

IS - Unidad 1 - Luis Nieto - 2022 36

IS - Unidad 1 - Luis Nieto - 2022 37

IS - Unidad 1 - Luis Nieto - 2022 38

IS - Unidad 1 - Luis Nieto - 2022 39

IS - Unidad 1 - Luis Nieto - 2022 40

IS - Unidad 1 - Luis Nieto - 2022 41

IS - Unidad 1 - Luis Nieto - 2022 42

IS - Unidad 1 - Luis Nieto - 2022 43

IS - Unidad 1 - Luis Nieto - 2022 44

IS - Unidad 1 - Luis Nieto - 2022 45

Principios básicos de la IS:

Principios básicos de la IS:

IS - Unidad 1 - Luis Nieto - 2022 47

Principios básicos de la IS: