1. UNIVERSIDAD REGIONAL AUTONOMA DE
LOS ANDES
UNIANDES
SISTEMAS MERCANTILES
SISTEMAS
Nombre: José Luis Salazar
Nivel : 6° Sistemas

2. Desarrollo de software orientado a
la web.
 Desarrollo web es un título algo arbitrario para el conjunto de
tecnologías de software del lado del servidor y del cliente que
involucran una combinación de procesos de base de datos con el uso de
un navegador en Internet a fin de realizar determinadas tareas o
mostrar información. Wikipedia, por ejemplo, ha sido realizada por
desarrolladores web.
 Tradicionalmente un software departamental o incluso un ambicioso
proyecto corporativo de gran envergadura es desarrollado en forma
standalone, es decir, usando lenguajes ya sea compilados(C, C++,
Delphi), semicompilados(.NET, Mono, Java), o interpretados (Python)
para crear tanto la funcionalidad como toda la interfaz de los usuarios,
pero cabe perfectamente un desarrollo orientado a web para dichos
propósitos, siendo más homogéneo y multiplataforma, y dependiendo
de las tecnologías utilizadas, más rápido y robusto tanto para diseñar,
implementar y probar, como para su uso una vez terminado.

3. Fases de un proyecto de desarrollo
de software orientado a la web.
Por lo que respecta al proceso de autoría de la aplicación,UWE hace un uso
exclusivo de estándares reconocidos como UMLy el lenguaje de especificación de
restricciones asociado OCL. Parasimplificar la captura de las necesidades de las
aplicaciones web,UWE propone una extensión que se utiliza a lo largo del proceso
deautoría. Este proceso de autoría está dividido en cuatro pasos o
actividades:
 Análisis de Requisitos: Fija los requisitos funcionales de la aplicación Web para
reflejarlos en un modelo de casos de uso.
 Diseño Conceptual: Materializado en un modelo de dominio, considerando los
requisitos reflejados en los casos de uso.
 Diseño Navegacional: Lo podemos subdividir en :
􀂄 Modelo del Espacio de Navegacional.
􀂄 Modelo de la Estructura de navegación: Muestra la forma de navegar ante el
espacio de navegación.
 Diseño de Presentación: Representa las vistas del interfaz del usuario
mediante modelos estándares de interacción UML.

4. Medida de la calidad de un
software para la web.
 Para evaluar la calidad de un software de ámbito web es
necesario considerar sus:
 Cualidades Externas (se refieren a factores esperables que son
útiles o aprovechables por los usuarios finales de un sistema)
 Cualidades Internas (aquellas que permitirán una labor
sencilla, productiva, ordenada, y eficiente, a los desarrolladores
del sistema, o a quienes deseen re-programarlo, mantenerlo, etc)
 Hay 16 atributos básicos de valoración esperables en la calidad
de las aplicaciones web a medida . Es importante conocerlos y
exigirlos como estándares que deben cumplir los programadores
o desarrolladores de aplicaciones a medida.
 A continuación un detalle de los mismos:

5. RESPUEST
CUALIDAD IMPORTANCIA PREGUNTAS PARA EVALUAR EL ATRIBUTO
A
•¿al someter al programa a diversas tareas básicas, cumple este el/los requerimiento/s del/los usuario/s?
Correctitud fundamental si / no
•¿realiza las tareas de manera tal que el resultado de las mismas sea correcto?
•¿es sencillo de entender y manejar el software para los usuarios a los cuales está destinado su uso?
•¿es intuitivo, y posee la información y ayudas adecuadas como para que el usuario no tenga que depender de
alguien que explique cómo utilizar cada función?
Usabilidad fundamental si / no
•¿son cómodos los menúes, los botones, las ventanas de interfaces, los cuadros de diálogo, los formularios,
etc?¿las jerarquías visuales son correctas?
•¿es sencillo buscar y filtrar información dentro del programa?
•¿el software puede ser (o ha sido) entregado en tiempo y forma por sus desarrolladores?
•¿pueden los desarrolladores establecer tiempos razonables de trabajo en relación a la complejidad del mismo?
Oportunidad y
fundamental •¿es capaz de ser desarrollado óptimamente sin utilizar más recursos que los previstos (presupuesto estimado)? si / no
Economía
•¿es capaz el desarrollador de establecer un precio justo de desarrollo, implementación y soporte, previsiblemente
amortizable según su productividad, y no inflado en relación al estándar del mercado?

6. •¿posee el proyecto una buena documentación interna y externa (del
código fuente, y de la ayuda al usuario). (esto está relacionado a otros
Documentación y Visibilidad esperable factores, como la usabilidad y la comprensibilidad). si / no
•¿Hay transparencia hacia afuera en las etapas de desarrollo (ciclo de
vida), están documentadas y disponibles para el cliente?
•¿puede interactuar el software con otras aplicaciones que
complementan tareas, o procesos que necesita abarcar el usuario?
Compatibilidad esperable •¿sus reportes y datos están en archivos compatibles con aplicaciones de si / no
uso común y popular (por ejemplo planillas de excel, que es el estandar
de las hojas de cálculo)?
•¿es amigable el software para los desarrolladores?
Comprensibilidad esperable •¿pueden comprender su estructura lógica, sus funciones de ejecución y si / no
procesamiento, su código fuente es fácilmente legible y comprensible?

7. •¿es confiable el software para el usuario final?
•¿después de un buen periodo de uso: sucede a veces que el usuario
“desconfía” porque en ocasiones anteriores ha perdido datos
abilidad fundamental si / no
importantes que le ha llevado tiempo cargar?
•¿cuándo falla, son fallas graves o leves, según las consecuencias que
provocan?
•cuando el volumen de datos crece dentro de lo contemplado, ¿el
software se vuelve lento?
•¿es capaz el software de procesar/almacenar datos de manera
Eficiencia fundamental si / no
eficiente?
•¿comienza a insumir muchos recursos de hardware?
•¿se ve afectada la productividad de los usuarios por esta lentitud?
•Escalabilidad funcional: ¿es sencillo y relativamente breve
implementar al software nuevas funcionalidades y servicios, a
Escalabilidad esperable medida que surgen nuevos requerimientos? (legibilidad, si / no
comprensibilidad, documentación).
•Escalabilidad por crecimiento en volumen de datos: (ver eficiencia)
•¿hay operaciones que el software podría realizar internamente y sin
embargo hay que hacerlas “a mano” o en otras aplicaciones?
•¿son muy limitadas o incompletas las funciones que realiza el
Funcionalidad fundamental si / no
software?
•¿resuelve casi todos los problemas de operatividad y gestión de la
información?

8. •Reparabilidad: ¿es sencillo corregir errores del software (bugs o
funcionalidades mal definidas)? (esto depende del grado de
modularidad del software) si el software es modular se aísla
problemas fácilmente y se gana tiempo encontrando y
corrigiendo errores.
•Flexibilidad: ¿es sencillo hacer adaptaciones cuando se alteran
ntenibilidad fundamental/esperable levemente los requerimientos iniciales? ¿es sencillo adaptar el si / no
software si se modifica su entorno de aplicación, si se actualiza el
sistema operativo o el hardware?
•Evolucionabilidad: ¿es sencillo perfeccionar el software en un
proceso evolutivo viable?
•Extensibilidad: ¿es sencillo extender el software hacia nuevas
funcionalidades sin tener que modificar el código “existente”?
•¿el software es portable a diferentes sistemas operativos y
plataformas?
Portabilidad esperable •¿es sencillo "trasladar" el software de una intranet a otra, o de un si / no
dominio/servidor a otro sin mayores problemas, y configurando
tan solo unos pocos parámetros?
•¿el sistema, se “cae” muy a menudo?
•¿es preciso inhabilitarlo por mucho tiempo cada vez que hay
Disponibilidad / Recuperabilidad fundamental que hacer tareas de mantenimiento? si / no
•¿cuánto tiempo demora el sistema en “arrancar” hasta su estado
funcional?
Reusabilidad esperable ¿es el código fuente del software, reusable? si / no
¿reacciona bien el sistema ante situaciones o casos no previstos o
Robustez esperable si / no
no contemplados en los requerimientos?

9. Las pruebas de un software de tipo
web
 PRUEBAS DE SOFTWARE EN APLICACIONES WEB
 En el caso de las aplicaciones web, además de las pruebas tradicionales, es necesario comprobar el funcionamiento del
servidor web, SGBD, red y el conjunto del sistema. Tanto de manera funcional como realizando un test de carga para
comprobar la capacidad del mismo.
 En este caso, algunas herramientas básicas para el desarrollador son:
 HERRAMIENTAS DE VALIDACIÓN DE CÓDIGO HTML/CSS
 No conviene olvidar que en las aplicaciones web la comunicación entre el servidor y el cliente se realiza mediante
HTML/CSS. Una cuestión fundamental para garantizar que el cliente va a poder representar la interfaz de la aplicación
de la manera correcta es que los datos que el servidor envía sean válidos. Por ello, en cualquier aplicación web se deberá
validar todo el HTML/CSS transmitido al cliente.
 Para ayudar en dicha tarea se pueden utilizar diferentes validadores como el del W3C
 HERRAMIENTAS PARA PONER A PRUEBA EL SERVICIO
 En una aplicación web es vital conocer la capacidad del sistema en cuanto a número de clientes y concurrencia de los
mismos. Por ello resulta necesario simular un enjambre de clientes que ponga a prueba la aplicación para poder valorar
su rendimiento, o que realice en ella ciertas operaciones que se quieren poner a prueba.
 ApacheBench (comando ab) es un pequeño programa que acompaña a la distribución de Apache y permite realizar
peticiones de forma repetida y concurrente para valorar el rendimiento del mismo.
 Otra opción más compleja es JMeter, en este caso es posible probar aplicaciones web y también otros protocolos (ftp,
ldap, jdbc, la aplicación es extensible mediante plugins). No solo se puede generar carga para el servidor y valorar el
tiempo de respuesta, sino que se puede realizar un completo plan de prueba que incluya pruebas unitarias (validando
la respuesta del servidor) o simulando determinado comportamiento de los usuarios.
 Herramientas en el navegador
 Por último, un desarrollador web también suele utilizar extensiones para el navegador (como Firebug para Firefox) que
permiten inspeccionar con detalle la respuesta recibida por el agente de usuario. Mostrando todo tipo de información
relativa a la red, rendimiento y elementos de la respuesta.