CLASE ARQUITECTURA DE SOFTWARE

ARQUITECTURA DE
SOFTWARE
Walter Adrián Gómez Céspedes
Ingeniero de Sistemas
Especialista en Pedagogía Universitaria
Candidato a Máster en Dirección Estratégica en Ingeniería del Software

DESARROLLO DE SISTEMAS DE
SOFTWARE
Software

Requisitos
Funcionale
s del
Software

Serviría para un
Software
monolítico

Los atributos de calidad de Software son esenciales
Software

Arquitectu
ra de
SoftwareSW de Calidad

LOS REQUISITOS DETERMINAN EL
MODELO
Sistema

Conocimiento

Arquitecto

Requisitos

IMPLICACIONES DE NO SEGUIR UN
PROCESO CONOCIDO DE MODELADO
Arquitectura es una
abstracción de un
sistema

Los sistemas
tienen una
estructura

El no
desarrollo de
una
arquitectura
explícita
conduce a
inconformidad

Todo sistema tiene
una arquitectura.

El tener una arquitectura, no implica
que setiene una arquitectura

CONSECUENCIAS DE LAS DECISIONES DE
AS SOBRE LAS CUALIDADES

La arquitectura es crítica para
alcanzar los atributos de calidad

Dependiendo
de las
decisiones de
Arquitectura,
un sistema
alcanza sus
requisitos de
calidad

Las cualidades del producto deben
diseñarse como parte de la
arquitectura

Un cambio en la estructura que mejora
una cualidad suele afectar a otrascualidades
La arquitectura sólo puede permitir, no
garantizar que cualquier requisito de calidad se
alcance

INFLUENCIA DE LOS INTERESADOS

Gerente
Empresa

Ingeniero de
soporte
Bajos costos
Ocupar
personal
Valor Activos

Elementos
atractivos
Terminar
rápido
Comparar
competencia
Gerente
Producto

Modificabilidad
Usuario
Final
Comportamien
to
Seguridad
Confiabilidad
Usabilidad
Arquitecto

Bajos costosTerminar
rápido
Pocos
cambios
Cliente

INTERESADOS INVOLUCRADOS
Objetivos de la organización y las propiedades del
sistema requeridas por el negocio, raramente se
comprenden

¿Qué debe
tener en
cuenta el
arquitecto
de
software?

Los requisitos de
calidad del
cliente, casi
nunca se
documentan

Identificar e
involucrar
activamente a los
interesados

- Objetivos que no
se alcanzan.
- Conflicto entre
losinteresados.

- Comprender
restricciones reales del
sistema.
- Administrar las
expectativas.
- Negociar prioridades
del sistema.
-Tomar decisiones de
compromiso.

ESQUEMA DE PROCESO DE MODELADO
DE AS

Determinar
los Requisitos
Arquitectónic
os
Diseño de la
Arquitectura

Validación

ESQUEMA DE PROCESO DE MODELADO
DE AS
Determinar
los Requisitos
Arquitectónico
s

Diseño de la
ArquitecturaValidación

Involucra
crear
un
modelo
desde
los
requerimientos que guiarán el diseño de la
arquitectura basado en los atributos de calidad
esperados.

Involucra
definir
la
estructura
y
responsabilidades de los componentes
comprenderán la Arquitectura de Software.

las
que

Significa “probar” la arquitectura, típicamente
pasando a través del diseño contra los
requerimientos actuales y cualquier posiblerequerimiento a futuro.

IDENTIFICAR REQUERIMIENTOS
Requisitos
Funcionale
s

Requisitos
de los
interesados

Determinar los
Requisitos
Arquitectónicos

Requisitos
de
Arquitectura

Priorizar

Clasificación de
los requisitos no
funcionales

Identificar
restricciones

REQUERIMIENTOS NO FUNCIONALES
Describen como el software debe comportarse,
es decir como hacer algo, no que debe hacer.
Estánrelacionados con los requerimientos
funcionales porque describen la forma que se
espera se logren dichos requerimientos.

En algunos casos tienen restricciones de cómo
hacerlo.
Se clasifican de acuerdo al atributo de calidad
esperado del sistema.

EJEMPLO DE REQUERIMIENTOS DE AS

ACTIVIDAD CON EL GRUPO DE TRABAJO
Como ya se tiene planteado cuál es el software que se va a desarrollar
durante el trimestre,el siguiente paso a trabajar en identificar los
requerimientos funcionales y no funcionales, para ello hacer uso de la
siguiente forma para el levantamiento de requerimientos:
Nombre:
Tipo:
Descripción:

Criterios de Aceptación:

Crítico: Si/No

DEFINICIONES DE AS
Clements: Vista del sistema que incluye los componentes principales del mismo,
la conducta de esos componentes según se la percibe...