Ing. Duque Escobar

Hace ya algún tiempo que esta tecnología dejó de ser una moda y una promesa, para convertirse en una realidad con muchas utilidades. Como muestra volvamos a Google. Esta compañía inició en Abril del año 2002 la posibilidad de hacer búsquedas usando su motor de búsqueda (que indexa más de 3.000 millones de documentos Web). Esto se hace mediante webservices. Como podemos ver, una aplicación real para el mundo real. Pero, ¿qué es un webservice?

MARCO TEÓRICO

1.1. La Web 3.0

En general, se asocia la Web 3.0 a una nueva etapa destinada a añadir significado a la web, y por tal motivo se acuerda con Tim Berners-Lee, el creador de la World Wide Web, en llamarla Web Semántica.

Todavía no se ha incorporado el cambio de actitud, que como señala Christian Van Der Henst S. implica la Web 2.0, cuando ya se habla de Web 3.0, como de una realidad inminente que promete transformar no sólo nuestra experiencia web, sino toda nuestra cotidianidad.

1.2. ¿Qué es la Web 3.0?

Si bien, en general, se asocia el término al de Web Semántica, acuñado por Tim Berners-Lee, cabe acotar, valga la paradoja, que no existe total consenso acerca de lo que significa la Web 3.0. Aunque se coincide en que esta etapa añadirá significado a la web, no hay acuerdo sobre cuáles son los caminos más apropiados para su desarrollo.

José Antonio del Moral, director general de la consultora Alianzo, en su artículo sobre Web 3.0 ¿futura realidad o ficción?, califica al término Web 3.0 de ‘abstracto’. Por su parte, Salvador Pérez Crespo de Telefónica de España, considera que la Web 3.0 será una revolución si se logra una combinación efectiva entre la inclusión de contenido semántico en las páginas web y el uso de inteligencia artificial que saque partido de ella.

No obstante, dado que los avances de esta disciplina son demasiado lentos y dificultosos, cree que la solución podría estar en la combinación de las técnicas de inteligencia artificial con el acceso a la capacidad humana de realizar tareas extremadamente complejas para un ordenador. Como lo está haciendo: Mechanical Turk de Amazon y Google Image Labeler.

En cualquier caso, el aumento de la interactividad y de la movilidad son dos factores que muchos señalan como decisivos en esta nueva etapa de la web.

1.3. ¿Es la Web Semántica sinónimo de Web 3.0?

De lo dicho anteriormente se desprende que no, aunque muchas veces estos términos sean empleados como tales. Quizás la principal diferencia sea que la Web 3.0 se concibe como un estadìo a ser alcanzado en mayor o menor plazo, mientras que la Web Semántica es un proceso evolutivo en construcción permanente.

En tal sentido, como señala Berners-Lee, ya estamos inmersos en ella. Es de suponer que, tal como es concebida, trascenderá tanto el concepto de Web 3.0, como el de sus sucesoras.

1.4. Ideas en torno a la definición de la Web 3.0

Básicamente, tienen que ver con los avances y proyectos en curso que tienden a una cada vez mayor y más eficiente incorporación de la web a la cotidianidad. Se habla así, de conceptos tales como: Web 3D, Web centrada en multimedia y Web permanente.

Por otra parte, íntimamente relacionados con la Web Semántica surgen los microformatos, que como dice Pérez Crespo, son un enfoque más pragmático de ésta, e intentan tener utilidad a más corto plazo.

1.5. ¿Qué es la Web Semántica?

Nadie mejor que Tim Berners-Lee, el creador de la World Wide Web, para dar respuesta a este interrogante. La denominación de Web Semántica se remonta al año 2001, cuando presentó en Scientific American el ya famoso caso de Lucy.

Sin embargo, en una entrevista publicada por BusinessWeek, en abril de este año, señala que quizás debería haberla llamado Web de los datos, dado que la palabra semántica es utilizada para significar diferentes cosas.

1.6. ¿En qué consiste la Web de los datos y para qué puede ser utilizada?

Básicamente, la idea se refiere a una web capaz de interpretar e interconectar un número mayor de datos, lo que permitiría un avance importante en el campo del conocimiento.

En tal sentido, Berners-Lee destaca lo que esta transformación traería aparejada en el campo de la investigación genética y el tratamiento farmacológico de enfermedades hasta ahora incurables. Diseñada correctamente, la Web Semántica puede asistir a la evolución del conocimiento humano en su totalidad.

1.7. El futuro de la Web actual

En una entrevista realizada por Andrew Updegrove y publicada en el Consortium Standards Bulletin el padre del web considera que la Web Semántica es más una evolución que una revolución de la Web actual.

En dicha oportunidad, se mostró satisfecho con la recepción que la misma había tenido en el área de las ciencias de la vida y el cuidado de la salud y agregó que, a diferencia de la Web de los documentos (Web 1.0), que tuvo un crecimiento exponencial muy rígido, esta nueva etapa depende, en gran medida, de las pequeñas comunidades que han comprendido el paradigma y de la atención que le ha merecido a la prensa.

1.8. ¿Cuándo y cómo este modelo podrá ser implementado?

En un artículo publicado en la edición online de ERCIM, en octubre de 2002, Tim Berners-Berners-Lee y Eric Molinero anticipaban que la Web alcanzaría su capacidad máxima cuando se convirtiese en un ambiente donde los datos pudiesen ser compartidos y procesados por las herramientas automatizadas, así como por la gente.

Esto se lograría a partir de la definición de estándares: los identificadores uniformes de recurso (URIs), base de la web semántica, el Extensible Markup Language (XML) fundamento sintáctico de la misma y el marco de la descripción del recurso (RDF).

En febrero de 2004, el World Wide Web Consortium (W3C) publicó las recomendaciones para el RDF y el Ontology Web Language (OWL), Este último describe la función y relación de cada uno de los componentes de la Web Semántica.

Puede especificar clases, propiedades y estados de algo. Estos estándares que constituyen la base sintáctica de la web semántica, ya están siendo adoptados por algunas empresas en sus últimos proyectos.

1.9. ¿Cuáles son las dificultades para su generalización?

En cuanto a las críticas y resistencias que el modelo semántico ofrece, Berners-Lee conviene en que la sintaxis RDF/XML, empleada por éste, no es muy fácil de leer.

Sin embargo, acota, esto no debería ser una complicación ya que al tratarse de sistemas de escritura de datos, la codificación semántica podrá ser totalmente automatizada. Cabe señalar que al igual que con la adopción de la Web 2.0, el desarrollo e implementación de la Web 3.0, será en gran parte una cuestión de actitud.

1.10. Los desafíos que deberá afrontar el nuevo modelo

Establecidos los estándares, que constituyen la base sintáctica de la nueva web, Berners-Lee cree que los nuevos desafíos en la evolución de la misma deberán ser tratados en términos de utilidad y accesibilidad.

Aunque el punto clave de la Web Semántica está, según expresa, en su potencial para las nuevas aplicaciones de datos sobre el web. En otras palabras, en la capacidad de generar búsquedas más precisas e “inteligentes”.

1.11. ¿Cuál será el futuro de los buscadores?

Algunos creen que la implementación de la nueva web, será el fin de los grandes buscadores. Según Nicholas Carr, la Web 3.0 “convertirá en obsoletos a los buscadores de hoy”. Sin embargo, Berners-Lee señala que esto no será así.

El hecho de que se agregue algo, aclara, no quiere decir que se esté sustituyendo; la existencia de datos no amenaza los documentos. Del mismo modo, los motores de búsqueda podrán evolucionar y hacerse Web semántico compatibles, en la medida en que los usuarios exijan dicha compatibilidad.

1.12. ¿Acaso no existen datos semánticos en la metadata de los documentos actuales?

Ya en mayo de 2001, Tim Berners-Berners-Lee, James Hendler y Ora Lassila observaban en un informe publicado en Scientific American , que la Web Semántica no era una Web separada sino una extensión de la existente y que los primeros pasos en tejer la Web Semántica en la estructura de la Web, ya estaban en curso.

Por otra parte, explicaban que el desafío de la Web Semántica era proporcionar una lengua, que expresase los datos y las reglas para razonar sobre esos datos, y que permitiese que las reglas de cualquier sistema existente de conocimiento, sean exportadas sobre el Web.

1.13. La Web Social

En la 5ta. Conferencia Internacional de la Web Semántica, realizada en noviembre de 2006, Tom Gruber señaló en su presentación que hay una falsa idea popular que tiende a considerar la Web Semántica y la Web Social como dos mundos con ideologías alternativas y en oposición sobre cómo debe ser la web.

Consideró que esto era absurdo, y que era hora de abrazar una idea unificada, suscribiendo a la visión del Web semántico como substrato para la inteligencia colectiva.

Al respecto, José Antonio del Moral sostiene que en la Web 3.0 se produciría una unificación de las comunidades sociales, para lograr que el usuario tuviera una sola identidad en internet.

¿Cuáles son los impedimentos para que el uso del modelo semántico, a corto plazo, se haga extensivo?, ¿existen alternativas a dicho modelo?

Más allá del optimismo expresado por Berners-Lee; la web semántica -como explica en su tesis doctoral, María Jesús Lamarca,- sin duda mejorará la accesibilidad de la información, pero el problema es que exige una completa reanotación de la web.

Por tal motivo, agrega, otros investigadores han tomado un camino diferente para implementar la Web Semántica. En lugar de utilizar estándares y reformateos webs, están construyendo nuevos agentes para que puedan entender mejor la web tal como está hoy en día.

Las páginas web ya tienen información semántica, así que lo que hacen es que los agentes las entiendan tal como los humanos. No están haciendo las páginas más fáciles de leer, sino los agentes más inteligentes.

1.14. ¿Qué son y cómo surgen estos agentes inteligentes?

Pérez Crespo señala que estos agentes inteligentes, llamados microformatos, surgen frente a la web semántica tradicional, producto del trabajo de la comunidad de desarrolladores de Technorati.

Su objetivo es estandarizar un conjunto de formatos en los que almacenar conocimiento básico. Considera que, a corto plazo, los microformatos serán los triunfadores.

1.15. ¿Qué es la Web 3D?

Se llama así, a lo que muchos ven como una extensión de los mundos virtuales, similar a la famosa Second Life o There.com se cree que en el futuro la web será una gran alternativa al mundo real, donde se podrá recorrer el planeta a través de ella, sin abandonar el escritorio.

La experiencia sería semejante al actual Google Earth. Compañías como Google y Microsoft trabajan en este tipo de proyectos.

1.16. La Web centrada en multimedia

Se refiere a una web que ofrezca, no solamente búsquedas basadas en metadatos, sino por similitudes en la multimedia.

La web “mediocéntrica” es una web enfocada en los multimedios, donde se podrán hacer búsquedas por similitud, de imágenes, música y videos, con sólo mostrar al buscador el medio de referencia. Entre las Compañías que están trabajando en estos proyectos se encuentran Ojos y Polar Rose.

1.17. ¿Qué es la Web permanente?

También llamada Web omnipresente o pervasive web es una web que está en todas partes, no sólo en el PC o celular sino en la ropa, joyas, automóviles, etc.

Es un concepto, que se ha extendido a partir del pasaje de los PC a los teléfonos celulares y PDA. Según un artículo publicado en el wiki Wadooa, el laboratorio de multimedios del MIT , ya está trabajando en estas ideas a partir de la creación de espejos de baños y ventanas de casas conectados a internet.

1.18. Las resistencias y cuestionamientos a esta evolución de la Web

Según Pérez Crespo, los pesimistas aducen que el grado de complejidad que esta exige no será alcanzado, porque existirá una fuerte reacción de quienes ahora disponen de la información, que no querrán compartirla o porque fenómenos como el “spam semántico” la harán poco utilizable.

Por su parte, Ricardo Baeza-Yates, director de Yahoo Research Barcelona, en el artículo sobre Web 3.0: la inteligencia hecha web, cree que la Web Semántica puede no existir nunca, ya que sólo podría ocurrir cuando las personas e instituciones usen los mismos estándares semánticos y sean confiables. Algo que considera prácticamente imposible.

Sin duda, existirá fuerte oposición entre los defensores de la privacidad y puede que ésta en determinado momento sea más vulnerable, sin embargo, cabe suponer que, paralelamente, se desarrollaran los mecanismos necesarios para protegerla.

1.19. Proyectos en curso que anticipan el modelo de la Web 3.0

Dentro de la corriente oficial, centrada en la creación de estándares y reformateo de páginas, algunas Compañías como HP y Yahoo ya vienen implementando los nuevos lenguajes.

Los ejemplos más citados son el de la empresa RadarNetworks , que busca explotar el contenido suministrado por los usuarios en las redes sociales y el proyecto KnowItAll, desarrollado en la Universidad de Washington y financiado por Google, que busca obtener y agregar información de usuarios de productos.

Se pueden encontrar estructuras web semánticas en la herramienta espacial de la base de datos Oracle. Empresas como Powerset y TextDigger han trabajado en buscadores web semánticos basados en el proyecto académico open source WordNet.

Por otra parte, dentro de la corriente alternativa, ocupada en la construcción de agentes más inteligentes, el proyecto más temprano ha sido el de BlueOrganizer de AdaptativeBlue.

Actualmente en desarrollo, Parakey es un proyecto de código abierto, comandado por Blake Ross, uno de los desarrolladores de Firefox. La idea es unificar el escritorio y la web, a partir de la creación de una especie de sistema operativo web.

1.20. ¿Cómo se caracteriza y diferencia la Web 3.0 de la Web 1.0 y de la Web 2.0?

El desarrollador uruguayo, Andrés Richero, presenta el siguiente esquema:

· Web 1.0 – Personas conectándose a la Web

· Web 2.0 – Personas conectándose a personas – redes sociales, wikis, colaboración, posibilidad de compartir.

· Web 3.0 – Aplicaciones web conectándose a aplicaciones web, a fin de enriquecer la experiencia de las personas, a esto agrega: estado de conciencia del contexto en la Web Geoespacial, autonomía respecto del navegador y construcción de la Web Semántica.

Sobre este último punto, cabe acotar que si bien diferentes factores se conjugan en la Web 3.0 a favor de la semantización de la web, en tanto esto es un proceso, no es privativo de ella. Por tal motivo, quizás sea más apropiado concebir la construcción de la Web Semántica, por fuera y por encima de estos estadíos o instancias.

2.1. Web services

Los Web Services permite la comunicación entre aplicaciones o componentes de aplicaciones de forma estándar a través de protocolos comunes (como http) y de manera independiente al lenguaje de programación, plataforma de implantación, formato de presentación o sistema operativo. Un Web service es un contenedor que encapsula funciones específicas y hace que estas funciones puedan ser utilizadas en otros servidores. Algunas ventajas que presentan los Web services son:

Ø Son programables

Ø Están basados en XML, que es un lenguaje abierto

Ø Son auto descriptivos

Ø Pueden buscar registros de otros Web services

2.2. Beneficios de Web services sobre otras tecnologías.

Los web services presentan algunas diferencias sobre sistemas distribuidos tradicionales, tales como EJB, COM/DCOM, CORBA, SOM/DSOM o DCE. Algunas de las diferencias son las siguientes.

· Escaso acoplamiento. El cliente no necesita conocer nada acerca de la implementación del servicio al que está accediendo, salvo la definición WSDL

· Independencia del lenguaje de programación. El servidor y el cliente no necesitan estar escritos en el mismo lenguaje

· Independencia del modo de transporte. SOAP puede funcionar sobre múltiples protocolos de transporte, como por ejemplo HTTP, HTTPS, HTTP-R, BEEP, JABBER, IIOP, SMTP o FTP.

· Múltiples modos de invocación. Los servicios web soportan tanto invocación estática como invocación dinámica.

· Múltiples estilos de comunicación. Los servicios web soportan tanto comunicación síncrona (RPC) como comunicación asíncrona (mensajería ).

· Extensibilidad. Al estar basados en XML, los servicios web son fáciles de adaptar, extender y personalizar.

2.3. Ejemplos de un web service que estén trabajando.

En la página de www.xmethods.net se encuentra una lista de empresas que utilizan Web services. Una de estas empresas es eraserver.net que utiliza los datos del servicio postal de los Estados Unidos para dar información del código postal actualizado, aun cuando la dirección sea incompleta. Se proporciona los datos de la calle, ciudad y el estado y el programa regresa el código postal.

2.4. Tecnologías se usan en Web services (XML, UDDI,ETC) y como se diferencia de un servicio normal de Web.

2.4.1. XML

Lenguaje extensible de etiquetas. Es un estándar para describir datos y crear etiquetas. Las características especiales son la independencia de datos, o de la separación de los contenidos de su presentación. Es un metalenguaje que permite diseñar un lenguaje propio de etiquetas para múltiples clases de documentos. Los documentos XML se componen de unidades de almacenamiento llamadas entidades (entities), que contienen datos analizados (parsed) o sin analizar (unparsed). Los datos analizados se componen de caracteres, algunos de los cuales forman los datos del documento y el resto forman las etiquetas. Las etiquetas codifican la descripción de la estructura lógica y de almacenamiento del documento. XML proporciona un mecanismo para imponer restricciones en la estructura lógica y de almacenamiento.

2.4.2. SOAP

(Simple Object Access Protocol, Protocolo de Acceso simple a objetos). Especificación XML para la formación de los mensajes intercambiados entre los sistemas distribuidos y la red. Este protocolo deriva de un protocolo creado por David Winer, XML-RPC en 1998. Los mensajes debían tener un formato determinado empleando XML para encapsular los parámetros de la petición. El mensaje está compuesto de tres partes: un sobre, encabezado y el cuerpo. El sobre envuelve al mensaje y contiene el encabezado y el cuerpo; el encabezado es un elemento opcional que provee información para el enrutamiento del mensaje; el cuerpo contiene datos etiquetados como XML.

2.4.3. WSDL

(Web Service Definition Language, Lenguaje de descripción de servicios web). Especificación XML para la formación del documento de descripción de un servicio web. Identifica los métodos, funciones y parámetros necesarios para invocar un determinado servicio. Así, un usuario puede crear una aplicación cliente que comunica con el servicio web.

2.4.4. UDDI

(Universal Description, Discovery and Integration,Descripción, Descubrimiento e Integración). , es un elemento básico sobre el que se asientan los Web services, hace posible que empresas pueden tanto publicar como encontrar servicos web. UDDI provee un mecanismo para que los negocios se "describan" a si mismos y los tipos de servicios que proporcionan y luego se pueden registrar y publicarse en un Registro UDDI. Tales negocios publicados pueden ser buscados, consultados o "descubiertos" por otros negocios utilizando mensajes con SOAP.

Los datos manejados por UDDI se dividen en tres categorías:

· Páginas Blancas: Con información general sobre una empresa (nombre, descripción, información de contacto, dirección y teléfono).

· Páginas Amarillas es muy similar a su equivalente telefónico, e incluyen categorías de catalogación industrial tradicionales, ubicación geográfica, etc. Mediante el uso de códigos y claves predeterminadas, los negocios se pueden registrar y así facilitar a otros servicios la búsqueda usando estos índices de clasificación.

· Páginas Verdes: Con información técnica sobre un servicio web. Generalmente esto incluye un apuntador a la especificación externa y una dirección en la que invocar el servicio.

2.5. Agrupaciones que desarrollan estándares para Web services.

W3C. World Wide Web consortium Fundada en 1994 con 500 miembros Es la principal desarrolalladora de estandares para Web services.

OASIS Organization of the Advancement Structured information standards de los avances de estándares de la información estructurada trabajan con tecnologías XML consiste en 400 miembros mejoran xml

IETF Internet Engineering Task ForceFuerza de tarea de ingeniería en internet. Trabaja sobre las arquitecturas y tecnologías de Internet.

ISO Internacional organization for Standardization tiene 140 países miembros se encarga de desarrollar estándares para mejorar el comercio internacional

2.6. Frameworks de Web services. (SOA)

SOA es el acrónimo de arquitectura orientada a servicios o en inglés Service Oriented Architecture.

Una arquitectura SOA está formada por tres partes: un proveedor, un intermediario y un cliente que no presentan ningún acoplamiento entre ellos.

El proveedor ofrece un servicio determinado y que el cliente no tiene porque conocer directamente. El cliente aprende como utilizar el servicio a partir de la información que le ofrece el intermediario que normalmente simplifica el uso de dicho servicio. El cliente sólo sabe cómo utilizar el servicio, es decir, como enviar y recibir datos pero no conoce ningún detalle de su implementación interna. Un ejemplo típico de arquitectura SOA son los Servicios Web que proporcionan una interfaz de acceso a un servicio escondiendo las particularidades de dicho servicio de modo que sea accesible desde cualquier tipo de cliente a través de protocolos estándar.

2.7. Service Level Ageement

Es un servicio que permite el acceso solo a las personas autorizadas, como un cliente que pago por el servicio. Los parámetros de la subscripción para el web service son determinados por el SLA por un periodo de tiempo

2.8. S2C, Service to custumer

Son web services dirigidos a los consumidores individuales, no a las grandes empresas. Los Web services pueden simplificar el proceso de comunicación y los datos requeridos por el usuario, en especial, los datos que frecuentemente son actualizados. Algunos servicios permiten a los clientes almacenar información y poderla accesar desde cualquier dispositivo conectado a Internet.

2.9. S2B, Service to business

Es la posibilidad que ofrecen los Web services para que las empresas puedan compartir datos sin importar las plataformas que cuenta cada empresa. Los socios comerciales pueden ligar sus bases de datos y pueden compartir los datos actualizados de inventarios y órdenes de compra, con esto, ya no es necesario el uso de los Electronic Data Interchange (EDI).

2.10. S2E Service to employee

El Web services son específicamente diseñado para uso de los empleados. Ayudan a entregar información a los empleados y también ayudan a interactuar entre los empleados.

2.11. e –gobierno

Reúne en un solo sitio la información, servicios y trámites electrónicos de las dependencias y entidades de la Administración Pública Federal, que más impacto tienen en la ciudadanía.

2.12. Registros

Un registro de UDDI contiene descripciones accesibles programadas de negocios y servicios que soporta, también contiene las referencias específicas de la industria que UDDI coloca dentro de una pila de Web services.

2.13. Brokerage

Son Web sites que contienen una lista de los Web services disponibles. Permite poner a los proveedores de servicio la dirección de la Web, la información y los servicios Web

2.14. Retos y amenazas que existen en Web services

· Retos de seguridad basados en el usuario final de un Web services. El problema es que se manda información personal o privada del usuario final por un mensaje SOAP y cada vez que se manda un mensaje, se vuelve a mandar información del usuario final.

· Retos de mantener la seguridad mientras se enrutea a diferentes Web services ya que la información puede ser leída mientras viaja por la red

· El reto de abstraer la seguridad de la red. La seguridad de un Web services no depende solo de la seguridad que se tenga en el Web. Se recomienda el uso de SSL para SOAP y para Web services.

3.1. EbXML

EbXML (Electronic Bussiness XML) es una infraestructura abierta basada en XML que permite que las compañías usen el comercio electrónico de una forma confiable. Es una alternativa para los sistemas EDI (Electronic Data Interchange) ya que permite realizar transacciones entre socios usando XML. Una desventaja de los sistemas EDI es que está dirigido solo para las grandes compañías ya que el costo es muy alto.

3.2. Trading partners

Son organizaciones que están involucradas en las transacciones con EbXML. Existen dos tipos de documentos que contienen información de los sumariales, son el CPP y el CPA.

3.2.1. CPP Collaboration Protocol Profile

Contiene información de las capacidades de los socios comerciales que incluyen la colaboración de negocios e intercambio de información de negocios. Los elementos de XML describen información acerca de los tipos de acuerdos que podrían aceptar los socios, información para intercambio y transporte de documentos y características de los mensajes como la seguridad y la confiabilidad.

3.2.2. CPA Collaboration Protocol Agreetment

Contiene información acerca de los negocios, colaboraciones incluyendo el proceso del negocio del vendedor, capacidades de intercambiar mensajes y los procesos de compra del comprador. Cuando dos negocios se quieren compartir negocios, se negocia el CPA. El CPA describe el servicio de mensajeria específico y los requerimientos del proceso de negocios que se acuerda con el socio.

3.3. El concepto de Proceso de negocios y modelado de la información (BPSS).

Es una especificación que ayuda a una organización a describir su proceso de negocios y escenarios en un CPP. Los desarrolladores pueden usar este modelo para componer los procesos definidos en CPPs. EL BPSS es un conjunto de vocabularios y guías para crear aplicaciones que permita al sistema de negocios implementar ebXML. Declara los elementos de XML y usos de atributos para describir el proceso de negocios del ebXML.

3.4. Elementos esenciales de ebXML

Los elementos esenciales están almacenadas en los registros de ebXML, son blocks de construcción, para un proceso común y reusable que los desarrolladores usan para PPS. Los desarrolladores pueden extender los componentes para crear componentes clientes específicos para una organización CPP. Puede ser una sola pieza de información del negocio o puede consistir en un set de componentes de información del negocio.

3.4.1. Registros

Permiten a los trading partners almacenar y compartir información, es posible buscar registros de ebXML por medio de los registros UDDI de XML.

Permiten a los trading partners aprender de otros socios compartir información. Los registros almacenan CPPs, CPAs, shemas, DTDs, modelo de procesos de negocios, etc. Los registros incluyen servicios para ayudar a las compañías a formar acuerdos con otros negocios. Los registros pueden almacenarse en los Web servers o un un ASP que distribuya y administre servicios sobre una red de sistemas distribuidos. Cada registro debe ser único UDI.

3.4.2. Servicios de mensajería.

ebXML un método estándar para intercambiar mensajes entre los socios comerciales. El servicio de mensajería incluye una especificación que describe como encapsular los mensajes ebXML para diferentes protocolos de transporte. ebXML tiene integrado a SOAP en el sistema de mensajes. El SOAP encapsula la información ebXML que se envía a los socios.

3.4.3. Protocolo de transacciones de negocios (BTP)

Fue diseñado para trabajar con los estándares existentes de mensajes de negocios, para manejar transacciones complejas entre negocios que usan web services u otras tecnologías para transacciones B2B.

La meta principal es definir como las organizaciones pueden coordinar sus sistemas para archivar automáticamente las transacciones de negocio.

3.5. Web Services Flow language

Es un lenguaje basado en XML para incorporar los Web services como parte de las operaciones requeridas para realizar un proceso o transacción. Ofrece un framework en el cual los proveedores y consumidores de los Web services pueden definir el trabajo a realizar y el flujo del trabajo.

3.6. Universal Business language

El UBL usa parámetros de ebXML para desarrollar un conjunto de documentos de negocios XML. La intención es de crear un conjunto de estándares internacionales abiertos para los documentos del e-commerce.

3.7. Modelado de BP y queries de BP.

EL BPML esta desarrollado para la administración de los procesos, es un metalenguaje para modelar los procesos de negocio. Provee un método para describir los procesos de negocios y compartir los detalles del proceso usando XML. Las compañías pueden usarlo para modelar y manejar las ordenes , los cuidados del cliente, plan de demanda y el proceso de desarrollo de productos.

El BPQL es usado por el BPML para interactuar con la infraestructura de la administración del negocio que incluye un process server , que es el que ejecuta los procesos y el process repository, que es donde se despliegan los procesos.

4.1. Características de los Web Services

Un desarrollador puede incluir en sus sitios soluciones sentencias, es decir, instrucciones que consuman Web Services de terceros o propios como por ejemplo aquellos que proporcionan los datos meteorológicos para una localidad determinada, las cotizaciones de determinadas monedas, la cartelera de películas, el calendario o agenda de un especialista médico, etc.

Pensando un poco más en forma comercial, ¿Qué pasaría si por ejemplo estuvieras trabajando en tu procesador de texto en un idioma para el cual no tienes un corrector ortográfico ni sintáctico instalado (quizás no exista para instalar), pero deseas realizar la revisión del documento a toda costa? Bien, perfectamente podría haber una opción en el menú de este procesador que de alguna forma localice un Web Service en Internet que brinde esta funcionalidad, y lo más interesante aún para quien lo haya desarrollado es que puede solicitar al usuario que se subscriba para su uso. Como ves, todos ganan en esta transacción.

El ejemplo anterior muestra una realidad a la que no podemos estar ajenos. Es un replanteo de la estrategia utilizada por los desarrolladores quienes ahora, al realizar una aplicación, no deben pensar únicamente en el lugar físico donde la misma va a ejecutarse sino en que esa aplicación deberá estar interconectada con otras computadoras, corriendo otras aplicaciones quizás en otras plataformas y lenguajes, pero usando protocolos y estándares universales. El intercambio se intensificará muchísimo más y quizás existan por ejemplo “proveedores de dominios de datos” como ser los países, de forma tal que la aplicación que yo realice en lugar de crear toda la lógica para manejar las tablas y el cargado de los datos para el concepto PAIS, se limite a consumir un Web Service que me tome esta información de algún lugar en Internet. Imagino una reutilización aún mayor de funcionalidades y una colaboración e intercambio de lógica a nivel mundial. Quizás sea muy ambicioso en este planteo.

Pasando al terreno más técnico y práctico de este artículo, existen algunas consideraciones y conceptos que es necesario mencionar para comenzar a entender el tema:

· Un Web Service puede ser registrado para poder dejarlo a disposición de otros usuarios y para que los mismos puedan localizarlo. Un mecanismo para registrar estos servicios es por medio de UDDI, sigla que corresponde a Universal Description , Discovery and Integration, un “repositorio de Web Services”. Para registrar un servicio tendrás que tener en cuenta que debes suministrar la información de tu empresa, en qué categorías ubicarías tu servicio y la interfaz a utilizar para consumir este servicio.

· El mecanismo utilizado por un Web Service para especificar de qué forma hay que proporcionarle los datos, de manera tal que cualquiera pueda interaccionar con el mismo, es por medio de lenguaje XML. Esta información se almacena en un archivo llamado WSDL (Web Services Description Language), el cual contiene un documento XML junto con la descripción de ciertos mensajes SOAP y cómo deben intercambiarse, así como también dónde está el recurso del servicio y con qué protocolo debe dialogar quien lo consume.

· El protocolo de comunicación utilizado es el SOAP generalmente, el cual es relativamente sencillo de utilizar.

· Los Web Services utilizan protocolos comúnmente conocidos y difundidos tales como el formato XML, TCP/IP como protocolo de transporte y HTTP como protocolo de transferencia de hipertexto.

4.2. ¿Qué es SOAP?

SOAP es un protocolo que define el formato XML para los mensajes de intercambio en el uso de un Web Service. Para aquellos programadores que solían utilizar llamadas del tipo RPC, SOAP también las soporta. Adicionalmente, es posible mediante SOAP definir un mensaje HTTP y este punto es de especial interés puesto que el protocolo imprescindible para Internet es HTTP.

4.3. Un ejemplo práctico

A partir de ahora describiré en unos pocos pasos un ejemplo práctico y sencillo de creación de un Web Service y una muestra de cómo consumirlo desde una aplicación cliente, en este caso una simple planilla de Microsoft Excel:

Paso 1: Lo primero será crear un proyecto Visual Basic del tipo ASP .NET Web Service, al que llamaremos DameCotizacion

Figura 1.

Paso 2: Al archivo Service1.asmx, que se crea una vez generado el proyecto, lo renombramos DameCotizacion.asmx y lo establecemos como Pagina de Inicio del proyecto

Figura 2.

Paso 3: Ingresando a la ventana de código del archivo DameCotizacion.asmx, en la zona del , agregamos el siguiente código:

Public Function GetCotizacion(ByVal strmoneda As String) As String

'Objetivo: Devolver cotización para una moneda en pesos uruguayos

' Obviamente esto es un ejemplo por lo que esta info que

' se presenta estática se tomaría de una base de datos

'Acepta: strmoneda - un id para la moneda de dos caracteres.

'Devuelve: cotizacion de dicha moneda en pesos uruguayos

Select Case UCase(Trim(strmoneda))

Case "DO"

'dolar

Return "30"

Case "RE"

'real

Return "9.9"

Case "EU"

'Euro

Return "33"

End Select

End Function

Para verificar el correcto funcionamiento de esta aplicación, vamos a ejecutarla. Para ello apretamos F5 y el resultado esperado se verá en Internet Explorer. Como puedes ver, se ofrece el método GetCotizacion() definido en el código anterior

Figura 3.

Si cliqueamos sobre este método, podremos ver la especificación del mismo y la definición del tipo de intercambio de mensajes

Figura 4.

Paso 4: Podemos comprobar su funcionamiento colocando el valor EU (código que establecimos para el Euro) y cliqueando en Invoke. El valor esperado por el método es del tipo string y deberá ser uno de los tipo de monedas (DO, RE ó EU) definido en nuestro método.

El resultado debería ser un mensaje en XML como se muestra en la Figura 5, mostrando el valor definido para la moneda de código EU:

Figura 5.

Pongamos a trabajar nuestro Web Service en una aplicación práctica. Supongamos que tenemos una planilla de Microsoft Excel donde tenemos artículos cuyos precios están en su moneda original y queremos que aparezca su valor en Pesos Uruguayos. Para esto consumiremos el Web Service creado en los pasos anteriores (DameCotizacion) que proporcionando el código de la moneda me devuelve la cotización correspondiente.

Paso 5: Crearemos una planilla de Microsoft Excel como se muestra en la Figura 6, donde agregaremos un botón cuyo nombre y Caption será Cotizar:

Figura 6.

Paso 6: En la celda E2 , la fórmula para calcular el valor del artículo en Pesos Uruguayos es =D2*C2. La columna Cotización será alimentada una vez que se oprima el botón Cotizar, el cual disparará un evento que consumirá el Web Service DameCotizacion y retornará en cada celda Cotización el valor correspondiente.

Paso 7: Haciendo doble clic sobre el botón Cotizar ingresaremos a la ventana de código Visual Basic posicionados en el evento Click de dicho botón.

Previo a esto último, relacionaremos nuestro Web Service a nuestra planilla mediante el uso de la herramienta Microsoft Web Services Toolkit (Paso 8). Para esto, desde el menú Herramientas de la ventana de código Visual Basic, seleccionamos la opción “Web Service References ...”

Figura 7.

En esta ventana seleccionamos Web Service URL y colocamos "http://localhost/DameCotizacion/DameCotizacion.asmx" en el cuadro de texto URL, y apretamos el botón Search. Esta acción deberá traer como resultado nuestro Web Service DameCotizacion en la sección Search Results, el cual seleccionaremos, donde podrá verse que está disponible nuestro método GetCotizacion(). Cliquearemos entonces Add.

Paso 9: El código del evento Cotizar_Click() es el siguiente:

Private Sub Cotizar_Click()

Dim clsCotizacion As clsws_DameCotizacion

Dim monedas As Range

Dim moneda As Range

Dim cotizacion As String

clsCotizacion = New clsws_DameCotizacion

monedas = Range(Range("b2"), Range("b65536").End(xlUp))

Application.ActiveSheet.Range("b2").Activate()

For Each moneda In monedas

cotizacion = clsCotizacion.wsm_GetCotizacion(moneda)

moneda.Offset(0, 1).Value = Val(cotizacion)

Next moneda

End Sub

Si todo sale como es de esperar, el resultado de oprimir el botón Cotizar deberá ser el que se muestra en la Figura 8:

Figura 8.

Como verás, este es un simple ejemplo que muestra cómo consumir un Web Service desde una aplicación cliente, en este caso Microsoft Excel, que ilustra dos puntos interesantes: la facilidad de implementación del mismo y la potencia que nos brinda. Basta conocer un proveedor de un servicio de cotizaciones de moneda para mantener nuestra planilla al día con las últimas cotizaciones del mercado bursátil.

Para aquellos desarrolladores que ya hacían uso de incluir referencias a objetos COM en sus herramientas quizás esto no sea muy novedoso, pero en el caso de los objetos COM, los mismos debían estar físicamente en la computadora cliente. En el caso de los Web Services, estamos hablando de compartir recursos que habiten en la Intranet corporativa o más aún, en Internet y en sitios bien dispersos en el mundo.

Para los que quieran hacer números y le quieran sacar un beneficio económico, ¿Qué ocurriría si tú fueras un proveedor de Web Services y solicitaras la suscripción para el uso de los mismos a tus clientes a lo largo y ancho del planeta? Interesante, ¿No es así?

Más aún, no necesariamente el escenario se limita a una aplicación cliente consumiendo un Web Service sino que a su vez un Web Service podría consumir otro Web Service para poder armar la información de respuesta a retornar al cliente. No hace falta imaginar un escenario de este tipo pues esto ya es posible.

4.4. Hacia dónde vamos

Si bien se ha avanzado mucho al respecto y hay infinidad de desarrolladores trabajando en este tema, existen aspectos a mejorar para catapultar aún más esta funcionalidad. Algunas características a mejorar pasan por temas relacionados con la seguridad (autorización, autenticación y cifrado) en el intercambio de mensajes, manejar el modelo transaccional y poder confirmar la entrega efectiva de los mensajes que se intercambian a través de los Web Services.

Adicionalmente, se continúa trabajando en la estandarización de los principales actores, como ser el WDSL y SOAP. Muchos fabricantes seguirán contribuyendo, elaborando herramientas para facilitar el manejo y elaboración de Web Services como es el caso de Microsoft y su Web Services Toolkit para Office 2003, que actualmente está en su versión 2.01.

CASOS Y EJEMPLOS

A. Ejemplo de un Web Service Transaccional

El ejemplo que utilizaremos asume que tenemos una política de procesar una orden sólo si todas las líneas de detalle pueden surtirse a partir del inventario. Si uno de los productos no tiene suficiente inventario, toda la orden es anulada.

Utilizaremos la table Products de la base de datos ejemplo Northwind. Podremos surtir un producto sólo si los UnitsInStock tienen suficiente cantidad. Por ejemplo, si tratamos de surtir 20 unidades de Aniseed Syrup, con el ProductID 3, la orden fallará, pues sólo hay 13 unidades actualmente.

Proyecto WebServOrdersTransactional

Haremos un proyecto tipo ASP.NET Web Service, al que llamaremos WebServOrdersTransactional:

En el Solution Explorer, renombré el archivo Service1.asmx a ServOrdersTransactional.asmx, sólo para que tenga un nombre más descriptivo:

Además, cambié el nombre del servicio:

Imports System.Web.Services

Namespace:="http://tempuri.org/WebServOrdersTransactional/Service1")> _

Public Class ServOrdersTransactional

Inherits System.Web.Services.WebService

Referencia a System.EnterpriseServices

Para obtener la funcionalidad transaccional, debemos referenciar la librería SystemEnterpriseServices.

En el Solution Explorer, en References, dar botón derecho y pedir: References:

De las referencias .NET escogemos System.EnterpriseServices:

Código del Web Service

Imports System.Web.Services

Namespace:= _

"http://tempuri.org/WebServOrdersTransactional/ServOrdersTransactional")> _

Public Class ServOrdersTransactional

Inherits System.Web.Services.WebService

(Web Services Designer Generated Code)

Para que sea transaccional, el atributo transactionOption debe ser .Required o .RequiresNew.
No hay diferencia funcional entre estas dos opciones

transactionoption:=EnterpriseServices.TransactionOption.Required)> _

Public Sub ProcessOrder(ByVal dsOrderLines As DataSet)

' Asumiremos que dsOrderLines trae una sola tabla,

' con una columna con el código del producto: ProductID

' y otra columna con la cantidad a restar: amount

Dim sSQL As String _

= "SELECT * FROM Products WHERE ProductID=@ProductID"

Dim sCnn As String _

= "server=(local);integrated security=sspi;database=Northwind"

Dim da As New SqlClient.SqlDataAdapter(sSQL, sCnn)

Dim paramProductID As _

New SqlClient.SqlParameter( _

"@ProductID", SqlDbType.Int)

da.SelectCommand.Parameters.Add(paramProductID)

Dim i As Integer

For i = 0 To dsOrderLines.Tables(0).Rows.Count - 1

' Lee datos enviados en una fila del DataSet

paramProductID.Value = _

dsOrderLines.Tables(0).Rows(i).Item("ProductID")

Dim cantidadARestar As Int64 = _

dsOrderLines.Tables(0).Rows(i).Item("amount")

Dim ds As New DataSet

da.Fill(ds, "Products")

If ds.Tables(0).Rows.Count <> 1 Then

' Debería ser sólo 1 fila, si no es así, aborta

System.EnterpriseServices.ContextUtil.SetAbort()

Return

Else

If ds.Tables(0).Rows(0).Item("UnitsInStock") _

>= cantidadARestar Then

' Si hay existencias, entonces, restar

ds.Tables(0).Rows(0).Item("UnitsInStock") _

-= cantidadARestar

Aborta transacción

Dim cb As New SqlClient.SqlCommandBuilder(da)

da.Update(ds, "Products")

Else

System.EnterpriseServices.ContextUtil.SetAbort()

Return

End If

' Si llega hasta acá, es que todas las líneas de detalle

Commit de la transacción

' tuvieron éxito, así que hace un "commit"

' de la transacción

System.EnterpriseServices.ContextUtil.SetComplete()

End Sub

End Class

B. Aplicación Cliente tipo Windows Form: WinAppOrdersTransactional

Crearemos un nuevo proyecto, que hará uso del WebService:

En el Solution Explorer, cambié el nombre del archivo del formulario de Form1.vb a frmOrdersTransactional.vb:

Además, en el formulario mismo, modifiqué las siguientes propiedades:

(Name) frmOrdersTransactional

Text Órdenes Transaccionales

Nota:

Al cambiar el (Name) del formulario, hay que ir a Solution Explorer, dar click derecho sobre el proyecto WinAppOrdersTransactional, pedir Properties, y en Common Properties, General, Startup Object: pedimos que el proyecto comience con: frmOrdersTransactional.

Referencia al Web Service

Vamos a referenciar el Web Service transaccional para poderlo utilizar en el proyecto cliente.

En el campo de la dirección URL ingresamos la dirección del Web Service:

http://localhost/WebServOrdersTransactional/ServOrdersTransactional.asmx

Y para el Web reference name: decidí ponerle el nombre: webrefOrdersTransactional:

Luego oprimimos Add Reference:

DataSet

Agregaremos un Typed DataSet para ingresar las líneas de la Orden, las cuales serán enviadas al Web Service. En el Solution Explorer, damos click derecho sobre el proyecto WinAppOrdersTransactional, y pedimos un DataSet:

Agregamos un Element que contiene dos Element, para el código del producto ProductID, y para la cantidad ordenada: amount.

Regresamos al formulario y colocamos un DataGrid, que llamaremos: dgOrders, y un botón, que tendrá el nombre (Name): btnProcess, y texto: Procesar

En el ToolBox, escogemos Data y de allí arrastramos un DataSet.

Renombré el control resultante: dsOrders1 a dsOrders.

Para el DataGrid dgOrders, especificamos los siguientes parámetros:

DataSource dsOrders

DataMember Orders

Código

Public Class frmOrdersTransactional

Inherits System.Windows.Forms.Form

(Windows Form Designer generated code)

Private Sub btnProcess_Click( _

ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles btnProcess.Click

Dim oOrdersTransactional As _

New webrefOrdersTransactional.ServOrdersTransactional

oOrdersTransactional.ProcessOrder(Me.DsOrders)

End Sub

End Class

Corrida

Resulta que para el código de producto (ProductID) igual a 3 (Aniseed Syrup), sólo hay 13 unidades disponibles.

Los saldos quedaron iguales:

Ahora probaremos para el producto 3 con la cantidad (amount) número 10:

Hoy sí se efectuó la transacción, restando 15 del 2:Chang para quedar con 2 en UnitsInStock,

y restando 10 del 3:Aniseed Syrup, para quedar con 3 en UnitsInStock.

5. BIBLIOGRAFÍA

LIBROS

Ø RIBAS LEQUERIA, Joan 2003, Web Services (Guías Practicas)

Ø Alonso, 2004 ,Web Services:Conceptos, Arquitectura y Aplicaciones, Springer - German language

Ø Sanjiva Weerawarana, Francisco Curbera, Frank Leymann, Tony Storey, Donald F. Ferguson 2005, Arquitectura de la Plataforma Web Service, Prentice Hall PTR

VIDEOS

Ø http://www.youtube.com/watch?v=sjeLotFrJtk

Ø http://www.youtube.com/watch?v=zpsmw2fFA7s&feature=related

Ø http://www.youtube.com/watch?v=I6y97h7oKc0&feature=related

Ø http://www.youtube.com/watch?v=APsFLEW-JFI&feature=related

Ø http://www.youtube.com/watch?v=kB3jAkjf-JE&feature=related

Ø http://www.youtube.com/watch?v=8L1qNBZdT90&feature=related

Ø http://www.youtube.com/watch?v=b_DcUkNwsZ0&feature=related

Ø http://www.youtube.com/watch?v=1Uo8If2sKPg&feature=related

ANEXOS

Sistema puesta a tierra

2011-05-31T09:28:00.001-07:00

“AÑO DEL CENTENARIO DE MACHU PICCHU PARA EL MUNDO”

TEMA:

SISTEMA PUESTA A TIERRA

CURSO:

REDES Y COMUNICACIONES II

DOCENTE:

ING.

ALUMNO:

DUQUE ESCOBAR DAVI DANIEL

PIURA - PERÚ

2011

INDICE

INTRODUCCION.. 3

1. Concepto. 4

2. ¿Por qué es importante su instalación?. 4

3. Finalidad De Las Puestas A Tierra. 4

4. Conceptos Fundamentales En Estudios De Resistividad. 5

4.1. Influencia De La Humedad. 6

4.2. Compactación.. 6

5. Métodos Para La Reducción De La Resistencia Eléctrica. 6

6. Tratamiento Químico Del Suelo. 7

7. Tipos De Tratamiento Químico. 7

7.1. Cloruro de Sodio + Carbón Vegetal 8

7.2. Bentonita. 8

7.2.1. Bentonita Sódica. 8

7.2.2. Bentonita Cálcica. 8

INTRODUCCION

Este trabajo está enfocado solo a una parte muy importante de las protecciones de electricidad como son las protecciones de puesta a tierra.

También se conocerán conceptos básicos como son los términos y lenguaje de ésta parte de la electricidad.

Por la importancia de los sistemas de puesta a tierra, es necesario conocer la mayor cantidad de factores que hacen variar la resistencia del sistema. Algunos de estos factores pueden ser: las condiciones climatológicas, estratigrafía, compactación del terreno, características físicas del electrodo de conexión a tierra, etc.

Otro aspecto importante que se menciona en este trabajo son las características que debe tener el conductor de sistema a tierra, como son: la sección transversal, longitud, material, etc.

1. Concepto

La puesta a tierra corresponde al conjunto de electrodos y partes conductoras que en contacto con tierra, permiten drenar hacia ésta, todas las corrientes de falla, peligrosas para la integridad de las personas y de los equipos electrónicos. La conexión a tierra eficaz conduce la electricidad indeseable hacia tierra alejando el peligro en forma segura.

2. ¿Por qué es importante su instalación?

Ante las posibles fallas de aislamiento de los conductores en algunos equipos eléctricos, se corre el riesgo de que la cubierta metálica de éstos quede con tensión eléctrica. El contacto directo con un equipo electrizado puede producir en el ser humano desde alteraciones del ritmo cardíaco hasta la muerte. La conexión a tierra eficaz conduce la electricidad indeseable hacia tierra alejando el peligro en forma segura. La cubierta metálica ("shield"), o apantallamiento puesto a tierra, es usual en muchas líneas de transmisión de la información, porque protege a los equipos electrónicos contra perturbaciones electromagnéticas. También sirve como referencia de las señales en un equipo electrónico y para eliminar las diferencias de potencial entre diferentes componentes de un sistema de comunicaciones o control automático. Todas estas y otras aplicaciones merecen un tratamiento singular y, por lo tanto, otros artículos que profundicen en ellas.

3. Finalidad De Las Puestas A Tierra

Los objetivos principales de las puestas a tierra son:

a. Obtener una resistencia eléctrica de bajo valor para derivar a tierra Fenómenos Eléctricos Transitorios (FETs.), corrientes de fallas estáticas y parásitas; así como ruido eléctrico y de radio frecuencia.

b. Mantener los potenciales producidos por las corrientes de falla dentro de los límites de seguridad de modo que las tensiones de paso o de toque no sean peligrosas para los humanos y/o animales.

c. Hacer que el equipamiento de protección sea más sensible y permita una rápida derivación de las corrientes defectuosas a tierra.

d. Proporcionar un camino de derivación a tierra de descargas atmosféricas, transitorios y de sobretensiones internas del sistema.

e. Ofrecer en todo momento y por el tiempo de vida útil del SPAT (±20 años) baja resistencia eléctrica que permita el paso de las corrientes de falla.

f. Servir de continuidad de pantalla en los sistemas de distribución de líneas telefónicas, antenas y cables coaxiales.

4. Conceptos Fundamentales En Estudios De Resistividad

Las corrientes eléctricas que nos interesan no recorren conductores lineales (hilos y cables) como en las instalaciones y aparatos eléctricos usuales, sino que se mueven en un medio tridimensional por lo que debemos estudiar las leyes físicas a las que obedecen estas corrientes.

Para hacer el problema fácilmente abordable desde el punto de vista matemático, habremos de estilizar las condiciones reales, suponiendo que el subsuelo se compone de varias zonas, dentro de cada una de las cuales la resistividad suponemos constantes separadas entre sí por superficies límite perfectamente planas. A pesar de esta simplificación, el problema es matemáticamente muy difícil y solo ha sido resuelto en casos muy sencillos.

A continuación la tabla de tipos de suelos con sus respectivas resistividades.

4.1. Influencia De La Humedad

La resistividad del suelo sufre alteraciones con la humedad. Esta variación ocurre en virtud de la activación de cargas eléctricas predominantemente iónicas por acción de la humedad, un porcentaje mayor de humedad hace que las sales presentes en el suelo o adicionadas a propósito se disuelvan formando un medio electrolítico favorable al paso de la corriente iónica. Así mismo un suelo específico con concentración diferente de humedad presenta una gran variación de su resistividad, siendo por lo tanto muy susceptible de los cambios estacionales.

4.2. Compactación

La compactación de un suelo a condiciones naturales, es la atracción que ejerce la gravedad con toda materia existente, habiéndose logrado una agregación de materiales a través del tiempo en forma intima entre ellos, quedando por lo tanto pocos espacios sin ocupar.

Cuando se hacen trabajos de excavación todo este entramado natural se rompe y al volver a llenarse las excavaciones en forma manual nos queda material aparentemente sobrante; lo ideal seria que con el cuidado necesario se logre regresar todo el material a su estado anterior para lograr así una compactación deseable que permita el firme contacto de los electrodos con el suelo y sales agregadas que permita una circulación de corrientes de falla en forma fluida.

5. Métodos Para La Reducción De La Resistencia Eléctrica

Existen distintos métodos para lograr la reducción de la resistencia eléctrica, aunque todos ellos presentan un punto de saturación que es conveniente conocer para evitar diseños antieconómicos. Los métodos para la reducción son los siguientes:

ü El aumento del número de electrodos en paralelo

ü El aumento de la distancia entre ejes de los electrodos

ü El aumento de la longitud de los electrodos.

ü El aumento del diámetro de los electrodos

ü El cambio del terreno existente por otro de menor resistividad.

ü El tratamiento químico electrolítico del terreno.

6. Tratamiento Químico Del Suelo

El tratamiento químico del suelo surge como un medio de mejorar y disminuir la resistencia eléctrica del SPAT sin necesidad de utilizar gran cantidad de electrodos.

Para elegir el tratamiento químico de un SPAT se deben considerar los siguientes factores:

ü Alto % de reducción inicial

ü Facilidad para su aplicación

ü Tiempo de vida útil (del tratamiento y de los elementos del SPAT)

ü Facilidad en su reactivación

ü Estabilidad (mantener la misma resistencia durante varios años)

Las sustancias que se usan para un eficiente tratamiento químico deben tener las siguientes características:

ü Higroscopicidad -Alta capacidad de Gelificación

ü No ser corrosivas -Alta conductividad eléctrica

ü Químicamente estable en el suelo -No ser tóxico

ü Inocuo para la naturaleza

7. Tipos De Tratamiento Químico

Existen diversos tipos de tratamiento químico para reducir la resistencia de un SPAT los más usuales son:

ü Cloruro de Sodio + Carbón vegetal

ü Bentonita

ü Thor-Gel

7.1. Cloruro de Sodio + Carbón Vegetal

El Cloruro de Sodio forma una solución verdadera muy conductiva que se precipita fácilmente junto con el agua por efecto de la percolación, capilaridad y evapotranspiración; la solución salina tiene una elevada actividad corrosiva con el electrodo, reduciendo ostensiblemente su tiempo de vida útil, la actividad corrosiva se acentúa si el electrodo es de hierro cobreado (copperweld).

7.2. Bentonita

Las bentonitas constituyen un grupo de sustancias minerales arcillosas que no tienen composición mineralógica definida y deben su nombre al hecho de haberse descubierto el primer yacimiento cerca de Fort Benton, en los estratos cretáceos de Wyoming en 1848; Aun cuando las distintas variedades de bentonitas difieren mucho entre sí en lo que respecta a sus propiedades respectivas, es posible clasificarlas en dos grandes grupos:

7.2.1. Bentonita Sódica

En las que el ion sodio es permutable y cuya característica más importante es una marcada tumefacción o hinchamiento que puede alcanzar en algunas variedades hasta 15 veces su volumen y 5 veces su peso.

7.2.2. Bentonita Cálcica

En las que el ion calcio es permutable, tiene menor capacidad para absorber agua y por consiguiente solo se hinchan en la misma proporción que las demás arcillas.

7.3. Thor-Gel

Es un compuesto químico complejo que se forma cuando se mezclan en el terreno las soluciones acuosas de sus 2 componentes. El compuesto químico resultante tiene naturaleza coloidal, formando una malla tridimensional, que facilita el movimiento de ciertos iones dentro de la malla, de modo que pueden cruzarlo en uno u en otro sentido; convirtiéndose en un excelente conductor eléctrico.

METODOLOGÍAS DE DESARROLLO DE APLICACIONES WEB

2011-05-31T09:24:00.000-07:00

“AÑO DEL CENTENARIO DE MACHU PICCHU PARA EL MUNDO”

TEMA:

METODOLOGÍAS DE DESARROLLO DE APLICACIONES WEB

CURSO:

INGENIERÍA WEB

DOCENTE:

ING. ANTHONY PAUL TÁVARA RAMOS

ALUMNO:

DUQUE ESCOBAR DAVI DANIEL

PIURA - PERÚ

2011

INDICE

1.1.1.1. Fase de Análisis. 9

1.1.1.2. Fase de Diseño. 9

1.1.1.3. Fase de Construcción, 10

1.2..... OOHDM.. 10

1.2.1. Fases. 11

1.2.1.1. Fase Conceptual 11

1.2.1.2. Fase Navegacional 11

1.2.1.3. Fase de Interfaz Abstracta. 13

1.2.1.4. Fase Implementación. 13

1.3..... SOHDM.. 15

1.3.1. Fases. 16

1.3.1.1. Fase de Análisis, 16

1.3.1.2. Fase de Modelado de Objetos, 16

1.3.1.3. Fase de Diseño de Vistas, 16

1.3.1.4. Fase de Diseño Navegacional, 16

1.3.1.5. Fase de Diseño de la Implementación, 16

1.3.1.6. Fase de Construcción, 17

1.4..... WSDM.. 17

1.4.1. Fases. 17

1.4.1.1. Fase de Modelo de Usuario. 17

1.4.1.1.1. Clasificación de usuarios:. 18

1.4.1.1.2. Descripción de los grupos de usuarios. 18

1.4.1.2. Fase de Diseño Conceptual 19

1.4.1.3. Fase de Diseño de Implementación. 19

1.4.1.4. Fase de Realización de Implementación. 20

1.5..... RNA.. 21

1.5.1. Fases. 21

1.5.1.1. Fase de Análisis del Entorno. 21

1.5.1.2. Fase de Definición de Elementos. 22

1.5.1.3. Fase de Análisis del Conocimiento. 22

1.5.1.4. Fase de Análisis de Navegación. 22

1.5.1.5. Fase de Implementación del Análisis. 22

2.1..... ¿El por qué de una Metodología de Desarrollo Web? 23

2.2..... Evolución de las metodologías de Desarrollo Web. 23

2.1.1. Primera Generación. 23

2.1.2. Segunda Generación. 23

2.1.3. Tercera generación. 24

2.3..... ¿Qué es UWE?.. 24

2.4..... Principales aspectos. 25

2.1.4. Uso de una notación estándar. 25

2.1.5. Definición de métodos. 25

2.1.6. Especificación de Restricciones. 25

2.5..... Fases del Desarrollo Web. 25

2.5.1. Análisis de Requisitos. 25

2.5.2. Diseño Conceptual 25

2.5.3. Diseño Navegacional 26

1.5.1.6. Modelo del Espacio de Navegacional. 26

1.5.1.7. Modelo de la Estructura de navegación. 26

2.5.4. Diseño de Presentación. 26

3.1..... WSDM: Web Site Design Method. 1997. 27

3.2. SOHDM: Scenario-based Object-Oriented Hypermedia Design Methodology. 1998 27

3.3..... RNA: Relationship Navigational Analysis. 1998 27

3.4..... HFPM: Hypermedia Flexible Process Modeling. 1999 28

3.5..... OOHDM: Object Oriented Hypermedia Design Model. 28

3.6..... UWE: UML-Based Web Engineering. 1999. 29

3.7..... W2000. 2001. 29

3.8..... UWA: Ubiquituos Web Applications. 2001. 29

3.9..... NDT: Navigational Development Tecniques. 2004 30

3.10... DDDP: Design-driven Requirements Elicitation. 2004 30

4.1..... Introducción a OOHDM.. 31

4.1.1. Diseño Conceptual 32

4.1.2. Diseño Navegacional 32

4.1.3. Diseño de Interfaz Abstracta. 33

4.1.4. Implementación. 34

5.1..... APRECIACIÓN PERSONAL.. 35

CONCLUSIONES.. 36

BIBLIOGRAFIA.. 38

ANEXOS.. 40

INTRODUCCIÓN

El desarrollo de aplicaciones web involucra decisiones no triviales de diseño e implementación que inevitablemente influyen en todo el proceso de desarrollo, afectando la división de tareas. Los problemas involucrados, como el diseño del modelo del dominio y la construcción de la interfaz de usuario, tienen requerimientos disjuntos que deben ser tratados por separado.

El alcance de la aplicación y el tipo de usuarios a los que estará dirigida son consideraciones tan importantes como las tecnologías elegidas para realizar la implementación. Así como las tecnologías pueden limitar la funcionalidad de la aplicación, decisiones de diseño equivocadas también pueden reducir su capacidad de extensión y reusabilidad. Es por ello que el uso de una metodología de diseño y de tecnologías que se adapten naturalmente a ésta, son de vital importancia para el desarrollo de aplicaciones complejas.

Existen en la actualidad tecnologías ampliamente usadas para el desarrollo de aplicaciones web, pero muchas de ellas obligan al desarrollador a mezclar aspectos conceptuales y de presentación.

La elección de tecnologías complejas demora el proceso e incrementa los costos, pero en ocasiones permite adecuarse a metodologías de diseño más fácilmente. Tal es el caso de las tecnologías orientadas a objetos, las cuales tienden a demorar el desarrollo en etapas tempranas. El tiempo de desarrollo en la actualidad es crítico, tanto por razones de marketing como por límites en el presupuesto y los recursos

MARCO TEÓRICO

1.1. EORM

Es una Metodología de Relación entre Objeto (Enhanced Object Relationship Methodology), es definido por un proceso iterativo que se concentra en el modelado orientado a objetos por la representación de relaciones entre los objetos (acoplamientos) como objetos, es por ello que fue una de las primeras propuestas para Web centrada en el paradigma de la orientación a objetos. Se basa en muchas de las ideas que se definen en HDM, pero las traslada a la orientación a objetos. La adopción del enfoque orientado a objetos garantiza todas las ventajas reconocidas para esta técnica de modelado, como la flexibilidad (posible existencia de múltiples formas de relaciones entre nodos) y la reutilización, por la existencia de una librería de clases de enlaces que pueden ser reutilizados en diferentes proyectos de desarrollo hipermedia.

Para automatizar la aplicación de la metodología EORM, su autor ha desarrollado, en los laboratorios de investigación de IBM, una herramienta denominada ODMTool que, junto a un generador comercial de Interfaces Gráficas de Usuario denominado ONTOS Studio y un Sistema de Gestión de Base de Datos Orientado a Objetos (SGBDOO), permite el diseño interactivo de esquemas EORM y la generación de código fuente, inicialmente en C++, de las clases incluidas en estos esquemas. El SGBDOO ofrece un repositorio de objetos que permite la compartición de la información de los esquemas entre las herramientas (ODMTool, ONTOS Studio) y las aplicaciones hipermediales desarrolladas.

Esta metodología tiene las siguientes ventajas: Encajamiento de relaciones semánticas en construcciones extensibles, pudiendo participar en otras relaciones pudiendo ser parte de bibliotecas reutilizables. EORM distingue dos tipos de relaciones orientadas a objetos: Relaciones de generalización y relaciones definidas por el usuario. Mientras que los primeros se concentran como en la semántica asociada entre ellas, los segundos confían totalmente en la especificación del usuario

La semántica de vínculos básicos de clases que se manejan, son las siguientes de manera resumida:

SimpleLink

Es la raíz vínculo básica de clase que proporciona capacidad de interconexión, incluido funciones para la creación, supresión y recorrido

NavigationalLink

Proporciona mecanismos para enlaces hipermedia que incluye el almacenamiento de creación de tiempo e información histórica. Se hereda de simpleLink

NodeToNode

Es un vínculo que hereda de NavigationalLink y proporcionar un objeto a un objeto Hipermedia de vínculo de funcionalidad

SpanToNode

Se hereda de NavigationalLink. Vincula el contenido de un objeto a otro objeto.

StructureLink

Se hereda de SimpleLink y la raíz de los vínculos estructurales. Se inserta después creación en el contexto estructural.

SetLink

Es una structureLink que proporciona acceso a un objeto en una desordenada colección de objetos.

ListLink

Es un structureLink que proporciona acceso a un objeto en una colección ordenada de objetos.

1.1.1. Fases

Podemos mencionar que esta metodología consta de las siguientes fases según el siguiente diagrama de flujo:

1.1.1.1. Fase de Análisis

Se trata de orientar a objetos al sistema, sin considerar los aspectos hipermediales del mismo, obteniéndose para ello un Modelo de Objetos con la misma notación utilizada en OMT, que refleje la estructura de la información (mediante clases de objetos con atributos y relaciones entre las clases) y el comportamiento del sistema (a través de los métodos asociados a las clases de objetos)

1.1.1.2. Fase de Diseño

Procede a modificar el modelo de objetos obtenido durante el análisis añadiendo la semántica apropiada a las relaciones entre clases de objetos para convertirlas en enlaces hipermedia, obteniendo finalmente un modelo enriquecido, que su autor denomina EORM (Enhanced Object-Relationship Model), en el que se refleje tanto la estructura de la información (modelo abstracto hipermedial compuesto de nodos y enlaces) como las posibilidades de navegación ofrecidas por el sistema. sobre dicha estructura, para lo cual existirá un repositorio o librería de clases de enlaces, donde se especifican las posibles operaciones asociadas a cada enlace de un hiperdocumento, que serán de tipo crear, eliminar, atravesar, siguiente, previo etc., así como sus posibles atributos (fecha de creación del enlace, estilo de presentación en pantalla, restricciones de acceso, etc.)

1.1.1.3. Fase de Construcción,

Se transformar los esquemas en código y guardados en una Base de Datos Orientada a Objetos, y en elaborar formularios de consulta de las clases con la ayuda de un editor gráfico de interfaces. Se genera el código fuente (por ejemplo en C#) correspondiente a cada clase y se prepara la Interface Gráfica de Usuario.

Las relaciones definidas en un modelo orientado a objetos pueden ser representadas por clases de enlaces hipermedia. Estas clases añaden a las relaciones del modelo objeto la semántica navegacional de la aplicación. Están organizadas en una jerarquía de herencia propuesta por el método bajo la forma de una biblioteca de clases. La semántica relativa a las propiedades hipermedia de las relaciones encuentra, por tanto, una representación en EORM bajo la forma de clases.

Toda la semántica de relaciones de aplicación se expresa por medio de enlaces hipermedia reagrupados en una jerarquía de clases y así, el comportamiento definido sobre los enlaces permite tener en cuenta una parte de la semántica de la navegación de la aplicación. También se permite alterar la propia estructura navegacional de la aplicación mediante operaciones de creación, destrucción o de modificación de elementos hipermedia. El modelo EORM se ha centrado, principalmente, en el enriquecimiento de los elementos hipermedia.

1.2. OOHDM

Es un Método de Diseño de Desarrollo en Hipermedia Orientado a Objetos (Object-Oriented Hypermedia Design Method) y abarca las cuatro actividades: El modelado conceptual, diseño navegacional, diseño abstracto de interfaz y la puesta en práctica. Estas actividades se relizan en una mezcla de estilo incremental, iterativo y basado en prototipos de desarrollo.

1.2.1. Fases

Los modelos orientados a objetos se construyen en cada paso que mejora los modelos diseñados en iteraciones anteriores y consta de las siguientes fases:

1.2.1.1. Fase Conceptual

Durante esta actividad se construye un esquema conceptual representado por los objetos del dominio, las relaciones y colaboraciones existentes establecidas entre ellos. En las aplicaciones hipermedia convencionales, cuyos componentes de hipermedia no son modificados durante la ejecución, se podría usar un modelo de datos semántico estructural (como el modelo de entidades y relaciones). De este modo, en los casos en que la información base pueda cambiar dinámicamente o se intenten ejecutar cálculos complejos, se necesitará enriquecer el comportamiento del modelo de objetos En OOHDM, el esquema conceptual está construido por clases, relaciones y subsistemas. Las clases son descritas como en los modelos orientados a objetos tradicionales. Sin embargo, los atributos pueden ser de múltiples tipos para representar perspectivas diferentes de las mismas entidades del mundo real.

1.2.1.2. Fase Navegacional

Se debe tener en mente que la generación de aplicaciones Web fue pensada para realizar navegación a través del espacio de información, utilizando un simple modelo de datos de hipermedia. En OOHDM, la navegación es considerada un paso crítico en el diseño aplicaciones.

Un modelo navegacional es construido como una vista sobre un diseño conceptual, admitiendo la construcción de modelos diferentes de acuerdo con los diferentes perfiles de usuarios. Cada modelo navegacional provee una vista subjetiva del diseño conceptual. El diseño de navegación es expresado en dos esquemas: el esquema de clases navegacionales y el esquema de contextos navegacionales. En OOHDM existe un conjunto de tipos predefinidos de clases navegacionales: nodos, enlaces y estructuras de acceso. La semántica de los nodos y los enlaces son las tradicionales de las aplicaciones hipermedia, y las estructuras de acceso, tales como índices o recorridos guiados, representan los posibles caminos de acceso a los nodos. La principal estructura primitiva del espacio navegacional es la noción de contexto navegacional. Un contexto navegacional es un conjunto de nodos, enlaces, clases de contextos, y otros contextos navegacionales (contextos anidados). Pueden ser definidos por comprensión o extensión, o por enumeración de sus miembros. Los contextos navegacionales juegan un rol similar a las colecciones y fueron inspirados sobre el concepto de contextos anidados. Organizan el espacio navegacional en conjuntos convenientes que pueden ser recorridos en un orden particular y que deberían ser definidos como caminos para ayudar al usuario a lograr la tarea deseada. Los nodos son enriquecidos con un conjunto de clases especiales que permiten de un nodo observar y presentar atributos (incluidos las anclas), así como métodos (comportamiento) cuando se navega en un particular contexto

1.2.1.3. Fase de Interfaz Abstracta

Se debe tener las estructuras navegacionales son definidas, se deben especificar los aspectos de interfaz. Esto significa definir la forma en la cual los objetos navegacionales pueden aparecer, de cómo los objetos de interfaz activarán la navegación y el resto de la funcionalidad de la aplicación, qué transformaciones de la interfaz son pertinentes y cuándo es necesario realizarlas.

El aspecto de la interfaz de usuario de aplicaciones interactivas (en particular las aplicaciones Web) es un punto crítico en el desarrollo que las modernas metodologías tienden a descuidar.

En OOHDM se utiliza el diseño de interfaz abstracta para describir la interfaz del usuario de la aplicación de hipermedia. El modelo de interfaz ADVs (Vista de Datos Abstracta) especifica la organización y comportamiento de la interfaz, pero la apariencia física real o de los atributos, y la disposición de las propiedades de las ADVs en la pantalla real son hechas en la fase de implementación

1.2.1.4. Fase Implementación

Se tendrá en cuenta que el diseñador debe ya implementar el diseño. Hasta ahora, todos los modelos fueron construidos en forma independiente de la plataforma de implementación; en esta fase es tenido en cuenta el entorno particular en el cual se va a correr la aplicación. Al llegar a esta fase, el primer paso que debe realizar el diseñador es definir los ítems de información que son parte del dominio del problema. Debe identificar también, cómo son organizados los ítems de acuerdo con el perfil del usuario y su tarea; decidir qué interfaz debería ver y cómo debería comportarse. A fin de implementar todo en un entorno Web, el diseñador debe decidir además qué información debe ser almacenada.

En los diagramas de clases navegacionales corresponden a vistas del esquema conceptual y los esquemas de contexto modelan el espacio de navegación incluyendo estructuras de acceso y contextos (que corresponde a un conjunto de instancias de una clase navegacional). Se podrían crear vistas parciales por usuario agrupando los contextos a partir de los tipos de usuarios que tienen acceso a los mismos. Las vistas por módulos o subsistemas no las modela de manera explícita, pero en los esquemas de contextos pueden modelarse fácilmente sub.-módulos

Construir la interfaz de una aplicación Web es también una tarea compleja; no sólo se necesita especificar cuáles son los objetos de la interfaz que deberían ser implementados, sino también la manera en la cual estos objetos interactuarán con el resto de la aplicación. Esta metodología propone dedicar un tiempo importante en las fases previas a la implementación.

Esta inversión de tiempo está ampliamente justificada no sólo porque simplifica el proceso de desarrollo, facilitando el trabajo del equipo encargado de cada capa de la aplicación, sino también durante su mantenimiento y eventual extensión.

Son quizás estas últimas tareas las más difíciles de lograr con tecnologías tradicionales, y aún imposibles en muchos casos donde no existe diseño detallado y la implementación concentra conceptos heterogéneos muy difíciles de modificar.

1.3. SOHDM

Es un Método que Desarrolla Diseño en panoramas (scenario) Orientada a Objetos en Hipermedia (Scenario - based Object-oriented Hypermedia Design Methodology). Presenta la necesidad de disponer de un proceso que permita capturar las necesidades del sistema. Para ello, propone el uso de escenarios.

Es una de las primeras propuestas para la web y brinda más importancia a la tarea de tratamiento de requisitos. Se caracteriza principalmente porque su ciclo de vida comienza con la aplicación de los escenarios como técnica de elicitación y definición de requisitos.

El proceso de definición de requisitos parte de la realización de un diagrama de contexto tal y como se propone en los diagramas de flujos de datos (DFD) de Yourdon (1989). En este diagrama de contexto se identifican las entidades externas que se comunican con el sistema, así como los eventos que provocan esa comunicación. La lista de eventos es una tabla que indica en qué eventos puede participar cada entidad. Por cada evento diferente, SOHDM propone elaborar un escenario. Estos son representados gráficamente mediante los denominados SACs2 (Scenario Activity Chart).

Cada escenario describe el proceso de interacción entre el usuario y el sistema cuando se produce un evento determinado, especificando el flujo de actividades, los objetos involucrados y las transacciones realizadas. SOHDM propone un proceso para conseguir a partir de estos escenarios el modelo conceptual del sistema, que es representado mediante un diagrama de clases. El proceso de SOHDM continúa reagrupando estas clases para conseguir un modelo de clases navegacionales del sistema.

Consiste en seis fases: análisis del dominio, modelado del objeto, diseño de la visión, diseño de la navegación, diseño de la puesta en práctica y construcción.

Esta metodología tiene semejanzas con, OOHDM y EORM donde se diferencian en el uso de panoramas, que describen las actividades en los acontecimientos y primitivas de flujos de actividades. Los panoramas se definen en la fase de análisis y se utilizan para modelar los objetos

1.3.1. Fases

A continuación detallaremos sus fases:

1.3.1.1. Fase de Análisis,

Se realizar un estudio de las necesidades de la aplicación, del entorno de trabajo y de los actores. La finalidad principal de esta fase es conseguir los escenarios que representen las actividades que se pueden llevar a cabo en el sistema.

1.3.1.2. Fase de Modelado de Objetos,

Se desarrolla un diagrama de clases que representa la estructura conceptual del sistema

1.3.1.3. Fase de Diseño de Vistas,

Se reorganizan los objetos en unidades navegacionales que representan una vista de los objetos del sistema.

1.3.1.4. Fase de Diseño Navegacional,

Se enriquecen dichas vistas definiendo los enlaces e hiperenlaces que existen en el sistema.

1.3.1.5. Fase de Diseño de la Implementación,

Se diseñan las páginas, la interfaz y la base de datos del sistema.

1.3.1.6. Fase de Construcción,

Se realiza la construcción de la base de datos del sistema. la que se implementa la aplicación.

Esta propuesta es hasta ahora la única que tiene en cuenta aspectos como la especificación de requisitos haciendo uso de los escenarios. Otra ventaja es que es un proceso sencillo de seguir, no obstante su nomenclatura es muy cerrada. Además es una propuesta donde se hacen uso de técnicas de modelado orientado a objetos, algo muy significativo ya que es adecuado para el desarrollo de este tipo de aplicaciones

1.4. WSDM

Es un Método de Diseño para Sitios Web (Web Site Design Method), donde hay un acercamiento al usuario que define los objetos de información basado en sus requisitos de información para el uso de la Web. En este método se definen una aplicación Web a partir de los diferentes grupos de usuarios que vaya a reconocer el sistema.

Propone cuatro etapas: modelo de usuario, diseño conceptual, diseño de la implementación e implementación. El tratamiento de requisitos se lleva a cabo en la etapa inicial, donde, en primer lugar, se identifican y clasifican los usuarios que van a hacer uso de la aplicación Web.

1.4.1. Fases

A continuación, se describen los requisitos de cada grupo de usuarios y sus fases.

1.4.1.1. Fase de Modelo de Usuario

Se intenta detectar los perfiles de usuarios para los cuales se construye la aplicación. Durante esta fase es necesario determinar:

¿Quién es el público objetivo? ¿Cómo será la visión de su sitio Web? ¿Cuáles son los objetivos de marketing de la empresa? ¿Cuáles son los objetivos de su sitio web? ¿Qué mensaje tiene su compañía quiere transmitir? ¿Cuál es el campo del negocio? ¿Cuáles son los estándares de la industria?

Una vez que tenemos una comprensión de su negocio y sus objetivos de la empresa, que hará recomendaciones a la mejor alcanzar sus metas. Nuestro proceso de planificación estratégica se creará un plan inicial de su sitio web. Se divide en dos subfases siguientes:

1.4.1.1.1. Clasificación de usuarios:

Se deben identificar y clasificar a los usuarios que van a hacer uso del sistema. Para ello, WSDM propone el estudio del entorno de la organización donde se vaya a implantar el sistema y los procesos que se vayan a generar, describiendo las relaciones entre usuarios y actividades que realizan estos usuarios. Para la representación gráfica de estas relaciones WSDM propone una especie de mapas de conceptos de roles y actividades

1.4.1.1.2. Descripción de los grupos de usuarios

Se describen con más detalles los grupos de usuarios detectados en la etapa anterior. Para ello, se debe elaborar un diccionario de datos, en principio con formato libre, en el que indican los requisitos de almacenamiento de información, requisitos funcionales y de seguridad para cada grupo de usuarios.

1.4.1.2. Fase de Diseño Conceptual

Se desarrolla el modelado conceptual no tiene el mismo significado que en OOHDM. Durante el modelado conceptual se realizan dos tareas a la vez: el modelado de objetos, que es lo que en OOHDM se llama modelo conceptual y el diseño de la navegación, que coincide con la idea del diseño navegacional de OOHDM, Este tipo de diseño de navegación en aplicaciones Web tiene una estructura muy jerárquica. La aplicación de diseño pasa a crear un coherente y eficiente modelado conceptual.

Pocas recomendaciones se dan en esta etapa, tales como la utilización de páginas de índice, derecho de información dividida en diversos tamaños, el uso de contexto y de la información y el uso de señales de navegación. La navegación modelo consiste en una serie de vías de navegación, uno para cada perspectiva expresando de forma en que los usuarios de una perspectiva particular puede navegar a través de la información disponible. WSDM describe en términos de los componentes y enlaces.

Distingue tres tipos de componentes de navegación, información y externos. Cada navegación consta de tres capas: contexto, navegación y capas de información. En WSDM puede existir más de un modelo de navegación, dependiendo de los roles de usuario detectados durante la primera fase

1.4.1.3. Fase de Diseño de Implementación

Se modela la interfaz para cada rol de usuario, Ahora que se tiene una versión definitiva del plan se puedan comenzar con la construcción del sitio web. Durante esta fase, se tendrá lugar lo siguiente:

La construcción de la arquitectura de navegación del sitio.

ü Creación de alta funcionalidad, teniendo como fin a la animación, pues hará que se propague por todas las páginas de los medios necesarios con sus los gráficos y el texto.

ü El código de los programas técnicos y la funcionalidad del sitio.

ü La creación y diseño de la página principal disponible

1.4.1.4. Fase de Realización de Implementación

Se codifican todos estos aspectos en el lenguaje concreto que se haya seleccionado. WSDM es también una propuesta viva que está cambiando y adaptándose a nuevos requisitos.

Preparamos el lanzamiento de la web teniendo en cuenta ¿Cuándo entrarían a nuestra web? Antes de la puesta en marcha vamos a garantizar lo siguiente:

ü Continuo y exhaustivas pruebas que garantizará un impecable final del sitio web.

ü Trabajo directamente con la empresa para garantizar la técnica y la usabilidad se cumplen las normas.

ü Velar el final del proyecto con la finalidad de ver si se han cumplido los requisitos planteados.

ü Crear una fecha de lanzamiento y el plan

WSDM se describe en términos de componentes y enlaces. Distingue tres tipos de componentes de navegación. Cada navegación consta de tres capas: contexto, la navegación y capas de información. El contexto es la capa superior de la navegación y a su vez la de información es la capa inferior. La capa de navegación conecta la capa de contexto y la capa de información. Para acceder a la información intermedia por componentes y los vínculos que se crean, tales como los índices. En la actualidad, es uno de los trabajos más interesantes y novedosos que se le está aplicando es el desarrollo de una herramienta CASE que permita aplicar el ciclo de vida de desarrollo de WSDM

1.5. RNA

Es un método de Análisis de Navegación Relacional (Relationship Navigational Analysis), que define una secuencia de pasos que se utilizarán para el desarrollo de la Web. Es especialmente útil para uso de la Web creados en base de sistema de herencia. En este método encontramos cinco fases las cuales son: Análisis del entorno, donde el propósito de esta fase es el de estudiar las características de la audiencia, luego encontramos las definiciones de elementos de interés, el análisis del conocimiento y navegación y finalmente la implementación de los análisis realizados.

La propuesta de RNA es quizás una de las que más ha resaltado la necesidad de trabajar con la especificación de requisitos, incluyendo tareas como el análisis del entorno y de los elementos de interés. Además, resulta interesante pues plantea la necesidad de analizar los requisitos conceptuales de manera independiente a los navegacionales.

1.5.1. Fases

A continuación detallaremos cada fase.

1.5.1.1. Fase de Análisis del Entorno

Se determinar y clasifica a los usuarios finales de la aplicación en grupos según sus perfiles

1.5.1.2. Fase de Definición de Elementos

Aquí prosiguen los elementos de interés en la cual se han listando dichos elementos de la aplicación. Por elementos de interés se entienden los documentos, las pantallas que se van a requerir, la información, etc.

1.5.1.3. Fase de Análisis del Conocimiento

Se desarrollar un esquema que represente a la aplicación. Para ello RNA propone identificar los objetos, los procesos y las operaciones que se van a poder realizar en la aplicación, así como las relaciones que se producen entre estos elementos

1.5.1.4. Fase de Análisis de Navegación

Se verifica que el esquema obtenido en la fase anterior sea enriquecido con las posibilidades de navegación dentro de la aplicación

1.5.1.5. Fase de Implementación del Análisis

Cuando una vez obtenido el esquema final en el que ya se encuentran incluidos los aspectos de navegación, se pasa el esquema a un lenguaje entendible por la máquina

2.1. ¿El por qué de una Metodología de Desarrollo Web?

Los principales problemas que nos encontramos es la falta de fiabilidad, seguridad, escalabilidad, mantenimiento, integración y la alta dependencia para su desarrollo e implantación junto con la falta de estándares.

Lo que deseamos es controlar el caos que han provocado en el pasado procesos creativos de desarrollo con el fin de proporcionar un proceso sistemático orientado a la mejora de la calidad de la aplicación final. En esta nueva disciplina se parte de la base de que las necesidades de evolución, mantenimiento, la adaptación a nuevos dispositivos de acceso y la migración a nuevas plataformas y entornos de desarrollo deben dirigir el proceso del ciclo de vida.

Para todo esto se han desarrollado metodologías que permiten estructurar comunicar, entender, simplificar y formalizar tanto el dominio como las decisiones de diseño, así como disponer de Documentación detallada para posibles cambios del software.

2.2. Evolución de las metodologías de Desarrollo Web.

Las distintas metodologías se pueden dividir en tres generaciones en base a su sofisticación, estas son:

2.1.1. Primera Generación

(Principios de los 90) Se sientan las bases de la ingeniería Web, en los que se incluyen conceptos como construcción de navegación, separación entre estructuras y el contenido durante el ciclo de desarrollo.

2.1.2. Segunda Generación

(Segunda mitad de los 90) Se refinan los primeros modelos y se añaden los soportes de funcionalidad básica y se llevan a cabo los primeros esbozos de proceso donde se delimitan los modelos conceptual, lógico y físico.

2.1.3. Tercera generación

(A partir del 2000): Se lleva a cabo la profundización en el soporte para la funcionalidad, enfatización de la figura del usuario en los métodos, y se avanza hacia la estandarización de notaciones, procesos y lenguajes de especificación.

2.3. ¿Qué es UWE?

La propuesta de Ingeniería Web basada en UML (UWE (Koch, 2000)) es una metodología detallada para el proceso de autoría de aplicaciones con una definición exhaustiva del proceso de diseño que debe ser utilizado. Este proceso, iterativo e incremental, incluye flujos de trabajo y puntos de control, y sus fases coinciden con las propuestas en el Proceso Unificado de Modelado. UWE está especializada en la especificación de aplicaciones adaptativas, y por tanto hace especial hincapié en características de personalización, como es la definición de un modelo de usuario o una etapa de definición de características adaptativas de la navegación en función de las preferencias, conocimiento o tareas de usuario.

Otras características relevantes del proceso y método de autoría de UWE son el uso del paradigma orientado a objetos, su orientación al usuario, la definición de un meta-modelo (modelo de referencia) que da soporte al método y el grado de formalismo que alcanza debido al soporte que proporciona para la definición de restricciones sobre los modelos.

2.4. Principales aspectos.

Los principales de aspectos en los que se fundamenta UWE son los siguientes:

2.1.4. Uso de una notación estándar

Para todos los modelos (UML : Lenguaje de modelado unificado).

2.1.5. Definición de métodos

Definición de los pasos para la construcción de los diferentes modelos.

2.1.6. Especificación de Restricciones

Se recomienda el uso de restricciones escritas (OCL: Lenguaje de restricciones de objetos) para aumentar la exactitud de los modelos.

2.5. Fases del Desarrollo Web.

Por lo que respecta al proceso de autoría de la aplicación, UWE hace un uso exclusivo de estándares reconocidos como UML y el lenguaje de especificación de restricciones asociado OCL. Para simplificar la captura de las necesidades de las aplicaciones web, UWE propone una extensión que se utiliza a lo largo del proceso de autoría. Este proceso de autoría está dividido en cuatro pasos o actividades:

2.5.1. Análisis de Requisitos

Fija los requisitos funcionales de la aplicación Web para reflejarlos en un modelo de casos de uso.

2.5.2. Diseño Conceptual

Materializado en un modelo de dominio, considerando los requisitos reflejados en los casos de uso.

2.5.3. Diseño Navegacional

Lo podemos subdividir en :

1.5.1.6. Modelo del Espacio de Navegacional.

1.5.1.7. Modelo de la Estructura de navegación

Muestra la forma de navegar ante el espacio de navegación.

2.5.4. Diseño de Presentación

Representa las vistas del interfaz del usuario mediante modelos estándares de interacción UML.

3.1. WSDM: Web Site Design Method. 1997

Define el sistema en base a los grupos de usuario.

Su proceso de definición de requisitos tiene por objetivo el detectar los perfiles de usuario mediante dos tareas.

ü Clasificación de usuarios mediante el estudio del entorno.

ü Descripción de los grupos de usuario.

En la actualidad, están trabando en una propuesta de herramienta que permita soportar el proceso de trabajo.

3.2. SOHDM: Scenario-based Object-Oriented Hypermedia Design Methodology. 1998

Esta propuesta ofrece un modelo de escenarios propio, denominado SAC, para representar los requisitos.

Para el desarrollo de los mismos hace uso del diagrama de contexto propuesto en los DFD.

En la actualidad ha caído en desuso, principalmente por el uso de los DFD.

Sin embargo tiene algunas variantes propuesta por los mismos autores.

3.3. RNA: Relationship Navigational Analysis. 1998

Plantea una secuencia de pasos en la que separa el tratamiento de diferentes requisitos:

ü Análisis del Entorno

ü Elementos de Interés

ü Análisis del Conocimiento

ü Análisis de la Navegación

ü Implementación del Análisis

Está muy focalizada a un grupo de sistemas: Los sistemas legales y en la actualidad no es muy usada.

3.4. HFPM: Hypermedia Flexible Process Modeling. 1999

HFPM define un proceso detallado que cubre todo el ciclo de vida y que está compuesto por 13 fases.

En la primera de ellas, modelado de requisitos, propone las tareas siguientes:

ü Descripción breve del problema

ü Descripción de los requisitos funcionales

ü Realización del modelo de datos

ü Modelado de la interfaz de usuario

ü Modelado de los requisitos no funcionales

HFPM no está siendo trabajada actualmente, sin embargo, fue la primera en definir ciertos aspectos:

ü Incluye al usuario desde el principio del desarrollo.

ü Introduce el concepto de la separación de aspectos, propuesto para el análisis, ya desde la Ingeniería de Requisitos.

ü Establece la necesidad de definir modelos específicos para el usuario. Aunque no define ninguno.

ü Establece la necesidad de elaborar

3.5. OOHDM: Object Oriented Hypermedia Design Model.

1999

OOHDM es una propuesta ampliamente aceptada para la web.

Inicialmente no proponía la fase de Ingeniería de Requisitos y centraba su

Desarrollo en cuatro etapas.

Sin embargo, en el año 2001 tuvo una propuesta orientada a la ingeniería de requisitos denominada User Interaction Diagrams (UID).

3.6. UWE: UML-Based Web Engineering. 1999

UWE es una propuesta basada en el proceso unificado y UML pero adaptados a la web.

En requisitos separa las fases de captura, definición y validación.

Hace además una clasificación y un tratamiento especial dependiendo del carácter de cada requisito.

En la actualidad ha evolucionado hacia el desarrollo MDD y define los conceptos en base a un conjunto de modelos. UWE ha sido ampliamente

Aceptado en los últimos años. Entra las ventajas más importantes de UWE es su uso 100% UML. Ofrece una herramienta denominada ArgoUWE.

3.7. W2000. 2001

Esta propuesta toma como base los conceptos de HDM para ampliar la notación UML y adecuarla a la web. La fase de especificación de requisitos en W2000 hace una separación y un tratamiento diferente de los requisitos funcionales y los de navegación. Utiliza para ello una extensión de los casos de uso de UML.

3.8. UWA: Ubiquituos Web Applications. 2001

El proyecto UWA ha nacido de la colaboración de varios grupos. Su fase de tratamiento de requisitos se basa en los roles de usuario y en ir refinando los requisitos en un proceso iterativo mediante el que se clasifican los objetivos según su carácter.

3.9. NDT: Navigational Development Tecniques. 2004

NDT es un proceso metodológico para especificar, analizar y diseñar sistemas web.

En el tratamiento de requisitos separa la captura, la definición y la validación de requisitos, proponiendo técnicas específicas para cada uno de ellos.

Ofrece además una herramienta, NDT-Tool, que sirve como soporte en la aplicación de sus técnicas.

3.10. DDDP: Design-driven Requirements Elicitation. 2004

Esta propuesta para el tratamiento de requisitos es parte del proceso design-Driven propuestos por Lowe y Ekluind.

Consiste en realizar la captura, la definición y la validación de requisitos durante el proceso de diseño.

El proceso que ofrecen fue definido en base a un exhaustivo análisis de best practices en el desarrollo de aplicaciones comerciales para la web. La mayoría de las propuestas de Ingeniería Web están muy orientadas a las fases de análisis y diseño, pero, en los últimos años cada día son más los grupos que evolucionan hacía los requisitos.

Cada día son más los grupos que incluyen el tratamiento con los usuarios en sus propuestas. Sin embargo, sigue sin haber una nomenclatura común, ni siquiera una delimitación adecuada de qué es requisitos. Una nueva tendencia, MDD, está buscando esta homogeneidad, no solo en requisitos, sino en todo el proceso.

4.1. Introducción a OOHDM

Las metodologías tradicionales de ingeniería de software, o las metodologías para sistemas de desarrollo de información, no contienen una buena abstracción capaz de facilitar la tarea de especificar aplicaciones hipermedia. El tamaño, la complejidad y el número de aplicaciones crecen en forma acelerada en la actualidad, por lo cual una metodología de diseño sistemática es necesaria para disminuir la complejidad y admitir evolución y reusabilidad.

Producir aplicaciones en las cuales el usuario pueda aprovechar el potencial del paradigma de la navegación de sitios web, mientras ejecuta transacciones sobre bases de información, es una tarea muy difícil de lograr.

En primer lugar, la navegación posee algunos problemas. Una estructura de navegación robusta es una de las claves del éxito en las aplicaciones hipermedia. Si el usuario entiende dónde puede ir y cómo llegar al lugar deseado, es una buena señal de que la aplicación ha sido bien diseñada. Construir la interfaz de una aplicación web es también una tarea compleja; no sólo se necesita especificar cuáles son los objetos de la interfaz que deberían ser implementados, sino también la manera en la cual estos objetos interactuarán con el resto de la aplicación. En hipermedia existen requerimientos que deben ser satisfechos en un entorno de desarrollo unificado. Por un lado, la navegación y el comportamiento funcional de la aplicación deberían ser integrados. Por otro lado, durante el proceso de diseño se debería poder desacoplar las decisiones de diseño relacionadas con la estructura navegacional de la aplicación, de aquellas relacionadas con el modelo del dominio.

OOHDM propone el desarrollo de aplicaciones hipermedia a través de un proceso compuesto por cuatro etapas: diseño conceptual, diseño navegacional, diseño de interfaces abstractas e implementación.

4.1.1. Diseño Conceptual

En OOHDM, el esquema conceptual está construido por clases, relaciones y subsistemas. Las clases son descritas como en los modelos orientados a objetos tradicionales. Sin embargo, los atributos pueden ser de múltiples tipos para representar perspectivas diferentes de las mismas entidades del mundo real.

Se usa notación similar a UML (Lenguaje de Modelado Unificado3) y tarjetas de clases y relaciones similares a las tarjetas CRC (Clase Responsabilidad Colaboración4). El esquema de las clases consiste en un conjunto de clases conectadas por relaciones. Los objetos son instancias de las clases. Las clases son usadas durante el diseño navegacional para derivar nodos, y las relaciones que son usadas para construir enlaces.

4.1.2. Diseño Navegacional

La primera generación de aplicaciones web fue pensada para realizar navegación a través del espacio de información, utilizando un simple modelo de datos de hipermedia. En OOHDM, la navegación es considerada un paso crítico en el diseño aplicaciones. Un modelo navegacional es construido como una vista sobre un diseño conceptual, admitiendo la construcción de modelos diferentes de acuerdo con los diferentes perfiles de usuarios. Cada modelo navegacional provee una vista subjetiva del diseño conceptual.

El diseño de navegación es expresado en dos esquemas: el esquema de clases navegacionales y el esquema de contextos navegacionales. En OOHDM existe un conjunto de tipos predefinidos de clases navegacionales: nodos, enlaces y estructuras de acceso. La semántica de los nodos y los enlaces son las tradicionales de las aplicaciones hipermedia, y las estructuras de acceso, tales como índices o recorridos guiados, representan los posibles caminos de acceso a los nodos.

La principal estructura primitiva del espacio navegacional es la noción de contexto navegacional. Un contexto navegacional es un conjunto de nodos, enlaces, clases de contextos, y otros contextos navegacionales (contextos anidados). Pueden ser definidos por comprensión o extensión, o por enumeración de sus miembros. Los contextos navegacionales juegan un rol similar a las colecciones y fueron inspirados sobre el concepto de contextos anidados. Organizan el espacio navegacional en conjuntos convenientes que pueden ser recorridos en un orden particular y que deberían ser definidos como caminos para ayudar al usuario a lograr la tarea deseada. Los nodos son enriquecidos con un conjunto de clases especiales que permiten de un nodo observar y presentar atributos (incluidos las anclas), así como métodos (comportamiento) cuando se navega en un particular contexto.

4.1.3. Diseño de Interfaz Abstracta

Una vez que las estructuras navegacionales son definidas, se deben especificar los aspectos de interfaz. Esto significa definir la forma en la cual los objetos navegacionales pueden aparecer, cómo los objetos de interfaz activarán la navegación y el resto de la funcionalidad de la aplicación, qué transformaciones de la interfaz son pertinentes y cuándo es necesario realizarlas.

Una clara separación entre diseño navegacional y diseño de interfaz abstracta permite construir diferentes interfaces para el mismo modelo navegacional, dejando un alto grado de independencia de la tecnología de interfaz de usuario. El aspecto de la interfaz de usuario de aplicaciones interactivas (en particular las aplicaciones web) es un punto crítico en el desarrollo que las modernas metodologías tienden a descuidar. En OOHDM se utiliza el diseño de interfaz abstracta para describir la interfaz del usuario de la aplicación de hipermedia.

El modelo de interfaz ADVs (Vista de Datos Abstracta5) especifica la organización y comportamiento de la interfaz, pero la apariencia física real o de los atributos, y la disposición de las propiedades de las ADVs en la pantalla real son hechas en la fase de implementación.

4.1.4. Implementación

En esta fase, el diseñador debe implementar el diseño. Hasta ahora, todos los modelos fueron construidos en forma independiente de la plataforma de implementación; en esta fase es tenido en cuenta el entorno particular en el cual se va a correr la aplicación. Al llegar a esta fase, el primer paso que debe realizar el diseñador es definir los ítems de información que son parte del dominio del problema. Debe identificar también, cómo son organizados los ítems de acuerdo con el perfil del usuario y su tarea; decidir qué interfaz debería ver y cómo debería comportarse. A fin de implementar todo en un entorno web, el diseñador debe decidir además qué información debe ser almacenada.

5.1. APRECIACIÓN PERSONAL

ü El avance de Internet y las comunicaciones han provocado en los últimos años el nacimiento de nuevas propuestas metodológicas para la web.

ü Sin embargo, la mayoría de ellas han centrado su trabajo principalmente en las etapas de diseño e implementación.

ü Existen proyectos que por su envergadura y la complejidad de la información que en él se maneja resulta necesario aplicar una metodología pesada pues han demostrado ser efectivas y necesarias en proyectos de gran tamaño (respecto a tiempo y recursos), donde por lo general se exige un alto grado de ceremonia en el proceso.

ü Las metodologías ágiles por su parte están especialmente orientadas para proyectos pequeños y constituyen una solución a medida para ese entorno, aportando una elevada simplificación que a pesar de ello no renuncia a las prácticas esenciales para asegurar la calidad del producto.

CONCLUSIONES

Ø En conclusión la metodología SOHDM es una propuesta nueva que cubre en mayor parte todas las fases del proceso de desarrollo, aunque no toma en cuenta la implantación y las pruebas, proponiéndonos un proceso cíclico de tal forma que al realizar una fase se puede regresar a alguna de las anteriores para refinarla y adaptarla mejor.

Ø OOHDM propone un conjunto de tareas que en principio pueden involucrar mayores costos de diseño, pero que a mediano y largo plazo reducen notablemente los tiempos de desarrollo al tener como objetivo principal la reusabilidad de diseño, y así simplificar la evolución y el mantenimiento.

Ø El avance de Internet y las comunicaciones ha provocado en los últimos años el nacimiento de nuevas propuestas metodológicas para la web.

BIBLIOGRAFIA

ü Nora Koch, Andreas Kraus1, Rolf Hennicker , El proceso de creación de UML basada en Ingeniería Web Enfoque.

ü Cristina Cachero Castro, OO-H: Una extensión de los métodos OO para el modelado y generación automática de interfaces hipermedia les.

ü Lee, H. Lee, C. Yoo, C. (1998). Una metodología basada en entornos orientados a objetos para desarrollo de sistemas de información hipermedia.

ü D. Schwabe, G. Rossi (1998). Desarrollo de Aplicaciones Hipermedia con OOHDM. Taller sobre el Proceso de Desarrollo de Hipermedia, Métodos y Modelos, Hypertext'98, Pittsburg, EE.UU.

ü Koch [UWE], N. (2001). Ingeniería de Software para Aplicaciones Hipermedia Adaptativo.

ESTIMACION DE COSTOS DE PROYECTOS DE SISTEMAS DE INFORMACION

2010-06-19T20:48:00.000-07:00

1.1. Estimación de costos de Proyecto

La estimación y al calendarización del proyecto se llevan a cabo de forma conjunta. Sin embargo. En las primeras etapas del proyecto se requieren algunas estimaciones de costos, antes de que se tenga la calendarización detallada. Estas estimaciones son necesarias para establecer un presupuesto para el proyecto o para asignar un precio para el software de un cliente.

Una vez que el proyecto se encamina, las estimaciones se actualizan de forma regular. Esto ayuda al proceso de planeación y permite la utilización efectiva de los recursos. Si el gasto real es significativamente más grande que las estimaciones, entonces el administrador del proyecto debe tomar algunas acciones. Estas pueden ser solicitar recursos adicionales para el proyecto o modificar el trabajo a realizar.

Existen tres parámetros involucrados en el cálculo del costo total de un proyecto de desarrollo de software:

· Los costos del hardware y software, incluyendo mantenimiento;

· Los costos de viajes y capacitación;

· Los costos de esfuerzo (los costos de pago a los ingenieros de software)

Para muchos proyectos, el costo dominante es el costo de esfuerzo. Las computadoras que son suficientemente poderosas como para desarrollar el software son relativamente baratas. Aunque los costos de viajes pueden ser importantes si un proyecto se desarrolla en sitios distintos, son relativamente bajos para muchos proyectos. Además el uso de correos electrónico, fax y teleconferencias reduce los viajes requeridos.

Los costos de esfuerzo no son simplemente los relacionados a los salarios de los ingenieros de software involucrados en el proyecto. Las organizaciones calculan los costos de esfuerzo en términos de los costos de sobrecarga donde se toma en cuenta el costo total de hacer funcionar la organización y dividen este entre el número de personas productivas. Por lo tanto los siguientes costos son parte de los costos de esfuerzo totales:

a. Los costos de proveer, calentar e iluminar oficinas.

b. Los costos del personal de apoyo como los contadores, secretarias, limpiadores y técnicos.

c. Los costos de las redes y las comunicaciones.

d. Los costos de los recursos centralizados como las bibliotecas, los recursos recreativos, etcétera.

e. Los costos de seguridad social y de beneficio de empleados como las pensiones y los seguros de salud.

FACTOR	DESCRIPCION
Oportunidad de mercado	Una organización de desarrollo podría cotizar un bajo precio debido a que desea moverse a un nuevo mercado del software. Aceptar un bajo beneficio en un proyecto podría darle la oportunidad de obtener más beneficios posteriormente. La experiencia obtenida le permite desarrollar nuevos productos.
Incertidumbre en la estimación de costos	Si una organización esta insegura de su costo estimado por alguna contingencia puede incrementar su precio por encima del beneficio normal.
Términos contractuales	Un cliente puede estar dispuesto a permitir que el desarrollador retenga la propiedad del código fuente y que reutilice dicho código en otros proyecto. Por lo tanto, el precio cargado podría ser menor que si el código fuente del software se le entrega al cliente.
Volatilidad de los requerimientos	Si es probable que los requerimientos cambien, una organización puede reducir los precios para ganar un contrato. Después de que el contrato se asigna, se cargan precios altos a los cambios en los requerimientos.
Salud financiera	Los desarrolladores en dificultades financieras podrían bajar sus precios para obtener un contrato. Es mejo tener beneficios más bajos que los normales o incluso quebrar antes que quedar fuera de los negocios.
Cuadro 1: Los factores que afectan la asignación de precios al software.

Típicamente, este factor de sobrecarga es alrededor de dos veces el salario del ingeniero de software, dependiendo del tamaño de la organización y sus sobrecargas asociadas. Por lo tanto, si un ingeniero de software se le pagan $90 000 al año, el costo total de la organización es de $180 000 por año a $15 000 por mes.

Calcular los costos del software se debe llevar a cabo de forma objetiva con el fin de predecir de forma precisa cuanto le cotara al contratista desarrollar el software. Si los costos del proyecto se calculan como parte de una oferta a un cliente, entonces se tiene que tomar una decisión del precio que se le dará al cliente. Por lo general, el precio es simplemente el costo más el beneficio. Sin embargo, la relación entre el costo del proyecto y el precio al cliente por lo regular no es tan simple.

Asignar un precio al software debe tomar en cuenta consideraciones organizacionales, económica, políticas y de negocios. En el cuadro N°1 se muestran los factores que se deben tomar en cuenta. Por lo tanto, no existe una relación sencilla entre el precio que se le da al cliente por el software y los costos de desarrollo. Debido a las consideraciones organizacionales involucradas, asignar el precio del proyecto por lo general le concierne al administrador principal de la organización, así como a los administradores del proyecto de software.

1.1.1. Productividad

La productividad en un sistema de manufactura se mide contando el número de unidades que se producen y dividiendo éste entre el número de personas-hora requeridas para producirlas. Sin embargo, para cualquier problema de software, existen muchas soluciones diferentes con distintos atributos. Una solución podría ejecutarse de forma más eficiente mientras que otra podría ser más legible y fácil de mantener. Cuando se producen soluciones con diferentes atributos, no tiene sentido comparar estas tasas de producción.

Sin embargo, los administradores tienen que estimar la productividad de los ingenieros en el proceso de desarrollo de software. Estas estimaciones son necesarias para la estimación del proyecto y para valorar si los procesos o las mejoras tecnológicas son efectivas. Por lo general, estas estimaciones de productividad se basan en medir algunos atributos del software y dividir el resultado entre el esfuerzo total requerido para el desarrollo. Existen dos tipos de medidas utilizadas:

1.1.1.1. Medidas relacionadas con el tamaño

Estas se relacionan con el tamaño de alguna salida de una actividad. La medida más común relacionada con el tamaño son las líneas de código fuente entregadas. Otras medidas que se utilizan son el numero de instrucciones de código objeto entregado o el número de páginas de la documentación.

1.1.1.2. Medidas relacionadas con la función

Estas se relacionan con la funcionalidad total del software entregado. La productividad se expresa en términos de la cantidad de funcionalidad útil producida en un tiempo dado. Los puntos de función y los puntos de objeto son las medidas más conocidas de este tipo.

Las líneas de código fuente por programador-mes son una métrica ampliamente utilizada en la medida de la productividad. Esta se calcula contando de número total de líneas del código fuente que se entrega. La cuenta se divide entre el tiempo total de programadores-mes requeridos para completar el proyecto. Por lo tanto, este tiempo incluye el tiempo requerido para el análisis y diseño, codificación, pruebas y documentación.

Este enfoque se desarrollo cuando muchos de los programas estaban en FORTRAN, lenguaje ensamblador o COBOL. Entonces, los programas se tecleaban en tarjetas, con una instrucción en cada tarjeta. El número de líneas del código era fácil de calcular. Correspondía al número de tarjetas en la cabina de tarjetas. Sin embargo, los programadores en lenguajes como JAVA o C++ consisten de declaraciones, instrucciones ejecutables; otras cuentan las instrucciones ejecutables y comentarios. Incluyen macroinstrucciones que ocupan varias líneas de código. Existe más de una instrucción por línea. Por lo tanto, no existe una relación sencilla entre las instrucciones del programa y las líneas de un listado.

Algunas técnicas de conteo de líneas consideran solo las instrucciones ejecutables; otras cuentan las instrucciones ejecutables y las de datos; algunas cuentan cada línea que no esté en blanco en el programa, independientemente de lo que esté en esa línea. Se han propuesto estándares para el conteo de líneas para varios lenguajes (Park, 1992) pero éstos no son ampliamente conocidos. Las comparaciones de productividad en las organizaciones son imposibles a menos que cada organización utilice el mismo método para contar las líneas de código.

Comparar la productividad de los diferentes lenguajes de programación también da impresiones engañosas de productividad del programador. Entre más expresivo sea un lenguaje de programación, más baja es la productividad aparente. Esta anomalía surge debido a que todas las actividades de desarrollo de software se consideran de forma conjunta cuando se calcula la productividad pero la métrica utilizada sólo aplica a los procesos de programación.

	Análisis	Diseño	Codificación	Pruebas	Documentación
Código ensamblador	3 semanas	5 semanas	8 semanas	10 semanas	2 semanas
Lenguaje de alto nivel	3 semanas	5 semanas	8 semanas	6 semanas	2 semanas
	Tamaño	Esfuerzo	Productividad	Cuadro 2. Tiempos de desarrollo del sistema.
Código ensamblador	5000 líneas	28 semanas	714 líneas/mes
Lenguaje de alto nivel	1500 líneas	20 semanas	300 líneas/mes

Por ejemplo, considere un sistema que podría codificarse con 5000 líneas de código ensamblador o 1500 líneas de código en un lenguaje de alto nivel. En el cuadro 2 se muestra el tiempo de desarrollo para las diversas fases. El programador en lenguaje de alto nivel menos de la mitad de estas, 300 líneas/mes. Así los costos de desarrollo para el sistema en lenguajes de alto nivel son menores y se producen en menor tiempo.

Una alternativa a la utilización del tamaño del código como atributo estimado del producto es utilizar alguna medida de la funcionalidad del código. Esto evitara la anterior anomalía puesto que la funcionalidad del código. Esto evitará la anterior anomalía puesto que la funcionalidad es independiente de la implementación del lenguaje. MacDonell (1994) brevemente describe y compara varias medidas diferentes basadas en la función.

La más conocida de estas medidas es el conteo de puntos de función. Éste fue propuesto por Albrecht (1979) y refinado por Albretch y Gaffney (1983). Los puntos de función son independientes del lenguaje por lo que se puede comparar la productividad en los diversos lenguajes de programación. La productividad se expresa como puntos de función producidos por personas-mes. Los puntos de función son adecuados para sistemas de procesamiento de datos que están dominados por operaciones de entrada y salida. Un punto de función no es una característica simple sino que es una combinación de características del programa. El número total de puntos de función en un programa se calcula midiendo o estimando las siguientes características del programa:

· Entradas y salidas externas.

· Interacciones con el usuario.

· Interfaces externas.

· Archivos utilizados por el sistema.

Cada una de estas se evalúa de forma individual acorde a su complejidad y se le asigna un valor de peso que varía desde 3 (para las entradas externas sencillas) hasta 15 (para los archivos internos complejos). Se pueden utilizar los valores de peso propuestos por Albretch o valores basados en la experiencia local.

El conteo de los puntos de función no ajustados (UFC) se calcula multiplicando los conteos llanos por el peso estimado y sumando todos los valores.

UFC =

Después, este conteo inicial de puntos de función es modificado por factores cuyo valor se basa en la complejidad total del proyecto. Esto toma en cuenta el grado de procesamiento distribuido, la cantidad de reutilización, el desempeño, etcétera. El conteo de puntos de función no ajustados se multiplica por los factores de complejidad del proyecto para producir un conteo de puntos función final.

Symons (1988) observo que la naturaleza subjetiva de la complejidad de las estimaciones implicaba que el conteo de puntos de función en un programa depende de la persona que hace la estimación. Varias personas tienen nociones diferentes de complejidad. Existe una amplia variedad de conteos de puntos de función, dependiendo del juicio del estimador. Por esta razón, existen versiones que difieren acerca del valor de los puntos de función (Furey y Kitchenham, 1997). Sin embargo, los usuarios argumentan que, a pesar de estos defectos, son efectivos en situaciones prácticas (Kemerer, 1993)

Los puntos de objeto (Banker 1992) son una alternativa para los puntos de función cuando se utilizan 4GLs o lenguajes comparables para el desarrollo de software. Los puntos de objeto se utilizan en el modelo de estimación COCOMO.

Los puntos de objeto no son clases de objetos que se producen cuando se considera un enfoque orientado a objetos para el desarrollo de software. Más bien, el número de puntos de objeto en un programa es una estimación con peso:

a. El número de pantallas independientes que se despliegan. Las pantallas sencillas cuentan como 1 punto de objeto, las pantallas moderadamente complejas cuentan como 2 y las pantallas muy complejas cuentan como 3 puntos de objeto.

b. El numero de informes que se producen. Para informes simples, cuentan como 2 puntos objeto, para informes moderadamente complejos, cuentan como 5 y para informes que son difíciles de producir, cuentan como 8 puntos objeto.

c. El numero de módulos 3GL que deben desarrollarse para complementar el código 4GL- cada módulo 3GL cuenta como 10 puntos de objeto.

La ventaja de utilizar puntos de objeto en lugar de puntos de función es que son más fáciles de estimar a partir de la especificación del software de alto nivel. Los puntos de objeto solo se refieren a las pantallas, informes y módulos 3GL.

Si se utilizaran los puntos de función o los puntos de objeto, entonces se pueden estimar en las primeras etapas del proceso de desarrollo. Las estimaciones de estos parámetros se pueden hacer tan pronto como se diseñen las interacciones externas del sistema. En esta etapa, es muy difícil producir una estimación precisa del tamaño de un programa en líneas de código fuente. En efecto, tal vez el lenguaje de programación a utilizar aun no está decidido. Las primeras estimaciones son esenciales cuando se utilizan los modelos de estimación de costos algorítmicos.

Los conteos de los puntos de función se pueden utilizar junto con las técnicas de estimación de líneas de código. El número de puntos de función se utiliza para estimar el tamaño final del código, AVC, en un lenguaje particular requerido para implementar un punto de función. El tamaño estimado del código para una nueva aplicación se calcula como se muestra a continuación:

Tamaño del código = AVC x Número de puntos de función.

FACTOR	DESCRIPCION
Experiencia en el dominio de la aplicación	Conocer el dominio de la aplicación es esencial para el desarrollo efectivo de software. Los ingenieros que ya conocen un dominio son probablemente los más productivos.
Calidad del proceso	El proceso de desarrollo utilizado puede tener un efecto importante en la productividad.
Tamaño del proyecto	Entre más grande sea un proyecto, se requiere más tiempo para las comunicaciones del equipo. Se dispone de menos tiempo para el desarrollo por lo que la productividad individual se reduce.
Apoyo tecnológico	La productividad se puede mejorar si se tiene buen apoyo tecnológico como de la herramientas CASE, de sistemas de administración de la configuración, etcétera.
Ambiente de trabajo	Un entorno de trabajo silencioso con áreas de trabajo privado contribuye a mejorar la productividad.
Cuadro 3: Los factores que afectan la productividad de la ingeniería de software.

La productividad de los ingenieros que trabajan en una organización se ve afectada por varios factores. Algunos de los más importantes se resumen en el cuadro 3. Sin embargo, las diferencias individuales en la habilidad son más importantes que cualquiera de estos factores. En una primera valoración de la productividad encontraron que algunos programadores eran diez veces más productivos que otros. La experiencia señala que esto aún es cierto. Los equipos grandes tienen una mezcla de habilidades por lo que tiene una productividad “promedio”. Sin embargo, en los equipos pequeños la productividad total depende en gran medida de las aptitudes y habilidades individuales.

No existe algo similar a un valor “Promedio” para la productividad que aplique a los dominios de aplicación y a las organizaciones. Para sistemas incrustados, grandes y complejos, la productividad es tan baja como 900 líneas/mes. Cuando se mide en términos de de puntos de objeto. Bohem señala que la productividad varía desde cuatro puntos de objeto por mes hasta 50 puntos de objeto/mes dependiendo de la herramienta de apoyo y de la capacidad del desarrollador.

El problema cuando estas medidas se expresan como volumen/tiempo es que no toman en cuenta las características no funcionales del software como la fiabilidad, el mantenimiento, etc.

1.1.2. Técnicas de estimación

No existe una forma simple de hacer una estimación precisa del esfuerzo requerido para desarrollar un sistema de software. Las estimaciones iniciales se hacen bajo la base de la definición de requerimientos de usuario de alto nivel. El software tiene que ejecutarse en computadoras poco familiares o utilizar nuevas tecnologías de desarrollo. Probablemente no se conozcan las personas involucradas en el proyecto y sus habilidades. Todos estos factores significan que en una primera etapa del proyecto es difícil producir una estimación precisa de los costos de desarrollo del sistema.

Por lo general, las estimaciones de los costos del proyecto se cumplen por su propia naturaleza. La estimación se utiliza para definir el presupuesto del proyecto y el producto se ajusta par que las cifras del presupuesto se cumplan. No se conocen informes de experimentos controlados sobre los costos de los proyectos donde los costos estimados no se utilicen para ajustar el experimento. Un experimento controlado no revelaría la estimación del costo al administrador del proyecto. Los costos reales tendrían que compararse con los estimados del proyecto.

A pesar de esto, las organizaciones necesitan hacer esfuerzos de software y estimaciones de los costos. Para hacerlo, se utilizan una o más de las técnicas descritas en el siguiente cuadro.

FACTOR	DESCRIPCION
Modelado del algoritmo de costos	Se desarrolla un modelo utilizando información histórica de costos que relaciona alguna métrica de software (por lo general, su tamaño) con el costo del proyecto. Se hace una estimación de esa métrica y el modelo predice el esfuerzo requerido.
Opinión de expertos	Se consultan varios expertos en las técnicas de desarrollo de software propuestas y en el dominio de aplicación. Cada uno de ellos estima el costo del proyecto. Estas estimaciones se comparan y discute. El proceso de estimación se itera hasta que se acuerda una estimación.
Estimación por analogía	Esta técnica es aplicable cuando otros proyectos en el mismo dominio de aplicación se han completado. Se estima el costo de un nuevo proyecto por analogía con estos proyectos completados Myers (1989) da una descripción muy clara de este enfoque.
Ley de Parkinson	La ley de Parkinson establece que el trabajo se extiende para llenar el tiempo disponible. El costo se determina por los recursos disponibles más que por los objetivos logrados. Si el software se tiene que entregar en 12 meses t se dispone de cinco personas el esfuerzo requerido se estima en 60 personas-mes
Asignar precios para ganar	El costo del software se estima independientemente de lo que el cliente esté dispuesto a pagar por el proyecto. El esfuerzo estimado depende del presupuesto del cliente y no de la funcionalidad del software.
Cuadro 4: Técnicas de estimación de costos.

Cuando se estiman costos de software, los administradores deben tomar en cuenta que existen diferencias importantes entre los proyectos anteriores y los futuros. Una gran variedad de nuevos métodos y técnicas de desarrollo han aparecido en los últimos diez años. Muchos administradores tienen poca experiencia en estas técnicas o poco conocimiento de cómo estas afectan los costos de los proyectos. Algunos ejemplos de los cambios que afectan las estimaciones de acuerdo con la experiencia son:

Ø Desarrollo orientado a objetos en lugar de desarrollo orientado a funciones.

Ø Sistemas cliente-servidor en lugar de sistemas basados en mainframes.

Ø Utilización de componentes de software comerciales en lugar de desarrollo de componentes.

Ø Desarrollar y reutilizar en lugar de desarrollar todas las partes de un sistema.

Ø La utilización de herramientas CASE y generadores de programas en lugar de desarrollo de software sin ayuda.

Todos estos factores han difícil que los administradores produzcan estimaciones precisas de los costos de producción del software. Su experiencia previa no es relevante para ayudarles a estimar los costos del proyecto de software.

1.1.3. Modelado algorítmico de costos

El enfoque más sistemático, aunque no necesariamente el más preciso, para la estimación del software es la estimación algorítmica de costos. Un modelo algorítmico de costos se construye analizando los costos y atributos de los proyectos realizados. Se utiliza una fórmula matemática para predecir los costos basados en estimaciones del tamaño del proyecto, número de programadores y otros factores de los procesos y productos Kitchenham (1990) describe 13 modelos algorítmicos de costos desarrollados a partir de observaciones empíricas.

En su forma general, una estimación algorítmica de costos para el software se expresa como:

Esfuerzo = A x Tamaño ^B x M

Esta fórmula A es un factor constante que depende de las practicas organizacionales locales y del tipo de software que se desarrolla. Tamaño es una valoración del tamaño del código del software o una estimación de la funcionalidad expresada en puntos de función o de objetos. El valor de exponente B por lo general se encuentra entre 1 y 1.5. Refleja el esfuerzo requerido para proyectos grandes. M es un multiplicador generado al combinar diferentes procesos, atributos del producto y del desarrollo.

Todos los modelos algorítmicos padecen las mismas dificultades básicas.

a. A menudo es difícil estimar Tamaño en una primera etapa de un proyecto donde solamente está disponible la especificación. Las estimaciones de los putos de función y los puntos de objeto son los más fáciles de producir que las del tamaño del código pero puede ser imprecisas.

b. Las estimaciones de los factores B y M son subjetivas. Las estimaciones varían de una persona a otra, dependiendo de su conocimiento y experiencia.

1.1.3.1. El modelo COCOMO

Se han propuesto varios modelos algorítmicos como una base para estimar el esfuerzo, la calendarización y los costos de un proyecto de software. Éstos son similares conceptualmente pero utilizan diferentes valores en sus parámetros. El modelo especifico que se discute aquí es el modelo COCOMO. Éste es un modelo empírico. Se obtuvo recolectando datos de varios proyecto de software grandes y después analizando esos datos para descubrir formulas que se ajustaran mejor a las observaciones. Elegí COCOMO por las siguientes razones.

a. Está bien documentado, es de dominio público y lo apoyan el dominio público y las herramientas comerciales.

b. Se ha utilizado y evaluado muy ampliamente.

c. Tienen una gran tradición desde su primera versión en 1981 (Bohem, 1981), pasando por un refinamiento para el desarrollo de software en ADA (Bohem y Royce 1989) gasta su versión más reciente publicada en 1995. (Bohem, 1995)

La primera versión del modelo COCOMO (conocida como COCOMO 81) fue un modelo de tres niveles donde estos reflejaban el detalle del análisis de la estimación del costo. El primer nivel (básico) provee una estimación inicial burda, el segundo nivel modifica utilizando varios multiplicadores del proyecto y el proceso, y el nivel más detallado produce estimaciones para las diferentes fases del proyecto. El siguiente cuadro muestra la formula básica de COCOMO para los diferentes tipos de proyectos.

Complejidad del proyecto	Fórmula	Descripción
SIMPLE	PM = 2.4 (KDSI)^1.05 x M	Aplicaciones bien comprendidas desarrolladas por equipos pequeños.
MODERADA	PM = 3.0 (KDSI)^1.12 x M	Proyectos más complejos donde los miembros del equipo tienen experiencia limitada en sistemas relacionados.
INCRUSTADA	PM = 3.6 (KDSI)^1.20 x M	Proyectos complejos donde el software es parte de un complejo fuertemente acoplado de hardware, software, reglas y procedimientos operacionales.
Cuadro 5: El modelo básico de COCOMO 81

1.1.3.2. Modelo algorítmico de costos en la planeación del proyecto

Los administradores de proyectos pueden utilizar un modelo algorítmico de costos para comparar las diferentes formas de invertir dinero para reducir los costos del proyecto. Esto es particularmente importante donde existen costos e hardware/software comerciales y donde se necesita reclutar nuevo persona con habilidades especificas para el proyecto.

Considere un sistema incrustado para controlar un experimento que se lanzará al espacio. Los experimentos espaciales tienen que ser muy fiables y están sujetos a límites de peso rigurosos. El numero de chips es una tarjeta electrónica tiene que minimizarse. En términos del modelo COCOMO, los multiplicadores correspondientes a las restricciones y la fiabilidad de la computadora son más grandes que 1.

Existen tres componentes a ser tomados en cuenta en el costo de este proyecto:

a. El costo del hardware objetivo que ejecuta el sistema.

b. El costo de la plataforma (computadora mas hardware) para desarrollar el sistema.

c. El costo del esfuerzo requerido para desarrollar el software.

1.1.4. Duración y personal del proyecto

Así como es necesario estimar el esfuerzo requerido para desarrollar un sistema de software y los costos totales del esfuerzo, los administradores de proyectos también estiman cuánto durara el desarrollo del software y cuanto personal se necesita para trabaje en el proyecto. El tiempo de desarrollo del proyecto se denomina duración del proyecto. Cada vez más, las organizaciones demandan tiempos de duración más cortos para que sus productos salgan al mercado antes que los de sus competidores.

La relación entre el número de personas que trabajan en un proyecto, el esfuerzo total requerido y el tiempo de desarrollo no es lineal. En cuanto crezca el número de personal, se necesitara más esfuerzo. Las personas deben invertir más tiempo en comunicarse. Se requiere más de un tiempo para definir las interfaces entre las partes del sistema. Doblar el número de personas (por ejemplo) no significa que la duración del proyecto se reducirá a la mitad.

1.2. Estimación De Costos De Proyecto

Cualquier tarea pasada por alto inadvertidamente durante el periodo de estimación, dará como resultado un menosprecio del proyecto en su totalidad, este hecho, a su vez podría comprometer la planificación del factor tiempo y de los recursos que se deben utilizar y, lo que es peor, habrá que pagar un trabajo omitido, no en base al presupuesto, sino en base a los beneficios esperados.

Toda empresa con experiencia en la ejecución de proyectos software debe de elaborar unas listas de comprobación para cotejar con las listas de trabajo del propio proyecto para salvaguardar omisiones. Repetimos que cualquier detalle pasado por alto en la fase del estudio del esfuerzo a aplicar puede tener consecuencias importantes, no sólo en la dimensión temporal del proyecto, sino en la calidad del producto a obtener o en el calendario del propio proyecto.

Existen muchos estudios sobre las técnicas de estimación de costes, el objetivo de la presente lección no es presentar al alumno una descripción de todas y cada una de ellas, pero sí de las más utilizadas, por eso presentamos la técnica de los puntos función de Albrecht (IBM), el COCOMO (Constructive Cost Method) de Boehm y la estimación de Putman.

El más utilizado es el de los puntos función de Albrecht cuya originalidad proviene de estimar los costes en función de la complejidad de los aspectos externos, o funciones, del propio programa. Por otra parte está bastante extendido el método COCOMO de Boehm que se describe en su libro 1 "Software Engineering Economics", y presenta una técnica del modelo a tres niveles según la complejidad de los proyectos aportando herramientas para controlar el coste, no sólo del diseño y desarrollo del sistema, sino que cubre todos los aspectos en la estimación de todo el proyecto a lo largo de su ciclo de vida, excepto el estudio de viabilidad, puesta en marcha y mantenimiento.

1.2.1. Modelos Empíricos

Una vez asentados sus conocimientos sobre las fases en que se divide un proyecto software desde las perspectivas de los distintos paradigmas de la Ingeniería del Software se considera, en líneas generales, que todo proceso de desarrollo de software está compuesto por tres fases genéricas que son: definición, desarrollo y mantenimiento, y en todos ellos tenemos que considerar los modelos de estimación de costes, que si bien en Informática no son relativamente novedosos, ya que los primeros esbozos en estudiar este problema comenzaron hace poco más de dos décadas, la implantación real en la industria no se ha realizado de forma masiva hasta que se ha dado el hecho de que el software se ha convertido en el factor más costoso de un sistema de información; es más: la desviación producida por los costes de software en el desarrollo de un proyecto tenía poca incidencia en el coste total, cosa que no ocurre hoy día ya que un error de estimación del tiempo de desarrollo puede colocar el proyecto entre el beneficio y la pérdida económica.

Los modelos de estimación tienen aplicación dentro de la fase de definición de un sistema software. En esta fase lo que se define es el qué, es decir, se intenta identificar en ella qué información va a ser procesada, qué función y rendimiento se desea, qué interfaces han de establecerse, qué ligaduras de diseño existen y, por último, qué criterios de validación se requieren para definir un sistema correcto. Dentro de la mayor parte de las organizaciones, la estimación de costes de un sistema software está basada en experiencias pasadas. Los datos históricos se usan para identificar los factores de coste y determinar la importancia relativa de los diversos factores dentro de la organización. Lo anteriormente expuesto implica que los datos de coste y productividad de los proyectos actuales deben de ser centralizados y almacenados para su empleo posterior. La estimación de costes puede llevarse a cabo de forma jerárquica hacia abajo (Top-Down) o jerárquica hacia arriba (Bottom-Up).

La estimación jerárquica hacia abajo se enfoca primero a los costes a nivel del sistema, además de los costes del manejo de la configuración, del control de calidad, de la integración del sistema, del entrenamiento y de la documentación. Los costes del personal relacionado se estiman mediante el examen del coste de proyectos anteriores que resulten similares. En la estimación jerárquica hacia arriba, primero se estima el coste del desarrollo de cada módulo o subsistema, tales costes se integran para obtener un coste total. La técnica puede fallar al no considerar los costes del manejo de la configuración o del control de calidad, pero tiene la ventaja de enfocarse directamente a los costes del sistema. Podemos establecer una clasificación de los llamados modelos empíricos de estimación de costes basados en la experiencia:

1.2.1.1. Juicio de experto

En esta categoría un experto o grupo de expertos estudia las especificaciones y hace su estimación (jerárquica hacia arriba o hacia abajo) en base a sus conocimientos previos. Cuando hay un único experto se denomina juicio experto puro y la empresa corre el riesgo de confiar una tarea tan importante a una única persona. Si desaparece el experto se deja de estimar. Si es un grupo de expertos el que estima se suele utilizar el método Delphi o juicio experto. Este método consiste en que el grupo se reúne para dar sus opiniones sobre la estimación. Las conclusiones individuales se envían al coordinador del grupo que las compara entre sí. Si los resultados son parecidos la estimación se da por buena, si no es así cada estimador recibe información sobre su estimación, y las ajenas pero de forma anónima. Cada uno revisa su propia estimación y la envía de nuevo al coordinador. Se repite el proceso hasta que la estimación converge de forma razonable. Es posible realizar nuevas reuniones del grupo si el coordinador lo considera oportuno según la divergencia de las estimaciones recibidas Tiene la ventaja de que las estimaciones de un grupo suelen ser mejores que las individuales y que el experto único no se convierte en un recurso crítico imprescindible.

1.2.1.2. Analogía

Consiste en comparar las especificaciones de un proyecto, con las de otros proyectos similares según el tamaño, complejidad, número y tipo de usuarios y otros factores como sistemas operativos, hardware, personal, etc.

1.2.1.3. Distribución de la utilización de los recursos durante el ciclo de vida.

Este método solo se puede aplicar cuando el proyecto ya ha comenzado y se ha desarrollado alguna de sus fases. Usualmente las organizaciones tienen una estructura de costes similar entre las distintas fases del ciclo de vida (especificaciones, análisis, diseño, construcción, prueba e implantación) de sus proyectos. Si en un proyecto ya hemos realizado algunas fases, es de esperar que los costes se distribuyan de manera proporcional en las fases siguientes.

1.2.1.4. Método basado exclusivamente en los recursos.

En la estimación consiste en ver de cuanto personal disponemos para el proyecto y durante cuánto tiempo se dispone de él. Estos serán los recursos a utilizar. Se basa en la siguiente premisa “El trabajo se expande hasta consumir todos los recursos disponibles” (Ley de Parkinson).

1.2.1.5. Método basado exclusivamente en el mercado.

Parte de que lo más importante es conseguir el contrato. El precio se fija en función de lo que creemos que está dispuesto a pagar el cliente. La estimación de costes del proyecto será el precio a pagar por el cliente menos los beneficios económicos que se desea obtener.

1.2.2. Puntos Función

Las Métricas Orientadas a la Función se basan en estimar no el número de líneas fuente del programa (LDC) sino su "funcionalidad". Estas métricas, propuestas inicialmente por Albretch en 1979 y 1983, intentan buscar un factor de productividad del software mediante el método denominado de análisis de los puntos función 2. Los puntos de función se obtienen como consecuencia de haber estudiado distintos proyectos de software y haber aplicado sobre ellos una métrica basada en la complejidad y el tamaño de la función realizada.

La medida del punto función se ha aplicado con éxito en sistemas “no empotrados” y concretamente en sistemas comerciales y puede no ser relevante en otros sistemas de ingeniería.

Las métricas orientadas al tamaño son bastante polémicas y no están aceptadas universalmente como el mejor método para medir la productividad en el desarrollo del software ya que el número de líneas de código escrito no parece una buena medida. Sus defensores dicen que esta medida es fácil de aplicar y que puede ser calculada fácilmente en base a la experiencia y que existe una gran cantidad de información basada en las LDC. Sus detractores dicen que las LDC dependen del lenguaje de programación, que perjudica a los programas más cortos pero mejor diseñados y que su utilización requiere un nivel de detalle que puede ser difícil de conseguir.

El análisis de los puntos función se basa en establecer relaciones entre los componentes básicos de cada tarea y el esfuerzo requerido en desarrollarlos. El procedimiento a seguir para calcular los puntos función consiste en ir rellenando los datos de una serie de tabla, basada en la experiencia, en las que se introducen algunos datos respecto a variables del proyecto como pudieran ser el número de entradas, el número de salidas, la cantidad de ficheros que trata la aplicación, el tamaño de los ficheros en número de campos, la cantidad de consultas que se pretenden efectuar, etc. Cada uno de estos valores se clasifica en tres categorías respecto a la complejidad que puede ser alta, media o baja. Igualmente se establece una segunda dimensión en cuanto al tamaño de cada elemento, clasificándolos en pequeño, medio y grande. En ambas clasificaciones siempre será más importante seguir criterios de consistencia sobre criterios de precisión; es decir deberá imperar el método de clasificar en grandes grupos todos los elementos de la configuración.

1.2.3. Distribución Porcentual Del Esfuerzo

Un método empleado por muchas compañías es el basado en la distribución porcentual del trabajo que se emplea en organizaciones donde el tipo de proyectos software que realizan son muy homogéneos y se basa en tener estadísticas muy actualizadas de los tiempos medios en satisfacer cada una de las fases del proyecto.

En nuestro caso, y según experiencias anteriores, se sabe que la media de nuestros últimos trabajos ha supuesto que la fase de diseño supone un porcentaje del tiempo total invertido en cada proyecto con independencia del tamaño, y cada una de las fases se distribuye según el porcentaje expuesto. Con estos criterios se puede estimar, por medio de la extrapolación, la duración total del proyecto cuando se ha ejecutado alguna de sus partes.

Este método tiene serios inconvenientes, sobre todo cuando los proyectos no son del mismo tamaño, ya que no es normal que se disponga de tablas adecuadas para cada tipo de proyectos suficientemente actualizados. No obstante se utiliza bastante como control de validez del método de los Puntos Función de Albretch, sobre todo cuando se comparan los porcentajes de ambos métodos, ya que nos puede ayudar a estudiar dónde se producen las mayores desviaciones por si se trata de errores de cálculo o si se han omitido alguna de las fases.

Para efectuar esta comparación se tabulan sobre una hoja de cálculo los resultados de cada fase del ciclo de vida y se decide estudiar a detalle aquellos hitos que tengan una desviación superior al 15%.

1.2.4. Modelo Cocomo

Es un modelo de costes, descrito por Barry W. Boehm en 1981 de tipo algorítmico que proporciona estimaciones directas tanto de la duración como del esfuerzo que está basado en la cantidad de líneas de código fuente escritas en la totalidad. Se trata de un modelo de estimación empírico que está basado en el paradigma del ciclo de vida clásico o modelo en cascada. Boehm se basa para el desarrollo de su modelo en los diagramas de procesos establecidos en la mayor parte de las metodologías de desarrollos de sistemas informáticos clásicas. Las fases que cubre el modelo de Boehm son todas las descritas en el ciclo de vida de productos software con la excepción del estudio de la viabilidad y el análisis de requerimientos, los cuales se estiman como un apartado cuantitativo del software de desarrollo. Sin embargo si se incluyen todos los costes incurridos en cada fase.

COCOMO es el modelo empírico para la estimación de los costes de producción de software más utilizado por los equipos de desarrollo de sistemas informáticos de tamaño grande, sin embargo, se deben tener en cuenta los propios comentarios de Boehm sobre COCOMO y por extensión sobre todos los modelos: “Hoy en día, un modelo de estimación de costes está bien realizado si puede estimar los costes de desarrollo de software dentro del 20% de los costes reales, del 70% del tiempo y en su propio campo (o sea dentro de los tipos de proyectos en los que ha sido calibrado). Esto no es tan preciso como quisiéramos, pero es lo suficientemente preciso para proporcionar una buena ayuda en el análisis económico de la ingeniería del software y en la toma de decisiones”.

Boehm como: considera que la función de distribución de Rayleight, definida

Donde td es el momento en el que se introduce un esfuerzo máximo, es un estimador exacto para los requisitos de personal para el ciclo de vida del desarrollo (desde el diseño arquitectónico hasta las pruebas del sistema siempre que usemos la porción de curva entre 0,3t y 1,7 t ).

El estimador de Rayleight

Antes de abordar el modelo propiamente dicho, es preciso enumerar una serie de definiciones y consideraciones en las que se basa Boehm para el desarrollo del modelo, como son:

Ø El cálculo del coste primario está basado en el número de instrucciones fuentes desarrolladas en el proyecto sin incluir las líneas de comentarios, pruebas, documentación, etc., a no ser que se escriban con un fin expreso y cuidado.

Ø El periodo de desarrollo cubierto por el modelo comienza al iniciarse la fase de diseño y termina al finalizar la fase de integración y prueba. El coste y calendario de otras fases se estiman por separado.

Ø El modelo cubre únicamente las actividades indicadas dentro del equipo de desarrollo de actividades o procesos del ciclo de vida. Por ello, incluye el esfuerzo de organización y documentación, pero excluye algunos esfuerzos tales como la planificación de la instalación, esfuerzo de conversión, etc.

Ø Las soluciones se expresan en criterios de la forma hombres-mes refiriéndose a 152 horas de tiempo de trabajo al mes desarrollado por las personas del equipo de desarrollo. Este factor se ha calculado teniendo en cuenta la experiencia en los distintos proyectos desarrollados y considerando el tiempo de vacaciones.

Ø El modelo considera que el proyecto es bien dirigido tanto por el desarrollador del mismo como por el cliente, existiendo por ello muy pocos tiempos perdidos en el análisis de requerimientos del producto.

Ø Considera que la especificación de requerimientos no tiene cambios sustanciales después de la fase de planificación y requerimientos del producto.

Ø El modelo avanzado considera que la influencia de los factores conductores de coste del software dependen de cada fase. Los otros modelos sólo hacen diferencias entre la etapa de desarrollo y la etapa de mantenimiento.

Ø El coste de cada fase incluye todos los costes incurridos durante la fase. Los costes de actualización del plan de integración y prueba y la aceptación completa de los planes de prueba están incluidos en la fase de diseño detallado.

Para que se cumplan los criterios de estimación del ciclo de vida desarrollo de software es necesario resaltar las siguientes características:

Ø Se debe de prestar especial cuidado a la definición y validación de la especificación de los requerimientos software por un grupo de personas relativamente pequeño con anterioridad a la entrada en la fase de diseño.

Ø Posteriormente se debe de someter la definición y validación del diseño del sistema software a un grupo de personas algo más grande como actividad anterior a la entrada en la fase de diseño detallado y de la codificación.

Ø El diseño detallado, la codificación y las pruebas de unidades serán desarrollados por un grupo grande de programadores trabajando en paralelo, y siguiendo una línea base sólida que suponga un desarrollo incremental de la planificación.

Ø La integración y prueba de cada incremento en el sistema está basada en una gran cantidad de planificación de pruebas tempranas y en la eliminación de casi todas las unidades defectuosas por medio de cuidadosos y completos recorridos de las unidades desarrolladas.

Ø Una parte importante del esfuerzo de documentación (por ejemplo los borradores de los manuales de usuario) se desarrollará en fases tempranas para proporcionar a los usuarios (y desarrolladores) información acerca de la naturaleza operacional del producto.

Para ajustar mejor sus estimaciones Boehm creó tres escenarios de estimación clasificando su modelo de forma jerárquica y en base a la complejidad y cantidad de información utilizada en la estimación; a los que denominó modelos COCOMO que son:

Ø Modelo básico

Ø Modelo intermedio

Ø Modelo avanzado

1.2.4.1. El modelo básico

Es un modelo estático, evaluado de forma única y que calcula el esfuerzo y el coste de desarrollo del software en función del tamaño del programa expresado en líneas de código estimadas (DSI o LDC). Tamaño

1.2.4.2. El modelo intermedio

Calcula el esfuerzo de desarrollo en función del programa y un conjunto de guías de coste que incluyen una evaluación subjetiva tanto del producto, como del hardware, del personal y de los atributos del proyecto.

1.2.4.3. El modelo avanzado

Incorpora todas las características de la versión intermedia con una evaluación del impacto de las guías de coste en cada fase (análisis, diseño, etc.) del proceso de ingeniería del software.

1.2.5. Método De Estimación De Putman

El modelo de estimación de Putman es un modelo multivariable dinámico que asume una distribución específica del esfuerzo a lo largo del ciclo de vida de un proyecto de desarrollo software. Las curvas mostradas en la figura toman la forma clásica descrita por Lord Rayleight en el año 1978 y los datos empíricos fueron recogidos por Norden.

La función es de la forma:

Donde C k es una constante de estado de la tecnología y refleja “las restricciones directas que frenan el progreso del programador”, K es el esfuerzo necesario medido en personas-hombre durante todo el ciclo de vida, K es el esfuerzo total del desarrollo en personas-año y td es el tiempo de desarrollo en años y L el número de miles de líneas fuente del proyecto.

Algunos valores típicos de C k pueden ser C k =2000 en entornos de desarrollo típicos o C k = 8000 en un buen entorno de desarrollo con buena metodología y herramientas.

El valor del esfuerzo se puede despejar de la ecuación anterior resultando, la ecuación de la forma:

1.2.6. Herramientas Automáticas De Estimación

Una vez estudiados los distintos modelos empíricos de estimación de costos vamos a señalar como está el estado del arte en la implementación en programas de usuario:

Existe un producto, denominado comercialmente ESTIMACS, que utiliza un modelo basado en los puntos función de Albretch mejorado que permiten al planificador ajustarse a distintos factores de personal a la vez que permite llevar varios proyectos en paralelo .

El programa COSTAR es una aplicación directa del modelo COCOMO descrito por el Dr. Barry Boehm en su libro Software Engineering Economics en sus tres modos, y es, seguramente el más empleado en la industria, permite obtener información estimada del esfuerzo del desarrollo del sistema, de los costes y del personal necesario.

De este programa existen numerosas versiones, tanto para UNIX, MSDOS y Windows; que la compañía Sunsets actualiza constantemente.

Aspecto del programa COSTAR para MS-DOS.

Algunos avances sobre el modelo se pueden ver aplicados en el programa COSTAR II, que es una ampliación del programa anterior que soporta una mayor cantidad de modelos de estimación, incluido el modelo COCOMO II, Para facilitar la planificación del proyecto, en esta versión del programa, Costar II facialita el supuesto de análisis de la forma ¿qué pasaría si? Además de comparar distintos planes de proyectos. La riqueza de informes y gráficos hacen que Costar II sea, actualmente, la “estrella” de los programas de estimación de esfuerzos.

La versión de evaluación permite estimar proyectos de hasta 5000 líneas de código fuente y permite efectuar supuestos sobre la duración partiendo de personal dedicado al proyecto y su inversa, es decir, qué personal se debe de dedicar en cada una de las fases de desarrollo para satisfacer un calendario previsto según unas especificaciones dadas.

En la versión evaluada (6.0) se ofrecen numerosas intercambiar la información con otros programas de Windows, obtener información gráfica para insertar o adjuntar dentro de ofimáticas como puede ser Microsoft Word.

Aspecto de Costar II

Otro producto interesante es el SLIM, basado en el modelo de Putnam que permite obtener unos estudios de programación lineal, la simulación estadística y los diagramas PERT en el mismo paquete.

Muchas instituciones y casa comerciales tienen herramientas en la red, alguna de ellas como puede ser el caso de la NASA, que presenta el aspecto de la siguiente figura.

Pagina COCOMO de la NASA

Todos estos productos, hoy día disponible en computadoras personales, permiten calibrar el entorno local de desarrollo y crear un modelo de información del software desarrollado mediante sus características básicas, los atributos de personal y las consideraciones del entorno.

Si en su organización no se dispone de software de estimación de proyectos, se pueden buscar “sitios” de la red que disponga de software que esté más o menos calibrado a nuestro entorno de desarrollo y a los usos y costumbres del grupo de trabajo concertadas en forma de metodologías.

1.2.7. Discusión Final

La estimación es una tarea difícil y errática en la Ingeniería del Software que se fundamenta en “medir” experiencias pasadas. De todos los modelos de estimación resulta ser COCOMO el más universalmente aceptado si bien hay que hacer hincapié en que cualquier método de estimación se debe de ajustar a la organización. Por ello, podemos decir que: una estimación de costes es sólo tan buena como nuestra capacidad de extrapolar al futuro las experiencias pasadas.

Una norma de buena costumbre que se suele utilizar en muchas ocasiones es la de comparar los resultados de ambas estimaciones en busca de desviaciones superiores al 15% para poder analizar las diferencias entre los componentes y así decidir si la planificación ha sido correcta.

Debido a que la mayor parte de las estimaciones de costes están desarrolladas en función del número estimado de instrucciones del producto final, la estimación de costes del producto no será superior a nuestra capacidad de estimar el número de instrucciones finales existentes en él.

El modelo de Barry W. Boehm proporciona una base firme para desarrollar una estimación de costes en un sistema software, debido a su adaptabilidad a los distintos sistemas, a su fácil aplicación y a la consideración por parte del modelo de la influencia de los factores más importantes del desarrollo de software.

Aunque existen otros modelos de estimación de costes, como el modelo SLIM de Putnam, el modelo SDC (System Development Corporation) de Nelson, etc., se ha desarrollado el estudio más profundo del modelo COCOMO debido a que es uno de los más completos de los existentes, además de uno de los más utilizados por las organizaciones para la estimación de costes en la producción de grandes sistemas informáticos.

1.3. Estimación de costos de Proyecto

El costo de un proyecto es de interés continuo y vital para los coparticipes. Con el precio de producción equivocado, incluso el producto más fantástico puede ser un desastre. La estimación de costo más sencilla es la que proporciona un costo fijo desde el principio, sin permitir desviaciones en ninguna circunstancia. Aunque las organizaciones muy competentes tienen suficientes aptitudes para cambiar las variables restantes (capacidad, programa de tiempos y calidad) para cumplir con un costo predeterminado, la rigidez absoluta en el costo no siempre se adopta. Suponga, por ejemplo, que un proyecto que desarrolla un producto que se vende muy bien se queda sin fondos cuando lleva el 90%. En lugar de abandonar todo el proyecto, lo común es que la organización haga todo lo posible para encontrar fondos para ese último 10%. Aun cuando el costo del proyecto seas rígido, es necesario estimar el costo de un conjunto dado de requisitos y/o del diseño para asegurar que cumple con el costo acordado y, si no lo hace, cambiarlos y después hacer la estimación de nuevo.

El proceso de estimar los costos (esto es, para capacidades, control de calidad y programación fijas) con frecuencia comienza desde la concepción del proyecto y continua aun después de iniciada la codificación. Cuando se inicia un proyecto, tal vez el equipo tenga sólo una idea vaga de su costo. Si la estimación del costo se puede posponer hasta que el proyecto tome forma, sin duda deben esperar, pero siempre existe la necesidad de estimar por lo menos un “intervalo burdo” a partir de un resumen de requisitos. Cuando más se sepa de los requisitos para el producto y mas diseño se realice, más preciso será el costo.

El error de estimación tan grande que indica en la siguiente figura se debe a un estudio reportado por Bohem. Por ejemplo, para una aplicación que con el tiempo costara $100 000, las estimaciones hechas después de desarrollar el concepto de la aplicación pueden ser tan bajas como $25 000 y tan altas como $400 000. Para perfeccionar la estimación del costo de un proyecto se usan varias técnicas lo antes posible, lo que significa reducir la altura de las líneas verticales de la figura.

Solo hasta el final del desarrollo se puede tener confianza completa en las estimaciones. (Sin embargo, las estimaciones son menos útiles en ese momento, ¡ya que la mayor parte del dinero está gastado!) Como la precisión es prácticamente imposible, un intervalo es una buena manera de proyectar los costos y esto se aplica al ejemplo anterior.

Sorprende a muchas personas que podamos siquiera pensar en los costos sin un diseño y los requisitos detallados, pero ésta es una práctica común en otros campos. Se puede obtener una estimación burda del costo de construir una casa, por ejemplo, sin un diseño o los requisitos detallados. Se pueden usar reglas cortas como “las casas en esta área cuestan alrededor de $100 por pie cuadrado de construcción”, y así una casa de 100 pies cuadrados costara alrededor de $100 000.

Una buena manera de enfocar la estimación de costos del proyecto durante las primeras etapas es desarrollar estimaciones de varias maneras independientes y después combinar resultados. Incluso se pueden ponderar las estimaciones obtenidas de acuerdo con el nivel de confianza personal en cada una de ellas.

Una máquina de coser o un torno es una herramienta compleja que no sirve sin un usuario capacitado. De igual manera la primera vez se usan las medidas de aproximación de costos es poco probable que los resultados sean confiables. El uso preciso de estas herramientas se aprende con el tiempo, la retroalimentación y la comprobación.

1.3.1. Estimación de líneas de código sin el proceso de puntos de función

Esta sección presenta la estimación de líneas de código en la etapa inicial, mucho antes de iniciar el trabajo de diseño. Una vez realizado éste, los métodos se basan en las partes del diseño y se vuelven mucho más precisos.

Varios métodos de estimación, como modelo de COCOMO, dependen del número de líneas de código (LoC).”COCOMO” son las siglas abreviadas de modelo de costos constructivo en ingles (CONSTRUCTIVE COST MODELO) de Boehm. En las primeras etapas de un proyecto es posible que COCOMO no parezca muy útil debido a que falta mucho para llegar a la codificación. Sin embargo, cuando un producto se puede comparar con otros, es factible estimar las líneas.

Las organizaciones que trabajan por encima del nivel 1 en los modelos de madurez de capacidades deben poder registrar las personas-hora y la duración de las partes de los trabajos. En ausencia de este tipo de datos, se tendría que comprar, por ejemplo, nuestro videojuego Encuentro con otros juegos. La obtención directa de los datos de otras compañías es entre difícil e imposible. Las publicaciones comerciales y de negocios, y los anuncios generales de la industria, en ocasiones proporcionan datos parciales. Por ejemplo, quizá se tenga conocimiento, por los informes públicos, que “BufEye Inc”. ha trabajado en sus nuevos juegos durante 3 años: tal vez incluso mencione un numero de programadores, pero debe sospecharse de estos datos, ya que algunas compañías consideran sus conocimientos sobre desarrollo como un activo corporativo y suelen exagerar estos números o publicar números menores, según sea el caso.

Cuando se dispone de un historial, tal vez sea necesario comparar el proyecto con proyectos relacionados (para el videojuego pueden ser simulaciones). Digamos que se tiene poca experiencia en la programación de juegos y alguna en la programación de simulaciones y Java. La estimación de líneas de código tal vez incluya algo como lo siguiente:

Una vez escribí una simulación no grafica de una cola sencilla en C++, que requirió entre 4 y 8 páginas de código, con alrededor de 30 a 50 líneas que no eran comentarios; esto es un total de 120 a 400 líneas. Suponga que Java requiere el mismo número de líneas. La primera versión comercial de Encuentro tiene de 4 a 15 colas de este tipo y de 30 a 90 componentes adicionales de tamaño comparable para hacerlo interesante, y esto da entre un mínimo de [(120 líneas) x (34 componentes)] y máximo de [(400 líneas) x (105 componentes)] para nuestro intervalo, o entre 5 000 y 42 000 líneas de código. El uso de gráficos multiplica el esfuerzo por 1.5 a 4 según la complejidad, lo que da un intervalo de 1.5 x 5 000 a 4 x 42 000 = 7.5 a 170 000 líneas de código.

1.4. Métricas

El proceso de planificación del desarrollo de cualquier sistema debe hacerse partiendo de una estimación del trabajo a realizar. Sólo a partir de ello es factible conocer los recursos necesarios y el tiempo necesario para su realización.

Una métrica es una medida efectuada sobre algún aspecto del sistema en desarrollo o del proceso empleado que permite, previa comparación con unos valores (medidas) de referencia, obtener conclusiones sobre el aspecto medido con el fin de adoptar las decisiones necesarias. Con esta definición, la definición y aplicación de una métrica no es un objetivo en sí mismo sino un medio para controlar el desarrollo de un sistema de software.

1.4.1. Métricas sobre el producto

Las métricas sobre el producto están orientadas a estimar las características del mismo antes de su desarrollo. Estas estimaciones se basan en el conocimiento que los desarrolladores adquieren a partir de datos obtenidos de proyectos anteriores.

1.4.1.1. Tamaño estimado del código.

La forma más obvia y la que se ha utilizado históricamente antes para estimar el tamaño es contar el número de líneas de código. Con ciertas normas para determinar qué es lo que se cuenta (líneas de comentario, código incluido, etc.) y siempre referido a un lenguaje concreto, lo que los valores nos dan es un valor para, comparando con otros casos, poder estimar el esfuerzo necesario en futuros desarrollos.

Los resultados obtenidos (estimaciones y valores reales) alimentan la base de datos históricos que es el fundamento para posteriores estimaciones.

Boehm desarrolló una técnica empleando el método Delphi para mejorar las estimaciones con múltiples opiniones de expertos. La idea de emplear el método Delphi es asegurar en dos o tres pasos de convergencia que las estimaciones son aceptadas por los expertos.

Ha sido muy criticada la tendencia en estimar el esfuerzo en base a las líneas de código. Una de las críticas se centra en que la complejidad del desarrollo no está directamente ligada al tamaño cuando nos movemos hacia el dominio de los sistemas concurrentes, distribuidos o de tiempo real. En ellos, las medidas deben referirse a estimaciones del mismo tipo de productos.

Otro problema surgido recientemente con la proliferación de generadores de código es que no importa demasiado el número de líneas de código generadas (excepto por problemas derivados del tamaño de la memoria para sistemas embebidos) sino el número de líneas de especificación que las han generado, porque la complejidad del problema de mantenimiento depende de ello.

1.4.1.2. Complejidad estimada.

Con el fin de superar el problema de las estimaciones del tamaño de código, se ha prestado recientemente atención a medidas de complejidad no basadas en estimaciones de número de líneas.

Albrecht definió en 1979 un método conocido como de puntos de función que está teniendo cada vez más aceptación. Su método se basa en el empleo de factores normalizados para juzgar la importancia relativa de varios requisitos funcionales.

Parte de cinco funciones básicas que suelen aparecer en muchos sistemas:

1) Entradas. Pantallas o formatos empleados para introducir datos a un programa.

2) Salidas. Pantallas o informes empleados para utilizarlos con otros programas o para lectura directa.

3) Consultas. Mecanismos para pedir ayuda o dar órdenes de ejecución.

4) Ficheros de datos. Conjuntos lógicos de información empleados por una aplicación (ya sean tablas en memoria como ficheros de disco) junto con los procedimientos de acceso a los mismos.

5) Interfaces. Ficheros compartidos con otras aplicaciones. La idea básica del método consiste en definir unas estimaciones de complejidad para cada una de estas funciones (en forma de pesos relativos) y estimar, dadas las especificaciones del sistema, cuántos elementos de cada tipo van a ser necesarios.

El problema con los puntos de función es que no son realmente medidas sino valoraciones subjetivas y no tienen en cuenta diferencias en la implementación (al fin y al cabo, el esfuerzo del desarrollo depende también del lenguaje utilizado o del dominio de aplicación y eso no se tiene en cuenta). De nuevo, la comparación con sistemas similares permite «calibrar» las decisiones tomadas.

1.4.1.3. Robustez.

Por robustez de un programa se entiende la ausencia de fallos en su ejecución con diferentes datos de entrada durante intervalos de tiempo predeterminados.

La robustez de un programa está ligada a la aparición de problemas durante su ejecución. Generalmente, el número de fallos encontrados durante la fase de prueba y, posteriormente, durante el mantenimiento del sistema constituye una medida de la calidad del producto de software e, indirectamente, de la calidad del proceso de desarrollo.

La importancia de conocer el número de fallos encontrados en un intervalo de tiempo no reside únicamente en obtener un valor global de la calidad del producto sino en los beneficios derivados de su análisis.

Las medidas estadísticas de fiabilidad (tiempo medio entre fallos encontrados durante la ejecución, reducción del número de recopilaciones necesarias, etc.) sirven para alimentar el proceso de desarrollo.

1.4.2. Métricas sobre el proceso

Las métricas mencionadas en la sección anterior estaban orientadas a conocer la complejidad del producto (con algún valor indirecto como el tamaño) para poder estimar los recursos necesarios para su realización. Hemos mencionado también que, según se vayan acumulando datos y se analicen estadísticamente, las estimaciones serán cada vez mejores. Esto nos servirá para planificar mejor futuros desarrollos.

Existen otros tipos de datos que se pueden tomar durante el desarrollo de un producto de software y que no están ligados al producto sino a los procesos implicados. El análisis de cómo estos procesos se realizan a partir de medidas tomadas en el desarrollo es la base para su ulterior mejora.

Algunos de los elementos a medir son:

A) Distribución del esfuerzo en cada una de las fases con objeto de poder estimar los recursos necesarios. Obsérvese que esta medida es complementaria al las de tamaño mencionado anteriormente; aquella nos permitía conocer los recursos globales necesarios; de lo que se trata aquí es de obtener medidas reales y extrapolarlas a futuros proyectos.

B) Productividad medida en número de líneas de código documentadas que es capaz de producir una persona en una unidad de tiempo. A título orientativo, podemos decir que los valores típicos de productividad por persona (empleando tecnologías de desarrollo convencional) están entre 30 y 50 líneas de código por día de trabajo.

1.5. Estimación de costos (concepto persona)

En el principio el costo del Software disponía un pequeño porcentaje del costo total de los sistemas basados en Computadoras. Hoy en día el Software es el elemento más costoso de la mayoría de los sistemas informáticos.

Un gran error en la estimación del costo puede ser lo que marque la diferencia entre beneficios y perdidas, la estimación del costo y del esfuerzo del software nunca será una ciencia exacta, son demasiadas las variables: humanas, técnicas, de entorno, políticas, que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo.

Muchas son las técnicas o métodos para realizar estimaciones.

Roger Pressman en su libro de Ingeniería de Software plantea que para lograr estimaciones del tamaño del proyecto confiables hay varias opciones:

Ø Retrasar la estimación para después.

Ø Basar la estimación en proyectos simulares ya terminados.

Ø Emplear técnicas de descomposición para generar estimaciones de costo y esfuerzo.

Ø Utilizar uno o más modelos empíricos en la estimación de costo y esfuerzo.

De ellas las más razonable es la de utilizar las técnicas y modelos empíricos, siendo la más recomendada pues es donde clasifican los métodos para estimar el tamaño del software planteados por Bhoem y Watts que son los más utilizados.

Por otra parte el esfuerzo es un indicador de la cantidad de trabajo necesario para realizar un proyecto. En productos de software se debe considerar equivalente estimar el esfuerzo y el coste ya que existe una relación directa entre ambos.

ADMINISTRACION DE PROYECTOS DE SOFTWARE

2010-05-11T12:05:00.000-07:00

ADMINISTRACION DE PROYECTOS DE SOFTWARE

1.1. LA GESTIÓN DEL CICLO DE VIDA DE UN PROYECTO

El presente esquema recoge las fases de las que se compone el Ciclo de Vida de un Proyecto: Definición, Planificación, Control y Seguimiento y Finalización.

El proyecto comienza con una definición que incluye la elaboración de la oferta y la especificación de requisitos, cuando se ha aprobado la oferta, se procede a la contratación y lanzamiento del proyecto, entonces se planifica y posteriormente se pasa a la ejecución que habrá que supervisar para que no se produzcan desviaciones con respecto al Baseline o para replanificarlo en caso de que sea necesario establecer un nuevo Baseline debido a que las condiciones iniciales planificadas (objetivos, plazos, presupuestos) hayan variado tanto que no sirvan como referentes. La última fase es la finalización.

La presente metodología abarca todas las fases del Ciclo de Vida del Proyecto facilitando la gestión de las mismas. A continuación se realiza una descripción más extensa de los aspectos a tener en cuenta en cada una de las fases:

1.1.1. INICIO

El Inicio es la primera etapa del Ciclo de Vida del proyecto. Se materializa elaborando la oferta y determinando los requisitos del producto/servicio que ofreceremos al cliente para su aceptación. Ambos elementos, oferta y requisitos, constituyen una presentación de la empresa y el proyecto al cliente, con el que nos comprometeremos, proporcionando una imagen de nosotros mismos, que trataremos que sea lo más positiva posible.

Por otro lado la labor de definición del proyecto nos permite conocer la disponibilidad de recursos para el desarrollo del mismo y por lo tanto nuestras limitaciones en ese aspecto a la vez que nos da la posibilidad de prevenir errores.

La definición del proyecto no sólo ha de responder a las tres preguntas fundamentales: QUÉ, CUÁNDO y CUÁNTO sino que ha de encontrar el equilibrio entre los parámetros que estas implican: ASPECTOS TÉCNICOS, TIEMPO DE EJECUCIÓN y COSTE respectivamente.

En cuanto al QUÉ (aspectos técnicos), la definición a de recoger las necesidades del cliente y determinar los requisitos del producto/servicio. El CUÁNDO (tiempo de ejecución) reflejará las principales fases del proyecto, la estimación de las horas y plazo de ejecución y el CUÁNTO (coste) recogerá el presupuesto final del proyecto que será la suma del coste, los riesgos y el margen de beneficio.

Es imprescindible, para eliminar posibles riesgos, realizar una revisión de la definición tanto de los aspectos técnicos como de los económicos (precio de venta, condiciones de aceptación y forma de pago). Además es conveniente realizar otras revisiones como: revisión de conformidad con el sistema de calidad, jurídica para cubrir posibles riesgos derivados del proyecto y revisión de tipo administrativo (justificaciones a la administración, previsión de inversiones, etc.)

En este sentido, la metodología contiene los estándares para la elaboración de las ofertas y determinación de los requisitos contemplando los aspectos anteriormente comentados, así como los mecanismos correspondientes para el control de acuerdo con sistema de calidad.

1.1.2. PLANIFICACIÓN DE UN PROYECTO

Tras la aceptación de la oferta y lanzamiento del proyecto se pasa a la fase de planificación que consiste en transformar el modelo teórico presentado en la oferta en un plan de acción aplicable que recoja: lo que hay que hacer, en el orden necesario y con los medios de que se dispone para alcanzar los objetivos tanto de costes como de plazos.

Acciones a realizar en la planificación de proyectos.

- Identificación de Actividades o Tareas.- Desglosar el trabajo a realizar tratando de no mezclar lo accesorio con lo importante y cuidando el nivel de detalle. Que todo el trabajo a realizar pueda imputarse a alguna tarea.

- Secuenciación de Actividades.- Determinación de actividades paralelas, interdependencias, retrasos.

- Estimación de la duración/esfuerzo de las Actividades.- Por parte del responsable de la realización de esa tarea y revisada por el Director del Proyecto

- Estimación de las necesidades de recursos.- Cada recurso de un proyecto debe de ir asignado a una o varias actividades e incluso de forma simultanea siempre que no sobrepase la dedicación del 100%.

- Estimación de los costes de las Actividades.

- Representación gráfica del flujo de Actividades.- Mediante un Diagrama Gantt.

- Optimización de la planificación.- Una vez finalizada la planificación y antes de poner en marcha el proyecto, es necesario revisar y optimizar el plan mediante la reducción, si es posible, de los siguientes aspectos:

§ Duración.- Modificando el camino, asignando más recursos, trabajo en horas extras, etc.

§ Sobreasignación.- Cambiando la asignación de tareas al recurso, modificando la secuencia de tareas, aumentando las horas de trabajo del recurso en su calendario laboral, reasignación automática, etc.

§ Costes.- Remplazando recursos caros por otros menos costosos, eliminando tareas de baja prioridad, revisando la duración y esfuerzo de las tareas, etc.

Todos los aspectos anteriormente señalados se recogen mediante distintos elementos, como la ficha de proyecto, el plan de desarrollo del proyecto, etc. que se integran para posibilitar no solo la planificación sino también la supervisión y control tanto técnico como económico del proyecto.

1.1.3. CONTROL Y SEGUIMIENTO DE UN PROYECTO

Las mayores desviaciones que se producen en un proyecto son debidas a deficiencias en el control del mismo. Para asegurar la eficacia de la ejecución es necesario que el director de proyecto realice un buen seguimiento:

- Seguimiento técnico.- Controlando el avance de las tareas, esto es, lo realmente conseguido, que será mucho más fiable si se calcula en función de estimaciones de las tareas individuales.

- Seguimiento económico.- De las horas invertidas, compras o pedidos realizados, subcontrataciones, viajes y otros gastos de forma que la suma de todo ello no supere el crédito asignado para completar el proyecto.

Estas son algunas acciones a llevar a cabo para realizar un adecuado Proceso de Control y Seguimiento de un Proyecto:

- Recoger datos.- La información es la principal herramienta de que dispone el director de proyectos para mantenerse alejado de los problemas. Existen varias formas de recogerla: informes (Informes de tarea), reuniones (Internas o Externas), de otros departamentos (Administración, Finanzas, etc.), etc.

- Análizar Datos referentes al esfuerzo, costes, plazos y avances intermedios.

§ ESFUERZO (horas empleadas por recurso y tarea)

§ COSTES y PLAZOS (duraciones, fechas de inicio y fin, márgenes)

§ AVANCES INTERMEDIOS

- Sacar conclusiones comparando los datos reales con los planificados.

- Informar.- Es tarea del director de proyecto elaborar los informes de seguimiento de forma periódica, puntual, concisa e impersonal y presentar propuestas de soluciones en el caso de producirse desviaciones. Estos informes deben de ser analizados por el supervisor que deberá sacar conclusiones y tomar medidas. Es conveniente que los informes tengan un formato fijo, que evite la tentación de seleccionar su contenido.

- Tomar medidas asegurándose de que la decisión se puede justificar con datos.- Teniendo en cuenta las aportaciones de la gente más afectada por la decisión, fijando prioridades y alternativas (criterios de ejecución, tiempos, costes) y comunicando las decisiones con tacto y consideración.

- Replanificación.- En caso de ser necesario realizar una replanificación del proyecto efectuando los cambios que sean necesarios e integrarlos de nuevo en todo el sistema de gestión de proyectos.

1.1.4. CIERRE DE UN PROYECTO

Una buena finalización del proyecto requiere realizar una serie de tareas para las que se recomienda reservar tiempo en la planificación. Estas tareas son las siguientes;

- La actualización de datos.- Tanto técnicos como de gestión para incorporar las últimas modificaciones al trabajo desarrollado.

- Revisar toda la documentación del proyecto.- Eliminar la documentación inútil y organizarla, de forma que sirva para:

§ Dar un buen soporte de garantía o mantenimiento.

§ Realizar modificaciones o ampliaciones del producto entregado.

§ Aprovechar aspectos técnicos para otros proyectos de la empresa.

§ Apoyar la planificación y estimación otros proyectos de la empresa.

- Realización de copia de seguridad de toda la información que se encuentre en el ordenador.- La realización de la memoria o informe de conclusiones

- El archivo del proyecto.- Así no queda ligado a una o varias personas que son las que tienen en su cabeza el trabajo realizado sino que toda la información estará disponible para el resto de la empresa.

La finalización del proyecto también implica la realización de las tareas correspondientes para modificar su estado dentro del sistema de activo a cerrado, así como su archivo tanto físico como en la gestión documental que soporta el sistema.

1.2. ADMINISTRACIÓN DE PROYECTOS

1.2.1. INTRODUCCIÓN A LA ADMINISTRACION DE PROYECTOS

1.2.1.1. SIGNIFICADO DE ADMINISTRACION DE PROYECTOS

La administración de proyectos consiste en gestionar la producción de un producto dentro del tiempo dado y los limites de fondos. Como esto requiere recursos humanos, la administración del proyecto involucra no solo la organización técnica y las habilidades organizacionales, sino también el arte de administrar personas. La administración de proyectos no es una actividad insignificante m pueden ser tan emocionante como aterrizar un jet jumbo en una pista corta.

1.2.1.2. LOS COMPONENTES DE LA ADMINISTRACIÓN DE PROYECTOS

La administración de proyectos comprende

Ø Estructura (elementos organizacionales involucrados)

Ø Proceso administrativo (responsabilidades y supervisión de los participantes)

Ø Proceso de desarrollo (métodos, herramientas, lenguajes, documentación y apoyo.

Ø Programa (tiempos en los que se deben realizarse las porciones del trabajo)

1.2.1.3. VARIABLES PRINCIPALES. COSTO, CAPACIDAD, CALIDAD Y PROGRAMA

Quienes planean los proyectos pueden varios costos, calidad y fecha de entrega como muestra la figura 1. El grado en el que estos cuatro factores pueden controlarse depende del proyecto. Aunque con frecuencias los costos pueden estar fijos de antemano, muchas veces hay cierta flexibilidad. Por ejemplo, suponga que el cliente es un químico que necesita una visualización molecular en 2D. Después de ver el prototipo de 3D se ve mucho mejor que el de 2D. Las capacidades tampoco son entidades fijas que parecen, Por ejemplo, el cliente puede estar de acuerdo con eliminar un requerimiento si hacerlo disminuye 15% la duración del proyecto (un trueque entre capacidades y programa). Aunque puede parecer poco ortodoxo, incluso las metas de calidad pueden variar. Cuando las metas de calidad se establecen demasiado bajas, se crea un desequilibrio en los costos a corto y largo plazo debido al retrabajo e insatisfacción del cliente. Cuando las metas de calidad son demasiado altas el costo de encontrar hasta el detalle más pequeño puede ser prohibitivo. La mayor parte de las personas no estarían dispuestas a pagar tres veces el precio por un procesador de palabra con el fin de tener una versión sin un defecto trivial reconocido. En ocasiones se pueden negociar las fechas de terminación. Por ejemplo, un gerente puede estar dispuesto a cambiar una fecha de entrega si el producto resultante tiene tantas capacidades que es probable que capte el mercado.

Una manera de visualizar estas cuatro variables es mediante el uso de un diagrama "polar". En este tipo de diagrama, cada una de las variables se grafica en un eje que se origina en el centro. Los ejes se dibujan simétricos entre si. En particular, el diagrama polar de la figura 1 contiene cuatro variables, de manera que los ejes están a ángulos rectos. En cada uno de estos ejes, el origen es el valor menos favorable, y el valor meta es el marcado en cada eje a la misma distancia del origen formando un cuadrilátero. (Si hubiera cinco variables, formarían un pentágono etc.) Por ejemplo, en el eje de capacidades, el origen denota "ningún requerimiento satisfechos". Los valores reales suelen estar en algún lugar en medio, aunque podría haber valores fuera del polígono si exceden las metas, como se ve en la figura 2. El estado de un proyecto se puede visualizar como un polígono solido, uniendo los valores en los ejes y sombreando el interior. Cuanto más se coincida con el polígono regular original mayor será el logro de las metras del proyecto. El ejemplo mostrado se queda corto en la mayoría de las variables pero se desempeña bien en las metas de costo. Esta visualización ayuda al administrador del proyecto al alterar las prioridades para alcanzar las metas de forma más pareja. Por ejemplo, el líder del proyecto de la figura debe permitir mayor gasto para obtener la densidad de defectos requerida.

Para resumir, el administrador del proyecto maneja de firma constante el trueque entre costo, capacidades, calidad y fecha de terminación. Los administradores de proyectos profesionales cuantifican estos trueques lo más que pueden.

1.2.1.4. MAPA CONCEPTUAL TÍPICO DE UN PROCESO DE ADMINISTRACIÓN DE PROYECTOS

1.2.2. ADMINISTRACIÓN DEL PERSONAL DEL PROYECTO

1.2.2.1. PROFESIONALISMO

Este es uno de los temas del creciente profesionalismo de la ingeniería del software; pero, ¿qué significa con exactitud? Los profesionalitas tienen responsabilidades de sus empleadores y supervisores. Con el impacto tan grande del software en el mundo moderno, los ingenieros de software tienen que contraer cada vez más responsabilidades.

Las prácticas de los ingenieros de software en la planeación, programación, diseño, inspección y pruebas de los artefactos pasan por un escrutinio cada vez mayor dentro y fuera de la profesión.

1.2.2.2. IMPORTANCIA DE ADMINISTRAR A LAS PERSONAS

El ingrediente principal requerido para producir software es la gente. Las aptitudes técnicas de los ingenieros cuentan, por supuesto, pero deben aprovecharse en el problema adecuado, en el tiempo correcto. Esto requiere una combinación de trabajo en equipo y liderazgo. La meta de esta sección es familiarizarlo con los aspectos comunes de personal. Esto aspectos analizarán desde varios puntos de vista: de la empresa que desea aplicación, de los administradores responsables de crearla de los ingenieros involucrados.

1.2.2.3. PERSPECTIVAS DE LA EMPRESA

Desde el punto de vista de la compañía que encomienda un proyecto, su desarrollo se ve como una contribución las metas de la empresa, producir un producto que justifique con creces su costo. Esta perspectiva es de negocios. El nombre mismo de la organización corporativa responsable del personal del proyecto ilustra esta perspectiva: “recursos humanos”, un tipo de recurso de la variedad de personas que apoya las metas de la organización.

1.2.2.4. PERSPECTIVAS DE LA ADMINISTRACIÓN

Se ha dicho que “no existen los errores técnicos, solo las fallas administrativas”. Aunque esto no es cierto en general, si nos recuerda la importancia de la administración para la terminación exitosa de las iniciativas de la ingeniería. El puesto de vista del administrador respecto a sus subordinados suele ser una mezcla de preocupación pro los negocios, por un lado, y un interés en las personas involucradas, por el otro. A pesar de las frecuentes inquietudes de los subordinados, el administrador promedio intenta que se haga el trabajo y al mismo tiempo trata de impulsar una fuerza de trabajo satisfecha. Esto va en el interés del administrador: los trabajadores descontentos no son productivos. Los administradores aseguran que los esfuerzos técnicos de los ingenieros vayan en la dirección adecuada. En especial los nuevos administradores encuentran difícil integral el hecho de dictar órdenes y permitir que los ingenieros hagan lo que crees más adecuado.

Los líderes de proyecto tienen diferentes grados de responsabilidad administrativa, dependiendo de la magnitud del proyecto.

1.2.2.5. PERSPECTIVAS DE LOS INGENIEROS

Por último considere los aspectos de “personas” que afectan al ingeniero de software típico. Los ingenieros desean trabajo interesante, quieren oportunidades para mostrar que son competentes, desean ser reconocidos y recompensados, y una relación cordial con sus compañeros de equipo. Un auto respeto sano es un prerrequisito para estos deseos. Una fuente importante de autoestima en el lugar de trabajo es la percepción de la calidad. No hay nada nuevo en esta observación.

1.2.3. IDENTIFICACIÓN Y RETIRO DEL RIESGO

1.2.3.1. DEFINICIÓN DE “RIESGOS”

Un riesgo es algo que puede ocurrir en el curso de un proyecto que, según el peor resultado, lo afectaría de manera negativa y significativa. Los factores que a la larga ocasionan que un proyecto fracase aparecen como riesgos cuando se reconocen con prontitud, y al reconocerlos tal vez pueda prevenirse el fracaso mediante la acción adecuada.

Existen dos tipos de riesgos.

Ø Riesgos que pueden evitarse o que se les puede sacar la vuelta (retirarlos)

Ø Riesgos que no pueden evitarse.

1.2.3.2. PANORAMA DE LA ADMINISTRACIÓN DEL RIESGO

Las aplicaciones muy similares a trabajos realizados con anterioridad por los mismos ingenieros de software pueden no tener riesgos; sin embargo, el universo de las aplicaciones de software es vasto y crece con rapidez. Muchos trabajos consisten en nuevas formas de realizar tareas, o son realizaciones de nuevas ideas. Por ello, es común que el desarrollo de aplicaciones de software incluya muchos riesgos.

Cada riesgo identificado debe ser bienvenido en el equipo del proyecto porque pueden comenzar a prevenirlo. Los problemas reales son los riesgos que no se han identificado. Estos son como minas en el campo que esperan explotar.

1.2.3.3. IDENTIFICACIÓN DE RIESGOS

La identificación de riesgos consiste en escribir todas las inquietudes o preocupaciones de quienes están relacionados con el proyecto, después presionar continuamente a los integrantes del equipo a pensar en más inquietudes. La identificación de riesgos requiere de una mentalidad escéptica similar a la requerida para la inspección, una búsqueda global de defectos en el plan de desarrollo. Las categorías de riesgos incluyen subestimación de tamaño del trabajo, cambios demasiados rápidos en los requerimientos, falta de habilidad para encontrar una implantación con suficiente eficiencia, deficiencias en las aptitudes del personal., un lapso grande para aprender a usar las herramientas y definiciones de los lenguajes.

1.2.3.4. RETIRO DE RIESGO

Retirar el riesgo es el proceso mediante el cual los riesgos se reducen o incluso se anulan. Existen dos maneras de retirar un riesgo. Una es hacer cambios en los requerimientos del proyecto para retirar (“evitar”) el aspecto que causa el riesgo. Otra manera es desarrollar técnicas y diseños que resuelvan el problema (“conquistar”, como manera de hablar). Cuando el equipo identifica un obstáculo para construir el paso, puede evitarlo si modifica la dirección o inicia de inmediato el trabajo de desarrollo para superarlo.

1.2.4. ELECCIÓN DE HERRAMIENTAS DE DESARROLLO Y SOPORTE

1.2.4.1. MÉTODOS DEL PROCESO

Debe tomarse una decisión en cuanto a que metodología de desarrollo o combinación de metodologías se usara. Las opciones de metodologías de casada, espiral, USDP y por incrementos.

1.2.4.2. HERRAMIENTAS

La ingeniería del software es un mercado sustancial. Un gran número de proveedores venden herramientas y entornos para ayudar a los ingenieros a desarrollar aplicaciones de software. Estas con frecuencias reciben el nombre de herramientas de ingeniería de software asistida por computadora.

1.2.4.3. DECISIONES DE CONSTRUIR O COMPRAR

Existe un número creciente de herramientas y aplicaciones en el mercado que prometen ayudar en, o formar la base para, nuevas aplicaciones. En general, estas decisiones se pueden retrasar gasta que se conocen los requerimientos, pero aquí se presentarán ya que son parte de la administración del proyecto-.

1.2.4.4. SELECCIÓN DEL LENGUAJE

Debe identificarse el lenguaje o lenguajes para el desarrollo casi al principio del proyecto. En ocasiones esta decisión es directa, como cuando una organización impone el lenguaje, o cuando el lenguaje es el único capaz de desarrollar requerimientos. Sin embargo, algunas veces deben elegirse varias alternativas para el desarrollo.

1.2.4.5. DOCUMENTACIÓN

Durante la etapa de la planeación, el equipo decide qué conjunto de documentación específico se producirá para el proyecto.

1.2.4.6. SERVICIOS DE APOYO

Los proyectos requieren apoyo para los administradores del sistema, de la red, de las bases de datos, los secretarios y otros. El administrador del proyecto debe asegurar que estas personas están disponibles.

1.3. ADMINISTRACIÓN DE PROYECTOS

La administración de proyectos asegura la entrega de un sistema de un sistema de calidad a tiempo y dentro del presupuesto. Los componentes principales de esta definición son calidad, tiempo y dinero. Para asegurar la entrega dentro del presupuesto se requiere que un gerente estime y asigne los recursos requeridos por el sistema desde el punto de vista de participantes, entrenamiento y herramientas. Para asegurar la entrega a tiempo se requiere que un gerente planee los esfuerzos de trabajo y supervise el estado del proyecto desde el punto de vista de tareas y productos de trabajo. Por último, para asegurar el control de calidad se requiere que un gerente de proyecto proporcione mecanismos para el reporte de problemas y supervise el estado del producto en cuanto a defectos y riesgos. Los tres aspectos del proyecto, calidad, presupuesto y tiempo, son esenciales y necesitan abordarse juntos para que el proyecto tenga éxito.

1.3.1. UN PANORAMA DE LA ADMINISTRACIÓN DE PROYECTOS.

La administración de proyectos tiene que ver con la planeación y asignación de recursos para asegurar la entrega de un sistema de software a tiempo y dentro del presupuesto. La administración de proyectos está sujeta a las mismas barreras que las actividades técnicas: complejidad y cambio.

Los modelos de administración nos permiten representar los recursos disponibles para el proyecto, las restricciones a las que están sujetos los recursos y las relaciones entre recursos. En este capítulo describimos los siguientes elementos:

Ø Los equipos representan conjuntos de participantes que trabajan en un problema común.

Ø Los papeles representan conjuntos de responsabilidades. Los papeles se usan para distribuir el trabajo a los participantes del equipo.

Ø Los productos de trabajo representan los productos a entregar e intermedios del proyecto. Los productos de trabajo son los resultados visibles del trabajo.

Ø Los calendarios representan la correspondencia entre un modelo de tareas y una línea de tiempo. Un calendario representa el trabajo desde el punto de vista de tiempo de calendario.

El gerente del proyecto y los lideres de equipo construyen y mantienen estos elementos del modelado a todo lo largo del desarrollo.

A nivel de abstracción más alto, el ciclo de vida del desarrollo puede descomponerse en tres fases principales: inicio del proyecto, durante el cual definen el alcance y recursos el proyecto, estado estable, durante el cual sucede la mayor parte del trabajo de desarrollo, y terminación del proyecto, durante la cual se entrega y acepta el sistema.

1.3.1.1. INICIO DEL PROYECTO

Durante esta fase el gerente del proyecto define el alcance del sistema junto con el cliente y construye la versión inicial del os modelos de administración. Al principio, solo están involucrados el gerente del proyecto, algunos líderes de equipo seleccionados y el cliente. El gerente del proyecto especifica el ambiente del proyecto, organiza los equipos, contrata participantes y arranca el proyecto. El inicio del proyecto incluye las siguientes actividades:

1.3.1.1.1. DEFINICIÓN DEL ENUNCIADO DEL PROBLEMA

Durante esta actividad el cliente y el gerente del proyecto definen el alcance del sistema desde el punto de vista de la funcionalidad, restricciones y productos a entregar. El cliente y el gerente del proyecto se ponen de acuerdo sobre los criterios de aceptación y fechas de destino.

1.3.1.1.2. DISEÑO INICIAL DE ALTO NIVEL

El gerente del proyecto y el arquitecto del sistema descomponen el sistema en subsistemas para efectos de la asignación de equipos. El gerente del proyecto define los equipos y productos de trabajo en función de los subsistemas. El arquitecto del sistema y los desarrolladores revisarán la descomposición en subsistemas durante el diseño del sistema.

1.3.1.1.3. FORMACIÓN DE EQUIPOS

El gerente del proyecto asigna un equipo a cada subsistema, define los equipos de funcionalidad cruzada y selecciona a los líderes de equipo. El gerente del proyecto y los líderes de equipo asignan juntos los papeles y responsabilidades a los participantes en función de las habilidades de éstos. Durante esta fase los líderes de equipo establecen las necesidades de entrenamiento para el equipo.

1.3.1.1.4. ESTABLECIMIENTO DE LA INFRAESTRUCTURA DE COMUNICACIÓN

El gerente del proyecto y los líderes de equipo establecen la infraestructura de comunicación del proyecto, incluyendo tableros de noticias, sitios web, herramientas para la administración de configuración, plantillas de documentos y procedimientos de reunión. Los participantes en el proyecto usarán esta infraestructura para la distribución de información y el reporte de problemas en forma ordenada.

1.3.1.1.5. PLANEACIÓN INICIAL DE INDICADORES DE AVANCE

El gerente del proyecto calendariza los productos de trabajo intermedios y los productos a entregar en forma extrema y los asigna a los equipos.

1.3.1.1.6. ARRANQUE DEL PROYECTO

El gerente del proyecto, los líderes de equipo y el cliente arrancan el proyecto en forma oficial. El propósito de las reuniones de arranque es explicar a los participantes el alcance del proyecto, la infraestructura de comunicación y las responsabilidades de cada equipo. Después del arranque el proyecto está en el estado estable.

1.3.1.1.7. TERMINACIÓN DEL PROYECTO

Durante esta fase se entrega el producto y se recopila la historia del proyecto. La mayor parte de la participación de los desarrolladores en el proyecto termina antes de esta fase. Unos cuantos desarrolladores principales, los escritores técnicos y los líderes de equipo se involucran del sistema para su instalación y aceptación, y recopilan la historia del proyecto para usarla en el futuro.

1.4. ADMINISTRACIÓN DE PROYECTOS

Es una combinación de muchas disciplinas que incorpora los procesos de comunicación, los ciencias de computación y administración, así como también las técnicas para la solución de problemas. Su objetivo principal es el mejoramiento de la productividad de todos los individuos involucrados en el desarrollo de software y la calidad de los sistemas de software.

1.4.1. COMPONENTES DE LA ADMINISTRACIÓN DE PROYECTOS

1.4.1.1. HABILIDADES CLAVE

Ø Liderazgo

Ø Comunicación

Ø Negociación

Ø Solución de problemas

Ø Lograr objetivos

1.4.1.2. CONOCIMIENTOS

Ø Técnicos

Ø Administrativos

Ø Herramientas

Ø Técnicas

1.4.2. ELEMENTOS RELACIONADOS CON EL PROYECTO

Ø Tiempo

Ø Calidad

Ø Alcance

Ø Entorno

Ø Recursos

Ø Costo

1.4.3. CICLO DE VIDA DEL PROYECTO

1.5. ADMINISTRACIÓN DE PROYECTO

La administración del proyecto no produce ningún artefacto por sí misma. En vez de ello, incluye las actividades de vigilancia que aseguran la entrega de un sistema de alta calidad a tiempo y dentro del presupuesto. Esto incluye la planeación y presupuestación del proyecto durante las negociaciones con el cliente, la contratación de desarrolladores y su organización en equipos, la vigilancia del estado del proyecto y las intervenciones cuando suceden desviaciones. La mayoría de las actividades de administración del proyecto que son visibles ante los desarrolladores y las técnicas que hacen más efectiva la comunicación entre el desarrollo y la administración.

1.6. CONCEPTO PERSONAL

La aplicación racional de conocimientos, habilidades, herramientas y técnicas para alcanzar los objetivos de un proyecto, a través de una serie de actividades interrelacionadas.

Son las actividades que permiten asegurar que el software se lleva a cabo a tiempo y de acuerdo con la planificación. Así como de acuerdo con los requerimientos de software.

Utilización eficiente de los recursos humanos y computacionales para el desarrollo de un proyecto.

2010-04-16T09:34:00.000-07:00

1.1. Estudios de factibilidad

Ø Para todos los sistemas nuevos, el proceso de ingeniería de requerimientos empieza con un estudio de factibilidad. La entrada de peste es una descripción resumida del sistema y de cómo se utilizará dentro de una organización. El resultado del estudio es un informe que recomienda su es conveniente llevar a cabo la ingeniería de requerimientos y el proceso de desarrollo del sistema.

Un estudio de factibilidad es un estudio de corto y orientado a resolver varias preguntas:

1. ¿El sistema contribuyente a los objetivos generales de la organización?

2. ¿El sistema se puede implementar utilizando la tecnología actual y con las restricciones de costo y tiempo?

3. ¿El sistema puede integrarse a otros que existen en la organización?

Aquí la cuestión es crítica es si el sistema contribuye a los objetivos del negocio. Si no contribuye a estos objetivos, entonces no tiene un valor real en el negocio. Aunque esto pueda parecer obvio, muchas organizaciones desarrollan sistemas que no contribuyen a sus objetivos ya sea porque no tiene una clara manifestación de estos objetivos o porque otros factores políticos u organizacionales influyen en la creación del sistema.

Llevar a cabo un estudio de factibilidad comprende la evaluación y recolección de la información, y la redacción de informes. La fase de evaluación de la información identifica la información requerida para contestar las tres preguntas anteriores. Una vez que dicha información se ha identificado, se cuestionan las tres preguntas anteriores, una vez que dicha información se ha identificado, se cuestionan las fuentes de información para descubrir las respuestas a estas preguntas. Algunos ejemplos de preguntas posibles son:

1. ¿Cómo se las arreglaría la organización si no se lleva a cabo este sistema?

2. ¿Cuáles son los problemas con los procesos actuales y cómo ayudaría el nuevo sistema a resolverlo?

3. ¿Cuál es la contribución directa que hará el sistema a los objetivos del negocio?

4. ¿La información se puede obtener y transferir a otros sistemas de la organización?

5. ¿El sistema requiere de tecnología que no se ha utilizado previamente en la organización?

6. ¿A que debe ayudar el sistema y a qué no necesita ayudar?

Las fuentes de información pueden incluir a los administradores de los departamentos donde el sistema se utilizará, los ingenieros de software que están relacionados con el tipo de sistema propuesto, los expertos en tecnología, los usuarios finales del sistema, etc. A ellos se les debe entrevistar durante el estudio de factibilidad para recolectar la información requerida.

Cuando la información esté disponible, se prepara el informe del estudio de factibilidad. Este hace una recomendación de cuando debe continuar el desarrollo del sistema. Proponer cambios en el alcance, el presupuesto y la calendarización del sistema y sugiere requerimientos adicionales de alto nivel para éste.

Ø Se estima si las necesidades del usuario se pueden satisfacer con las tecnologías actuales del software y hardware. El estudio determina el costo del sistema desde un punto de vista de negocios y si se puede desarrollar dadas las restricciones de presupuesto. Este estudio debe ser relativamente bueno y rápido de elaborar. El resultado debe informar si se va a continuar con un análisis detallado.

Ø Algunas veces existe incertidumbre respecto a si los requerimientos propuestos se pueden llevar a la práctica. En otras palabras, existe un riesgo para todo el proyecto en lugar de riesgos centrados en los requerimientos específicos. Además, el proyecto no sería factible no valdría la pena construirlo si el riesgo fuera una realidad. En eso casos, se puede realizar ESTUDIOS DE FACTIBILIDAD. Estos estudios son implantaciones parciales o simulaciones de la aplicación. Por ejemplo, considere la factibilidad de un ENCUENTRO BAJADO DE INTERNET, escrito en Java; suponga que se sospecha que el desempeño será tan lento que nadie tendrá interés en él. Un estudio de factibilidad puede consistir en establecer una simulación del envidio de mensajes o la tasa prevista concierto número de jugadores, pero con un contenido ficticio. Sería posible estimar los retrasos midiendo la simulación.

Las simulaciones son costosas ya que son aplicaciones por sí mismas, que requieren los artefactos de ingeniería del software. La simulación creció y se convirtió en un programa grande que se necesito durante varios años, mientras que el sistema real se desarrollaba. Nadie tomo en serio los requerimientos de la simulación porque no era “EL PROGRAMA REAL”. Como resultado, el costo de mantener y usar simulación llego a ser astronómico. Por ejemplo, hacer cambios requería primero rastrear a un empleado que “CONOSCA EL SISTEMA”. Las simulaciones de factibilidad son comunes en programas grandes de defensa que implican gran cantidad de software y hardware.

Cuando simplemente no se puede decir si valdría la pena un concepto de aplicación visualizada, a veces es posible construir una PRUEBA DE CONCEPTO. Esta es una implementación. Antes de que la Naval de EEUU construyera la generación. Aegis de sistemas de barcos elaboro un sistema típico a escala completo con software y hardware. Esta prueba de concepto sirvió para convencer a la Naval de que se tenía una buena oportunidad de que el concepto imaginado para Aegis se construyera en un tiempo aceptable a un costo razonable.

1.2. Perfil De Inversi6n

La importancia de una adecuada planeación de las inversiones (para proyectos privados y proyectos de desarrollo) nos obliga contar; antes de llevarla a cabo, con la información preliminar del medio en el que se pretende invertir. En la actualidad no es posible invertir en algo que no se conoce porque se corre el riesgo de fracasar en la empresa. Tampoco es posible realizar formal mente estudios de pre factibilidad o de factibilidad para todos los temas de inversión, aparentemente disponibles o posiblemente rentables. Una alternativa para contar con la información preliminar necesaria, esté constituida por un perfil de inversi6n, que sin proporcionar la información detallada de un formal estudio de factibilidad, técnica económica y financiera de un Proyecto de Inversión, constituye un esquema formal, claro y actualizado de las bases, características y resultados por esperar una inversión.

1.3. Estudios De Prefactibilidad

Una forma breve de un estudio de factibilidad muchas veces es llamada "estudio de pre factibilidad." En principio contiene todas las partes principales de un estudio amplio pero en breve y a grosso modo. Este tipo de estudios determina la factibilidad en forma aproximada para luego decidir acerca de la elaboración de un estudio que involucre todos los detalles.

1.4. Estudios Parciales

Bajo ciertas circunstancias 5610 algunos aspectos de un proyecto de inversión se investigan detalladamente. Esta situación puede presentarse, cuando por ejemplo, el suministro de agua y energía eléctrica, pueden tener una importancia tal para ciertas inversiones, que sus investigaciones se hacen antes de examinar otros aspectos. Sin embargo, estos estudios parciales solo pueden sustituir a un estudio amplio, cuando sin lugar a duda, se compruebe que d proyecto no es factible y que por lo tanto, pueda ahorrase el costo de la elaboración de cualquier otra parte del estudio.

1.5. Estudios De Factibilidad

Esta forma puede denominarse como un estudio "amplio" para distinguirlo de un anti proyecto de inversiones, o estudio de pre factibilidad. EI término normalmente usado es "Estudio de Factibilidad" y emplearemos este término, durante todo el curso. Este estudio es la base completa de la evaluación significativa del proyecto.

ETAPAS

ü Se aprueba identificar la idea (perfil, viabilidad inicial)

ü Se efectúa un análisis mas avanzado hasta encontrar al menos un camino viable (pre factibilidad).

ü Se aporta más dinero y tiempo para mejorar los elementos de juicio (factibilidad).

ü Se rechazan 0 aceptan las pruebas (proyecto definitivo).

1.6. Aplicación De Estudios De Factibilidad

Los estudios de Factibilidad (en forma completa o parcial) pueden usarse para un sin número de casos específicos de los cuales a continuación se mencionan algunos típicos:

Ø Proyectos industriales ya existentes.

Ø Ampliaciones de empresas ya existentes.

Ø Modificaciones de empresas ya existentes.

Ø Proyectos de servicios (hoteles. bancos. hospitales. Escuelas, comercios.)

Ø Proyectos de infraestructura.

De la lista anterior. Se desprende que aquí trataremos de conocer y manejar un instrumento versátil y ampliamente útil para cualquier proyecto que implica que se tomen decisiones que afectan el área económica del interesado.

Es obvio que la calidad del estudio de factibilidad depende de la calidad de los datos utilizados de la capacidad técnica y analítica de las personas que lo elaboren.

De todos modos debemos estar conscientes de que por medio del estudio de factibilidad pueden disminuirse los riesgos empresariales, pero de ninguna manera pueden eliminarse por completo.

1.7. Factibilidad

Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas señalados. Generalmente la factibilidad se determina sobre un proyecto.

El estudio de factibilidad, es una de las primeras etapas del desarrollo de un sistema informático.

El estudio incluye los objetivos, alcances y restricciones sobre el sistema, además de un modelo lógico de alto nivel del sistema actual (si existe). A partir de esto, se crean soluciones alternativas para el nuevo sistema, analizando para cada una de éstas, diferentes tipos de factibilidades.

1.7.1. Tipos

* Factibilidad técnica: si existe o está al alcance la tecnología necesaria para el sistema.

* Factibilidad económica: relación beneficio costo.

* Factibilidad operacional u organizacional: si el sistema puede funcionar en la organización.

Para cada solución factible, se presenta una planificación preliminar de su implementación.

Estos resultados se entregan a la gerencia, quienes son los que aprueban la realización del sistema informático.

El estudio de factibilidad, es una tarea que suele estar organizada y realizada por los analistas de sistemas. El estudio consume aproximadamente entre un 5% y un 10% del costo estimado total del proyecto, y el período de elaboración del mismo varía dependiendo del tamaño y tipo de sistema a desarrollar.

1.8. Factibilidad del proyecto empresarial

Para las personas que se asocian como empresa cooperativa para emprender un negocio nuevo, resulta conveniente que el comité organizador realice con profesionales que conozcan de la materia, un análisis de la factibilidad del proyecto empresarial. En esta etapa inicial se debe hacer un estudio de la viabilidad legal, técnica, financiera, económica, de gestión, institucional y medioambiental. Lo anterior permitirá tener una proyección acerca de las tareas e inversiones que se deberán considerar para la puesta en marcha del o de los negocios presupuestados.

“La realización de estos estudios no constituye un requisito legal para proceder a la constitución de una empresa cooperativa. Responden más bien a una sugerencia de buena administración, basados en las experiencias exitosas en el sector.”

A continuación se describen en forma muy básica, en que consisten estos estudios:

ü Viabilidad legal

ü Viabilidad técnica

ü Viabilidad financiera

ü Viabilidad de gestión

ü Viabilidad económica

ü Viabilidad institucional

ü Viabilidad medioambiental

1.8.1. Viabilidad Legal

El estudio de viabilidad legal debe informar si la legalidad vigente permite, o más bien no impide la realización del proyecto empresarial. Este estudio de viabilidad, al igual que los otros, en lo posible debe ser efectuado por expertos y el encargado de evaluar la factibilidad global del proyecto ha de seguir la orientación de los especialistas.

En algunos casos y para tener una idea preliminar sobre la viabilidad legal del proyecto, puede consultarse a organismos relacionados con las actividades que serán desarrolladas en el mismo (p.e. SAG, SERNAPESCA, DIRECTEMAR, DEPARTAMENTO DE COOPERATIVAS, CONAMA, etc.).

1.8.2. Viabilidad Técnica

Este estudio es de vital importancia, en él se determina si la tecnología (dura y blanda) disponible, permite hacer realidad el proyecto y también si es conveniente hacerlo.

Un estudio de viabilidad técnica debe proveer información sobre las diversas formas de materializar el proyecto o los diferentes procesos que pueden utilizarse para producir un bien o servicio. El estudio deberá contener una estimación de los requerimientos de capital, mano de obra y recursos materiales, tanto para la puesta en marcha, como para el estado de operación del proyecto.

La información técnica obtenida se utiliza para determinar cual es la forma más eficiente de materializar el proyecto. Esta determinación de eficiencia, se hace basándose en criterios técnicos y económicos, esto ha de ser así, puesto que puede ocurrir que una solución óptima desde el punto de vista técnico, no lo sea desde un punto de vista económico.

1.8.3. Viabilidad Financiera

El estudio de la viabilidad financiera no es otra cosa que ver si existe suficiente dinero para financiar los gastos e inversiones que implica la puesta en marcha y operación del proyecto.

Por lo general, se dice que los buenos proyectos, es decir, aquellos con rentabilidad alta, con un riesgo razonable y bien evaluado, encuentran financiamiento con cierta facilidad. También se afirma que los proyectos deben ser evaluados con independencia de las fuentes de financiamiento. Lo que se observa en la realidad es, que no es fácil conseguir recursos financieros si no se cuenta con garantías reales (prendas sobre vehículos, hipotecas sobre terrenos o cascos, etc.) y que el acceso a créditos para los microempresarios tiene más de una dificultad.

El estudio de viabilidad financiera debe mostrar que con las diferentes fuentes de financiamiento a las que puede acceder el proyecto, es posible financiar todas las etapas del mismo. Estas fuentes pueden ser propias (capital aportado por los mismos socios), bancos, financieras, cooperativas de ahorro y crédito, fuentes externas, etc.

1.8.4. Viabilidad De Gestión

La gestión o administración de un proyecto es de vital importancia, especialmente cuando es necesario crear una empresa para ponerlo en operación. Una gestión eficiente hace más probable que los beneficios netos obtenidos sean iguales o mayores a los estimados en el proyecto. Muchos buenos proyectos fracasan por mala gestión.

En algunos casos el estudio de viabilidad de gestión pierde importancia, por ejemplo, cuando se trata de producir un bien o servicio en una empresa en marcha o cuando el proceso de producción requiere de un diseño organizacional muy simple.

Este estudio debe contener a lo menos lo siguiente:

· Estructura organizativa que más se adecue a las necesidades de puesta en marcha y operación del proyecto.

· Con base en la estructura organizacional, se debe definir las necesidades de personal y estimar los costos de mano de obra y honorarios profesionales.

· Requerimiento de sistemas para una gestión eficiente. (Sistema contable, inventarios, cobranzas, abastecimiento o proveedores, clientes o socios, etc.)

· Una estimación de la infraestructura requerida y del equipamiento correspondiente.

1.8.5. Viabilidad Económica

El estudio de la viabilidad económica no es otra cosa que la evaluación del proyecto. En esta parte se calcula la rentabilidad del proyecto. Para ello, se utilizan diversos indicadores, los más usados son el Valor Actual Neto (VAN) y la Tasa Interna de Retorno (TIR), también se puede usar la razón Beneficio Costo (B/C), indicadores de Costo Efectividad o de Período de Recuperación de la Inversión.

En este estudio se debe evaluar económicamente todas las opciones encontradas en los estudios anteriores. Es necesario analizar todas las alternativas que resulten de combinar las diversas opciones técnicas, financieras, de gestión y de mercado encontradas en los respectivos estudios de viabilidad. A veces una opción técnica que fue desechada en el correspondiente estudio de viabilidad, puede resultar conveniente al hacer un análisis integrando opciones de gestión, de mercado, legales y financieras.

En esta parte se ordenan los ítems de inversiones, de ingresos de operación (información que proporciona el estudio de mercado), los costos de operación, impuestos, depreciación, etc. Con estos ítems ordenados se construyen los flujos netos de ingresos futuros, que son el insumo básico utilizado en la evaluación económica del proyecto.

1.8.6. Viabilidad Institucional

Esto dice relación con la resistencia de otras organizaciones a la formación de una empresa de tipo cooperativa.

1.8.7. Viabilidad Medioambiental

Si el proyecto en su proceso productivo es contaminante (ruidos molestos, emanaciones tóxicas, mal tratamiento de desechos, malos olores, etc.), puede ser inviable y tener impedimentos legales para operar.

1.9. Importancia del análisis de factibilidad (HOTELERÍA)

En esta etapa la habilidad del equipo de trabajo para controlar la marcha y desarrollo del proyecto, así como el compromiso para financiarlo resultan significativos. Para lograr esto es conveniente realizar un estudio de mercado o de factibilidad que permita conocer anticipadamente las condiciones del mercado y los resultados financieros en caso de no realizarse dicho estudio, el proyecto puede resultar un fracaso, ya sea porque la zona donde se construirá el hotel presenta una escasa demanda o porque el área de mercado está saturada. En general, estas situaciones resultan adversas a las expectativas estimadas y terminan con un pobre desempeño en su operación, que compromete, en ambos casos, la credibilidad financiera de los inversionistas y desarrolladores.

Debido a lo anterior, es necesario que los inversionistas y desarrolladores realicen un estudio de mercado o de factibilidad antes de iniciar un proyecto, el cual puede ser competo o preliminar. Elaborar un estudio preliminar interno permite un ahorro inicial de cotos; sin embargo, este estudio puede carecer del nivel requerido por las instituciones financieras para el otorgamiento de un crédito o por las compañías operadoras para aceptar la afiliación a sus cadenas.

Contratar a una firma especializada en hotelería para realizar el estudio de factibilidad, permite el equipo de trabajo contar con una información y base de datos completa que repercuta en una ahorro de tiempo y esfuerzo.

El estudio de factibilidad es parte clave en la solicitud de un financiamiento, cualquier institución financiera o bancaria que forme parte del sector público o privado, requiere antes de conceder un crédito o conseguir recursos por aportaciones de capital, de un estudio de factibilidad completo, que comprenda el estudio de mercado con proyecciones financieras.

1.9.1. Equipo de trabajo

Un estudio de factibilidad puede ser realizado indistintamente por el inversionista, desarrollador u operador; sin embargo, en la práctica, en la mayoría de los casos, cualquiera de ellos puede contratar los servicios de firmas especializadas en hotelería para que lo efectúen. Para los fines de este libro nos referiremos a estas firmas consultoras como el consultor o analista.

Cuando uno firma consultora es contratada por el cliente, su primer paso será de designar a una persona responsable denominada director del proyecto, el cual contara con amplios conocimientos y experiencia en la industria hotelera. Su función principal consistirá en coordinar las diversas actividades de su propio equipo de trabajo, el cual deberá ser lo más reducido posibles tanto para fines de ahorro presupuestal como para poder controlar y facilitar la interpretación de los hallazgos encontrados durante la realización del trabajo.

El director del proyecto, a su vez, distribuirá y delegara el estudio en un grupo de consultores que serán responsables de efectuar las investigaciones de campo y elaborar el informe final para el cliente, teniendo el director del proyecto como obligación interpretar los juicios a respuestas intangibles y subjetivas derivadas del trabajo de campo, que por no haberse encontrado físicamente estará en desventaja al momento de revisar la redacción del informe final.

Antes de entrar en la materia de lo que comprende un estudio de factibilidad económico para un hotel, revisaremos brevemente el producto y mercado de un hotel.

1.9.2. Producto y mercado

Los hoteles cuentan con un inventario fijo de habitaciones, su éxito se mide en porcentajes de ocupación, y su meta para que se considere rentable varía para los hoteles de ciudad entre 60 y 80%, y para los hoteles de recreo en un porcentaje menor. Los hoteles de ciudad tienen un porcentaje de ocupación mayor de lunes a jueves, y disminuye en los fines de semana, mientras que los hoteles de recreo su mayor ocupación lo obtienen los fines de semana y periodos vacacionales.

El éxito de un hotel depende de su composición de producto, mercado y localización. Sus instalaciones para descansar, comer, trabajar y jugar, deberían estar cuidadosamente diseñadas para que concuerden con las expectativas preferencias y necesidades de los segmentos predominantes de mercado que pretende captar, así como en la adecuada selección del sitio que asegure su total potencial de realización.

La industria hotelera vende servicios para satisfacer las necesidades de los huéspedes en cuanto a alojamiento, alimentación y empleo. Sus servicios consisten básicamente en la venta por habitaciones, alimentos y bebidas y renta de salones para juntas, banquetes y convenciones; su segmento de mercado es el de viajeros con fines de negocios o de placer, que buscan un producto con una localización e instalaciones acordes con sus necesidades.

El mercado básico para la venta por habitaciones puede dividirse en transitorio o terminal. Los huéspedes transitorios son aquellos viajeros cuya estancia es de parada breve y cuyo destino es una plaza especifica, con propósitos de negocios, vacaciones de placer o celebración de juntas y convenciones. La composición de estos huéspedes obliga a los hoteleros a diseñar sus instalaciones para cumplir con las expectativas y preferencias de la categoría predominante.

El mercado por alientos y bebidas, salones para juntas y banquetes, puede dividirse en huéspedes alojados en el hotel y en residentes de la localidad, que sin ser huéspedes utilizan estos servicios. Algunos huéspedes tomaran sus alimentos en el hotel, mientras que otros lo harán fuera. El servicio más solicitado por los huéspedes es el desayuno, mientras que para los residentes locales será el de comidas y cenas. La frecuencia en el uso de restaurantes y salines para banquetes por huéspedes y clientes locales, hacen que las instalaciones varíen en cada sitio y lugar, siendo los factores que influyen, bastante visibles y cuantificables, como por ejemplo la proximidad a edificios de oficinas, que pueden atraer una cantidad importante de comensales. La renta para salones de juntas vincula tanto el segmento por grupos y convenciones de huéspedes como el de los locatarios que utilizan los salones para conferencias y seminarios de trabajo, demanda que cada día crece, aun cuando algunas compañías están en posibilidades de usar sus propias instalaciones para la realización de estas actividades.

El área en el que se localiza un hotel tiene un efecto sustancial en la composición del producto y mercado, ya que ambos repercuten no solo en los segmentos que captura el hotel, sino en el de toda la comunidad. Los hoteles de ciudad, recreo, carretero, transitorios y de destino final, presentan características distintas que influyen significativamente en el mercado y en las instalaciones requeridas para capturar la clientela que se pretende atender.

El estudio de factibilidad está compuesto por una seria de investigaciones, sondeos, entrevistas, interpretaciones y análisis, que sirven como punto de referencia para hacer recomendaciones a un proyecto. Los métodos utilizados siguen un claro patrón., aunque sus aplicaciones varían de acuerdo con situaciones, metas y disponibilidad. En algunos casos la información se obtiene por medio de publicaciones, en otros mediante sondeos, entrevistas e investigaciones, cuyo proceso considera juicios subjetivos y objetivos que varían de una situación a otra. Sus procedimientos están diseñados para maximizar tanto la información objetiva cuantitativa como los juicios no cuantitativos, su panorama es amplio y va de lo macro a lo micro, lo que permite rendir detalles precisos y valorar las bases de juicio de los hallazgos encontrados.

La metodología de un estudio de factibilidad consiste en una secuencia ordenada de lineamientos básicos en su desarrollo, cuyos procedimientos de aplicación serian flexibles, según las circunstancias, permitiendo al analista conducir un informe final objetivo que cumpla con las necesidades y expectativas de los clientes.

Para que un estudio de factibilidad se considere completo, deberá contener los siguientes cuatro elementos clave de análisis.

1. Análisis de localización y del sitio.

2. Análisis de mercado, que incluya estudio de competencia, oferta y demanda y de segmentación del área de mercado, que permitan determinar su crecimiento potencial futuro.

3. Análisis de evaluación en razón del sitio y mercado del hotel propuesto.

4. Análisis financiero.

En caso de que un cliente no requiera los cuatro factores anteriores, el consultor o encargado del análisis deberá especificar claramente el alcance del estudio, mencionar si se trata de un estudio de sitio, mercado o de factibilidad, y si se incluyen o no las proyecciones financieras.

1.9.3. Objetivos de un estudio de factibilidad

Los objetivos básicos de un estudio de factibilidad son los siguientes:

a. Evaluación del potencial para el hotel propuesto, basado en un análisis de mercado que soporte el sitio seleccionado.

b. Recomendación del número, tipo y tamaño de habitaciones para huéspedes y el de otras instalaciones que sirvan para atender mejor sus necesidades.

c. Preparación de proyecciones del flujo de efectivo, antes de cargos fijos, pagos por incentivos a la operadora y deuda e impuestos por sus primeros 10 años de operación.

d. Elaboración del informe final con las conclusiones del estudio de factibilidad y de las proyecciones financieras para el hotel propuesto.

Como se ha mencionado los estudios de factibilidad presentan diversos factores que influyen de manera importante en el éxito o fracaso de un hotel, por lo que los consultores deberán analizar con detalle cada uno de ellos, siguiendo todos los procedimientos de aplicación necesarios para asegurarse de que la información recabada es confiable, fidedigna, y cuyo objetivo final derive en una opinión que permita tomar la decisión de llevar a cabo suspender, en forma definitiva o temporal, un proyecto hotelero.

2010-01-18T09:50:00.001-08:00

Base de Datos

Las Bases de Datos son programas que administran información y hacen más ordenada la información, aparte de hacerla fácil de buscar.

Sus características pueden ser ventajosas o desventajosas: pueden ayudarnos para almacenar, organizar, recuperar, comunicar y manejar información en formas que serían imposibles sin los computadores, pero también nos afecta de alguna manera ya que existen enormes cantidades de información en bases de datos de las que no se tiene control del acceso

Las bases de Datos tienen muchos usos: nos facilitan el almacenamiento de grandes cantidades de información; permiten la recuperación rápida y flexible de información, con ellas se puede organizar y reorganizar la información, así como imprimirla o distribuirla en formas diversas.

Algunos paquetes comerciales manejadores de Bases de Datos son: El file Marker Pro, ProQuest Periodical Abstracts, Organizer de Lotus y Far Side Calendar de Amaze.

Dato: Información que una computadora registra y almacena.

Campo: es cada trozo discreto de información en un registro.

Registro: es la información relacionada con una persona, un producto o suceso. En una BdeD un simple archivo es un conjunto de registros.

Archivo: es una colección de información relacionada. En él la información se guarda como si fuera un archivero.

Consulta: puede ser una búsqueda simple de un registro específico o una solicitud para seleccionar todos los registros que satisfagan un conjunto de criterios.

Reporte o informe: es una lista ordena de los campos y registros seleccionados en un formato fácil de leer.

Los tipos de datos que se pueden introducir a una base de datos son:

Menciones los tipos de datos que pueden introducirse en una Base de Datos, se dividen en:

*numéricos: se pueden introducir números para identificar partes del archivo, esto identifica la parte que numera al archivo o lo distingue de alguna manera.

*texto: el texto es un nombre que identifica al campo, ya sea el nombre del autor o

*etiquetas: son los títulos con los que cada campo es designado.

*fórmulas: son datos que aparecen como numéricos pero fueron hechos por medio de fórmulas

Un paquete manejador de bases de datos es más conveniente cuando se esta trabajando con bases de datos, y un administrador de archivos se usa más cuando sólo se esta buscando un archivo desde un procesador de textos

EL AMOR DE DIOS

2009-11-01T20:29:00.000-08:00

EL AMOR DE DIOS

Muchas personas que se sienten solas buscan encontrar el amor de su vida y han fracasado, madres solteras que buscan alguien que las ame y las apoye vuelven a fracasar en el amor, eso se debe a que han buscado en el lugar equivocado.

JUAN 13:1 En el mundo existen muchas cosas que hablan acerca del amor, como canciones románticas que dicen que por su ser amado es capaz de dar la vida y que sin su ser amado prefiere la muerte, los jóvenes muy seguido hablan de haber encontrado el verdadero amor, además de también existe un día en el que el mundo acostumbra intercambiar regalos para demostrar su amor, al ver esas cosas pareciera que en el mundo hay amor hacia los demás, pero la realidad es que no es así, las canciones románticas solo son palabras que se las lleva el viento, los jóvenes se desilusionan muy seguido al darse cuenta que lo que ellos creían que era amor solamente era una ilusión pasajera o solamente pasión, y se dan cuenta que no han conocido el verdadero amor, por lo cual el mundo esta tan necesitado de conocer el verdadero amor y todo el que anda en busca lo puede encontrar en el evangelio de Cristo porque a través de él es que llegamos a conocer el amor de Dios, un amor puro, sincero, sin interés, un amor perfecto que seguramente no hay amor sin igual.

Juan 3:16 Porque de tal manera amo Dios al mundo para que todo aquel que en Él crea no se pierda mas tenga vida eterna.

I. La fuente del regalo. (Dios)

Dios es la fuente de todo bien, Dios miro como el hombre lo había traicionado y como las consecuencias habían causado la condenación de su alma.

Y en base a su amor y misericordia fue que el tomo la decisión de encarnarse y darnos asi el regalo más sublime e inmerecible SU HIJO JESUCRISTO.

El hecho de que Dios sea el originador del regalo, declara que la salvación con todos sus beneficios son de origen divino y no en base a deseos o obras humanas para que de esa manera sea Dios glorificado en todo Ya que solo a el corresponde la gloria por los siglos de los siglos amen.

II. La razón del regalo. (Amor)

El único motivo por el cual Dios se encano y murió y resucito fue amor, Dios nos ama, independientemente de nuestra nacionalidad, condición física, condición económica o cualquier otra cosa Dios nos amo y nos ama.

Y ello lo llevo no solo a encarnarse sino aun a dar su vida en rescate por la nuestra lo cual es la prueba de amor mas grande que el ser humano pueda recibir. ( Gracias señor.)

III. El objeto del regalo. (El mundo)

Dios en su amor decidió hacer del hombre la máxima expresión de su creación y convertirlo en el propósito principal de su creación.

Por ello es que somos nosotros los que nos convertimos en el objeto hacia el cual es dirigido el regalo de Dios a través de Jesucristo.

IV. El propósito del regalo. (Salvación)

Salvación, la razón por la cual Dios se encarno es para darnos salvación y vida eterna.
No hay otra razón, solo el que podamos ser salvos y poder asi pasar la eternidad con nuestro creador.

V. La condición. (Fe)

Lo único que Dios pide para ser dignos de recibir el regalo es Fe, que creamos en su hijo Jesucristo y aceptemos su señorío en nuestra vida, el no creer hace que seamos indignos de merecer el regalo y nos convierte en enemigos de Dios ya que despreciamos su sacrificio con nuestra indiferencia. (Dios mío líbranos)

1 – CORINTIOS 13 NADA MÁS PERFECTO QUE EL AMOR… A veces el verdadero amor también lastima el corazón, a veces se destruyen vidas de tanto amar, pero ese mismo amor puede curar las heridas, llenar vacíos y hacer olvidar rencores.

El amor tiene una amplia gama… amor de padre, de madre, de hermano de amigo….amor de hombre o mujer; pero siempre funciona de la misma manera…si es amor verdadero sabe curar… Nada es más perfecto que el amor…

Jesús sabia que los momento que se le avecinaban eran los más amargos de su vida porque sabía que tendría que morir en una cruz para llevar los pecados de los que creerían en El, pero aun en esos momentos difíciles no dejo de brindar atención y cuidados a sus discípulos, ese mismo amor es el que muestra hacia nuestras vidas en que siendo nosotros personas débiles llenas de imperfección y sabiendo que le vamos a fallar, el tiene amor para perdonarnos, para limpiarnos del pecado con su sangre. el amor de Dios no disminuye, no cambia porque es un amor santo y puro, y sincero, a diferencia del que existe en el mundo un amor que disminuye que deja de existir, un amor de apariencia, un amor interesado, un amor carnal. Por cual amor te decides la decisión es tuya o el amor de Dios, o el amor que hay en el mundo.

Hay que tomar en cuenta que no importa en qué condiciones te encuentres en este momento, quizás creas que nadie te ama, que no tienes perdón, o que solo has ido de fracaso en fracaso, pero en Cristo tienes la solución para tu vida, solo debes creer en El, que él te puede perdonar tus pecados y darte vida eterna. Dios hoy hace un llamado a tu vida, Cree en el Señor Jesucristo y se Salvo. Recibe el regalo de la vida eterna que Dios te ofrece, la decisión es tuya.

“SI QUIERES AMAR A CRISTO...,

EXTIENDE TU AMOR A TODO EL MUNDO...,

PORQUE LOS MIEMBROS DE CRISTO ESTÁN POR TODO EL MUNDO...”

“EL QUE AMA CONSTRUYE”