1_1 Introduccion

UNIVERSIDAD TECNICA DEL NORTE
FACULTAD DE INGENIERIA EN CIENCIAS APLICADAS
CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES
Ing. Pablo Landeta López

INTRODUCCION Y DEFINICIONES
Cómo desarrollamos sistemas?
• Se detecta la necesidad de iniciar un proyecto.- Varias
restricciones son originadas en esta fase
• Se reúnen los requerimientos del usuario .- El centro de
atención es la Funcionalidad.
• Se planea el proyecto.- Repartiendo la funcionalidad
deseada el el tiempo y presupuesto disponibles.
• Se diseña la aplicación.- De acuerdo a la especificación técnica de los
requerimientos funcionales
• Se desarrolla y se prueba el software.- La prioridad es cubrir la funcionalidad
acordada.
• Se libera y se pone en operación al nuevo sistema.- Todos conocen por fin el
nuevo sistema y..

Resultados típicos:
• Los usuarios: Sienten lento el sistema, lo encuentran difícil de usar,
experimentan interrupciones en el servicio.
• Los operadores: Tienen dificultad para ponerlo en
ejecución y para diagnosticar y detectar fallos. Se dan
cuenta de que no soporta la carga real.
• Los programadores: Se encuentran con problemas al
agregar nueva funcionalidad.
• El área de pruebas: encuentra un sistema difícil de probar
• Los gerentes y áreas de negocio: No sienten que el sistema esté obteniendo
resultados con la eficiencia esperada.
• Los promotores: No sienten que el sistema se atractivo, encuentran rechazo
por parte de los usuarios / clientes.
• Los directivos: No sienten que la inversión haya dado los resultados que
esperaban.

Significado:
El sistema no tiene la calidad esperada
La razón:
• Nunca se pudo atención en la calidad del sistema en las fases de
desarrollo.
• Muchas veces las expectativas de calidad no eran ni siquiera conocidas al
comenzar el desarrollo.

La culpa?
El negocio dice: Esto es responsabilidad de sistemas … y con muchas razón
Sistemas dice: Nada de esto venía en los requerimientos!! … y también con
mucha razón.

Problemas:
• Relacionados con requerimientos no funcionales: rendimiento,
disponibilidad, confiabilidad, etc.
• No se puede identificar al responsable (culpable)
• No son defectos de programación, sino malas
decisiones: protocolos, seguridad, escalabilidad,
rendimiento, etc.
• Existe un brecha natural de comunicación entre las áreas de negocio y los
desarrolladores.
• Hay decisiones que ninguno de ellos puede tomar de manera
independiente.
Origen del problema:

Necesidad:
• Darle a la calidad del software la misma importancia que a la funcionalidad
• El análisis y diseño basados únicamente en la funcionalidad no nos permiten
expresar correctamente las necesidades de calidad del software
Análisis y diseño tienen distinto enfoque:
Contexto del
problema
Contexto de la
solución

Solución:
• La disciplina de la Arquitectura del software
• Funciona como enlace entre el Análisis y Diseño.
Contexto del
problema
Contexto de la
solución
• Introduce al proceso de desarrollo la atención hacia la calidad del software.
Análisis de
requerimientos
Diseño de
software
Arquitectura
de software

Por qué la Arquitectura?:
• Analogía: Arquitectos, ingenieros, y constructores. Diversos perfiles,
pero complementarios
• La Arquitectura de Software no es sobre objetos o páginas o pantallas o
algoritmos.
• La Arquitectura de Software no es sobre como construir software, sino que
software construir (o reutilizar o comprar).

Arquitectura en una construcción es una estructura física. Pero tenemos muchos
atributos (forma en que se adapta al ambiente y se integra a otros edificios, el
grado en que cumple su propósito y satisface al propietario, la estética, el efecto
visual interno y externo).
También son las miles de decisiones (grandes y pequeñas). Algunas se toman en la
etapa inicial del diseño y tienen efecto en las demás acciones. Otras se toman
más adelante
Es importante porque no es posible construir una casa sin un plano. Tampoco se
empieza los planos con el dibujo de la plomería. Antes de los detalles es
necesario tener un panorama general. Eso hace el diseño arquitectónico: da el
panorama y asegura que sea el correcto.

En el Software Engineering Institute se agrupan muchas definiciones
http://www.sei.cmu.edu/architecture/definitions.html
- lugar en el ciclo de vida
- configuración o topología estática
- vista del sistema con sus componentes principales
- estructura global de control: protocolos, sincronización, funcionalidad a
elementos de diseño, distribución física, escalabilidad, performance.
- puente entre requerimiento y código
Ingeniería del software IEEE 610.12.1990:
La aplicación de una estrategia sistemática, disciplinada y cuantificable
al desarrollo, aplicación y mantenimiento del software; esto es, la
aplicación de la ingeniería al software.
Definición oficial: IEEE Std 1471-2000
La Arquitectura de Software es la organización fundamental de un
sistema encarnada en sus componentes, las relaciones entre ellos y el
ambiente y los principios que orientan su diseño y evolución.

Al hablar de componentes de software puede ser un módulo de programa, una
clase orientada a objetos, puede incluir bases de datos y middleware, etc.
Las propiedades de los componentes son las características necesarias para
entender comp interactuan unos componentes con otros.
Las relaciones entre componentes pueden ser una invocación de procedimientos
de un módulo a otro o protocolos de acceso a base de datos.
La arquitectura permite:
 Analizar la efectividad del diseño pra cumplir los requerimientos establecidos
 Considerar alternativas arquitectonicas en un etapa en la que hacer cambios
de diseño es todavía relativamente fácil
 Reducir los riesgos asociados en la construcción de software

La diferencia entre AS e IS: la noción clave de la AS es la organización (un
concepto cualitativo o estructural), mientras que la IS tiene fundamentalmente
que ver con una sistematicidad susceptible de cuantificarse.
El énfasis de la solución del ingeniero de software se encuentra en los aspectos
técnicos. La del arquitecto en el contexto del negocio.
La razón principal de la Arquitectura de Software reside en el que el análisis y
diseño no son suficientes para resolver el problema. En la mayoría de los sistemas
empresariales es muy importante tomar en cuenta los requerimientos no
funcionales conocidos también como Atributos de Calidad.

Beneficios de la arquitectura del software:
• Aumenta la predictibilidad de la calidad del producto final
• Abre la oportunidad de detectar riesgos en una fase temprana del ciclo de
desarrollo.
• Las representaciones de la arquitectura del software fomentan una
comunicación eficiente y oportuna entre interesados y desarrolladores.
• La arquitectura resalta las primeras decisiones que tendrán un efecto profundo
en todo el trabajo de ingeniería de software siguiente y en el éxito del sistema
• La arquitectura se constituye en un modelo pequeño y asequible sobre como
esta estructurado el sistema.

Como se logra todo esto?
• Al reconocer que no es suficiente con identificar los
requerimientos funcionales sino que también hay otras
influencias que determinan el éxito de un sistema. La
arquitectura las identifica y trabaja con ellas
• El diseño de la arquitectura comienza con el diseño de los
datos y continua con la obtención de una o más
representaciones de la estructura arquitectónica del
sistema.
• Se analizan alternativas de estilos o patrones
arquitectónicos para llegar a la estructura más adecuada
para los requerimientos del usuario y para los atributos de
calidad.
• Seleccionada la alternativa se elabora la arquitectura usando un método de
diseño.
• Se crea un modelo de la arquitectura que incluye la arquitectura de los datos y
la estructura del programa. Se describen las relaciones entre componentes.

Influencias de la Arquitectura del software:
• Los Involucrados o interesados en el sistema (stakeholders)
• La organización misma
• El ambiente tecnológico
• La experiencia de los arquitectos
• El contexto gubernamental y legal
Influencia: Stakeholders
• La gente que ideó el proyecto
• La que la va a financiar
• La que la va a usar
• La que recibirá los beneficios
• La que lo va a diseñar
• La que lo va a desarrollar
• La que lo va a probar
• La que lo va a operar
• La que lo va a promocionar
• La que lo va a dar soporte técnico.

Influencia: la organización:
• Procesos y políticas del negocio
• Infraestructura tecnológica
• Tiempos y presupuestos
• Recursos humanos y materiales
• Nivel de experiencia del equipo de desarrollo
Influencia: el ambiente tecnológico:
• Tecnologías de moda
• Hardware disponible
• Patrones arquitectónicos
• Disponibilidad de productos de terceros
• Tendencias de la industria
• Expertos y consultores
• Servicios de outsourcing existentes
Influencia: experiencia de arquitectos:
• Con todo constante, dos arquitectos
trabajando por separado nunca
diseñarían una arquitectura idéntica.
Cada quien utilizaría las técnicas y
herramientas que le han sido útiles en
el pasado

Requerimientos funcionales: Lo que el sistema debe proveer. Estos definen que
es lo que el usuario necesita y no el como lo hace. Es el conjunto de
características y capacidades del programa.
Estos requerimientos se desprenden del Diagrama de Contexto del sistema a
través de Procesos del negocio (persiste en el tiempo) y Casos de Uso (interacción
particular del usuario)

Atributos de calidad (requerimientos no funcionales):
La funcionalidad puede ser la misma, pero las características de calidad no.
• Desempeño o rendimiento: Se mide con base a la velocidad de procesamiento,
el tiempo de respuesta. El grado en que el sistema responde a un cierto evento
es decir la eficiencia.
• Disponibilidad: grado de operabilidad del sistema. Recuperación en eventos.
• Seguridad: que no produce consecuencias fatales.
• Escalabilidad: propiedad de un sistema que indica su habilidad para reaccionar
y adaptarse, o bien manejar el crecimiento continuo de trabajo de manera
fluida, o para estar preparado para hacerse más grande sin perder calidad.

Atributos de calidad (requerimientos no funcionales):
• Usabilidad: que tan fácil es la operación del sistema, es decir se toma en
cuenta factores humanos, la estética, la consistencia.
• Fiabilidad o Confiabilidad: Propiedad de un sistema tal que se puede confiar
justificablemente en los servicios que este presta. Se evalúa con la medición
de la frecuencia y gravedad de la fallas, exactitud de resultados, capacidad de
recuperación.
• Mantenibilidad: la capacidad del programa para ser ampliable (extensibilidad),
adaptable y servicial; además que pueda probarse, ser compatible y
configurable.
No todo atributo de calidad de software se pondera por igual al diseñarlo. Una
aplicación tal vez aborde a lo funcional con énfasis en la seguridad. Otra quizá
busque el rendimiento enfocándose en la velocidad de procesamiento.

Drivers de arquitectura: Son los escenarios (funcionales + atributos de calidad)
críticos y significativos que nos permiten modelar, comunicar y evaluar la
arquitectura: generalmente estos son los requerimientos más prioritarios de los
stakeholders.

Calidad
La calidad es un concepto complejo y de facetas múltiples que puede describirse
desde cinco puntos de vista:
o Punto de vista trascendental: La calidad es algo que se reconoce de inmediato,
pero que no es posible definir explícitamente.
o Punto de vista del usuario: concibe la calidad en términos de sus metas
específicas
o Punto de vista del fabricante: la define en términos de las especificaciones
originales del producto. Si las cumple tiene calidad.
o Punto de vista del producto: la calidad tiene que ver con las características
inherentes (funciones y características) de un producto.
o Punto de vista del valor: Mide de acuerdo con lo que un cliente esta dispuesto
a pagar por un producto.

Calidad
En el desarrollo de software la calidad del diseño incluye el grado en que el
diseño cumple las funciones y características especificadas en el modelo de
requerimientos. La calidad de la conformidad se centra en el grado en el que la
implementación se apega al diseño y en el que el sistema resultante cumple sus
metas de requerimientos y desempeño.
Se puede plantear una relación más intuitiva:
Satisfacción del usuario = producto que funciona + buena calidad + entrega dentro del presupuesto y plazo
Si el usuario esta satisfecho nada más importa, es decir este punto de vista de la
calidad afirma que si un producto de software beneficia mucho a los usuarios
finales, estos podrían estar dispuestos a tolerar problemas ocasionales de
confiabilidad y desempeño.

Calidad
Se puede definir a la calidad del software como un proceso eficaz que se aplica
de manera que crea un producto útil que proporciona valor medible a quienes lo
producen y a quienes lo utilizan.
 Proceso eficaz: administración del proceso, prácticas de ingeniería del
software, la administración del cambio y revisiones técnicas.
 Producto útil: funciones y características de forma confiable y sin errores.
Satisface los requerimientos establecidos
 Agregar valor: la organización que elabora el software obtiene valor agregado
porque el software de calidad requiere menos esfuerzo de mantenimiento,
menos errores que corregir, menos asistencia. Para el usuario final significa
mayores utilidades, más rentabilidad y mejor disponibilidad.

Factores de la Calidad ISO 9126
Este estandar se desarrollo con la intención de identificar los atributos clave del
software. Identifica 6 atributos clave de calidad:
 Funcionalidad: grado en que el software satisface las necesidades planteadas
 Confiabilidad: Cantidad de tiempo que el software se encuentra disponible.
 Usabilidad: Grado en que el software es fácil de usar
 Eficiencia: Grado en que el software emplea óptimamente los recursos
 Facilidad de mantenimiento: facilidad con la que pueden realizarse
reparaciones al software (analizable, cambiable, estable, fácil para pruebas)
 Portabilidad: Facilidad con la que un software puede llevarse de un ambiente a
otro (adaptable, instalable, conformidad y sustituible)

Ejemplo: Factores de la Calidad que se persiguen en la interfaz
Para hacer una evaluación se necesita determinar atributos específicos y
medibles de la interfaz:
Intuitiva: Grado en que la interfaz sigue patrones de uso esperados, de modo que
hasta un novato lo pueda usar sin mucha capacitación.
Eficiencia: Grado en que es posible localizar o iniciar las operaciones y la
información.
Robustez: Grado en que el software maneja
entradas erróneas de datos o en el que se
presenta interacción inapropiada por parte del
usuario
Riqueza: Grado en que la interfaz provee un
conjunto abundante de características.

Dilema de la calidad del software
Si produce un software de mala calidad, usted pierde porque nadie lo querrá
comprar.
Si dedica un esfuerzo infinito (tiempo y dinero) para generar un elemento
perfecto de software, entonces tomará tanto tiempo terminarlo y será tan caro
que de igual manera terminará fuera del negocio.
En cualquier caso habrá perdido la ventana
del mercado, o habrá agotado sus recursos.
Las personas tratan de situarse en es punto
medio donde el producto es
suficientemente bueno para para no ser
rechazado de inmediato, pero tampoco un
objeto perfeccionista.

Software lo suficientemente bueno
Es aceptable producir software lo suficientemente bueno?.. La pregunta debe ser
que sí, de hecho las principales compañías de software lo hacen a diario. Crean
software con errores detectados y lo distribuyen a una gran población de usuarios
finales. Reconocen que algunas funciones de la versión 1.0 tal vez no sean de la
calidad más alta y planean hacer mejoras en la versión 2.0.
El software lo suficientemente bueno contiene las funciones y características de
alta calidad que desean los usuarios, pero al mismo tiempo contiene errores
conocidos. El vendedor espera que la mayoría de usuarios finales perdone los
errores gracias que están muy contentos con la funcionalidad de la aplicación.

Software lo suficientemente bueno
Esto puede funcionar para ciertos dominios de aplicación y para algunas
compañías grandes de software.
Pero en una compañía pequeña hay que tener cuidado. Al entregar un producto
bueno (pero defectuoso) corre el riesgo de causar un daño permanente re
reputación a su compañía. Tal vez no llegue a entregar una versión 2.0 porque la
empresa se puede derrumbar antes de lograrlo.
En casos como software automotriz o de telecomunicaciones, entregar software
con errores conocidos se convierte en una negligencia y puede crear litigios
legales o incluso puede ser un delito.

Costo de la calidad
No hay dudad que la calidad tiene un costo,
pero la mala calidad también lo tiene.
El costo de la calidad puede dividirse en los
costos asociados con la prevención, la
evaluación y la falla.
• Prevención: costo de actividades de administración para planear y coordinar las
actividades de control, costo de actividades técnicas agregadas para desarrollar
modelos completos de los requerimientos y del diseño, costos de capacitación
• Evaluación: costo de efectuar revisiones técnicas, costo de recopilar datos y
unidades de medida, costo de hacer pruebas y depurar
• De falla: costo por repeticiones, costos por efectos colaterales, costo de
unidades de medida de calidad, costos por solución de quejas, devoluciones,
sustitución de productos, garantía.

Riesgos de la mala calidad
Lo perjudicial de la aplicaciones mal diseñadas e implementadas no siempre se
mide en dólares y tiempo.
Ejemplo: En noviembre del 2000, en un hospital de Panamá, 28 pacientes
recibieron dosis masivas de rayos gama durante un tratamiento contra cáncer.
Meses después 5 pacientes murieron por envenenamiento radiactivo 15 quedaron
con complicaciones serias.
Que ocasionó la tragedia?: Un paquete de software
desarrollado por una compañía estadounidense, que
fue modificado por técnicos del hospital para
calcular la dosis de radiación para cada paciente.
Los tres médicos panameños que modificaron el
software fueron acusados de asesinato en segundo
grado.
La empresa desarrolladora enfrentó litigios legales
en dos países.

Calidad y seguridad
El software que no tiene calidad es fácil de penetrar por parte de intrusos, en
consecuencia el software de mala calidad aumenta indirectamente el riesgo de
seguridad con los costos y problemas que conlleva.
Para construir un sistema seguro hay que centrarse en la calidad, y eso debe
comenzar durante el diseño.
Al eliminar las fallas de arquitectura (con lo que
mejora la calidad del software) será más difícil que
intrusos penetren en el software.

Lograr la calidad del software
La calidad del software no solo se ve, es el resultado de una buena administración
del proyecto y de una correcta práctica de ingeniería de software. Se pueden
considerar 4 actividades para lograr una alta calidad.
 Métodos de la arquitectura del software: Se debe entender el problema que se
quiere resolver. Para esto se debe lograr un buen diseño que esté de acuerdo
con el problema.
 Técnicas de administración de proyectos: usar estimaciones para verificar que
las fechas pueden cumplirse, la planeación del riesgo es fundamental.
 Control de calidad: revisión de modelos para garantizar consistencia,
inspeccionar el código para descubrir y corregir errores antes de las pruebas,
etc.
 Aseguramiento de la calidad: funciones de auditoría y reportes para evaluar la
eficacia de las acciones de control de calidad.

En conclusión la AS es:
- Vista estructural de alto nivel
- Define estilo o combinación de estilos para una solución
- Se concentra en requerimientos no funcionales (los funcionales requieren
modelado y diseño de la aplicación)
- Escencial para el éxito o fracaso de un proyecto
Lo hace: Un Ingeniero de software puede diseñar tanto los datos como la
arquitectura pero en sistemas grandes y complejos es necesario un especialista.
El Arquitecto del software selecciona un estilo arquitectónico a partir de los
requerimientos obtenidos durante el análisis de los datos
Se ocupa de:
- Diseño preliminar de alto nivel y su efectividad
- Organización a alto nivel del sistema: descrición y análisis de propiedades,
de estructura y control global, protocolos de comunicación y sincronización,
distribución física, componentes, etc.
- Aspectos del desarrollo, evolución y adaptación: composición, reutilización,
escalabilidad, mantenimiento.

1_1 Introduccion

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 1_1 Introduccion

Similar a 1_1 Introduccion (20)

Más de landeta_p

Más de landeta_p (10)

Último

Último (20)

1_1 Introduccion