Embed Size (px)
Citation preview
Universidad Nacional Experimental
De los Llanos Occidentales
“Ezequiel Zamora”
Barinas. Estado. Barinas
Barinas, Febrero de 2014
BACHILLERES:
RIVERO JENNY C.I. 24774554
TORRES KENNYMAR C.I.23023059
SUBPROYECTO: METODOLOGIA DEL
SOFTWARE.
PROFESOSRA: DAJERLING SILVA.
SECCION: 01G1D
DEFINICIÓN
ANALISIS DEL SISTEMA
Ámbito del software
¿Qué es Xataka?
Es un WebLog corporativo, que fusiona ámbitos web de información pura con gran
cantidad de temas diversos, la función de Xataka es de una web tecnológica informativa, lo
temas de Xataka son exclusivamente tecnológicos.
XATAKA ANTES XATAKA AHORA
Tomado de: http://www.xatakaciencia.com/xatakaciencia/asi-es-el-nuevo-xataka-y-asi-
sera-muy-pronto-xataka-ciencia
El diseño actual de Xataka viene del diseño de 2009, que, a su vez, fue una evolución del
diseño de 2007. Tres años en internet es una eternidad. Se necesitaba actualizar la
apariencia gráfica del diseño.
En el nuevo diseño de Xataka lo primero que encontraréis diferente es una cabecera más
delgada, sobre la cual encontramos la barra superior con la caja de login (ahora también te
puedes identificar con tu cuenta de Twitter). En conjunto hemos conseguido que el diseño
sea más claro y que sea más fácil hacer lecturas diagonales de la información para detectar
rápidamente qué te interesa.
En el nuevo diseño tenemos dos menús superiores, uno dedicado a las grandes categorías
temáticas y otro a las etiquetas de mayor peso y actualidad en la publicación. También
2004 2007 2009 2012
ganan protagonismo en el nuevo diseño otros elementos como la selección de mejores post
y la sección de respuestas.
El login para los usuarios registrados (o para registrarse los nuevos) lo hemos subido a la
barra de navegación entre nuestros sitios.
El rediseño está centrado en la nueva portada, con sólo cambios menores en el resto de
páginas, a excepción de la nueva página del equipo.
Análisis de requisitos del sistema software:
DEFINICIÓN DETALLADA DEL SOFTWARE
Xataka es una publicación de Weblogs SL para todos los apasionados de la tecnología. Se
ocupa tanto de contar de manera rigurosa y con pasión la actualidad tecnológica, como de
analizar en profundidad los principales lanzamientos y compararlos con otros modelos
similares. Lanzada en 2004, Xataka se ha convertido en la publicación líder en tecnología
en español, creando una comunidad de usuarios muy informados, influyentes y altamente
participativos, que supera el millón de usuarios únicos mensuales según datos de comScore.
Xataka es pasión por un futuro que ya se ha hecho realidad.
Es desarrollada por un grupo de editores y colaboradores, entre los editores están Javier
Penalva, Pablo Espeso, Kote Puerto, Juan Carlos, Javier Pastor, Jesus Maturana, R.
Martínez, Juan Carlos Lopez. Colaboradores están: Antonio Ortiz, Jaime Novoa, Ibañez,
Probertoj, Paco Rodriguez, Guillermo Juliam, Fernando Doutel, Remo, Natxo Sobrado,
Alejandro Nieto, Trikar, Lorenzo Martínez, Javi Sánchez, Marina Such, Txema Rodríguez,
Mikel Cid, Minue y Juan Lara.
Xataka está alojada en Weblogs SL que es la empresa líder en medios especializados online
en España. La principal línea de negocio de Weblogs SL es la creación de publicaciones
especializadas por temáticas. En noviembre de 2004 publican la primera, Xataka. Fue el
primer blog especializado y el primer blog con clara vocación comercial.
REQUERIMIENTOS DONDE PUEDA FUNCIONAR
En computadores los requisitos aproximados son:
- Puede funcionar en cualquier computador que cuente con conexión a internet y
tenga los complementos básicos para visualizar imágenes y videos.
En telefonía móvil los requisitos aproximados son:
- Para androide la versión del software completa está entre 2.2 y en adelante y se
almacena en un tamaño de 207k
- Para androide la versión móvil necesita de un software entre 2.2 y superiores, y su
almacenamiento es de 198k.
- Para la versión móvil, funciona en cualquier dispositivo móvil, el almacenamiento
está entre 83.1k
- Y para dispositivos que cuentan con el sistema operativo de Windows Phone su
almacenamiento estará en 73k
Planificación
ANALISIS DE RIESGOS
Al momento de realizar el cambio del diseño del WebLog el mayor riesgo tomado fue el
del rechazo de usuarios con el nuevo ámbito de la página. E incluso tuvo muchas críticas
referentes de la modificación del diseño.
Uno de los comentarios más resaltantes fue el de Julio Alonso el 27 febrero de 2012 a las
12:43:18
Un diseño peor que el que había.
Habéis pasado de tres párrafos de cuatro líneas y dieciséis palabras cada una; a un párrafo de seis líneas y
doce palabras. Mucha menos información al primer golpe de vista que es lo que te engancha.
Así que si antes te leías la entradilla de la noticia y entrabas en la noticia en caso necesario. Ahora es más
fácil perder interés y pasar de largo.
Ahora el párrafo y poco te deja a medias, te quita las ganas de abrir.
En cuanto a las imágenes. Las imágenes de las páginas antiguas hacía más atractiva la noticia. Eran más
grandes.
Era mucho más claro e impactante el diseño anterior.
Una vez abierta la noticia. La zona de publicidad e información de la izquierda es mucho mayor que antes.
Cuando lo importante es la noticia.
Podéis dar la opción de que se visualice con dos estilos de página web?
Un saludo!
Tomado de: http://www.weblogssl.com/2012/02/27-nuevo-diseno-en-xataka-2012
DEFINICION DE TAREAS
A continuación se muestran una serie de elementos correspondientes al WebLog donde sus
funciones son:
En la parte superior de la cabecera se encuentran algunos logos correspondientes al
WebLog en donde se encuentra almacenado el sitio web, allí encontraremos el inicio de
sesión por redes sociales como Facebook o Twitter; así como el registro de un nuevo
usuario y para acceder al sitio como registrado.
Esta es la cabecera del WebLog aquí se sitúa el menú de inicio el cual está compuesto por 6
casillas. En la primera donde aparece el logo de una casa es la redirección de inicio; la
segunda son respuestas a preguntas realizadas sobre temas publicados; la siguientes son
relacionadas a las noticias en diferentes secciones como de análisis, móviles, tablet y otros.
Debajo de la cabecera esta una sección especificada a mas informaciones las cuales son las
más visitadas.
En esta imagen encontramos las publicaciones hechas en la parte izquierda, aquí podemos
observar que constan de un titulo, imagen y descripción. En la parte derecha se hallan las
noticias más resaltantes y algunas de las respuestas hechas sobre los temas publicados, de
lo contrario se pueden hallar logos de publicidad.
En la parte derecha se encuentra el cuadro de preguntas a enviar sobre temas relacionados
con la página, lo cual exige estar registrado dentro del sitio.
Parte derecha se encuentran los medios por donde se puede seguir el WebLog de Xataka,
así como la suscripción vía email; para recibir boletines de informaciones nuevas o actuales
A continuación se describen en la parte superior color verde son logos correspondientes a
diferentes publicaciones hechas ubicadas en categorías, luego en la parte inferior
encontramos las diferentes extensiones de Xataka con sus respectivos logos.
En esta parte del sitio ubicada en el final del WebLog Xataka encontramos la información
relevante a ella.
Al iniciar sesión se observara en la parte superior al lado derecho el nombre del usuario y
una fotografía o icono correspondiente al perfil, el cual te indicara que ya has iniciado
sesión, en cuanto a la estructura de la pagina seguirá siendo la misma.
En esta página al dar click al nombre de usuario aparecerá un menú desplegable en el cual
se encuentra las opciones de: pagina de usuario, editar perfil y salir.
Una vez accedido a la página de usuario se mostrara esta pantalla donde encontraras tu
información así como los posts favoritos y las conversaciones.
Accedido a la página de editar perfil se mostrara esta pantalla donde encontraras tu
información y podrás modificarla.
Luego de acceder al sistema en la pestaña de respuestas podrás comentar o preguntar al
igual dar respuestas a publicaciones hechas, teniendo en cuenta que solo registrado puedes
hacer esto. A demás de esto el usuario registrado no tiene poder de subir una noticia.
Desarrollo
DISEÑO
METODOLOGIA DE DESARROLLO DEL SOFTWARE:
Según Kent Beck
La programación extrema o eXtreme Programming (XP) es una metodología de desarrollo
de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la
materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado
de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación
extrema se diferencia de las metodologías tradicionales principalmente en que pone más
énfasis en la adaptabilidad que en la previsibilidad.
La Programación Extrema es una metodología de desarrollo de software que se basa en la
simplicidad, la comunicación y la retroalimentación o reutilización del código
desarrollado.
Kent Beck, Creador de la Metodología XP
El autor de la XP, Kent Beck, que con su larga experiencia como programador eligió las
mejores características de las metodologías y profundizó en las relaciones de éstas y como
se reforzaban unas a otras. Por tanto, la XP no se basa en principios nuevos, sino que todas,
o casi todas, sus características ya se conocen dentro de la ingeniería del software, las
cuales se complementan para minimizar los tópicos problemas que pueden surgir en todo
desarrollo de proyectos software.
Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un
aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser
capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es
una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo
del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos. Se
puede considerar la programación extrema como la adopción de las mejores metodologías
de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de
manera dinámica durante el ciclo de vida del software.
LOS PASOS DE LA METODOLOGÍA XP
Según Kent Beck
Los Pasos fundamentales inmersos en las fases del método son:
- Desarrollo iterativo e incremental: Pequeñas mejoras, unas tras otras.
- Pruebas unitarias continuas: Son frecuentemente repetidas y automatizadas,
incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes
de la codificación.
- Programación en parejas: Se recomienda que las tareas de desarrollo se lleven a
cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del
código escrito de esta manera el código es revisado y discutido mientras se escribe-
es más importante que la posible pérdida de productividad inmediata.
- Frecuente integración del equipo de programación con el cliente o usuario: Se
recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
- Corrección de todos los errores: Antes de añadir nueva funcionalidad. Hacer
entregas frecuentes.
- Refactorización del código: Es decir, reescribir ciertas partes del código para
aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento.
Las pruebas han de garantizar que en la refactorización no se ha introducido ningún
fallo.
- Propiedad del código compartido: En vez de dividir la responsabilidad en el
desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el
que todo el personal pueda corregir y extender cualquier parte del proyecto. Las
frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
- Simplicidad del código: Es la mejor manera de que las cosas funcionen. Cuando
todo funcione se podrá añadir funcionalidad si es necesario. La programación
extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo
extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca
utilizarlo.
- La simplicidad y la comunicación: Son extraordinariamente complementarias.
Con más comunicación resulta más fácil identificar qué se debe y qué no se debe
hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo
que lleva a una comunicación más completa, especialmente si se puede reducir el
equipo de programadores.
FASES DE LA METODOLOGÍA XP
Según Kent Beck
1ª FASE: Planificación del proyecto.
Historias de usuario: El primer paso de cualquier proyecto que siga la metodología X.P es
definir las historias de usuario con el cliente. Las historias de usuario tienen la misma
finalidad que los casos de uso pero con algunas diferencias: Constan de 3 ó 4 líneas escritas
por el cliente en un lenguaje no técnico sin hacer mucho hincapié en los detalles; no se debe
hablar ni de posibles algoritmos para su implementación ni de diseños de base de datos
adecuados, etc. Son usadas para estimar tiempos de desarrollo de la parte de la aplicación
que describen. También se utilizan en la fase de pruebas, para verificar si el programa
cumple con lo que especifica la historia de usuario. Cuando llega la hora de implementar
una historia de usuario, el cliente y los desarrolladores se reúnen para concretar y detallar lo
que tiene que hacer dicha historia. El tiempo de desarrollo ideal para una historia de usuario
es entre 1 y 3 semanas.
Release Planning: Después de tener ya definidas las historias de usuario es necesario crear
un plan de publicaciones, en inglés "Release plan", donde se indiquen las historias de
usuario que se crearán para cada versión del programa y las fechas en las que se publicarán
estas versiones. Un "Release plan" es una planificación donde los desarrolladores y clientes
establecen los tiempos de implementación ideales de las historias de usuario, la prioridad
con la que serán implementadas y las historias que serán implementadas en cada versión del
programa. Después de un "Release plan" tienen que estar claros estos cuatro factores: los
objetivos que se deben cumplir (que son principalmente las historias que se deben
desarrollar en cada versión), el tiempo que tardarán en desarrollarse y publicarse las
versiones del programa, el número de personas que trabajarán en el desarrollo y cómo se
evaluará la calidad del trabajo realizado. (*Release plan: Planificación de publicaciones).
Iteraciones: Todo proyecto que siga la metodología X.P. se ha de dividir en iteraciones de
aproximadamente 3 semanas de duración. Al comienzo de cada iteración los clientes deben
seleccionar las historias de usuario definidas en el "Release planning" que serán
implementadas. También se seleccionan las historias de usuario que no pasaron el test de
aceptación que se realizó al terminar la iteración anterior. Estas historias de usuario son
divididas en tareas de entre 1 y 3 días de duración que se asignarán a los programadores.
La Velocidad del Proyecto: es una medida que representa la rapidez con la que se
desarrolla el proyecto; estimarla es muy sencillo, basta con contar el número de historias de
usuario que se pueden implementar en una iteración; de esta forma, se sabrá el cupo de
historias que se pueden desarrollar en las distintas iteraciones. Usando la velocidad del
proyecto controlaremos que todas las tareas se puedan desarrollar en el tiempo del que
dispone la iteración. Es conveniente reevaluar esta medida cada 3 ó 4 iteraciones y si se
aprecia que no es adecuada hay que negociar con el cliente un nuevo "Release Plan".
Programación en Parejas: La metodología X.P. aconseja la programación en parejas pues
incrementa la productividad y la calidad del software desarrollado.
El trabajo en pareja involucra a dos programadores trabajando en el mismo equipo;
mientras uno codifica haciendo hincapié en la calidad de la función o método que está
implementando, el otro analiza si ese método o función es adecuado y está bien diseñado.
De esta forma se consigue un código y diseño con gran calidad.
Reuniones Diarias: Es necesario que los desarrolladores se reúnan diariamente y expongan
sus problemas, soluciones e ideas de forma conjunta. Las reuniones tienen que ser fluidas y
todo el mundo tiene que tener voz y voto.
2ª FASE: Diseño.
Diseños Simples: La metodología X.P sugiere que hay que conseguir diseños simples y
sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un
diseño fácilmente entendible e impleméntable que a la larga costará menos tiempo y
esfuerzo desarrollar.
Glosarios de Términos: Usar glosarios de términos y un correcta especificación de los
nombres de métodos y clases ayudará a comprender el diseño y facilitará sus posteriores
ampliaciones y la reutilización del código.
Riesgos: Si surgen problemas potenciales durante el diseño, X.P sugiere utilizar una pareja
de desarrolladores para que investiguen y reduzcan al máximo el riesgo que supone ese
problema.
Funcionabilidad extra: Nunca se debe añadir funcionalidad extra al programa aunque se
piense que en un futuro será utilizada. Sólo el 10% de la misma es utilizada, lo que implica
que el desarrollo de funcionalidad extra es un desperdicio de tiempo y recursos.
Refactorizar: Es mejorar y modificar la estructura y codificación de códigos ya creados sin
alterar su funcionalidad. Supone revisar de nuevo estos códigos para procurar optimizar su
funcionamiento. Es muy común rehusar códigos ya creados que contienen funcionalidades
que no serán usadas y diseños obsoletos.
3ª FASE: Codificación.
Como ya se dijo en la introducción, el cliente es una parte más del equipo de desarrollo; su
presencia es indispensable en las distintas fases de X.P. A la hora de codificar una historia
de usuario su presencia es aún más necesaria. No olvidemos que los clientes son los que
crean las historias de usuario y negocian los tiempos en los que serán implementadas. Antes
del desarrollo de cada historia de usuario el cliente debe especificar detalladamente lo que
ésta hará y también tendrá que estar presente cuando se realicen los test que verifiquen que
la historia implementada cumple la funcionalidad especificada. La codificación debe
hacerse ateniendo a estándares de codificación ya creados. Programar bajo estándares
mantiene el código consistente y facilita su comprensión y escalabilidad.
4ª FASE: Pruebas.
Uno de los pilares de la metodología X.P es el uso de test para comprobar el
funcionamiento de los códigos que vayamos implementando. El uso de los test en X.P es el
siguiente:
Se deben crear las aplicaciones que realizarán los test con un entorno de desarrollo
específico para test.
Hay que someter a tests las distintas clases del sistema omitiendo los métodos más triviales.
Se deben crear los test que pasarán los códigos antes de implementarlos; en el apartado
anterior se explicó la importancia de crear antes los test que el código.
Un punto importante es crear test que no tengan ninguna dependencia del código que en un
futuro evaluará.
Como se comentó anteriormente los distintos test se deben subir al repositorio de código
acompañados del código que verifican.
Test de aceptación. Los test mencionados anteriormente sirven para evaluar las distintas
tareas en las que ha sido dividida una historia de usuario.
Al ser las distintas funcionalidades de nuestra aplicación no demasiado extensas, no se
harán test que analicen partes de las mismas, sino que las pruebas se realizarán para las
funcionalidades generales que debe cumplir el programa especificado en la descripción de
requisitos.
METODOLOGIA ARQUITECTONICA:
Atributos de calidad y escenarios:
Para poder evaluar una arquitectura, Bass, Clemens y Kazman, en su libro “Software
Architecture in Practice”, recogen y sistematizan seis atributos de calidad que serían
aplicables a la Arquitectura de un sistema software, permitiendo la evaluación de los
mismos y, por lo tanto, de la Arquitectura Software propuesta; en base a dicha evaluación,
esta última se podrá modificar y adaptar de acuerdo con los resultados obtenidos, lo que
permitiría corregir posibles errores mucho antes de comenzar con el ciclo de vida de
desarrollo de aplicaciones software, disminuyendo el riesgo del proyecto.
Los atributos de calidad de un sistema serían: rendimiento (performance), disponibilidad
(availability), modificabilidad (modificability), seguridad (security), facilidad de uso
(usability) y verificabilidad (testability), que son parte integrante de la propia arquitectura,
por lo que, incluirlos o añadirlos en una fase más tardía del desarrollo no sería sencillo. No
obstante, debe quedar claro, que estos atributos se definen de forma genérica, y deberán
concretarse en cada caso para la arquitectura concreta que se vaya a definir, de hecho habrá
arquitecturas que exijan más a un tipo de atributo que a otro.
En grandes sistemas, el cumplimiento de algunos de estos atributos de calidad, como por
ejemplo el comportamiento, la disponibilidad, la seguridad y la modificabilidad dependen
no solo de cómo se programe el código de los distintos módulos o componentes del sistema
(lenguaje de programación, algoritmos, estructuras de datos, pruebas), sino también, de la
arquitectura software tomada en su totalidad.
El conjunto de atributos de calidad definidos por Bass, Clements y Kazman, estos autores
proponen la utilización de Escenarios de atributos de calidad como una forma de
categorizar dichos atributos. Un Escenario (Scenario) consistiría en la definición de un
requisito específico de un atributo de calidad, que permitiría poder evaluar el sistema para
observar si lo cumple o no. De esta forma, podríamos formular los requisitos del sistema y
evaluarlos sobre una arquitectura determinada, antes de dar comienzo al diseño y desarrollo
propiamente dichos.
ESTILO ARQUITECTÓNICO:
CENTRALIZADO EN DATOS
Esta familia de estilos enfatiza la integrabilidad de los datos. Se estima apropiada para
sistemas que se fundan en acceso y actualización de datos en estructuras de
almacenamiento. Sub-estilos característicos de la familia serían los repositorios, las bases
de datos, las arquitecturas basadas en hipertextos y las arquitecturas de pizarra.
Un almacén de datos se encuentra en el centro de esta arquitectura, otro componente tiene
acceso a él y cuentan con la opción de gestionar los datos de ese almacén.
El software cliente tiene acceso a un almacén central, en algunos casos este es pasivo, el
software cliente accede a los datos independientemente de cualquier cambio hecho en los
datos o las acciones de otro software cliente.
Una variación de este enfoque transforma el depósito en un pizarrón que envía
notificaciones al software cliente cuando cambian datos de interés para el cliente.
Características
Promueve la capacidad de integración, es decir, que es posible cambiar componentes
existentes y agregar nuevos componentes a la arquitectura sin preocuparse por otros
clientes, además es posible pasar datos entre clientes empleando el mecanismo del pizarrón.
Los componentes clientes ejecutan los procesos de manera independiente.
Arquitecturas de Pizarra o Repositorio
La arquitectura software en pizarra es un modelo arquitectónico de software habitualmente
utilizado en sistemas expertos, sistemas multiagente y, en general, sistemas basados en el
conocimiento.
En esta arquitectura hay dos componentes principales: una estructura de datos que
representa el estado actual y una colección de componentes independientes que operan
sobre él.
En base a esta distinción se han definidos dos subcategorías principales del estilo:
- Si los tipos de transacciones en el flujo de entrada definen los procesos a ejecutar,
el repositorio puede ser una base de datos tradicional (Implícitamente no cliente-
servidor).
- Si el estado actual de la estructura de datos dispara los procesos a ejecutar, el
repositorio es lo que se llama una pizarra pura o un tablero de control.
Tomado de:
http://es.wikipedia.org/wiki/Arquitectura_en_pizarra_(inform%C3%A1tica)
http://repositorio.utp.edu.co/dspace/bitstream/11059/2460/1/00422V152.pdf
http://carlosreynoso.com.ar/archivos/arquitectura/Estilos.PDF
ATRIBUTOS DE CALIDAD: ISO STD 9126
ISO std 9126 CONCEPTO CRITERIO
SI NO POCO
Funcionabilidad Mantiene a los usuarios bien informados X
Confiabilidad Los contenidos publicados tienen una fuente real X
Usabilidad Los usuarios se mantienen en contacto debido a la
información
X
Eficiencia Se trata del manejo que tiene el usuario
correspondiente a la pagina
X
Mantenibilidad Se realizan constantes publicaciones X
Portabilidad Está disponible en multiplataforma X
ESTRUCTURA DE LOS DATOS
Lenguajes de programación y codificación:
Trata de una nueva versión del lenguaje HTML, con nuevos
elementos, atributos y comportamientos, y un conjunto más
amplio de tecnologías que permite a los sitios Web y las
aplicaciones más diversas y de gran alcance.
Se referencia a un lenguaje de hojas de estilos usado para
describir la presentación semántica (el aspecto y formato) de
un documento escrito en lenguaje de marcas. Css3 es el
estándar de CSS y es compatible hacia atrás con otros
estándares de versiones anteriores.
Javascript permite a los desarrolladores crear acciones en sus
páginas web. Tiene la ventaja de ser incorporado en cualquier
página web, puede ser ejecutado sin la necesidad de instalar
otro programa para ser visualizado.
Es un lenguaje de programación de uso general de código del
lado del servidor originalmente diseñado para el desarrollo
web de contenido dinámico.
Es un sistema de administración de bases de datos. Una base
de datos es una colección estructurada de tablas que
contienen datos.
El sitio WebLog Xataka usa un CMS desarrollado sobre
Symfony 2.0. Consiste en una interfaz que controla una o
varias bases de datos donde se aloja el contenido del sitio
web
ESTRUCTURA INTERNA DEL WEBLOG XATAKA
En esta imagen se observa la cabecera seleccionada con sombreado con las redirecciones al
resto de la barra de menú del WebLog Xataka.
En esta imagen se observa que la selección está orientada al JavaScript.
Se observa en la selección que esta parte de la codificación se encuentra el inicio de sesión
mediante twitter o facebook, así como el logo y las publicaciones encontradas en la parte
superior de Xataka.
En la selección se puede observar que contiene las publicaciones más recientes dentro del
sitio web.
En la selección se encuentra tomada la parte en donde se redirecciona a las diferentes
extensiones de Xataka.
En la imagen superior se encuentra en selección la parte inferior del sitio WebLog en donde
muestra ¿Quiénes Somos?, Políticas y demás.
Finalización del sitio WebLog en donde se muestran las funciones por JavaScript.
CRITERIOS DE EVALUACIÓN
El WebLog Xataka ofrece responsabilidad en el área de servicios informáticos y de ciencia,
teniendo fiabilidad en los contenidos publicados. Al hablar de los términos y condiciones
de uso esta se caracteriza por ser una página informativa sin fines de lucro, donde su
principal responsabilidad es mantener usuarios bien informados.
En respecto a sus productos el material que publica el WebLog Xataka son actuales y
forman parte de diferentes ámbitos tanto tecnológicos, informáticos, sociales u otros que
sean relacionados con la tecnología. El tiempo de publicación es diario y cada cierta hora
están actualizando la información. Con respecto al riesgo que toman los desarrolladores es
que esta información no sea recibida por igual en todos los usuarios o no les sea atrayente.
Lo intangible de Xataka es que sus recursos en diferentes plataformas son entretenidos para
el usuario y a su vez contiene idoneidad en su información, sirviendo de entretenimiento y
de recurso para los lectores al igual ofreciendo una calidad de las referencias.
ESTRUCTURA INTERNA DE LOS PROGRAMAS
XATAKA WEB
XATAKA FOTO
XATAKA PARA
ANDROID
XATAKA MOVIL
(CUALQUIER
DISPOSITIVO
MOVIL)
XATAKA ON
(CONTENIDOS
ELECTRONICOS)
XATAKA SMART
HOME (ARTICULOS
DE DOMESTICA
DIGITAL)
XATAKA PARA
WINDOWS
XATAKA CIENCIA
(CONTENIDOS DE
CIENCIA)
XATAKA PARA
APPLE( IPHONE O
IPOD ENTRE OTROS)
XATAKA VIDA
EXTRA (CONSOLAS
Y VIDEOJUEGOS)
XATAKA GENBETA
(SOFTWARE Y WEB)
XATAKA
GENBETA:DEV
(DESARROLLO Y
SOFTWARE)
MANTENIMIENTO
CAMBIOS EN EL ENTORNO:
- Rediseñar el sitio web con respecto a modificar la parte superior respecto a
eliminarle los botones de re direccionamiento a facebook, twitter, eliminando el
cintillo donde estos aparecen, para realizar esto la pagina tendría que tener un
hosting propio donde se pueda alojar. Y eliminaría la sección de publicidades que se
encuentra debajo de la barra de menú, dejando dichas publicidades en la sección de
lo mejor, cambiando el nombre a ultimas agregadas. También agregaría a la parte
del cintillo un botón que permitiera iniciar sesión y si no estás registrado permita
realizar dicho registro.
- Rediseñar el sitio web con respecto a modificar la parte inferior en donde se muestra
información correspondiente a la página y cambiarla de forma que se agregue como
un menú desplegable en la parte superior donde se encuentra los demás vínculos de
la parte superior, teniendo como categoría o botones uno sobre Xataka donde fuese
lo encontrado en la última imagen, y otro botón donde se ubique las extensiones
encontradas en la tercera imagen, con respecto a la segunda imagen añadiría un
botón en la barra de menú desplegable superior donde se alojara todas estas
categorías presentes en esta imagen.
PARTE
SUPERIOR
1
2
3
Estas modificaciones son hechas para hacerle menos complicada la búsqueda de
información al usuario y facilitarle la misma.
BIBLIOGRAFIA
- http://www.fceia.unr.edu.ar/~mcristia/publicaciones/ingreq-a.pdf
- http://www.issi.uned.es/doctorado/softwarch/DEA/Trabajos%2010/Trabajo%20de
%20Investigacion%20-%20Juan%20Antonio%20Perez-Campanero.pdf
- http://www.weblogssl.com/2012/02/27-nuevo-diseno-en-xataka-2012
- http://www.xatakaciencia.com/xatakaciencia/asi-es-el-nuevo-xataka-y-asi-sera-
muy-pronto-xataka-ciencia
- http://www.xatakaciencia.com/xatakaciencia/asi-es-el-nuevo-xataka-y-asi-sera-
muy-pronto-xataka-ciencia
- http://ingenieriadesoftware.mex.tl/52753_XP---Extreme-Programing.html
- http://carlosreynoso.com.ar/archivos/arquitectura/Estilos.PDF
- http://www.xataka.com/
- http://www.xatakamovil.com/?utm_source=xataka&utm_medium=network&utm_c
ampaign=footer
- http://www.xatakafoto.com/?utm_source=xataka&utm_medium=network&utm_ca
mpaign=footer
- http://www.xatakandroid.com/?utm_source=xataka&utm_medium=network&utm_c
ampaign=footer
- http://www.xatakaon.com/?utm_source=xataka&utm_medium=network&utm_cam
paign=footer
- http://www.xatakahome.com/?utm_source=xataka&utm_medium=network&utm_c
ampaign=footer
- http://www.xatakawindows.com/?utm_source=xataka&utm_medium=network&ut
m_campaign=footer
- http://www.xatakaciencia.com/?utm_source=xataka&utm_medium=network&utm_
campaign=footer
- http://www.applesfera.com/?utm_source=xataka&utm_medium=network&utm_ca
mpaign=footer
- http://www.vidaextra.com/?utm_source=xataka&utm_medium=network&utm_cam
paign=footer
- http://www.genbeta.com/?utm_source=xataka&utm_medium=network&utm_camp
aign=footer
- http://www.genbetadev.com/?utm_source=xataka&utm_medium=network&utm_ca
mpaign=footer
- http://www.davidvalverde.com/blog/introduccion-a-la-programacion-extrema-xp/
UNIVERSIDAD NACIONAL EXPERIMENTAL
DE LOS LLANOS OCCIDENTALES
“EZEQUIEL ZAMORA”
BARINAS. ESTADO. BARINAS
BACHILLERES:
RIVERO JENNY C.I. 24774554
TORRES KENNYMAR C.I.23023059
¿QUÉ ES XATAKA?
Es un WebLog corporativo, que fusiona ámbitos web de
información pura con gran cantidad de temas diversos, la función
de Xataka es de una web tecnológica informativa, lo temas de
Xataka son exclusivamente tecnológicos.
XATAKA ANTES XATAKA AHORA
ESTRUCTURA INTERNA DE LOS PROGRAMAS
ESTRUCTURA DE LA PAGINA WEBLOG XATAKA
REQUERIMIENTOS DONDE PUEDA FUNCIONAR
DISPOSITIVO MOVIL
XATAKA S.O VERSION DEL S.O ALMACENAMIENTO
COMPLETA ANDROID 2.2 EN ADELANTE 207K
ANDROID ANDROID 2.2 EN ADELANTE 198K
MOVIL CUALQUIERA ------------- 83.1K
WINDOWS WINDOWS
PHONE
------------- 73K
METODOLOGIA DE DESARROLLO DEL SOFTWARE
La programación extrema o Extreme Programming (XP) es una metodología de
desarrollo de la ingeniería de software formulada por Kent Beck.
METODOLOGIA ARQUITECTONICA
Atributos de calidad y escenarios:
Para poder evaluar una arquitectura, Bass, Clemens y Kazman, en su libro “Software
Architecture in Practice”, recogen y sistematizan seis atributos de calidad que serían
aplicables a la Arquitectura de un sistema software, permitiendo la evaluación de los
mismos y, por lo tanto, de la Arquitectura Software propuesta .
ESTILO ARQUITECTÓNICO
CENTRALIZADO EN DATOS
Un almacén de datos se encuentra en el centro de esta arquitectura, otro
componente tiene acceso a él y cuentan con la opción de gestionar los datos de
ese almacén. El software cliente tiene acceso a un almacén central, en algunos
casos este es pasivo, el software cliente accede a los datos independientemente de
cualquier cambio hecho en los datos o las acciones de otro software cliente.
ATRIBUTOS DE CALIDAD: ISO STD 9126
ISO STD 9126 CONCEPTO CRITERIO
SI NO POCO
Funcionabilidad Mantiene a los usuarios bien informados X
Confiabilidad Los contenidos publicados tienen una fuente real X
Usabilidad Los usuarios se mantienen en contacto debido a la
información
X
Eficiencia Se trata del manejo que tiene el usuario
correspondiente a la pagina
X
Mantenibilidad Se realizan constantes publicaciones X
Portabilidad Está disponible en multiplataforma X
CRITERIOS DE EVALUACIÓN
GRACIAS
POR SU
ATENCIÓN
