1.

Introducción

MCSEA: Mantenimiento, Confiabilidad, Seguridad, Eficiencia, Aceptabilidad

Tomar en cuenta Tiempo/Presupuesto/Limitantes de la organización

Proceso de software: Secuencia de actividades que conducen a la elaboración del

software. Especificación, Desarrollo, Validación, Evolución.

Problemas: Heterogeneidad, Cambio empresarial y social, Seguridad y confianza

Costo, Fecha, Confiabilidad del software

Fundamentos: Crear proceso de desarrollo, Confiabilidad y desempeño, Especificación

y requerimientos, Reutilizar recursos existentes (incluyendo otros softwares)

Responsabilidad: Confidencialidad, Competencia (habilidades), Propiedad

intelectual, Mal uso de computadoras (virus)

Los ingenieros de software deben comprometerse a hacer del análisis, la

especificación, el diseño, el desarrollo, la prueba y el mantenimiento del
software, una profesión benéfica y respetada

2. Procesos de software

Proceso de software: Serie de actividades relacionadas que conduce a la elaboración

de un producto de software

Clasificación: Plan-Driven y procesos ágiles

Modelos de proceso:
*Cascada (o ciclo de vida del software, plan-driven)
*Incremental
*Orientado a la reutilización: Analisis de componentes, Modificación de
requerimientos, Diseño de sistemas con reutilización, Desarrollo e integración
*Espiral (dirigido por el riesgo, Objetivos, Riesgos, Desarrollo y validación,
Planeación, Reiterar si es necesario)
*Proceso relacionado relacional RUP: Concepcion, Elaboración, Construcción,
Transición.

CASE: Herramientas de Ingeniería de Software Asistido por Computadora, como

editores de diseño, diccionarios de datos, compiladores, depuradores (debuggers),
herramientas de construcción de sistema, etcétera

Requerimientos de usuario (alto nivel) y de sistema (detallado para el programador)

Proceso de diseño:
*Arquitectonico: Estructura global del sistema, modulos, relaciones.
*Interfaz: Interfaces entre componentes (al otro no le importa como se implementó
el anterior)
*Componentes: Reutilización, funcionalidades.
*Base de datos: Estructura del sistema de datos.

Validación y Verificación:
1. Prueba de desarrollo
2. Prueba del sistema
3. Prueba de aceptación

METODOLOGIAS AGILES
Desarrollo y entrega rapidos en empresas que son muy cambiantes, un software
estable cuando se entregue posiblemente ya sea obsoleto.

Los procesos que buscan especificar por completo requerimientos, diseñar, construir
y probar el sistema no están orientados al desarollo rápido de software, el diseño
o la implementacion tienen que reelaborarse y probarse de nuevo.

Proceso de desarollo del software rápido. El software no se desarrolla como una

sola unidad, sino como una serie de incrementos, cada uno incluye una nueva
funcionalidad del sistema.

Caracteristicas:
1. Especificacion, diseño e implementación están entrelazados. Solo las
caracteristicas mas importantes del sistema.
2. El sistema se desarrolla en diferentes versiones. Proponen cambios y nuevos
requerimientos.
3. Las interfaces de usuario se desarrollan usando con frecuencia un sistema de
elaboracion interactivo para crear interfaces rápidamente.

Entre más tarde la planeacion, mas costoso es, especialmente en pequeñas empresas.

Metodos:
1. Programación extrema
2. Scrum
3. Crystal
4. DSDM
5. Adaptativo
6. Por características

Todos se basan en desarollo y entrega incremental, pero proponen diferentes

procesos para lograrlo. Están orientados a pequeños equipos, por tanto, dificil en
equipos grandes o divididos por paises

Los contratos deben ser por tiempo, por requisitos no porque seria una planeacion y
por tanto modelo cascada

La documentación no se mantiene actualizada por tanto cambio

Los programadores entienden el sistema sin documentación, pero los nuevos no lo

hacen y causa problemas.

Cuando usar cada uno?

1. Si se requiere especificacion y diseño antes de implementar, usar basada en un
plan.
2. Si se quiere entregar incrementalmente y obtener rapida retroalimentacion, usar
metodos agiles
3. Si el equipo es pequeño, usar agiles. Si el equipo es muy grande igual que el
sistema usar un plan.
4. Si el sistema requiere mucho analisis usar un plan.

*Programación Extrema: Se toma una historia del usuario, se desglosa en tareas, se

planea la liberacion, se desarolla y pone a prueba, se libera el software, se
evalua y se repite el proceso. Se refactoriza cuando se puede, osea, optimizar como
convertir en funciones o eliminar codigo repetido. Programar en pares de
desarrolladores, es menos eficiente cuando los programadores son expertos porque
hacen menos codigo que individualmente.
ADMINISTRACIÓN DE PROYECTO AGIL

*Scrum: Planeacion del bosquejo y diseño arquitectonico, ciclo de sprints

(valoracion, seleccion, desarrollo y revision), cierre del proyecto. La
comunicacion se hace a traves del Scrum Master, se debe quitar la idea de un
"administrador de proyecto" porque todos tienen derecho a tomar decisiones.

ESCALAMIENTO DE METODOS AGILES

*Scaling up y out (para grandes sistemas, y para grandes organizaciones)

INGENIERIA DE REQUERIMIENTOS

Requerimientos: Descripciones de lo que el sistema debe hacer.

Ingenieria de requerimientos: Proceso de descubrir, analizar, documentar y

verificar los servicios y restricciones

Requerimientos del usuario: Enunciados acerca de que servicios esperan los usuarios
del sistema y las restricciones con las que este debe operar. Puede luego dividirse
en requerimientos del sistema. Se escriben en lenguaje natural.

Requerimientos del sistema: Descripciones de las funciones, servicios y

restricciones operacionales del sistema de software. El documento de requerimientos
del sistema (especificacion funcional) define con exactitud lo que se implementará.
Se escriben en lenguaje natural, pero se usan otras notaciones basadas en formas,
modelos graficos del sstema o modelos matematicos, UML es un ejemplo.

Requerimientos funcionales: Enunciados acerca de servicios que el sistema debe

proveer, como reacciona el sistema a entradas particulares y de como deberia
comportarse el sistema en situaciones especificas

Requerimientos no funcionales: Limitaciones sobre servicios o funciones que ofrece

el sistema. Temporizacion o desarrollo por estandares. Aplican al sistema como un
todo, mas que como caracteristicas o servicios individuales. Pueden causar nuevos
requerimientos funcionales como seguridad. Incluyen etica, regulaciones gobierno,
legalidad, seguridad, confiabilidad, fiabilidad, espacios y almacenamientos. Hay
requerimientos del producto (defininiciones o restricciones), de la organización
(cumplir procesos internos y su cultura) y externos (como las regulaciones de los
bancos)

Metricas para no funcionales: Rapidez (transacciones/segundo), Tamaño (MB),

Facilidad de uso (Capacitaciones), Fiabilidad (Disponibilidad, probabilidad de
indisponibilidad, tiempo medio de falla), Robustez (tiempo de reinicio despues de
falla, baja probabilidad de corrupcion), Portabilidad (Numero de sistemas objetivo)

Documento de requerimientos de sofrware (o especificacion de requerimientos SRS):

Comunicado oficial de lo que deben implementar los desarrolladores, incluye los de
usuario como los de sistema. Pero en desarrollo agil, los requerimientos cambian
tanto que el documento queda obsoleto.

Especificacion de requerimientos: Es el proceso de escribir, en un documento de

requerimientos, los del usuario y del sistema. Claros, sin ambigüedad. No debe
incluir arquitectura o diseño del sistema.

Especificacion en lenguaje natural: Sencillo y universal, propenso ambiguedad

Especificacion en lenguaje natural estructurado: Ejemplo, poner historias de
usuario en tarjetas que contienen campos de razon, dependencias con otros
requerimientos, materiales, etc.

Procesos de ingenieria de requerimientos:

1. Estudio de factibilidad
2. Adquisicion y analisis de requerimientos
2.1 Descubrimiento de requerimientos
2.2 Clasificacion y organizacion de requerimientos (por subsistemas)
2.3 Priorizacion y negociacion de requerimientos
2.4 Especificacion de requerimientos (se documentan e ingresan en la siguiente
ronda esperial de estos 4 pasos)
3. Especificacion de requerimientos (convertilos e forma estandar)
4. Validacion (Comprobar que los requerimientos definan el sistema que realmente
quiere el cliente)

Entrevistas: Formular preguntas a los participantes sobre el sistema viejo y el

nuevo a desarrollar, a fin de encontrar requerimientos a traves de las respuestas.
Algunos problemas son la jerga de cada participantes por su dominio, y la
familiaridad con un proceso que no lo mencionan porque creen que es obvio para el
entrevistador.

Escenarios: Es mas facil vincularse con ejemplos reales para saber como interactua
el participante con el sistema en un determinado escenario

Caso de uso: Identifica a los actores implicados en una interaccion y nombra el

tipo de interaccion.

Etnografia: Contexto social y organizacional. Es una tecnica de observacion que se

usa para entender los procesos operacioneales, obteniendo requerimientos de apoyo a
dichos procesos. Un usuario sabe su trabajo, pero quiza no su relacion con la
empresa.

Validación de requerimientos: Proceso de verificar que los requerimientos definan

realmente al sistema que en verdad quiere el cliente.

1. Comprobaciones de validez: Un usuario piensa que requiere ciertas funciones,

pero quiza se pueda lograr de otras maneras.
2. Comprobaciones de consistencia: Los requerimientos no deben estar en conflicto.
3. Comprobaciones de totalidad: Incluir requerimientos que definan todas las
funciones y restricciones pretendidas por el usuario
4. Comprobaciones de realismo: Garantizar que en realidad puedan realizarse con la
tecnologia existente, así como presupuestos y fechas
5. Verificabilidad: Requerimientos deben escribirse de manera que puedan ser
verificables.

Tecnicas de validacion:

1. Revisiones de requerimientos: Un equipo revisa errores e inconsistencias

2. Creacion de prototipos: Se muestra un modelo ejecutable del sistema a los
usuarios finales y clientes, y ver si cumple sus necesidades
3. Generacion de casos de prueba: Las pruebas deben ser faciles de diseñar, sino,
los requerimientos entonces son muy complejos.

Administracion de requerimientos: Para grandes sistemas, los requerimientos siempre

cambian. Los requerimientos deben evolucionar para reflejar la vision cambiante del
problema. Es el proceso de comprender y controlar los cambios en los requerimientos
del sistema.
1. Los ambientes empresariales y tecnicos cambian despues de la instalacion
2. Los usuarios finales van cambiando, y sus necesidades tambien
3. La comunidad de usuarios es grande y diversa, y posiblemente existan conflictos

Planeacion de la administración de requerimientos:

1. Identificacion de requerimientos
2. Administracion del cambio (valoran el efecto y costo de los cambios)
3. Politicas de seguimiento (relaciones entre cada requerimiento)
4. Herramientas de apoyo

Herramientas de apoyo:

1. Almacenamiento de requerimientos
2. Administracion del cambio
3. Administracion de seguimiento

Administracion del cambio en los requerimientos: Si los beneficios de implementar

nuevos requerimientos estan justificados por los costos de la implementacion, las
estapas son:

1. Analisis del problema y especificacion del cambio

2. Analisis del cambio y estimacion del costo
3. Implementacion del cambio

MODELADO DEL SISTEMA

Modelado sistemas: Proceso para desarrollar modelos abstractos del sistema, cada
modelo presenta una vision o perspectiva diferente del sistema. Se usa mucho UML,
modelos matematicos. Se usa en la ingenieria de requerimientos para entender el
sistema anterior y comprobar el nuevo sistema. Deja fuera los detalles por su
abstraccion.

Perspectivas: Externa, Interacción con entorno, Estructural y de Comportamiento.

Diagramas UML más usados:

1. Actividad: Actividades de un proceso
2. Caso de uso: Interacciones entre el sistema y el entorno
3. Secuencias: Interacciones actores, sistema y componentes del sistema
4. Clase: Clases de objetos y las asociaciones entre estas
5. Estado: Como reacciona el sistema frente a eventos internos y externos

Los diagramas buscan facilitar discusion entre ingenieros del sistema, para
documentar el sistema o como descripcion detallada que sirve para generar una
implementacion de sistema

MODELOS DE CONTEXTO

Es una primera etapa en la especificación de un sistema, decidir fronteras del

sistemas. Participantes determinan cual funcionalidad se incluira en el sistema y
cual la ofrece el entorno del sistema. Decidr apoyo automatizado para algunos
procesos empresariales. Buscar traslapes en la funcionalidad con los sistemas
existentes y determinar donde tiene que implementarse la nueva funcionalidad.

En algunos casos, la frontera entre un sistema y su entorno es relativamente clara,

donde un sistema automatico sustituye un sistema manual, el entorno del nuevo
sistema suele ser el mismo que el del sistema existente. También puede ser una
frontera considerada con factores no tecnicos, como que todo el proceso de analisis
esté en un solo lugar, que consultar a un administrador particularmente dificil sea
innecesario, etc. Una vez tomadas las deciciones sobre fronteras, parte de la
actividad de analisis es la definicion de dicho contexto y las dependencias que un
sistema tiene en su entorno

Modelos de contexto muestran que el entorno incluye sistemas automatizados, pero no

representan los tipos de relaciones entre sistemas en el entorno y el sistema que
se especifica, como sistemas externos que se conectan para consumir datos. Por eso,
los modelos de contexto se usan con otros modelos, como los de proceso empresarial.
Las flechas indican la dirección del flujo de trabajo, y la linea solida
coordinacion de tareas.

MODELOS DE INTERACCIÓN

Interacciones del usuario, como sus entradas y salidas. Interacciones entre el

sistema y otros, o incluso interacciones entre componentes del sistema. Ayuda a
identificar los requerimientos del usuario, destaca posibles problemas de
comunicacion.

1. Modelado de caso de uso: Interacciones entre un sistema y actores externos

(usuarios u otros sistemas)
2. Diagramas de secuencia: Modelar interacciones entre componentes del sistema,
aunque pueden incluirse agentes externos.

MODELADO DE CASOS DE USO

Parte del UML, es un simple escenario que describe lo que espera el usuario de un
sistema. Cada caso de uso representa una tarea discreta que implica interaccion
externa con un sistema. Un caso de uso se representa como una elipse, con actores
con figuras humanas.

DIAGRAMA DE SECUENCIA

Parte del UML, modelan interacciones entre actores y objetos del sistema, como
tambien entre objetos. Muestra la sucesion de interacciones que ocurre durante un
caso de uso particular o una intancia de caso de uso.

MODELOS ESTRUCTURALES

Muestran la organización de un sistema, en terminos de los componentes que que

constituyen dicho sistema y sus relaciones. Se crean cuando se discute y diseña la
arquitectura del sistema.

DIAGRAMAS DE CLASE:

Se usan cuando se desarrolla un sistema orientado a objetos, muestran clases de un

sistema y las asociaciones entre dichas clases. Se incluye relacion entre clases,

GENERALIZACIÓN

Tecnica cotidina apara gestionar la complejidad, en vez de aprender las

caracteristicas contidianas detalladas de cada entidad, dichas entidades se colocan
en clases mas generales. Permite deducir que diferentes miembros de estas clases
tienen algunas caracteristicas comunes. Básicamente es herencia de clases. En UML
se define la generalización como una flecha que apunta hacia la clase más general.

AGREGACIÓN

Los objetos del mundo real están compuestos por diferentes partes. Un paquete de
estudio tiene libro, diapositivas, examenes y recomendaciones. La asosiacion
especial entre clases es llamada agregación, que significa que un objeto (el todo)
se compone de otros objetos (las partes).

MODELOS DE COMPORTAMIENTO

Son modelos dinamicos del sistema conforme se ejecuta. Muestra lo que sucede o se
supone que pasa cuando un sistema responde ante un estimulo de su entorno.

1. Datos: Llegan y se procesan por el sistema.

2. Eventos: Eventos activamn procesamiento del sistema.

MODELADO DIRIGIDO POR DATOS

Muestran secuencia de acciones involucradas en el procesamiento de datos de

entrada, así como de una salida asociada. Es util para el analisis de
requerimientos, pues muestran el procesamiento "extremo a extremo" en un sistema,
exhiben toda la secuencia de acciones que ocurren desde una entrada a procesar,
hasta la salida correspondiente, que es la respuesta del sistema.

MODELADO DIRIGIDO POR UN EVENTO

Muestra como responde un sistema a eventos externos e internos. Se basa en la

suposicion que un sistema tiene un numero finito de datos y que los eventos
(estimulos) pueden causar una transicion de un estado a otro. Ej. Valula abierta ->
Valuva cerrada. Adecuados para sistemas en tiempo real.

INGENIERIA DIRIGIDA POR MODELO

Es un enfoque al desarrollo donde los modelos son las salidas principales del
desarollo de software. La elevada abstracción de esto permite a los ingenieros
preocuparse por las salidas y no tanto por detalles del lenguaje de programación o
especificidades de las plataformas de ejecución. Pero no siempre es posible manejar
abstracción, especialmente si el sistema hace uso de un software ya existente.

ARQUITECTURA DIRIGIDA POR MODELO

Enfoque orientado a modelos para el diseño e implementación de software. Usa

subconjuntos de modelos UML para describir un sistema. Se crean modelos a
diferentes niveles de abstracción, a partir de un modelo independiente de alto
nivel, es posible, generar un programa funcional sin intervencion manual.

UML EJECUTABLE

La nocion fundamental detras de la ingenieria dirigida por modelo es que debe ser
posible la transformación completamente automatizada de modelos a codigo, se debe
ser capaz de construir modelos graficos, cuya semantica esté bien definida.
También, agregar información a los modelos sobre la forma en que se implementan las
operaciones. xUML permite esto.

CAPITULO 6: DISEÑO ARQUITECTONICO

El diseño arquitectónico se interesa por entender cómo debe organizarse un sistema,

y cómo tiene que diseñarse la estructura global de ese sistema. Es la primera etapa
en el proceso de diseño del software. Es el enlace crucial entre el diseño y la
ingeniería de requerimientos, identifica los principales componentes estructurales
en un sistema y la relación entre ellos. Las arquitecturas de software se diseñan
en dos niveles de abstracción:

1. Arquitectura en pequeño: Se interesa por la arquitectura de programas

individuales, uno se preocupa por la forma en que el programa individual se separa
en componentes.

2. Arquitectura en grande: Se interesa por la arquitecutra de sistemas

empresariales complejos que incluye otros sistemas, programas y componentes.

La arquitectura es importante porque afecta el desempeño, potencia y capacidad de

distribución y mantenimiento de un sistema. Los componentes individuales
implementan los requerimientos funcionales del sistema. Los no funcionales dependen
de la arquitectura del sistema, es decir, la forma en que dichos componentes se
organizan y comunican. Ventajas de diseñar y documentar de manera explícita la
arquitectura de software:

1. Comunicacion con los participantes: Arquitectura es una presentación de alto

nivel del sistema, puede usarse como enfoque para la discución de un amplio número
de participantes.

2. Análisis del sistema: En una etapa temprana, aclara la arquitectura del sistem
requiere cierto análisis. Las decisiones del diseño arquitectónico definen si un
sistema puede cubrir o no cubrir los requerimientos criticos como rendimiento,
fiabilidad y mantenibilidad.

3. Reutilización a gran escala: Un modelo de una arquitectura de sistema es una

descripcion corta y manejable de cómo se organiza un sistema y como interoperan sus
componentes. Por tanto, si el sistema se asemeja a otro, es posible reuitilizar
software a gran escala.

Hofmeister propone a una arquitectura de software que sirve en primer lugar como un
plan de diseño para la negociación de requerimientos de sistema, en segundo lugar,
como un medio para establecer discusiones con los clientes, desarrolladores y
administradores. Se modelan con frecuencia con diagramas de bloque. Hay dos formas
en que se utiliza un modelo arquitectonico de un programa:

1. Facilitar discucion acerca del diseño del sistema

2. Forma de comunetar una arquitectura que se haya diseñado

DECISIONES EN EL DISEÑO ARQUITECTÓNICO

1. ¿Existe alguna arquitectura de aplicación genérica que actúe como plantilla para
el
sistema que se está diseñando?
2. ¿Cómo se distribuirá el sistema a través de algunos núcleos o procesadores?
3. ¿Qué patrones o estilos arquitectónicos pueden usarse?
4. ¿Cuál será el enfoque fundamental usado para estructurar el sistema?
5. ¿Cómo los componentes estructurales en el sistema se separarán en
subcomponentes?
6. ¿Qué estrategia se usará para controlar la operación de los componentes en el
sistema?
7. ¿Cuál organización arquitectónica es mejor para entregar los requerimientos no
funcionales
del sistema?
8. ¿Cómo se evaluará el diseño arquitectónico?
9. ¿Cómo se documentará la arquitectura del sistema?

Patrón arquitectónico: Es una descripcion de una organización del sistema, como

cliente-servidor, o por capas. Capan la esencia de una arquitectura que se usó en
diferentes sistemas de software.

El estitulo y estructura arquitectónicos particulares elegidos dependeran de los

requerimientos de sistema no funcionales:

1. Rendimiento: Si el rendimiento es critico, la arquitectura debe diseñarse para

realizar operaciones criticas dentro de un pequeño numero de compnentes, o usar
componentes más grandes que pequeños (granularidad)

2. Seguridad: Utilizar capas, con los activos criticos protegidos en las capas más
internetas.

3. Protección: Arquitectura debe diseñarse para que las operaciones relacionadas

con la proteccion se ubiquen en un componente individual, reduciento así costos y
problemas de validación.

4. Disponibilidad: Arquitectura debe diseñarse para incluir componentes redundantes

a fin de sustiuir y mantener el sistema sin detenerse.

5. Mantenibilidad: Arquitectura debe diseñarse usando componentes autocontenidos de

grano fino que permitan cambiarse con facilidad.

VISTAS ARQUITECTONICAS

1. ¿Qué vistas o perspectivas son útiles al diseñar y documentar una arquitectura

del
sistema?
2. ¿Qué notaciones deben usarse para describir modelos arquitectónicos?

Las vistas sugeridas son:

1. Lógica: Abstracciones, entidades.

2. Proceso: Como están compuestos los procesos en interacción
3. Desarrollo: Como está descompuesto el software para su desarrollo, elementos
que se implementan mediante un solo desarrollador.
4. Física: Hardware de sistema, procesadores y su distribución de componentes.

PATRONES ARQUITECTÓNICOS

Forma de presentar, compartir y reutilizar el conocimiento sobre sistemas de

software. Son una descripción abstracta estilizada de una buena práctica que se
ensayó y puso a prueba en diferentes sistemas y entornos.

1. Capas: Muy usado en desarrollo incremental, cada capa está separada y algunos
servicios y se apoya en facilidades y servicios ofrecidos por la capa
inmediatamente abajo de ella, es posible cambiar la capa o modificarla. Rendimiento
es menor porque la solicitud entra en diferentes nivel de interpretación mientras
se procesa en cada capa.

2. MVC: Modelo vista controlador. Modelo (datos y sus operaciones), Vista

(Representación de datos a usuario), Controlador (Encargado de llevar eventos como
clicks al modelo y vista)

3. Repositorio: Describe como comparten datos un conjunto de componentes en

interacción. Todos los datos se gestionan en un repositorio cental, accesible a
todos los componentes del sistema, los componentes no interactuan mas que solo a
través del repositorio.

4. Cliente-Servidor: La funcionalidad se organiza en servicios, cada servicio lo

entrega un servidor independiente. Tiene un conjunto de servidores que ofrecen
servicios a otros componentes (como impresión), clientes que solicitan los
servicios que ofrecen los servidores, red que permite a los clientes acceder a
dichos servicios.

5. Tuberia y filto: El procesamiento de datos se organiza de forma que cada

componente de procesamiento (filtro) sea discreto y realice un tipo de
transformación de datos, estos fluyen (como tuberia) de un componente a otro para
su procesamiento.

ARQUITECTURAS DE APLICACIÓN

Tienen la intención de cubrir las necesidades de una empresa u organización.

Encapsulan las principales características de una clase de sistemas, ejemplo de
esto son los sistemas ERP.
Es posible crear modelos de arquitecturas de aplicación para:

1. Punto de partida para el proceso de diseño arquitectonico (comenzar genérico

luego detalle)
2. Lista de verificación de diseño (verificar que el diseño sea consistente con la
arquitectura genérica)
3. Organizar el trabajo de desarrollo
4. Medio para valorar los componentes a reutilizar
5. Vocabulario para hablar acerca de tipos de aplicaciones

Ejemplos aplicaciones:

1. De procesamiento de transacción: Base de datos, procesan requerimientos mediante

información y la guardan.
2. Procesamiento de lenguaje: Se expresan las intenciones del usuario en lenguaje
formal (como Java). Un ejemplo son los compiladores.

SISTEMA DE PROCESAMIENTO DE TRANSACCIONES

TP, diseñados para procesar peticiones del usuario mediante información de una base
de datos, o requerimientos para actualizarla. Una transacción es cualquier
secuencia coherente de operaciones que satisfacen un objetivo. Ejemplo, buscar
vuelos, retirar dinero de un cajero, etc.

SISTEMAS DE INFORMACIÓN

Todos los sistemas que incluyen interaccion con una base de datos compartida se
consideran sistemas de información basados en transacciones. Permite acceso
controlado a una gran base de información como bibliotecas. También se consideran
sistemas de gestion de recursos,

SISTEMAS DE PROCESAMIENTO DE LENGUAJE

Convierten lenguaje natural o artificial en otra representación del lenguaje,

inclusive puede ejecutar el código resultante si son de programación. Ejemplos:
Compiladores, traductores, etc.

CAPITULO 7: DISEÑO E IMPLEMENTACIÓN

El diseño y la implementación del software es la etapa del proceso de ingenieria

del software en que se desaroolla un sistema de software ejecutable. En sistemas
simples, diseño e implementación es ingenieria del software y los demas procesos se
fusionan con este. Para sistemas grandes, estos son solo dos procesos de todos los
implicados (ingenieria de requerimientos, verificacion, validación, etc)

Diseño es la actividad creativa donde se identifican los componentes del software y

sus relaciones con los requerimientos. La implementación es el proceso de realizar
el diseño como un programa.

COTS: Commercial Off-The-Shelf

DISEÑO ORIENTADO A OBJETOS CON EL USO DE UML

Un sistema orientado a objetos se constituye con objetos que interactuan y

mantienen su prpio estado local, ofreciendo operaciones sobre dicho estado. Es mas
fácil modificar un sistema orientado a objetos que uno funcional

Para desarrollar un sistema desde el concepto hasta el diseño detallado orientado a

objetos se debe:

1. Comprender y definir el contexto y las interacciones externas con el sistema

2. Diseñar la arquitectura del sistema
3. Identificar los objetos principales en el sistema
4. Desarrollar modelos de diseño
5. Especificar interfaces

CONTEXTO E INTERACCIONES DEL SISTEMA

La primer etapa en cualquier proceso de diseño de software es desarrollar la

comprension de las relaciones entre el software que se diseñará y su ambiente
externo. Esto es esencial para decidir como proporcionar la funcionalidd requerida
del sistema, y como estructurar el sistema para que se comunique con su entorno.
Establecer las fronteras ayuda a decidir las caracteristicas que se implementarán.

1. Un modelo de contexto es un modelo estructural, que muestra a los otros sistemas

en el entorno del sistema a desarrollar
2. Un modelo de interacción es un modelo dinámico que indica la forma en que el
sistema interactúa con su entorno conforme se utiliza

DISEÑO ARQUITECTONICO

Identificar los principales componentes que constituyen el sistema y sus

interacciones, posteriormente, organice los componentes utilizando un patrón
arquitectónico como modelo en capas o cliente-servidor.

IDENTIFICACION DE CLASE DE OBJETO

Se debe tener ideas sobre los objetos esenciales del sistema que se diseña. La
descripción del caso de uso identifica objetos y operaciones del sistema, también
define el encapsulamiento de interacciones. Para identificar clases de objetos se
propone:

1. Análisis gramatical de una descripción en lenguaje natural del sistema. Objetos

y atributos son sustantivos, operaciones o servicios son verbos.

2. Usar entidades tangibles (cosas como naves), roles, eventos, interacciones,

ubicaciones, unidades organizacionales.

3. Emplear análisis basado en escenarios. Identificar objetos, atributos y

operaciones requeridos por cada escenario.

El conocimiento del dominio de aplicación se usa para identificar otros objetos,

atributos
y servicios. Se sabe que las estaciones meteorológicas se localizan generalmente
en lugares remotos e incluyen varios instrumentos que algunas veces funcionan mal.
Las
fallas en los instrumentos deben reportarse automáticamente. Esto implica que se
necesitan
atributos y operaciones para comprobar el buen funcionamiento de los instrumentos.

MODELOS DE DISEÑO

Muestran los objetos o clases de objetos en un sistema, asociaciones y relaciones

entre entidades. Estos modelos son el puente entre diseño e implementación, por eso
deben ser abstractos pero in perder mucho detalle que ayuda a los programadores a
tomar decisiones de implementación.

1. Modelos estructurales: Estructura estatica del sistema usando objetos y sus

relaciones
2. Modelos dinámicos: Estructura dinámica del sistema y muestran interacciones
entre objetos del sistema.

Los modelos más utiles al iniciar son:

1. Modelos de subsistema: Exponen agrupamientos lógicos de objetos en subsistemas

coherentes.
2. Modelos de secuencia: Secuencia de interacción de objetos
3. Modelos de máquina de estado: Como los objetos individuales cambian de estado en
respuesta a eventos

ESPECIFICACIÓN DE LA INTERFAZ

Es necesario especificar las interfaces de modo que los objetos y subsistemas

puedan diseñarse en paralelo, el diseño de interfaz se preocupa por la
especificación del detalle de la interfaz hacia un objeto o un grupo de objetos.
Las interfaces pueden especificarse en UML, pero no hay sección de atributos así
que debe incluirse el estereotipo UML <interface>

La semántica de la interfaz se define mediante el lenguaje de restricción de objeto

(OCL). El diseño no debe incluir detalles de la representación de datos, los
atributos no se definenen en una especificación de intefaz. Sin embargo, debe
contener operaciones para acceder a los datos y actualizarlos. Ejemplo, una
representación de arreglo en pila puede cambiarse por una lista, sin afectar otros
objetos que usen la pila.

PATRONES DE DISEÑO

Es una descripción del problema y la esencia de su solución, de modo que la

solución puede reutilizarse en diferentes configuraciones. Es una descripción de
sabiduría y experiencia acumulada, una solución bien probada a un problema común.

Los patrones y los lenguajes de patrón son formas de describir mejores prácticas,
buenos diseños, y captan la experiencia de tal manera que es posible que otros
reutilicen esta experiencia.

Se usan más en diseño orientado a objetos, se apoyan en características como

herencia, polimorfismo y encapsulamiento.

Los cuatro elementos esenciales de los patrones de diseño, definidos por la “Banda
de
los cuatro” en su libro de patrones, son:

1. Un nombre que sea una referencia significativa al patrón.

2. Una descripción del área problemática que enuncie cuándo puede aplicarse el
patrón.
3. Una descripción de solución de las partes de la solución de diseño, sus
relaciones y
responsabilidades. No es una descripción concreta de diseño; es una plantilla para
que una solución de diseño se instale en diferentes formas. Esto con frecuencia se
expresa gráficamente y muestra las relaciones entre los objetos y las clases de
objetos
en la solución.
4. Un estado de las consecuencias, los resultados y las negociaciones, al aplicar
el patrón.
Lo anterior ayuda a los diseñadores a entender si es factible usar o no un patrón
en una
situación particular.

CONFLICTOS DE IMPLEMENTACIÓN

La ingeniería de software incluye todas las actividades implicadas en el desarrollo

de
software, desde los requerimientos iniciales del sistema hasta el mantenimiento y
la
administración del sistema desplegado

1. Reutilización: Debe usarse el código existente tanto como sea posible

2. Administración de la configuración: Al crear muchas versiones de cada
componente, no seguir la huella podría causar que se incluyan las versiones
equivocadas de dichos componentes
3. Huésped-objetivo: La producción de software no se ejecuta por lo
general en la misma computadora que el entorno de desarrollo de software. En vez
de ello, se diseña en una computadora (el sistema huésped) y se ejecuta en una
computadora separada (el sistema objetivo). Los sistemas huésped y objetivo son
algunas veces del mismo tipo, aunque suelen ser completamente diferentes

REUTILIZACIÓN

1. Nivel Abstracción: Se reutiliza no el código, sino, patrones de diseño y

arquitectonicos, y conocimientos exitosos
2. Nivel objeto: Reutilizar objetos de una libreria en vez de escribirlo (como
JavaMail)
3. Nivel componente: Colecciones de objetos y clases de objeto que operan en
conjunto para brindar funciones y servicios. A veces se debe adaptar y extender el
componente al agregar código como interfaces al marco (framework), plantillas, etc.
4. Nivel sistema: Se reutilizan sistemas de aplicaciones completos, COTS.

Costos de reutilizar software existente:

1. Costos de tiempo empleado en buscar un software y asegurarse que funcionará en

el entoro
2. Costo de compra puede ser elevado
3. Costo de adaptar y configuar el software para los requerimientos
4. Cosos de integrar elementos de software unos con otros, es muy complicado y
legal también modificar código del software

ADMINISTRACIÓN DE LA CONFIGURACIÓN

1. Gestión de versiones, para evitar que un código sobreescriba otro enviado por
alguien más
2. Integración del sistema, que versiones de componentes integran una versión del
sistema
3. Rastreo de problemas: Soporte a usuarios para reportar bugs
DESARROLLO HUESPED-OBJETIVO

El software se desarrolla en una computadora (huésped) y opera en una máquina

separada (objetivo). Desarrollo/Ejecución. Algunas herramientas son: Compilador,
depurador, editores gráficos, de prueba como JUnit, apoyo de proyecto como
versionado

Al decidir sobre la plataforma, se debe considerar los conflictos:

1. Requerimientos de hardware/software de un componente

2. Disponibilidad de sistema HA
3. Comunicaciones de componentes (si hay alto tráfico lo mejor es que todos los
componentes estén en la misma plataforma o cercanas entre si)

DESARROLLO DE CÓDIGO ABIERTO

Se publica el código y se invita a voluntarios a participar en el desarrollo,

LICENCIA DE CÓDIGO ABIERTO

Legalmente, el propietario sigue siendo una compañia o individuo, por tanto, suele
incluirse la licencia de software de código abierto donde si el componente es
abierto, el software a desarrollar con el también debe serlo.

1. La licencia pública general GNU se conoce como licencia “recíproca”; de manera

simple, significa que si usted usa software de código abierto que esté permitido
bajo
la licencia GPL, entonces debe hacer que dicho software sea de código abierto.

2. La licencia pública menos general GNU es una variante de la licencia anterior,

en
la que usted puede escribir componentes que se vinculen con el código abierto, sin
tener que publicar el código de dichos componentes. Sin embargo, si cambia el
componente
permitido, entonces debe publicar éste como código abierto.

3. La licencia Berkeley Standard Distribution es una licencia no recíproca, lo cual

significa que usted no está obligado a volver a publicar algún cambio o
modificación
al código abierto. Puede incluir el código en sistemas propietarios que se vendan.
Si
usa componentes de código abierto, debe reconocer al creador original del código.

CAPITULO 8: PRUEBAS DE SOFTWARE

Pruebas intentan demostrar que un program hace lo que se intenta que haga. Metas:

1. Demostrar al desarrollador y al cliente que el software cumple con los

requerimientos.
2. Encontrar situaciones donde el comportamiento del software sea incorrecto.

La primera conduce a la prueba de validación, que el sistema se desempeñe de manera

correcta mediante un conjunto dado de casos de prueba.
La segunda se orienta a pruebas de defectos, para demostrar malos usos del sistema.
Las pruebas no pueden demostrar que no existan defectos.

Las pruebas pueden mostrar sólo la presencia de errores, mas no su ausencia.

El V&V (validación y verificación)

“Validación: ¿construimos el producto correcto?”.
“Verificación: ¿construimos bien el producto?”.

Niveles de confianza:

1. Proposito del software: Entre más crítico, mas importante su confiabilidad, como
uno de seguridad.
2. Expectativas del usuario: Debido a experiencia con software no confiable y con
errores, muchos usuarios no se sorprenden cuando este falla. Esto permite usar
menos tiempo en pruebas pero mejorar el software con cada versión posterior
3. Entorno de mercado: Si el software es más barato, los usuarios tal vez toleren
un nivel menor de fiabilidad. Pero hay que tener en cuenta la comptenencia, el
precio y fechas de entrega.

Etapas de pruebas:

1. Desarrollo: Se pone a prueba durante el proceso descubrir errores (bugs) y

defectos.
2. Versiones de prueba: Un equipo experimenta una versión completa del sistema
antes de presentarlo a los usuarios.
3. Pruebas de usuario: Donde los usuarios reales prueban el sistema en su propio
entorno.

PRUEBAS DE DESARROLLO

Depuración: Debugging es el proceso para corregir los errores descubiertos por las
pruebas.

1. Pruebas de unidad: Se ponen a prueba unidades de programa o clases de objetos

individuales.
2. Pruebas de componentes: Muchas unidades individuales se integran para crear
componentes compuestos
3. Pruebas del sistema: Algunos componentes en un sistema se integran y el sistema
se prueba como un todo.

CASOS DE PRUEBA

Algunos de los lineamientos más generales que se sugiere son:

■ Elegir entradas que fuercen al sistema a generar todos los mensajes de error;
■ Diseñar entradas que produzcan que los buffers de entrada se desborden;
■ Repetir varias veces la misma entrada o serie de entradas;
■ Forzar la generación de salidas inválidas;
■ Forzar resultados de cálculo demasiado largos o demasiado pequeños.

PRUEBAS DE COMPONENTES

1. Interfaces de parametro
2. Interfaces de memoria compartida (un bloque de memoria se reparte entre
componentes como sistemas embebidos)
3. Interfaces de procedimiento (encapsulamiento de metodos, reutilización por otros
componentes)
4. Interfaces que pasan mensajes (cliente-servidor)

ERRORES DE INTERFAZ

1. Uso incorrecto de interfaz (parametros incorrectos)

2. Mala interpretación de interfaz (componente no se comporta como se esperaba)
3. Errores de temporización (el consumidor es más rápido y puede acceder a
información incorrecta)

PRUEBAS DEL SISTEMA

Las pruebas del sistema durante el desarrollo incluyen la integración de

componentes
para crear una versión del sistema y, luego, poner a prueba el sistema integrado.
Las
pruebas de sistema demuestran que los componentes son compatibles, que interactúan
correctamente y que transfieren los datos correctos en el momento adecuado a través
de
sus interfaces.

Diferencias con las pruebas de componentes:

1. Componentes reutilizables y los sistemas comerciales se integran para probar el

sistema completo
2. Componentes desarrollados por diferentes miembros se integran y se prueban como
un todo

DESARROLLO DIRIGIDO POR PRUEBAS

Test-Driven Development, el código se desarrolla incrementalmente, junto a su

respectiva prueba. Parte de metodos ágiles como la programación exterma. Aunque
puede usarse en desarrollo basado en plan.

1. Se comienza por identificar el incremento de funcionalidad requerido. Éste

usualmente
debe ser pequeño y aplicable en pocas líneas del código.

2. Se escribe una prueba para esta funcionalidad y se implementa como una prueba
automatizada. Esto significa que la prueba puede ejecutarse y reportarse, sin
importar
si aprueba o falla.

3. Luego se corre la prueba, junto con todas las otras pruebas que se
implementaron.
Inicialmente, no se aplica la funcionalidad, de modo que la nueva prueba fallará.
Esto es deliberado, pues muestra que la prueba añade algo al conjunto de pruebas.

4. Luego se implementa la funcionalidad y se opera nuevamente la prueba. Esto puede

incluir la refactorización del código existente, para perfeccionarlo y adicionar
nuevo
código a lo ya existente.

5. Una vez puestas en funcionamiento con éxito todas las pruebas, se avanza a la
implementación de la siguiente funcionalidad.

Beneficios:

1. Cobertura de código: Cada codigo tiene su respectiva prueba

2. Regresión: Demostrar que los cambios no introdujeron nuevos bugs al correr
pruebas viejas
3. Simplifación: Cuando una prueba falla, es evidente donde yace el problema
4. Documentación del sistema: Las pruebas actúan como una forma de documentación de
lo que debe hacer el código

PRUEBAS DE VERSIÓN
Existen dos distinciones importantes entre pruebas de versión y pruebas del sistema

1. Un equipo independiente que no intervino en el desarrollo del sistema debe ser

responsable de las pruebas de versión

2. Las pruebas del sistema por parte del equipo de desarrollo deben enfocarse en el
descubrimiento de bugs en el sistema (pruebas de defecto). El objetivo de las
pruebas
de versión es comprobar que el sistema cumpla con los requerimientos y sea
suficientemente bueno para uso externo (pruebas de validación).

PRUEBAS BASADAS EN REQUERIMIENTOS

Los requerimientos tienen que escribirse de forma que pueda diseñarse una prueba
para dicho requerimiento

PRUEBAS DE ESCENARIO

Las pruebas de escenario son un enfoque a las pruebas de versión donde se crean
escenarios
típicos de uso y se les utiliza en el desarrollo de casos de prueba para el
sistema.

PRUEBAS DE RENDIMIENTO

Rendiminto y confiabilidad. Garantizar que el sistema procese su carga pretendida.

PRUEBAS DE USUARIO

Las pruebas de usuario o del cliente son una etapa en el proceso de pruebas donde
los
usuarios o clientes proporcionan entrada y asesoría sobre las pruebas del sistema

1. Pruebas alfa, donde los usuarios del software trabajan con el equipo de diseño
para
probar el software en el sitio del desarrollador.

2. Pruebas beta, donde una versión del software se pone a disposición de los
usuarios,
para permitirles experimentar y descubrir problemas que encuentran con los
desarrolladores
del sistema.

3. Pruebas de aceptación, donde los clientes prueban un sistema para decidir si

está o no
listo para ser aceptado por los desarrolladores del sistema y desplegado en el
entorno
del cliente.

PRUEBAS DE ACEPTACIÓN

1. Definir los criterios de aceptación (antes de firmar el contrato por el

sistema)
2. Plan de pruebas de aceptación (recursos, tiempo y presupuesto para pruebas de
aceptación, calendario de pruebas, en orden de requerimientos, mitigar posibles
fallos)
3. Derivar pruebas de aceptación (Pruebas para comprobar si un sistema es aceptable
o no, tanto caracteristicas funcionales como no funcionales como rendimiento)
4. Correr pruebas de aceptación (Las pruebas acordadas se ejecutan sobre el
sistema)
5. Negociar resultados de pruebas (Es poco probable que se pasen todas las
pruebas de aceptación definidas y que no haya problemas con el sistema. Si éste es
el caso, entonces las pruebas de aceptación están completas y el sistema está listo
para entregarse. Con mayor regularidad se descubrirán algunos problemas. En tales
casos, el desarrollador y el cliente tienen que negociar para decidir si el sistema
es suficientemente adecuado para ponerse en uso.)
6. Rechazo/aceptación (Esta etapa incluye una reunión entre los desarrolladores
y el cliente para decidir si el sistema debe aceptarse o no. Si el sistema no
es suficientemente bueno para usarse, entonces se requiere mayor desarrollo para
corregir los problemas identificados. Una vez completo, se repite la fase de
pruebas
de aceptación.)

CAPITULO 9: EVOLUCIÓN DEL SOFTWARE

El desarrollo del software no se detiene cuando un sistema se entrega, sino que

continúa a lo largo de la vida de éste, para modificarlo y mantenerlo útil.

Software subutilizado: Cuando tiene que desarrollarse y gestionarse en un ambiente

donde depende de muchos otros sistemas de software.

En el 85~90% de empresas, la mayor parte de presupuesto va a mantener el software

más que a crear uno nuevo

Proceso espiral: Requerimientos, diseño, implementación y pruebas continuas a lo

largo de la vida del sistema.

Evolución y servicio: Visión alternativa del ciclo de vida de evolució del software

1. Desarrollo inicial
2. Evolución (cambios significativos)
3. Servicio (cambios pequeños)
4. Retiro gradual

Cuando un software se modifica mucho, se degrada por tanto cambio en la

arquitectura y se llega a un punto donde seguir evolucionando es muy caro. Ideal
para considerar usar ese esfuerzo en un nuevo software.

Identificación del cambio:

1. Proceso de identificación del cambio

2. Propuestas de cambio
3. Proceso de evolución del software
4. Nuevo sistema

PROCESOS DE EVOLUCIÓN

Varian dependiendo del tipo de software, de los procesos de desarrollo y las

habilidades de las personas que intervienen. Algunos son informales basados en las
conversaciones entre usuarios del sistema, otras se basan en documentación
estructurada.

Proceso:

1. Peticiones de cambio
2. Análisis de impacto
3. Planeación de la versión (Reparación de fallas, adaptación de plataforma, mejora
del sistema)
4. Cambio de implementación
5. Liberación del sistema

El problema surge cuando es necesario realizar reparaciones de emergencia, que se

salta el proceso de análisis de riesgo y posiblemente rompa algunos componentes,
teniendo que realizar más reparaciones, al final, el cambio original se olvida y la
documentación y el código del sistema nunca se realinean.

Problemas de transferencia entre equipo de desarrollo y de evolución:

1. El de desarrollo usó un método ágil y el de evolución solo sepa usar planeación,

la falta de documentación del ágil supondrá problemas.
2. El de desarrollo usó planeación y el de evolución usará ágil, causando que se
deba escribir desde cero pruebas automatizadas, además de posible ausencia de
refactorización de código

LEYES DE LEHMAN

1. Mantenimiento del sistema es un proceso inevitable, al modificar el sistema se

cambia el entorno y el proceso de evolución comienza de nuevo

2. Conforme cambia un sistema, su estructura se degrada, para evitarlo, debe

invertirse en mantenimiento preventivo, se invierte tiempo mejorando la estructura
del software sin agregar nada a su funcionalidad.

3. Los sistemas grandes tienen una dinámica propia que se establece es una etapa
temprana del proceso de desarrollo, esto determina grandes tendencias del
mantenimiento del sistema y limita el numero de cambios posibles.

4. La mayoria de los grandes proyectos de programación funcionan en un estado

saturado, los grandes equipos de desarrollo con frecuencia son improductivos porque
los gastos en comunicación dominan el trabajo en equipo

5. Agregar nueva funcionalidad al sistema introduce inevitablemente nuevas fallas

al mismo.

6. Los usuarios son cada vez más infortunados con el sistema, a menos que se le
mantenga y agregue nueva funcionalidad

7. Procesos de retroalimentación

MANTENIMIENTO DEL SOFTWARE

Es el proceso general de cambiar un sistema despues que se entregó, los tipos son:

1. Reparación de fallas
2. Adaptación ambiental (como cambios del sistema o hardware)
3. Adición de funcionalidad

Mantenimiento correctivo: Reparación de fallas

Mantenimiento adaptativo: Adaptarse a un nuevo entorno

Mantenimiento perfectivo: Perfeccionar el software al implementar nuevos

requerimientos, o mejorar su rendimiento y estructura.

2/3 de presupuesto van a mantenimiento, 1/3 a desarrollo. Si se usá mas esfuerzo e

inversion en crear un software mantenible, se puede lograr ahorrar una gran
cantidad de costos de mantenimiento porque se reducen los costos de la comprensión,
analisis y pruebas.

En general, resulta más costoso agregar funcionalidad después de que un sistema

está en
operación, que implementar la misma funcionalidad durante el desarrollo. Las
razones son:

1. Estabilidad del equipo (los individuos se separan o van a otros proyectos)

2. Práctica de desarrollo deficiente (si el mantenimiento va a una compañia

diferente, el
programador prefiere hacer el código rápido sin pensar en mantenibilidad pues el no
lo va hacer)

3. Habilidades del personal (personal inexperto, no hay familiaridad con el

sistema, lenguajes obsoletos que los novatos a quienes les dan el mantenimiento no
conocen)

4. Antigüedad y estructura del prorama

Para evaluar las relaciones entre un sistema y su ambiente, se debe valorar:

1. Numero y complejidad de interfaces del sistema

2. Numero de requerimientos inherentemente inestables

3. Procesos empresariales donde se usa el sistema

Después de poner en servicio un sistema, se deben usar datos de proceso para

auxiliarse a predecir la mantenibilidad. Los siguientes son ejemplos de métricas de
proceso que sirven para valorar la mantenibilidad:

1. Numero de peticiones de mantenimiento correctivo (si hay mas bugs luego de una
reparación hay un declive de mantenibilidad)

2. Tiempo promedio requerido para análisis del impacto (Si el tiempo aumenta, es
porque muchos componentes se vieron afectados y la mantenibilidad decrece)

3. Tiempo promedio tomado para implementar una peticion de cambio (tiempo necesario
para modificar el sistema)

4. Numero de peticiones de cambio pendientes (si aumenta, es porque hay un declive

de mantenibilidad)

REINGENIERÍA DE SOFTWARE

Proceso de evolución incluye comprender el programa a cambiarse e implementar esos

cambios. Pero algunos programas son difíciles de entender y cambiar. Para que el
sistem heredado sea más sencillo de mantener, se puede someter a reingenieria para
mejorar su estructura y rendimiento. Documentar, refactorizar, usar lenguajes
modernos. Beneficios:

1. Reducción del riesgo (hay un alto riesgo de cometer errores al desarrollar

software comercial)
2. Reducción de costos (puede ser más barata la reingenieria que el desarrollo de
software nuevo)
Actividades del proceso de reingenieria:

1. Traducción del código fuente

2. Ingenieria inversa
3. Mejoramiento de la estructura
4. Modularización del programa
5. Reingenieria de datos

MANTENIMIENTO PREVENTIVO MEDIANTE REFACTORIZACIÓN

Proceso de hacer mejoras a un programa para frenar la degradación mediante el

cambio. Mejorar su estructura, reducir complejidad. No hay que agregar
funcionalidad en este proceso.

La reingenieria se lleva a cabo después de haber mantenido un sistema durante

cierto tiempo, causando que los cosos de manenimiento aumenten.

La refactorización es parte de los métodos ágiles, es un proceso continuo de

mejoramiento debido al proceso de desarrollo y evolución. Como los ágiles cambian
mucho, los programadores refactorizan siempre que es posible para reducir la
degradación de la estructura

Malos olores que se pueden arreglar por refactorización:

1. Código duplicado
2. Métodos largos
3. Enunciados de switch (cambiar por polimorfismo)
4. Aglomeración de datos (mismo grupo de datos ocurren en muchos lugares del
programa, corregir con un objeto que los encapsule)
5. Generalidad especulativa (cuando se incluye generalidad en caso que se requiera
en el futuro)

ADMINISTRACIÓN DE SISTEMAS HEREDADOS:

Estrategias de evolución de sistemas:

1. Desechar completamente el sistema

2. Dejar sin cambios el sistema y continuar el mantenimiento regular
3. Someter el sistema a reingenieria para mejorar su mantenibilidad
4. Sustituir todo o parte del sistema con un nuevo sistema

Grupos de sistemas:

1. Baja calidad, bajo valor empresarial (desecharse)

2. Baja calidad, alto valor empresarial (reingenieria)
3. Alta calidad, bajo valor empresarial (no sustituir a menos que los cambios sean
costosos)
4. Alta calidad, alto valor empresarial (continuar el mantenimiento normal del
sistema)

Calcular el valor empresarial de un sistema:

1. Uso del sistema

2. Los procesos empresariales que se mantienen (si fuerza procesos empresariales
obsoletos o no)
3. Confiabilidad del sistema
4. Salidas del sistema (si la empresa depende de esas salidas es alto valor)
Calcular valoración de calidad

1. Numero de peticiones de cambio del sistema

2. Numero de interfaces de usuario (entre más, más probabilidad de existencia de
inconsistencias y redundancias)
3. Volumen de datos usados por el sistema (entre más alto numero de archivos, base
de datos, más probable será la inconsistencia de datos)

CAPITULO 10: SISTEMAS SOCIOTÉCNICOS

Sin hardware no hay software, y sin software no hay hardware. Un sistema es la suma
de sus partes, sus propiedades no son evidentes hasta que sus componentes de
integran

Cuando los sistemas son más amplios, porque se conecta a hardware, a otros
sistemas, incluyen procesos, entonces se les llama sociotécnicos.

Los sistemas sociotécnicos deben verse como capas:

1. Equipo: Dispositivos de hardware

2. Sistema operativo: Interactúa con hardware y ofrece facilidades para capas

superiores

3. Comunicaciones y gestión de datos: Interfaz para interacción con sistemas

remotos, bases de datos. También se le conoce como Middleware, por estar entre la
aplicación y el sistema operativo

4. Aplicaciones: Entrega la funcionalidad específica, pueden haber varios programas

diferentes

5. Proceso empresarial: Se definen y establecen procesos empresariales de la

organización que usa el software

6. Organización: Procesos estratégicos de alto nivel como reglas, políticas, normas

de la empresa para usar el sistema

7. Social: Leyes y regulaciones de la sociedad

Es preciso examinar cómo interactúa el software con su entorno inmediato para

garantizar que:

1. Fallas de operación del software estén contenidas dentro de las capas del
sistema, sin afectar capas adjuntas. No deben conducir a fallas de operación del
sistema.

2. Entender como las fallas del desarrollo y operación en las capas, que no son del
software, llegan afectar al software.

SISTEMAS COMPLEJOS

Un sistema es una colección intencionada de componentes interrelacionados, de

diferentes tipos, que trabajan en conjunto para lograr algún objetivo

Subsistema: Sistemas que pueden operar por cuenta propia como independiente

Categorías de software:

1. Sistemas técnicos basados en computadora: TV, teléfonos, juegos. Un procesador

de texto no sabe si fue utilizado para crear un libro.
2. Sistemas sociotécnicos: Incluyen individuos que entienden el proposito del
sistema, tienen procesos operacionales definidos, los operadores son parte
inherente del sistema. Están administrados por políticas y reglas organizacionales,

Factores organizacionales que afectan al sistema sociotécnico:

1. Cambios de procesos
2. Cambios laborales
3. Cambios en la organización

Características de seguridad y confiabilidad de sistemas sociotécnicos:

1. Propiedades emergentes: Solo se evalúan cuando el sistema está ensamblado, como

seguridad y confiabilidad

2. No deterministas: Una entrada específica puede que no produzca siempre la misma

salida.

3. Amplitud con el que el sistema apoya los objetivos de la organización no solo

depende del sistema, sino también de la administración

PROPIEDADES EMERGENTES DEL SISTEMA

Son propiedades que son propiedades del sistema como un todo, ya ensamblado. Hay
dos tipos:

1. Propiedades emergentes funcionales: Cuando el proposito solo surge después de

integrar sus componentes

2. Propiedades emergentes no funcionales: Se relacionan con el comportamiento del

sistema en su entorno operacional, Fiabilidad, rendimiento, seguridad, protección.

En un sisema sociotécnico, se debe considerar la fiabilidad desde tres

perspectivas:

1. Fiabilidad del hardware: ¿Cuál es la probabilidad de que los componentes de

hardware fallen y cuánto tiempo tardaría en repararse un componente averiado?

2. Fiabilidad del software: ¿Cuál es la probabilidad de que un componente de soft-

ware produzca una salida incorrecta? El sistema suele seguir funcionando después de
producir un resultado incorrecto

3. Fabilidad del operador: ¿Cuán probable es que el operador de un sistema cometa

un error y proporcione una entrada incorrecta? ¿Cuán probable es que el software
falle para detectar este error y lo propague?

Los 3 no son independientes, uno puedo causar el otro, como un usuario estresado.

NO DETERMINISMO

Un sistema determinista es uno completamente predecible, producen siempre la misma

salida. Los sistemas sociotécnicos no son deterministas porque las personas que los
usan pueden usar entradas y procesos diferentes para lograr el mismo resultado
además, el software, hardware y datos cambian de manera frecuente.

CRITERIOS DE ÉXITO

Los sistemas sociotécnicos se usan para enfrentar a los "problemas malvados". Un

problema malvado es aquel que es tan complejo y que implica tantas entidades
relacionadas que no hay especificación definitiva del problema. ¿Como determinar si
un nuevo sistema contribuye, en base a lo planteado y las metas? osea si es éxitoso
o no.
Desde un punto de vista un sistema puede causar conflictos entre metas, pero mejora
algo como seguridad. Pero si sufre un ataque ¿es porque fue un fracaso? No se sabe
a menos que podamos saber si sufrió menos daño que un ataque al sistema anterior
que sustituyó.

INGENIERIA DE SISTEMAS

Abarca todas las actividades que hay en la procuración, especificación, diseño,

implementación, validación y despliegue. El ingeniero no solo se preocupa por el
software, sino también por hardware y las interacciones con el usuario y su
entorno. Pensar en servicios, restricciones de construcción y operación, así como
formas para cumplir el proposito del software. Existen tres etapas que se traslapan
en la vida de los sistemas sociotécnicos grandes y complejos:

1. Procuración o adquisición: Decidir proposito del sistema, establecer

requerimientos de alto nivel, decisiones de funcionalidad en hardware, software y
personal, adquirir los componentes que constituirán el sistema.

2. Desarrollo: Diseñar el sistema, definir requerimientos, diseñar el sistema,

ingenieria del hardware y software, integración y pruebas del sistema. Definir
procesos operacionales y diseñar cursos de capacitación para los usuarios.

3. Operación: Implementar el sistema, capacitar usuarios, poner en funcionamiento

el sistema, evolucionar el sistema con nuevos requerimientos y cuando declina en
valor, se retira el servicio activo para reemplazarse.

La ingenieria de sistemas incluye otras disciplinas como eletronica a lo largo de

la vida del sistema. Arquitectos, ingenieros civiles, etc. Esta inclusión puede
causar problemas de seguridad por ejemplo:

1. Diferentes disciplinas usan las mismas palabras para cuestiones distintas. Como
función en C es un Metodo en Java.

2. Suposiciones de una disciplina acerca de otra, como un diseñador UI/UX creara

una UI demasiado pesada y difícil de renderizar en un sistema embebido sin suponer
carga del CPU

3. Las disciplinas tratan de proteger sus fronteras profesionales al justificar

ciertas decisiones de diseño basadas en experiencia profesional, como un ingeniero
de software cuestioando un sistema de seguridad de puertas por software, cuando
sería más fiable un sistema mecánico basado en llaves.

PROCURACIÓN DEL SISTEMA

Es la fase inicial de la ingeniería de sistemas, es la toma de decisiones sobre el

ámbito de un sistema que se adquirirá, presupuestos, plazos, requerimientos de alto
nivel. Controladores para talees decisiones son:

1. Estado de otros sistemas de la organización: Si la organización tiene sistemas

que no se comunican bien o son costosos, un sistema de reemplazo proveerá
beneficios signficativos.

2. Necesidad de cumplir con regulaciones externas: Podría requerir la sustitución

de los sistemas que no cumplen o provisión de nuevos sistemas específicamente para
monitorizar el cumplimiento.

3. Competencia externa: Si la empresa desea competir de forma más efectiva, o

mantener una buena posición competitiva, es mejor invertir en sistemas que mejoren
los procesos empresariales.

4. Reorganización empresarial: Las empresas y organizaciones se reestructuran

frecuentemente con la intención de mejorar la eficiencia y/o servicio al cliente.

5. Presupuesto disponible

Puntos importantes del proceso de procuración del sistema:

1. Definición de requerimientos empresariales

2. Estudio de mercado para sistemas existetes

Sistema comercial disponible: Adaptar requerimientos, valoración de sistemas

existentes, elección del proveedor del sistema, negociación de contrato.

Personalización del sistema requerido: Definición de requerimientos, emisión de

solicitud de licitación, seleccionar al licitador, negociación del contrato.

Tomar en cuenta que:

1. Los componentes comerciales no cubren con exactitud los requerimientos. Hay que
buscar la coincidencia más cercada. Quiza sea necesario modificar los
requerimientos, pero podria causar problemas en subsistemas.

2. Si se construye a la medida, la especificación de requerimientos forma parte del

contrato para el sistema que se va adquirir, por consiguiente, se trata de un
documento tanto legal como técnico.

3. Después de seleccionar a un contratista para construir un sistema, hay un

periodo
de negociación del contrato en que quizá se tengan que negociar más cambios a los
requerimientos, y discutir temas como el costo de los cambios al sistema. De igual
modo, una vez seleccionado un sistema COTS, posiblemente se deba negociar con
el proveedor acerca de costos, condiciones de licencia, posibles cambios al
sistema,
etcétera.

DESARROLLO DEL SISTEMA

Metas del proceso de desarrollo del sistema son diseñar o adquirir los componentes
de un sistema, integrarlos y elaborr el sistema final. Requerimientos son el puente
entre procesos de procuración de desarrollo.

Los procesos derivados de un plan se utilizan en la ingeniería de sistemas, ya que

diferentes partes del sistema se desarrollan al mismo tiempo.

Hay seis actividades fundamentales en cuanto al desarrollo de sistemas:

1. Desarrollo de requerimientos
2. Diseño del sistema (subsistemas se desarrollan en paralelo)
3. Ingenieria de subsistemas
4. Integración del sistema
5. Pruebas del sistema
6. Implementación del sistema
Usar integración inclemental, porque:

1. Generalmente es imposible programar el desarrollo de los subsistemas para que

terminen al mismo tiempo
2. Integración incremental reduce el costo de localización del error.

OPERACIÓN DEL SISTEMA

Los procesos operacionales son aquellos que están relacionados con el uso del
sistema
para su propósito definido. Aunque el sistema se desempeñe de acuerdo con las
especifica-
ciones, probablemente sus funciones no cubran las necesidades operacionales reales,
quiza el usuario no use el sistema como pretendían los diseñadores.

ERROR HUMANO

1. Enfoque personal: Los errores se consideran responsabilidad del individuo y

los “actos inseguros” (como un operador que falla al implementar una barrera de
seguridad) son consecuencia de un descuido individual o un comportamiento impru-
dente. Las personas que adoptan este enfoque creen que los errores humanos suelen
reducirse con amenazas disciplinarias, procedimientos más rigurosos, capacitación
adicional, etcétera. Su visión es que el error es culpa del individuo responsable
por
cometer la falla.

2. Enfoque de sistemas: El supuesto básico es que las personas son falibles y se

equivocarán. Los errores que la gente comete por lo general son consecuencia de
deci-
siones de diseño del sistema, que llevan a formas erróneas de trabajar, o bien, de
facto-
res de la organización, que afectan a los operadores del sistema. Los sistemas
eficaces
tienen que reconocer la posibilidad del error humano, e incluir barreras y
protecciones
que los detecten, y permitir al sistema recuperarse antes de que ocurra la falla.
Cuando
ésta sucede, la prioridad no es encontrar al individuo para echarle la culpa, sino
enten-
der cómo y por qué las protecciones del sistema pasaron por alto el error.

Para reducir la probabilidad de que las fallas del sistema sean

producto del error humano, los diseñadores tienen que:

1. Diseñar un sistema que incluya diferentes tipos de barreras. Esto significa que
los
“orificios” probablemente estarán en diferentes lugares y, por lo tanto, hay una
posi-
bilidad menor de que los orificios se alineen y fracasen para detectar un error.
2. Minimizar el número de condiciones latentes en un sistema. Efectivamente, esto
significa reducir el número y el tamaño de los “orificios” del sistema.

EVOLUCIÓN DEL SISTEMA:

Los sistemas grandes y complejos tienen una vida muy larga. Durante ella, cambian
para
corregir errores en los requerimientos originales del sistema e implementar los
nuevos
requerimientos que hayan surgido. Es probable que las computadoras del sistema se
susti-
tuyan por máquinas nuevas y más rápidas. La organización que usa el sistema puede
reor-
ganizarse a sí misma y, por consiguiente, usar el sistema en una forma diferente.
El entorno
externo del sistema llega a variar, lo cual forzaría los cambios al sistema. En
consecuencia,
la evolución, donde el sistema se modifica para acomodar el cambio ambiental, es un
pro-
ceso que funciona junto con los procesos operacionales normales del sistema. La
evolución
del sistema implica reingresar al proceso de desarrollo para realizar cambios y
extensiones
al hardware, el software y los procesos operacionales del sistema.

CAPITULO 11: CONFIABILIDAD Y SEGURIDAD

La confiabilidad de los sistemas es ahora usualmente más importante que su

funcionalidad detallada por las siguientes razones:

1. Las fallas del sistema afectan a un gran número de individuos

2. Los usuarios rechazan a menudo los sistemas que son poco fiables
3. Los costos por las fallas del sistema suelen ser enormes
4. Los sistemas no confiables pueden causar pérdida de información

Al diseñar un sistema confiable se debe considerar:

1. Falla del hardware

2. Falla en el desarrollo de software
3. Falla de operación

Confiabilidad: Propiedad del sistema que refleja su fiabilidad, grado de confianza

que un usuario tiene que el sistema ejecutará como se espera, y que el sistema no
fallará en su uso normal. En ocasiones, la utilidad vale la pena de que el sistema
no sea tan confiable, como que un procesador de texto se congele. Pero para
compensar la falta de confianza, el usuario guarda constantemente su trabajo.

Dimensiones de la confiabilidad:

1. Disponibilidad: Probabilidad de que en un momento dado el software funcionará,

ejecutará y ofrecerá servicios útiles a los usuarios.

2. Fiabilidad: Probabilidad de que durante un tiempo determiado, el sistema

brindará correctamente servicios como espera el usuario

3. Protección: Es un juicio de cuán probable es que el sistema causará daños a las

personas o a su ambiente.

4. Seguridad: Juicio de cuán probable es que el sistema pueda resistir intrusiones

accidentales o deliberadas

También se pueden considerar las siguientes:

1. Reparabilidad: En caso de falla, que el sistema pueda reparase rápidamente

2. Mantenibilidad: Economicamente se adapta para lidiar con nuevos requerimientos,

mientras mantiene baja probabilidad de que los cambios inserten nuevos errores en
el sistema
3. Supervivencia: Habilidad de continuar entregando servicio cuando está bajo
ataque y con partes deshabilitadas

4. Tolerancia para el error: Refleja la medida en que el sistema se diseño de modo

que se eviten y toleren los errores de entrada de usuario.

Para desarrollar software confiable:

1. Evitar entrada de errores accidentales en el sistema durante especificación y

desarrollo
2. Diseñar procesos de verificación y validación para descubrir errores
3. Desarrollar mecanismos de protección contra ataques externos
4. Configurar correctamente el sistema y el software para el entorno operacional

DISPONIBILIDAD Y FIABILIDAD

1. Fiabilidad: Probabilidad de operación libre de falla durante cierto tiempo

2. Disponibilidad: Probabilidad de que un sistema, en un momento en el tiempo, sea
operativo y brinde los servicios solicitados

Las fallas en el desarrollo no siempre derivan en errores, y los errores del

sistema no necesariamente originan caídas del sistema por las siguientes razones:

1. No todo el código de un programa se ejecuta: El código que incluye una falla

quizá nunca se ejecute debido a la forma en que se utiliza un sistema

2. Los errores son transitorios: Quiza una variable tiene un error incorrecto, pero
antes que se acceda a ésta otro proceso la inicialice con un valor correcto

3. El sistema puede incluir mecanismos de detección de fallas y protección.

Algunos usuarios saben que causa una caída del sistema, así que evitan usar
entradas que saben que las causan.

Enfoques para mejorar la fiabilidad de un sistema:

1. Prevención de fallas de desarrollo

2. Detección y eliminación de fallas en el desarrollo
3. Tolerancia a fallas en el desarrollo

PROTECCIÓN

Los sistemas críticos para la protección son aquellos en los que resulta esencial
que la operación del sistema sea segura en todo momento, nunca debe dañar a
personas o a su entorno.

Software crítico para la protección se divide en dos clases:

1. Software primario crítico para la protección: Software embebido para controlar

un sistema, un mal funcionamiento puede causar daños como una bomba de insulina
daños a un usuario o lesión

2. Software secundario crítico para la protección: Software que podría repercutir

indirectamente en una lesión, como el mal funcionamiento de un CAD, que podría
causar error de diseño, y lesión a los individuos.

Razones por las que los sistemas fiables no necesariamente son seguros:
1. Nunca hay total certeza que un sistema esté libre de fallas en el desarrollo y
sea tolerante a los mismos.
2. Especificación podría estar incompleta en cuanto a que no describe el
comportamiento requerido del sistema en algunas situaciones críticas
3. Mal funcionamiento del hardware origina que el sistema se comporte de forma
impredecible, y presente al software un entorno no anticipado.
4. Los operadores del sistema pueden generar entradas que no son individualmente
incorrectas, pero que, en ciertas situaciones, conducirían a un mal funcionamiento
del sistema.

La clave para garantizar la seguridad consiste en cerciorarse de que no ocurrirán

accidentes o de que serán mínimas las consecuencias de un accidente, esto se
logrará mediante tres formas complementarias:

1. Evitar el peligro: Diseñar para evitar riesgos, como botones de protección en un

calentador para evitar accidente si se vuelca
2. Detectar y eliminar el peligro: Como cuando se detecta una presión excesiva y se
abre una valvula para liberar presión antes de un estallido
3. Limitar el daño: Minimizar el daño resultante de un accidente, como extintores
automáticos en un motor en caso de incendio.

SEGURIDAD

Atributo del sistema que refleja la habilidad de éste para protegerse a si mismo de
ataques externos, accidentales o deliberados

En cualquier sistema en red, existen tres principales tipos de amenazas a la

seguridad:

1. Amenazas a la confidencialidad del sistema y sus datos

2. Amenazas a la integridad del sistema y sus datos
3. Amenazas a la disponibilidad del sistema y sus datos

Controles que se deben implementar para mejorar la seguridad del sistema son:

1. Evitar la vulnerabilidad
2. Detectar y neutralizar ataques
3. Limitar la exposición y recuperación

CAPITULO 12: Especificación de confiabilidad y seguridad

Un software puede funcionar, pero el sistema como tal puede fallar porque la
especificación puede estar incompleta y no considerar una situación extraña. La
confiabilidad del sistema no solo depende de buena ingeniería, sino también de
atención a los detalles cuando se derivan los requerimientos del sistema y la
inclusión de requerimientos especiales de software que se ajustan para garantizar
la confiabilidad y seguridad de un sistema. Estos requerimientos de confiabilidad y
seguridad son de dos tipos:

1. Requerimientos funcionales: Definen mecanismos de comprobación y recuperación

que deben incluirse en el sistema, y en las características que ofrecen protección
contra fallas de sistema y ataques externos

2. Requerimientos no funcionales: Definen la confiabilidad y disponibilidad

requeridas del sistema.

Para generar requerimientos funcionales de confiabilidad y seguridad, hay que

partir de reglas, políticas y regulaciones de alto nivel. Debe comenzarse por los
requerimientos del "no debe" para conocer el comportamiento inaceptable y
finalmente descomponer en requerimiento funcionales más específicos.

ESPECIFICACIÓN DIRIGIDA POR RIESGOS:

1. Identificación (Descripción del riesgo)

2. Análisis del riesgo (Valoración del riesgo)
3. Descomposición del riesgo (Análisis de la causa raíz)
4. Reducción del riesgo (Requerimientos de confiabilidad)

Requerimientos de confiabilidad y seguridad pueden considerarse como requerimientos

de protección, como el sistema debe protegerse a sí mismo de fallas internas,
detener fallas de sistema que causen daño al entorno, contener accidentes o ataques
y facilitar la operación de recuperación en caso de falla.

Para este enfoque se debe tomar en cuenta:

1. Eventos peligrosos que pudieran ocurrir

2. Probabilidad de que realmente sucedan
3. Posibilidad de que el daño derivará de ese vento, y el grado de daño causado

Etapas del proceso:

1. Identificación del riesgo: Identificar riesgos potenciales al sistema, también

condiciones extrañas como un avión aterrizando con solo una rueda en vez de dos

2. Análisis y clasificación del riesgo: Considerar cada riesgo por separado, los
más serios y no improbables se seleccionan para mayor añalisis

3. Descomposición del riesgo: Buscar causas raíz de cada riesgo.

4. Reducción del riesgo: Proposiciones de formas para reducir o eliminar los

riesgos identificados.

Para sistemas grandes, el añalisis de riesgo puede estructurarse en:

1. Análisis preliminar del riesgo: Principales riesgos del entorno del sistema,
independientes de tecnología.

2. Análisis de riesgo de ciclo de vida: Durante el desarrollo del sistema, riesgos

surgidos por decisiones de diseño del sistema.

3. Análisis de riesgo operativo: Intefaz de usuario del sistema y riesgos del

operador.

ESPECIFICACIÓN DE PROTECCIÓN

Fallas llegan afectar el entorno del sistema y causar lesiones o muerte a ls

individuos en este ambiente. Los requerimientos de protección son básicamente
requerimientos de seguridad y no se interesan por la operación normal del sistema.
Evitar sobreprotección que cause el sistema sea demasiado costoso.

Peligro es algo que podria derivar en lesión o muerte de una persona, y Riesgo es
la probabilidad de que el sistema entre en un estado peligroso.

Proceso de especificación de protección:

1. Identificación de riesgo: En la especificación de protección, es el proceso de

identificación del peligro que identifica los riesgos que amenazarían al sistema
2. Análisis de riesgo: Proceso de valoración del peligro que permite determinar qué
riesgos son los más peligrosos, que tienen mayor probabilidad de ocurrir.

3. Descomposición del riesgo: Se enfoca en el descubrimiento de eventos que quizá

conduzcan a que ocurra un peligro..

4. Reducción del riesgo: Lleva a indentificar requerimientos de protección, se

puede inclinar por asegurar que no surja un peligro o conduzca a un accidente, o si
ocurre, minimizar el daño.

IDENTIFICACIÓN DE PELIGRO:

Los riesgos principales provinene de los peligros que conducen a un accidente,

riesgos de tipo físico, eléctricos, biológicos, radiación, etc.

VALORACIÓN DEL PELIGRO:

Comprender la probabilidad de que sobrevenga un peligro, y las consecuencias de que

este ocurriese. Existen tres categorías:

1. Riesgos intolerables: Amenazan la vida humana, el sistema debe diseñarse para

que tal peligro no pueda suceder, garantizar que se detectará antes de un
accidente.

2. Riesgos tan bajos como sea razonablemente práctico (ALARP): Consecuencias menos
serias, pero con baja probabilidad de suceder.

3. Riesgos aceptables: Derivan en daño menor, hay que reducir los riesgos
aceptables sin aumentan el costo y tiempo de entrega, así como de no afectar otros
atributos no funcionales del sistema.

ANÁLISIS DEL PELIGRO:

Proceso para descubrir las causas raíz de los peligros en un sistema de protección
crítico. Eventos o combinaciones de eventos que causarían una falla. Técnicas
deductivas ascendentes (parte del peligro y sube hasta la falla, más fácil),
inductiva descentente (parte de la falla, desciende hasta los peligros que resultan
de dicha falla). Existen técnicas como los árboles de fallas para representar los
riesgos y fallas posibles.

REDUCCIÓN DEL RIESGO

Una vez identificados los riesgos potenciales y sus causas raíz, entonces se podrán
derivar requerimientos de seguridad que administren los riesgos y garanticen que no
ocurran los indicentes o accidentes, existen tres posibles estrategias:

1. Evitar el peligro: El sistema se diseña de modo que no pueda ocurrir el peligro

2. Detectar y eliminar el peligro: El sistema se diseña de forma que los peligros

se detecten y neutralicen antes que suceda un accidente

3. Limitar el daño: El sistema se diseña de manera que se minimicen las

consecun=encias de un accidente

ESPECIFICACIÓN DE FIABILIDAD:

La fiabilidad global de un sistema depende de la fiabilidad del hardware, software

y operadores del sistema. Los requerimientos de fiabilidad son de dos tipos:
1. No Funcionales: Numero de fallas aceptables durante el uso normal del sistema
2. Funcionales: Definen las funciones del sistema y el software que evitan,
detectan o toleran fallas del software, para que no conduzca a fallas del sistema.

PROCESO DE ESPECIFICACIÓN DE FIABILIDAD:

1. Identificación del riesgo: Examinar tipos de fallas que originan pérdidas

económicas.

2. Análisis del riesgo: Estimación de costos y consecuencias de diferentes tipos de

fallas de software.

3. Descomposición de riesgo: Análisis de la causa raíz de las graves y probables

fallas de sistema. (regresar acá durante el diseño y desarrollo)

4. Reducción del riesgo: Especificaciones cuantitativas de fiabilidad que

establezcan probabilidades aceptables de los diferentes tipos de fallas.

METRICAS DE FIABILIDAD:

La fiabilidad puede especificarse como una probabilidad de que una falla del
sistema ocurrirá cuando un sistema está en uso dentro de un entorno operacional
especificado. Las métricas son:

1. Probabilidad de falla a pedido (POFOD): Definir la probabilidad de que la

demanda por un servicio derive en una falla del sistema.

2. Tasa de ocurrencia de fallas (ROCOF): Numero probable de fallas de sistema que

se observan en relación con cierto tiempo.

3. Disponibilidad (AVAIL): Capacidad de entregar servicios cuando se le solicitan

(99.99%)

REQUERIMIENTOS DE FIABILIDAD NO FUNCIONALES:

Especificaciones cuantitativas de la fiabilidad y disponibilidad del sistema,

usando alguna métrica anterior.

ESPECIFICACIÓN DE FIABILIDAD FUNCIONAL:

Identificar los requerimientos que definen las restricciones y características que

contribuyen a la fiabilidad del sistema.

1. Requerimientos de comprobación: Entradas al sistema incorrectas o fuer de rango

2. Requerimientos de recuperación: Ayudan al sistema a recuperarse luego de una
falla.
3. Requerimientos de reduncancia: Aseguran que la falla en un componente no
conduzca a pérdida completa del servicio.

ESPECIFICACIÓN DE SEGURIDAD:

1. Cuando se considera la protección, se puede suponer que el entorno donde se

instala el sistema no es hostil.

2. Cuando ocurren fallas, se buscan los errores o las omisiones que produjeron la
falla

3. Es acetable desactivar o degradar servicios del sistema para evitar una falla
relacionada con la protección.
4. Los eventos relacionados con la protección no los genera un adversario
inteligente, sino uno que entre más ataca más aprende sobre el funcionamiento del
sistema.

10 tipos de requerimientos de seguridad que pueden incluirse en una especificación

de sistema:

1. Los requerimientos de identificación especifican si un sistema debe o no debe

identificar
a sus usuarios antes de interactuar con ellos.
2. Los requerimientos de autenticación explican cómo se identifica a los usuarios.
3. Los requerimientos de autorización detallan los privilegios y permisos de acceso
de
los usuarios identificados.
4. Los requerimientos de inmunidad definen cómo un sistema debe protegerse a sí
mismo contra virus, gusanos y amenazas similares.
5. Los requerimientos de integridad describen cómo puede evitarse la corrupción de
datos.
6. Los requerimientos de detección de intrusiones puntualizan qué mecanismos deben
usarse para detectar ataques al sistema.
7. Los requerimientos de no repudio especifican que una parte en una transacción no
puede negar su involucramiento en dicha transacción.
8. Los requerimientos de privacidad se refieren a cómo se mantiene la privacidad de
los datos.
9. Los requerimientos de auditoría de seguridad plantean cómo puede auditarse y
verificarse
el uso del sistema.
10. Los requerimientos de seguridad de mantenimiento del sistema especifican cómo
una aplicación puede evitar cambios autorizados a partir de la inhabilitación
accidental
de sus mecanismos de seguridad.

ESPECIFICACIÓN FORMAL:

El punto de partida para todos los procesos de desarrollo formal es un modelo de

sistema formal, que sirve como una especificación de sistema. Para crear este
modelo,
traduzca los requerimientos de usuario del sistema, que se expresan en lenguaje
natural,
diagramas y tablas, a un lenguaje matemático que tenga semántica definida
formalmente.
La especificación formal es una descripción sin ambigüedades de qué debe hacer el
sistema.
Al usar métodos manuales o soportados por herramientas, es posible comprobar
que el comportamiento de un programa es congruente con la especificación.

1. Mientras se desarrolla una especificación formal a detalle, se obtiene una

comprensión
profunda y pormenorizada de los requerimientos del sistema. Incluso si no se
usa la especificación en un proceso de desarrollo formal, la detección del error de
requerimientos es un potente argumento para elaborar una especificación formal
(Hall, 1990). Los problemas de requerimientos que se descubren con antelación son,
por lo general, mucho menos costosos de corregir, que si se encuentran en etapas
posteriores en el proceso de desarrollo.

2. Conforme la especificación se expresa en un lenguaje con semántica definida

formalmente,
puede analizarse de manera automática para descubrir inconsistencias y
aquello que no se completó.

3. Si se usa un método como el método B, se puede transformar la especificación

formal
en un programa, a través de una secuencia de transformaciones que preserven
la exactitud. En consecuencia, se garantiza que el programa resultante cumpla su
especificación.

4. Los costos de las pruebas del programa suelen reducirse porque el programa se
verificó
contra su especificación.

CAPITULO 16: REUTILIZACIÓN DE SOFTWARE

Reduce los costos de producción y mantenimiento, entregar sistemas con mayor

rapidez y aumentar la calidad del software. Las univdades de software que se pueden
reutilizar son por ejemplo:

1. Sistema de aplicación: Se puede reutilizar al incorporarlo sin cambios en otros

sistemas, o configurar la aplicación para diferentes clientes.

2. Componentes: Componentes de una aplicación que varían en tamaño desde

subsistemas hasta objetos individuales pueden reutilizarse.

3. Objetos y funciones: Reutilizarse componentes de software que implementan una

sola función.

También se puede hacer reutilización de idea o concepto, cuando es costoso

modificar un algoritmo ya existente.

PANORAMA DE LA REUTILIZACIÓN

1. Calendario de desarrollo de software: Si hay poco tiempo, es mejor reutilizar

programas comerciales.

2. Vida esperada del software: Si ha de durar mucho tiempo, es mejor evitar COTS
porque no se puede acceder a su código fuente al momento de agregar nuevos
requerimientos en la evolución

3. Antecedentes, habilidades y experiencia del equipo de desarrollo: Mejor enfocar

al equipo en el área donde tiene más habilidad.

4. Criticidad del software y sus requerimientos no funcionales: Crear un caso de

confiabilidad para un regulador externo, pero si no se tiene acceso al código
fuente quizas sea mejor desarrollarlo

5. Dominio de la aplicación: Existen productos genericos en dominios como

fabricación o medicina que solo es necesario configurarlos a gusto.

FRAMEWORKS DE APLICACIÓN

Como sugiere el nombre, un framework es una estructura genérica que se extiende

para crear una aplicación o un subsistema más específico. Es un conjunto integrado
de artefactos de software (tales como clases, objetos y
componentes), que colaboran en la facilitación de una arquitectura de reutilización
para una familia de aplicaciones relacionadas

Clases de frameworks:
1. Infraestrucura del sistema: Comunicaciones, UI, compiladores.
2. Integración de middleware: Estandares, clases para comunicación e intercambio de
información entre componentes
3. Aplicación empresarial: Dominios de aplicación específicos, como comunicaciones
o financieros.

Los WAF (frameworks de aplicación web) ofrecen:

1. Seguridad
2. Páginas web dinámicas
3. Soporte a base de datos
4. Gestión de sesión
5. Interacción de usuarios

LINEAS DE PRODUCTO DE SOFTWARE:

La reutilización tiene una gran efectividad en el enfoque de creación de lineas de

producción de software o familias de aplicación. Permite cosas como creación de
diferentes arquitecturas, procesos industriales diferentes, etc.

REUTILIZACIÓN DE PRODUCTOS COTS

Comercial off the shelf.

Ventajas:

1. Al igual que sucede con otros tipos de reutilización, es posible la

implementación
más rápida de un sistema fiable.
2. Es posible ver qué funcionalidad ofrece la aplicación, de manera que es más
fácil
juzgar si es probable que sea adecuada o no. Quizás otras compañías ya usen las
aplicaciones, de manera que existen antecedentes de experiencia con el sistema.
3. Se evitan algunos riesgos de desarrollo al usar software existente. Sin embargo,
este
enfoque tiene sus propios riesgos, como se verá más adelante.
4. Las empresas pueden enfocarse en su actividad central sin tener que dedicar
muchos
recursos al desarrollo de sistemas TI.
5. Conforme evolucionan las plataformas operativas, las actualizaciones de
tecnología
se pueden simplificar, pues éstas son responsabilidad del proveedor del producto
COTS y no del cliente.

Problemas:

1. Tienen que adaptarse los requerimientos para reflejar la funcionalidad y el modo

de
operación del producto COTS. Esto puede conducir a cambios bruscos en los procesos
empresariales existentes.
2. El producto COTS puede basarse en suposiciones que sean casi imposibles de
cambiar. Por lo tanto, el cliente debe adaptar su empresa para reflejar dichas
suposiciones.
3. Elegir el sistema COTS correcto para una empresa puede ser un proceso difícil,
en especial porque muchos productos COTS no están debidamente documentados.
Tomar la decisión equivocada podría ser desastroso, ya que tal vez sea imposible
hacer funcionar el nuevo sistema como se requiere.
4. Quizá no haya experiencia local para apoyar el desarrollo de los sistemas. En
consecuencia,
el cliente deberá apoyarse en el proveedor y en consultores externos para
obtener consejos de desarrollo. Estos consejos podrían estar sesgados y dirigidos a
vender productos y servicios, y no a satisfacer las necesidades reales del cliente.
5. Los proveedores de productos COTS controlan el soporte y la evolución del
sistema.
Pueden salir del negocio, perder el control o incluso hacer cambios que ocasionen
dificultades a los clientes.

Sistemas comunes son los CRM, ERP.

CAPITULO 17: INGENIERIA DE SOFTWARE BASADA EN COMPONENTES

Para el software personalizado, donde un COTS no satisface los requisitos, la

ingenieria de software basada en componentes es una forma efectiva orientada a la
reutilización para desarrollar nuevos sistemas empresariales. CBSE se desarrolló
cuando los diseñadores se percataron que el desarrollo orientado a objetos no
conducía a una reutilización extensa como se había sugerido originalmente. Las
clases de objetos individuales eran muy detalladas y específicas y con frecuencia
tenían que acotarse con una aplicación al momento de compilar.

Los componentes son abstracciones de alto nivel en comparación con objetos y se

definen mediante sus interfaces. La CBSE es el proceso de definir, implementar e
integrar o componer los componentes independientes e imprecisos en los sistemas.

Fundamentos de la CBSE:

1. Componentes independientes que se especifican por completo mediante sus

inferfaces.

2. Estándares de componentes que facilitan la integración de éstos. Definen a nivel

mínimo cómo deben especificarse las interfaces de componentes y cómo se comunican
estos últimos.

3. Middleware que brinda soporte de software para integración de componentes. Para

hacer que componentes independientes distribuidos trabajen en conjunto.

4. Un proceso de desarrollo que se engrana con CBSE, se necesita un proceso de

desarrollo que permita la evolución de requerimientos.

Principios de diseño:

1. Componentes son independientes, ejecuciones no interfieren entre sí

2. Componentes se comunican a través de interfaces bien definidas.
3. Las infraestructuras de componentes ofrecen varios servicios estándar que pueden
usarse en sistemas de aplicación.

Un componente se considera como un elemento de un sistema de software al que se

podría acceder, mediante un mecanismo llamado procedimiento remoto, por parte de
otros componentes que se ejecutan en computadoras independientes. Cada sistema que
reutiliza un componente debe incorporar su propia copia de dicho componente.

COMPONENTES Y MODELOS DE COMPONENTES

La comunidad dice que un componente es una unidad de software independiente que

puede organizarse con otros componentes para crear un sistema de software. Una
forma útil de pensar de un componente es como un proveedor de uno o más servicios,
cuando el sistema necesita un servicio, llama a un componente que lo brinder. Como
el buscador de una biblioteca. Un componente como un servicio pone a relieve:
1. El componente es una entidad ejecutable independiente definida por sus
interfacces, no se necesita conocimiento de su código fuente para usarlo.
2. Los servicios ofrecidos por un componente se ponen a disposición mediante una
interfaz, se expresa en términos de operaciones parametrizadas y nunca se expone el
estado interno del componente.

Interfaces de un componente:

1. Interfaz "Proporciona" los servicios ofrecidos por el componente. API.

2. Intefaz "Requiere" son los servicios que ofrecen otros componentes, y que se
usan para que el componente actual pueda proporcionar su servicio.

MODELOS DE COMPONENTES

Definición de estándares para implementación, documentación y despliegue de

componentes. Esto es para que los desarrolladores se aseguren de que éstos
componentes puedan interoperar.

Información y como debe implementarse un componente:

1. Interfaces: Nombres de operación, parámetros, excepciones. (Web Service

Description Language WSDL)

2. Uso: Los componentes deben tener nombre único asociado, si es web es con URI
(Uniform Resource Identifier). También deberian tener metadatos de su
funcionamiento (SOAP)

3. Implementación: Deben empacarse con todo el software requerido para funcionar.

Weinreich y Sametinger (2001) usan

la analogía de un sistema operativo para explicar los modelos de componentes. Un
sistema
operativo brinda un conjunto de servicios genéricos que pueden usar las
aplicaciones. La
implementación de un modelo de componentes ofrece servicios compartidos comparables
para los componentes.

Los servicios brindados por una implementación de modelo de componentes se dividen

en dos categorías:

1. Servicios de plataforma: Permiten a los componentes comunicarse e interoperar en

un entorno distribuido.

2. Servicios de apoyo: Como los middleware de autenticación para uso de todos los
componentes.

Un contenedor es una implementación de los servicios de apoyo más una definición de

las
interfaces que debe proporcionar un componente para integrarlo con el contenedor.
Incluir
el componente en el contenedor significa que el componente puede ingresar a los
servicios
de apoyo, y el contenedor puede acceder a las interfaces de componente.

PROCESOS CBSE:

Procesos de software que brindan soporte a la CBSE. Toman en cuenta posibilidades

de reutilización y las diferentes actividades de proceso implicadas en el
desarrollo y uso de componentes reutilizables. Existen dos tipos de procesos CBSE:
1. Desarrollo para reutilización: Se ocupa del desarrollo de componentes o
servicios que se reutilizarán en otras aplicaciones.

2. Desarrollo con reutilización: Proceso para desarrollar nuevas aplicaciones

usando los componentes y servicios existentes.

Proceso básicos de CBSE:

1. Adquisición de componentes: Adquirir componentes para reutilización o desarrollo

en un componente reutilizable (normalmente no se tiene acceso al código fuente)

2. Gestión de componentes: En una compañia sirve para catalogar, almanecar y

disponer de componentes reutilizables.

3. Certificación de componentes: Proceso de comprobar un componente y asegurarse

que cumple su especificación.

CBSE PARA REUTILIZACIÓN:

Proceso de desarrollar componentes reutilizables, y ponerlos a disposición para

reutilizarlos a través de un sistema de gestión de componentes. Componentes pueden
integrarse en el desarrollo, pero si no están disponibles solamente puede accederse
a sus servicios externamente.

Tener en cuenta que primero habrá que decidir si es probable que un componente se
reutilice y, segundo, si los ahorros de costo de la futura reutilización justifican
los costos de hacer reutilizable al componente

Los cambios que se pueden hacer a un componente para volverlo más reutilizable
incluyen:

• eliminar métodos específicos de aplicación;

• cambiar los nombres para hacerlos más generales;
• agregar métodos para brindar cobertura funcional más completa;
• hacer manejadores de excepción consistentes para todos los métodos;
• adicionar una interfaz de “configuración” para permitir la adaptación de los
componentes a diferentes situaciones de uso
• integrar los componentes requeridos para aumentar la independencia.

Sin embargo, en la práctica, existen dos problemas con publicar las excepciones en
la interfaz:

1. Publicar todas las excepciones conduce a interfaces infladas que son difíciles
de
entender. Esto podría alejar a usuarios potenciales del componente.

2. La ejecución del componente puede depender del manejo de excepciones locales,

y cambiar esto tal vez tenga serias implicaciones para la funcionalidad del
componente.

CBSE CON REUTILIZACIÓN

Las diferencias esenciales entre CBSE con reutilización y procesos de software para
desarrollo de software original son:

1. Los requerimientos del usuario se desarrollan inicialmente en bosquejos, no en

detalle para buscar mayor flexibilidad. Los requerimientos muy específicios limitan
la cantidad de componentes reutilizables. El desarrollo incremental requiere un
conjunto completo de requerimientos para identificar identificar tantos componentes
sea posible para reutilización.

2. Los requerimientos se afinan y modifican oportunamente durante el proceso,

dependiendo de los componentes disponibles. Si los requerimientos no puede
cumplirse a partir de los componentes disponibles, se debe analizar los
requerimientos relacionados que puedan cumplirse. Quiza el usuario tenga voluntad
de cambiar mentalidad si esto significa entregar un sistema de menor costo más
rápidamente.

3. Después de diseñar la arquitectura del sistema, hay una actividad adicional de

busqueda de componentes y clarificación de diseño. Algunos componentes
aparentemente utilizables quizá resulten inadecuados o no funcionen como es debido
con otros componentes elegidos

4. El desarrollo es un proceso de composición en que se integran los componentes

descubiertos.
Esto implica integrar los componentes con la infraestructura del modelo
de componentes y, con frecuencia, desarrollar adaptadores que reconcilien las
interfaces
de componentes incompatibles. Desde luego, también puede requerirse funcionalidad
adicional por encima de la que ofrecen los componentes de reutilización.

La etapa de diseño arquitectónico es importante, una arquitectura robusta es

crucial para tener éxito en la reutilización.

COMPOSICIÓN DE COMPONENTES:

La composición de componentes es el proceso de integrar componentes uno con otro y

con “código pegamento” especialmente escrito para crear un sistema u otro
componente.

1. Composición secuencial: Componente A no llama directamente a componente B, sino

que se usa código pegamento para pasar los resultados del servicio A en la llamada
al componente B.

2. Composición jerárquica: Cuando un componente llama directamente a los servicios

que ofrece otro componente, su interfaz requiere debe ser compatible con la
interfaz proporciona del componente llamado. Si las interfaces no coinciden, puede
usarse un código de conversión intermedio.

3. Composición aditiva: Cuando dos o más componentes se juntan (se suman) para
crear un nuevo componente, exponiendo sus interfaces independientes. Los
componentes siguen siendo dependientes y no se llaman mutuamente.

Posibles problemas de interfaces:

1. Incompatibilidad de parámetro Las operaciones en cada lado de la interfaz tienen

el mismo nombre, pero sus tipos de parámetro o el número de parámetros son
diferentes.

2. Incompatibilidad de operación Los nombres de las operaciones en las interfaces

“proporciona” y “requiere” son diferentes.

3. Operación incompleta La interfaz “proporciona” de un componente es un

subconjunto
de la interfaz “requiere” de otro componente o viceversa.

CAPITULO 18: INGENIERIA DE SOFTWARE DISTRIBUIDO:

Practicamente todos los grandes sistemas basados en en computadora son ahora
sistemas distribuidos. Un sistema distribuido es aquel que implica numerosas
computadoras. Un sistema centralizado es que todos los componentes del sistema se
ejecutan en una computadora.

Un sistema distribuido es una colección de computadoras independientes que aparecen

al usuario como un solo sistema coherente

Ventajas de un sistema distribuido:

1. Compartición de recursos: Un sistema distribuido permite compartir recursos de

hardware y software como discos, impresoras, archivos, compiladores que se asocian
con computadoras en una red.

2. Apertura: Por lo general son sistemas abiertos, están diseñados en torno a

protocolos estándar que permiten la combinación de equipo y software de diferentes
proveedores.

3. Concurrencia: Grandes procesos pueden ejecutarse al mismo tiempo en computadoras

independientes en red. Dichos procesos pueden o no comunicarse uno con el otro
durante su operación normal.

4. Escalabilidad: Escalables cuando las capacidades del sistema pueden aumentarse

al agregar nuevos recursos para afrentar la demanda del sistema.

5. Tolerancia a fallas: La disponibilidad de muchas computadoras y el potencial de

reproducir información significa que los sistemas distribuidos pueden tolerar
algunas fallas de hardware y software. En la mayoría de los sistemas distribuidos,
puede darse un servicio degradado al ocurrir fallas; la pérdida completa de
servicio sólo sucede cuando hay una falla de red.

Los sistemas distribuidos son inherentemente más complejos que los sistemas
centralizados.
Esto los hace más difíciles de diseñar, implementar y poner a prueba.

Estos sistemas dependen no solo de la velocidad del procesador, sino también del
ancho de red, carga de red y velocidad del resto de computadoras.

CONFLICTOS DE LOS SISTEMAS DISTRIBUIDOS:

1. Transparencia ¿En qué medida el sistema distribuido debe aparecer al usuario

como un solo sistema? ¿Cuándo es útil para los usuarios entender que el sistema es
distribuido?

2. Apertura ¿Un sistema debe diseñarse usando protocolos estándar que soporten
interoperabilidad o deben usarse protocolos más especializados que restrinjan la
libertad del diseñador?

3. Escalabilidad ¿Cómo puede construirse el sistema para que sea escalable? Esto
es,
¿cómo podría diseñarse un sistema global para que su capacidad se pueda aumentar
en respuesta a demandas crecientes hechas sobre el sistema?

4. Seguridad ¿Cómo pueden definirse e implementarse políticas de seguridad útiles

que se apliquen a través de un conjunto de sistemas administrados de manera
independiente?

5. Calidad de servicio ¿Cómo debe especificarse la calidad del servicio que se

entrega a los usuarios del sistema y cómo debe implementarse el sistema para
entregar
una calidad de servicio aceptable para todos los usuarios?

6. Gestión de fallas ¿Cómo pueden detectarse las fallas del sistema, contenerse (de
modo que tengan efectos mínimos sobre otros componentes del sistema) y repararse?

Dimensiones de la escalabilidad:

1. Tamaño: Debe ser posible agregar más recursos a un sistema para enfrentar el
creciente número de usuarios

2. Distribución: Debe ser posible dispersar geográficamente los componentes de un

sistema sin reducir su rendimiento

3. Manejabilidad: Debe ser posible administrar un sistema conforme aumenta en

tamaño

Scaling up (expandir): Sustituir los recursos en el sistema con otros más

poderosos.

Scaling out (ampliar): Agregar recursos adicionales al sistema, como un nuevo

servidor web (procesamiento concurrente), este es mejor

Tipos de ataques a sistemas distribuidos:

1. Intercepción: Atacante intercepta comunicaciones entre partes del sistema

2. Interrupción: Servicios son atacados y no puede entregarse lo solicitado.

3. Modificación: Atacante cambia datos o servicios del sistema

4. Fabricación: Atacante genera información que no debe existir y la usa para

conseguir privilegios. (generar falsa entrada de contraseña)

QoS: Quality of service, capacidad del sistema para entregar sus servicios de
manera confiable y con un tiempo de respuesta y rendimiento total que sean
aceptables para sus usuarios. Los requerimientos QoS deben especificarse por
adelantado, y diseñarse el sistema y configurarse para entregar dicho QoS, pero no
es posible porque:

1. No es costo-efectivo diseñar y configurar el sistema para que entregue un QoS

bajo carga pico, porque esos recursos no se usarian gran parte del tiempo. La
computación en la nube enfrenta parcialmente este problema.

2. Parametros QoS pueden ser contradictorios entre sí, creciente fiabilidad puede
significar reducción en el rendimiento total, ya que se introducen procedimientos
de comprobación para garantizar que son válidas todas las entradas del sistema.

QoS es importante en video y sonido. Usted sabe que tiene un sistema distribuido
cuando la caída de un sistema de la que nunca escuchó impide que usted realice
cualquier trabajo.

MODELOS DE INTERACCIÓN:

Interacción procedimental: Implica que una computadora que solicita el servicio

conocido ofrecido por otra computadora y por lo general espera la entrega de dicho
servicio.
Interacción basada en mensajes: Implica que la computadora emisora defina en un
mensaje la información acerca de lo que requiere, el cual se envía entonces a otra
computadora.

RPC: Remote Procedure Calls, solicitudes de procedimiento remoto. Un componente

solicita a otro componente como si fuera un procedimiento o método local. Se
realiza más que todo por un middleware que intercepta la solicitud y la transmite a
un componente remoto. En java se conoce como Remote Method Invocation RMI

MIDDLEWARE:

Es un software, se encuentra en el centro, entre los componentes distribuidos del

sistema. Gestion de comunicaciones con base de datos, gestores de transacciones,
convertidores de datos y controladores de comunicación. Tienen dos tipos de
soporte:

1. Interacción: El middleware coordina las interacciones entre diferentes

componentes del sistema.'

2. Provisión de servicios comunes: Middleware proporciona implementaciones de

reutilización de servicios que pueden requerir varios componentes en el sistema
distribuido.

COMPUTACIÓN CLIENTE-SERVIDOR:

Los sistemas distribuidos a los que se accede por internet se organizan normalmente
como sistemas cliente-servidor. En un sistema cliente-servidor, el usuario
interactúa con
un programa que se ejecuta en su computadora local (por ejemplo, un navegador Web
o una aplicación basada en telefonía). Éste interactúa con otro programa que se
ejecuta
en una computadora remota (por ejemplo, un servidor Web). La computadora remota
proporciona servicios, como acceso a páginas Web, que están disponibles a clientes
externos

Cuatro capas del cliente-servidor:

1. Presentación: Presentar información al usuario y gestionar todas las

interacciones de este.

2. Gestion de datos: Gestiona los datos que pasan hacia y desde el cliente. Incluye
compraciones de datos, generación de páginas web, etc.

3. Procesamiento de aplicación: Implementa la lógica de la aplicación, proporciona

funcionalidad requerida a los usuarios finales.

4. Capa de base de datos: Almacena datos y ofrece servicios de gestión de

transacción, etc.

Cliente-Servidor puede desarrollarse con diferentes arquitecturas, un ejemplo son

los SaaS.

PATRONES ARQUITECTÓNICOS PARA SISTEMAS DISTRIBUIDOS:

Los diseñadores de sistemas distribuidos deben organizar sus diseños de sistema

para encontrar un equilibrio entre rendimiento, confiabilidad, seguridad y
manejabilidad del sistema

Estilos arquitectónicos:
1. Arquitecutra Maestro-Esclavo: Sistemas de tiempo real, garantía de tiempos de
respuesta de interacción. Maestro es el responsable de la computación, coordinación
y comunicaciones. Los esclavos se dedican a acciones específicas como adquisición
de datos de sensores.

2. Arquitectura cliente-servidor de dos niveles: Cliente-Servidor simple,

situaciones donde es importante centraliar el sistema por seguridad. La
comunicación está encriptada entre cliente y servidor.

*Cliente ligero es cuando la capa de presentación se realiza en el cliente, y los

procesos y bases de datos en el servidor.

*Cliente pesado: Gran parte del procesamiento se realiza en el cliente, gestión de

datos y base de datos se implementan en el servidor.

3. Arquitectura Cliente-Servidor multinivel: Cuando existe un enorme volumen de

transacciones a procesar por el servidor. Básicamente es ejecutar las capas del
cliente-servidor en diferentes procesadores para aumentar la escalabilidad.

4. Arquitectura de componentes distribuidos: Cuando es necesario combinar recursos

de diferentes sistemas y bases de datos. Diseñar el sistema como un conjunto de
servicios, sin tratar de asignar dichos servicios a capas en el sistema. Los
sistemas de componentes distribuidos dependen del middleware, que gestiona las
interacciones de componentes, reconcilia las diferencias entre tipos de parámetros
transmitidos entre componentes, y ofrece un conjunto de servicios comunes que
pueden usar los componentes de la aplicación.

5. Arquitectura peer-to-peer: Par a par, cuando los clientes intercambian de manera

local la información almacenada, y el servidor tiene como papel presentar a los
clientes entre si. En principio, cada nodo en una red p2p podría estar al tanto de
cualquier otro nodo.

SOFTWARE COMO SERVICIO:

SaaS implica alojar el software remotamente y proporcionar acceso al mismo a través

de Internet. Los elementos clave de SaaS son los siguientes:

1. El software se despliega en un servidor y se accede a él a través de un

navegador. No se implementa en una computadora local.

2. Software es propiedad del proveedor, quien administra, no de las organizaciones

que usan el software.

3. Los usuarios pueden pagar por el software de acuerdo con la cantidad de uso que
hagan de él o mediante una suscripción anual o mensual.

Para usuarios de software, el beneficio de SaaS es que los costos para administrar
el
software se transfieren al proveedor. El proveedor es responsable de corregir los
bugs e instalar
las actualizaciones de software, enfrentar los cambios a la plataforma del sistema
operativo
y asegurar que la capacidad del hardware pueda cumplir la demanda.

SOA y SaaS no son lo mismo SOA es Service-Oriented-Architecture. Diferencias:

1. SaaS: Proporciona funcionalidad en un servidor remoto con clientes que acceden

mediante un navegador web, servidor conserva datos y estados de usuario durante la
sesion, las transacciones son largas.

2. SOA: Conjunto de servicios independientes sin estado, proporcionados mediante

múltiples proveedores. Son transacciones cortas donde se solicita un servicio y se
devuelve un resultado.

Factores al implementar un Saas:

1. Configurabilidad ¿Cómo configura usted el software para los requerimientos

específicos de cada organización?

2. Multitenencia ¿Cómo presenta a cada usuario del software la impresión de que

trabaja con su propia copia del sistema mientras, al mismo tiempo, hace uso
eficiente
de los recursos del sistema?

3. Escalabilidad ¿Cómo diseña el sistema de modo que pueda escalarse para alojar
un número impredeciblemente grande de usuarios?

Las instalaciones de configuración pueden permitir lo siguiente:

1. Marca: A los usuarios de cada organización se les presenta una interfaz que
refleja
su propia organización.

2. Reglas y flujos de trabajo empresariales: Cada organización define sus propias

reglas que regulan el uso del servicio y sus datos.

3. Extensiones de base de datos: Cada organización define cómo se extiende el

modelo
de datos del servicio genérico para cubrir sus necesidades específicas.

4. Control de acceso: Los clientes del servicio crean cuentas individuales para su
personal
y definen los recursos y funciones que son accesibles a cada uno de sus usuarios.

CAPITULO 19: ARQUITECTURA ORIENTADA A SERVICIOS

Servicio web: Las organizaciones que querían hacer accesible su información para
otros programas podían lograrlo al definir y publicar una interfaz de servicio web,
la interfaz define los datos disponibles y cómo se puede acceder a ellos. De manera
más general,
un servicio Web es una representación estándar para cierto recurso computacional o
información que pueden usar otros programas

La particularidad de un servicio es que el hecho de proveer el servicio es

independiente de la aplicación que usa el servicio.

Estandares SOA:

1. SOAP: Simple Objet Access Protocol, intercambio de mensajes que soporta

comunicación entre servicios. Define el componente esencial y opcional en los
mensajes transmitidos entre servicios.

2. WSDL: Web Service Definition Language, define interfaces. Establece nombres de

operaciones, parámetros, tipos, etc.

3. WS-BPEL: Lenguaje de flujo de trabajo, define programas de proceso que implican

varios servicios diferentes.
Estandares SOA especializados:

1. WS-Reliable messaging: Garantiza que los mensaje se entregarán una y solo una
vez.

2. WS-Security: Seguridad del servicio, definición de políticas y firmas digitales.

3. WS-Addressing: Define como debe representarse la información de dirección en un

mensaje SOAP.

4. WS-Transactions: Define cómo se coordinan las trasacciones a través de los

servicios distribuidos.

Estos estandares son muy "pesados", son muy generales e ineficientes. Requieren una
considerable cantidad de procesamiento para crear, transmitir e interpretar los
mensajes XML asociados. Por esto, algunas organizaciones como Amazon, utilizan un
enfoque más simple y eficiendo utilizando los servicios RESTful.

Un ejemplo de enfoque orientado a servicios es un automóvil con un sistema de

información a bordo, como clima. El sistema se conecta a los servicios disponibles
a través de descubrimiento (como el reloj y la señal militar de hora), a fín de
brindar su posición y obtener el clima del lugar.

SERVICIOS COMO COMPONENTES DE REUTILIZACIÓN:

CBSE indica que los sistemas de software se construyen al combinar componentes de

software basados en un modelo de componentes estandar, por otro lado, servicio son
un desarrollo natural de los componentes de software donde el modelo de componente
es, en esencia, un conjunto de estándares asociados con servicios web.

Un servicio puede definirse como:

Un componente de software de reutilización, debidamente ajustado, que ofrece
discreta funcionalidad, la cual puede distribuirse y a la que se accede de manera
programática. Un servicio Web es un servicio al que se accede mediante protocolos
estándar de Internet y basados en XML.

Distinción entre servicio y componente:

*Servicio debe ser independiente y ajustarse debidamente
*Servicio debe operar siempre en la misma forma sin importar el entorno de
ejecución
*Servicio no tiene interfaz requiere
*Servicio tiene interfaz proporciona
*Servicio se comunica por mensajes XML, HTTP y TCP/IP
*Para usar servicio se debe conocer su URI

Especificación WSDL:

1. Parte "qué": Es la intefaz, especifica operaciones que soporta el servicio,

define el formato de los mensajes

2. Parte "como": Llamado enlace, mapea la interfaz abstracta a un conjunto concreto

de protocolos, especifica los detalles técnicos de cómo comunicarse.

3. Parte "dónde": Describe la ubicación de una implementacióón de servicio web. (su

punto final).

Modelo conceptual WSDL:

1. Parte introductoria que define los espacios de nombre (namespaces) XML.
2. Descripción opcional de los tipos que se usan en los mensajes
3. Descripción de la interfaz de servicio, operaciones que ofrece el servicio
4. Descripción de los mensajes de entrada y salida procesados por el servicio
5. Descripción de los enlaces usados por el servicio (por defecto es SOAP)
6. Especificación de punto final, ubicación física del servicio (URI)

namespace:nombre

INGENIERÍA DE SERVICIO

Proceso de desarrollo de servicios para reutilización en aplicaciones orientadas a

servicios. Los ingenieros de servicio deben garantizar que el servicio represente
una
abstracción de reutilización que podría ser útil en diferentes sistemas.

Etapas lógicas en el proceso de ingeniería de servicio:

1. Identificación de candidatos a servicio, donde se identifican los posibles

servicios
que se podrían implementar y se definen los requerimientos del servicio.

2. Diseño del servicio, donde se diseñan las interfaces lógica y de servicio WSDL.

3. Implementación y despliegue del servicio, donde el servicio se implementa, se

prueba y se pone a disposición del usuario

IDENTIFICACIÓN DE CANDIDATOS A SERVICIO

Los servicios deben soportar procesos empresariales, por tanto, hay que comprender
y analizar que procesos podrían implementarse como servicios. Existen tres tipos
fundamentales de servicios:

1. Servicios utilitarios: Implementan una funcionalidad general que pueden usar

diferentes procesos empresariales, como conversión de divisas.

2. Servicios empresariales: Servicios asociados con una funcion empresarial

específica, como la inscripción de estudiantes para un curso.

3. Servicios de coordiación o proceso: Servicios que soportan un proceso

empresarial más general, implican diferentes actores y activiades, como un servicio
de pedidos con proveedores y pagos.

4. Servicios orientados a tareas: Son sociados con alguna actividad

5. Servicios orientados a entidades: Como objetos, formato de solicitud de empleo.

Un ejemplo es un servicio catálogo, que provee precios y quiza tiene más de un

proveedor. Similar a un servicio de armar computadoras.

DISEÑO DE INTERFACES DEL SERVICIO:

Una vez seleccionados los servicios cantidados, hay que definir las operaciones y
sus parámetros.

1. Diseñar interfaz lógica: Operaciones, entradas, alidas, excepciones.

2. Diseñar mensajes: Estructura que envia y recibe (XML)
3. Desarrollo WSDL: Descripción de interfaz escrita en WSDL
IMPLEMENTACIÓN Y DESPLIEGUE DEL SERVICIO

Esta etapa puede implementarse usando Java, C#. Puede desarrollarse el servicio al
implementar las interfaces a un componente existente, como el caso de los sistemas
heredados.

SERVICIOS DE SISTEMAS HEREDADOS

Son sistemas antiguos que emplea una organización, depende de tecnología obsoleto,
pero todavía son esenciales para la empresa. En vez de reescribir o sustituir, es
mejor juntarlo con software moderno usando Wrappers, así se puede acceder a los
servicios, funciones y datos para integrarlos con otras aplicaciones.

DESARROLLO DE SOFTWARE CON SERVICIOS:

Se basa en la idea que se combinan y configuran servicios para crear nuevos

servicios compuestos. AWS es un ejemplo con sus funciones lambda. Todo esto genera
un flujo de trabajo.

DISEÑO E IMPLEMENTACIÓN DEL FLUJO DE TRABAJO:

Implica analizar los procesos empresariales existentes o planeados para comprender

las actividades que se realizan y como éstas intercambian informacion. Hay que
establecer etapas implicadas para realizar el proceso, y la información que se
transmite en cada una.

Una vez diseñado el modelo de proceso empresarial debe pasar a iteraciones para
permitir la máxima reutilización de servicios.

PRUEBAS DEL SERVICIO:

Demuestran que el sistema cumple con sus requerimientos funcionales y no

funcionales.

CAPITULO 20: SOFTWARE EMBEBIDO:

Es software muy relacionado a manejar hardware en base a eventos, el software está

embebido en el sistema, normalmente en la memoria de sólo lectura. Teléfonos,
hornos, etc.

Sistema de software de tiempo real: Es un sistema cuya correcta operación

depende tanto de los resultados producidos por el sistema como del tiempo en que
se producen dichos resultados. Un “sistema blando de tiempo real” es un sistema
cuya operación se degrada si los resultados no se producen de acuerdo con los
requerimientos de tiempo especificados. Si los resultados no se producen según la
especificación de tiempo en un “sistema duro de tiempo real”, se considera una
falla del sistema.

Carácteristicas:

0. No todos los sistemas embedidos tienen que ser de tiempo de respuesta rápida.

1. Los sistemas embebidos operan de manera continua. Desde que el hardware enciende
hasta que te apaga.

2. Las interacciones con el entorno del sistema son incontrolables e impredecibles.

Por eso puede existir concurrencia de procesos.
3. Pueden haber limitaciones físicas que afecten el diseño de un sistema.

4. Es posible que se requiera interacción directa con el hardware, ya que deben

interactuar con dispositivos de hardware que no tienen controlares por separado
(I2C)

5. Los conflictos de protección y fiabilidad pueden dominar el diseño del sistema.

Muchos sistemas embebidos controlan dispositivos cuyas fallas pueden tener altos
costos humanos o económicos.

DISEÑO DE SISTEMAS EMBEBIDOS:

Es necesario considerar el diseño y el rendimiento del hardware al detalle. Las

decisiones de bajo nivel como hardware, software de soporte y timing deben
considerarse desde el inicio del proceso, por tanto, no es posible partir de un
diseño de alto nivel abstracto.

Clases de estímulos:

1. Periódicos: Ocurren a invertalos predecibles, como examinar un sensor cada 50

milisegundos y actuar (responder) a partir del valor de dicho sensor (estimulo)

2. No periódicos: Irregular e impredecible, se suelen señalar mediante interrupción

de hardware (microcontroladores)

Los estimulos provienen de sensores.

Actividades del proceso de diseño de software en tiempo real:

1. Selección de plataforma: Hardware, OS.

2. Identificación de estímulos/respuestas
3. Análisis de temporización: Establecer plazos de procesos, restricciones de
tiempo, respuesta
4. Diseño de procesos: Se agrega el estímulo y procesamiento de respuesta.
5. Diseño de algoritmo: Para cada estímulo se diseñan algoritmos que realizan
cálculos requeridos
6. Diseño de datos: Especificar información que intercambian los procesos
7. Planeación del proceso: Garantiza que los procesos iniciarán a tiempo para
cumplir sus plazos.

MODELADO DE SISTEMAS DE TIEMPO REAL:

Los eventos de un sistema de tiempo real causan que el sistema se mueva de un

estado a otro, por tanto, se usan modelos de estado para describir sistemas de
tiempo real.

PROGRAMACIÓN EN TIEMPO REAL:

Si son plazos muy ajustados se usa ensamblador, de lo contrario, C es muy usado por
su eficiencia. Pero estos no soportan concurrencia o gestión de recursos, sino, que
se implementan a través de llamadas primitivas, como semáforos. Por sus
restricciones de temporización, es muy díficil que puedan usar desarrollo orientado
a objetos en sistemas de tiempo real duros.

PATRONES ARQUITECTÓNICOS:

Descripciones abstractas estilizadas de buenas prácticas de diseño.

1. Observar y reaccionar: En el momento que un sensor indica que sucedió un evento,

el sistema debe reaccionar iniciando un proceso para manejar dicho evento.

2. Control ambiental: Cuando se incluyen sensores sobre el entorno y los actuadores

pueden cambiar el entorno.

3. Segmentación de proceso (process pipeline): Se usa al transformarse datos de una

representación a otra antes que puedan procesarse.

ANÁLISIS DE TEMPORIZACIÓN

La exactitud de un sistema de tiempo real depende no solo de la exactitud de sus

salidas, sino también del tiempo en que se produjeron dichas salidas.

1. Plazos: Tiempos en que debe procesarse los estímulos y producir alguna

respuesta. De no cumplirse en un sistema duro es una falla, en un sistema blando es
una degradación de servicio.

2. Frecuencia: Numero de veces por segundo que debe ejecutarse un proceso para
asegurar que se cumpliran los plazos

3. Tiempo de ejecución: Tiempo requerido para procesar un estímulo y producir una

salida. Tener en cuenta el peor tiempo.

SISTEMAS OPERATIVOS DE TIEMPO REAL:

Un sistema operativo convencional gestiona recursos, archivos, brinda

características (API) y todo esto genera una gran utilización de espacio y tiempos
de ejecución, por eso los delay no son exactos en un SO a diferencia de un
microcontrolador.

Los sistemas embebidos pueden implementarse como sistemas Barebones. Las

aplicaciones embebidas se construyen en la parte superior de un sistema RTOS.

Los componentes de un RTOS son:

1. Reloj de tiempo real, para proporcionar información requerida para programar

procesos periódicamente

2. Manipulador de interrupciones, gestion de peticiones no periódicas de servicios

3. Planificador, examina los procesos que pueden ejecutarse y elegir uno de ellos

4. Gestor de recursos, asigna memoria adecuada y recursos de procesos para aquellos

que se programaron para ejecución

5. Despachador, responsable de iniciar la ejecución de procesos.

Niveles de prioridad:

1. Nivel de interrupción: Prioridad más alta, se asigna a procesos que necesitan

una respuesta muy rápida.

2. Nivel de reloj: Este nivel de prioridad se asigna a los procesos periódicos.

Existen dos estrategias de planeación:

1. No sustitutiva: Una vez se planea el proceso para su ejecución, se ejecuta hasta

completarse o bloquearse.
2. Sustitutiva: Es posible detener la ejecución de un proceso en operación si un
proceso de mayor prioridad requiere servicio.

Algoritmos de planeación:

1. Round-Robin: Cada proceso se ejecuta en turnos

2. Tasa monotónica: Se otorga prioridad al proceso con el periodo más corto

(frecuencia más alta)

3. Plazo más corto: Se programa el proceso en cola con el plazo más corto

CAPITULO 21: INGENIERÍA DE SOFTWARE ORIENTADA A ASPECTOS

En grandes sistemas, las relaciones entre requerimientos y componentes del programa

son complejas, ya que un solo requerimiento puede implementarse a través de muchos
componentes. Por eso modificar un requerimiento implica modificar más de un
componente.

AOSE: Aspect Oriented Software Engineering

AOSE se basa en abstracciones llamadas aspectos para crear software más fácil de
mantener y reutilizar. Aspectos encapsulan funcionalidad que atravise y coexiste
con otra funcionalidad que incluye el sistema.
Un programa orientado a aspectos se crea automáticamente al combinar (tejer, weave)
objetos, métodos y aspectos de acuerdo con las especificaciones comprendidas en el
código fuente del programa.

Una importante característica de los aspectos es que incluyen una definición sobre
dónde deben incluirse en un programa, además del código que implementa la
competencia
que atraviesa. Puede especificar que el código transversal (cross-cutting)
debe incluirse antes o después de una llamada de método específico o al acceder a
un
atributo. En esencia, el aspecto se entrelaza en el programa central para crear un
nuevo
sistema aumentado

El beneficio de AOSE principal es que soporta la separación de competencias. Al

representar las competencias transversales como aspectos, éstas pueden
comprenderse, reutilizarse y modificarse de manera independiente, si importar donde
se usa el código.

Considere que tiene un requerimiento en el que se precise autenticación del usuario

antes de realizar cualquier cambio de información personal en una base de datos.
Puede
describir esto en un aspecto al enunciar que debe incluir un código de
autenticación antes de cada solicitud de métodos que actualicen datos personales

SEPARACIÓN DE INTERESES

Separación de competencias o intereses (concerns) es un principio clave del diseño

e implementación del software. Básicamente es organizar el código a modo que cada
elemento realice una y solo una función.

SOLID:

1. Principio de Responsabilidad Única :“A class should have one, and only one,
reason to change."
2. Principio de Abierto/Cerrado: “You should be able to extend a classes behavior,
without modifying it.”

3. Principio de Sustitución de Liskov: “Derived classes must be substitutable for

their base classes.”

4. Principio de Segregación de la Interfaz: “Make fine grained interfaces that are

client specific.”

5. Principio de Inversión de Dependencias: “Depend on abstractions, not on

concretions.”

Las competencias son más que simplemente elementos funcionales, pero

una definición más general es tan vaga, que en realidad resulta inútil.

Existen varios tipos diferentes de competencias o intereses para el participante:

1. Competencias funcionales: Se relacionan con la funcionalidad específica a

incluir en un sistema. Como el frenado de un tren.

2. Competencias de calidad de servicio: Se relacionan con el comportamiento no

funcional del sistema como rendimiento, fiabilidad y disponibilidad.

3. Competencias de política: Se relacionan con políticas generales que rigen el uso

de un sistema. Incluyen competencias de seguridad y protección, y las relacionadas
con reglas de negocio.

4. Competencias de sistema: Se relacionan con atributos del sistema como un todo,

tales como mantenibilidad o configurabilidad.

5. Competencias organizacionales: Relacionan con metas y prioridades de la

organización, como producir un software dentro del presupuesto, usar activos de
software existente y mantener la imagen de la organización

Las competencias centrales de un sistema son aquellas competencias funcionales

relacionadas
con su propósito primario

Competencias transversales: Pueden influir en la implementación de todos los otros

requerimientos del sistema, como las de seguridad de datos

Las abstracciones de lenguaje de programación, como procedimientos y clases, son el

mecanismo que se usa normalmente para organizar y estructurar las competencias
centrales de un sistema.

Fenomenos indeseables:

1. Enredos (tangling): Ocurre cuando un módulo del sistema incluye código que
implementa diferentes requerimientos del sistema. Por ejemplo, el codigo wait()
para esperar a que un buffer libere espacio está enredado con los metodos put(), ya
que siempre que se desee hacer un put() habrá que utilizar el código de
sincronización wait().

2. Dispersion (Scattering): Cuando la implementación de una competencia se dispersa

a través de varios componentes del programa. Como la competenca de mantener
registros de información personal de un hospital, pero existen otras como consulta,
radiográficas, etc. que el conjunto de ellos logran la competencia central anterior
del registro.
ASPECTOS, PUNTOS DE ENLACE Y PUNTOS DE CORTE

1. Consejo (advice): El código que implementa una competencia

2. Aspecto (aspect): Abstracción de programa que define una competencia

transversal. Incluye el punto de corte (pointcut) y el consejo (advice) de dicha
competencia

3. Punto de enlace (join joint): Evento en un programa en que puede ejecutarse el

consejo asociado con un aspecto.

4. Punto de corte (pointcut): Enunciado, incluido en un aspecto, que define los

puntos de enlace en que debe ejecutarse el consejo del aspecto asociado

5. Tejido (weaving): La incorporación del código del consejo (advice) en los puntos
de enlace (join

Ejemplo: Se requiere autenticación antes de ejecutar un método de Update().

1. Usar update en cada componente para llamar a otros metodos y realizar a

autenticación: Este enfoque lleva a implementación enredada, porque auth y log son
competencias (concerns) no relacionadas, además, el codigo de auth y log debe
incluirse en varios métodos diferentes

2. Modificar el sistema a forma que cada vez que se solicite un método update, las
llamas del método se agreguen antes del llamado para hace autenticación y despues
para registrar los cambios en el log: Esto conlleva a implementación dispersa, ya
que el código de auth y log debe incluirse antes y despues del update() en varios
lugares del código.

La mejor forma de solucionar esto es con el punto de corte (pointcut), se puede

crear un enunciado en Java/AspectJ como el siguiente:

before: call (public void update* (..))

Antes de la ejecución de cualquier método cuyo nombre comience con la cadena

update, debe ejecutarse el código del before (advice).

Eventos de AspectJ:

1. Eventos de llamada: llamadas a un método o constructor;

2. Eventos de ejecución: ejecución de un método o constructor;
3. Eventos de inicialización: inicialización de clase u objeto;
4. Eventos de datos: acceso o actualización de un archivo;
5. Eventos de excepciones: manejo de una excepción.

INGENIERIA DE SOFTWARE CON ASPECTOS

Los aspectos se introdujeron originalmente con un lenguaje de programación de

secuencias,
pero, como se estudió, la noción de competencias es una que realmente proviene de
los requerimientos del sistema

Tipos de extensiones que derivan de los distintos tipos de competencias:

1. Extensiones funcionales secundarias: Agregan capacidades adicionalides a la

funcionalidad que ofrece el sistema central.
2. Extensiones de política: Agregan capacidades funcionales para soportar políticas
de la organización

3. Extensiones QoS: Agregan capacidades funcionales para ayudar alcanzar los

requerimientos de calidad del servicio que se especificaron para el sistema.

4. Extensiones de infraestructura: Agregan capacidades funcionales para soportar la

implementación de un sistema en alguna plataforma de implementación específica.

INGENIERIA DE REQUERIMIENTOS ORIENTADOS A COMPETENCIAS

Las competencias reflejan los requerimientos de las partes interesadas. Se conoce

también como "aspectos tempranos", porque se usan aspectos en etapas tempranas del
ciclo de vida del software donde se enfatiza la separación de competencias.

Importante separar las competencias durante la ingeniería de requerimientos.

DISEÑO Y PROGRAMACIÓN ORIENTADA A ASPECTOS

Diseño orientado a aspectos es el proceso de diseñar un sistema que utilice los

aspectos para implementar las competencias transversales y extensiones que se
identificaron durante el proceso de ingeniería de requerimientos.

Pueden usarse los casos de uso en la ingeniería de software orientada a aspectos.

Sugieren que cada caso de uso representa un aspecto, y proponen extensiones al
enfoque de caso de uso para apoyar los puntos de enlace y puntos de corte.

Proceso de diseño orientado a aspectos:

1. Diseño del sistema central: Se diseña la arquitectura del sistema para soportar
la funcionalidad central del sistema. Debe considerarse también los requerimientos
de QoS, rendimiento y confiabilidad.

2. Identificación y diseño de aspectos: A partir de las extensiones identificadas

en los requerimientos del sistema, habrá que efectuar un análisis para ver si son
aspectos en sí mismos o si debe descomponerse en varios aspectos.

3. Diseño de composición: Se analiza el sistema central y los diseños de aspectos

para descrubir dónde deben combinarse los aspectos con el sistema central, osea,
puntos de enlace donde se tejerán los aspectos.

4. Análisis y resolución de conflictos: Los aspectos pueden interferir entre sí

cuando se combinan con el sistema central. Ocurren cuando hay choque de puntos de
corte con diferentes aspectos que especifican que deben combinarse en el mismo
punto del programa.

5. Diseño de nombre: Ésta es una importante actividad de diseño que define

estándares para nombrar las entidades del programa. Esto es cuando por error el
nombre coincide accidentalmente con el de un patrón de punto de corte.

VERIFICACIÓN Y VALIDACIÓN:

Es demostrar que un programa cumple su especificación (verificación) y satisface

las necesidades reales de las partes interesadas (validación).

1. ¿Cómo deben especificarse los aspectos de manera que puedan derivarse pruebas
para dichos aspectos?

2. ¿Cómo pueden probarse los aspectos independientemente del sistema base con el
que deben tejerse?

3. ¿Cómo puede someterse a prueba la interferencia de aspectos? Como se estudió, la

interferencia de aspectos ocurre cuando dos o más aspectos usan la misma
especificación
de punto de corte.

4. ¿Cómo pueden diseñarse pruebas de manera que se ejecuten todos los puntos de
enlace de programa y se apliquen pruebas de aspecto adecuadas?

CAPITULO 22: GESTIÓN DE PROYECTOS

Gestión de proyectos es una parte esencial de la ingeniería de software. Los

proyectos necesitan administrarse porque la ingeniería del software profesional
está sujeta siempre a estricciones organizacionales de presupuesto y fecha.

El trabajo del administrador del proyecto es asegurarse que el proyecto de software

cumpla y supere tales restricciones, que se entregue software de calidad.

La buena gestión no garantiza el éxito del proyecto, pero la mala gestión suele dar
como resultado falla del proyecto como entregarse tarde, costar más de lo estimado
o no cumplir las expectativas de los clientes.

En la mayoria de proyectos, las metas importantes son:

1. Entregar el software al cliente en el tiempo acordado.

2. Mantener costos dentro del presupuesto general.
3. Entregar software que cumpla con las expectativas del cliente.
4. Mantener un equipo de desarrollo óptimo y con buen funcionamiento.

Estas metas no son únicas de ingeniería de software, pero sí lo son para todos los
proyectos de ingeniería.

la ingeniería de software es diferente en algunas formas a otros tipos de

ingeniería que hacen a la gestión del software particularmente desafiante. Algunas
de estas diferencias son:

1. Producto es intangible: El software es intangigle, no se puede ver ni tocar, es

más dificil constatar el progreso con sólo observar el artefacto que se construye,
a diferencia de una materia prima donde el retraso se nota en la lentitud de otros
procesos.

2. Los grandes proyectos de software con frecuencia son proyectos excepcionales:

Entre más grande el proyecto, más diferente es con respecto a experiencia en
proyectos anteriores, además, los cambios tecnológicos pueden dejar obsoleta la
experiencia pasada de un administrador.

3. Procesos de software son variables y específicos de la organización: Los

procesos de software varían considerablemente de una organización a otra, por
tanto, no se puede saber si un proceso de softwaré llevará a tener problemas.

Actividades de un administrador de proyecto:

1. Planeación de proyecto: Planeación, estimación, calendarización del proyecto y

asignación de tareas a personas. Supervisan y verifican progreso en base a
estándares, monitorizan que esté a tiempo y dentro del presupuesto.

2. Informes: Son responsables de informar el avance del proyecto a clientes y

administradores de compañia. Deben se capaces de comunicarse en varios niveles,
tanto información þecnica detalladas hasta resumenes administrativos.

3. Gestión del riesgo: Tienen que valorar los riesgos que puedan afectar un
proyecto, monitorizar los riesgos y emprender acciones cuando surjan problemas.

4. Gestión de personal: Son responsables de administrar un equipo de personas,

elegir a los integrantes del equipo y buscar que se desempeñen de la manera mas
efectiva.

5. Redactar propuestas: La primera etapa del proyecto puede implicar una propuesta
para obtener un contrato de trabajo, se describen objetivos y como se realizarán.
Estimaciones de costo y calendario, ademas justificar porque el contrato debe darse
a una cierta organización/equipo.

GESTIÓN DEL RIEGSO:

Implica anticipar riesgos que pudieran alterar el calendario del proyecto o la

calidad del software a entregar. Posteriormente, tomar acciones para evitar dichos
riesgos.

1. Riesgos del proyecto: Alteran calendario y recursos. Como la reunincia de un

diseñador experimentado.

2. Riesgos del producto: Afectan la calidad o rendimiento del software, como la

falla de un componente que se adquirió al no desempeñarse como se esperaba.

3. Riesgos empresariales: Afectan a la organización que desarrolla o adquiere el

software, como que un competidor introduzca un nuevo producto, haciendo que las
suposiciones de ventas de un producto de software existente sea demasiado
optimista.

Es necesario registrar los resultados del análisis del riesgo en el plan del
proyecto, junto con análisis de consecuencias. La gestión de riesgos efectiva
facilita hacer frente a
los problemas y asegurar que éstos no conduzcan a un presupuesto inaceptable o a
retrasos
en el calendario. Tal vez se necesite diseñar planes de contingencia de manera que,
si ocurren los riesgos, se puedan tomar acciones inmediatas de recuperación.

Etapas del proceso de gestión del riesgo:

1. Identificación del riesgo: Identificar posibles riesgos para producto, empresa,

proyecto.
2. Análisis del riesgo: Valorar probabilidad y consecuencias de dichos riesgos.
3. Planeación del riesgo: Elaborar planes para enfrentar el riesgo, evitarlo o
minimizarlo.
4. Monitorización del riesgo: Valorar regularmente el riesgo y los planeas para
atenuarlo.

Los risgos también pueden cambiar hasta de prioridad durante cada iteración.

IDENTIFICACIÓN DEL RIESGO:

Algunos tipos de riesgos son:

1. Riesgos tecnológicos: Tecnologías de software/hardware para desarrollar el

sistema.
2. Riesgos personales: Equipo de desarrollo
3. Riesgos organizacionales: Entorno organizacional donde se desarrolla el
software.
4. Riesgos de herramientas: Herramientas de software/soporte para desarrollar el
sistema
5. Riesgos de requerimientos: Cambios a los requerimientos del cliente y proceso de
gestión
6. Riesgos de estimación: Estimaciones administravidas de recursos para construir
el sistema

ANÁLISIS DE RIESGO

Durante el proceso de análisis de riesgos, hay que considerar cada riesgo

identificado y
realizar un juicio acerca de la probabilidad y gravedad de dicho riesgo, debe
apoyarse en su propio juicio y en la experiencia obtenida en los proyectos
anteriores y los problemas que surgieron en ellos.

No es posible hacer valoraciones precisas y numéricas de la probabilidad y gravedad

de cada riesgo

Bandas de riesgo:

1. La probabilidad del riesgo puede valorarse como muy baja (< 10%), baja (del 10
al
25%), moderada (del 25 al 50%), alta (del 50 al 75%) o muy alta (> 75%).

2. Los efectos del riesgo pueden estimarse como catastróficos (amenazan la

supervivencia
del proyecto), graves (causarían grandes demoras), tolerables (demoras dentro
de la contingencia permitida) o insignificantes.

PLANEACIÓN DEL RIESGO

El proceso de planeación del riesgo considera cada uno de los riesgos clave
identificados y
desarrolla estrategias para manejarlos

Categorías de estrategias:

1. Estrategias de evitación: Reducir la probabilidad de que surja el riesgo

2. Estrategias de minimización: Se reducirá el efecto del riesgo.

3. Planeas de contingencia: Se está preparado para lo peor y se tiene una

estrategia para hacer frente a ello.

Aquí se observa una clara analogía con las estrategias utilizadas en los sistemas
críticos
para garantizar fiabilidad, seguridad y protección, cuando hay que evitar, tolerar
o recuperarse de las fallas.

MONITORIZACIÓN DEL RIESGO:

Proceso de comprobar que no han cambiado las suposiciones sobre riesgos de

producto, proceso y empresa. Los riesgos deben monitorizarse comúnmente en todas
las etapas del proyecto. En
cada revisión administrativa, es necesario reflexionar y estudiar cada uno de los
riesgos
clave por separado. También hay que decidir si es más o menos probable que surja el
riesgo, y si cambiaron la gravedad y las consecuencias del riesgo
GESTIÓN DE PERSONAL

Las personas que trabajan en una organización de software son los activos más
importantes. Cuesta dinero reclutar y retener al buen persona, por tanto, la
organización debe aprovechar al máximo su inversión.

Factores críticos en la gestión de personal:

1. Consistencia: Todos deben recibir un trato similar, no hacer sentir que una
persona aporta menos que los demas de la organización.

2. Respeto: Los administradores deben respetar las distintas habilidades de cada

persona.

3. Inclusión: Las personas contribuyen efectivamente cuando sienten que otros las
escuchan y tienen en cuenta.

4. Honestidad: Como administrador debe ser honesto lo que está bien y lo que está
mal en el equipo. Incluyendo conocimientos y habilidades.

MOTIVACIÓN DEL PERSONAL

Como administrador de proyecto, usted necesitará motivar a las personas con quienes
trabaja, de manera que éstas contribuyan con lo mejor de sus habilidades

Necesidades de autorealización:

1. Necesidades de estima
2. Necesidades sociales
3. Necesidades de seguridad
4. Necesidades fisiológicas

Tipos de profesionales:

1. Personas orientadas a tareas: Están motivadas por el trabajo que realizan.

2. Personas orientadas hacia sí mismas: Motivadas principalmente por el éxito y

reconocimiento personal. (no necesariamente son egoistas) quiza tienen metas
profesionales a largo plazo.

3. Personas orientadas a la interacción: Motivadas por la presencia y acciones de

los compañeros de trabajo.

TRABAJO EN EQUIPO:

Los equipos de proyecto de ingeniería de software no deben tener más de 10

miembros, esto con el fin de disminuir los problemas de comunicación.

Conformar un grupo que tiene el equilibrio justo de habilidades técnicas,

experiencia
y personalidades es una tarea administrativa fundamental. Sin embargo, los grupos
exitosos
son mucho más que una colección de individuos con el equilibrio justo de
habilidades.
Un buen equipo es cohesivo y tiene espíritu de grupo. Las personas que participan
están motivadas tanto por el éxito del grupo como por sus metas personales.

En un grupo cohesivo, los miembros piensan que el equipo es más importante que los
individuos que lo integran. Los miembros de un grupo cohesivo bien liderado son
leales
al equipo.

Beneficios de un grupo coheviso:

1. El grupo puede establecer sus propios estándares de calidad Puesto que dichos
estándares se establecen por consenso, éstos tienen más probabilidad de respetarse
que los estándares externos impuestos sobre el grupo.

2. Los individuos aprenden de los demás y se apoyan mutuamente Las personas en el

grupo aprenden de los demás. Las inhibiciones causadas por la ignorancia se
minimizan
mientras se promueve el aprendizaje mutuo.

3. El conocimiento se comparte Puede mantenerse la continuidad si sale un miembro

del grupo. Otros en el grupo pueden tomar el control de las tareas críticas para
asegurar
que el proyecto no se altere en forma considerable.

4. Se alientan la refactorización y el mejoramiento continuo Los miembros del grupo

trabajan de manera colectiva para entregar resultados de alta calidad y corregir
problemas,
sin importar quiénes crearon originalmente el diseño o programa.

Factores que afectan el trabajo en equipo:

1. Las personas en el grupo Se necesita una combinación de personas en un grupo

de proyecto, puesto que el desarrollo de software implica diversas actividades,
como
negociación con clientes, programación, pruebas y documentación.

2. La organización grupal Un grupo debe organizarse de forma que los individuos

puedan contribuir con sus mejores habilidades y completar las tareas como se
esperaba.

3. Comunicaciones técnicas y administrativas Es esencial la óptima comunicación

entre los miembros del grupo, y entre el equipo de ingeniería de software y otras
partes interesadas en el proyecto.

SELECCIÓN DE LOS MIEMBROS DEL GRUPO:

La labor de un administrador o líder de equipo es crear un grupo cohesivo y

organizar a
los miembros del grupo para que puedan trabajar en conjunto de manera efectiva.

Con frecuencia deben recurrir a las personas que estén disponibles en la compañía,
aun cuando no sean ideales para el puesto

En ocasiones es imposible elegir un grupo con personalidades complementarias. Si

éste es el caso, el administrador del proyecto tiene que controlar al grupo de modo
que
las metas individuales no se antepongan a los objetivos de la organización y del
grupo.

ORGANIZACIÓN DEL GRUPO:

La forma en que se organiza un grupo influye en las decisiones que toma dicho
grupo, las
maneras como se intercambia la información y las interacciones entre el grupo de
desarrollo
y los participantes externos del proyecto.

1. Si el administrador del proyecto tiene las habilidades, puede ser también lider
técnico. Si el proyecto es muy grande, lo mejor es contratar a un ingeniero con
experiencia coo arquitecto del proyecto,

2. ¿Quién se encargará de tomar las decisiones técnicas críticas, y cómo se

tomarán?

3. ¿Cómo se manejarán las interacciones con los participantes externos y los altos
directivos de la compañía?

4. ¿Cómo es posible que los grupos logren integrar a personas que no se localizan
en el mismo lugar?

5. ¿Cómo puede compartirse el conocimiento a través del grupo?

COMUNICACIONES GRUPALES:

Es absolutamente esencial que los miembros del grupo se comuniquen efectiva y

eficientemente
entre sí y con otras partes interesadas en el proyecto. La efectividad de las
comunicaciones están influidas por:

1. Tamaño del grupo: El número de vínculos de comunicación de un

canal es n * (n – 1), donde n es el tamaño del grupo, de manera que, con un grupo
de ocho miembros, existen 56 posibles rutas de comunicación.

2. Estructura del grupo: Las personas en los grupos estructurados de manera

informal
se comunican más efectivamente que los individuos en grupos con una estructura
jerárquica formal

3. Composición del grupo: Las personas con los mismos tipos de personalidad pueden
chocar y, como resultado, las comunicaciones se inhiben

4. EL ambiente laboral físico: La organización del centro de trabajo es un factor

importante para facilitar o inhibir las comunicaciones

5. Los canales de comunicación disponibles: Existen muchas formas diferentes de

comunicación: cara a cara, correo electrónico, documentos formales, teléfono y
tecnologías Web 2.0, como las redes sociales y los wikis

CAPITULO 23: PLANEACIÓN DE PROYECTOS

La planeación de proyectos es una de las labores más importantes de un

administrador
de proyectos de software. Como administrador, debe dividir el trabajo en partes y
asignar
éstas a los miembros del equipo del proyecto, anticipar los problemas que pudieran
surgir y preparar posibles soluciones a tales inconvenientes.

La planeación se presenta durante tres etapas en un ciclo de vida del proyecto:

1. Etapas de propuestas: Elaborar un plan de licitación que demuestre que se tienen

los recursos, tiempo y un precio para el cliente.
2. Fase de inicio: Quien trabajará en el proyecto, cómo se dividirán los
incrementos, asignación de recursos.

3. Periódicamente a lo largo de proyecto: Esta información permite hacer

estimaciones más precisas sobre cuánto tardará el trabajo. Más aún, es probable que
los requerimientos del software cambien y esto, por lo general, significa que debe
modificarse la división del trabajo y extenderse el plazo.

Existen tres principales parámetros que se deben usar al calcular los costos de un
proyecto
de desarrollo de software:

1. Costos de esfuerzo: Pago de ingenieros y administradores

2. Costos de hardware, software y mantenimiento
3. Costos de viajes y capacitación

FIJACIÓN DE PRECIO AL SOFTWARE

El precio no solo depende de sacar el costo de desarrollo y ganacias del diseñador.

El precio puede verse afetado por la organización, economía, política. Riesgos y
tipos de contrato.

Como el costo de un proyecto sólo está débilmente relacionado con el precio

cotizado
a un cliente, “cotizar para ganar” es una estrategia usada comúnmente. Cotizar para
ganar
significa que una compañía tiene alguna idea del precio que el cliente espera pagar
y
hace una apuesta por el contrato con base en el precio esperado por el cliente.
Esto puede
parecer no ético y poco práctico en los negocios, pero tiene ventajas tanto para el
cliente
como para el proveedor del sistema.

DESARROLLO DIRIGIDO POR UN PLAN:

El desarrollo dirigido por un plan o basado en un plan es un enfoque para la

ingeniería de
software donde el proceso de desarrollo se planea a detalle. Se elabora un plan de
proyecto
que registra el trabajo que se va a realizar, quién lo efectuará, el calendario de
desarrollo y
los productos de trabajo. Los administradores utilizan el plan para apoyar la toma
de decisiones
del proyecto y también como una forma de medir el progreso.

El principal argumento contra el desarrollo basado en un plan es que muchas

decisiones
tempranas deben revisarse debido a cambios al entorno en los que se desarrollará y
usará el software.

Los argumentos en favor de un enfoque dirigido por un plan son que la

planeación temprana permite que los asuntos de la organización (disponibilidad de
personal,
otros proyectos, etcétera) se tomen estrictamente en cuenta, y que los problemas
potenciales y dependencias se descubran antes de que se inicie el proyecto, y no
cuando
ya esté en marcha.
Desde esta perspectiva, el mejor enfoque a la planeación del proyecto incluye una
mezcla juiciosa de desarrollo basado en un plan y ágil. El equilibrio depende del
tipo de
proyecto y de las habilidades del personal que estén disponibles.

PLANES DE PROYECTO

En el plan de proyecto se establecen

los recursos disponibles para el proyecto, la división del trabajo y un calendario
para
realizar el trabajo.

Los planes incluyen por lo regular las siguientes secciones:

1. Introducción: Describe brevemente los objetivos del proyecto y establece

restricciones.

2. Organización del proyecto: Forma de organizar el equipo, personas y sus roles.

3. Análisis de riesgo: Detalla posibles riesgos del proyecto, probabilidad que

surjan y estrategias para reducirlo.

4. Requerimientos de recursos de hardware y software: Detallan el H/S requerido

para realizar el trabajo

5. División del trabajo: División del proyecto en actividades, plazos, entregas.

6. Calendario del proyecto: Indica las dependencias entre las actividades, tiempo
estimado para cada plazo y asignación de personal a las actividades.

7. Mecanismos de monitorización y reporte: Define informes administrativos que

deben producirse, cuando elaborarse y mecanismos de monitorización de proyecto que
se usarán.

PROCESO DE PLANEACIÓN

La planeación del proyecto es un proceso iterativo que comienza cuando se diseña un

plan de proyecto inicial durante la fase de arranque del proyecto. Un diagrama de
actividad UML que muestra un flujo de trabajo típico para un proceso de planeación
de proyecto

CALENDARIZACIÓN DE PROYECTOS

Proceso de decidir cómo se organizará el trabajo en un proyecto como tareas

separadas, cuando y cómo se ejecutarán dichas tareas. Se estima el tiempo
calendario para completar cada tarea, el esfuerzo requerido y quién
trabajará en las tareas identificadas. También hay que estimar los recursos
necesarios
para completar cada tarea (como el espacio de disco requerido en un servidor), el
tiempo
que se necesitará el hardware especializado (como un simulador) y cuál será el
presupuesto
de viajes.

Tanto los procesos basados en un plan como los ágiles precisan de un calendario
de proyecto inicial, aunque el nivel de detalle puede ser menor en un plan de
proyecto
ágil.
Algunas de estas tareas se realizan paralelamente, con distintas personas que
trabajan
en diferentes componentes del sistema. Es necesario coordinar las tareas paralelas
y organizar
las actividades para que la fuerza de trabajo se desempeñe de manera óptima y no
introduzca entre las tareas dependencias innecesarias

Como ya se sugirió, al evaluar calendarios hay que tomar en cuenta la posibilidad

de
que las cosas salgan mal.

Una buena regla empírica es estimar que nada saldrá mal, luego ampliar la
estimación
para enfrentar problemas anticipados. También puede añadirse a la estimación un
factor
de contingencia para hacer frente a problemas no anticipados

REPRESENTACIÓN DEL CALENDARIO:

Los calendarios de proyecto pueden representarse simplemente en una tabla u hoja de

cálculo que indique las tareas, el esfuerzo, la duración esperada y las
dependencias entre
las tareas

1. Gráficas de barra: Graficas de Gantt

2. Redes de actividad: Muestran dependencias entre las diferentes actividades que

constituyen un proyecto.

Las actividades de proyecto son el elemento de planeación básico. Cada actividad

cuenta con:

1. Duración en días o meses calendario

2. Estimación del esfuerzo, número de días-hombe o meses-hombre para completar el

trabajo

3. Plazo dentro del cual completar la actividad

4. Punto final definido. Resultado tangile de completar la actividad.

Cuando planee un proyecto, también deberá definir los hitos; esto es, cada etapa
del
proyecto en la que puede realizarse una valoración del avance

PLANEACIÓN ÁGIL

Los métodos ágiles de desarrollo de software son enfoques iterativos donde el

software
se desarrolla y entrega a los clientes en incrementos.

A diferencia de los enfoques dirigidos

por un plan, la funcionalidad de dichos incrementos no se planea por anticipado,
sino
que se decide durante el desarrollo

1. Planeación de la entrega (release), que prevé con muchos meses de antelación y

decide sobre las características que deben incluirse en una entrega de un sistema.
2. Planeación de la iteración, la cual tiene un panorama a corto plazo y se enfoca
en
la planeación del siguiente incremento de un sistema. Esto, para el equipo,
generalmente
representa de dos a cuatro semanas de trabajo.

Existen dos beneficios importantes a partir de este enfoque a la asignación de

tareas:

1. Todo el equipo consigue un panorama de las tareas a completar en una iteración.

Por
lo tanto, todos tienen una comprensión de lo que hacen otros miembros del equipo y
saben a quién dirigirse si se identifican dependencias de tarea.

2. Los desarrolladores individuales eligen las tareas a implementar; no son

simplemente
tareas asignadas por un administrador de proyecto. En consecuencia, tienen
un sentido de propiedad sobre dichas actividades y es probable que esto los motive
a completar la tarea.

TÉCNICAS DE ESTIMACIÓN

Es difícil la estimación del calendario del proyecto. Probablemente haya que hacer
estimaciones
iniciales sobre la base de una definición de requerimientos de usuario de alto
nivel.

Técnicas de estimación:

1. Técnicas basadas en la experiencia La estimación de los requerimientos de

esfuerzo futuro se basan en la experiencia del administrador con proyectos
anteriores
y el dominio de aplicación. En esencia, el administrador emite un juicio informado
de cuáles serán los requerimientos de esfuerzo.

2. Modelado algorítmico de costo En este caso se usa un enfoque formulista para

calcular el esfuerzo del proyecto con base en estimaciones de atributos del
producto
(por ejemplo, el tamaño), así como las características del proceso (por ejemplo, la
experiencia del personal implicado).

MODELADO ALGORÍTMICO DE COSTOS:

El modelado algorítmico de costos utiliza una fórmula matemática para predecir los
costos
del proyecto con base en estimaciones del tamaño del proyecto, el tipo de software
a desarrollar, y otros factores de equipo, proceso y producto.

Los modelos algorítmicos para estimar el esfuerzo en un proyecto de software se

basan principalmente en una fórmula sencilla:

Esfuerzo = A x Tamaño^B x M

Todos los modelos algorítmicos tienen problemas similares:

1. Con frecuencia es difícil estimar el Tamaño en una etapa temprana del proyecto,
cuando sólo está disponible la especificación. Las estimaciones de punto de función
y punto de aplicación (véase más adelante) son más fáciles de producir que las
estimaciones
de tamaño del código, pero por lo general aún son imprecisas.

2. Las estimaciones de los factores que contribuyen a B y M son subjetivas. Las

estimaciones
varían de una persona a otra, dependiendo de sus antecedentes y experiencia
con el tipo de sistema que se desarrolla.

MODELO COCOMO II:

Éste es un modelo empírico que se derivó al recopilar datos a partir de

un gran número de proyectos de software.

Dichas fórmulas vinculan el tamaño

del sistema y los factores del producto, proyecto y equipo, con el esfuerzo para
desarrollar
el sistema

Los submodelos (figura 23.10) que se consideran parte del modelo COCOMO II son:

1. Un modelo de composición de aplicación Éste modela el esfuerzo requerido para

desarrollar sistemas que se crean a partir de componentes de reutilización,
escritura de guiones o programación de base de datos. El número de puntos de
aplicación en un
programa es una estimación ponderada del número de pantallas separadas que se
despliegan, el número de informes que se producen, el número de módulos en
lenguajes
de programación imperativa (como Java) y el número de líneas de lenguaje
de escritura de guiones (scripting) o código de programación de base de datos

2. Un modelo de diseño temprano Este modelo se usa durante etapas tempranas del
diseño del sistema después de establecer los requerimientos. La estimación se basa
en la fórmula de estimación estándar que se discutió en la introducción, con un
conjunto
simplificado de siete multiplicadores. Los puntos
de función son una forma independiente de lenguaje para cuantificar la
funcionalidad
del programa. El número total de puntos de función en un programa se calcula
al medir o estimar el número de entradas y salidas externas, las interacciones de
usuario, las interfaces externas y las tablas de archivos o bases de datos que usa
el
sistema

3. Un modelo de reutilización Este modelo se emplea para calcular el esfuerzo

requerido
al integrar los componentes de reutilización y/o código de programa generado
automáticamente. Muchas veces se utiliza en conjunto con el modelo
posarquitectónico.

4. Un modelo posarquitectónico Una vez diseñada la arquitectura del sistema, puede

hacerse una estimación más precisa del tamaño del software. Nuevamente, este
modelo usa la fórmula estándar para estimación de costo discutida líneas arriba.
Sin embargo, incluye un conjunto más extenso de 17 multiplicadores que reflejan
características de capacidad personal, del producto y del proyecto.

DURACIÓN DEL PROYECTO Y ASIGNACIÓN DEL PERSONAL

Además de estimar los costos globales de un proyecto y el esfuerzo que se requiere

para
desarrollar un sistema de software, los administradores de proyecto también deben
estimar
cuánto tardará el software en desarrollarse, y cuándo el personal necesitará
trabajar en el
proyecto

El modelo COCOMO incluye una fórmula para estimar el tiempo calendario requerido
para completar un proyecto:

TDEV = 3 X (PM) ^ (0.33 1 0.2*(B 2 1.01)

TDEV es el calendario nominal para el proyecto, en meses calendario, que ignora

cualquier
multiplicador relacionado con el calendario del proyecto.

PM es el esfuerzo calculado por el modelo COCOMO.

B es el exponente relacionado con la complejidad

Si B = 1.17 y PM = 60, entonces

TDEV = 3 X (60)^0.36 = 13 meses

CAPÍTULO 24: GESTIÓN DE LA CALIDAD

El desarrollo de los primeros grandes sistemas de software resultaron ser lentos,

poco fiables, difíciles de mantener y de reutilizar. Este descontento condujo a la
adopción de técnicas de gestión de calidad.

Gestión de calidad del software para sistemas de software tiene tres intereses
fundamentales:

1. A nivel de organización: Equipo de gestión de calidad tiene la responsabilidad

de definir procesos de desarrollo del software a usar, estándares que deben
aplicarse al software y su documentación relacionada, incluyendo los
requerimientos, el diseño y el código del sistema.

2. A nivel de proyecto: Implica la aplicación de procesos específicos de calidad y

verificación, garantiza que los resultados del proyecto estén en conformidad con
los estándares aplicables a dicho proyecto.

3. A nivel de proyecto: La gestión de calidad también se ocupa de establecer un

plan de calidad para un proyecto.

Los términos de aseguramiento de calidad y control de calidad, use utilizan

ampliamente en la industria manufacturera.

QA: Quality Assurance, es la definición de procesos y estándares que deben conducir

a la obtención de productos de alta calidad, y en el proceso de fabricación, a la
introducción de procesos de calidad.

Aseguramiente de calidad suele incluir Verificación y Validación

Bosquejo de estructura para un plan de calidad:

1. Introducción del producto: Descripción del producto, presentsión de su mercado y

las expectativas de calidad para el producto.

2. Planes del producto: Indican fechas de entrega críticas y las responsabilidades

para el producto, junto con planes para distribución y servicio al producto.
3. Descripción de procesos: Describen procesos y estándares de desarrollo y
servicio que deben usarse para diseño y gestión del producto.

4. Metas de calidad: Metas y planes de calidad para el producto, incluyendo una

identificación y justificación de los atributos esenciales de calidad y del
producto.

5. Riesgos y gestión del riesgo: Los riesgos clave que pueden afectar la calidad
del producto y las acciones a tomar para enfrentar dichos riesgos

Cuando se describan planes de calidad, se debe tratar de mantenerlos tan breves

como sea posible, de lo contrario podrían no leerlo y anular el proposito del plan.

Los administradores de calidad deben desarrollar una "cultura de calidad" para que
todo responsable del desarrollo del software se comprometa a lograr un alto nivel
de calidad del producto.

Hay aspectos intangibles en la calidad, como elegancia, legibilidad, etc. Los

administradores de calidad deben logra que estos aspectos sean tomados en cuenta
por los desarrolladores.

CALIDAD DEL SOFTWARE

Es prácticamente imposible llegar a una conclusión objetiva sobre si un sistema de

software cumple o no con su especificación, por las siguientes razones:

1. Es difícil escribir especificaciones de software completas y sin ambigüedades.

Esto causa que los desarrolladores y clientes interpreten los requerimientos de
diferentes formas, imposibilitando llegar a acuerdos acerca de si el software
cumple conforme a su especificación.

2. Las especificaciones integran requerimientos de varias clases de participantes.

PEro es posible que no se incluyan requerimientos de todos los grupos de
participantes, haciendo los excluidos perciban el sistema como uno de mala calidad.

3. Es imposible medir de manera directa ciertas características de calidad (como

mantenibilidad) y por ende, no pueden especificarse plenamente sin ambiguüedades.

El equipo de gestión de calidad debe usar su juicio para decidir si se logró un

nivel aceptable de calidad:

1. ¿En el proceso de desarrollo se siguieron los estándares de programación y

documentación?
2. ¿El software se verificó de manera adecuada?
3. ¿El software es suficientemente confiable para utilizarse?
4. ¿El rendimiento del software es aceptable para uso normal?
5. ¿El software es utilizable?
6. ¿El software está bien estructurado y es comprensible?

La calidad no solo depende de si la funcionalidad del software se implementó

correctamente, sino que también depende de los atributos no funcionales
(fiabilidad, velocidad, etc). Si los no funcionales no se cumplen, dificilmente un
usuario utilizará el software.

ESTÁNDARES DE SOFTWARE

Los estándares de software tienen una función muy imporante en la gestión de

calidad del software. Los estandares de software son importantes por tres razones:
1. Estandar refleja sabiduría, brindan mejor o más adecuada práctica para la
compañia. Ayuda a reutilizar experiencia y evitar errores pasados.

2. Estandar permite definir de mejor manera el término "calidad". Para esto hay que
establecer estándares que reflejen expectativas del usuario para confiabilidad,
usabilidad y rendimiento del software.

3. Estandares auxilian la continuidad cuando una persona retoma el trabajo iniciado

por alguien más. Estandares aseguran que todos los ingenieros adopten las mismas
prácticas.

Existen dos tipos de estándares de ingeniería de software relacionados que pueden

definirse y usarse en la gestión de calidad del software:

1. Estandares del producto: Se aplican al producto de software a desarrollar,

incluyen documentos, estandares hasta de comentarios, codificación, usos del
lenguaje de programación.

2. Estándares de proceso: Establecen procesos que deben seguirse durante el

desarrollo del software. Pueden incluir definiciones de especificación, procesos
de diseño y validación, herramientas de soporte de proceso y una descripción de los
documentos que deben escribirse durante dichos procesos.

Los estándares deben entregar valor, en la forma de calidad aumentada del producto.
No hay razón para definir estándares que sean costosos en términos de tiempo y
esfuerzo,
pues aplicarlos sólo conduce a mejoras secundarias en la calidad

Los administradores de calidad que establezcan los estándares deben dar los
siguientes pasos:

1. Involucrar a los ingenieros de software en la selección de estándares de

producto
2. Revisar y modificar regularmente los estándares para reflejar las tecnologías
cambiantes
3. Ofrecer herramientas de software para dar soporte a los estándares

EL MARCO DE ESTÁNDARES ISO 9001

El ISO 9000 es un conjunto internacional de estándares que pueden utilizarse en el

desarrollo de los sistemas de administración de calidad en todas las industrias.

El ISO 9001 es el más general, aplica a organizaciones que diseñan, desarrollan y

mantienen productos, incluido software. Es más un marco para elaborar estándares
que un estándar por sí mismo. Establece principios de calidad totoal, describe el
proceso de calidad, explica estandares y procedimientos organizacionales que deben
determinarse.

Se puede obtener la certificación de ISO 9001 para clientes esten seguros que la
compañia que desarrolla el software tiene un sistema de gestión de calidad
aprobado.

REVISIONES E INSPECCIONES

Revisiones e inspecciones son actividades QA. Comprueban la calidad de los

entregables del proyecto. Examinar el software, documentación y los registros de
proceso para descubrir errores y omisiones, así como observar que se siguieron los
estándares de calidad. Se usan en conjunto con las pruebas del programa como parte
del proceso general de verificación y validación del software.
Si se descubren problemas, los comentarios de los revisores deben pasar al autor
del software o al responsable de corregir estos errores u omisiones.

El proceso de revisión se estructua por lo general en tres fases:

1. Actividades previas a la revisión: Actividades preparatorias esenciales para que

sea efectiva la revisión. Planeación y preparación de la revisión. Establecer
equipo de revisión, organizar un iempo, destinar un lugar para la revisión y
distribuir los documentos a revisar.

2. La reunión de revisión: Un autor del documento o programa a revisar debe repasar

el documento con el equipo de revisión. Debe ser corta (2 horas a lo sumo). La
dirección de la revisión debefirmar un registro de comentarios y acciones acordados
durante la reisión, y el responsable es el encargado de garantizar que se cumplan.

3. Actividades posteriores a la revisión: Despues de terminada la reunión, deben

tratarse los conflictos y problemas surgidos durante la revisión. Implica corregir
bugs de software, refactorizar el software de modo que esté conforme con los
estándares de calidad, o reescribir los documentos

INSPECCIONES DEL PROGRAMA:

Son revisiones de partes, en las que los miembros del equipo colaboran para
encontrar bugs en el programa de desarrollo. Pueden ser parte del proceso de
verificación y validación. Complementan las pruebas pues no se requiere la
ejecución del programa.

Los defectos pueden ser errores lógicos, anomalías en el código que indican una
condición errónea o ciertas características que se hayan omitido del código

Es posible detectar más del 60% de los errores en un programa mediante inspecciones
informales de programa.

Un enfoque más formal a la inspección, con base en argumentos de exactitud, permite

detectar más del 90% de los errores en un programa.

Los procesos ágiles pocas veces usan procesos de inspección formal o revisión de
pares. En vez de ello, se apoyan en los miembros del equipo que cooperan para
comprobar
mutuamente el código y en lineamientos informales, tales como “comprobar antes
de ingresar”, lo que sugiere que los programadores deben comprobar su propio
código.

Los profesionales de la programación extrema argumentan que la programación en

parejas
es un sustituto efectivo de la inspección, ya que, en efecto, se trata de un
proceso de
inspección continuo. Dos personas observan cada línea de código y la comprueban
antes
de aceptarla.

MEDICIÓN Y MÉTRICAS DEL SOFTWARE

La medición del software se ocupa de derivar un valor numérico o perfil para un

atributo
de un componente, sistema o proceso de software. Al comparar dichos valores unos
con
otros, y con los estándares que se aplican a través de una organización, es posible
extraer
conclusiones sobre la calidad del software, o valorar la efectividad de los
procesos, las
herramientas y los métodos de software.

Existen dos formas en que pueden usarse las mediciones de un sistema de software:

1. Para asignar un valor a los atributos de calidad del sistema (como

mantenibilidad)
2. Para identificar los componentes del sistema cuya calidad está por debajo de un
estándar

Existen razones por las que se dificulta implementar programas de métricas

organizacional:

1. Es imposible cuantificar la rentabilidad de la inversión de introducir un

programa de métricas organizacional.

2. No hay estándares para las métricas de software o para los procesos

estandarizados para medición y análisis.

3. En gran parte de las compañias, los procesos de software no están estandarizados

y se encuentran mal definidos y controlados.

4. Buena parte de la investigación en la medición y métricas del software se enfoca

en métricas basadas en códigos y procesos de desarrollo basados en un plan.

5. La introducción de medición representa una carga adicional a los procesos. Esto

contradice las metas de los métodos ágiles, los cuales recomiendan la eliminación
de
actividades de proceso que no están directamente relacionadas con el desarrollo de
programas.

MÉTRICAS DEL PRODUCTO

Las métricas del producto son métricas de predicción usadas para medir los
atributos internos de un sistema de software. Incluye tamaño del sistema, la medida
en líneas de código, número de métodos asociados con cada clase de objeto.

Las métricas del producto se dividen en dos clases:

1. Métricas dinámicas: Se recopilan mediante mediciones hechas de un programa en

ejecución. Número de reportes de bugs o el tiempo necesario para completar un
cálculo. Ayudan a valorar la eficiencia y fiabilidad de un programa.

2. Métricas estáticas: Se recopilan mediante mediciones hechas de representaciones

del sistema, como el diseño, el programa o la documentación. Tamaño de código y la
longitud promedio de los identificadores. Ayudan a valorar la complejidad,
comprensibilidad y mantenibilidad de un software y sus componentes.

ANÁLISIS DE COMPONENTES DE SOFTWARE

Cada componente del sistema puede analizarse por separador mediante un rango de
métricas. Las etapas clave en este proceso de medición de componentes son:

1. Elegir las mediciones a realizar: Deben formularse las preguntas que la medición
busca responder y definir las mediciones requeridas para responder a tales
preguntas.
2. Seleccionar componentes a valorar: No es necesario estimar méticas para todos
los componentes de un software.

3. Medir las características de los componentes: Se miden los componentes

seleccionados y se calculan los valores de métrica asociados.

4. Identificar mediciones anómalas: Se comparan las mediciones de componentes unas

con otras, y con mediciones pasadas para encontrar desviaciones.

5. Analizar componentes anómalos: Si se identifican vaores anomales, hay que

examinar los componentes para decidir si dichos valores de métrica significan que
la calidad está comprometida o no.

AMBIGÜEDAD DE MEDICIONES

Cuando reúna datos cuantitativos relativos al software y los procesos de software,

deberá
analizar dichos datos para entender su significado. Es fácil malinterpretar los
datos y
hacer inferencias incorrectas. No basta con observar los datos por sí mismos, sino
que
también hay que considerar el contexto donde se recaban los datos.

Para comprender por qué puede ocurrir este tipo de ambigüedad, hay que conocer las
razones por las que los usuarios pueden hacer peticiones de cambio:

1. El software no es lo bastante bueno y no hace lo que quieren los clientes. Por

lo
tanto, solicitan cambios para obtener la funcionalidad que ellos requieren.

2. Como alternativa, el software puede ser muy bueno y, por consiguiente, se usa
amplia e intensamente. Las peticiones de cambio pueden generarse porque existen
muchos usuarios de software que piensan creativamente en nuevas ideas que
podrían hacer con el software.

CAPÍTULO 25: ADMINISTRACIÓN DE LA CONFIGURACIÓN

Los sistemas de software siempre cambian durante su desarrollo y uso. Se descubren

bugs y éstos deben corregirse. Los requerimientos cambian, y es necesario
implementar dichos cambios en una nueva versión del sistema. También hay nuevas
versiones de software/hardware.

La administración de la configuración (Configuration Management) se ocupa de las

políticas, procesos y herramientas para administrar los sistemas cambiantes de
software.

Es necesario gestionar los sistemas en evolución para no perder la pista de cuáles

cambios y versiones implementan propuestas para cambios.

El objetivo de la administración de configuración es evitar gastar esfuerzo

modificando la versión equivocada de un sistema.

La administración de la configuración de un producto de sistema de software

comprende
cuatro actividades estrechamente relacionadas:

1. Administración del cambio: Seguir peticiones de cambios por clientes y

desarrolladores, estimar costos, efecto de realizar los cambios y decidir si deben
implementarse y cuando.
2. Gestión de versiones: Seguimiento de versiones de componentes, garantizar que
cambios a los componentes no interfieran entre sí

3. Construcción del sistema: Proceso de ensamblar componentes, datos y librerías,

luego compilarlos y vincularlos para crear un sistema ejecutable.

4. Gestión de entregas (release): Preparar el software para entrega externa,

seguimiento de versiones.

Las herramientas de apoyo a la administración de gestión incluyen programas como

seguimientos de bugs.

Las políticas y los procesos de administración de la configuración definen cómo

registrar
y procesar los cambios propuestos al sistema, cómo decidir qué componentes del
sistema
modificar, cómo gestionar las diferentes versiones del sistema y sus componentes,
y cómo distribuir estos cambios a los clientes.

Las herramientas de administración de la

configuración se usan para rastrear las propuestas de cambio, almacenar versiones
de
componentes del sistema, construir sistemas a partir de dichos componentes, y
rastrear
liberaciones de las versiones del sistema para los clientes.

ADMINISTRACIÓN DEL CAMBIO

Las necesidades y los requerimientos organizacionales cambian durante la vida de un

sistema, los bugs deben repararse, los sistemas adaptarse a su entorno.

Para garantizar que los cambios se apliquen al sistema de forma controlada, es

necesario un conjunto de procesos de gestión de cambio soportado por herramientas.

El proceso de administración del cambio se ocupa de analizar los costos y

beneficios
de los cambios propuestos, aprobar aquellos que lo ameritan e indagar cuál o cuáles
de
los componentes del sistema se modificaron

Los procesos de administración del cambio deben tener siempre un medio que
compruebe, costee y apruebe los cambios.

Algunas compañías tratan por separado los reportes de

bug y los nuevos requerimientos, pero, en principio, ambos son simplemente
peticiones
de cambio. Estas últimas pueden enviarse mediante un formato de petición de cambio
(CRF, por las siglas de change request form)

Después de enviar una petición de cambio, ésta se verifica para asegurarse de que
sea válida. Además, no todas las peticiones de cambio requieren acción. En
ocasiones,
lo que la gente considera como problemas en realidad son malas interpretaciones
de lo que se espera que haga el sistema

Un grupo separado debe determinar si realizar el cambio

al software es rentable desde una perspectiva empresarial. Para sistemas militares
y
gubernamentales este grupo se conoce usualmente como consejo de control del cambio
(CCB, por las siglas de change control board). En la industria puede llamarse
“grupo de
desarrollo del producto”, el cual es el responsable de tomar las decisiones sobre
cómo
debe evolucionar el sistema de software. Decide si el cambio
en cuestión está justificado económicamente y prioriza los cambios aceptados para
su
implementación.

Los factores significativos que deben tomarse en cuenta para decidir si un cambio
debe aprobarse o no son los siguientes:

1. Las consecuencias de no realizar el cambio: Cuando se valora una petición de

cambio se debe considerar lo que ocurrirá si éste no se implementa

2. Los beneficios del cambio: ¿El cambio es algo que beneficiará a muchos usuarios
del sistema o simplemente es una propuesta que beneficiará sobre todo a quien
propone
el cambio?

3. El número de usuarios afectados por el cambio: Si sólo algunos usuarios resultan

afectados, entonces al cambio se le puede asignar una baja prioridad. De hecho,
hacer el cambio no resulta aconsejable si pudiera tener efectos adversos sobre la
mayoría de los usuarios del sistema

4. Los costos de hacer el cambio: Si hacer el cambio afecta a muchos componentes

del sistema (lo que, por lo tanto, aumenta las posibilidades de introducir nuevos
bugs) y/o tarda mucho tiempo en implementarse, entonces se puede rechazar el
cambio,
debido a los elevados costos implicados.

5. El ciclo de liberación del producto: Si una nueva versión del software se libera
a
los clientes, tal vez tenga sentido demorar la implementación del cambio hasta la
siguiente liberación planeada

En algunos métodos ágiles, como en la programación extrema, los clientes participan

directamente en la decisión de implementar un cambio

GESTIÓN DE VERSIONES

Es el proceso de hacer un seguimiento de las diferentes versiones de los

componentes de software o ítems de configuración, y los sistemas donde se usan
dichos componentes

La gestión de versiones es el proceso de administrar líneas de código y líneas

base.

Baseline: A baseline is a collection of component versions that make up a

system. ... This means that it should always be possible to recreate a baseline
from its constituent components.

Codeline: A codeline is a set of versions of a software component and other

configuration items on which that component depends.

Para soportar la gestión de versiones, siempre se deben usar herramientas de

gestión
de versiones (llamadas en ocasiones sistemas de control de versiones o sistemas de
control de código fuente).

Los sistemas de gestión de versiones ofrecen a menudo varias características:

1. Identificación de versión y entrega (release): A las versiones gestionadas se

les asignan identificadores cuando se envían al sistema.

2. Gestión de almacenamiento: Para reducir el espacio de almacenamiento requerido

por múltiples versiones de los componentes que difieren sólo ligeramente, los
sistemas
de gestión de versiones ofrecen, por lo general, facilidades de gestión de
almacenamiento.
En vez de conservar una copia completa de cada versión, el sistema
almacena una lista de diferencias (deltas) entre una versión y otra

3. Registro del historial de cambios: Todos los cambios realizados al código de un

sistema o componente se registran y enumeran.

4. Desarrollo independiente: Es posible que diferentes desarrolladores trabajen en

el
mismo componente al mismo tiempo. El sistema de gestión de versiones hace un
seguimiento de los componentes que se marcaron para la edición y se asegura de que
no interfieran los cambios hechos a un componente por diferentes desarrolladores.

5. Soporte de proyecto: Un sistema de gestión de versiones puede soportar el

desarrollo
de varios proyectos que comparten componentes

Una consecuencia del desarrollo independiente del mismo componente es que las
líneas de código pueden ramificarse (branch).

Espacio publico es donde se almacena el código (repositorio), el privado es el

local donde se modifica (local del desarrollador)

CONSTRUCCIÓN DEL SISTEMA

La construcción del sistema es el proceso de crear un sistema ejecutable y completo

al
compilar y vincular los componentes del sistema, librerías externas, archivos de
configuración,
etcétera.

Plataformas de sistema en el proceso de construir:

1. El sistema de desarrollo: Herramientas de desarrollo, compiladores, editores. Se

construye una versión del sistema local para probar antes.

2. Servidor de construcción: Se usa para construir versiones ejecutables

definitivas del sistema.

3. Entorno objetivo: Plataforma donde se ejecuta el sistema.

Existe una gran cantidad de herramientas de construcción disponibles, y un sistema

de
construcción puede ofrecer algunas de las siguientes características o todas ellas:

1. Generación de rutinas (scripts) de construcción Si es necesario, el sistema de

construc
ción debe analizar el programa en construcción, identificar los componentes
dependientes y generar automáticamente una rutina de construcción (llamado algunas
veces archivo de configuración). El sistema debe soportar también la creación
manual
y la edición de rutinas de construcción.

2. Integración del sistema de gestión de versiones El sistema de construcción debe

sacar las versiones de componentes requeridas del sistema de gestión de versiones.

3. Recompilación mínima El sistema de construcción debe establecer qué código

fuente necesita volver a compilarse y establecer las compilaciones si así se
requiere.

4. Creación de sistema ejecutable El sistema de construcción debe vincular los

archivos
de código de objeto compilado entre sí y con otros archivos requeridos, como las
librerías
y los archivos de configuración, para crear un sistema ejecutable.

5. Automatización de pruebas Algunos sistemas de construcción pueden efectuar

pruebas automatizadas utilizando herramientas de automatización de pruebas como
JUnit. Éstas comprueban que la construcción no se haya “roto” por los cambios.

6. Informes El sistema de construcción debe ofrecer informes sobre el éxito o

fracaso
de la construcción y las pruebas que se efectuaron.

7. Generación de documentación El sistema de construcción puede generar notas

referentes a las páginas de ayuda de la construcción y del sistema.

Al comparar las firmas en los archivos

de código fuente y objeto, es posible decidir si el componente del código fuente se
usó
para generar el componente de código objeto.
Hay dos tipos de firmas que pueden usarse:

1. Modificación de marca de tiempo (timestamp) La firma en el archivo del código

fuente es la fecha y hora de cuándo éste se modificó.

2. Sumas de verificación (checksums) de código fuente La firma en el archivo del

código fuente es una suma de verificación calculada a partir de datos en el
archivo.

Los pasos de la integración

continua son:

1. Saque la línea principal del sistema de gestión de versiones hacia el espacio de

trabajo
privado del desarrollador.

2. Construya el sistema y efectúe pruebas automatizadas para garantizar que el

sistema
construido pasa todas las pruebas. Si no lo hace, la construcción se descompone y
hay que informar a quienquiera que ingrese al último sistema línea base (baseline).
Ellos son responsables de reparar el problema.

3. Realice los cambios a los componentes del sistema.

4. Construya el sistema en el espacio de trabajo privado y vuelva a efectuar las

pruebas
del sistema. Si las pruebas fallan, continúe la edición.

5. Una vez que el sistema pasa sus pruebas, ingréselo en el sistema de

construcción,
pero no confirme como una línea base nueva del sistema

6. Construya el sistema en el servidor de construcción y efectúe las pruebas.

Necesita
hacer esto en caso de que otros hayan modificado componentes luego de que usted
los sacó del sistema. Si éste es el caso, saque el componente que falló y edítelo
de
modo que las pruebas pasen en su espacio de trabajo privado.

7. Si el sistema pasa sus pruebas en el sistema de construcción, confirme entonces

los
cambios que hizo como una nueva línea base en la línea principal del sistema.

Sin embargo, aunque la integración continua es una buena idea, no siempre es

posible implementar este enfoque a la construcción del sistema. Las razones para
esto son:

1. Si el sistema es muy grande, puede tardar mucho tiempo construir y probar. Por
lo
tanto, no es práctico construir muchas veces al día dicho sistema.

2. Si la plataforma de desarrollo es diferente de la plataforma objetivo, tal vez

no sea
posible efectuar pruebas del sistema en el espacio de trabajo privado. Puede haber
diferencias en el hardware, el sistema operativo o el software instalado. Por
consiguiente,
se requiere más tiempo para probar el sistema.

GESTIÓN DE ENTREGAS DE SOFTWARE (RELEASE)

Una entrega (release) de sistema es una versión de un sistema de software que se

distribuye
a los clientes

Tipos de entregas:

1. Release mayor: Entrega funcionalidades significativas.

2. Release menor: Repara bugs y corrige problemas.

Una entrega de sistema no sólo es el código ejecutable del sistema; ésta también
puede
incluir:

1. Archivos de configuración
2. Archivos de datos (mensajes de error)
3. Programa de instalación
4. Documentación electrónica
5. Empaquetado y publicidad

CAPÍTULO 26: MEJORA DE PROCESOS

En la actualidad existe una constante demanda de la industria por un mejor y más

barato software, que debe entregarse en plazos caa vez más cortos. Numerosas
compañias han dirigido la atención hacia la mejora de procesos de software para
aumentar la calidad, reducir costos o acelerar los procesos de desarrollo.

Enfoques para mejora y cambio de procesos:

1. Enfoque de madurez de procesos: Orientado a mejorar proceso y gestión de

proyecto, introducir buenas prácticas en la organización. Mejorar la calidad del
producto y la previsibilidad del proceso. Se basa en el desarrollo orientado en un
plan.

2. Enfoque ágil: Orientado a desarrollo iterativo, reducción de sobrecargas en el

proceso de software. Entrega rápida de funcionalidad, capacidad de respuesta ante
los cambiantes requerimientos del cliente.

Existe una relación proceso/producto, y puede relacionarse la cantidad de defectos

con el proceso a fin de mejorarlo.

Si el equipo tiene un alto nivel de habilidad y experiencia, es

probable que la calidad del producto sea alta, independientemente del proceso
utilizado.
Si el equipo carece de experiencia y habilidad, un buen proceso puede limitar el
daño,
pero, en sí mismo, no llevará a un software de alta calidad.

PROCESO DE MEJORA DE PROCESOS

Proceso de software: Secuencia de actividades que, cuando se ejecuta, conduce a la

producción de un sistema de software. Algunos procesos genéricos son el modelo en
cascada y desarrollo basado en reutilización.

Es imposible hacer mejoras de proceso que optimicen simultáneamente todos los

atributos de proceso. Por ejemplo, si su meta es tener un proceso de desarrollo
rápido,
entonces tal vez haya que reducir la visibilidad del proceso. (documentación)

Si quiere hacer un proceso más mantenible, hay que adoptar procedimientos y

herramientas que reflejen la amplia práctica de la organización y que se usen en
diferentes partes de la compañía

El proceso de mejora es ciclico, con tres subprocesos:

1. Medición del proceso: Medir atributos del proyecto/producto actual. Elaborar

medidas de acuerdo a los objetivos de la organización.

2. Análisis del proceso: Se valora el proceso actual, identificar debilidades y

cuellos de botella, elaborar mapas de procesos, se debe buscar describir la rapized
y robustez.

3. Cambio del proceso: Cambios al proceso son propuestas para atacar algunas de las
debilidades identificadas. Los cambios se introducen y el cicle vuelve a comenzar.

MEDICIÓN DEL PROCESO:

Las mediciones del proceso son datos cuantitativos acerca del proceso de software,
como
el tiempo que tarda en realizarse cierta actividad del proceso

Pueden recopilarse tres tipos de métricas de proceso:

1. Tiempo que tarda en completarse un proceso particular

2. Recursos requeridos para un proceso particular
3. Número de ocurrencias de un evento particular

El paradigma GQM (Goal-Question-Metric) se usa en la mejora de procesos para ayudar

a responder tres preguntas fundamentales:

1. ¿Por qué se introduce la mejora de procesos?

2. ¿Qué información se necesita para ayudar a identificar y valorar las mejoras?
3. ¿Qué mediciones de proceso y producto se requieren para obtener esta
información?

Abstraciones de GQM:

1. Metas: Objetivo que la organización pretende lograr.

2. Preguntas: Mejoras de las metas, se identifican áreas específicas de
incertidumbre relacionadas con las metas.
3. Métricas: Mediciones que deben recopilarse para ayudar a responder las preguntas
y confirmar si las mejoras del proceso lograron o no las metas deseadas.

ANÁLISIS DEL PROCESO

Es el estudio de los proceso para ayudar a entender sus características clave y

cómo las personas implicadas realizan en la práctica dichos procesos.

Objetivos del añalisis del proceso:

1. Comprender las actividades implicadas en el proceso y las relaciones entre

dichas
actividades.

2. Entender las relaciones entre las actividades del proceso y las mediciones
realizadas.

3. Relacionar el proceso o procesos específicos analizados con procesos comparables

en otras partes de la organización, o idealizar procesos del mismo tipo

Técnicas usadas más comúnmente:

1. Cuestionarios y entrevistas: Sesgo, piramides, etc.

2. Estudios etnográficos: Se observa a los participantes en el proceso mientras

trabajan.

EXCEPCIONES DE PROCESO

Los ejemplos de tipos de excepción que debe enfrentar un líder de proyecto

incluyen:

• Muchas personas clave se enferman al mismo tiempo, justo antes de una revisión
crítica del proyecto;

• Una violación grave en la seguridad de la computadora, lo que significa que todas

las
comunicaciones externas están fuera de acción durante varios días;

• Una reorganización de la compañía, lo que significa que los administradores

tienen
que pasar buena parte de su tiempo trabajando en asuntos de la organización y no en
la
gestión del proyecto;

• Una petición no prevista de escribir una propuesta para un nuevo proyecto, lo

cual
significa que el esfuerzo debe transferirse del proyecto actual a la elaboración de
una
propuesta.

CAMBIOS EN LOS PROCESOS

El cambio al proceso implica hacer modificaciones al proceso existente. Como se

sugirió,
esto incluye introducir nuevas prácticas, métodos o herramientas; cambiar el orden
de las actividades del proceso; introducir o eliminar entregables del proceso;
mejorar las comunicaciones, o introducir nuevos roles y responsabilidades.

Etapas clave en el proceso de cambios al proceso:

[Link]ón de mejoras
2. Priorización de mejoras
3. Introducción de cambios a los procesos
4. Capacitación de proceso
5. Afinación del cambio.

Dificultades en el proceso de cambio:

1. Resistencia al cambio
2. Persistencia del cambio (regresar al proceso anterior después de un tiempo)

EL MARCO DE TRABAJO PARA LA MEJORA DE PROCESOS CMMI

CMM: Software Capability Maturity Model

CMMI: Modelo capacidad integrado

Componentes del CMMI:

1. Conjunto de áreas de proceso que se relacionan con las actividades de proceso

del software.

2. Algunas metas, las cuales son descripciones abstractas de un estado deseable que
debe lograr una organización.

3. Conjunto de buenas prácticas, las cuales son descripciones de formas para lograr
una meta.

Nivel de madurez de un área de proceso:

1. Incompleto
2. Realizado
3. Gestionado
4. Definido
5. Gestionado cuantitativamente
6. Optimizado

El nivel de gestión tiene las áreas:

1. Gestión de requerimientos
2. Planeación de proyecto
3. Monitorización y control del proyecto
4. Gestión de acuerdos con el proveedor
5. Medición y análisis
6. Aseguramiento de calidad de proceso y producto
7. Administración de la configuración