Proceso Software

Resumen completo

Clara Valle Gómez

1 de junio de 2023
PS - Resumen C.Valle

Índice
1. T1: Introducción a la Ing. Software 2
1.1. Características del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Problemas del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Principios de la ingeniería de software . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Fases de la ingeniería de software . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5. Tipos de mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6. Capas de la ingeniería de software . . . . . . . . . . . . . . . . . . . . . . . . 3
1.7. Conceptos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.8. Proyecto software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. T2: Ciclos de vida de desarrollo 4

2.1. Codificación directa (code and fix) . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. En cascada (waterfall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Modelo en V (cascada mejorado) . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Modelo de prototipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Modelos evolutivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5.1. Modelo incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5.2. Modelo en espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Ciclos de vida orientados a objetos . . . . . . . . . . . . . . . . . . . . . . . . 6

3. T3: Análisis de requisitos 6

3.1. Especificación de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Modelos de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4. T4: Análisis de sistemas software 8

4.1. T4.1 Análisis estructurado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Diagrma de Flujo de Datos (DFD) . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Diccionario de datos (DD) . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.3. Especificación de procesos (EP) . . . . . . . . . . . . . . . . . . . . . . 11
4.1.4. Balanceo entre modelos . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.5. Proceso reocmendado . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5. T5: Diseño estructurado 12

5.1. Diagrama de Estructuras (DEC) . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Tabla de interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Estrategias de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3.1. Análisis de transformación . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3.2. Análisis de transacción . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6. T6: Metodología de desarrollo software 14

6.1. Metodologías tradicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Metodologías ágiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. Metodología tradicional: Métrica V3 . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Metodología ágil: Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.5. Tradicionales vs ágiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7. T7: Calidad 16

8. T8: Planificación 17

9. T9: Pruebas de software 19

9.1. T9.1: Pruebas de software convencional . . . . . . . . . . . . . . . . . . . . . 20

1
PS - Resumen C.Valle

1. T1: Introducción a la Ing. Software

1.1. Características del software
El software es un conjunto de 3 componentes: programas (instrucciones), datos y docs.

Es un elemento lógico
Se desarrolla
Se deteriora

Diferencias entre errores:

Error: Cometido a nivel humano (código)

Defecto: Causa del error (el producto tiene un defecto)
Fallo: el defecto provoca un fallo (el producto no funciona)

1.2. Problemas del software

Proyectos fuera de plazo y presupuesto
Gran dependencia de los desarrolladores
Falta de control en el desarrollo
Escasa intgración en las fases del desarrollo
Escaso control de calidad
Escasa documentación
No uso de metodologías

1.3. Principios de la ingeniería de software

Abstracción: Simplificar los problemas para un mejor entendimiento (grano grueso)
Encapsulamiento: Esconder detalles que no afectan a otros módulos
Modularidad: Dividir los problemas en módulos (max cohesión, min acoplamiento)
Localización: Agrupar elementos afectados por el mismo hecho (API)
Uniformidad: Todos los módulos deben tener una notación similar
Completitud: Deben estar desarrollados todos los aspectos del sistema
Validación y verificabilidad: Comprobar desarrollo y funcionamiento

1.4. Fases de la ingeniería de software

Definición: ¿Qué debe hacer el sistema? (Análisis)
• Información que maneja el sistema
• Necesidades de rendimiento
• Restricciones de Diseño
• Interfaces del sistema
• Criterios de validación
• Análisis de requisitos1
Desarrollo: ¿Cómo construir el sistema? (Diseño, codificación y pruebas)
• Diseño de estructuras de datos y programas
• Documentación y escritura de los programas
• Pruebas de software

1 Es un factor clave en el éxito del proyecto. El resultado del análisis con el cliente se plasma en la

Especificación de Requisitos.

2
PS - Resumen C.Valle

Mantenimiento: Una vez construido el sistema

• Se centra en el cambio
• Reparaciones y modificación de fallos
• Fase de mayor coste
• El software debe ser fácil de mantener

1.5. Tipos de mantenimiento

Correctivo: Si el programa falla debe modificarse
Perfectivo: Adaptar mejor el programa a los requisitos, eficiencia, funcionalidad...
Adaptativo: Adaptar el programa a los cambios del entorno externo
Preventivo: Corrección del software debido al deterioro por los cambios

1.6. Capas de la ingeniería de software

Procesos: Define un marco de trabajo (cómo)
• Identificar actividades y tareas de la IS
• Definir el flujo de trabajo
• Identificar los productos que se producen
• Especificar los puntos de control de calidad
Métodos: Actividades técnicas que se deben realizar
Herramientas: Soporte a los procesos y métodos
• Automatización de actividades manuales
• Reduce la posibilidad de errores

1.7. Conceptos básicos

Descomposición (análisis): Descomponer un problema en partes más pequeñas
Composición (síntesis): Componer una solución a partir de soluciones más simples

Cliente: Persona que financia y solicita el producto software.

Usuario: Usa el software y define los detalles operativos.

Producto: Resultado de cada etapa o actividad entregable.

Proyecto: Conjunto de actividades relacionadas con un comienzo y un fin claros sujeto
a tiempo, presupuesto y alcance (objetivo).

1.8. Proyecto software

Es una actividad que transforma los requisitos de un cliente en un producto software entre-
gable. Para esta transformación se aplica un ciclo de desarrollo establecido.

Proceso: Marco de trabajo que define actividades abstractas dentro del proyecto
Proceso Software: conjunto de estructuras, políticas y procedimientos necesarios
para desarrollar, instalar y mantener un producto software

Ciclo de vida: Marco de referencia (qué) que contiene los procesos y las actividades
involucradas en el desarrollo, explotación y mantenimiento de un producto software,
desde la definición de requisitos hasta el fin de su uso
Ciclo de vida del desarrollo: Desde el análisis a la entrega al usuario

3
PS - Resumen C.Valle

2. T2: Ciclos de vida de desarrollo

Un ciclo de vida debe:
Determinar el orden de las fases de un proceso software
Establecer criterios de transición de una fase a otra

2.1. Codificación directa (code and fix)

Antónimo de Ingeniería de Software
No requiere de planificación
No recomendable excepto para proyectos enanos
Sinónimo de arte en la ingeniería de software

2.2. En cascada (waterfall)

Más empleado y difundido
Realización temprana de las actividades, muy lineal
Cada fase productos de salida que son la entrada de la siguiente actividad

Ventajas
Marco de referencia asignar actividades
Método muy estructurado
Coordinación de los recursos
Disposición de hitos/seguimiento desarrollo
Estimación de seguimiento y control progreso
Detección de desviaciones
Productos entregables al final de cada fase
Desventajas
Requiere todos los requisitos al principio
Gran rigidez
Errores se detectan tarde
Los productos parciales son solo documentos

2.3. Modelo en V (cascada mejorado)

Rama descendente: actividades en desarrollo
Rama ascendente: actividades de prueba
Ambas ramas se comunican a través de pruebas

4
PS - Resumen C.Valle

Ventajas
Hereda todas las ventajas de cascada
Conforma un marco de referencia con actividades V&V (verification and validation)
Favorece las pruebas lo antes posible
Desventajas
Requiere todos los requisitos al principio (como en cascada)
Puede no ser viable (no se contemplan cambios de parecer del usuario)
Gran rigidez, aún que menor que cascada
Los productos parciales son solo documentos

2.4. Modelo de prototipos

La construcción de un prototipo facilita al desarrollador la posterior creación del software.
Existen diferentes tipos de prototipos:
Desechables: elimina dudas sobre lo que realmente quiere el cliente
Evolutivos: modelo que pasa de prototipo a software si cumple los criterios de calidad

Ventajas
El prototipo es un mecanismo ideal para extraer requisitos
Desventajas
Tendencia del cliente a creer que el trabajo ya está hecho
Se pueden tomar decisiones rápidas para hacer el prototipo que no son las ideales

2.5. Modelos evolutivos

Se desarrolla un modelo que cumple los requisitos principales, pero todavía quedan por
definir los detalles (los anteriores no tienen en cuenta la naturaleza evolutiva del software).
Existen varios ejemplos de modelos evolutivos:

2.5.1. Modelo incremental

Es la aplicación reiterada de varias secuencias basadas en el modelo Cascada. Cada aplicación
del ciclo constituye un incremento software y resulta en un producto ya operativo.

Ventajas
No requiere tener disponible una implementación completa
Cada incremento es un producto ya operativo
Mayor flexibilidad ante nuevas funcionalidades
La calidad del software mejora con las iteraciones

5
PS - Resumen C.Valle

Desventajas

Puede ser complejo de finir el núcleo operativo de la primera versión

Puede ser complicado establecer prioridades para el siguiente incremento
Las soluciones a incrementos anteriores pueden no valer para incrementos posteriores
No es útil en proyectos cortos o de funcionalidad bien definida

2.5.2. Modelo en espiral

Es un proceso evolutivo que permite combinar la naturaleza interactiva de un prototipo
con aspectos controlados del modelo en cascada
Pone énfasis en el análisis de los riesgos para reducir su impacto
El software se desarrolla en una serie e versiones incrementales
Cada fase tiene: determina los objetivos, evalua alternativas, desarrollo del siguiente
nivel y planificaión de la siguiente fase

Ventajas
Se adapta a las necesidades cambiantes del proyecto
Permite el uso de prototipos
Gestiona los riesgos antes de que se conviertan en problemas
Desventajas
Considerar los riesgos requiere de habilidad

2.6. Ciclos de vida orientados a objetos

Desarrollo iterativo e incremental
Sin fronteras entre fases
Incluye componentes reutilizables

Verificación: da los RESULTADOS correctos ajustándose a las necesidades del cliente.

Validación: el código se ajusta a lo que el cliente REALMENTE quería.

3. T3: Análisis de requisitos

Requerimiento: Petición de una cosa que se considera necesaria
Requisito: Condición del usuario para resolver un problema o alcanzar un objetivo.
Es una característica que el sistema DEBE tener.

6
PS - Resumen C.Valle

3.1. Especificación de requisitos

Los requisitos de un proyecto deben documentarse, pueden ser parte del contrato y son
fuente (origen) del diseño.

Características de la especificación de requisitos (precontrato):

Utiliza estándares para estructurarse
Aclara el objetivo a cumplir por el sistema
Emplea descripciones textuales y gráficas
Ordena y agrupa los requisitos de forma lógica
Relaciona unos requisitos con otros para mejor comprensión
Relaciona requisitos con otros elementos
Pasos a seguir para identificar los requisitos de un producto:
Entender el trabajo desde el punto de vista del usuario
Interpretar el trabajo y la forma en que lo describe el usuario
Inventar mejores formas de hacer el trabajo
Plasmar los resultados en una especificación de requisitos
Problemas a la hora de definir los requisitos:

Los requisitos no son obvios y vienen de muchas fuentes

Pueden ser difíciles de expresar en palabras
Gran cantidad de requisitos a manejar en algunos proyectos
Un requisito puede cambiar a lo largo del Desarrollo
Recordar lo excepcional y olvidar lo rutinario
Los usuarios tienen distinto vocabulario que los desarrolladores

Actividades de la ingeniería de requisitos (4):

Obtención: análisis del problema
Análisis: evaluación de los requisitos
Especifiación: documentar los requisitos
Validación: requisitos consistentes y completos

Evolución de los requisitos:

Al analizar el problema no se hacen las preguntas correctas
Cambió el problema que se estaba resolviendo
Los usuarios cambiaron su forma de pensar
Cambió el mercado en el que se desenvuelve el negocio
Tipos de requisitos (3):
Requisitos de negocio
Requisitos de usuario: Describe comportamiento externo del sistema, evitar diseño
Requisitos del sistema: Definen el producto (contrato), origen del diseño, + detalle
• Requisitos funcionales: Describen lo que el sistema debe hacer (consultar libro)
• Requisitos no funcionales: Define las cualidades del producto (interfaz manejable)
◦ Requisitos de producto: usabilidad, eficiencia, fiabilidad...
◦ Requisitos organizacionales: entrega, implementación, estándares...
◦ Requisitos externos: legislación, privacidad, seguridad...

7
PS - Resumen C.Valle

Características de la descripción de un requisito (7):

Completo Realizable Priorizable Verificable

Correcto Necesario No ambiguo

Características de la especificación de requisitos (4):

Completa Modificable
Consistente Trazable

Técnicas de recogida de requisitos (6):

Reuniones/entrevistas Brainstorming Prototipos

Cuestionarios/encuestas Casos de uso Escenarios

3.2. Modelos de casos de uso

Un diagrama de casos de uso representa las funcionalidades del sistema (casos de uso) en
relación a una interacción externa (actores).

Los actores son entidades externas que realizan interacciones (son tanto personas como
otros sistemas) y se distinguen en principales (constituyen) y secundarios (dan soporte).

Un caso de uso es una descripción de la secuencia de interacciones entre un actor y el

sistema. Para identificar un caso de uso:
Captura el comportamiento sin especificar la implementación
Proporciona un medio de comprensión entre usuarios y expertos
Se define un conjunto de secuencias de acciones y sus variantes
Representa requisitos funcionales del sistema
Las relaciones representan el flujo de información
Tipos de casos de uso: Grano grueso y grano fino

Relaciones en los casos de uso:

Asociación: relación
Extensión: Un caso de uso incluye partes de otro bajo ciertas condiciones
Generalización: Caso general que tiene hijos más específicos (se usa en actores)
Inclusión: Un caso de uso se incluye en el comportamiento de otro caso de uso

4. T4: Análisis de sistemas software

Objetivos del análisis:

Especificar funciones del software
Especificar la información que se usa
Especificar interfaces con otros elementos del sistema
Establecer restricciones a cumplir por el software

8
PS - Resumen C.Valle

Resultados del análisis:

El análisis plasmará los requisitos en modelos del sistema (ER, DFD)
Estos modelos dependerán del enfoque (estructurado, objetual...)
Motivos por los que hacer modelos de análisis

Permiten centrarse en las propiedades importantes del sistema

Favorecen la comunicación con el usuario
Permiten verificar que el analista ha comprendido el problema a abordar

Los modelos de análisis aportan:

Reflejar lo que quiere el usuario (generalmente de forma gráfica)

Establecer la base de un diseño de software
Definir un modelo contra el que validar el software

Principios de los modelos: (10)

No es tarea del equipo de software crear modelos
No crear más modelos de los necesarios
Tratar de reproducir el modelo más sencillo
Construir modelos susceptibles al cambio
Ser capaz de enunciar un propósito para cada modelo
Adaptar los modelos al sistema
Tratar de construir modelos útiles, no perfectos
Lo importante es que comunique bien, la representación es secundaria
Si tu instinto dice que el modelo está mal, preocúpate
Obtener retroalimentación lo antes posible
Principios de los modelos de análisis: (5)
Debe entenderse y representarse el dominio de información del problema
Deben entenderse y representarse las funciones del software
Debe representarse el comportamiento del software a comportamientos externos
Deben dividirse los modelos de manera que descubran los detalles por capas
El proceso de análisis va desde lo esencial hasta el detalle

4.1. T4.1 Análisis estructurado

4.1.1. Diagrma de Flujo de Datos (DFD)
Objetivos:
Dejar constancia de los límites del sistema
Construir una jerarquía de niveles de explosión2
Reflejar de forma lógica procesos que transforman la información
Simplificar la complejidad del sistema y su comprensión
Facilitar el mantenimiento del sistema
Elementos de un DFD:
Entidad externa (actor): Agentes ajenos al sistema, aportan o reciben información
Proceso: Actividad que transforma datos de entrada en uno o varios datos de salida
Almacén de datos: Depósito de información en el sistema (no transforma)

2 El DFD se va haciendo por niveles cada uno con más complejidad y procesos que el anterior

9
PS - Resumen C.Valle

Flujo de datos: Transporta información hasta otros componentes (lógicos o físicos)

• Se pueden agrupar flujos por claridad
• El mismo contenido puede tener distintos significados en diferentes partes
• Flujo divergente (diferentes caminos) o flujo convergente (combinar flujos)
• Un flujo a un almacén representa actualización, borrado o adición de uno, parte
o varios paquetes
Aplicación:
Debido a los numerosos almacenes, procesos... puede organizarse por niveles
Lo que se obtiene es una jerarquía de niveles de explosión
La aproximación más común es Top-Down (facilita comprensión del sistema)
• Nivel 0 - Una única burbuja e interfaces (sistema completo genérico)
• Nivel 1 (diagrama de sistema )- Tantas burbujas como subsistemas
• Siguientes niveles de explosión - refinan y detallan los identificados anteriormente
No todas las partes del sistema deben tener la misma altura de nivel
Si la especificación de un proceso no cabe en una página hay que explosionarlo
Si un DFD tiene más de 6 o 7 burbujas hay que crear un nivel intermedio
Los almacenes internos no se dibujan hasta que se comparten, los almacenes externos
se dibujan en la primera capa si el sistema lo modifica
Los niveles deben ser consistentes y estar balanceados (Principio Conservación de flujo)
No deben reflejarse subsistemas que solo se vayan a emplear una vez
Datos entrada y salida de una burbuja que se expande al siguiente nivel se corresponden

Temporalidad:
Un DFD es una red de procesos asíncronos (no especifica temporalidad)
NO se modelan secuencias (orden) de ejecución ni alternativas
Las se se establecen solo por la existencia o falta de información
Consistencia:
Evitar sumideros infinitos (procesos con entradas y sin salidas)
Evitar procesos de generación espontánea (procesos que no tienen entradas)
Evitar flujos y procesos no etiquetados
Evitar almacenes internos de solo lectura o escritura

4.1.2. Diccionario de datos (DD)

Define con exactitud todos los datos del resto de modelos, sin estos un modelo no puede
considerarse completo (complementa DFD).
Lista organizada de datos del sistema con definiciones precisas
Evita ambiguedad y asegura entendimiento común de todas las entradas y salidas
Definición de datos:
Describe el significado de los flujos del DFD (entidades, flujos y almacenes)
Describe la composición de los paquetes que se mueven por los flujos
Describe la composición de los paquetes en los almacenes
Especifica los valores y datos relevantes en flujos y almacenes
Describe detalles relacionados con el E/R (entidades y relaciones)
Para definir un dato se debe incluir el contexto en la aplicación, la composición (si es único
o está compuesto de otros más simples) y los valores que puede tomar

10
PS - Resumen C.Valle

4.1.3. Especificación de procesos (EP)

Describe cómo los procesos (generalmente los del último nivel) hacen para transformar en-
tradas en salidas (complementa DFD).

La descripción debería tener en cuenta:

Descripción de los datos de entrada
Descripción de los datos de salida
Descripción del proceso (1 pag. max)

4.1.4. Balanceo entre modelos

Balanceo DFD y DD
• Cada flujo y almacén del DFD debe estar incluido en el DD
• Cada dato y almacén del DD debe estar en el DFD
Balanceo DFD y EP
• Cada burbuja está asociada con un DFD de nivel inferior o EP (no los dos)
• Cada EP debe tener una burbuja de nivel inferior asociada en el DFD
• Las entradas y salidas deben coincidir en el EP y DFD
Balanceo EP con DFD y DD
• Cada dato en la EP tiene que cumplir:
◦ El nombre de los flujos y almacenes debe coincidir con el del EP
◦ Es un término local definido explícitamente en el EP
◦ Aparece como entrada del DD
Balanceo DD con DFD y EP
• Cada entrada del DD tiene que tener referencia en EP o DFD o el propio DD
Balanceo ER con DFD y EP
• Cada almacén y entidad debe corresponderse con uno del ER y viceversa
• Los nombres de las entidades y relaciones deben coincidir
• Las EP deben interactuar con las entidades del ER
• Algún proceso del DFD tiene que usar los valores de cada dato
Balanceo ER con DD
• Las entidades en singular y los almacenes en plural
• Todos los atributos de una entidad aparecerán en el DD

4.1.5. Proceso reocmendado

1. Obtener conocimiento del entorno
Descripción del entono, entrevistas, recoger requisitos
2. Obtener los modelos de análisis
Obtener DFD, ER y DD
Explosionar DFD hasta el nivel adecuado
Balancear DFD, ER y DD
3. Obtener las EP
Obtener el EP de al menos las burbujas primitivas
Evaluar la necesidad de obtenerlas del resto de niveles
Balancear EP con el resto de modelos

Ahora comenzaría la fase de diseño

11
PS - Resumen C.Valle

5. T5: Diseño estructurado

Es una técnica de diseño que comunica el análisis y la programación del mismo a través de
reglas, deriva en una arquitectura de software.
Características:

Obtención de la solución a partir de la definición del problema

Simplifica el problema (subdivide el problema en una jerarquía, ocultando información)
Técnicas gráficas (diagramas de estructuras y tablas de interfaz)
Conjunto de estrategias
Criterios para evaluar la calidad

5.1. Diagrama de Estructuras (DEC)

El diagrama de estructuras proporciona una vista de las entidades y sus relaciones dentro
del sistema.
Características:
Ofrece una jerarquía de control
Comunicación entre módulos (interfaz)
Nombres significativos
Los flags no se representan, excepto en el análisis de transacción
Posibilidad de abrstracción (se ocultan datos para hacer el diagrama más sencillo)
Máxima cohesión mínimo acoplamiento
Un módulo es una parte lógica separable de un problema que se puede llamar.

Visiones del módulo:

Externa (Alto nivel, ves el módulo como una caja negra): interesan entradas y salidas
Interna (Bajo nivel, caja blanca): interesa ver los datos y los mecanismos internos

5.2. Tabla de interfaz

Especifica los parámetros que se pasan entre módulos (interfaces)

Contiene la siguiente información

Módulo llamado Parámetros entrada Uso parámetro

Parámetros formales Parámetros salida Significado parámetro

Uso:

Complementa los diagramas de estructura

Mejora la claridad de los DEC mediante especificación más rigurosa de las interfaces
Permite desglosar una comunicación de datos definida en un diagrama de estructuras

5.3. Estrategias de diseño

Permiten la transformación de un DFD a una descripción del diseño. Se usan dos técnicas:
Análisis de transformación y análisis de transacción.

Técnica:

Todos los procesos pueden verse como transformación y transacción (depende enfoque)
Las zonas de transformación y transacción no están definidas por la forma

12
PS - Resumen C.Valle

5.3.1. Análisis de transformación

Se usa cuando el DFD:

Los datos externos llegan al sistema por caminos que los transforman (flujo de llegada)
En el centro del sistema (núcleo) ocurre una transformación
Los datos transformados circulan por una única salida (flujo de salida)
Análisis:
1. Revisar el modelo del sistema (DFD)
2. Determinar características del DFD (transformación en este caso)
3. Aislar el centro de transformación (núcleo)
4. Factorización de primer nivel
Módulo superior (Cm )
Módulo control de flujo de llegada (Ce )
Módulo centro de transformación (Ct )
Módulo control de flujo de salida (Cs )
5. Factorización de segundo nivel (flujos, entradas y salidas)
6. Refinar la arquitectura del sistema (módulos, flags...)
7. Revisar diseño

5.3.2. Análisis de transacción

Se usa cuando el DFD:

Tiene un único camino en el flujo de llegada

En el núcleo ocurre un encaminamiento del flujo de entrada (se divide)
Los datos encaminados circulan en varias salidas (flujo de salida)
Análisis:
Igual que el análisis de transformación.

Identificar el centro de transacción:

Determinar el proceso que constituye el centro
Normalmente identificable a simple vista (de él el salen caminos independientes)
Aislar el flujo de llegada y evaluar cada camino de acción
Estos caminos pueden pertenecer a cualquiera de los dos tipos, por lo que habrá que
identificarlos individualmente y realizar un segundo nivel de factorización

13
PS - Resumen C.Valle

6. T6: Metodología de desarrollo software

Metodología: Conjunto de métodos que formalizan y optimizan una actividad, indica los
pasos a seguir, planificarlos y como realizarlos (puede seguir varios ciclos de vida).

Ciclo de vida: Marco de referencia que contiene procesos, actividades y tareas involucradas
en el desarrollo, explotación y mantenimiento de un producto software (en orden desde la
definición hasta la finalización de su uso).

Ciclo de desarrollo: Contempla las actividades dentro de la fase de desarrollo.

Proceso: Conjunto de pasos realizados para un fin determinado.

Elementos de una metodología:

Fases: tareas a realizar
Productos: entrada/salida de cada fase
Procedimientos: realización de cada tareas
Criterios de evaluación: saber si se han logrado los objetivos
Ventajas del uso de metodologías:
Gestión
• Facilita planificación
• Facilita control y seguimiento
• Mejora la relación coste/beneficio
• Optimiza los recursos
• Facilita la evaluación de resultados
• Facilita comunicación usuario-desarrollador
Ingenieros de software
• Facilita comprensión del problema
• Optimiza el proceso de desarrollo
• Facilita el mantenimiento del producto
• Permite la reutilización de partes del producto
Cliente o usuario
• Garantía de calidad
• COnfianza en los plazos
Existen varios tipos de metodologías: tradicionales y ágiles

6.1. Metodologías tradicionales

Cumplir con un plan de desarrollo definido al principio
Llevar una documentación exhaustiva
Altos costes ante cambios (falta de flexibilidad)
Se focaliza en documentar y planificar

6.2. Metodologías ágiles

Valora al individuo y las interacciones con el equipo
El cliente colabora en todo momento
Más importante el producto que la documentación
Más importante la capacidad de respuesta al cambio que el plan

Críticas:

14
PS - Resumen C.Valle

Falta de estructura y documentación

Enorme coste para los clientes
Complicado estimar el esfuerzo para el presupuesto
Ineficiente si los requisitos cambian durante las iteraciones

6.3. Metodología tradicional: Métrica V3

Características:
Cubre el proceso de desarrollo y mantenimiento
Abarca el desarrollo completo del sistema
Se adapta a las dimensiones y características de cada proyecto
Orientado al proceso
Descompone los procesos en actividades y estas en tareas
Establece un conjunto de técnicas
Desarrolla sistemas de mayor calidad, productividad y satisfacción
Facilita el mantenimiento posterior

Procesos:
Planificación de sistemas de información
• Proporciona un marco de referencia de in determinado ámbito
Desarrollo de sistemas de información
• Contiene todas las actividades y tareas que se deben llevar a cabo (desde el análisis
a la instalación)
Mantenimiento de sistemas de información
• Obtener una nueva versión a partir de las peticiones de los usuarios
Estudio de viabilidad
Análisis del sistemaDiseño del sistema
Construcción del sistema
Implantación y aceptación del sistema
Roles:

Directivo Consultor Programador

Jefe de proyecto Analista

6.4. Metodología ágil: Scrum

Características:
Estrategia de desarrollo incremental
La calidad se basa en el conocimiento de las personas en equipos organizados
Solapamiento de las diferentes fases de desarrollo
Esta metodología está organizada por sprints. Cada sprint finaliza con la entrega de una
parte operativa, un incremento. Se monitariza la evolución en reuniones breves diarias.

Roles:
Propietario (determina las prioridades)
Equipo (construye el producto)
Scrum master (gestiona la ejecución de las reglas de scrum)
Intersados (asesoran y observan)

15
PS - Resumen C.Valle

6.5. Tradicionales vs ágiles

Metodologías Tradicionales Metodologías ágiles

Basadas en normas provenientes de estándares
Resistencia a los cambios
Normas impuestas externamente
Proceso muy controlado con políticas y normas
Existe un contrato prefijado
Cliente interactúa a través de reuniones
Grupos grandes y distribuidos
Más artefactos
Más roles
Arquitectura de software mediante modelos
Basadas en heurísticas provenientes de producción
Preparado para cambios durante el proyecto
Normas impuestas internamente (por el equipo)
Proceso menos controlado, pocos principios
Contrato flexible, no tradicional
El cliente es parte del equipo de desarrollo
Grupos pequeños trabajando en el mismo sitio
Pocos artefactos
Pocos roles
Menos énfasis en la arquitectura de software

7. T7: Calidad
La calidad es un conjunto de propiedades del producto que satisfacen los requisitos del cliente

Datos:
Cuesta más obtener un cliente nuevo que conservar uno antiguo
Pocos clientes descontentos se quejan
Un cliente descontento transmite su desontento a al menos 9 personas
Pocos clientes descontentos vuelven a repetir la compra
Bastantes clientes dejan la compañía por la mala calidad del servicio
La mitad de los clientes eligen una compañía en base a recomendaciones
Solo la mitad de los servicios satisfacen al cliente
El 30 % de los servicios tienen incidencias que los clientes no reclaman
Muchos servicios generan reclamaciones que no suelen llegar a los equipos de gestión
Solo el 3 % de los servicios generan quejas por escrito bien dirigidas
Costes:
Costes de prevención: Controlar el proceso de producción con revisiones y formación
para que es respeten los criterios de calidad.

Costes de evaluación: Asociados a la producción terminada: inspecciones, pruebas...

Costes de la no calidad: Asociados a gastos internos (reclamaciones, reparaciones...)
o externos (garantías, juicios...)
Enfoques:

Calidad Control Aseguramiento Gestión

Concierne Dpt. Control de calidad Auditores de calidad Todos
Se aplica Todas fases del producto Procesos operativos Todos los procesos
Actúa para Encontrar defectos Econtrar no conformidades Conseguir objetivos
Se orienta Al producto (efecto) A los procesos (causa) Procesos
Personal No necesaria Conveniente Imprescindible
Actitud Arreglo/reacción Prevención Mejora
Configuración:
Política de calidad: Directrices y objetivos generales
Sistemas de calidad: Conjunto de elementos de gestión (organización)
Gestión de calidad: Conjunto de actividades llevadas a cabo para cumplir la calidad
Plan de calidad: Documento que especifica procedimientos y recursos a aplicar

16
PS - Resumen C.Valle

Atributos de la calidad de software:

Fiable: Ofrece siempre los mismos resultados bajo las mismas condiciones
Eficiente: Utilización óptima de los recursos de la máquina
Robusto: Tolerante a fallos
Correcto: Se ajusta a las especificaciones del usuario
Portable: Capaz de integrarse a entornos distintos
Adaptable: Modificar alguna función no afecta a todas las actividades
Inteligible: Diseño claro, bien estructurado y documentado
No erróneo: No existe diferencia entre los valores reales y los calculados
Reutilizable
La mejora del proceso software ayuda a:

Mejorar la funcionalidad, costes y plazos del producto

Coordinación eficaz con proveedores y clientes
Proveer servicios con reconocimiento de calidad
Implemenntación desde una perspectiva integrada a un negocio de ingeniería
Procesos comunes, integrados y basados en mejorar el desarrollo

Proceso de creación de valor:

1. Voz del cliente: Conocer necesidades y expectativas
2. Desplegar voz del cliente: Transformarla en un plan de acciones
3. Desplegar sistemas de calidad: identifican los procesos de acuerdo a los estándares
4. Medir y evaluar la satisfacción del cliente: y así orientar las mejoras

8. T8: Planificación
Problemas del desarrollo software (7):
Proyectos fuera de plazo
Excesiva dependencia de los desarrolladores
Falta de control del desarrollo
Escasa integración de las fases del desarrollo
Escaso control de calidad del producto
Escasa documentación actualizada de los proyectos
No utilizar una metodología formal

Un proyecto es un conjunto de actividades coordinadas con fechas de inicio y de fin defi-

nidas con la finalidad de crear un producto conforme a unos requisitos con limitaciones de
tiempo, coste y recursos.

La gestión de proyectos es la aplicación de un conjunto de conocimientos y técnicas a las

actividades de un proyecto para satisfacer los requisitos.

Actividades del gestor:

Redacción de la propuesta
Planificación y calendarización del proyecto
Estimación de los costes
Supervisión y revisión
Selección y evaluación del Personal
Redacción y presentación de informes

17
PS - Resumen C.Valle

Proceso de planificación:

1. Se valoran las restricciones (fechas de entrega, personal...)

2. Se prepara un calendario
3. Se comienza el proyecto
4. Se revisa el proyecto y se actualiza el plan

Un calendario debería responder a:

Qué actividades hay que realizar y cuando deben terminarse?
Existen los recursos necesarios?
Que actividad realizará cada miembro del equipo?
Cuando finalizará el analista su participación?
Cuanto costará el proyecto?
Plan de proyecto (calendarización):
Muestra la división y organización del trabajo en actividades
Fija los recursos disponibles (humanos, materiales...)
Crea un calendario de trabajo mostrando una relación entre actividades recursos y
tiempo
Conceptos básicos:
Tarea/actividad: Unidad elemental del nivel de planificación
Hito: Indica un acontecimiento relevante en el proyecto (no consume tiempo)
Hamaca: Mide el tiempo transcurrido entre dos actividades del proyecto
Esfuerzo Tiempo que le lleva a un solo recurso realizar la tarea (se mide en días/hombre)
Restricciones: Establecen dependencias entre las distintas tareas del proyecto
• Fin-Comienzo: B no puede empezar hasta que A termine
• Comienzo-Fin: B no puede terminar hasta que A empiece
• Comienzo-Comienzo: B no puede empezar hasta que A empiece
• Fin-Fin: B no puede terminar hasta que A termine
Recursos: Elemento sujeto a compartición (conflictos), hacen las actividades.
Tiempo/Duración: Duración de la tarea una vez asignados recursos (paralelo)
Coste: En función de los recursos y costes adicionales
Diagrama de Gantt: Representa la organización enn el tiempo de las actividades
mediante barras con sus relaciones y recursos
Nivelación: Si un recurso trabaja más que su jornada está sobreasignado (sobrecarga)
• Alargar las actividades para evitarlo
• Cambiar los recursos
• Introducir recursos para compartir el esfuerzo
• Modificar la temporalidad
• Segmentar las actividades...
Camino crítico: Sucesión actividades marcan la duración del proyecto (sin retrasos)
Holgura: Tiempo que se puede retrasar una tarea sin que se retrase ninguna otra
Línea de base: Línea que transcurre el proyecto de forma óptima
Seguimiento del proyecto:

Comprobar que todo sucede según lo previsto

Comparar los resultados con los previstos (línea de base)
Tomar decisiones correctivas ante las desviaciones
Definir normativa para el seguimiento del proyecto (temporal)

18
PS - Resumen C.Valle

9. T9: Pruebas de software

Una estrategia de prueba software proporciona unos pasos a realizar, cuando se llevan a ca-
bo y cuanto esfuerzo, tiempo y recursos se destinan para descubrir problemas lo antes posible.

El objetivo de las pruebas es descubrir errores.

Las pruebas las realizan:

gerente ingenieros especialistas

Las pruebas de software representan el mayor esfuerzo técnico en el proceso software.

Orden:
Se empieza por lo pequeño: sobre un componente para descubrir errores en los datos
o la lógica (verificación)
Hacia lo grande: serie de pruebas para descrubrir errores en la satisfacción de los
requerimientos (validación)
Según se van descubriendo errores se va depurando el programa
Las pruebas nunca se terminan, la carga pasa del ingeniero al usuario final.

Pruebas de unidad: pruebas de las funciones individuales

Se enfocan a la verificación de la unidad más pequeña de software
Se prueban las rutas para descubrir errores en las fronteras de un módulo
Se enfocan en la lógica interna y estructuras de datos
Pueden realizarse en paralelo
Usan controladores (drivers) y stubs (subprogramas tontos)
Pruebas de integración: pruebas de la arquitectura des software completa
Pruebas estáticas: se hacen sin necesidad de ejecutar el código
Pruebas de integración descendente: usan conductores (drivers) y resguardos
Pruebas de integración ascendente
Pruebas de regresión
Prueba de humano
Pruebas OO: Compienza con pruebas pequeñas dentro de una clase
Pruebas web: Se prueban de forma parecida a OO
Pruebas de validación: garantía de que se cumplen los requerimientos
Desaparece la distinción entre tipos de software
Se enfocan en acciones visibles para el usuario y salidas del sistema
La validación es exitosa cuando cumple con las expectativas del cliente
Se satisfacen os requerimientos y el contenido es preciso
• Si el software está hecho a medida se pueden realizar pruebas de aceptación
que permiten al cliente validar los requerimientos
• Si no, se realizan pruebas alfa ( en un entorno controlado por el desarrollador) y
beta (se lanzan al usuario final sin ser controladas)
Pruebas del sistema: pruebas de todo el sistema al completo
Se prueba el software con otros elementos del sistema y se realizan pruebas de inte-
gración y validación
Pruebas de recuperación: comprobar que el sistema es tolerante a fallos
Recuperación automática (reinicio, backups...)
Recuperación con intervención humana (Tiempo Medio de Recuperación)

19
PS - Resumen C.Valle

Pruebas de seguridad: proteger la información sensible del software

Quien realiza la prueba toma el papel del atacante

EL objetivo es hacer que cueste más entrar al sistema que la info que vas a obtener
Pruebas de esfuerzo: enfrentan programas a situaciones anormales
Se ejecuta un sistema que pude una cantidad anormal de recursos
Se llaman de sensibilidad si descubren combinaciones de datos que rompen el sistema
Pruebas de despliegue: probarse en diferentes plataformas
Ejecutar el software en el entorno en el que opera
Examinar todos los procedimientos de instalación
Examinar toda la documentación que introducirá el software a los usuarios finales
Depuración:
La depuración ocurre como consecuencia de pruebas exitosas (que descubren errores)
Da como resultado un rastreo y corrección del error
Ojo clínico: a partir de una manifestación del error, saber la causa del problema
Tácticas:
• Fuerza bruta: recopilar la mayor cantidad de info hasta encontrar el problema
• Vuelta atrás: ir a dónde se descubrió el error y rastrearlo desde ahí
• Eliminación de causas: se particionan los datos related y se aíslan sus causas

Corrección del error:

Preguntarse si ese error se produce en otras partes del programa
Al corregir el error pueden generarse problemas nuevos
Preguntarse que debió hacerse para evitar el error desde el principio

9.1. T9.1: Pruebas de software convencional

Diseñan una serie de casos de prueba que tienen una alta probabilidad de encontrar errores.
En ellas, cada vez que el programa se ejecuta el cliente lo prueba.

Pruebas de caja blanca: Lógica del programa

Garantiza que se revisan todas las rutas dentro del módulo
Revisan todas las decisiones lógicas en sus dos ramas
Ejecutan todos los bucles
Revisan las estructuras de datos internas

Pruebas de caja negra: Requerimientos

Funciones faltantes o incorrectas
Errores de interfaz, estructuras de datos o acceso a BBDD
Errores de comportamiento o rendimiento
Errores de inicialización y terminación

La configuración está conformada por Instrucciones + Datos + Documentación

20