2.
ELEMENTOS CLAVE EN EL SISEO DE SOFTWARE
Se tiene que tener en cuenta a la hora de disear software una serie
de principios clave.
2.1. Concurrencia.
Cmo repartir el software en procesos, tareas o hilos de ejecucin
y abordar los problemas de eficiencia, atomicidad, sincronizacin
y planificacin.
2.2. Control y Manejo de Eventos.
Cmo organizar datos y flujo de control.
Cmo manejar eventos reactivos y temporales: mediante
mecanismos como invocacin implcita o llamadas hacia atrs
(callbacks).
2.3. Distribucin de componentes.
Cmo distribuir el software en el hardware.
Cmo comunicar los componentes.
Cmo utilizar el middleware para tratar
heterogneo.
con
software
2.4. Manejo de Errores y Excepciones y Tolerancia a Fallos
Cmo prevenir y tolerar
excepcionales (no previstas).
fallos
tratar
condiciones
2.5. Interaccin y Presentacin.
Cmo estructurar y organizar las interacciones con el usuario y
la presentacin de informacin. Ej.: separando la presentacin
de la lgica de negocio usando la aproximacin MVC (ModeloVista-Controlador).
2.6. Persistencia de Datos.
Cmo se manejan los datos que tienen una vida superior e
independiente a las ejecuciones del software.
4. ELEMENTOS CLAVE EN EL SISEO DE SOFTWARE
4.1. Atributos de calidad.
Performance
La habilidad del sistema para ejecutar en forma predecible dentro del
perfil de performance
definido (y la capacidad para procesar volmenes incrementados de c
arga)
Esto incluye:
Tiempo de respuesta
Latencias y throughputs
Picos de carga
Cuellos de botella
Para lograrlo se dispone del uso de las siguientes tcticas
Demanda de Recursos:
Aumentar la eficiencia del tiempo de computacin: Al recibir
un gran flujo de informacin, que incluye todos los aspectos
del sistema y a la vez estos influyen entre s. Se debe
proveer un bajo tiempo de computacin para evitar cuellos
de botella en el proceso.
Reducir sobrecarga computacional: Cada llamada a una
funcin implica un gasto de tiempo, reusar y redefinir
mtodos permitir reducir el tiempo de computacin.
Gestin de tasa de eventos: Un manejo adecuado de los
eventos, permitir la reduccin de peticiones a los mismos
recursos y datos. Adems de evitar conflictos entre tares del
sistema.
Control de la frecuencia de muestreo: Obtener muestras de
funcionamiento puede servir para detectar bugs o errores,
ms un control adecuado de la cantidad de veces que se
realice el proceso en tiempo real permitir reducir
significativamente la cantidad de recursos y tiempo que
puede llevar.
Manejo de Recursos:
Introducir concurrencia
Mantener copias mltiples: Tanto en la base de datos, como
en el resto de sistema, debe asegurarse que no haya
prdidas de datos por accidentes, errores tcnicos, errores
humanos o ataques externos.
Aumentar los recursos disponibles: Disponer de mejores
recursos, tanto de hardware como de software, a largo plazo
mejorara el sistema. Ms esto deber realizarse despus de
una implantacin exitosa.
Arbitraje de recursos:
Poltica de planificacin: El equipo de trabaja deber tener en
cuenta las prioridades del sistema, y as asignar importancia
a los diferentes mdulos para poder realizar un trabajo
adecuado y ordenado.
Disponibilidad
La habilidad del sistema de estar completa o parcialmente
operacional cuando se lo requiera (y para gestionar
efectivamente fallas que puedan afectar su disponibilidad)
Esto incluye:
Clases de servicios (QoS)
Tiempo fuera planeado
Tiempo de Recuperacin
Tasa de fallas
Recuperacin de desastres.
Para lograrlo se dispone del uso de las siguientes tcticas
Seguridad
La habilidad de un sistema para controlar, monitorear y auditar en
forma confiable quin puede realizar qu acciones sobre el sistema y
sus recursos, y la habilidad para detectar y recobrar de fallas en los
sistemas de seguridad.
Esto incluye:
Polticas
Amenazas
Disponibilidad
Deteccin de ataques
Recuperacin de ataques
Para lograrlo se dispone del uso de las siguientes tcticas
Otorgar el mnimo necesario de privilegios.
Asegurar los puntos ms dbiles detectados, de tal forma
que no puedan ser explotados.
No confiar en la oscuridad.
Usar valores por omisin seguros.
Fallar en forma segura en condiciones de pruebas o no.
Asumir que las entidades externas no son seguras.
Auditar eventos sensitivos.
Autenticar los principales usuarios y desarrolladores.
Autorizar acceso de forma limpia.
Asegurar confidencialidad de la informacin.
Asegurar integridad de la informacin.
Usabilidad
La facilidad con la cual las personas interactan con la aplicacin en
forma efectiva, y sobre como el sistema provee soporte al usuario en
este sentido.
Esto incluye:
Interfaz de usuario
Proceso de negocio
Calidad de la informacin
Alineamiento de capacidad de usuario con interfaz.
Crecimiento de productividad acorde a aprendizaje en el uso.
Para lograrlo se dispone del uso de las siguientes tcticas
Ejecucin
Hacer buen uso de Human vs Computer initiative
Modelo del usuario
Informacin sobre el conocimiento del usuario que sirve para
saber qu tipo de respuesta ste espera.
Modelo de la tarea
Informacin sobre el contexto del proceso que sirve para
acotar las acciones posibles que puede realizar en ese
momento el usuario.
Modelo del sistema
Informacin sobre la actividad que el sistema
ejecutando y que es relevante para el usuario.
est
Tiempo de diseo
Separar interfaz del resto del sistema
Modificabilidad
La habilidad del sistema para ser flexible frente a cambios inevitables
durante su desarrollo y luego del despliegue. (En balance es el costo
de construccin dentro de estos trminos versus el costo de cambio).
Esto incluye:
Probabilidad de cambio
Magnitud y dimensin de cambio
Costo del cambio
Complejidad del cambio
Conservacin del conocimiento de la solucin
Confiabilidad del cambio
Para lograrlo se dispone del uso de las siguientes tcticas
Localizar modificaciones (mdulos afectados)
Generalizacin
Coherencia Semntica
Anticipar cambios
Limitar opciones
Prevenir efecto de propagacin de cambios
Ocultar informacin
Conservar interfaces
Restringir caminos posibles de comunicacin
Usar intermediarios
Establecer contratos
Posponer momento de binding
Runtime / Configuration / Component replacement
4.2. Tecnicas
anlisis:
de
evaluacin
calidad
de
Existen varios tipos de tcnicas para la evaluacin, en el proyecto se
utilizaran las pruebas dinmicas para comprobar el estado del
software y puesto que en el desarrollo se seguirn usando se
explicaran brevemente aqu. Y pruebas estticas para la evaluacin
del desarrollo del proyecto, en la que se usara principalmente
auditorias.
Tcnicas de evaluacin esttica
Las tcnicas de Evaluacin esttica de artefactos del desarrollo se las
conoce de modo genrico por Revisiones. Las revisiones pretenden
detectar manualmente defectos en cualquier producto del desarrollo.
Por manualmente queremos decir que el producto en cuestin (sea
requisito, diseo, cdigo, etc.) est impreso en papel y los revisores
estn analizando ese producto mediante la lectura del mismo, sin
ejecutarlo.
Auditorias.
Las auditorias contrastan los artefactos
generados durante el desarrollo con estndares, generales o
de la organizacin. Tpicamente pretenden comprobar
formatos de documentos, inclusin de toda la informacin
necesaria, etc. Es decir, no se tratan de comprobaciones
tcnicas, sino de gestin o administracin del proyecto.
Tcnicas de evaluacin dinmica
PRUEBAS UNITARIAS
La prueba de unidad es la primera fase de las pruebas dinmicas y se
realizan sobre cada mdulo del software de manera independiente. El
objetivo es comprobar que el mdulo, entendido como una unidad
funcional de un programa independiente, est correctamente
codificado. En estas pruebas cada mdulo ser probado por separado
y lo har, generalmente, la persona que lo creo. En general, un
mdulo se entiende como un componente software que cumple las
siguientes
Debe ser un bloque bsico de construccin de programas.
Debe implementar una funcin independiente simple.
Podr ser probado al cien por cien por separado.
No deber tener ms de 500 lneas de cdigo.
Tanto las pruebas de caja blanca como las de caja negra han de
aplicarse para probar de la manera ms completa posible un mdulo.
Pruebas de Caja Blanca y negra.
4.3. Mtricas
El proyecto se realizar siguiendo las mtricas y metodologa de su
clculo, establecido por el estndar ISO/IEC 9126, el que se describe
brevemente a continuacin.
ISO 9126 es un estndar internacional para la evaluacin del
Software, fue originalmente desarrollado en 1991 para proporcionar
un esquema para la evaluacin de calidad del software.
La normativa define seis caractersticas de la aplicacin, estas seis
caractersticas son dividas en un nmero de sub- caractersticas, las
cuales representan un modelo detallado para la evaluacin de
cualquier sistema informtico.
Caractersticas norma ISO/IEC 9126
El modelo establece diez caractersticas, seis que son comunes a las
vistas interna y externa y cuatro que son propias de la vista en uso.
A continuacin se describen las caractersticas y subcaractersticas
propias de este estndar que se encuentran dentro de las vistas
interna y externa, las cuales usaremos para evaluar el software.
Funcionalidad: capacidad del software de proveer los servicios
necesarios para cumplir con los requisitos funcionales.
Subcaractersticas:
Idoneidad.- Hace referencia a que si el software desempea las tareas
para las cuales fue desarrollado.
Exactitud.- Evala el resultado final que obtiene el software y si tiene
consistencia a lo que se espera de l.
Interoperabilidad.- Consiste en revisar si el sistema puede interactuar
con otro sistema independiente.
Seguridad.- Verifica si el sistema puede impedir el acceso a personal
no autorizado.
Fiabilidad: capacidad del software de mantener las prestaciones
requeridas del sistema, durante un tiempo establecido y bajo un
conjunto de condiciones definidas.
Subcaractersticas:
Madurez.- Se debe verificar las fallas del sistema y si muchas de estas
han sido eliminadas durante el tiempo de pruebas o uso del sistema.
Recuperabilidad.- Verificar si
el software puede
reasumir el
funcionamiento y restaurar datos perdidos despus de un fallo
ocasional.
Tolerancia a fallos.- Evalua si la aplicacin desarrollada es capaz de
manejar errores.
Usabilidad: esfuerzo requerido por el usuario para utilizar el
producto satisfactoriamente.
Subcaractersticas:
Aprendizaje.- Determina que tan fcil es para el usuario aprender a
utilizar el sistema.
Comprensin.- Evala que tan fcil es para el usuario comprender el
funcionamiento del sistema
Operatividad.- Determina si el usuario puede utilizar el sistema sin
mucho esfuerzo.
Atractividad.- Verifica que tan atractiva se ve la interfaz de la
aplicacin.
Eficiencia: relacin entre las prestaciones del software y los
requisitos necesarios para su utilizacin.
Subcaractersticas:
Comportamiento en el tiempo.- Verifica la rapidez en que responde el
sistema
Comportamiento de recursos.- Determina si el sistema utiliza los
recursos de manera eficiente
Mantenibilidad: esfuerzo necesario para adaptarse a las nuevas
especificaciones y requisitos del software.
Subcaractersticas:
Estabilidad.- Verifica si el sistema puede mantener su funcionamiento
a pesar de realizar cambios.
Facilidad de anlisis.- Determina si la estructura de desarrollo es
funcional con el objetivo de diagnosticar fcilmente las fallas.
Facilidad de cambio.- Verifica si el sistema puede ser fcilmente
modificado
Facilidad de pruebas.- .- Evala si el sistema puede ser probado
fcilmente
Portabilidad: capacidad del software ser transferido de un
entorno a otro.
Subcaractersticas:
Capacidad de instalacin.- Verifica si el software se puede instalar
fcilmente
Capacidad de reemplazamiento.- Determina la facilidad con la que el
software puede remplazar otro software similar.
Adaptabilidad.- El software se puede trasladar a otros ambientes
Co-Existencia.- El software puede funcionar con otros sistemas
Cada una de las caractersticas debe ser evaluada dentro del software
basndonos en pruebas de funcionamiento, medicin de rendimiento
y pruebas con usuarios que harn uso del sistema.
6. ESTRATEGIAS Y METODOS DEL DISEO DE SOFTWARE
La construccin final del producto depender del anlisis y el diseo
redactado aqu, es por eso que para determinar qu tipo diseo se usara se
analizara los recursos disponibles, antes y ahora mencionados.
Puntos a considerar en la generacin de alternativas de estrategias
de diseo
Seleccin de software off-the-shelf. Cuando se piensa comprar un
software off-the-shelf, hay que comparar el paquete de software y el
proceso de desarrollo de la misma aplicacin en casa, segn los
siguientes criterios: costo, funcionalidad, soporte del vendedor,
viabilidad del vendedor, flexibilidad, documentacin, tiempo de
respuesta y facilidad de instalacin. Adems, hay que recurrir a
mtodos cuantitativos cuando se comparan distintos paquetes de
software. Es por eso que mediante el anlisis actual se puede
determinar que con el uso de software libre, se reducirn costes y se
ahorrara tiempo que en cambio se perdera en el desarrollo propio
Hardware y software. Es necesario determinar si la plataforma de
hardware y software existente en la organizacin soporta el nuevo
sistema o si es necesario realizar mejoras de hardware y/o adquisicin
de software (manejador de bases de datos, lenguajes de
programacin, sistemas operativos, software de red, generador de
cdigo, entre otros). Esto tiene que ser parte esencial de las
alternativas de estrategias de diseo.
Implementacin. Es necesario tener en cuenta los aspectos tcnicos y
sociales de la implementacin del nuevo si como parte de las
alternativas de estrategias de diseo. Los gerentes y los usuarios
deben conocer qu tiempo tomar a implementacin, qu
entrenamiento se requerir, cmo ser el impacto en los procesos,
qu nuevas habilidades sern necesarias, qu tan doloroso ser el
proceso.
Organizacionales. El costo (financiero y humano), la forma en que la
gerencia ser soportada y, la aceptacin y uso que le darn los
usuarios al nuevo si, son temas que las alternativas de estrategias de
diseo no pueden dejar fuera. No hay que olvidar que el sistema a
desarrollar est inmerso dentro de una organizacin y que sta
influye directamente sobre el uso y aprovechamiento del sistema, as
como el funcionamiento de ste influye en el desempeo de la
organizacin.
Un anlisis de lo anteriormente expuesto lleva a pensar en el uso de
una metodologa gil, y con mdulos perfectamente definidos, debido
a que el software recibir un gran flujo de datos y realizara tareas
simultaneas muy seguido.
La metodologa orientada a objetos ser la adecuada para la
realizacin del software.
