Ingeniería del Software II – 8/8

Software: lógica intangible que gestiona el hardware. Es modificable, pero hacer esto correctamente es difícil.

- Lógica: conjuntos de 1s y 0s. Representación de la realidad.

- Para el software no hay modelos matemáticos ni físicos, no hay forma de demostrar que esté completamente
perfecto.

Paso previo para desarrollar mediante código:

- Se basa en diagramas de clases de diseño

- Representación formal del conocimiento.

Modelo de análisis: (se basa en el Modelo de casos) se centra en utilizar herramientas y técnicas computacionales para
obtener conocimientos valiosos y tomar decisiones informadas a partir de datos.

- Utiliza herramientas computacionales y técnicas para obtener conocimientos a partir de datos.

- Objetivo: tomar decisiones informadas basadas en información valiosa.
- Proceso: recopilación, limpieza y preparación de datos.
- Aplica análisis estadístico, matemático y de aprendizaje automático.
- Descubre patrones, tendencias, relaciones y estructuras en los datos.
- Incluye análisis de texto y procesamiento de lenguaje natural.
- Facilita la toma de decisiones con insights significativos.
- Contribuye al desarrollo de inteligencia artificial y aprendizaje automático.

Código fuente:

- Se basa sobre otro modelo

- Otra forma de representar
- Modelo anterior (modelo de análisis)

Compilador:

- Es un programa.
- Si el compilador es imperfecto entonces el programa también lo es.

El modelo es un costo despreciable frente a la realidad.

- Evaluar alternativas es razonable.

- En el software hay menos tendencia a hacer alternativas.

Para vender un software se necesita:

- Un vínculo comercial.
- El cliente te juzga por lo que puede evaluar.
- Prestigio.
- Hay que venderse a uno mismo.
- Para deslumbrar al cliente hay que conocer sobre el área del cliente. (Marketing de uno, y su propio equipo.

Relación con el cliente:

- El cliente piensa que todo es posible y fácil de hacer.

- Solución: dejar de usar dimsminuir coloquialmente el trabajo

Jhon gaal: Systematica: La suma de los problemas es una cupla, No hay forma de disminuir el mismo.

Jessie:
 - 14 a 15 cualidades de software.
- Visto como producto.
- El software producto y otro como proeceso.
1. Conjunto de cualidades percibidas.
 Cualidades internas, las percibidas
 Cualidades externas, por el cliente
 Mixta: más importantes que las internas

Definiciones importantes:

- Corrección: relación entre la especificación y la funcionalidad, si la funcionalidad responde a la especificación,

entonces es correcto
- Robustez: efectividad y precisión en momentos inesperados.
- Confiabilidad: consistencia y precisión en diferentes situaciones.

Buenas prácticas:

- Código simple
- Objetos pequeños
- Acoples débiles
- Los objetos deben ser independientes entre sí.
- Los objetos deben usar los datos que necesitan, en lugar de depender de otros objetos para proporcionarlos.

Cualidades deseables del software:

- Corrección funcional: debe ser correcto, condición necesaria. En cuanto se especifique una cualidad, pasa a ser
una corrección funcional.
- Confiabilidad: debe ejecutar sus funciones de forma predecible y sin interrupciones inesperadas.
- Robustez: capacidad del software que no fue previamente pensada (no especificada). Se logra con buenas
prácticas, concentrarse mientras se programa (no usar celular, dormir bien, etc.).

Menos acople => Mejor código

Dimensiones de calidad del software: los usuarios juzgan cuando una cualidad no se cumple.

- Cualidades internas: solo las ven los desarrolladores.

- Cualidades externas: solo las ven los usuarios.

Calidad: es subjetiva, es una percepción.

Cualidades o características de un software:

 Performance: Rapidez. Se mide por 3 tiempos:

 Tiempo de corrida llamado a: si al tiempo q transcurre en un proceso "Bach" hasta que tengo el resultado. Es
disimulado a través de distintas técnicas.
 Tiempo de respuesta: tiempo que media entre mandar una información y responda a la información.
 Volumen de procesamiento: cantidad de transacciones q se da en una unidad de tiempo.
 Amigabilidad: fácil de usar y entender. Sensación de confort q tiene el usuario.
 Verificabilidad: propiedad del producto (interna).
 Mantenibilidad: capacidad del software de sufrir modificaciones exitosas con el menor esfuerzo posible.
 Reparabilidad: mantenimiento correctivo.
 Evolutividad: mantenimiento actualizable.
 Reusabilidad: elementos preconstruidos y preprovados. Menos costoso.
  Portabilidad: una cosa es portable cuando puede cambiar de plataformas. Incrementa los costos.
 Comprensibilidad: virtud vista por el desarrollador a nivel de proceso y vista por el usuario a nivel de producto.
El sistema debe ser comprensible.
 Interoperabilidad: las aplicaciones tienen que ser capaces de coexistir.
 Productividad: tiene dos formas de ser medida:
 Del punto de vista del cliente: es lo que logra que el cliente tenga placer y que le guste.
 Del punto de vista del desarrollador: se basa en el proceso.
 Oportunidad: capacidad de satisfacer las necesidades del cliente y aportar un beneficio. Se basa en su utilidad y
su disponibilidad.
 Visibilidad: la documentación le da visibilidad.

Proceso: pasos que se siguen para crear y desarrollar software de manera organizada y eficiente.

Flujo de proceso secuencial: comunicación -> planeación -> modelado -> construcción -> pruebas -> despliegue ->
mantenimiento

- Comunicación: Comprender las necesidades del software a través de conversaciones con los interesados.
- Planeación: Crear un plan detallado que establece cómo se desarrollará el software, incluyendo recursos y
plazos.
- Modelado: Diseñar una representación visual del software que muestra su estructura y funcionalidad.
- Construcción: Escribir y desarrollar el código del software según el diseño previo.
- Pruebas: Probar exhaustivamente el software para identificar y corregir errores y asegurarse de que funcione
correctamente.
- Despliegue: Hacer que el software esté disponible para su uso, instalándolo en sistemas o servidores.
- Mantenimiento: Realizar correcciones, actualizaciones y mejoras en el software para mantenerlo en buen
estado a lo largo del tiempo.

Modelo de cascada: para comenzar una etapa tiene que haberse completado correctamente la etapa anterior. Puede
llegar a ser útil en algunas organizaciones gubernamentales.

Requerimientos: expresiones formales de las necesidades de nuestros clientes.

- Requerimientos funcionales: son lo que el software debe hacer.

- Requerimientos no funcionales: son cómo debe hacerlo.
- Requerimientos informales: características que quiero que tenga el producto. No se puede representar
simbólicamente.
- Requerimientos formales: Cualidades que debe tener un producto. Soporta una representación simbólica.

Etapas del proceso de desarrollo del software:

- Necesidades: lenguajes coloquiales.

- Requerimientos: lenguaje formal – glosario.
- Especificaciones: diagramas de secuencia, despliegue, etc.
- Desarrollo: construcción, implementación (prueba y error).
- Despliegue (implementación): comienza después de la reparación del sistema.
- Mantenimiento: acción que se entiende que comienza tiempo después de la implementación.

Flujos:

- Flujo de proceso iterativo:

 Las etapas nunca se dan por terminado.
 Tiende a ser más realista
  Soluciona el problema de la realidad, pero no el de los costos (muy altos).
- Flujo de proceso evolutivo o incremental: desarrollar el software en etapas iterativas, mejorando y ampliando
funcionalidades con cada ciclo.
 Prototipo evolutivo: fuente de negocio. Versión temprana del software que se mejora gradualmente en
pasos sucesivos.
- Flujo de proceso paralelo: se hacen avances en paralelo, en cada uno de los subsistemas. Se divide la aplicación
en subsistemas.

Metodologías:

 Métodos agiles: flexibles, permiten ajustes continuos y dividen el trabajo en partes pequeñas. Mejoras
constantes y rápidas. Colaboración activa, para que el producto cumpla las expectativas.
 Métodos clásicos: planificación detallada desde el inicio, con requisitos especificados. Dificulta los cambios con
el proyecto en marcha. La entrega se hace al final del ciclo, con una secuencia lineal.

Modelos modernos: necesariamente iterativos.

Manifiesto ágil: lista de reglas para hacer software de manera flexible y eficiente. Valores de los métodos agiles

 Personas e interacciones más que procesos y herramientas.

 Software funcionando más que documentación extensa.
 Colaboración con el cliente más que negociación de contratos.
 Responder a cambios más que seguir un plan fijo.

Valores: aquellas cosas percibidas como una cosa buena por un grupo de personas.

Características comunes

 Surge en libros con impacto en la industria y en el público.

 Metodología simple y fácil de aprender (valores, principios, practicas (hechos completos), roles, artefactos).
 Equipos no jerárquicos y autoorganizados: en todo equipo no jerárquico hay alguien q mantiene el control,
organiza o da las órdenes.
 Comunicación intensiva.
 Minimalismo: (prescinde del modelado) si no te lo pidieron no lo hagas.
 Proceso iterativo e incremental: entregas rápidas.
 Capacidad adaptativa: rápida propuesta al cambio.

Principios ágiles:
1. Satisfacer al cliente con entregas tempranas y continuas de software valioso.
2. Adaptarse a cambios en los requisitos incluso en etapas tardías para beneficio competitivo.
3. Entregar software funcional frecuentemente, preferiblemente cada dos semanas.
4. Colaboración diaria entre dueños del negocio y desarrolladores.
5. Empoderar a individuos motivados y proporcionarles apoyo y confianza.
6. La comunicación cara a cara es la forma más efectiva de transmitir información.
7. El software funcional es la principal medida de progreso.
8. Fomentar un desarrollo sostenible para mantener un ritmo constante indefinidamente.
9. Enfocarse en la excelencia técnica y el buen diseño de manera continua.
10. Maximizar la simplicidad y minimizar el trabajo no realizado es crucial.
11. Las mejores soluciones surgen de equipos autoorganizados.
12. Reflexionar y adaptar en intervalos regulares para mejorar la efectividad del equipo.

Aplicación del sentido común:

 - Revisión => programación en parejas: Trabajar en parejas para revisar y mejorar constantemente el código
mientras se escribe, en lugar de revisarlo después de terminar.
- Pruebas => programadores y clientes: Colaboración cercana entre programadores y clientes en las pruebas para
garantizar que el software cumpla con las expectativas del cliente.
- Diseño => recodificación: Enfocarse en un diseño flexible que se ajusta y mejora a medida que se avanza en el
desarrollo, en lugar de realizar un diseño detallado antes de la codificación.
- Simplicidad => minimalismo: Promover la simplicidad y evitar la complejidad innecesaria en el software y los
procesos de desarrollo.
- Arquitectura => metáfora: Usar una metáfora comprensible por todos para describir la arquitectura del
software, facilitando la comunicación entre el equipo.
- Pruebas de integración => integración continua: Realizar pruebas de integración de componentes de forma
continua durante el proceso de desarrollo, en lugar de esperar hasta el final.
- Iteraciones cortas => juego de la planificación: Dividir el trabajo en iteraciones breves y planificarlas
eficientemente, permitiendo adaptación y flexibilidad a medida que se avanza.

XP: es una forma ligera, eficiente, de bajo riesgo, predecible, y divertida de desarrollar software.

¿Por qué fracasan los proyectos de software?:

- Retrasos y desviaciones en la planificación: Problemas con los plazos y desviaciones del plan original.
- Coste de mantenimiento elevados: Mantener el software es costoso y puede superar el presupuesto.
- Alta tasa de defectos: Errores frecuentes en el software que afectan su funcionamiento.
- Requisitos mal comprendidos: Falta de comprensión adecuada de lo que el cliente necesita.
- Cambios de negocio: Cambios en las necesidades o el enfoque del negocio.
- Falsa riqueza de características: Incluir demasiadas características innecesarias que complican el proyecto.
- Cambios de personal: Rotación de miembros del equipo que afecta la continuidad del proyecto.

Soluciones de XP:

- Retrasos y desviaciones: versiones cortas.

- Cancelan el proyecto: entregas periódicas.
- Sistemas deteriorados y defectos: pruebas continuas.
- Requisitos mal comprendidos: cliente dentro del equipo.
- Cambios de negocio: versiones cortas.
- Falsa riquezas de características: realizar tareas prioritarias.
- Cambios de personal: anima el contacto y la integración.

Valores de XP:

- Comunicación: Hablar y escuchar mucho para entenderse bien.

- Simplicidad: Mantener las cosas simples, sin complicaciones innecesarias.
- Realimentación: Aprender y mejorar constantemente mediante retroalimentación.
- Coraje: Tomar decisiones difíciles y enfrentar problemas sin miedo.

Los valores de los métodos agiles son del XP también, tiene 8 valores, 4 de los métodos agiles y 4 del XP

Un proyecto puede generar:

 Felicidad.
 Comodidad.
 Fama.
 Prestigio.
 Dinero.
  Etc.

Pero lo más importante es que genere Rentabilidad.

Factores que hacen a la rentabilidad de un proyecto:

 Flujos de entrada y salida.

 Tipos de interés.
 Mortalidad del proyecto.

Maximizar el valor económico del proyecto:

 Gastar menos - ¿Cómo ahorrar?

 Gastar más – Marketing comercialización.
 Gastar más tarde y ganar antes – Intereses.
 Aumentar la probabilidad de que el proyecto siga vivo.

VAN (valor actual neto): hace que el negocio sea factible

D = Da + D x ti = Da(1+ti)}x P C n
D = x + x ti = x(1+ti) = Da(1+ti)(1+ti) = Da(1+ti)2 0 997,01 1
D = Da(1+ti)n 0 994,02 2
Da= D/(1+ti)n 0 991,05 3
0 988,09 4
Vn = 10000/(1+ti)4 = 10000/1,11^4 = 6586 0 985,30 5
ti 11% mensual 0 982,18 6
ti = 0,11 979,24 979,24 7
976,32 976,32 8
973,4 973,4 9
D = 509,06
970,48 970,48 10
D = (509,06 + 1000)(1+0,003)^12
967,59 967,59 11
D = 1564,29 964,69 964,69 12
961,8 0 13
Da = 1509,06 958,9 0 14
VA = 1000/1,003^n 956,6 0 15
953,2 0 16
Considerar siempre:
950,3 0 17
 Opción de cambiar. 947,5 0 18
 Opción de abandonar.
 Opción de aplazar.
 Opción de crecer.

Al enfrentar proyectos se debe hacer con la mente abierta (considerar todas las opciones).

El costo del cambio en XP: el cambio es costoso, cuanto más metido en el proyecto más costoso todavía.

- Se necesita que el costo y el cambio sean independientes del tiempo.

- Y el costo se estabiliza.

Cosas que no se pueden ignorar, para poder decidir a future

 Daño potencial del objeto y cual.

 Si no hay riesgo no hay negocio. (cuanto mayor riesgo, mayor ganancia)
 Los riesgos son necesarios.
Riesgo, dos conceptos: impacto y daño de la probabilidad

 Incertidumbre del futuro.

 Base del negocio.
 A mayor riesgo mayor ganancia.
 Riesgos constitutivos del negocio, necesarios e imprescindibles.

Riesgos inherentes: día a día del negocio, se toman decisiones frente a estos riesgos. A veces algunos riesgos se ignoran.

Riesgos desconocidos: Se funden.

Hay que tomar acciones para disminuir los riesgos de alto impacto. (restringir las vulnerabilidades del sistema):

 Evitar que alguien dañe al sistema.

 Evitar que el sistema se dañe a sí mismo.
 Atacar las consecuencias en caso de un error o fallo.

Traspasar responsabilidades/riesgo:

 Que alguien se haga cargo. (compañías de seguro de las consecuencias)

Desconocer el riesgo: no tener conciencia de la naturaleza del peligro.

Para poder gestionar un riesgo adecuadamente:

- Hay que determinar si existen indicadores tempranos de que algo podría estar pasando, de que algún evento
podría estar por ocurrir.
1. Daño potencial
2. Probabilidad de ocurrencia.
3. Regla gatillo.
4. Disminución de probabilidad.
5. Calcular el posible riesgo.
 El producto es un numero de referencia nada más.
 El líder del equipo y el gasto de riesgo.
 Puede haber riesgos sin medidas preventivas.

Contratos tácitos y escritos.

Lista de errores q si esta ordenada: se clasifican en 2 grupos

- Errores de nivel superior: son percibidos por el cliente

 Error de comunicación: que es cuando el sistema hace lo que el cliente quiere, pero no como lo quiere.
- Errores de nivel inferior: son los que quedan en la organización
 Errores de lógica: ocurre cuando un sistema no hace lo que el equipo de desarrollo quiere que haga.
 Errores triviales (lo más barato q hay): afecta a la sintaxis o a la semántica. Error de ortografía que el propio.

Entorno de programación: me avisa de su existencia y de su localización (Solo lo sabe el programador).

- Nosotros probamos el código para demostrarnos a nosotros mismos que el código funciona bien.

Condiciones de pruebas:

- Las pruebas no debes ser llevadas adelante por los programadores. (Se considera como parte de desarrollo del
Código).
- Probamos para demostrar q el software no hace lo q yo quiero. Intentar encontrar la mayor cantidad de errores
posibles en el menor tiempo posible. Una prueba exitosa es cuando el sistema encuentra un error.
Como encontrar errores:

- Inspección: leer el código para encontrar errores. Una inspección suele durar 3h y se suele hacer una sola vez.
optimizar el proceso de prueba.
- Suponer que una base de datos no tiene problemas es la primer idiotes del desarrollo del software
- No alcanza con probar entradas y salidas, hay q probar tambien puntos intermedios.

Tipos de pruebas: presentan una dificultad común con que probarlo.

- Pruebas unitarias: prueban las partes.

- Pruebas de integración: prueban el todo.

Acople: independientemente del paradigma, es la forma en que intercambia información dos componentes del sistema.
Pueden cambiar mucha o nada de información.

- El tipo de acople q no intercambia información es nulo.

- La cantidad de información que intercambian dos componentes cuanta menos información más débil el acople.
Acople débil producto fuerte o robusto.
- Cuanto más fuertes son los acoples más débiles es el producto.

Partición de equivalencia (no incremental porque la cantidad de componentes que se están probando simultáneamente
es constante):

- Para cada problema requiere un grado de experticia particular del cual nosotros no somos dueños, necesitamos
un experto en asesoramiento del problema.
- No intercambiar muchos parámetros porque el componente resulta frágil, porque las pruebas son imposibles.

Lotes de prueba: generarlos de forma útil es difícil. Los mismos deben ser valiosos y no desechables.

Entornos de pruebas unitarios:

- El problema es cuando los limites son difusos

Partición de pruebas: no incremental porque la cantidad de componentes que se están probando simultáneamente es
constante.

- Ventaja: Permite identificar interacciones entre componentes desde el inicio, lo que puede llevar a la detección
temprana de errores de integración.
- Desventaja: Puede requerir más recursos y tiempo al probar todos los componentes a la vez, lo que podría hacer
que el proceso de prueba sea más extenso y complejo.

Modelos según Pressmann:

Proceso de desarrollo del software: es iterativo, osea que los pasos del proceso se pueden repetir varias veces para
mejorar el software.
Pasos:
 Requisitos: se recopilan y documentan los requisitos del usuario. Son las funciones y características que el
software debe tener.
 Diseño: se crea un diseño para el software. Describe cómo se implementarán los requisitos del usuario.
 Implementación: se escribe el código para el software.
 Prueba: se prueba el software para asegurarse de que funciona correctamente.
 Implementación y mantenimiento: se implementa el software en producción y se mantiene para garantizar que
funcione correctamente en el tiempo.
Factores que afectan al proceso de desarrollo de software:
  Requisitos del usuario: determinan el alcance del software. Si los mismos son cambiantes o inciertos, puede
dificultar el proceso.
 Tecnología: la tecnología que utilizada para el desarrollo puede afectar al proceso de desarrollo.
 Equipo de desarrollo: es responsable de crear el software. La experiencia y habilidades de este pueden afectar
al proceso de desarrollo.
 Presupuesto y el cronograma: restricciones considerar en el proceso.
Mejorar el proceso de desarrollo de software:
 Definir claramente los requisitos del usuario: ayudará a que el software cumpla las necesidades del usuario.
 Utilizar un método de desarrollo de software adecuado.
 Gestionar el proyecto de manera eficaz: garantizar finalizar tiempo y dentro del presupuesto.
 Utilizar herramientas y técnicas de desarrollo de software eficaces.