Miw. Vgiw. 3. Software

Visin General de la
Ingeniera Web.
3. Software
Luis Fernndez Muoz
https://www.linkedin.com/in/luisfernandezmunyoz
setillofm@gmail.com
http://blogs.upm.es/garabatossoftware
miw.etsisi.upm.es https://twitter.com/garabatSoftware
3. Software 2
INDICE
1. Naturaleza del Software
2. Fundamentos del Software
3. Economa del Software
4. Crisis del Software
5. Complejidad del Software
6. Disciplinas del Software
7. Calidad del Software
8. Metodologas de Desarrollo del Software
3. Software 3
ndice
3.1. Naturaleza del Software

1. Definicin de Software
2. Definicin de Sistema Complejos
3. Atributos de Sistemas Complejos
3. Software > 1. Naturaleza del Software 4
ndice
3.1.1. Definicin del Software

Software es la informacin que se suministra el
desarrollador a la computadora para que manipule la
informacin que suministra el usuario [Cox]
Esta informacin la suministra el desarrollador mediante:
Programas en lenguajes de programacin (Java, C/C++, ),
Scripts para la creacin de las tablas de las bases de datos y su
poblacin (SQL) o generacin de pginas dinmicas en aplicaciones
Web (JSP, PHP, ),
Presentaciones en lenguajes de formato para aplicaciones Web
(HTML, CSS, )
Datos de configuracin en diversos formatos (texto libre, XML, )
Multimedia en formatos de imagen, sonido o video para iconos o
pantallas de presentacin (*.png, *.waw, *.mpeg, )

ndice
3.1.2. Definicin de Sistemas Complejos

Un Sistema es un conjunto de componentes interactuando o
interdependientes formando un todo integrado. Cada
sistema est delimitado por sus lmites espacio/temporales e
influenciado por su entorno, descrito por su estructura y
propsito y expresado en su funcionamiento
Un Sistema Complejo es aquel cuya complejida excede la
capacidad intelectual humana.
ndice
3.1.3. Atributos de Sistemas Complejos

Atributos:
Estructura jerrquica
Elementos primitivos
relativos
Separacin de asuntos
Patrones comunes
Formas intermedias
estables
ndice

Estructura jerrquica. Frecuentemente, la complejidad
adquiere una forma jerrquica donde el sistema complejo
est compuesto de subsistemas interrelacionados que a su
vez tienen sus propios subsistemas y as hasta que se alcanza
algn elemento del ms bajo nivel. No solo son sistemas
complejos jerrquicos sino que los niveles de su jerarqua
representan los diferentes niveles de abstraccin cada uno
construido sobre otro y cada uno comprensible por s mismo.
En cada nivel de abstraccin, encontramos una coleccin de
elementos que colaboran para proveer servicios a niveles
superiores
ndice

Elementos primitivos relativos. La eleccin de qu
componentes en un sistema son primitivos es relativamente
arbritraria y mayormente est a discreccin del observador
del sistema
Separacin de asuntos. Las intra-conexiones de
componentes son ms fuertes que las inter-conexiones de
componentes. Este hecho tiene el efecto de separar los
componentes con dinmica de alta frecuencia (involucrando
la interaccin entre componentes) de los de dinmica de baja
frecuencia. En trminos sencillos, hay una clara separacin
de asuntos entre las partes de diferentes niveles de
abstraccin
ndice

Patrones comunes. Los sistemas jerrquicos se componen
generalmente de slo unos pocos tipos diferentes de
subsistemas en varias combinaciones y rdenes. Nos
encontramos con una gran similitud en la forma de
mecanismos compartidos unificando esta vasta jerarqua
Formas intermedias estables. Un sistema complejo que
funciona invariablemente se encuentra que ha evolucionado
a partir de un sistema sencillo que funcion. Un sistema
complejo diseado desde cero no funciona y no puede ser
remendado para hacer que funcione. Usted tiene que
comenzar de nuevo, a partir de un sistema sencillo de trabajo
3. software 10
ndice
3.2. Fundamentos del Software

1. Introduccin
2. Abstraccin
3. Encapsulacin
4. Modularidad
5. Jerarqua
6. Conclusin
3. Software > 2. Fundamentos del Software 11
ndice
3.2.1. Introduccin
La observacin general es que el principal enemigo de la fiabilidad, y tal
vez de la calidad del software en general, es la complejidad. [Meyer]
Ley de Conservacin de la Complejidad dice que cada aplicacin
tiene una cantidad de complejidad que no puede ser eliminada u
oculatada [Tesler, 87].
Cuanto ms complejo sea un sistema, ms abierto est al colapso
total. Gran parte de la complejidad que se tiene que dominar es la
complejidad arbitraria. [Booch]
Como afirma Descartes, "El descubrimiento de un orden no es tarea
fcil. . . . sin embargo, una vez que el orden ha sido descubierto no hay
dificultad alguna en reconocerlo".
La historia del software disfruta de cuatro mecanismos que
facilitan enormemente nuestra comprensin de sistemas
complejos:
Abstraccin
Encapsulacin
Modularidad
Jerarqua
ndice
3.2.2. Abstraccin
Definiciones:
La abstraccin es "una descripcin simplificada, o especificacin, de un
sistema que hace hincapi en algunos de los detalles o propiedades mientras
que suprime otros del sistema. Una buena abstraccin es la que hace hincapi
en los detalles que son importantes para el lector o usuario y suprime detalles
que son, al menos por ahora, de distraccin [Shaw]
La abstraccin surge de un reconocimiento de similitudes entre ciertos
objetos, situaciones o procesos en el mundo real, y la decisin de concentrarse
en estas similitudes e ignorar por el momento, las diferencias [Dahl,
Dijkstra y Hoare]
La abstraccin es proceso mental de extraccin de las caractersticas
esenciales de algo, ignorando los detalles superfluos [Booch]
Para hacer frente a la complejidad, nos abstraemos de ella!!!

ndice
3.2.2. Abstraccin
Implicaciones:
Una abstraccin denota las caractersticas esenciales de un objeto que lo
distinguen de todos los otros tipos de objetos y por lo tanto proporciona
lmites conceptuales ntidamente definidos, en relacin con la perspectiva
del espectador.
Una abstraccin se centra en la visin exterior de un objeto y sirve para
separar el comportamiento esencial de un objeto de su implantacin
La abstraccin es eminentemente subjetiva, dependiendo del inters del
observador
Nos esforzamos para construir abstracciones de las entidades porque son
directamente paralelos al vocabulario del dominio de un determinado
problema.
Ejemplos:
Mundo real: un autobs de un pasajero o un mecnico, un ordenador,,
Software orientado a procesos: factorial, mostrar men, ordenar,
Software orientado a objetos: una fecha, un intervalo, un gestor de
comunicaciones, un coleccin de datos,
ndice
3.2.3. Encapsulacin
Definiciones:
La encapsulacin es proceso por el que se ocultan los detalles del soporte de
las caractersticas esenciales de una abstraccin [Booch]. Hacer notar que
en ninguno de los casos no se trata de ocultar la informacin en s
misma sino de ocultar los detalles del soporte de dicha informacin.
La encapsulacin se logra con mayor frecuencia a travs de
ocultacin de informacin, que es el proceso de ocultar todos los
secretos de un objeto que no contribuyen a sus caractersticas
esenciales.
La encapsulacin proporciona barreras explcitas entre las diferentes
abstracciones y por lo tanto conduce a una clara separacin de
asuntos. El beneficio inmediato ser la posibilidad de cambiar los
soportes de las caractersticas de una abstraccin sin afectar a todos
los elementos que dependan de esas caractersticas porque ni los
conocen, ni los mencionan.
Principio de Encapsulacin: todo aquello que no sea necesario dar a
conocer, no se debe dar a conocer
ndice
3.2.3. Encapsulacin
Implicaciones:
Una vez realizada cierta abstraccin hay que trasladarlas al
lenguaje de programacin. Esto conlleva decidir entre diversas
estructuras de datos (estticas o dinmicas, en memoria principal o
secundaria, etc.) y/o diversos algoritmos (con variables auxiliares o
no? recursivo o iterativo?, etc.), siendo diversas las alternativas que
recogen dichas caractersticas esenciales. Una vez que se selecciona
una implantacin, debe ser tratado como un secreto de la abstraccin
y oculta a la mayora de los clientes. En la prctica, esto significa que
cada clase debe tener dos partes:
La interfaz de una clase capta slo su vista exterior, que abarca
nuestra abstraccin del comportamiento comn a todas las
instancias de la clase. La interfaz de una clase es el nico lugar
donde establecemos todas los suposiciones que un cliente puede
hacer sobre cualquier instancia de la clase
La implementacin de una clase comprende la representacin de
la abstraccin, as como los mecanismos para conseguir el
comportamiento deseado. La implementacin encapsula detalles
sobre los qu ningn cliente puede hacer suposiciones.
ndice
3.2.3. Encapsulacin
Implicaciones:
La abstraccin de un objeto debe preceder a las decisiones acerca de
su implantacin.
Ninguna parte de un sistema complejo debe depender de los detalles
internos de cualquier otra parte. Mientras que la abstraccin ayuda a
las personas a pensar en lo que estn haciendo, la encapsulacin
permite hacer cambios fiables en el programa con un esfuerzo
limitado.
Ejemplos:
Mundo real: un autobs, un ordenador, una universidad,
ndice
3.2.4. Modularidad
Definiciones:
La modularidad es el proceso de descomposicin de un sistema en un
conjunto de piezas poco acoplados y cohesivos [Booch, 96]
El acoplamiento [...] es la medida de fuerza de la asociacin establecida
por una conexin ente un mdulo -elemento- y otro. El acoplamiento
fuerte complica un sistema porque los mdulos son ms difciles de
comprender, cambiar o corregir por s mismos si estn muy
interrelacionados con otros mdulos [Booch, 96]. Por tanto, hay que
minimizar las dependencias entre mdulos
La cohesin mide el grado de conectividad entre los elementos de un solo
mdulo. [Booch, 96] Por tanto, un mdulo cohesivo debe tener
significado propio por s mismo agrupando abstracciones
lgicamente relacionadas
ndice
3.2.4. Modularidad
Implicaciones:
La tcnica de manejar la complejidad ha sido conocida desde la
antigedad: divide et impera (divide y vencers).
Al disear un sistema de software complejo, es esencial para
descomponer en partes ms pequeas y ms pequeas, cada una de
las cuales podemos entonces refinar independientemente. De esta
manera, satisfacemos la restriccin muy real que existe sobre la
capacidad del canal de la cognicin humana: para entender cualquier
nivel dado de un sistema, slo necesitamos comprender algunas
partes (en lugar de todas las partes) a la vez.
Al dividir un programa crean una serie de lmites documentados bien
definidos dentro del programa, los cuales son de gran valor en la
comprensin del programa
la descomposicin inteligente se dirige directamente a la complejidad
inherente del software al obligar a una divisin del espacio de estados de un
sistema [Parnas]
ndice
3.2.4. Modularidad
Implicaciones:
Debera ser posible cambiar la implementacin de otros mdulos sin
el conocimiento de la aplicacin de otros mdulos y sin afectar el
comportamiento de los otros mdulos
El bajo acoplamiento de un modulo se basa en la abstraccin que
limita su interfaz a lo esencial y en la encapsulacin que oculta todos
los detalles necesarios para su implantacin pero innecesarios para
otros mdulos que se relacionen con ste
Ejempos:
Mundo real: un autobs, un ordenador, una universidad,
ndice
3.2.5. Jerarqua
Definiciones:
Jerarqua es una clasificacin u ordenamiento de las abstracciones
[Booch]
La jerarquizacin es el proceso de estructuracin por el que se
produce una organizacin de un conjunto de elementos en grados o
niveles de responsabilidad, de clasificacin o de composicin,
entre otros
Univesidad Profesores
Facultades Rectorado Titulares Asociados
Departamentos Direccin Interinos Funcionarios

ndice
3.2.5. Jerarqua
Implicacines:
La abstraccin es una buena cosa pero en todos los casos, excepto las
aplicaciones ms triviales, podemos encontrar muchas ms
abstracciones diferentes de lo que podemos comprender a la vez. La
encapsulacin ayuda a gestionar esta complejidad al ocultar el
interior de la vista de nuestras abstracciones. La modularidad ayuda
tambin, por que nos da una manera de agrupar abstracciones
relacionados lgicamente. An as, esto no es suficiente. Un conjunto
de abstracciones a menudo forma una jerarqua, y mediante la
identificacin de estas jerarquas en nuestro diseo se simplifica
enormemente nuestra comprensin del problema.
La identificacin de las jerarquas dentro de un sistema de software
complejo a menudo no es fcil. Una vez que se exponen esas
jerarquas, la estructura de un sistema complejo se vuelve muy simple
y obtenemos la comprensin de la misma.
ndice
3.2.5. Jerarqua
Implicacines:
Si no revelamos la estructura de clases de un sistema, tendramos que
multiplicar nuestro conocimiento sobre las propiedades de cada parte
individual. Con la inclusin de la estructura de clases, captamos estas
propiedades comunes en un solo lugar.
La estructura de clases y la estructura de objetos no son
completamente independientes; ms bien, cada objeto en la
estructura de objetos representa una instancia especfica de una clase.
Por lo general hay muchos ms objetos que clases de objetos dentro
de un sistema complejo. Al mostrar la "parte de", as como la
jerarqua "es un", exponemos de forma explcita la redundancia del
sistema considerado.
Existen dos jerarquas ortogonales del sistema: la estructura de clases
y la estructura de objetos. Cada jerarqua est en capas, con clases
ms abstractas y objetos construidos sobre otros ms primitivos. La
clase u objeto que se elija como primitivo est en relacin con el
problema en cuestin. Mirando dentro de cualquier nivel dado revela
otro nivel de complejidad. Especialmente entre las partes de la
estructura del objeto, existe una estrecha colaboracin entre los
objetos de ese mismo nivel de abstraccin.
ndice
3.2.5. Jerarqua
Implicacines:
La mayora de los sistemas interesantes no incorporan una nica
jerarqua; en cambio, nos encontramos con que muchas jerarquas
diferentes suelen estar presentes dentro del mismo sistema complejo.
En nuestra experiencia, hemos encontrado que es esencial para ver un
sistema desde ambas perspectivas, estudiando su jerarqua "es un"
(clasificacin), as como su jerarqua "parte de (composicin)
Nuestra experiencia es que los sistemas de software complejos ms exitosos
son aquellos cuyos diseos incluyen explcitamente las estructuras de clases
y objetos bien diseadas y encarnan los cinco atributos de sistemas complejos
descritos en la seccin anterior. [] Muy raramente nos encontramos con
sistemas de software que se entregan a tiempo, que estn dentro del
presupuesto y que cumplen con sus requisitos, a menos que estn diseados
con estos factores en mente [Booch]
ndice
3.2.6. Conclusin
Software es un conjunto de clases/mdulos relacionndose
por herencia, composicin, o interdependientes formando
una aplicacin. Cada aplicacin est delimitada por su
entorno tecnologco-comercial, descrito por su arquitectura
del software y requisitos y expresado en su ejecucin
Software de una aplicacin media (~100.000 lneas de
cdigo) tiene una complejida excede la capacidad intelectual
humana
Software es un sistema complejo con:
Estructura jerrquica gracias a sus jerarquas de herencia,
composicin,
Elementos primitivos relativos gracias a sus tipos primitivos
dependiendo del lenguaje (enteros, cadena de caracteres?, fechas?, )
y los definidos por el usuario
Separacin de asuntos gracias a la encapsulacin y modularidad
Patrones comunes gracias al paso de mensajes con argumentos
Formas intermedias estables gracias a las metodologas iterativas
3. Software 25
ndice
3.3. Economa del Software

1. Introduccin
2. Variable mbito
3. Variable Tiempo
4. Variable Coste
5. Variable Calidad
6. Variables correlacionadas
3. Software > 3. Economa del Software 26
ndice
3.3.1. Introduccin
Cuatro variables: mbito
Coste,
Tiempo
mbito (funcionalidad/
requisitos) y
Calidad
Calidad Coste Tiempo
No hay una relacin sencilla entre las cuatro variables. Por

ejemplo, no puedes obtener software ms rpido, gastando
ms dinero:
nueve mujeres no pueden tener un beb en un mes
dieciocho mujeres an no pueden tener un beb en un mes
[Brooks]
ndice
3.3.2. Variable mbito

Es la ms importante a tener en cuenta
Menos mbito hace posible entregar mejor calidad (mientras
el problema del cliente est todava resuelto). Tambin
permite entregar ms rpido y barato.
ndice

Una de las principales cuestiones acerca del mbito es que es
una variable que vara mucho.
Los requisitos nunca estn claros al principio. Los clientes no pueden
decirnos exactamente lo que ellos quieren. El desarrollo de una pieza
de software cambia sus propios requisitos. Tan pronto como el cliente
ve la primera versin, ellos aprenden lo que quieren para la segunda
versin o lo que realmente queran en la primera. Y esto es un
aprendizaje valioso, porque no hay posibilidades de especulacin.
Este aprendizaje solamente puede venir de la experiencia. Pero los
clientes no pueden estar solos. Ellos necesitan gente que pueda
programar, no como guas, sino como compaeros.
Los programadores y el personal del negocio no tienen ms que una
idea vaga sobre lo que tiene valor en el software que se est
desarrollando. Una de las decisiones ms importantes en la gestin
del proyecto es la eliminacin del mbito. Si se gestiona activamente
el mbito, se puede proporcionar a los directores de proyecto y
clientes control sobre el coste, calidad y tiempo.
ndice

Si el tiempo est limitado a la fecha de lanzamiento de
una versin, hay siempre algo que podemos diferir a la
siguiente versin.
No intentando hacer demasiado, mantenemos nuestra capacidad de
producir la calidad requerida en un tiempo determinado.
Si dejas fuera importante funcionalidad al final de cada ciclo de
versin, el cliente quedar disgustado. Para evitar esto, se utilizan
dos estrategias:
Consigue mucha prctica haciendo estimaciones y realimentando
los resultados reales. Mejores estimaciones reducen la
probabilidad de que tengas que dejar fuera funcionalidad
Implementa en primer lugar los requisitos ms importantes del
cliente, de tal manera que si se deja despus alguna
funcionalidad, es menos importante que la funcionalidad que ya
est incorporada al sistema
ndice
3.3.3. Variable Tiempo

Las restricciones de controlar proyectos controlando el
tiempo, generalmente vienen de fuera, de las manos del
cliente
Disponer de ms tiempo para la entrega puede mejorar
la calidad e incrementar el mbito.
Ya que la realimentacin desde los sistema en produccin es de
mayor calidad que cualquier otra clase de realimentacin, dar a un
proyecto demasiado tiempo ser perjudicial.
Si damos a un proyecto poco tiempo, la calidad sufre,
con el mbito.
Si la mayora de los proyectos de tu organizacin son obsesivamente cortos,
proyectos conducidos por el calendario, hay algo muy, muy malo. Cambios
radicales en la organizacin del proceso de desarrollo software son necesarios,
antes de que la compaa o su gente se arruine [Booch, Object Solutions]
ndice
3.3.4. Variable Coste

Mucho dinero puede engrasar la maquinaria un poco, pero
demasiado dinero pronto crea ms problemas que resuelve.
Mayores costes a menudo alimentan objetivos tangenciales,
como estatus o prestigio (tengo un proyecto de 150
personas respira profundamente)
Por otra parte, si damos a un proyecto muy poco dinero, no
seremos capaces de resolver el problema del negocio del
cliente
Dentro del rango de inversin que pueda sensatamente
hacerse, gastando ms dinero puedes aumentar el mbito, o
puedes intentar de forma ms deliberada aumentar la
calidad, o puedes (hasta cierto punto) reducir el tiempo de
salida al mercado. Tambin puede reducir las desavenencias:
mquinas ms rpidas, ms especialistas tcnicos, mejores
oficinas.
ndice
3.3.4. Variable Coste

No puedes gastar solo en calidad o mbito. De hecho, al
comienzo de un proyecto, no puedes gastar mucho. La
inversin tiene que comenzar siendo pequea y crecer con el
tiempo. Despus de un tiempo, se puede de forma
productiva gastar ms y ms dinero.
Todas las restricciones sobre el coste pueden volver locos a
los directores de proyecto. Especialmente si estn sujetos a
un proceso de presupuesto anual, ellos estn tan
acostumbrados a considerarlo todo desde la perspectiva del
coste y cometern grandes errores al ignorar las restricciones
sobre cunto control te proporciona el coste
ndice
3.3.5. Variable Calidad

Hay una extraa relacin entre la calidad interna (que miden
los programadores) y externa (que mide el cliente). Sacrificar
temporalmente la calidad interna para reducir el tiempo de
salida al mercado del producto, con la esperanza que la
calidad externa no se vea muy daada es tentador a corto
plazo. Y puedes con frecuencia hacerlo impunemente
generando una confusin en cuestin de semanas o meses.
Al fin y al cabo, los problemas de calidad interna te alcanzan
a ti y hacen que tu software sea prohibitivamente caro de
mantener.
A menudo, al insistir en la mejora de la calidad puedes hacer
que el proyecto est listo en menos tiempo, o puedes
conseguir hacer ms en un una cantidad de tiempo dada. Se
trabaja mejor si no se desmoraliza al producir software
basura.
ndice
3.3.6. Variables correlacionadas

La forma de hacer en este modelo del juego del desarrollo del
software es que las fuerzas externas (clientes, directores de
proyecto) eligen los valores de tres variables cualquiera. El equipo
de desarrollo determina el valor resultante de la cuarta variable
Algunos directores de proyecto y clientes creen que pueden

escoger el valor de las cuatro variables. Cuando esto suceda, la
calidad siempre desaparecer, ya que nadie hace bien el trabajo
cuando est sujeto a una fuerte presin. Tambin, probablemente,
el tiempo estar fuera de control
[Beck, 1999]
3. Software 35
ndice
3.4. Crisis del Software

1. Justificacin de la Crisis del Software
2. Estadsticas de Proyectos
3. Causas de la Crisis del Software
3. Software > 4. Crisis del Software 36
ndice
3.4.1. Justificacin de la Crisis del Software

Nuestra incapacidad para dominar la complejidad
desprende los resultados de los proyectos software que
llegan tarde, por encima del presupuesto y deficientes en los
requisitos establecidos.
La complejidad del software es una propiedad esencial, no
un accidente. Por esencial queremos decir que podemos dominar
esta complejidad, pero nunca podemos hacer que se vaya. [...] A
menudo llamamos esta condicin la crisis del software, pero,
francamente, una enfermedad que se ha llevado a los largo de este
tiempo debe ser llamado normalidad". [Brooks]
ndice
3.4.2. Estadsticas de Proyectos

Estadsticas de Standish Group sobre 50.000 proyectos:
Incluyendo accidentes que conllevaron a la muerte de tres personas en la mquina de

radioterapia Therac-25 que emiti una sobredosis masiva de radiacin u otros con
prdidas multimillonarias
ndice
3.4.3. Causas de la Crisis del Software

1. Falta del involucracin del usuario 12.8%
2. Requerimientos y especificaciones poco claras 12.3%
3. Cambio de requerimientos y especificaciones 11.8%
4. Poco apoyo de las gerencias involucradas 7.5%
5. Tecnologa deficiente 7.0%
6. Falta de recursos 6.4%
7. Expectativas poco realistas 5.9%
8. Objetivos poco claros 5.3%
9. Tiempos poco realistas 4.3%
10. Nuevas tecnologas 3.7%
11. Otros 23.0%
3. Software 39
ndice
3.5. Complejidad del Software

1. La complejidad del dominio
del problema
2. Las limitaciones de la
capacidad humana
3. La posible flexibilidad a
travs del software
4. El comportamiento de los
sistemas discretos
5. La dificultad de gestionar el
proceso de desarrollo
3. Software > 5. Complejidad del Software 40
ndice
3.5.1. La complejidad del dominio del problema

Los problemas que tratamos de resolver en el software a
menudo implican elementos de complejidad ineludible, en
las que encontramos una gran variedad requisitos que
compiten, incluso contradictorios. Una complicacin
adicional es que los requisitos de un sistema de software a
menudo cambian durante su desarrollo:
Ley del Cambio Continuo:

Un programa que se usa en un mbito del mundo real, necesariamente debe cambiar
o convertirse cada vez en menos til
Ley de la Complejidad Creciente:
Debido a que los programas cambian por evolucin, su estructura se convierte en
ms compleja a menos que se hagan esfuerzos activos para evitar este fenmeno
[Lehman y Belady]
ndice
3.5.2. Las limitaciones de la capacidad humana

Experimentos realizados por los psiclogos, tales como las
de Miller, sugieren que el nmero mximo de piezas de
informacin que un individuo puede comprender al mismo
tiempo es del orden de siete, ms o menos dos. Esta
capacidad de canal parece estar relacionada con la capacidad
de la memoria a corto plazo.
Simon, adems, seala que la velocidad de procesamiento es
un factor limitante: la mente toma unos cinco segundos para
aceptar una nueva pieza de informacin.
ndice
3.5.3. La posible flexibilidad a travs del software

Mientras que la industria de la construccin tiene cdigos y
estndares para la calidad de las materias primas de
construccin uniforme, existen pocos de esos estndares en
la industria del software. Como resultado, el desarrollo de
software sigue siendo una empresa de trabajo intensivo.
ndice
3.5.4. El comportamiento de los sistemas discretos

Dentro de una aplicacin grande, puede haber cientos o
incluso miles de variables, as como ms de un hilo de
control. Toda la coleccin de estas variables, sus valores
actuales y su direccin actual y la pila de llamadas de cada
proceso dentro del sistema constituyen el estado actual de la
aplicacin.
Por desgracia, es absolutamente imposible para una sola
persona realizar un seguimiento de todos estos detalles a la
vez.
Este es el problema de la caracterizacin del
comportamiento de los sistemas discretos
ndice
3.5.5. La dificultad de gestionar el proceso de desarrollo

La gran cantidad de requisitos de un sistema a veces es
inevitable y nos obliga a escribir una gran cantidad de
software nuevo o volver a utilizar el software existente en
formas novedosas.
Hace tan slo unas dcadas, los programas en lenguaje ensamblador
de slo unos pocos miles de lneas de cdigo subrayaron los lmites
de nuestras capacidades de ingeniera de software.
Hoy en da, no es raro encontrar sistemas entregados cuyo tamao se
mide en cientos de miles o incluso millones de lneas de cdigo (y
todo eso en un lenguaje de programacin de alto nivel).
3. Software 45
ndice
3.6. Disciplinas del Software

1. Introduccin
2. Disciplina de Requisitos
3. Disciplina de Anlisis
4. Disciplina de Diseo
5. Disciplina de Programacin
6. Disciplina de Pruebas
7. Ecosistema de Desarrollo
8. Conclusiones
3. Software > 6. Disciplinas del Software 46
ndice
3.6.1. Introduccin
Ingeniera de software es la aplicacin prctica del
conocimiento cientfico al diseo y construccin de
programas de computadora y a la documentacin asociada
requerida para desarrollar, operar y mantenerlos. Se conoce
tambin como desarrollo de software o produccin de
software [Bohem, 1976]
El software es sagrado
[Booch]
[ y requiere de un ritual]
ndice
3.6.2. Disciplina de Requisitos

La disciplina de requisitos es el flujo de trabajo,
incluyendo actividades, trabajadores y documentos,
cuyo propsito principal es dirigir el desarrollo hacia el
sistema correcto al describir los requisitos del sistema
as que pueda alcanzarse un acuerdo entre los clientes,
usuarios y desarrolladores sobre lo que el sistema
debera hacer:
Establecer y mantener el acuerdo entre los clientes y otros
interesados (stakecholders gerencia, marketing, usuarios, )
sobre lo que el sistema debera hacer
Proveer a los desarrolladores del sistema con una mejor
comprensin de los requisitos del sistema
Definir los lmites del sistema
Proveer las bases para planificar los aspectos tcnicos del
desarrollo
Proveer las bases para estimar los costes y tiempos para
desarrollar el sistema
ndice
3.6.3. Disciplina de Anlisis

La disciplina de anlisis es el flujo de trabajo, incluyendo
trabajadores, actividades y documentos, cuyo principal
objetivo es analizar los requisitos a travs de su
refinamiento y estructura para realizar una compresin
ms precisa de los requisitos, una descripcin de los
requisitos que es fcil de mantener y ayuda a estructurar el
sistema:
Dar una especificacin ms precisa de los requisitos obtenidos en la
captura de requisitos
Describir usando el lenguaje de los desarrolladores y poder
introducir ms formalismo y ser utilizado para razonar sobre el
funcionamiento interno del sistema
Estructurar los requisitos de manera que facilite su comprensin,
cambindolos y, en general, mantenerlos
Acercase al diseo, aunque sea un modelo en s mismo, y es por tanto
un elemento esencial cuando el sistema est conformado en diseo e
implementacin
ndice

Comparativa entre requisitos y anlisis:
Requisitos: Anlisis:
Descrito usando el Descrito usando el lenguaje
lenguaje del cliente de los desarrolladores
Visin externa del sistema Visin interna del sistema
Estructurado por Estructurado por clases
requisitos, da estructura a estereotipadas y paquetes,
la vista externa da estructura a la vista
Usado principalmente interna
como contrato entre los Usado principalmente por
clientes y los desarrolladores para
desarrolladores sobre lo comprender qu forma
que el sistema debera debera tener el sistema (p.ej.
hacer diseo e implementacin)
ndice

Comparativa entre requisitos y anlisis:
Requisitos: Anlisis:
Contiene muchas No debera contener
redundancia, redundancias,
inconsistencias, .. entre inconsistencias, entre los
los requisitos requisitos
Captura la funcionalidad Esboza cmo realizar la
del sistema, incluyendo funcionalidad en el sistema,
funcionalidad incluyendo la
arquitectnica funcionalidad
significativa arquitectnica significativa;
funciona como un primer
corte del diseo
ndice
3.6.4. Disciplina de Diseo

La disciplina de diseo es el flujo de trabajo, incluyendo
actividades, trabajadores y documentos, cuyo principal
propsito es desarrollar enfocados en los requisitos no
funcionales y en el dominio de la solucin para preparar
para la implementacin y pruebas del sistema:
Adquirir una comprensin profunda sobre los aspectos de los
requisitos no funcionales y limitaciones relacionadas con:
los lenguajes de programacin,
la reutilizacin de componentes,
sistemas operativos,
tecnologas de distribucin y concurrencia,
tecnologas de bases de datos,
tecnologas de interfaz de usuario,
tecnologas de gestin de transacciones,
y as sucesivamente
ndice

Crear una entrada apropiada como punto de partida para las
disciplinas posteriores mediante la captura de los requisitos
correspondientes a los distintos subsistemas, interfaces y clases
Capacitar para la descomposicin del trabajo de implementacin en
piezas ms manejables gestionados por diferentes equipos de
desarrollo, posiblemente al mismo tiempo
Captura las interfaces principales entre los subsistemas del ciclo de
vida del software. Esto es til cuando razonamos sobre la
arquitectura y cuando usamos las interfaces como instrumentos de
sincronizacin entre los diferentes equipos de desarrollo
Capacitar para visualizar y razonar sobre el diseo utilizando una
notacin comn
Crear una abstraccin sin fisuras de la implementacin del sistema,
en el sentido de que la aplicacin es un refinamiento sencillo del
diseo mediante la cumplimentacin de la "carne", pero sin cambiar
la estructura. Esto permite el uso de tcnicas como la generacin de
cdigo e ingeniera directa e inversa entre el diseo y la
implementacin
ndice

Comparativa entre anlisis y diseo:
Anlisis: Diseo:
Modelo conceptual Modelo fsico porque es un
porque es una abstraccin esbozo de la
del sistema y evita implementacin
cuestiones de Ms formal
implementacin No es genrico sino
Menos formal especfico para una
Diseo genrico, aplicable implementacin
a varios diseos concretos Cualquier nmero de
Tres estereotipos estereotipos fsicos en las
conceptuales en las clases: clases, dependiendo del
modelo, vista, controlador lenguaje de
implementacin
ndice

Anlisis: Diseo:
Menos costoso para el Ms costoso para el
desarrollo (1:5 frente al desarrollo (5:1 frente al
diseo) anlisis)
Pocas capas arquitectnicas Muchas capas
Puede no ser mantenido a arquitectnicas
travs de todo el ciclo de Debera ser mantenido a
vida del software travs de todo el ciclo de
Principalmente creado en vida del software
trabajo de campo, talleres y Principalmente creado por
similares programacin visual
(ingeniera directa e
inversa)
ndice

Anlisis: Diseo:
Define la estructura que Dar forma al sistema
es la entrada esencial mientras intenta preservar
para dar forma al la estructura definida por el
sistema, incluyendo la modelo de anlisis
creacin del modelo de Enfatiza en la solucin
diseo conceptual que cubra los
Enfatiza la investigacin requisitos ms que en su
del problema y sus implementacin
requisitos Hazlo correctamente
Haz lo correcto
ndice
3.6.5. Disciplina de Programacin

La disciplina de implementacin es el flujo de trabajo,
incluyendo actividades, trabajadores y documentacin, cuyo
principal propsito es implementar el sistema en trminos
de componentes, p.ej. cdigo, scripts, ficheros binarios,
cdigo ejecutables:
Definir la organizacin del cdigo en trminos de subsistemas de
implementacin organizados en capas
Implementar las clases y objetos en trminos de componentes
Probar el desarrollo de componentes como unidades
Integrar en un sistema ejecutable el resultado producido por
implementadores individuales o equipos
ndice
3.6.6. Disciplina de Pruebas

La disciplina de pruebas es el flujo de trabajo, incluyendo
actividades, trabajadores y documentacin, cuyo principal
propsito es comprobar el resultado de la implementacin
al probar cada versin, incluyendo internas e intermedias,
y versiones finales del sistema a entregar:
Encontrar y documentar fallos en el producto software: defectos,
problemas,
Avisar a la gestin sobre la calidad del software percibida
Evaluar las asunciones hechas en el diseo y especificacin de
requisitos a travs de demostraciones concretas
Validar que el software trabaja como fue diseado
Validar que los requisitos son implementados apropiadamente
ndice
3.6.7. Ecosistema de Desarrollo

La complejidad del software justifica la necesidad de
herramientas que aceleren su produccin, controlen su
calidad y monitoricen su gestin a lo largo de todas las
disciplinas de la ingeniera del software
El ecosistema es un conjunto de servicios integrados
orientados al desarrollo de software y su objetivo es mejorar
la coordinacin y el trabajo realizado por el equipo de
desarrollo.
Para la disciplina de requisitos se requiere un entorno colaborativo
con editores, historial, autora, respaldos, donde los
especificadores de requisitos (casos de uso / historias de usuario)
puedan escribir y el resto del equipo de desarrollo
(analistas/diseadores, programadores, probadores y desplegadores)
puedan leer dichos requisitos centralizados: Wiki de GitHub
ndice

Para la disciplina de anlisis y diseo se requiere de una herramienta
CASE (Computer Aided Software Engineering) que facilite la edicin de
diagramas de anlisis y diseo (diagramas de casos de uso, clases,
objetos, paquetes, secuencia, colaboracin, estados y actividades,
implementacin y despliegue) junto con su trazabilidad: MagicDraw
Para la disciplina de anlisis y diseo se requiere de una herramienta
de mtricas del software que determine automticamente el grado de
bondad de los componentes de la arquitectura del software:
SonarQube
Para la disciplina de programacin se requiere un entorno de
desarrollo integrado para la edicin, compilacin, ejecucin, del
cdigo en desarrollo en la mquina local: Eclipse
Para la disciplina de programacin se requiere ayudas para el
cumplimiento de las reglas de estilo (formato, identificadores, )
dadas en la arquitectura del software: Eclipse, Checkstyle, PMD,
FindBugs y Sonarqube
ndice

Para la disciplina de programacin se requiere, en el contexto de
metodologas giles, ayudas para automatizar en lo posible la
refactorizacin del cdigo (renombrado de identificadores, nombrar
constantes, mover mtodos, ): Eclipse
Para la disciplina de programacin se requiere un sistema de registro
para gestionar (escritura, destino, avisos, ) los mensajes de trazas,
depuracin, errores, ) durante la ejecucin: Log4j
Para la disciplina de programacin se requiere de un sistema de
control de versiones del repositorio de cdigo comn del proyecto
para facilitar la gestin (actualizaciones, vuelta atrs, mezclas, ) de
la rama de desarrollo, la rama de entregas, la rama de produccin:
GitHub
Para la disciplina de pruebas se requiere un sistema para la gestin
de pruebas que facilite la edicin, ejecucin, evaluacin, de la
pruebas: Junit, Selenium,
ndice

Para la disciplina de pruebas se requiere de un sistema de
integracin continua para comprobar que el cdigo y las pruebas
funcionan tras cualquier cambio: Travis
Para la disciplina de pruebas se requiere un sistema de cobertura de
pruebas que facilite la misin y estrategias de pruebas: SonarQube
Para la disciplina de despliegue se requiere un gestor de proyectos
para la automatizacin, en lo posible, de la construccin de
entregables (compilacin, pruebas, reglas de estilo, empaquetado,
): Maven
Para la disciplina de gestin de proyectos se requiere una
herramienta para gestin de tickets que permitan la asignacin de
tareas con su tiempo estimado y real, finalizacin por parte del
asignado y cierre tras la comprobacin por el emisor de la tarea:
Tickets de GitHub
ndice
3.6.8. Conclusiones
Problemas por la Complejidad Soluciones de la
del Software: Ingeniera del Software:
La complejidad del dominio del
Requisitos
problema
Las limitaciones de la capacidad
humana para el tratamiento de la Anlisis y Diseo
complejidad
La posible flexibilidad a travs del Calidad y Reusabilidad: Mtricas,

software Patrones, Antipatrones, Estilos de
Arquitectura, Frameworks,
Los problemas de la caracterizacin del
comportamiento de los sistemas Pruebas Automticas e Integracin
discretos Continua
La dificultad de gestionar el proceso de Metodologas iterativas pesadas vs

desarrollo ligeras
3. Software 63
ndice
3.7. Calidad del Software

1. Calidad del Software
2. Calidad del Software de Bajo Nivel
3. Calidad del Software de Medio Nivel
4. Calidad del Software de Alto Nivel
5. Mtricas de Calidad del Software
6. Reusabilidad del Software
7. Conclusiones
3. Software > 7. Calidad del Software 64
ndice
3.7.1. Calidad del Software

Factores de la Calidad del Software:
Correccin: Hace lo que se le pide?
Fiabilidad: Lo hace de forma fiable todo el tiempo?
Eficiencia: Qu recursos hardware y software necesito?
Integridad: Puedo controlar su uso?
Usabilidad: Es fcil y cmodo de manejar?
Facilidad de mantenimiento: Puedo localizar los fallos?
Flexibilidad: Puedo aadir nuevas opciones?
Facilidad de prueba: Puedo probar todas las opciones?
Portabilidad: Podr usarlo en otra mquina?
Reusabilidad: Podr utilizar alguna parte del software en otra
aplicacin?
Inter-operatividad: Podr comunicarse con otras aplicaciones o
sistemas informticos?
todos, en mayor o menor medida, dependen del diseo
ndice

El diseo de software orientado a objetos es difcil, y el diseo de
software orientado a objetos reutilizable es an ms difcil. [] Su
diseo debe ser especfico para el problema en cuestin, pero
tambin suficiente para abordar los problemas y las necesidades
futuras en general. Tambin quiere evitar redisear, o al menos
minimizarlo [Gamma et al]
Aspectos a tener en cuenta:
Determinar objetos y clases con responsabilidades correctas
Determinar el interfaz correcto de cada clase
Determinar la granularidad de mtodos, clases y paquetes
Determinar las jerarquas de herencia
Determinar las dependencias entre las clases y paquetes
ndice

Signos de un Mal
Diseo:
Rigidez vs Flexibilidad,
para la adaptacin al
cambio
Fragilidad vs Robustez,
sin propagacin de
errores
Viscosidad vs Claridad,
para la legibilidad
Inmovilidad vs
Movilidad, para la
reusabilidad
ndice

Signos de un Mal Diseo:
Rigidez es la tendencia del software que es difcil de cambiar, incluso
en formas simples. Cada cambio provoca una cascada de cambios
posteriores en los mdulos dependientes. Lo que comienza como un
simple cambio de dos das a un mdulo se convierte en un maratn
de varias semanas de cambios en el mdulo despus de otros
mdulos segn los ingenieros persiguen el hilo del cambio a travs
de la aplicacin.
Cuando el software se comporta de esta manera, los gerentes temen
que permitir a los ingenieros no solucionar problemas crticos. Esta
resistencia se deriva del hecho de que ellos no saben, con
confiabilidad, cuando terminarn. Si los gerentes insisten, los
ingenieros se perdern en este tipo de problemas, que pueden
desaparecer durante largos periodos de tiempo.
Cuando los miedos del gerente son tan agudos que se niegan a
permitir cambios en el software, la rigidez oficial se instala. Por lo
tanto, lo que comienza como una deficiencia de diseo, termina
siendo una poltica de gestin adversa.
ndice

Fragilidad. En estrecha relacin con la rigidez est la fragilidad.
Fragilidad es la tendencia del software para estropearse en muchos
lugares cada vez que se cambia. A menudo, el error se produce en
las zonas que no tienen ninguna relacin conceptual con el rea que
se ha cambiado..
Segn empeora la fragilidad, la probabilidad de error aumenta con el
tiempo, asintticamente acercndose 1. Este tipo de software es
imposible de mantener. Cada solucin hace que sea peor, la
introduccin de ms problemas que soluciones.
Tales errores llenan las sensaciones de los gerentes de malos
presagios. Cada vez que autorizan una solucin, temen que el
software va a estropearse de alguna manera inesperada. Este tipo de
software hace que los gerentes y los clientes sospechen que los
desarrolladores han perdido el control de su software. La
desconfianza reina, y la credibilidad se pierde.
ndice

Viscosidad viene en dos formas: viscosidad del diseo, y la
viscosidad del entorno.
La viscosidad del diseo se produce cuando nos enfrentamos a un
cambio, los ingenieros suelen encontrar ms de una manera de hacer
el cambio. Algunas de las formas conservan el diseo, otros no lo
hacen, es decir, son atajos. Cuando preservar el diseo es ms difcil
que emplear los atajos, a continuacin, la viscosidad del diseo es
alta. Es fcil de hacer las cosas mal, pero difcil de hacer lo correcto.
La viscosidad del entorno se produce cuando el entorno de
desarrollo es lento e ineficiente. Por ejemplo, si los tiempos de
compilacin son muy largos, los ingenieros tendrn la tentacin de
hacer cambios que no obligan a grandes re-compilaciones, a pesar
de que esos cambios no son ptimos desde el punto de vista del
diseo. Si el sistema de control de cdigo fuente requiere horas para
comprobar tan slo unos pocos archivos, consecuentemente, los
ingenieros tendrn la tentacin de hacer cambios que requieren el
menor nmero de subidas (commits) como sea posible,
independientemente de si el diseo se conserva.
ndice

La inmovilidad es la imposibilidad de volver a utilizar el software
de otros proyectos o de partes del mismo proyecto.
A menudo sucede que un ingeniero descubrir que necesita un
mdulo que es similar a uno que escribi otro ingeniero. Sin
embargo, tambin sucede a menudo que el mdulo en cuestin tiene
demasiado equipaje del que depende.
Despus de mucho trabajo, los ingenieros descubren que el trabajo y
el riesgo requerido para separar las partes deseables del software de
las partes no deseadas son demasiado grandes como para tolerarlo. Y
as, el software es simplemente reescrito en lugar de reutilizado.
ndice

Causas de un mal
diseo:
Cambio de los requisitos
Mala Gestin de
Dependencias
ndice

Causas de un Mal Diseo:
Cambio de los requisitos (Ley del Cambio Continuo [Lehman y
Belady]):
Los requisitos han ido cambiando de forma que el diseo inicial
no anticip. A menudo, estos cambios deben hacerse
rpidamente, y pueden ser hechos por los ingenieros que no estn
familiarizados con la filosofa de diseo original. As que, aunque
el cambio en el diseo funciona, viola de alguna manera el diseo
original. Poco a poco, a medida que los cambios siguen llegando,
estas violaciones se acumulan hasta que la podredumbre se
asienta. Ley de Complejidad Creciente [Lehman y Belady]
ndice

Cambio de los requisitos (Ley del Cambio Continuo [Lehman y
Belady]):
Sin embargo, no podemos culpar a la deriva de los requisitos por
la degradacin del diseo. Nosotros, como ingenieros de
software, sabemos muy bien que las necesidades cambian. De
hecho, la mayora de nosotros nos damos cuenta de que el
documento de requisitos es el documento ms voltil en el
proyecto. Si nuestros diseos estn fallando debido a la lluvia
constante de cambios en los requisitos, son nuestros diseos los
que estn fallando. Tenemos que encontrar alguna manera una
manera de hacer nuestros diseos resistentes a tales cambios y
protegerlos de la descomposicin.
ndice

Mala Gestin de Dependencias.
Los cambios que introducen dependencias nuevas y no
planificadas.
Cada uno de los cuatro sntomas mencionados anteriormente son,
ya sea directamente o indirectamente, causados por indebidas
dependencias entre los mdulos del software. Es la arquitectura
de dependencias la que se est degradando y con ella la
capacidad del software para ser mantenido.
Con el fin de evitar la degradacin de la arquitectura de
dependencias, las dependencias entre mdulos en una aplicacin
deben ser gestionadas. Esta gestin consiste en la creacin de
cortafuegos de dependencias. A travs de cortafuegos, las
dependencias no se propagan.
ndice
3.7.2. Calidad del Software de Bajo Nivel

Cdigo sucio (Smell Code cdigo
maloliente, hediondez del cdigo) de
Beck, K. y Fowler, M. en 1999.
Cdigo sucio es cualquier sntoma en el cdigo
fuente de un programa que posiblemente indica
un problema ms profundo. Las hediondeces
del cdigo usualmente no son errores de
programacin, no son tcnicamente incorrectos
y en realidad no impiden que el programa
funcione correctamente. En cambio, indican
deficiencias en el diseo que puede ralentizar el
desarrollo o aumentan el riesgo de errores o
fallos en el futuro.
ndice

Cdigo Limpio (Clean Code) de Martin,
R. en 2008
El cdigo limpio se puede leer y mejorar por un
desarrollador que no sea su autor original.
Tiene pruebas de unidad y de aceptacin. Tiene
nombres significativos. Proporciona una forma en
lugar de muchas maneras para hacer una cosa.
Tiene dependencias mnimas, que se definen
explcitamente, y proporciona una API clara y
mnima. El cdigo se debe saber leer y escribir ya
que dependiendo del lenguaje, no toda la
informacin necesaria se puede expresar con
claridad en el cdigo solo [Thomas, D. -
Eclipse]
Cdigo limpio es simple y directo. Cdigo
limpio se lee como una buena prosa escrita. Cdigo
limpio nunca oscurece la intencin del diseador,
sino que est lleno de abstracciones ntidas y lneas
sencillas de control [Booch, G. - RUP]
ndice

Ambas propuestas han recuperado las Guas y/o Reglas de
Estilo, Modismos, al centro de atencin como punto de
partida para un buen diseo. Su mbito suele reducirse a
reglas postivas (Clena Code)/negativas (Smell Code) de
sentencias, atributos, mtodos y clases pero no suelen afectar
a paquetes o arquitecturas.
El estilo de codificacin y la legibilidad establecen los precedentes que

afectan a la mantenibilidad y extensibilidad mucho despus de que el
cdigo original se haya cambiado
[Martin, R]
ndice
3.7.3. Calidad del Software de Medio Nivel

Patrones Generales de Software para Asignacin de
Responsablidades (GRASP General Responsibility
Assignment Software Patterns / captar) de Larman, C. en 2005:
Patrn Experto en informacin
Patrn Alta cohesin
Patrn Bajo acoplamiento
Patrn Controlador
Patrn Creador
Patrn Polimorfismo
Patrn Fabricacin pura
Patrn Indireccin
Patrn Variaciones Protegidas
Vlidos para el anlisis o diseo preliminar afectando a clases o
pequeas colecciones de clases
ndice

Principios de Diseo Orientado a
Objetos (SOLID) por Martin, R. en
1995:
Principio de nica Responsabilidad (SRP
- The Single Responsibility Principle)
Principio Abierto/Cerrado (OCP - The
Open Closed Principle)
Prinicipio de Sustitucin de Liskov (LSP -
The Liskov Substitution Principle)
Principio de Separacin de Interfaces
(ISP - The Interface Segregation Principle)
Principio de Inversin de Dependencias
(DIP - The Dependency Inversion Principle)
Vlidos para el diseo detallado afectando a
clases o pequeas colecciones de clases y
sus relaciones de dependencia
ndice

Patrones de Diseo por Gamma et
al en 1994:
Cada patrn describe un problema que
ocurre una y otra vez en nuestro entorno y
luego describe el ncleo de la solucin a ese
problema, de tal manera que se puede
utilizar esta solucin un milln de veces,
sin tener que hacerlo de la misma manera
dos veces [Alexander]
Vlidos para el diseo de colecciones de
clases que colaboran y sus dependencias
en un contexto muy particular
ndice

Antipatrones (Antipatterns) por
Brown, W et al en 1998:
Antipatrones proporcionan experiencia del
mundo real en el reconocimiento de los
problemas recurrentes en la industria del
software y proporcionar un remedio detallado
para los predicamentos ms comunes.
Vlidos para clases o colecciones de clases en
un contexto particular
ndice

Comparativa entre Patrones y Antipatrones
ndice
3.7.4. Calidad del Software de Alto Nivel

Arquitectura del Software es el conjunto de decisiones
significativas sobre la organizacin del sistema software, la
seleccin de elementos estructurales en los que el sistema
est compuesto y los interfaces entre ellos, junto con sus
comportamientos especificados como colaboraciones de
estos elementos, la composicin de estos elementos
estructurales y de comportamiento en subsistemas ms
grandes progresivamente [Booch, G] y
parbola del ciego y el elefante

ndice

Arquitectura del Software y el estilo arquitectnico que
gua esta organizacin dado por [Booch, G]:
Restricciones no funcionales (rendimiento, plataforma, )
Tecnologas (protocolos, bases de datos, )
Reusabilidad (diccionarios de datos, APIs, )
Economa (sistemas heredados, frameworks, )
Compromisos de uso (disponibilidad, amigabilidad, )
Flexibilidad al cambio (patrones de software, cortafuegos, )
y aspectos estticos (C2, CMMI, )
compartir una estructura de alto nivel y

mecanismos clave similares
ndice

Principios de Paquetes de Martin, R.
en 1996 establece:
Principio de Equivalencia entre Entrega y
Reusabilidad
Principio del Cierre Comn
Principio de la Reusabilidad Comn
Principio de Dependencias Acclicas
Principio de Dependencias Estables
Principio de Abstracciones Estables
ndice

Estilos arquietectnicos y Patrones de
Arquitectura del Software por Fowler,
M. et al en 2002
Presento mi percepcin de las partes
principales de una aplicacin empresarial y de
las decisiones que me gustara tomar para poder
hacerlo bien desde el principio. El patrn
arquitectnico que ms me gusta es el de capas,
[]. Algunos de los patrones en este libro
razonablemente se puede llamar arquitectnicos,
ya que representan las decisiones importantes
sobre estas partes; otros son ms sobre el diseo
y ayudan a realizar la arquitectura
ndice

Antipatrones (Antipatterns) por
Brown, W et al en 1998:
Antipatrones proporcionan experiencia del
mundo real en el reconocimiento de los
problemas recurrentes en la industria del
software y proporcionar un remedio detallado
para los predicamentos ms comunes
Los siguientes antipatrones centran en
algunos problemas y errores comunes en la
creacin, implementacin y gestin de la
arquitectura
ndice
3.7.5. Mtricas de Calidad del Software

Una aplicacin practica de las mtricas orientadas a objetos
(OO), es predecir que clases tienen una alta probabilidad
de contener defectos.
Esto tiende a ser significativo dado que, se cree que las mtricas OO
son indicadores de complejidad psicolgica y, las clases que son ms
complejas son ms probables que contengan defectos.
Recientemente se ha propuesto una teora cognitiva la cual sugiere
que existe un efecto de umbral para varias mtricas OO. Esto significa
que las clases OO son fciles de entender, mientras su complejidad
este por debajo del valor de umbral. Por encima del valor de umbral,
su comprensin decrece, llevando a una probabilidad de fallas
incremental.
Acorde a esta teora, esto sucede debido a que la memoria humana a
corto plazo colapsa. Si esta teora se confirma, proveera un
mecanismo que podra explicar la introduccin de fallas en sistemas
OO, y proveera tambin una gua practica de cmo disear sistemas
OO
ndice
3.7.6. Reusablidad del Software

Reusabilidad a menudo se promociona como el propsito de los
objetos. Creemos que la reusabilidad est sobrevalorada (slo tiene
que utilizar).
Sin embargo, no podemos negar que gran parte de nuestra
habilidad de programacin se basa en las clases de la biblioteca,
para que nadie pueda decir que nos hemos olvidado de nuestros
algoritmos de ordenacin [Fowler]
ndice
3.7.6. Reusablidad del Software

Tipos:
Reusabilidad del Cdigo: es utilizar
cdigo ya escrito, documentado y
probado en nuevos contextos
(aplicaciones). Ej.: Bibliotecas
Reusabilidad del Diseo: es utilizar
diseos ya documentados y probados
en nuevos contextos (aplicaciones).
Ej.: Patrones
Reusabilidad del Cdigo/Diseo: es
utilizar cdigo ya escrito
documentado y probado en nuevos
contextos (aplicaciones) e impone
diseos ya documentados y probados
en dichos contextos (aplicaciones).
Ej.: Frameworks (Bibliotecas)
ndice
3.7.7. Resumen
Calidad del Software de Calidad del Software de
soluciones positivas: soluciones negativas:
Principios. Ej.: Simplicidad, Prohibiciones. Ej.: Duplicidad,

Cdigo Limpio. Ej.: Nombres Cdigo Sucio. Ej.: Acrnimos
significativos, de nombres,
Patrones: Soluciones buenas a Antipatrones: Soluciones malas
problemas recurrentes, a problemas recurrentes,
ndice
3.7.7. Resumen
3. Software 93
ndice
3.8. Metodologas de Desarrollo del Software

1. Introduccin
2. Metodologa en Cascada
3. Metodologas Iterativas e Incrementales
4. Metodologas RUP vs Scrum+XP
3. Software > 8. Metodologas de Desarrollo del Software 94
ndice
3.8.1. Introduccin
Proceso de Desarrollo Software: el conjunto total de
actividades necesarias para transformar los requerimientos
del cliente en un conjunto consistente de artefactos que
representan un producto software y, en un momento
posterior, para transformar los cambios de estos
requerimientos en una nueva versin del producto software.
La diferencia entre una metodologas y otras radica en el orden,
grado y tcnicas en que se acometen las actividades de las distintas
disciplinas de la ingeniera del software
ndice
3.8.2. Metodologa en Cascada

La versin original fue propuesta por Royce, W. W. en 1970
y posteriormente revisada por Boehm, B. en 1980 y
Sommerville, I. en 1985.
Etapas:
El inicio de cada etapa debe esperar a la finalizacin de la

etapa anterior. Ante la deteccin de un error en una etapa se
requiere la retroalimentacin de fases anteriores
ndice
3.8.2. Metodologa en Cascada

Ventajas:
Son modelos fciles de implementar y entender. Son modelos
conocidos y utilizados con frecuencia.
Promueven una metodologa de trabajo efectiva: definir antes que
disear, disear antes que codificar
Si el 90% o ms de los requisitos de tu sistema se espera que sean
estables a lo largo de la vida del proyecto, entonces aplicar una
poltica dirigida por los requisitos es una oportunidad apropiada de
dar razonablemente una solucin ptima. [Booch Object Solutions]
Desventajas:
Cualquier error de diseo detectado en la etapa de prueba conduce
necesariamente al rediseo y nueva programacin del cdigo
afectado, aumentando los costos del desarrollo
Otros grados menores de estabilidad en los requisitos requieren un
enfoque de desarrollo diferente para dar un valor tolerable del coste
total [Booch Object Solutions]
ndice
3.8.3. Metodologas Iterativas

Definiciones:
Iteracin: Un conjunto distinto de actividades llevado a cabo de
acuerdo con un plan dedicado (iteracin) y criterios de evaluacin
que se traduce en una entrega, ya sea interna o externa.
Incremento: Una parte del sistema pequea y manejable, por lo
general, la diferencia entre dos construcciones sucesivas.
Cada iteracin se traducir en al menos una nueva
construccin y, por lo tanto, se aadir un incremento en el
sistema.
Planificar de un poco.
Especificar, disear e implementar un poco.
Integrar, probar y ejecutar un poco en cada iteracin
[Booch]
ndice

Definiciones:
Entrega. Un conjunto de artefactos (documentos y posiblemente una
construccin ejecutable) relativamente complete y consistente
entregada a usuarios externos o internos
Entrega interna. Una entrega no expuesta a los clientes y usuarios
pero s internamente solo para el proyecto y sus miembros
Entrega externa. Una entrega expuesta a clientes y usuarios
externos al proyectos y sus miembros.
Releases
Inception Elaboration Construction Transition
Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition

Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration
ndice

Desventajas:
Dificultad para gestionar a los miembros del equipo de desarrollo en
un iteracin cerrada o dificultad para gestionar a los miembros del
equipo de desarrollo con varias iteraciones abiertas en paralelo
Ventajas:
Permite la participacin del usuario desde fechas tempranas del
proyecto para corregir las desviaciones de sus necesidades
Permite elevar el nimo del equipo de desarrollo con las entregas
externas que superan las pruebas de aceptacin
Errores de programacin, diseo, se localizan con facilidad en el
incremento producido en la iteracin vigente
ndice

Falta del involucracin del usuario 12.8%
Requerimientos y especificaciones poco claras 12.3%
Cambio de requerimientos y especificaciones 11.8%
? Poco apoyo de las gerencias involucradas 7.5%
? Tecnologa deficiente 7.0%
? Falta de recursos 6.4%
Expectativas poco realistas 5.9%
Objetivos poco claros 5.3%
Tiempos poco realistas 4.3%
? Nuevas tecnologas 3.7%
? Otros 23.0%
ndice
3.8.4. Metodologas RUP vs Scrum+XP

RUP (Rational Unified Process):
DO {
Requisitar
Analizar
Disear
Programar
Probar
Desplegar
} WHILE (finProyecto)
ndice

Scrum+XP (eXtreming programming):
DO {
Requisitar-Analizar Sprint Planning Meeting
Probar-Disear Test Driven Development
Programar-Redisear (Refactoring)
Desplegar Continuous Integration
} WHILE (finProyecto)
ndice

RUP: Scrum+XP:
Gestin de documentacin de Poca documentacin porque la
requisitos, anlisis y diseo: mejor documentacin es el
pesadas cdigo: ligeras
Con estimaciones del tiempo y Sin estimaciones del tiempo ni
coste del proyecto entero coste del proyecto entero
Planificacin a largo plazo y Planificacin de la iteracin
revisiones del plan en cada actual pero sin previsin a largo
iteracin plazo
Entrevistas con el cliente Entrevistas con el cliente
durante las primeras iteraciones durante todo el proyecto, cliente
y en cada entrega in situ parte del proyecto
Desarrollo priorizado por Desarrollo priorizado por el
riesgos tcnicos, polticos, valor de retorno al cliente
Roles especializados por Desarrolladores
desarrollador multidisciplinares
Diseo de la Arquitectura Arquitectura emergente segn
propuesta previa al desarrollo se re-disea (TDD y refactoring)
ndice

Arquitectura del Software:
RUP
XP+Scrum
ndice

Arquitectura del Software :
Top-down
Bottom-up

Miw. Vgiw. 3. Software

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Miw. Vgiw. 3. Software

Uploaded by

Copyright:

Available Formats

Visin General de la

3.1. Naturaleza del Software

3.1.1. Definicin del Software

3.1.2. Definicin de Sistemas Complejos

3.1.3. Atributos de Sistemas Complejos

3.1.3. Atributos de Sistemas Complejos

3.1.3. Atributos de Sistemas Complejos

3.1.3. Atributos de Sistemas Complejos

3.2. Fundamentos del Software

Para hacer frente a la complejidad, nos abstraemos de ella!!!

Facultades Rectorado Titulares Asociados

Departamentos Direccin Interinos Funcionarios

3.3. Economa del Software

No hay una relacin sencilla entre las cuatro variables. Por

3.3.2. Variable mbito

3.3.2. Variable mbito

3.3.2. Variable mbito

3.3.3. Variable Tiempo

3.3.4. Variable Coste

3.3.4. Variable Coste

3.3.5. Variable Calidad

3.3.6. Variables correlacionadas

Algunos directores de proyecto y clientes creen que pueden

3.4. Crisis del Software

3.4.1. Justificacin de la Crisis del Software

3.4.2. Estadsticas de Proyectos

Incluyendo accidentes que conllevaron a la muerte de tres personas en la mquina de

3.4.3. Causas de la Crisis del Software

3.5. Complejidad del Software

3.5.1. La complejidad del dominio del problema

Ley del Cambio Continuo:

3.5.2. Las limitaciones de la capacidad humana

3.5.3. La posible flexibilidad a travs del software

3.5.4. El comportamiento de los sistemas discretos

3.5.5. La dificultad de gestionar el proceso de desarrollo

3.6. Disciplinas del Software

3.6.2. Disciplina de Requisitos

3.6.3. Disciplina de Anlisis

3.6.3. Disciplina de Anlisis

3.6.3. Disciplina de Anlisis

3.6.4. Disciplina de Diseo

3.6.4. Disciplina de Diseo

3.6.4. Disciplina de Diseo

3.6.4. Disciplina de Diseo

3.6.4. Disciplina de Diseo

3.6.5. Disciplina de Programacin

3.6.6. Disciplina de Pruebas

3.6.7. Ecosistema de Desarrollo

3.6.7. Ecosistema de Desarrollo

3.6.7. Ecosistema de Desarrollo

3.6.7. Ecosistema de Desarrollo

La posible flexibilidad a travs del Calidad y Reusabilidad: Mtricas,

La dificultad de gestionar el proceso de Metodologas iterativas pesadas vs

3.7. Calidad del Software

3.7.1. Calidad del Software

3.7.1. Calidad del Software

3.7.1. Calidad del Software

3.7.1. Calidad del Software

3.7.1. Calidad del Software

3.7.1. Calidad del Software

3.7.1. Calidad del Software

3.7.1. Calidad del Software

3.7.1. Calidad del Software

3.7.1. Calidad del Software