GUIA CONCEPTOS BASICOS Preparado por: Salatiel Moreno Toro 2019 A

ARQUITECTURA DEL SISTEMA: Referenciado hacia la Vistas: Referenciado hacia las proyecciones de modelos
representación del sistema es la que se define la que muestran entidades importantes desde un punto de
correlación de funciones con componentes de hardware vista particular. Estas proyecciones suelen ilustrarse Commented [SMT1]: Arquitectura de sistema:
y software, Es decir, la correlación de la arquitectura de mediante diagramas de algún tipo. Referenciado hacia la representación de un sistema en la
software con la arquitectura de hardware, e interacción TIPOLOGIA VISTAS que hay una correlación de funciones con componentes de
hardware y software, una correlación de la arquitectura de
humana con estos componentes. Estática: Referenciada hacia la descripción de qué software con la arquitectura de hardware, e interacción
MODELOS Y DIAGRAMAS componentes tiene la arquitectura. humana con estos componentes.
Modelo: Referenciado hacia la representación, que Funcional: Referenciada hacia la descripción de qué hace
normalmente trata un área de preocupación en cada componente.
particular. Un sistema, por lo tanto, suele representarse Dinámica: Referenciada hacia la descripción hacia cómo
mediante un conjunto de modelos, ya que el desarrollo o se comportan los componentes a lo largo del tiempo y
la utilización del sistema tienen varios asuntos que tratar. cómo interactúan entre sí.
Cada modelo se puede construir con varios niveles de
abstracción, desde el más general, que oculta o
encapsula detalles, al más específico, que presenta
decisiones de diseño más explícitas y detalladas.
Punto de vista: Referenciado hacia la enfoque o punto
de vista nocional desde la que se pueden ver algunos
aspectos o asuntos del sistema, lo que supone la
aplicación de un conjunto de conceptos y reglas para
formar un filtro conceptual. Normalmente, no es
suficiente (para obtener conocimiento) limitarse a
examinar el sistema real; los modelos se han construido
(o deberían haberse construido) para representar y
describir las preocupaciones.

CONCEPTOS ARQUITECTONICOS Y REGLAS DE ESTRUCTURA
PUNTO DE VISTA ASUNTO
Referenciado hacia el conjunto seleccionado Referenciado hacia el contenido y acciones
de conceptos arquitectónicos y reglas de que se deben tener en cuenta desde el punto
estructura, para centrarse en problemas de vista de la arquitectura
particulares de un sistema)
Trabajador Referenciado hacia los roles y las
responsabilidades de los trabajadores del
sistema, la organización y las políticas que les
afectan.
Información Referenciado hacia las clases de información
que maneja el sistema y las restricciones de
utilización e interpretación de dicha
información.
Lógico Referenciado hacia la descomposición del
sistema en un conjunto de subsistemas que
interactúan en interfaces, colaboran para
proporcionar los servicios del sistema.
Distribución/Físico Referenciado hacia la infraestructura
necesaria para soportar la distribución y la
funcionalidad del sistema.
Proceso Concurrencia, escalabilidad, rendimiento,
producción, fiabilidad.
Commented [SMT2]: Los roles son función(es) que una
persona desempeña en un Sistema.
IMPACTO
Referenciado hacia el alcance del
contenido(s) y acciones considerado en la
arquitectura Commented [SMT3]: Punto de vista: Referenciado hacia
las diferentes áreas de preocupación que deben tratarse en
Referenciado hacia las actividades del el diseño y la arquitectura del sistema.
trabajador, interacción humana/sistema.
Especificación del rendimiento humano y
factores humanos.
Referenciado hacia la integridad de la
información, limitaciones de capacidad.
Accesibilidad de la información, actualidad.
Referenciado hacia que el sistema muestra el
comportamiento deseado.
Referenciado hacia que el sistema es
extensible, adaptable y se puede mantener.
Los activos son reutilizables. Commented [SMT4]: Requisitos funcionales:
Referenciado hacia la adecuación de las Referenciado hacia aquellos que describen cualquier
características físicas del sistema para alojar actividad que este deba realizar: Tenga presente:
las funciones y satisfacer los requisitos no Comportamiento o función particular de un sistema o
funcionales. software cuando se cumplen ciertas condiciones.
La adecuación de la capacidad de respuesta, Requisitos No funcionales: Referenciado hacia aquellos que
el rendimiento y la tolerancia a errores del no se refieren directamente a las funciones específicas
sistema. suministradas por el sistema (características de usuario),
sino a las propiedades del sistema: rendimiento, seguridad,
disponibilidad. En palabras más sencillas, no hablan de “lo
que” hace el sistema, sino de “cómo” lo hace.
 GUIA CONCEPTOS BASICOS Preparado por: Salatiel Moreno Toro 2019 A

NIVEL DE PUNTOS DE VISTA

MODELO Trabajador Lógico Información Distribución/Físico Proceso
Contexto Vista Diagrama de Vista Datos Vista Localidad Vista Proceso Commented [SMT5]: En Bd, una vista es una consulta
Organización contexto del empresariales empresarial empresarial que se presenta como una tabla (virtual) a partir de un
UML sistema conjunto de tablas en una base de datos relacional.
Las vistas tienen la misma estructura que una tabla: filas y
Análisis Vista Trabajador Vista Vista Datos del Vista Localidad del Vista Proceso columnas. La única diferencia es que sólo se almacena de
del sistema Subsistema sistema sistema del sistema ellas la definición, no los datos.
generalizado
Diseño Vista Trabajador Vistas Clase de Esquema de Vista Nodo de Vista Proceso
del sistema subsistema datos del descriptor detallado
Vistas sistema
Componente de
software
Implementación Instrucciones y Configuraciones: diagramas de despliegue con componentes del sistema de
especificaciones hardware y software.
del rol de
trabajador

TIPOS DE ARQUITECTURA Tipos: 3. Cliente-servidor-servidor:

Desarrollo de software
Proceso: El proceso de arquitectura
de software toma los requisitos de
los clientes, los analiza y produce un
diseño para obtener un software que
satisfará sus necesidades.
Requisitos:
Usuario: Referenciado hacia la
inclusión del diseño de interfaz,
capacidades operativas y facilidad de
uso del software.
Sistema: Referenciado hacia el
hardware, las redes y las capacidades
y restricciones del entorno en tiempo
de ejecución. En la figura 1 se
muestra cómo pueden variar estos
distintos requisitos, de modo que el
arquitecto debe trabajar hasta lograr
un diseño que se ajuste al área de
superposición.
Empresariales: Referenciado hacia
como los procesos de negocios, los
factores de rendimiento (como
seguridad, confiabilidad y capacidad
de proceso) y las restricciones de
presupuesto y costos.
1. Arquitectura orientada a
servicios (SOA) Referenciada hacia
que está apoyada en servicios.
Tenga presente: Un servicio es una
representación lógica de una
actividad de negocio que tiene un
resultado de negocio específico
(ejemplo: comprobar el crédito de un
cliente, obtener datos de los
estudiantes de la universidad,
Establecer reportes del clima,
consolidar reportes de perforación)
2. Arquitectura de modelo-
vista-controlador: Referenciado
hacia el conocido patrón MVC, divide
una aplicación interactiva en 3
partes:
Modelo: Referenciado hacia que
contiene la funcionalidad y los datos
básicos
Vista: Referenciado hacia que
muestra la información al usuario (se
puede definir más de una vista)
Controlador: Referenciado hacia que
maneja la entrada del usuario
Referenciado hacia el patrón
consiste en dos partes; un servidor y
múltiples clientes. El componente
del servidor proporcionará servicios
a múltiples componentes del cliente.
Los clientes solicitan servicios del
servidor y el servidor proporciona
servicios relevantes a esos clientes.
Además, el servidor sigue
escuchando las solicitudes de los
clientes.
4. Arquitectura capas: Para el
caso de cuatro capas Las 4 capas
más comúnmente encontradas de
un sistema de información general
son las siguientes.
Capa de presentación (también
conocida como capa UI)
Capa de aplicación (también
conocida como capa de servicio)
Capa de lógica de negocios
(también conocida como capa de
dominio)
Capa de acceso a datos (también
conocida como capa de
persistencia)
 GUIA CONCEPTOS BASICOS Preparado por: Salatiel Moreno Toro 2019 A
CALIDAD DEL SOFTWARE
Confiabilidad: Referenciado hacia el
grado en que se esperaría que un
programa desempeña su función con
la precisión requerida. El grado en
que se puede esperar que un
producto de software lleve a cabo
sus funciones esperadas con la
precisión requerida.
Corrección: Referenciado hacia el
grado en que el programa cumple
con su especificación y satisfacer los
objetivos que propuso el cliente. El
grado en que un producto de
software satisface sus
especificaciones y consigue los
objetivos de la misión encomendada
por el usuario.
Eficiencia: Referenciado hacia la
cantidad de código y de recursos de
cómputo necesarios para que un
programa realice su función. La
cantidad de recursos
computacionales y de código
requeridos por un producto de
software para llevar a cabo las
funciones encomendadas.
Facilidad de interoperación:
Referenciado hacia el esfuerzo
requerido para lograr que un
producto de software trabaje con
otro, compartiendo recursos.
Facilidad de mantenimiento:
Referenciado hacia el esfuerzo
necesario para localizar y corregir un
error en un programa. El esfuerzo
necesario para localizar y corregir los
errores en un producto de software.
CALIDAD DEL SOFTWARE
Facilidad de prueba: Referenciado
hacia el esfuerzo requerido para
probar un producto de software, de
tal forma que se asegure que realiza
las funciones especificadas por el
usuario.
Facilidad de reutilización:
Referenciado hacia el grado en que
un programa o partes de él pueden
reutilizarse en otras aplicaciones (en
relación con el empaquetamiento y
el alcance de las funciones que
realiza el programa).
Facilidad de uso: Referenciado hacia
el esfuerzo necesario para aprender,
operar y preparar los datos de
entrada de un programa interpretan
la salida. El esfuerzo requerido para
aprender, trabajar, preparar la
entrada e interpretar la salida de un
producto de software.
CALIDAD DEL SOFTWARE
Flexibilidad: Referenciado hacia el
esfuerzo que demanda probar un
programa con el fin de asegurar que
realiza su función. El esfuerzo
requerido para modificar un
producto de software una vez que
se encuentra ya liberado o en
producción, esto es, una vez que el
usuario esté haciendo uso de él.
Integridad: Referenciado hacia el
grado de control sobre el acceso al
software o los datos por parte de las
personas no autorizadas. El grado en
que puede controlarse (facilitar y
restringir) el uso y acceso al
software y a los datos, tanto al
personal autorizado como al no
autorizado.
Interoperabilidad: Referenciado
hacia el esfuerzo necesario para
acoplar un sistema con otro.
Portabilidad: Referenciado hacia el
esfuerzo necesario para transferir el
programa de un entorno de
hardware o software a otro. El
esfuerzo requerido para transferir
un producto de software de una
plataforma (entorno de hardware y
software) a otra.
Reusabilidad. Referenciado hacia el
grado en que un producto de
software (o alguna de sus partes)
pueda volver a ser utilizado en otras
aplicaciones, aun cuando la
funcionalidad de la misma cambie.
 GUIA CONCEPTOS BASICOS Preparado por: Salatiel Moreno Toro 2019 A
METRICAS PARA EL DESARROLLO DEL
SOFTWARE
Propósito: Referenciado hacia la
comparación de procesos o 1.Métricas para el modelo de
productos entre sí en la búsqueda de
optimizar la calidad del software.
En gestión de proyectos: sirven para
llevar la productividad del personal,
evaluar la calidad del producto,
mejorar el proceso de desarrollo,
servir de base de estimación,
controlar los riesgos potenciales,
entre otros.
En desarrollo de software: Se
pueden utilizar para controlar la
calidad del producto y la
productividad. Pueden ser
clasificadas según el tamaño, la
funcionalidad y otras medidas.
Principios o actividades a o el grado en que se ha completado
desarrollar:
1. Formulación: Referenciado hacia
la derivación de medidas y métricas
apropiadas para la representación
del software que se considera.
2. Recolección: Referenciado hacia el
mecanismo con que se acumulan los
datos necesarios para derivar las
métricas formuladas.
3. Análisis: Referenciado hacia el
cálculo de las métricas y la aplicación
de herramientas matemáticas.
4. Interpretación: Referenciado
hacia la evaluación de las métricas en
un esfuerzo por conocer mejor la
calidad de la representación.
5. Retroalimentación:
Referenciada hacia las
recomendaciones derivadas de la
interpretación de las métricas del
producto transmitidas al equipo del
software.
METRICAS PARA EL DESARROLLO DEL
SOFTWARE
TIPOLOGIA DE LAS METRICAS
análisis. Referenciado hacia la
atención de varios aspectos de la
etapa de análisis en donde se
incluyen:
Funcionalidad entregada.
Proporciona una medida indirecta de
la funcionalidad que se empaqueta
con el software.
Tamaño del sistema. Mide el tamaño
general del sistema, definido desde
el punto de vista de la información
disponible como parte del modelo de
análisis.
Calidad de la especificación.
Proporciona un indicador específico
la especificación de los requisitos.
2. Métricas para el modelo de
diseño. Estas métricas cuantifican los
atributos del diseño de manera tal
que le permiten al ingeniero de
software evaluar la calidad del
diseño, la métrica incluye:
Métricas arquitectónicas:
Referenciado hacia que
proporcionan un indicio de la calidad
del diseño arquitectónico.
Métricas al nivel de componente:
Referenciado hacia que mide la
complejidad de los componentes del
software y otras características que
impactan la calidad.
Métricas de diseño de la interfaz:
Referenciado hacia que se
concentran principalmente en la
facilidad de uso.
Métricas especializadas en diseño
orientado a objetos: Referenciado
hacia que miden características de
clases, además de las
correspondientes a comunicación y
colaboración.
METRICAS PARA EL DESARROLLO DEL
SOFTWARE
3. Métricas para el código fuente:
Referenciado hacia la medición del
código fuente y se usan para evaluar
su complejidad, además de la
facilidad con que se mantiene y
prueba entre otras características
como:
Métricas de complejidad:
Referenciado hacia que miden la
complejidad lógica del código
fuente.
Métricas de longitud: Referenciado
hacia que proporcionan un indicio
del tamaño del software.
4.Métricas para pruebas. Estas
métricas ayudan a diseñar casos de
prueba efectivos y evaluar la eficacia
de las pruebas en donde se incluyen:
Métricas de cobertura de
instrucciones y ramas: Referenciado
hacia que lleva al diseño de casos de
prueba que proporcionan cobertura
del programa.
Métricas relacionadas con los
defectos: Referenciado hacia que se
concentran en encontrar defectos y
no en las propias pruebas.
Efectividad de la prueba.
Proporciona un indicio en tiempo
real de la efectividad y de las
pruebas aplicadas.
Métricas en el proceso:
Referenciado con el proceso de las
pruebas.
 GUIA CONCEPTOS BASICOS Preparado por: Salatiel Moreno Toro 2019 A
LAS PRUEBAS EN DESARROLLO DE
SOFTWARE
Pruebas estáticas: Referenciado
hacia el tipo de pruebas que se
realizan sin ejecutar el código de la
aplicación. Puede referirse a la
revisión de documentos, ya que no
se hace una ejecución de código.
Esto se debe a que se pueden
realizar "pruebas de escritorio" con
el objetivo de seguir los flujos de la
aplicación.
Pruebas dinámicas: Referenciado
hacia todas aquellas pruebas que
para su ejecución requieren la
ejecución de la aplicación.
Las pruebas dinámicas permiten el
uso de técnicas de caja negra y caja
blanca con mayor amplitud. Debido a
la naturaleza dinámica de la
ejecución de pruebas es posible
medir con mayor precisión el
comportamiento de la aplicación
desarrollada.
Prueba unitaria: Referenciado hacia
la forma de comprobar el correcto
funcionamiento de una unidad de
código. Por ejemplo en diseño
estructurado o en diseño funcional
una función o un procedimiento, en
diseño orientado a objetos una clase.
Pruebas integrales o pruebas de
integración: Referenciado hacia las
pruebas que una vez que se han
aprobado las pruebas unitarias y lo
que prueban es que todos los
elementos unitarios que componen
el software, funcionan juntos
correctamente probándolos en
grupo. Se centra principalmente en
probar la comunicación entre los
componentes y sus comunicaciones
ya sea hardware o software.
LAS PRUEBAS EN DESARROLLO DE
SOFTWARE
Pruebas de humo: Referenciado a las
pruebas que pretenden evaluar la
calidad de un producto de software
previo a una recepción formal, ya sea
al equipo de pruebas o al usuario
final, es decir, es una revisión rápida
del producto de software para
comprobar que funciona y no tiene
defectos que interrumpan la
operación básica del mismo.
Pruebas alpha: Referenciado hacia
las realizadas cuando el sistema está
en desarrollo y cuyo objetivo es
asegurar que lo que estamos
desarrollando es probablemente
correcto y útil para el cliente. Por
ejemplo, podríamos desarrollar un
prototipo de una parte del sistema
que no estamos seguros de cómo
implementar la interfaz.
Pruebas Beta: Referenciado hacia
que se realizan cuando el sistema
está teóricamente correcto y pasa a
ejecutarse en un entorno real. Es la
fase siguiente a las pruebas Alpha.
Pruebas caja blanca: Referenciado
hacia que se hacen sobre las
funciones internas de un módulo.
Pruebas de caja negra: Referenciado
hacia que ejercitan los requisitos
funcionales desde el exterior del
módulo, están dirigidas a las
funciones internas.
GUIA CONCEPTOS BASICOS Preparado por: Salatiel Moreno Toro 2019 A