¿Qué es el software?

El software es más que programas, es más, mucho más que eso y esa característica será una de
las que más impacte en la conformación y ejecución de un proyecto de software.

Hay una característica de él que debe atenderse: el hecho que es un sistema.

El software es un conjunto de partes interrelacionadas que alcanzan algún objetivo.

El software

 "La programación no se trata solo de código, sino de crear soluciones a los problemas."
- Kathy Sierra
 "Programar es la única profesión donde puedes empezar con nada y llegar a construir
algo que cambie el mundo." - Sal Khan
 "La programación es un arte, porque es la expresión creativa de una idea a través de la
tecnología." - Scott Hanselman

El software es tanto un producto como conocimiento.

¿Qué hace único al software?

 Es intangible → dificulta su control y medición

 Posee un alto contenido intelectual → necesita personal capacitado
 Su proceso de desarrollo es mano de obra intensivo, basado en equipos y por
proyectos → multiplica el problema de la comunicación, un aspecto clave de los
proyectos
 No hay separación entre I+D y producción
 Potencialmente, es modificable hasta el infinito

Visiones del software

Técnica: código

Filosófica: conocimiento

Sistémica: conjunto de partes interrelacionadas con un objetivo en común

Ingeniería de Software

Su producción es humano-intensiva: requiere más ingeniería que manufactura. El proceso de

producción de software se vincula más con el diseño e implementación que con la
manufactura.

En la ingeniería clásica el ingeniero dispone de herramientas para describir el producto que

son distintas del producto, no es así en la Ingeniería Software.

Cualidades (deseables) del software

 Corrección funcional: se comporta de acuerdo a las especificación de requerimientos

funcionales.
  Confiabilidad: el usuario puede depender del software
 Robustez: se comporta "razonablemente", incluso en circunstancias no previstas en la
especificación de requerimientos
 Performance: uso económico de los recursos de computación (en Ingeniería Software
se la identifica con eficiencia)
 "Amistosidad": fácil uso por los seres humanos
 Verificabilidad: sus propiedades pueden verificarse fácilmente
 Mantenibilidad: puede repararse y evolucionar
 Reusabilidad: utilizar componentes sin modificarlas en otros sistemas
 Portabilidad: puede correr en distintos ambientes
 Comprensibilidad: facilidad de ser entendidos por los usuarios (desarrolladores)
 Interoperabilidad: capacidad de coexistir y cooperar con otros sistemas
 Productividad: mide la eficiencia del proceso de producción de software
 Oportunidad: capacidad de liberar un producto en tiempo
 Visibilidad: sus pasos previos y estado actual están correctamente documentados

Productos de Software

Productos genéricos: Productos que son producidos por una organización para ser vendidos al
mercado.

Productos hechos a medida: Sistemas que son desarrollados bajo pedido a un desarrollador
específico.

Proceso de software

Conjunto estructurado de actividades requeridas para desarrollar un sistema de software.

 Especificación
 Diseño
 Validación
 Evolución

Las actividades varían dependiendo de la organización y del tipo de sistema a desarrollar.

Características del proceso

 Definido: ¿Se encuentra el proceso bien definido y es comprensible?

 Visible: ¿El proceso es visible?
 Asistido: ¿Puede el proceso ser soportado por herramientas CASE?
 Aceptable: ¿El proceso es aceptado por el personal involucrado?
 Confiable: ¿Los errores del proceso son descubiertos antes de que se conviertan en
errores del producto?
 Robusto: ¿Puede continuar el proceso a pesar de problemas inesperados?
 Mantenible: ¿Puede el proceso evolucionar para cumplir con los objetivos
organizacionales?
 Ágil: ¿Qué tan rápido puede producirse el sistema?
Modelo del proceso

Un modelo de procesos es una expresión abstracta de los procesos principales de una

organización o proyecto. El Modelo de Procesos solamente muestra los procesos principales o
macro procesos que a su vez pueden contener otros procesos.

Modelo del proceso

 Especificación: establecer los requerimientos y restricciones del sistema.

 Diseño: modelar la solución.
 Construcción: desarrollar el sistema.
 Prueba: verificar y validar que el sistema cumpla con las especificaciones requeridas.
 Instalación: entregar el sistema al usuario y asegurar su funcionamiento.
 Mantenimiento: ¿reparar fallos en el sistema cuando sea descubiertos?

Problemas del modelo del proceso

Normalmente, las especificaciones son incompletas o anómalas.

No existe una distinción precisa entre la especificación, el diseño y la construcción.

No se puede probar el sistema hasta que se haya producido.

Falta de flexibilidad ante cambios o situaciones imprevistas.

El software no se puede reemplazar (o modificar) siempre durante el mantenimiento.

Modelos genéricos de desarrollo de software

Modelo de Cascada: Separa en distintas fases la especificación y el desarrollo.

Desarrollo Evolutivo: La especificación y el desarrollo están intercalados.

Prototipado: Un modelo sirve de prototipo para la construcción del sistema final.

Prototipado exploratorio

El objetivo es trabajar con clientes hasta evolucionar a un sistema final, a partir de una
especificación inicial. Se debe comenzar con unas especificaciones bien entendidas.

Prototipado de “throw-away”.

El objetivo es entender los requerimientos del sistema. Se puede comenzar con

especificaciones poco entendidas.

Riesgos de los modelos

Cascada

Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseño.

La dificultad en este modelo reside, en realizar cambios entre etapas.

Bajo riesgo para desarrollos bien comprendidos utilizando tecnología conocida.

Evolutivo

Alto riesgo debido a la necesidad de tecnología avanzada y habilidades del grupo

desarrollador.

Prototipado

Bajo riesgo para nuevas aplicaciones debido a que las especificaciones y el diseño se llevan a
cabo paso a paso.

Alto riesgo debido a falta de visibilidad.

Problemas del Modelo de Espiral

El desarrollo contractual específica el modelo del proceso y los resultados a entregar por
adelantado.

Resulta difícil convencer a clientes de que el enfoque evolutivo es controlable.

No se aconseja utilizarlo en pequeños sistemas.

Requiere de experiencia en la identificación de riesgos.

Requiere refinamiento para uso generalizado.

Modelos híbridos

Los sistemas grandes están hechos usualmente de varios subsistemas.

No es necesario utilizar el mismo modelo de proceso para todos los subsistemas.

El prototipado es recomendado cuando existen especificaciones de alto riesgo.

El modelo de cascada es utilizado en desarrollos bien comprendidos.

Modelo en espiral

Planteamiento de Objetivos: Se identifican los objetivos específicos para cada fase del
proyecto.

Identificación y reducción de riesgos: Los riesgos clave se identifican y analizan, y la

información sirve para minimizar los riesgos.

Desarrollo y Validación: Se elige un modelo apropiado para la siguiente fase del desarrollo.

Planeación: Se revisa el proyecto y se trazan planes para la siguiente ronda del espiral.

Qué es SCRUM

Metodología ágil para desarrollar productos y servicios innovadores

Dónde se aplica?

 Grandes empresas
 Medianas empresas
 Pequeñas empresas
 Proyectos personales
 Desarrollo de software
 Startups
 Proyectos complejos
 Servicios

Características de SCRUM

 Sistema de trabajo en serie

 Sistema de trabajo en paralelo
 Ciclos cortos
 Enfocado en entrega de resultados
 Mejora constante
 Trabajo en equipo

Cascada vs. SCRUM

 Cascada
 Convencional
 Ampliamente utilizada
 Forma natural de trabajo
 Se trabaja por módulos (y de a uno)
 No toma en cuenta desvíos o regresiones
 Ante problemas fugas de tiempo y dinero
 Bloqueos por esperar a finalizar módulos antecesores
 Se asume que se tiene una idea completa y clara del proyecto

SCRUM

 Ciclos cortos (sprint)

 Módulos en paralelo
 Cada ciclo resulta en un producto (funcional)
 Cada ciclo es un proyecto viable
 Se adapta a incertidumbre y necesidades cambiantes del proyecto

¿Por qué utilizarlo?

 Eficiencia (se trabaja en paralelo)

 Obtiene lo mejor de cada miembro del equipo (no hay jerarquías)
 Los roles son intercambiables
 Aprovecha talento natural de cada miembro
 Favorece la mejora constante
  Adaptabilidad a cambios imprevistos (internos y externos)
 Maduración del producto (muchas veces no se conoce lo que se quiere entregar desde
un principio)
 Pensar que con scrum haré mis proyectos más rápidos
 Moda
 Pensar que la agilidad es solo del equipo y no de toda la organización
 Proyectos ya iniciados (en cascada)
 Miembros de equipos no convencidos/capacitados en la metodología
 Personal no capacitado en liderazgo/trabajo en equipo
 Falta de profesionalismo de los miembros
 Tener personal “multitasking” (no permitir enfocarse)

Roles

 Product Owner: responsable de aumentar al máximo el valor del producto durante el

trabajo del equipo.
 Scrum Master: Responsable de ayudar al equipo a comprender la teoría y la práctica
de Scrum. Aseguran que los eventos de Scrum se lleven a cabo y ayudan al equipo a
concentrarse en entregar valor y a eliminar los impedimentos.
 Equipo Scrum: auto organizados y multidisciplinarios.

Artefactos

 Product Backlog: Lista de tareas clave para el desarrollo de producto, del cual es
responsable el Product Owner, las actividades de Product Backlog están ordenadas
en función de otorgar el máximo valor al producto en desarrollo.
 Sprint Backlog: Es el listado de tareas del Product Backlog que se emplearán en un
Sprint.
 Incremento: Lista de actividades del Product Backlog que se entregaron en el
Sprint.

Ceremonias (eventos)

 Sprint Planning Meeting: El equipo y product owner prioriza las tareas

contenidas en el Product Backlog y define aquellas que entrarán en el próximo
sprint.
 Sprint: Son unidades de tiempo que empleamos para el cumplimiento de una
tarea.
 Daily Standup o daily meeting: Una vez definido el tiempo de trabajo es
obligatorio realizar una reunión diaria para coordinar las tareas del equipo.
 Entregables: Los entregables forman la parte final del proyecto en el que se
debe presentar los documentos según las exigencias del Product Owner.

Especificación de requerimientos de software

Funcionales: define una función del sistema de software o sus componentes. Una
función es descrita como un conjunto de entradas, comportamientos y salidas
(orientado al qué).

No funcionales: imponen restricciones en el diseño o la implementación, como,

por ejemplo, restricciones en el diseño o estándares de calidad (orientado al
cómo).

Smart especifico ,medible,alcanzable, relevante ,temporal

Cualidades (deseables) de la especificación de requisitos

Completa: Todos los requerimientos deben estar reflejados en ella y todas las
referencias deben estar definidas.

Consistente: Debe ser coherente con los propios requerimientos y también con
otros documentos de especificación.

Inequívoca: La redacción debe ser clara de modo que no se pueda malinterpretar.

Correcta: El software debe cumplir con los requisitos de la especificación.

Trazable: Se refiere a la posibilidad de verificar la historia, ubicación o aplicación

de un ítem a través de su identificación almacenada y documentada.

Priorizable: Los requisitos deben poder organizarse jerárquicamente según su

relevancia para el negocio y clasificándolos en esenciales, condicionales y
opcionales.

Modificable: Aunque todo requerimiento es modificable, se refiere a que debe ser

fácilmente modificable.

Verificable: Debe existir un método finito sin costo para poder probarlo.

Las dificultades esenciales del software

Existen dos tipos de dificultades en el software:

Esenciales: inherentes a su naturaleza.

Accidentales: las ofrece (actualmente) su producción pero no son inherentes al

software.

Dificultades esenciales

 Complejidad
 Conformidad (conformity)
 Modificabilidad
 Invisibilidad

Impactan en:
  Cómo entendemos lo que nos piden que hagamos
 Qué tenemos qué hacer
 La volatilidad de lo que nos piden
 La imposibilidad de visualizar el producto

Stakeholders

Individuos u organismos que ganan o pierden con algún cambio, son impactados positiva o
negativamente independientemente o no de su voluntad. Tienen interés en el resultado del
cambio.

1. Interesados en su construcción

Responsabilidad por el diseño y desarrollo

Incluye: project managers, diseñadores de software, expertos en comunicaciones

2. Interés financiero

Responsabilidad por la compra o la venta

Incluye: analista de negocios, gerente de ventas, comprador

3. Interesados en su introducción y operación

Responsabilidad por la implementación y el mantenimiento

Incluye: equipo de entrenamiento y soporte del usuario, ingenieros de instalación y

mantenimiento, gerentes usuarios

4. Interesados en su uso

Interés en utilizar el producto o servicio resultante

Incluye: gerentes usuarios, toda clase de usuarios (directos e indirectos)

Diferencias de los stakeholders

Stakeholder Motivación Área de

expertise

Desarrollo Equipo de Soportar los Conocimiento

entrenamiento y clientes actuales de los
soporte y generar ventas problemas del
futuras usuario

Diseñador de Producir un Técnicas de

software producto de alta diseño,
calidad y usar las habilidades
 últimas técnicas creativas

Reutilizar Conocimiento
software existente de sistemas
existentes

Analista de Producir la Análisis de

sistemas especificación de problemas
requerimientos en
tiempo

Gerente de Completar el Conocimiento

proyecto proyecto en costo de
y tiempo planeamiento
y ejecución

Representante Introducir el Conocimiento

del usuario cambio con la de la
mínima organización,
discontinuidad  y usuarios y
Negocio máximo beneficio tareas

Analista de Superar la Conocimiento

negocio/mercado competencia del mercado y
del negocio

 Analistas Usuarios

Definición funcional Definición cualitativa

Formulación precisa Requiere interpretación

Congelada Todos los

requerimientos deben
alcanzarse

Definición producida en el tiempo Definición sobre la

asignado para la fase marcha

Sistema implementado en tiempo y costo Impacto favorable del

sistema en los
presupuestos del área
Buen sistema Sistema que trabaje