miércoles, 25 de octubre de 2017

Lenguaje HTML

En 1989 existían dos técnicas que permitían vincular documentos electrónicos, por un lado los hipervínculos y por otro lado un poderoso lenguaje de etiquetas denominado SGML. Por entonces, Tim Berners-Lee da a conocer a la prensa que estaba trabajando en un sistema que permitirá acceder a ficheros en línea que funcionaba sobre redes de computadoras o máquinas electrónicas basadas en el protocolo TCP/IP.

A principios de 1990, define por fin el HTML como un subconjunto del conocido SGML y crea algo más valioso aún, el World Wide Web. Aparte de esto creó un sistema que facilitaba la lectura de información mediante un programa de navegación, es decir, creó el primer navegador. A partir de ahí se fueron desarrollando más navegadores como Line Mode Browser.

En 1997, HTML 4.0 se publicó como una recomendación del W3C. HTML 4.0 adoptó muchos elementos específicos desarrollados inicialmente para un navegador web concreto, pero al mismo tiempo comenzó a limpiar el HTML señalando algunos de ellos como desaprobados.

En 2006, el W3C se interesó en el desarrollo de HTML5, y en 2007 se unió al grupo de trabajo del WHATWG para unificar el proyecto.


Historia del estándar

El diseño en HTML, aparte de cumplir con las especificaciones propias del lenguaje, debe respetar ciertos criterios de accesibilidad web, siguiendo unas pautas o las normativas y leyes vigentes en los países donde se regule dicho concepto.

Se encuentra disponible y desarrollado por el W3C a través de las Pautas de Accesibilidad al Contenido, aunque muchos países tienen especificaciones propias, como es el caso de España


Historia de HTML

Tim Berners-Lee en 1991 describe 22 elementos que incluyen el diseño inicial y relativamente simple de HTML. Trece de estos elementos todavía existen en HTML 4.

Documento en HTML

El HTML se escribe en forma de «etiquetas», rodeadas por corchetes angulares (<,>). HTML también puede describir, hasta un cierto punto, la apariencia de un documento, y puede incluir o hacer referencia a un tipo de programa llamado script, el cual puede afectar el comportamiento de navegadores web y otros procesadores de HTML.


Marcado HTML

El lenguaje HTML puede ser creado y editado con cualquier editor de textos básico, como puede ser Gedit en Linux, el Bloc de notas de Windows, pero hemos trabajado con Notepad++.
Existen, además, otros editores para la realización de sitios que permiten ver el resultado de lo que se está editando en tiempo real, a medida que se va desarrollando el documento. Estos editores se llaman WYSIWYG y algunos ejemplos de él son KompoZer o Adobe Dreamweaver.

Nociones básicas del HTML

¿Qué es el lenguaje HTML?

Tipos de etiquetas

HTML, siglas de lenguaje de marcas de hipertexto en inglés, hace referencia al lenguaje de marcado para la elaboración de páginas web. Las páginas web están construidas en un lenguaje de etiquetas denominado lenguaje html.

El lenguaje HTML está basado en su desarrollo en la referenciación. Para añadir un elemento externo a la página, este no se incrusta directamente en el código de la página, sino que se hace una referencia a la ubicación de dicho elemento mediante texto.
Al ser un estándar, HTML busca ser un lenguaje que permita que cualquier página web escrita en una determinada versión, pueda ser interpretada de la misma forma (estándar) por cualquier navegador web actualizado.

Berners-Lee consideraba a HTML una ampliación de SGML, pero no fue formalmente reconocida como tal hasta la publicación a mediados de 1993. Destacó el reconocimiento de la etiqueta propia del navegador Mosaic usada para insertar imágenes sin cambio de línea, que reflejaba la filosofía del IETF de basar estándares en prototipos con éxito. De la misma manera, el boceto competidor de Dave Raggett HTMLde finales de 1993, sugería estandarizar características ya implementadas, como las tablas.

HTML también sirve para referirse al contenido del tipo de MIME o todavía más ampliamente como un término genérico para el HTML.

HTML consta de varios componentes vitales, que son los elementos y sus atributos.
Los elementos son la estructura básica de HTML. Estos tienen dos propiedades básicas: atributos y contenido. Cada atributo y contenido tiene ciertas restricciones para que se considere válido al documento HTML. Un elemento generalmente tiene una etiqueta de inicio y una de cierre

La mayoría de los atributos de un elemento son pares nombre-valor, separados por un signo de igual «=» y escritos en la etiqueta de comienzo de un elemento, después del nombre de éste. El valor puede estar rodeado por comillas dobles o simples, aunque ciertos tipos de valores pueden estar sin comillas en HTML. De todas maneras, dejar los valores sin comillas es considerado poco seguro.


Elementos

Atributos

<html>: Inicia el documento HTML, le indica al navegador que lo que viene a continuación debe ser interpretado como código HTML.
<script>: incrusta un script en una web, o llama a uno mediante src="url del script".
<head>: define la cabecera del documento HTML; esta cabecera suele contener información sobre el documento que no se muestra directamente al usuario como, por ejemplo, el título de la ventana del navegador. Dentro de la cabecera es posible encontrar:
<title>: define el título de la página. Por lo general, el título aparece en la barra de título encima de la ventana.
<href=””>: para vincular el sitio a hojas de estilo o iconos. Por ejemplo: href="/style.css"
<style>: para colocar el estilo interno de la página.
<meta>: para metadatos como la autoría o la licencia, incluso para indicar parámetros http (http-equiv="") cuando no se pueden modificar por no estar disponible la configuración o por dificultades con server-side scripting.
<body>: define el contenido principal o cuerpo del documento. Esta es la parte del documento html que se muestra en el navegador; dentro de esta etiqueta pueden definirse propiedades comunes a toda la página, como color de fondo y márgenes. Dentro del cuerpo <body> es posible encontrar numerosas etiquetas. A continuación se indican algunas a modo de ejemplo:
<h1> a <h6>: etiquetas o encabezados del documento con diferente relevancia.
<table>: define una tabla.
<tr>: fila de una tabla.
<td>: celda de una tabla (debe estar dentro de una fila).
<a>: hipervínculo o enlace, dentro o fuera del sitio web. Por ejemplo:<a href="http://www.example.com" title="Ejemplo" </a>
<div>: división de la página. Se recomienda en vez de <table> cuando se desea alinear contenido.
<img>: imagen. Es necesario indicar la ruta en la que se encuentra la imagen. Por ejemplo: <img src="./imágenes/mifoto.jpg" />.
<li><ol><ul>: etiquetas para listas. <ul> para agregar una lista desordenada y <ol> para añadir una lista ordenada. <li> se usa para poner un punto dentro de una línea desordenada.
<strong>: texto en negrita
<em>: texto en cursiva
<del>: texto tachado


• <table><tr><td>Contenido de una celda</td></tr></table>.

• <script>Código de un script integrado en la página</script>.

domingo, 1 de octubre de 2017

EL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS

En la clase de estos días hemos hecho referencia a la metodología sistemática con la que los analistas llevan a cabo el análisis y diseño de los sistemas de información. Gran parte de ello se expresa en lo que conocemos como el ciclo de vida del desarrollo de sistemas (SDLC). El SDLC es una metodología en fases para el análisis y diseño, de acuerdo con la cual los sistemas se desarrollan mejor al utilizar un ciclo específico de actividades del analista y los usuarios.

Los analistas no se han puesto de acuerdo sobre la cantidad de fases que hay en el SDLC, pero por lo general alaban su metodología organizada. En este libro vamos a dividir el ciclo en siete fases, como se muestra en la figura de abajo. Aunque cada fase se presenta de manera discreta, en realidad nunca se puede llevar a cabo como un paso separado, sino que varias actividades pueden ocurrir al mismo tiempo, e incluso se pueden repetir.




1- Identificación de los problemas, oportunidades y objetivos

En esta primera fase del ciclo de vida del desarrollo de sistemas, el analista se encarga de identificar correctamente los problemas, las oportunidades y los objetivos. Esta etapa es imprescindible para el éxito del resto del proyecto: ya que a nadie le gusta desperdiciar el tiempo resolviendo un problema mal caracterizado. En la primera fase el analista debe analizar con honestidad lo que está ocurriendo en la empresa. Después, junto con otros miembros de la organización, debe comenzar a señalar los problemas. A menudo, otras personas habrían planteado también estos problemas, razón por la cual se llamó en un principio al analista. Las oportunidades residen en las situaciones que el analista cree poder mejorar mediante el uso de sistemas de información computarizados. Al aprovechar estas oportunidades, la empresa puede obtener una ventaja competitiva o establecer un estándar en la industria.

La identificación de los objetivos también es un componente importante de la primera fase. El analista debe descubrir primero qué trata de hacer la empresa; después debe ser capaz de determinar si alguno de los aspectos
de las aplicaciones de los sistemas de información puede ayudar a que la empresa logre sus objetivos al enfrentar
problemas u oportunidades específicos. Las personas involucradas en la primera fase son los usuarios, los analistas y los administradores de sistemas que coordinan el proyecto. En esta fase las actividades consisten en entrevistar a los encargados de la administración de los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del proyecto y documentar los resultados. El resultado de esta fase es un informe de viabilidad, el cual contiene la definición de un problema y sintetiza los objetivos. Después, la administración de la empresa debe tomar una decisión en cuanto a proceder o no con el proyecto propuesto. Si el grupo de usuarios no tiene suficientes fondos en su presupuesto o desea hacer frente a problemas que no están relacionados, o si los problemas no requieren un sistema computacional, tal vez se pueda recomendar una solución distinta y el proyecto de sistemas no continúe.


2- Determinación de los requerimientos de información del factor humano

La siguiente fase a la que entra el analista es determinar las necesidades de los usuarios involucrados, mediante
el uso de varias herramientas, para comprender la forma en que interactúan en el contexto laboral con sus sistemas de información actuales. El analista utilizará métodos interactivos como entrevistas, muestreos e investigación de datos duros, además de los cuestionarios y los métodos discretos, como observar el comportamiento de los encargados al tomar las decisiones y sus entornos de oficina, y los métodos integrales como la creación de prototipos.

El analista utilizará estos métodos para plantear y responder muchas preguntas relacionadas con la interacción
humano-computadora (HCI), incluyendo preguntas tales como: “¿Cuáles son las fortalezas y limitaciones físicas de los usuarios?”, o dicho en otras palabras, “¿qué hay que hacer para que el sistema sea perceptible, legible y seguro?”, “¿cómo puede diseñarse el nuevo sistema para que sea fácil de usar, aprender y recordar?”, “¿cómo puede el sistema ser agradable o incluso divertido de usar?”, “¿cómo puede el sistema apoyar las tareas laborales individuales de un usuario y buscar nuevas formas de hacerlas más productivas?”.

En la fase de requerimientos del SDLC, el analista se esfuerza por comprender qué información requieren los usuarios para realizar sus trabajos. En este punto el analista examina cómo hacer que el sistema sea útil para las personas involucradas. ¿Cómo puede el sistema ofrecer un mejor apoyo para las tareas individuales que se deben llevar a cabo? ¿Qué nuevas tareas habilita el nuevo sistema que los usuarios no podían realizar sin él? ¿Cómo se puede crear el sistema de manera que extienda las capacidades de un usuario más allá de lo provisto por el sistema anterior? ¿Cómo puede el analista crear un sistema gratificante para los trabajadores?

Las personas involucradas en esta fase son los analistas y los usuarios, por lo general los gerentes y los trabajadores de operaciones. El analista de sistema debe conocer los detalles sobre las funciones del sistema actual: el quién (las personas involucradas), el qué (la actividad de la empresa), el dónde (el entorno en el que se lleva acabo el trabajo), el cuándo (la coordinación) y el cómo (de qué manera particular se realizan los procedimientos actuales) de la empresa a la que está estudiando. Después, el analista debe preguntar por qué la empresa utiliza el sistema actual. Puede haber buenas razones por las cuales la empresa trabaje con los métodos actuales, razón por la que se deben tener en cuenta al diseñar un nuevo sistema.

El desarrollo ágil es una metodología orientada a objetos (OOA) para el desarrollo de sistemas, en la cual se incluye un método de desarrollo (junto con la generación de los requerimientos de información) así como herramientas de software. En el capítulo 6 veremos este tipo de desarrollo, junto con los prototipos.

No obstante, si la razón de seguir con las operaciones actuales es que “siempre se ha hecho de esa forma”, el analista querrá mejorar los procedimientos. Al terminar esta fase, el analista deberá comprender la forma en que los usuarios realizan su trabajo al interactuar con una computadora y deberá empezar a comprender cómo mejorar la utilidad y capacidad de uso del nuevo sistema. También deberá saber cómo funciona la empresa y tener información completa sobre personas, objetivos, datos y procedimientos involucrados.


3- Análisis de las necesidades del sistema

La siguiente fase que debe llevar a cabo el analista de sistemas involucra el analista de sistemas involucra el análisis de las necesidades del sistema. Aquí también hay herramientas y técnicas especiales que ayudan al analista a realizar las determinaciones de los requerimientos. Las herramientas como los diagramas de flujo de datos (DFD) para graficar la entrada, los procesos y la salida de las funciones de la empresa, o los diagramas de actividad o de secuencia para mostrar la secuencia de los eventos, sirven para ilustrar a los sistemas de una manera estructurada y gráfica. A partir de los diagramas de flujo de datos, de secuencia u otros tipos de diagramas se debe desarrollar un diccionario de datos para enlistar todos los elementos de datos utilizados en el sistema, así como sus especificaciones.
Durante esta fase, el analista de sistemas también analiza las decisiones estructuradas llevadas a cabo. Las decisiones estructuradas son aquellas para las que se pueden determinar condiciones, alternativas de condición, acciones y reglas de acción. Hay tres métodos principales para el análisis de las decisiones estructuradas: inglés/ español estructurado, tablas de decisión y árboles de decisión.

En este punto del SDLC, el analista de sistemas prepara una propuesta de sistemas en la que sintetiza todo lo que ha averiguado sobre los usuarios, la capacidad de uso y la utilidad de los sistemas actuales; incluye un análisis de costo-beneficio de las alternativas y, si se requiere, hace recomendaciones. Si la administración acepta una de las recomendaciones, el análisis continúa por esa vía. Cada problema de sistemas es único, por lo que nunca hay sólo una solución correcta. La manera en que se formule una recomendación o solución depende de las cualidades individuales y la capacitación profesional de cada analista, y de su interacción con los usuarios en el contexto de su entorno laboral.


4- Diseño del sistema recomendado

En la fase de diseño del SDLC, el analista de sistemas utiliza la información recolectada antes para realizar el diseño lógico del sistema de información. El analista diseña los procedimientos para ayudar a que los usuarios introduzcan los datos con precisión, de manera que los datos que entren al sistema de información sean los correctos. Además, el analista debe ayudar a que los usuarios completen la entrada de datos efectiva al sistema de información mediante el uso de las técnicas del buen diseño de formularios y páginas Web o pantallas.

Parte del diseño lógico del sistema de información es idear la HCI. La interfaz conecta al usuario con el sistema, por lo que es extremadamente importante. La interfaz del usuario se diseña con ayuda de los usuarios para asegurar que el sistema sea perceptible, legible y seguro, así como atractivo y divertido de usar. Ejemplos de interfaces de usuario físicas son el teclado (para escribir las preguntas y respuestas), los menús en pantalla (para obtener los comandos de los usuarios) y varios tipos de interfaces gráficas de usuario (GUI) basadas en un ratón o una pantalla táctil.

La fase de diseño también incluye el diseño de bases de datos que almacenarán gran parte de los datos necesarios para los encargados de tomar las decisiones en la organización. Los usuarios se benefician de una base de datos bien organizada que sea lógica para ellos y se corresponda con la forma en que ven su trabajo. En esta fase, el analista también trabaja con los usuarios para diseñar una salida (ya sea en pantalla o impresa) que cumpla con sus necesidades de información.

Por último, el analista debe diseñar controles y procedimientos de respaldo para proteger el sistema y los datos, y para producir paquetes de especificación de programas para los programadores. Cada paquete debe contener los diseños de las entradas y las salidas, las especificaciones de los archivos y los detalles sobre el procesamiento; también puede incluir árboles o tablas de decisión, UML o diagramas de flujo de datos, junto con los nombres y las funciones de cualquier código previamente escrito dentro de la empresa o que utilice código u otras bibliotecas de clases.


5- Desarrollo y documentación del software

En la quinta fase del SDLC, el analista trabaja con los programadores para desarrollar el software original requerido. Durante ella, el analista desarrolla junto con los usuarios una documentación efectiva para el software, incluyendo manuales de procedimientos, ayuda en línea, sitios Web con preguntas frecuentes (FAQ) y archivos Léame (Read Me) para incluir con el nuevo software. Como los usuarios están involucrados desde el principio, la fase de documentación debe lidiar con las preguntas que hicieron y resolvieron junto con el analista. La documentación indica a los usuarios cómo deben usar el software y qué deben hacer en caso de que ocurran problemas.


Los programadores desempeñan un rol clave en esta fase, ya que diseñan, codifican y eliminan los errores sintácticos de los programas de computadora. Para asegurar la calidad, un programador puede llevar a cabo un recorrido por el diseño o por el código para explicar las porciones complejas del programa a un equipo formado por otros programadores.


6- Prueba y mantenimiento del sistema

Antes de utilizar el sistema de información, se debe probar. Es mucho menos costoso detectar los problemas antes de entregar el sistema a los usuarios. Una parte del procedimiento de prueba es llevado a cabo por los programadores solos; la otra la realizan junto con los analistas de sistemas. Primero se completa una serie de pruebas para señalar los problemas con datos de muestra y después se utilizan datos reales del sistema actual. A menudo, los planes de prueba se crean en las primeras etapas del SDLC y se refinan a medida que el proyecto progresa. El mantenimiento del sistema y la documentación de este mantenimiento empiezan en esta fase y se lleva a cabo de manera rutinaria durante toda la vida del sistema de información. Gran parte del trabajo rutinario del programador consiste en el mantenimiento, por lo cual las empresas invierten una gran cantidad de dinero en este proceso.

Ciertos procedimientos de mantenimiento, como las actualizaciones de los programas, se pueden llevar a cabo a través del sitio Web del distribuidor. Muchos de los procedimientos sistemáticos que emplea el analista durante el SDLC pueden ayudar a asegurar que el mantenimiento siempre se mantenga en el nivel mínimo necesario.


7- Implementación y evaluación del sistema

En esta última fase del desarrollo de sistemas, el analista ayuda a implementar el sistema de información. En esta fase hay que capacitar a los usuarios para operar el sistema. Los distribuidores se encargan de una parte de la capacitación, pero la supervisión de la capacitación es responsabilidad del analista de sistemas. Además, el analista necesita planear una conversión sin problemas del sistema antiguo al nuevo. Este proceso incluye convertir los archivos de los formatos anteriores a los nuevos, o crear una base de datos, instalar equipo y llevar el nuevo sistema a producción.

La evaluación se incluye como parte de esta fase final del SDLC principalmente por cuestiones informativas. En realidad, la evaluación se realiza durante cada fase. El criterio clave que debemos satisfacer es si los usuarios previstos están utilizando el sistema. Hay que tener en cuenta que a menudo el trabajo relacionado con los sistemas es cíclico. Cuando un analista termina una fase del desarrollo de sistemas y continúa con la siguiente, al descubrir un problema tal vez se vea obligado a regresar a la fase anterior y modificar el trabajo que realizó ahí.