Portafolio oscar vega by oscar vega

Profesor José Benito franco Urrea Materia: ingeniería de software Matricula: 25083154 alumno: Oscar Fermín Vega Cota Unidad: centro Horario: 1:00 a 3:00 pm Aula: 8 Cuatrimestre: 6

Portafolio de Evidencia Ingeniera del Software

INGENIERIA DE SOFTWARE

PLANEACIÓN DE CURSO

Plantel: Programa:

CENTRO LSIC

Fecha:

13/05/2013

Curso: Docente:

INGENIERIA DE SOFTWARE M.C. JOSÉ BENITO FRANCO URREA

Ciclo: Módulo:

2014-1 I

Conocimientos (saber)  Diseñar Soluciones de Software a través de la aplicación de metodologías, herramientas y estándares apropiados al problema.  Producir aplicaciones de software a partir de especificaciones de diseño y haciendo uso de las mejores prácticas que aseguren la calidad del producto.  Administrar Proyectos de Desarrollo de Software mediante la aplicación de procesos, modelos y estándares que contribuyan a la calidad total del producto. Habilidades (saber hacer) Manejo correcto y eficiente de la expresión oral y escrita Identificación de variables involucradas en la formulación de proyectos Analítico en el manejo del contenido de clase Responsable y analítico en la solución de casos reales. Diligencia, cuidado y limpieza Comunicación asertiva Aplicación de teorías y modelos a casos concretos Administración del tiempo y Manejo de grupos Investigación documental y de campo Actitudes (Ser) Puntual en la asistencia en clase. Disciplinado en la entrega de sus tareas y elaboración de ejercicios. Participativo en trabajo de grupo. Hábitos de estudio Disposición para trabajar en equipo Creatividad Comunicativo Respetuoso Crítico ante los problemas del entorno Predisposición positiva al cambio Humanista Mediación entre las diferencias Disposición de aceptar riesgos

Objetivo: El alumno conocerá y aplicará la metodología de diseño de software en el desarrollo de proyectos de desarrollo de sistemas de software.

SEMANA 1 Del 13 de Mayo al 16 de Mayo de 2013 Contenido Estrategia de enseñanza-aprendizaje 1.

Proceso de ingenierí a del software 1.1 Proyecto s de software 1.2 Procesos de producció n

Presentación del programa de curso.

2. inducción a la materia. 3. Formación de equipos y asignación de los temas. 4. Exposición en PowerPoint de los temas. (Maestro). 5. Análisis y reflexión de los temas por parte del alumno. 6. Exposición por parte del equipo #1. Tema investigado: Preguntas frecuentes de la Ingeniería de Software. 7. Video: Si los Programadores construyeran aviones. 8. Reporte de lectura del tema: Preguntes frecuentes de la ingeniería de software. 9. Proyecto Final

Materiales didácticos Pizarrón, cañón, PC, Videos

Recursos

Evaluación

Libros digitalizados de: INGENIERIA DEL SOFTWARE un enfoque practico Sexta Edición Autor: Roger S. Pressman

Ingeniería del Software Séptima Edición Ian Sommerville

Trabajo independiente: Exposición del Equipo #.1 Tema investigado: Preguntas frecuentes de la Ingeniería de Software.

SEMANA 2 Del 20 de Mayo al 23 de Mayo de 2013 Contenido Estrategia de enseñanza-aprendizaje 1.3 Métricas,

estimación y planeación

1.4 El equipo de desarrollo

Exposición en PowerPoint de los temas. (Maestro).

Materiales didácticos Pizarrón, cañón, PC, Videos

2. Análisis y reflexión de los temas por parte del alumno.

Recursos

Evaluación

Libros digitalizados de: INGENIERIA DEL SOFTWARE un enfoque practico Sexta Edición Autor: Roger S. Pressman

Ingeniería del Software Séptima Edición Ian Sommerville

Fase de análisis 2.1 Requeri mientos y docume ntación

Exposición por parte del equipo #2. Ingeniería de Software asistida por computadora. 4. Reporte de lectura del tema: Ingeniería de software asistida por computadora. 5. Revisión de avances del proyecto final

Pizarrón, cañón, PC

1. Trabajo independiente: Investigación y exposición del tema: Ingeniería de Software asistida por computadora.

SEMANA 3 Del 27 de Mayo al 30 de Mayo Contenido Estrategia de enseñanza-aprendizaje 2.2 Análisis 2.3 Modela do y diseño

Exposición en PowerPoint de los temas. (Maestro). 2. Análisis y reflexión de los temas por parte del alumno.

Materiales didácticos Pizarrón, cañón, PC

Recursos

Evaluación

Libros digitalizados de: INGENIERIA DEL SOFTWARE un enfoque practico Sexta Edición Autor: Roger S. Pressman

Ingeniería del Software Séptima Edición Ian Sommerville 3

Fase de implementac ión 3.1 Determi nación del lenguaje y metodol ogía

3. Exposición por parte del equipo #3. Tema investigado: Diseños de Interfaces de Usuarios 4. Revisión de avances del proyecto final.

Evaluación 1er. parcial: Deberá ser revisado por el coordinador académico y abarcar el 100% de los temas abordados hasta la semana 3 Trabajo independiente: Investigación y Exposición del Tema: Diseños de Interfaces de Usuarios.

SEMANA 4 Del de Contenido

3.2 Impleme ntación de requerim ientos del modelo 3.3 Program ación 3.4 Impleme ntación

de Estrategia de enseñanza-aprendizaje 1.

Exposición en PowerPoint de los temas. (Maestro).

2. Análisis y reflexión de los temas por parte del alumno.

3. Exposición por parte del equipo #4. Tema investigado: Diseños de Interfaces de Usuarios

Materiales didácticos Pizarrón, cañón, PC

Recursos

Evaluación

Libros digitalizados de: INGENIERIA DEL SOFTWARE un enfoque practico Sexta Edición Autor: Roger S. Pressman

Ingeniería del Software Séptima Edición Ian Sommerville

4. Reporte de lectura del tema investigador: Diseño de interfaces de usuarios.

Trabajo independiente: Exposición del Proyecto Final.

SEMANA 5 Del de Contenido

Fase de pruebas y mantenimien to 4.1 Diseño de pruebas 4.2 Estrategi as de prueba 4.3 Plan de manteni miento

de Estrategia de enseñanza-aprendizaje 1.

Materiales didácticos Pizarrón, cañón, PC

Exposición en PowerPoint de los temas. (Maestro).

2. Análisis y reflexión de los temas por parte del alumno. 3. Exposición y revisión del proyecto Final

Recursos

Evaluación

Libros digitalizados de: INGENIERIA DEL SOFTWARE un enfoque practico Sexta Edición Autor: Roger S. Pressman

Ingeniería del Software Séptima Edición Ian Sommerville

Evaluación 2o. parcial: Deberá ser revisado por el coordinador académico y abarcar el 100% de los temas abordados en las semanas 4 y 5. Portafolio de aprendizaje: Deberá ser revisado por el coordinador académico e incluir todos los elementos establecidos en el formato institucional. Trabajo independiente: Exposición y revisión del proyecto final.

RECURSOS TIPO

TITULO

AUTOR

EDITORIAL / REVISTA

AÑO

Libro

Ingeniería del Software - Un Enfoque Practico

Pressman, Roger S.

Mc. Graw Hill

2002

Libro

Ingeniería del Software Ingeniería de Software Orientada a Objetos Con Java E Internet

Sommerville, Ian

Pearson

2006

Weitzenfeld, Alfredo

Thomson

2006

Libro

ESTAS CELDAS NO DEBEN MODIFICARSE EVALUACIÓN Actividades semanales Trabajos independientes Evaluación 1er. parcial Evaluación 2o. Parcial Portafolio de aprendizaje TOTAL

30 20 15 25 10 100

% % % % % %

UNIVERSIDAD DEL DESARROLLO PROFESIONAL

Perfil Descriptivo de Clase Materia:

INGENIERÍA DE SOFTWARE

Ciclo:

2013-2

Maestro:

M.C. JOSÉ BENITO FRANCO URREA

Horario:

13:00-15:00

Objetivo del Curso:

El alumno conocerá y aplicará la metodología de diseño de software en el desarrollo de proyectos de desarrollo de sistemas de software.

Bibliografía:

TIPO

LIBRO

TITULO

Ingeniería del Software - Un Enfoque Practico

AUTOR

Pressman, Roger S.

EDITORIAL/REVISTA

Mc. Graw Hill

AÑO

2002

LIBRO

criterios para la Evaluación

Ingeniería del Software Ingeniería de Software Orientada a Objetos Con Java E Internet

Sommerville, Pearson Ian

2006

Weitzenfeld, Thomson Alfredo

2006

CALIFICACIÓN ORDINARIA (PONDERACIÓN) Actividades semanales

30%

Examen primer parcial.

15%

Portafolio reaprendizaje

10%

Examen segundo parcial.

25%

Trabajos independientes

20%

TOTAL

100%

Reglas 1. El alumno es responsable de enterarse de su número de faltas y retardos. 2. El alumno debe contar con un mínimo del 80% de asistencia para tener derecho a su calificación final. 3. El alumno que se sorprenda incurriendo en actos desleales en la elaboración de exámenes, tareas o trabajos, obtendrá cero (0) de calificación en el trabajo, tarea y/o examen 4. Es responsabilidad del estudiante hablar inmediatamente con el maestro cuando tenga problemas con el material de clase, sus calificaciones, etc. De esta manera evitaremos problemas en el fin del ciclo. 5. Sólo se justifican inasistencias si son autorizadas por la coordinación académica bajo el procedimiento correspondiente 6. Se tomara asistencia al iniciar la clase. 7. Prohibido utilizar teléfonos celulares y/o aparatos electrónicos dentro del aula. 8. La clase es de 100 minutos efectivos. 9. La clase inicia a la hora en punto 10. No se permiten alimentos ni bebidas dentro del aula.

11. Deberá presentar su Carnet de Pago, expedido por su coordinador administrativo, para la autorización de recepción de trabajos finales y la aplicación de exámenes en la última semana del módulo. Calendarización Sesión

Tema

Fecha

13/05/2013

14/05/2013

15/05/2013

16/05/2013

20/05/2013

21/05/2013

Presentación del programa, Introducción al tema exposición por parte del maestro, Integración de equipos, diagnóstico de conocimientos del grupo. 1. Proceso de ingeniería del software a. Modelos del proceso del software 1.1. Proyectos de software 1.2. Procesos de producción  Modelo en cascada.  Desarrollo evolutivo o espiral  Modelo Incremental  Desarrollo Iterativo 1.3. Métricas, estimación y planeación 1.4. Equipo de Desarrollo Exposición tema de investigación Equipo #1 Preguntas frecuentes de la Ingeniería de Software. 2. Fase de análisis 2.1. Requerimientos y documentación 2.1.1 proceso de ingeniería de requerimientos. 2.2. 2.3.

Análisis Modelado y diseño

3 7

22/05/2013

23/05/2013

Fase de implementación 3.1. Determinación del lenguaje y metodología Revisión de Avances del Proyecto Final 3.2. Implementación de requerimientos del modelo Exposición del tema investigado por el equipo #2: Ingeniería de Software asistida por computadora. 3.3. Programación 3.3.1. Métodos ágiles 3.3.2. Programación extrema 3.3.3. Desarrollo rápido de aplicaciones 3.3.4. Prototipado de Software 3.4. Implementación 4. Fase de pruebas y mantenimiento

27/05/2013

28/03/2013

29/05/2013

Repaso de clase para presentar el primer examen parcial Revisión de avances del proyecto final.

30/05/2013

EXAMEN PRIMER PARCIAL

03/06/2013

04/06/2013

4.1.

Diseño de pruebas Exposición del tema investigado por el equipo #3: Diseños de Interfaces de Usuarios

4.2.

Estrategias de prueba

Plan de mantenimiento

05/06/2013

06/06/2013

10/06/2013

11/06/2013

12/06/2013

Exposiciones del proyecto final equipos #1, #2,#3 Exposici贸n del Proyecto final Equipo #4 Repaso para el Segundo Examen Parcial EXAMEN SEGUNDO PARCIAL

13/06/2013

ENTREGA DE CALIFICACIONES ORDINARIAS

4.3.

Exposici贸n del tema investigado por el equipo #4: Atributos de los sistemas y

aplicaciones basados en WEB

EXAMEN EXTRAORDINARIOS

INFORMACION INSTITUCIONAL MISION.

La misión de UNIDEP es formar profesionales de éxito que cuenten con actitudes, habilidades y conocimientos que demanda el sector productivo de la región.

VISION.

La Universidad del Desarrollo Profesional es una institución de educación superior de calidad, que ofrece programas presénciales y semipresenciales de bachillerato, profesional asociado, licenciatura, postgrado, diplomados y cursos en México y en el extranjero.

Se distingue por facilitar a sus egresados la incorporación al mercado de trabajo, apoyada en una estrecha vinculación con el sector productivo y en planes de estudios pertinentes y dinámicos.

Es reconocida por su modelo educativo profesionalizante, por la flexibilidad de su oferta académica impartida en ciclos continuos y por horarios y cuotas accesibles, acordes a la disponibilidad de tiempo y recursos económicos del alumno.

Cuenta con profesores de amplia experiencia profesional y educativa. Sus instalaciones

dentro

ciudad

permiten

fácil

acceso.

Cuenta con un modelo de administración sistematizado, participativo, operado por personal que es recompensado por su desempeño efectivo que le permite maximizar las aportaciones de sus socios y mantener finanzas sanas.

VALORES Y ACTITUDES UNIDEP Lealtad._ Los Integrantes de la comunidad Universitaria consideramos la fidelidad como un valor excelso que enaltecemos en nuestro quehacer diario. Justicia._ Los integrantes de la comunidad Universitaria actuamos con la constante y perpetua voluntad de dar a cada cual lo que le corresponde conforme a sus méritos o actos. Honestidad._ Los integrantes de la comunidad universitaria actuamos con sinceridad y honradez en nuestras tareas y en congruencia entre los pensamientos, palabras y acciones. Responsabilidad._ Los integrantes de la comunidad universitaria llevamos a cabo nuestras actividades con integridad, con sentido del propósito y apegados a los objetivos institucionales. Esfuerzo._ Los integrantes de la comunidad universitaria usamos nuestra máxima energía para cumplir con los objetivos trazados. Creatividad._ Los integrantes de la comunidad universitaria resolvemos los problemas con imaginación, conocimientos y con un espíritu de mejora continua.

Índice. 1. INTRODUCCIÓN A INGENIERIA DE SOFTWARE. 2. REPORTE DE LECTURA PREGUNTAS FRECUENTES DE INGENIERÍA DEL SOFTWARE. 3. PRESENTACIÓN DEL EQUIPO #1 PREGUNTAS FRECUENTES DE INGENIERIA DEL SOFTWARE. 4. REPORTE DE LECTURA EQUIPO # 2 INGENIERÍA DEL SOFTWARE ASISTIDA POR COMPUTADORA. 5. PRESENTACIÓN DEL EQUIPO #2 INGENIERÍA DEL SOFTWARE ASISTIDA POR COMPUTADORA. 6. INVESTIGACIÓN DE CLASE MODELO RUP. 7. INVESTIGACIÓN DE CLASE DE LAS 4 FASE DEL MODELO RUP. 8. INVESTIGACIÓN DE CLASE MÉTRICA-CALIDAD. 9. INVESTIGACIÓN DE CLASE FASE DE GESTIÓN DE PLANEACIÓN (PLANIFICACIÓNCLAENDARIZACIÓN-GETIÓN DE RIESGOS). 10. REPORTE DE LECTURA TEMA EQUIPO #3: DISEÑO DE INTERFASE DE USUARIOS. 11. REPORTE DE LECTURA TEMA EQUIPO #4: ATRIBUTOS DE LOS SISTEMAS Y APLICACIONES BASADAS EN WEB. 12. INVESTIGACIONES ESPECIALES: a. FRAMEWORKS. b. UML (MODELO DE LENGUAJE UNIFICADO). c. MICROSOFT PROJECT, INTELIGENCIA ARTIFICIAL, LENGUAJE COBOL. d. SOFTWARE REQUISITE PRO. e. SECOND LIFE

INTRODUCCIÓN A INGENIERIA DE SOFTWARE. Un sistema informático está compuesto por hardware y software. En cuanto al hardware, su producción se realiza sistemáticamente y la base de conocimiento para el desarrollo de dicha actividad está claramente definida. La fiabilidad del hardware es, en principio, equiparable a la de cualquier otra máquina construida por el hombre. Sin embargo, respecto del software, su construcción y resultados han sido históricamente cuestionados debido a los problemas asociados, entre ellos podemos destacar los siguientes [1]: 

Los sistemas no responden a las expectativas de los usuarios.



Los programas “fallan” con cierta frecuencia.



Los costes del software son difíciles de prever y normalmente superan las estimaciones.



La modificación del software es una tarea difícil y costosa.



El software se suele presentar fuera del plazo establecido y con menos prestaciones de las consideradas inicialmente.



Normalmente, es difícil cambiar de entorno hardware usando el mismo software.



El aprovechamiento óptimo de los recursos (personas, tiempo, dinero, herramientas, etc.) no suele cumplirse. 1

Según el Centro Experimental de Ingeniería de Software (CEIS) , el estudio de mercado The 2 Chaos Report realizado por Standish Group Internactional en 1996, concluyó que sólo un 16% de los proyectos de software son exitosos (terminan dentro de plazos y costos y cumplen los requerimientos acordados). Otro 53% sobrepasa costos y plazos y cumple parcialmente los requerimientos. El resto ni siquiera llega al término. Algunas deficiencias comunes en el desarrollo de software son: 

Escasa o tardía validación con el cliente.



Inadecuada gestión de los requisitos.



No existe medición del proceso ni registro de datos históricos.



Estimaciones imprevistas de plazos y costos.



Excesiva e irracional presión en los plazos.



Escaso o deficiente control en el progreso del proceso de desarrollo.



No se hace gestión de riesgos formalmente.



No se realiza un proceso formal de pruebas.



No se realizan revisiones técnicas formales e inspecciones de código.

El primer reconocimiento público de la existencia de problemas en la producción de software tuvo lugar en la conferencia organizada en 1968 por la Comisión de Ciencias de la OTAN en Garmisch (Alemania), dicha situación problemática se denominó crisis del software. En esta conferencia, así como en la siguiente realizada en Roma en 1969, se estipuló el interés hacia los aspectos técnicos y administrativos en el desarrollo y mantenimiento de productos software. Se pretendía acordar las bases para una ingeniería de construcción de software. Según Fritz Bauer [2] lo que se necesitaba era “establecer y usar principios de ingeniería orientados a obtener software de manera económica, que sea fiable y funcione eficientemente sobre máquinas reales”. Esta definición marcaba posibles cuestiones tales como: ¿Cuáles son los principios robustos de la ingeniería aplicables al desarrollo de software de computadora? ¿Cómo construimos el software económicamente para que sea fiable? ¿Qué se necesita para crear programas de computadora que funcionen eficientemente no en una máquina sino en diferentes máquinas reales?. Sin 1 2

http://www.ceis.cl/Gestacion/Gestacion.htm (5.3.2003) http://standishgroup.com/ (5.3.2003)

embargo, dicho planteamiento además debía incluir otros aspectos, tales como: mejora de la calidad del software, satisfacción del cliente, mediciones y métricas, etc. El “IEEE Standard Glossary of Software Engineering Terminology” (Stad. 610.12-1990) ha desarrollado una definición más completa para ingeniería del software [1]: “(1) La aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento del software; es decir, la aplicación de ingeniería al software. (2) El estudio de enfoques en (1)”. Pressman [1] caracteriza la Ingeniería de Software como “una tecnología multicapa”, ilustrada en la Figura 1.

Figura 1: Capas de la Ingeniería de Software. Dichas capas se describen a continuación: 

Cualquier disciplina de ingeniería (incluida la ingeniería del software) debe descansar sobre un esfuerzo de organización de calidad. La gestión total de la calidad y las filosofías similares fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de enfoques cada vez más robustos para la ingeniería del software.



El fundamento de la ingeniería de software es la capa proceso. El proceso define un marco trabajo para un conjunto de áreas clave, las cuales forman la base del control de gestión proyectos de software y establecen el contexto en el cual: se aplican los métodos técnicos, producen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio gestiona adecuadamente.



Los métodos de la ingeniería de software indican cómo construir técnicamente el software. Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. Estos métodos dependen de un conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas.



Las herramientas de la ingeniería del software proporcionan un soporte automático o semiautomático para el proceso y los métodos, a estas herramientas se les llama herramientas CASE (Computer-Aided Software Engineering).

de de se se

Dado lo anterior, el objetivo de la ingeniería de software es lograr productos de software de calidad (tanto en su forma final como durante su elaboración), mediante un proceso apoyado por métodos y herramientas. A continuación nos enfocaremos en el proceso necesario para elaborar un producto de software.

El proceso de desarrollo del software Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Dicho proceso, en términos globales se muestra en la Figura 2 [3]. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas [4]. Aunque un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuación se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construcción. Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución que se puedan presentar (entradas, valores de variables, datos almacenados, software del sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.). Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son inevitables, no sólo después de entregado en producto sino también durante el proceso de desarrollo. Además, de las dos anteriores, siempre puede señalarse la inmadurez de la ingeniería del software como disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniería. Sin embargo, esto no es más que un inútil consuelo.

Requisitos nuevos o modificados

Proceso de Desarrollo de Software

Sistema nuevo o modificado

Figura 2: proceso de desarrollo de software.

El proceso de desarrollo de software no es único. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difícil automatizar todo un proceso de desarrollo de software. A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos [4]: 1. Especificación de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software. 2. Diseño e Implementación: Se diseña y construye el software de acuerdo a la especificación. 3. Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente. 4. Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente. Además de estas actividades fundamentales, Pressman [1] menciona un conjunto de “actividades protectoras”, que se aplican a lo largo de todo el proceso del software. Ellas se señalan a continuación: 

Seguimiento y control de proyecto de software.



Revisiones técnicas formales.



Garantía de calidad del software.



Gestión de configuración del software.



Preparación y producción de documentos.



Gestión de reutilización.



Mediciones.



Gestión de riesgos.

Pressman [1] caracteriza un proceso de desarrollo de software como se muestra en la Figura 3. Los elementos involucrados se describen a continuación: 

Un marco común del proceso, definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamaño o complejidad.



Un conjunto de tareas, cada uno es una colección de tareas de ingeniería del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garantía de calidad, que permiten que las actividades del marco de trabajo se adapten a las características del proyecto de software y los requisitos del equipo del proyecto.



Las actividades de protección, tales como garantía de calidad del software, gestión de configuración del software y medición, abarcan el modelo del proceso. Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

Figura 3: Elementos del proceso del software

Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de software es establecer las relaciones entre elementos que permitan responder Quién debe hacer Qué, Cuándo y Cómo debe hacerlo [5].

Figura 4: Relación entre elementos del proceso del software

En la Figura 4 se muestran los elementos de un proceso de desarrollo de software y sus relaciones. Así las interrogantes se responden de la siguiente forma: 

Quién: Las Personas participantes en el proyecto de desarrollo desempeñando uno o más Roles específicos.



Qué: Un Artefacto es producido por un Rol en una de sus Actividades. Los Artefactos se especifican utilizando Notaciones específicas. Las Herramientas apoyan la elaboración de Artefactos soportando ciertas Notaciones.



Cómo y Cuándo: Las Actividades son una serie de pasos que lleva a cabo un Rol durante el proceso de desarrollo. El avance del proyecto está controlado mediante hitos que establecen un determinado estado de terminación de ciertos Artefactos.

La composición y sincronía de las actividades está basada en un conjunto de Principios y Prácticas. Las Prácticas y Principios enfatizan ciertas actividades y/o la forma como deben realizarse, por ejemplo: desarrollar iterativamente, gestionar requisitos, desarrollo basado en componentes, modelar visualmente, verificar continuamente la calidad, gestionar los cambios, etc.

Modelos de proceso software Sommerville [4] define modelo de proceso de software como “Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real.” Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software. Modelos que se van a discutir a continuación:  3

Codificar y corregir

Un artefacto es una pieza de información que (1) es producida, modificada o usada por el proceso, (2) define un área de responsabilidad para un rol y (3) está sujeta a control de versiones. Un artefacto puede ser un modelo, un elemento de modelo o un documento.



Modelo en cascada



Desarrollo evolutivo



Desarrollo formal de sistemas



Desarrollo basado en reutilización



Desarrollo incremental



Desarrollo en espiral

Codificar y corregir (Code-and-Fix) Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos: 

Escribir código.



Corregir problemas en el código.

Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y mantenimiento. Este modelo tiene tres problemas principales [7]: 

Después de un número de correcciones, el código puede tener una muy mala estructura, hace que los arreglos sean muy costosos.



Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara.



El código es difícil de reparar por su pobre preparación para probar y modificar.

Modelo en cascada El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de ingeniería [8]. Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso. El modelo en cascada consta de las siguientes fases: 1. Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle. 2. Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema. 3. Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad.

4. Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente. 5. Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos. La interacción entre fases puede observarse en la Figura 5. Cada fase tiene como resultado documentos que deben ser aprobados por el usuario. Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la corrección de los problemas encontrados en fases previas.

Figura 5: Modelo de desarrollo en cascada. En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción entre las distintas fases de desarrollo. Algunos problemas que se observan en el modelo de cascada son: 

Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación de documentos.



Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases.



Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean ignorados o corregidos de una forma poco elegante.



Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto.



Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a cambios en los requisitos.

Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte de proyectos grandes.

Desarrollo evolutivo La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. En la Figura 6 se observa cómo las actividades concurrentes: especificación, desarrollo y validación, se realizan durante el desarrollo de las versiones hasta llegar al producto final. Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

Figura 6: Modelo de desarrollo evolutivo.

Existen dos tipos de desarrollo evolutivo: 

Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario.



Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos.

Entre los puntos favorables de este modelo están: 

La especificación puede desarrollarse de forma creciente.



Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.



Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.

Desde una perspectiva de ingeniería y administración se identifican los siguientes problemas: 

Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema.



Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento.



Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.

Este modelo es efectivo en proyectos pequeños (menos de 100.000 líneas de código) o medianos (hasta 500.000 líneas de código) con poco tiempo para su desarrollo y sin generar documentación para cada versión. Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento más estructurado. Los subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio.

Desarrollo formal de sistemas Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable. Desarrollo Formal

Desiciones Especificación Informal Especificación Especificación de alto nivel (prototipo)

Tranformación Interactiva

Especificación de bajo nivel

Transformación Automática

Código Fuente

Optimización Validación de Especificación

Mantenimiento

Figura 7: Paradigma de programación automática. La Figura 7 (obtenida desde [20]) ilustra un paradigma ideal de programación automática. Se distinguen dos fases globales: especificación (incluyendo validación) y transformación. Las características principales de este paradigma son: la especificación es formal y ejecutable constituye el primer prototipo del sistema), la especificación es validada mediante prototipación. Posteriormente, a través de transformaciones formales la especificación se convierte en la implementación del sistema, en el último paso de transformación se obtiene una implementación en un lenguaje de programación determinado. , el mantenimiento se realiza sobre la especificación (no sobre el código fuente), la documentación es generada automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante parches sobre la implementación). Observaciones sobre el desarrollo formal de sistemas: 

Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las pruebas que verifican la correspondencia con la especificación no son necesarias.



Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes.



Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.

Desarrollo basado en reutilización Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización. Este modelo consta de 4 fases ilustradas en la Figura 9. A continuación se describe cada fase: 1. Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos. 2. Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes más adecuados (fase 1). 3. Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco. 4. Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada.

Las ventajas de este modelo son: 

Disminuye el costo y esfuerzo de desarrollo.



Reduce el tiempo de entrega.



Disminuye los riesgos durante el desarrollo.

Figura 8: Desarrollo basado en reutilización de componentes

Desventajas de este modelo: 

Los “compromisos” en los requisitos son inevitables, por lo cual puede que el software no cumpla las expectativas del cliente.



Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores del sistema.

Procesos iterativos A continuación se expondrán dos enfoques híbridos, especialmente diseñados para el soporte de las iteraciones: 

Desarrollo Incremental.



Desarrollo en Espiral.

Desarrollo incremental Mills [9] sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema (ver Figura 10). Es una combinación del Modelo de Cascada y Modelo Evolutivo. Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema. Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

Figura 9: Modelo de desarrollo iterativo incremental.

Entre las ventajas del modelo incremental se encuentran: 

Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento.



Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema.



Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.



Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos.

Algunas de las desventajas identificadas para este modelo son: 

Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas).



Cada incremento debe aumentar la funcionalidad.



Es difícil establecer las correspondencias de los requisitos contra los incrementos.



Es difícil detectar las unidades o servicios genéricos para todo el sistema.



Desarrollo en espiral El modelo de desarrollo en espiral (ver Figura 11) es actualmente uno de los más conocidos y fue propuesto por Boehm [7]. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra. Cada ciclo de desarrollo se divide en cuatro fases: 1. Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos. 2. Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos. 3. Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase. 4. Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto.

Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es una actividad importante en la administración del proyecto.

El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalúan los riesgos con actividades como análisis detallado, simulación, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.

Figura 10: Modelo de desarrollo en Espiral

¿Cuál es el modelo de proceso más adecuado? Cada proyecto de software requiere de una forma de particular de abordar el problema. Las propuestas comerciales y académicas actuales promueven procesos iterativos, donde en cada iteración puede utilizarse uno u otro modelo de proceso, considerando un conjunto de criterios (Por ejemplo: grado de definición de requisitos, tamaño del proyecto, riesgos identificados, entre otros). En la Tabla 1 se expone un cuadro comparativo de acuerdo con algunos criterios básicos para la selección de un modelo de proceso [10], la medida utilizada indica el nivel de efectividad del modelo de proceso de acuerdo al criterio (Por ejemplo: El modelo Cascada responde con un nivel de efectividad Bajo cuando los Requisitos y arquitectura no están predefinidos ):

Modelo de proceso

Funciona con requisitos y arquitectura no predefinidos

Produce software altamente fiable

Gestión de riesgos

Codificar y corregir

Bajo

Visión del progreso por el Permite correcciones Cliente y el sobre la marcha Jefe del proyecto

Alto

Medio

Cascada

Bajo

Alto

Bajo

Medio o Alto

Medio

Medio o Alto

Alto

Medio

Alto

Desarrollo formal de sistemas

Bajo

Alto

Bajo a Medio

Bajo

Desarrollo orientado a reutilizaci贸n

Medio

Bajo a Alto

Bajo a Medio

Alto

Incremental

Bajo

Alto

Medio

Bajo

Espiral

Alto

Medio

Evolutivo exploratorio

Evolutivo prototipado

Tabla 1: Comparaci贸n entre modelos de proceso de software.

Metodologías para desarrollo de software Un proceso de software detallado y completo suele denominarse “Metodología”. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, etc.). Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño. La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, información disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de análisis y diseño, podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales (o peyorativamente denominada Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso. A continuación se revisan brevemente cada una de estas categorías de metodologías.

Metodologías estructuradas Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente apropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta generación. 4

Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE (Francia), MÉTRICA 6 (España), SSADM (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito 7 8 9 10 académico: Gane & Sarson , Ward & Mellor , Yourdon & DeMarco e Information Engineering .

Metodologías orientadas a objetos Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de 11 C++ por Bjarne Stroustrup en 1981 y actualmente Java o C# de Microsoft. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto. En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más 12 modesto, para dar lugar al Unified Modeling Language (UML) , la notación OO más popular en la actualidad. 4

http://perso.club-internet.fr/brouardf/SGBDRmerise.htm (7.5.2002) http://www.map.es/csi/metrica3/ (7.5.2003) 6 http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html (7.5.2003) 7 http://portal.newman.wa.edu.au/technology/12infsys/html/dfdnotes.doc (29.8.2003) 8 http://www.yourdon.com/books/coolbooks/notes/wardmellor.html (29.8.2003) 9 http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Yourdon%2FDemarco (29.8.2003) 10 http://gantthead.com/Gantthead/process/processMain/1,1289,2-12009-2,00.html (29.8.2003) 11 http://java.sun.com/ (7.5.2003) 12 http://www.uml.org/ (7.5.2003) 5

Algunos métodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh). Algunas metodologías orientadas a objetos que utilizan la notación UML son: Rational Unified 13 14 Process (RUP) , OPEN , MÉTRICA (que también soporta la notación estructurada).

Metodologías tradicionales (no ágiles) Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción del sistema. Todas las propuestas metodológicas antes indicadas pueden considerarse como metodologías tradicionales. Aunque en el caso particular de RUP, por el especial énfasis que presenta en cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse), realizando una configuración adecuada, podría considerarse Ágil.

Metodologías ágiles Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último momento) [11]. Entre las metodologías ágiles identificadas en [11]:

13 14



Extreme Programming [6].



Scrum ([12], [13]).



Familia de Metodologías Crystal [14].



Feature Driven Development [15].



Proceso Unificado Rational, una configuración ágil ([16]).



Dynamic Systems Development Method [17].



Adaptive Software Development [18].



Open Source Software Development [19].

http://www.rational.com/products/rup/index.jsp (7.5.2003) http://www.open.org.au/ (17.9.2003)

Referencias [1] [2]

Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997. Naur P., Randell B., Software Engineering: A Report on a Conference Sponsored by the NATO Scienc, 1969. [3] Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software, Addison Wesley 2000. [4] Sommerville, I., Ingeniería de Software, Pearson Educación, 2002. [5] Letelier, P., Proyecto Docente e Investigador, DSIC, 2003. [6] Beck, K., Una explicación de la Programación Extrema. Aceptar el cambio, Pearson Educación, 2000. [7] Boehm, B. W., A Spiral Model of Software Develpment and Enhancement, IEEE Computer ,1988. [8] Royce, W., Managing the developmento of large software systems: concepts and technique, IEEE Westcon, 1970. [9] Mills, H., O´Neill, D., The Management of Software Engineering, IBM Systems, 1980. [10] Laboratorio Ing. Soft., Ingeniería de software 2, Departamento de Informática, 2002. [11] Abrahamsson, P., Salo, O., Ronkainen, J., Agile Software Development Methods. Review and Analysis, VTT, 2002. [12] Schwaber, K., Scrum Development Process. Workshop on Business Object Design and Implementation, OOPSLA´95, 1995. [13] Schwaber, K., Beedle, M., Agile Software Development With Scrum, Prentice Hall, 2002. [14] Cockburn, A., Agile Software Development, Addison Wesley, 2002. [15] Palmer, S. R., Felsing, J. M., A Practical Guide to Feature Driven Development, Prentice Hall, 2002. [16] Kruchten, P., A Rational Development Process, Crosstalk, 1996. [17] Stapleton, J., Dynamic Systems Development Method - The Method in Practice, Addison Wesley, 1997. [18] Highsmith, J., Adaptive Software Development: A Collaborative Approach, Dorset House, 2000.

[19] O´Reilly, T., Lessons from Open Source Software Development, ACM, 1999. [20] Balzer R. A 15 Year Perspective on Automatic Programming. IEEE Transactions on Software Engineering, vol.11, núm.11, páginas 1257-1268, Noviembre 1985.

REPORTE DE LECTURA PREGUNTAS FRECUENTES DE INGENIERÍA DEL SOFTWARE. ¿Qué es un Software? El software no son sólo programas, sino todos los documentos asociados y la configuración de datos que se necesitan para hacer que estos programas operen de manera correcta. Por lo general, un sistema de software consiste en diversos programas independientes, archivos de configuración que se utilizan para ejecutar estos programas, un sistema de documentación que describe la estructura del sistema, la documentación para el usuario que explica cómo utilizar el sistema y sitios web que permitan a los usuarios descargar la información de productos recientes. Los tipos de software 1. Genéricos. Son sistemas aislados producidos por una organización de desarrollo y que se venden al mercado abierto a cualquier cliente que le sea posible comprarlos. Ejemplos de este tipo de producto son el software para Pc´s tales como bases de datos, procesadores de texto, paquetes de dibujo y herramientas de gestión de proyectos. 2. Personalizados (o hechos a medida). Son sistemas requeridos por un cliente en particular. Un contratista de software desarrolla el software especialmente para ese cliente. Ejemplos de este tipo de software son los sistemas de control para instrumentos electrónicos, sistemas desarrollados para llevar a cabo procesos de negocios específicos y sistemas de control del tráfico aéreo. ¿Qué es la ingeniería del software? Es una disciplina de la ingeniería que comprende todos los aspectos de la producción de software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste después de que se utiliza. ¿Cuál es la diferencia entre ingeniería del software y ciencia de la computación? Esencialmente, la ciencia de la computación se refiere a las teorías y métodos subyacentes alas computadoras y los sistemas de software, mientras que la ingeniería del software se refiere a los problemas prácticos de producir software. Los ingenieros de software requieren ciertos conocimientos de ciencia de la computación, de la misma forma que los ingenieros eléctricos requieren conocimientos de física.

¿Cuál es la diferencia entre ingeniería del software e ingeniería de sistemas? La ingeniería de sistemas se refiere a todos los aspectos del desarrollo y de la evolución de sistemas complejos donde el software desempeña un papel principal. Por lo tanto, la ingeniería de sistemas comprende el desarrollo de hardware, políticas y procesos de diseño y distribución de sistemas, así como la ingeniería del software.

PRESENTACIÓN DEL EQUIPO #1 PREGUNTAS FRECUENTES DE INGENIERIA DEL SOFTWARE.

REPORTE DE LECTURA EQUIPO # 2 INGENIERÍA DEL SOFTWARE ASISTIDA POR COMPUTADORA. El diseño asistido por computadora, más conocido por sus siglas inglesas CAD (computer-aided design), es el uso de un amplio rango de herramientas computacionales que asisten a ingenieros, arquitectos y a otros profesionales del diseño en sus respectivas actividades. El CAD es también utilizado en el marco de procesos de administración del ciclo de vida de productos (en inglés product lifecycle management). También se puede llegar a encontrar denotado con las siglas CADD (computer-aided design and drafting), que significan «dibujo y diseño asistido por computadora». Estas herramientas se pueden dividir básicamente en programas de dibujo en dos dimensiones (2D) y modeladores en tres dimensiones (3D). Las herramientas de dibujo en 2D se basan en entidades geométricas vectoriales como puntos, líneas, arcos y polígonos, con las que se puede operar a través de una interfaz gráfica. Los modeladores en 3D añaden superficies y sólidos. Se trata básicamente de una base de datos de entidades geométricas (puntos, líneas, arcos, etc) con la que se puede operar a través de una interfaz gráfica. Permite diseñar en dos o tres dimensiones mediante geometría alámbrica, esto es, puntos, líneas, arcos, splines (curva definida a trozos mediante polinomios); superficies y sólidos para obtener un modelo numérico de un objeto o conjunto de ellos. La base de datos asocia a cada entidad una serie de propiedades como color, capa, estilo de línea, nombre, definición geométrica, etc., que permiten manejar la información de forma lógica. Además pueden asociarse a las entidades ó conjuntos de estas, otro tipo de propiedades como el coste, material, etc., que permiten enlazar el CAD a los sistemas de gestión y producción. De los modelos pueden obtenerse planos con cotas y anotaciones para generar la documentación técnica. El diseño asistido por computadora es un proceso conocido por las siglas CAD, (del inglés Computer Aided Design), que mejora la fabricación, desarrollo y diseño de los productos con la ayuda de la computadora. Con este proceso se pretende fabricarlos con mayor precisión, a un menor precio y mucho más rápido que con si se hiciera solamente por el hombre. El diseño asistido por computadora nos muestra el proceso completo de fabricación de un determinado producto con todas y cada una de sus características como tamaño, contorno, etc. Todo esto se graba en la computadora en dibujos bidimensionales o tridimensionales. Estos dibujos o diseños se guardan en la computadora. Así si creador puede con posterioridad mejorarlos, o compartirlos con otros para perfeccionar su diseño. La fabricación de productos por medio del diseño asistido por computadora tiene muchas ventajas respecto a la fabricación con operarios humanos. Entre estas están la reducción de coste de mano de obra, o la eliminación de errores humanos. También en la computadora se simula en funcionamiento de un determinado producto, se comprueba por ejemplo en un engranaje cual son sus puntos de fricción críticos y poder corregirlos. Con el diseño asistido por computadora se puede fabricar productos

complejos que serían prácticamente imposibles de realizar por el ser humano. Se estima que en un futuro se eliminar por completo la fabricación de costoso simuladores, ya que todo será comprobado por el diseño asistido por computadora.

PRESENTACIÓN DEL EQUIPO #2 INGENIERÍA DEL SOFTWARE ASISTIDA POR COMPUTADORA.

INVESTIGACIÓN DE CLASE MODELO RUP. ¿Qué es RUP? Es un proceso de ingeniería de software, que hace una propuesta orientada por disciplinas para lograr las tareas y responsabilidades de una organización que desarrolla software. Su meta principal es asegurar la producción de software de alta calidad que cumpla con las necesidades de los usuarios, con una planeación y presupuesto predecible. ¿Para quién es RUP? Diseñado para: –Profesionales en el desarrollo de software. –Interesados en productos de software. –Profesionales en la ingeniería y administración de procesos de software. ¿Por qué usar RUP? –Provee un entorno de proceso de desarrollo configurable, basado en estándares. –Permite tener claro y accesible el proceso de desarrollo que se sigue. –Permite ser configurado a las necesidades de la organización y del proyecto. –Provee a cada participante con la parte del proceso que le compete directamente, filtrando el resto.

INVESTIGACIÓN DE CLASE DE LAS 4 FASE DEL MODELO RUP. Inicio Se logra un acuerdo todos los interesados teniendo en cuenta el ciclo de vida para el proyecto generando el cuerpo del proyecto :Caso de negocios Síntesis de arquitectura posible Define el alcance del proyecto Elaboración Establecimiento de la estructura base para la arquitectura del sistema, proporciona el diseño del mismo y el desarrollo de la siguiente fase Plan del proyecto Especificación de características Arquitectura base Construcción Construir el producto, completa el desarrollo del sistema basado en la estructura base de la arquitectura Transición Transición del producto a la comunidad del usuario, en si garantiza que el software esté listo para entregar al usuario

INVESTIGACIÓN DE CLASE MÉTRICA-CALIDAD. CALIDAD DEL SOFTWARE El software es un producto como cualquier otro, y por tanto podemos hablar de software de buena calidad y software de mala calidad. La calidad del software comprende distintos aspectos como estética (que sea agradable a la vista), funcionalidad (que sea fácil de usar), eficiencia (que ejecute con rapidez y precisión los procesos), etc. Lo que distingue al software de otros productos industriales es que no es de naturaleza material, no se puede tocar. Por tanto no resulta viable hacer una valoración del mismo en base a una impresión rápida o análisis del aspecto ni en base al coste de materiales componentes. Métrica y calidad del software. Para justificar la existencia de este tipo de métrica, se argumenta que éstas deben ser enunciadas y utilizadas para administrar el proceso de desarrollo y debe ser conforme al producto de software particular. El proveedor de productos de software debe de recopilar y actuar sobre las medidas cuantitativas de la calidad de esos productos de software. Estas medidas deben ser utilizadas para los propósitos siguientes: 1. Para recopilar información y reportar valores de métricas sobre bases regulares., 2. Para identificar el actual nivel de desempeño por cada métrica., 3. Para tomar la acción remedial si los niveles de las métricas crecen peor o exceden los niveles objetivos establecidos. 4. Para establecer metas de mejoras especificas en términos de las mismas métricas. Métricas de proceso El proveedor debe tener métricas cuantitativas de la calidad del proceso de desarrollo y de liberación. Estas métricas deben de reflejar: a) Qué tan bien el proceso de desarrollo está siendo llevado a cabo en términos de puntos de revisión y en objetivos de calidad en el proceso, siendo cumplidos en tiempo de calendario, b) Qué tan efectivo es el proceso de desarrollo, al reducir la probabilidad que se introduzcan fallas o que cualquier falla introducida sea detectada. Aquí como las partes de las métricas del producto, lo importante es que los niveles sean conocidos y utilizados para el control del proceso y de las mejoras y no sean utilizadas métricas fijas. Las métricas seleccionadas deben de ajustarse al proceso utilizado y si es posible, tener un impacto directo sobre la calidad de software liberado. Las métricas también pueden ser categorizadas como métricas de resultado o métricas de predicción [35]. Una medición de predicción es normalmente una métrica de producto que puede ser utilizada para predecir el valor de otra métrica. La métrica es predicha, una métrica de proceso, es conocida como una métrica de resultado.

INVESTIGACIÓN DE CLASE FASE DE GESTIÓN DE PLANEACIÓN (PLANIFICACIÓNCLAENDARIZACIÓN-GETIÓN DE RIESGOS). CALENDARIZACION DEL PROYECTO 1.- se selecciona el modelo de proceso apropiado. 2.-identificamos tareas 3.-estimamos cantidad de trabajo y numero de personas. 4.-conocemos la fecha limite de entrega del proyecto. 5.- identificamos los riesgos. ENTONCES… Creamos una red de tareas que nos permita tener el trabajo listo en la fecha indicada. Una vez creada la red asignaremos responsabilidades a cada tarea y nos aseguraremos de realizarlas.

Gestión de riesgos. La identificación y gestión de los riesgos asociados a los requisitos del software, individuales y a grupos de ellos, desde la fase se ingeniería de requisitos puede permitir minimizarlos, evadirlos y controlarlos. El enfrentamiento proactivo de los riesgos que pueden afectar al desarrollo o a la calidad de los requisitos y las acciones para evitarlos, permitirían minimizar problemas que persisten en el desarrollo de software. Son de mayor importancia los riesgos asociados a las principales características de calidad de los requisitos.

Planificación. La Planificación es la primera función de la administración, y consiste en determinar las metas u objetivos a cumplir. La planificación incluye seleccionar misiones y objetivos como las acciones para alcanzarlos; requiere tomar decisiones; es decir, seleccionar entre diversos cursos de acción futuros. Así la planificación provee un enfoque racional para lograr objetivos preseleccionados. Objetivos Se puede afirmar que la planificación es básica para las otras funciones de la administración, ya que sin la formulación de un objetivo no habría para que organizar, nadie para dirigir y nada que controlar. Los objetivos son de gran importancia para la administración, pues le dan un sentido, una dirección u orientación a los esfuerzos aplicado. Estos objetivos, bien definidos, conocidos y planteados de un modo práctico, tienen fuerza motivadora en sí y por ellos mismos. Por eso se dice que la sola formulación de un objetivo claro implica obtener ya la mitad de su cumplimiento. En muchos casos, si bien existen objetivos, estos se formulan de un modo vago o ambiguo, sin determinar una meta precisa

REPORTE DE LECTURA TEMA EQUIPO #3 DISEÑO DE INTERFASE DE USUARIOS. El diseño de interfaz de usuario o ingeniería de la interfaz es el diseño de computadoras, aplicaciones, máquinas, dispositivos de comunicación móvil, aplicaciones desoftware, y sitios web enfocado en la experiencia de usuario y la interacción. Normalmente es una actividad multidisciplinar que involucra a varias ramas es decir al diseño y el conocimiento como el diseño gráfico, industrial, web, de software y la ergonomía; y está implicado en un amplio rango de proyectos, desde sistemas para computadoras, vehículos hasta aviones comerciales. Su objetivo es que las aplicaciones o los objetos sean más atractivos y además, hacer que la interacción con el usuario sea lo más intuitiva posible, conocido como el diseño centrado en el usuario. En este sentido las disciplinas del diseño industrial y gráfico se encargan de que la actividad a desarrollar se comunique y aprenda lo más rápidamente, a través de recursos como la gráfica, los pictogramas, los estereotipos y la simbología, todo sin afectar el funcionamiento técnico eficiente.

La Interfaz de Usuario, en adelante IU, de un programa es un conjunto de elementos hardware y software de una computadora que presentaninformación al usuario y le permiten interactuar con la información y con el computadora. También se puede considerar parte de la IU la documentación (manuales, ayuda, referencia, tutoriales) que acompaña al hardware y al software. Si la IU está bien diseñada, el usuario encontrará la respuesta que espera a su acción. Si no es así puede ser frustrante su operación, ya que el usuario habitualmente tiende a culparse a sí mismo por no saber usar el objeto. Los programas son usados por usuarios con distintos niveles de conocimientos, desde principiantes hasta expertos. Es por ello que no existe una interfaz válida para todos los usuarios y todas las tareas. Debe permitirse libertad al usuario para que elija el modo de interacción que más se adecúe a sus objetivos en cada momento. La mayoría de los programas y sistemas operativos ofrecen varias formas de interacción al usuario. Existen tres puntos de vista distintos en una IU: el del usuario, el del programador y el del diseñador (analogía de la construcción de una casa). Cada uno tiene un modelo mental propio de la interfaz, que contiene los conceptos y expectativas acerca de la misma, desarrollados a través de su experiencia.

Modelo del usuario: El usuario tiene su visión personal del sistema, y espera que éste se comporte de una cierta forma. Se puede conocer el modelo del usuario estudiándolo, ya sea realizando tests de usabilidad, entrevistas, o a través de una realimentación. Una interfaz debe facilitar el proceso de crear un modelo mental efectivo.

Para ello son de gran utilidad las metáforas, que asocian un dominio nuevo a uno ya conocido por el usuario. Un ejemplo típico es la metáfora del escritorio, común a la mayoría de las interfaces gráficas actuales. Modelo del diseñador: El diseñador mezcla las necesidades, ideas, deseos del usuario y los materiales de que dispone el programador para diseñar un producto de software. Es un intermediario entre ambos. El modelo del diseñador describe los objetos que utiliza el usuario, su presentación al mismo y las técnicas de interacción para su manipulación. Consta de tres partes: presentación, interacción y relaciones entre los objetos. La presentación es lo que primero capta la atención del usuario, pero más tarde pasa a un segundo plano, y adquiere más importancia la interacción con el producto para poder satisfacer sus expectativas. La presentación no es lo más relevante y un abuso en la misma (por ejemplo, en el color) puede ser contraproducente, distrayendo al usuario.

REPORTE DE LECTURA TEMA EQUIPO #4 ATRIBUTOS DE LOS SISTEMAS Y APLICACIONES BASADAS EN WEB. No hay mucho que decir con respecto al hecho de que los sistemas y las aplicaciones' basados en Web (nos referiremos a estas como WebApps) son muy diferentes de las otras categorías de software informático que se tratan en el Capítulo 1. Powell resume las diferencias básicas cuando afirma que los sistemas basados en Web «implican una mezcla de publicación impresa y desarrollo de software, de marketing e informática, de comunicaciones internas y relaciones externas, y de arte y tecnología». Los atributos siguientes se van a encontrar en la gran mayoría de las WebApps2:

Intensivas de Red. Por su propia naturaleza, una WebApp es intensiva de red. Reside en una red y debe dar servicio a las necesidades de una comunidad diversa de clientes. Una WebApp puede residir en Internet (haciendo posible así una comunicación abierta par todoel mundo). De forma alternativa, una aplicación se puede ubicar en una Intranet (implementando la comunicación a través de redes de una organización) o una Extranet (comunicación entre redes).

Controlada por el contenido. En muchos casos, la función primaria de una WebApp es utilizar hipermedia para presentar al usuario el contenido de textos, gráficos, sonido y vídeo. Evolución continua. A diferencia del software de aplicaciones convencional, que evoluciona con una serie de versiones planificadas y cronológicamente espaciadas, las aplicaciones Web están en constante evolución. No es inusual que algunas WebApps (específicamente, su contenido) se actualicen cada hora.

Un cuidado y una alimentación continua permite que un sitio Web crezca (en robustez y en importancia). Pero a diferencia de un jardín, las aplicaciones Web deben de servir (y adaptarse a) las necesidades de más de un jardinero, Las siguientes características de WebApps son las que conducen el proceso:

Inmediatez. Las aplicaciones basadas en Web tienen una inmediatez [NOR99] que no se encuentra en otros tipos de software. Es decir, el tiempo que se tarda en comercializar un sitio Web completo puede ser cuestión de días o semanas3. Los desarrolladores deberán utilizar los métodos de planificación, análisis, diseño, implementación y comprobación que se hayan adaptado a planificaciones apretadas en tiempo para el desarrollo de WebApps.

Seguridad. Dado que las WebApps están disponibles a través de1 acceso por red, es difícil, si no imposible, limitar la población de usuarios finales que pueden acceder a la aplicación. Con objeto de proteger el contenido confidencial y de proporcionar formas seguras de transmisión de datos, deberán implementarse fuertes medidas de seguridad en toda la infraestructura que apoya una WebApp y dentro de la misma aplicación.

Estética. Una parte innegable del atractivo de una WebApp es su apariencia e interacción. Cuando se ha diseñado una aplicación con el fin de comercializarse o vender productos o ideas, la estética puede tener mucho que ver con el éxito del diseño técnico.

Las características generales destacadas anteriormente se aplican a todas las WebApps, pero con un grado diferente de influencia. Las categorías de aplicaciones que se enumeran a continuación son las más frecuentes en el trabajo de la Web:

INVESTIGACIONES ESPECIALES:

FRAMEWORKS. FrameWork es un concepto sumamente genérico, se refiere a “ambiente de trabajo, y ejecución”, por ejemplo “.Net” es considerado un “framework” para desarrollar aplicaciones (Aplicaciones sobre Windows). En general los framework son soluciones completas que contemplan herramientas de apoyo a la construcción (ambiente de trabajo o desarrollo) y motores de ejecución (ambiente de ejecución). Siguiendo con el ejemplo: “.Net” ofrece el “Visual Studio .net” (ambiente construcción o desarrollo) que le permite a lo desarrolladores construir aplicaciones, y su motor es el “.Net framework” que permite ejecutar dichas aplicaciones. El motor de “.net” es una anexo al sistema operativo (un componente que se instala sobre el sistema operativo), y que ahora viene incluido en la mayoría de los sistema operativos de Microsoft. FrameWork puede ser algo tan grande como “.NET” o Java (también es un framework), pero también el concepto se aplica a ámbitos mas específicos, por ejemplo; dentro de Java en el ámbito especifico de aplicaciones Web tenemos los framework: Struts, “Java Server Faces”, o Spring. Estos frameworks de Java en la practica son conjuntos de librerías (API’s) para desarrollar aplicaciones Web , más librerías para su ejecución (o motor), y más un conjunto de herramientas para facilitar esta tarea (debuggers, ambientes de desarrollo como Eclipse, etc). Otros ejemplos de frameworks para ámbitos específicos: 

Ámbito: Webservices => FrameWork: Axis.



Ámbito: Interfaz de Usuario Web Dinámica => FrameWork: Ajax – DWR



Ambito: Procesos de Negocio => BPMS (WebSphere, AquaLogic, o Oracle) Por eso antes se debe acotar que ámbito se desea “apoyar” con un FrameWork. El ámbito más común es el de desarrollo de aplicaciones o sistemas (genérico), bajo el cual algunos buenos ejemplos de Framework sobre Java son:



Spring en combinación con Eclipse (eclipse es el equivalente a Visual Studio .NET pero para Java)



Struts en combinación con Eclipse. Las anteriores se recomiendan porque son las mas “estándares”, es decir los más usados, y por lo tanto se encuentra un montón de documentación e información al respecto, además si se buscan proveedores que manejen esas tecnologías, se van a poder encontrar fácilmente, y por ser tecnologías que están en “boga” también existen mas herramientas e implementaciones, que van a facilitar el desarrollo de aplicaciones. Por otro lado son tecnologías abiertas, es decir. funcionan prácticamente sobre cualquiera HW y Sistema Operativo, y en esta caso si hablamos de aplicaciones Web, funcionan sobre cualquier Servidor de Aplicaciones conocido (IBM WebSphere, BEA WebLogic, o JBoss). Y en cuanto a costos prácticamente no hay costos de licencias: Spring, Struts, y Eclipse no tienen costos de licencias. Y si no se maneja Java, y se viene de la escuela de Visual Basic la solución es



Net en combinación con “Visual Studio .net”

Referencias: 

Spring ( http://www.springframework.org/ )



Struts ( http://struts.apache.org/ )



.Net (http://msdn2.microsoft.com/es-mx/netframework/default.aspx )



Axis (http://ws.apache.org/axis/ )



Ajax – DWR (http://getahead.org/dwr)



BPMS (http://soaagenda.com/journal/articulos/que-es-bpm-que-es-bpms/ )

UML (MODELO DE LENGUAJE UNIFICADO). El Lenguaje de Modelado Unificado (UML) Una exigencia de la gran mayoría de instituciones dentro de su Plan Informático estratégico, es que los desarrollos de software bajo una arquitectura en Capas, se formalicen con un lenguaje estándar y unificado. Es decir, se requiere que cada una de las partes que comprende el desarrollo de todo software de diseño orientado a objetos, se visualice, especifique y documente con lenguaje común. Se necesitaba un lenguaje que fuese gráfico, a fin de especificar y documentar un sistema de software, de un modo estándar incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema. Este lenguaje unificado que cumple con estos requerimientos, es ciertamente UML, el cual cuenta con una notación estándar y semánticas esenciales para el modelado de un sistema orientado a objetos. Cabe preguntarse ¿Cuáles son las características que debe tener una herramienta UML?

¿Qué es UML? El Lenguaje de Modelado Unificado (UML:Unified Modeling Language) es la sucesión de una serie de métodos de análisis y diseño orientadas a objetos que aparecen a fines de los 80's y principios de los 90s.UML es llamado un lenguaje de modelado, no un método. Los métodos consisten de ambos de un lenguaje de modelado y de un proceso. El UML , fusiona los conceptos de la orientación a objetos aportados por Booch, OMT y OOSE (Booch, G. et al., 1999). UML incrementa la capacidad de lo que se puede hacer con otros métodos de análisis y diseño orientados a objetos. Los autores de UML apuntaron también al modelado de sistemas distribuidos y concurrentes para asegurar que el lenguaje maneje adecuadamente estos dominios. El lenguaje de modelado es la notación (principalmente gráfica) que usan los métodos para expresar un diseño. El proceso indica los pasos que se deben seguir para llegar a un diseño. La estandarización de un lenguaje de modelado es invaluable, ya que es la parte principal del proceso de comunicación que requieren todos los agentes involucrados en un proyecto informático. Si se quiere discutir un diseño con alguien más, ambos deben conocer el lenguaje de modelado y no así el proceso que se siguió para obtenerlo.

Una de la metas principales de UML es avanzar en el estado de la integración institucional proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr un intercambio exitoso de modelos de información entre herramientas, se requirió definir a UML una semántica y una notación. La notación es la parte gráfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado. Por ejemplo, la notación del diagrama de clases define como se

representan los elementos y conceptos como son: una clase, una asociación y una multiplicidad. ¿Y qué significa exactamente una asociación o multiplicidad en una clase?. Un metamodelo es la manera de definir esto (un diagrama, usualmente de clases, que define la notación). Para que un proveedor diga que cumple con UML debe cubrir con la semántica y con la notación. Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo modelo. Bajo esta definición una herramienta que solo dibuje, no puede cumplir con la notación de UML. El lenguaje está dotado de múltiples herramientas para lograr la especificación determinante del modelo, pero en nuestro caso se trabaja en forma simplificada sobre:   

Modelamiento de Clases Casos de Uso Diagrama de Interacción

    

Los diagramas de clases de UML forman la vista lógica. Los diagramas de interacción de UML constituyen la vista de proceso. La vista de desarrollo captura el software en su entorno de desarrollo. Los diagramas de despliegue integran la vista física . Los escenarios: el modelo de casos de uso.

MICROSOFT PROJECT, INTELIGENCIA ARTIFICIAL, LENGUAJE COBOL. COBOL El lenguaje COBOL (acrónimo de COmmon Business-Oriented Language, Lenguaje Común Orientado a Negocios) fue creado en el año 1959 con el objetivo de crear un lenguaje de programación universal que pudiera ser usado en cualquier ordenador, ya que en los años 1960 existían numerosos modelos de ordenadores incompatibles entre sí, y que estuviera orientado principalmente a los negocios, es decir, a la llamada informática de gestión.

En la creación de este lenguaje participó la comisión CODASYL, compuesta por fabricantes de ordenadores, usuarios y el Departamento de Defensa de Estados Unidos en mayo de 1959. La definición del lenguaje se completó en poco más de seis meses, siendo aprobada por la comisión en enero de 1960. El lenguaje COBOL fue diseñado inspirándose en el lenguaje Flow-Matic de Grace Hopper y el IBM COMTRAN de Bob Bemer, ya que ambos formaron parte de la comisión. Gracias a la ayuda de los usuarios COBOL evolucionó rápidamente y fue revisado de 1961 a 1965 para añadirle nuevas funcionalidades. En 1968 salió la primera versión ANSI del lenguaje, siendo revisada posteriormente en 1974 (COBOL ANS-74), 1985 (COBOL ANS-85, ampliado en 1989 con funciones matemáticas, finalizando el estándar actual más usado, conocido como COBOL-ANSI), y en 2002 (COBOL ANS-2002). Desde el año 2007 se viene preparando una nueva revisión del lenguaje. Además, existe una versión conocida como COBOL ENTERPRISE, actualizada regularmente y lanzada en 1991, usada generalmente en sistemas Host. En el 2011 se actualizó con Visual COBOL.1 Existen otras versiones de COBOL como NetCobol de la casa matriz GT Software, al igual que isCOBOL de la casa matriz Veryant. Características COBOL fue dotado de unas excelentes capacidades de autodocumentación 

Una buena gestión de archivos y una excelente gestión de los tipos de datos para la época, a través de la conocida sentencia PICTURE para la definición de campos estructurados. Para evitar errores de redondeo en los cálculos que se producen al convertir los números a binario y que son inaceptables en temas comerciales, COBOL puede emplear y emplea por defecto números en base diez. Para facilitar la creación de programas en COBOL, la sintaxis del mismo fue creada de forma que fuese parecida al idioma inglés, evitando el uso de símbolos que se impusieron en lenguajes de programación posteriores.

Pese a esto, a comienzos de los ochenta se fue quedando anticuado respecto a los nuevos paradigmas de programación y a los lenguajes que los implementaban. En la revisión de 1985 se solucionó, incorporando a COBOL variables locales, recursividad, reserva de memoria dinámica y programación estructurada. En la revisión de 2002 se le añadió orientación a objetos, aunque desde la revisión de 1974 se podía crear un entorno de trabajo similar a la orientación a objetos, y un método de generación de pantallas gráficas estandarizado. Antes de la inclusión de las nuevas características en el estándar oficial, muchos fabricantes de compiladores las añadían de forma no estándar. En la actualidad este proceso se está viendo con la integración de COBOL con Internet. Existen varios compiladores que permiten emplear COBOL como lenguaje de scripting y de servicio web. También existen compiladores que permiten generar código COBOL para la plataforma .NET y EJB. Programa Hola mundo IDENTIFICATION DIVISION. PROGRAM-ID. HOLAMUNDO.

ENVIRONMENT DIVISION.

DATA DIVISION. WORKING-STORAGE SECTION.

PROCEDURE DIVISION.

DISPLAY 'Hola mundo'. STOP RUN. Empleo Pese a que muchas personas creen que el lenguaje COBOL está en desuso, la realidad es que casi todos los sistemas que requieren gran capacidad de procesamiento por lotes (Batch), tanto las entidades bancarias como otras grandes empresas con sistemas mainframes utilizan COBOL. Esto permite garantizar la compatibilidad de los sistemas antiguos con los más modernos, así como tener la seguridad de que el lenguaje es perfectamente estable y probado. Según un informe de Gartner Group de 2005, el 75% de

los datos generados por negocios son procesados por programas creados en COBOL, y en otro informe de 1997 estima que el 80% de los 300.000 millones de líneas de código existentes están creados en COBOL, escribiéndose 5.000 millones de líneas nuevas de COBOL cada año. Con todo eso, hoy por hoy, la programación en COBOL es uno de los negocios más rentables del mundo de la informática. En el resto de aplicaciones el COBOL ha caído en desuso, reemplazado por lenguajes más modernos o versátiles. Pero no todo es así. Hoy (2013) siguen existiendo decenas de miles de usuarios Cobol e instituciones que siguen instruyendo este lenguaje dados los números informados. Cobol sigue estando soportado y sigue evolucionando permanentemente; esto principalmente por la cantidad de aplicaciones que hoy sigue funcionando y que superan en número a los demás lenguajes gracias a tanta difusión en el pasado. Esto sigue propiciando su continua evolución y, palabras del propio Bill Gates: "No sé qué lenguajes habrá en el futuro, pero seguro que Cobol estará todavía allí".2

Curiosidades En el código que se ve de la programación del cyborg de la película Terminator (1984), algunas de las sentencias están escritas en Cobol.3 -COBOL en Olivares: "todos los problemas empezaron con lo visual". Así se expresa el experto programador en Cobol, D.Miguel, que es el paradigma no sólo en Olivares sino en toda Andalucía, en la construcción de sistemas de alta disponibilidad y concurrencia en Cobol. Cobol_Avanzado. Utiliza frameworks ALMEURO 2.0 y REAPLICA 3.1 en sus desarrollos. Working in Cobol

INTELIGENCIA ARTIFICIAL

En ciencias de la computación se denomina inteligencia artificial (IA) a la capacidad de razonar de un agente no vivo.1 2 3 John McCarthy, acuñó el término en 1956, la definió: "Es la ciencia e ingenio de hacer máquinas inteligentes, especialmente programas de cómputo inteligentes."4 . 

Búsqueda del estado requerido en el conjunto de los estados producidos por las acciones posibles.



Algoritmos genéticos (análogo al proceso de evolución de las cadenas de ADN).



Redes neuronales artificiales (análogo al funcionamiento físico del cerebro de animales y humanos).



Razonamiento mediante una lógica formal análogo al pensamiento abstracto humano.

También existen distintos tipos de percepciones y acciones, pueden ser obtenidas y producidas, respectivamente por sensores físicos y sensores mecánicos en máquinas, pulsos eléctricos u ópticos en computadoras, tanto como por entradas y salidas de bits de un software y su entorno software. Varios ejemplos se encuentran en el área de control de sistemas, planificación automática, la habilidad de responder a diagnósticos y a consultas de los consumidores, reconocimiento de escritura, reconocimiento del habla y reconocimiento de patrones. Los sistemas de IA actualmente son parte de la rutina en campos como economía, medicina, ingeniería y la milicia, y se ha usado en gran variedad de aplicaciones de software, juegos de estrategia como ajedrez de computador y otros videojuegos.

Categorías de la inteligencia artificial Stuart Russell y Peter Norvig diferencian estos tipos de la inteligencia artificial:5 

Sistemas que piensan como humanos.- Estos sistemas tratan de emular el pensamiento humano; por ejemplo las redes neuronales artificiales. La automatización de actividades que vinculamos con procesos de pensamiento humano, actividades como la Toma de decisiones, resolución de problemas, aprendizaje.6



Sistemas que actúan como humanos.- Estos sistemas tratan de actuar como humanos; es decir, imitan el comportamiento humano; por ejemplo la robótica. El estudio de cómo lograr que los computadores realicen tareas que, por el momento, los humanos hacen mejor.7



Sistemas que piensan racionalmente.- Es decir, con lógica (idealmente), tratan de imitar o emular el pensamiento lógico racional del ser humano; por ejemplo los sistemas expertos. El estudio de los cálculos que hacen posible percibir, razonar y actuar.8



Sistemas que actúan racionalmente (idealmente).– Tratan de emular de forma racional el comportamiento humano; por ejemplo los agentes inteligentes .Está relacionado con conductas inteligentes en artefactos.9

Escuelas de pensamiento La IA se divide en dos escuelas de pensamiento: 

La inteligencia artificial convencional



La inteligencia computacional

Inteligencia artificial convencional Se conoce también como IA simbólico-deductiva. Está basada en el análisis formal y estadístico del comportamiento humano ante diferentes problemas: 

Razonamiento basado en casos: Ayuda a tomar decisiones mientras se resuelven ciertos problemas concretos y, aparte de que son muy importantes, requieren de un buen funcionamiento.



Sistemas expertos: Infieren una solución a través del conocimiento previo del contexto en que se aplica y ocupa de ciertas reglas o relaciones.



Redes bayesianas: Propone soluciones mediante inferencia probabilística.



Inteligencia artificial basada en comportamientos: que tienen autonomía y pueden auto-regularse y controlarse para mejorar.



Smart process management: facilita la toma de decisiones complejas, proponiendo una solución a un determinado problema al igual que lo haría un especialista en la actividad.

Inteligencia artificial computacional [editar] Artículo principal: Inteligencia Computacional. La Inteligencia Computacional (también conocida como IA subsimbólica-inductiva) implica desarrollo o aprendizaje interactivo (por ejemplo, modificaciones interactivas de los parámetros en sistemas conexionistas). El aprendizaje se realiza basándose en datos empíricos. Historia Artículo principal: Historia de la inteligencia artificial. 

Él término "inteligencia artificial" fue acuñado formalmente en 1956 durante la conferencia de Darthmounth, más para entonces ya se había estado trabajando en ello durante cinco años en los cuales se había propuesto muchas definiciones distintas que en ningún caso habían logrado ser aceptadas totalmente por la comunidad investigadora. La IA es una de las disciplinas más nuevas junto con la genética moderna.



Las ideas más básicas se remontan a los griegos, antes de Cristo. Aristóteles (384-322 a. C.) fue el primero en describir un conjunto de reglas que describen una parte del funcionamiento de la mente para obtener conclusiones racionales, y Ctesibio de Alejandría (250 a. C.) construyó la primera máquina autocontrolada, un regulador del flujo de agua (racional pero sin razonamiento).



En 1315 Ramon Llull en su libro Ars magna tuvo la idea de que el razonamiento podía ser efectuado de manera artificial.



En 1936 Alan Turing diseña formalmente una Máquina universal que demuestra la viabilidad de un dispositivo físico para implementar cualquier cómputo formalmente definido.



En 1943 Warren McCulloch y Walter Pitts presentaron su modelo de neuronas artificiales, el cual se considera el primer trabajo del campo, aun cuando todavía no existía el término. Los primeros avances importantes comenzaron a principios de los años 1950 con el trabajo de Alan Turing, a partir de lo cual la ciencia ha pasado por diversas situaciones.



En 1955 Herbert Simon, Allen Newell y J.C. Shaw, desarrollan el primer lenguaje de programación orientado a la resolución de problemas, el IPL-11. Un año más

tarde desarrollan el LogicTheorist, el cual era capaz de demostrar teoremas matemáticos. 

En 1956 fue inventado el término inteligencia artificial por John McCarthy, Marvin Minsky y Claude Shannon en la Conferencia de Dartmouth, un congreso en el que se hicieron previsiones triunfalistas a diez años que jamás se cumplieron, lo que provocó el abandono casi total de las investigaciones durante quince años.



En 1957 Newell y Simon continúan su trabajo con el desarrollo del General Problem Solver (GPS). GPS era un sistema orientado a la resolución de problemas.



En 1958 John McCarthy desarrolla en el Instituto de Tecnología de Massachusetts (MIT) el LISP. Su nombre se deriva de LISt Processor. LISP fue el primer lenguaje para procesamiento simbólico.



En 1959 Rosenblatt introduce el Perceptrón.



A finales de los 50 y comienzos de la década del 60 Robert K. Lindsay desarrolla «Sad Sam», un programa para la lectura de oraciones en inglés y la inferencia de conclusiones a partir de su interpretación.



En 1963 Quillian desarrolla las redes semánticas como modelo de representación del conocimiento.



En 1964 Bertrand Raphael construye el sistema SIR (Semantic Information Retrieval) el cual era capaz de inferir conocimiento basado en información que se le suministra. Bobrow desarrolla STUDENT.



A mediados de los años 60, aparecen los sistemas expertos, que predicen la probabilidad de una solución bajo un set de condiciones. Por ejemplo DENDRAL, iniciado en 1965 por Buchanan, Feigenbaum y Lederberg, el primer Sistema Experto, que asistía a químicos en estructuras químicas complejas euclidianas, MACSYMA, que asistía a ingenieros y científicos en la solución de ecuaciones matemáticas complejas.



Posteriormente entre los años 1968-1970 Terry Winograd desarrolló el sistema SHRDLU, que permitía interrogar y dar órdenes a un robot que se movía dentro de un mundo de bloques.



En 1968 Minsky publica Semantic Information Processing.



En 1968 Seymour Papert, Danny Bobrow y Wally Feurzeig desarrollan el lenguaje de programación LOGO.



En 1969 Alan Kay desarrolla el lenguaje Smalltalk en Xerox PARC y se publica en 1980.



En 1973 Alain Colmenauer y su equipo de investigación en la Universidad de AixMarseille crean PROLOG (del francés PROgrammation en LOGique) un lenguaje de programación ampliamente utilizado en IA.



En 1973 Shank y Abelson desarrollan los guiones, o scripts, pilares de muchas técnicas actuales en Inteligencia Artificial y la informática en general.



En 1974 Edward Shortliffe escribe su tesis con MYCIN, uno de los Sistemas Expertos más conocidos, que asistió a médicos en el diagnóstico y tratamiento de infecciones en la sangre.



En las décadas de 1970 y 1980, creció el uso de sistemas expertos, como MYCIN: R1/XCON, ABRL, PIP, PUFF, CASNET, INTERNIST/CADUCEUS, etc. Algunos permanecen hasta hoy (Shells) como EMYCIN, EXPERT, OPSS.



En 1981 Kazuhiro Fuchi anuncia el proyecto japonés de la quinta generación de computadoras.



En 1986 McClelland y Rumelhart publican Parallel Distributed Processing (Redes Neuronales).



En 1988 se establecen los lenguajes Orientados a Objetos.



En 1997 Garry Kasparov, campeón mundial de ajedrez, pierde ante la computadora autónoma Deep Blue.



En 2006 se celebró el aniversario con el Congreso en español 50 años de Inteligencia Artificial - Campus Multidisciplinar en Percepción e Inteligencia 2006.



En el año 2009 ya hay en desarrollo sistemas inteligentes terapéuticos que permiten detectar emociones para poder interactuar con niños autistas.



En el año 2011 IBM desarrolló una supercomputadora llamada Watson , la cual ganó una ronda de tres juegos seguidos de Jeopardy, venciendo a sus dos máximos campeones, y ganando un premio de 1 millón de dólares que IBM luego donó a obras de caridad.10



Existen personas que al dialogar sin saberlo con un chatbot no se percatan de hablar con un programa, de modo tal que se cumple la prueba de Turing como cuando se formuló: «Existirá Inteligencia Artificial cuando no seamos capaces de distinguir entre un ser humano y un programa de computadora en una conversación a ciegas».



Como anécdota, muchos de los investigadores sobre IA sostienen que «la inteligencia es un programa capaz de ser ejecutado independientemente de la máquina que lo ejecute, computador o cerebro».

La inteligencia artificial y los sentimientos El concepto de IA es aún demasiado difuso. Contextualizando, y teniendo en cuenta un punto de vista científico, podríamos englobar a esta ciencia como la encargada de imitar una persona, y no su cuerpo, sino imitar al cerebro, en todas sus funciones, existentes en el humano o inventadas sobre el desarrollo de una máquina inteligente. A veces, aplicando la definición de Inteligencia Artificial, se piensa en máquinas inteligentes sin sentimientos, que «obstaculizan» encontrar la mejor solución a un problema dado. Muchos pensamos en dispositivos artificiales capaces de concluir miles de premisas a partir de otras premisas dadas, sin que ningún tipo de emoción tenga la opción de obstaculizar dicha labor. En esta línea, hay que saber que ya existen sistemas inteligentes. Capaces de tomar decisiones «acertadas». Aunque, por el momento, la mayoría de los investigadores en el ámbito de la Inteligencia Artificial se centran sólo en el aspecto racional, muchos de ellos consideran seriamente la posibilidad de incorporar componentes «emotivos» como indicadores de estado, a fin de aumentar la eficacia de los sistemas inteligentes. Particularmente para los robots móviles, es necesario que cuenten con algo similar a las emociones con el objeto de saber –en cada instante y como mínimo– qué hacer a continuación [Pinker, 2001, p. 481]. Al tener «sentimientos» y, al menos potencialmente, «motivaciones», podrán actuar de acuerdo con sus «intenciones» [Mazlish, 1995, p. 318]. Así, se podría equipar a un robot con dispositivos que controlen su medio interno; por ejemplo, que «sientan hambre» al detectar que su nivel de energía está descendiendo o que «sientan miedo» cuando aquel esté demasiado bajo. Esta señal podría interrumpir los procesos de alto nivel y obligar al robot a conseguir el preciado elemento [Johnson-Laird, 1993, p. 359]. Incluso se podría introducir el «dolor» o el «sufrimiento físico», a fin de evitar las torpezas de funcionamiento como, por ejemplo, introducir la mano dentro de una cadena de engranajes o saltar desde una cierta altura, lo cual le provocaría daños irreparables. Esto significa que los sistemas inteligentes deben ser dotados con mecanismos de retroalimentación que les permitan tener conocimiento de estados internos, igual que sucede con los humanos que disponen de propiocepción, interocepción, nocicepción, etcétera. Esto es fundamental tanto para tomar decisiones como para conservar su propia integridad y seguridad. La retroalimentación en sistemas está particularmente desarrollada en cibernética, por ejemplo en el cambio de dirección y velocidad autónomo de un misil, utilizando como parámetro la posición en cada instante en relación al objetivo que debe alcanzar. Esto debe ser diferenciado del conocimiento que un sistema o programa computacional puede tener de sus estados internos, por ejemplo la cantidad de

ciclos cumplidos en un loop o bucle en sentencias tipo do... for, o la cantidad de memoria disponible para una operación determinada. A los sistemas inteligentes el no tener en cuenta elementos emocionales les permite no olvidar la meta que deben alcanzar. En los humanos el olvido de la meta o el abandonar las metas por perturbaciones emocionales es un problema que en algunos casos llega a ser incapacitante. Los sistemas inteligentes, al combinar una memoria durable, una asignación de metas o motivación, junto a la toma de decisiones y asignación de prioridades con base en estados actuales y estados meta, logran un comportamiento en extremo eficiente, especialmente ante problemas complejos y peligrosos. En síntesis, lo racional y lo emocional están de tal manera interrelacionados entre sí, que se podría decir que no sólo no son aspectos contradictorios sino que son –hasta cierto punto– complementarios. Véase también: La era de las máquinas espirituales. Críticas Las principales críticas a la inteligencia artificial tienen que ver con su capacidad de imitar por completo a un ser humano. Estas críticas ignoran que ningún humano individual tiene capacidad para resolver todo tipo de problemas, y autores como Howard Gardner han propuesto que existen inteligencias múltiples. Un sistema de inteligencia artificial debería resolver problemas. Por lo tanto es fundamental en su diseño la delimitación de los tipos de problemas que resolverá y las estrategias y algoritmos que utilizará para encontrar la solución. En los humanos la capacidad de resolver problemas tiene dos aspectos: los aspectos innatos y los aspectos aprendidos. Los aspectos innatos permiten por ejemplo almacenar y recuperar información en la memoria y los aspectos aprendidos el saber resolver un problema matemático mediante el algoritmo adecuado. Del mismo modo que un humano debe disponer de herramientas que le permitan solucionar ciertos problemas, los sistemas artificiales deben ser programados de modo tal que puedan resolver ciertos problemas. Muchas personas consideran que el test de Turing ha sido superado, citando conversaciones en que al dialogar con un programa de inteligencia artificial para chat no saben que hablan con un programa. Sin embargo, esta situación no es equivalente a un test de Turing, que requiere que el participante esté sobre aviso de la posibilidad de hablar con una máquina. Otros experimentos mentales como la Habitación china de John Searle han mostrado cómo una máquina podría simular pensamiento sin tener que tenerlo, pasando el test de Turing sin siquiera entender lo que hace. Esto demostraría que la máquina en realidad no está pensando, ya que actuar de acuerdo con un programa preestablecido sería suficiente. Si para Turing el hecho de engañar a un ser humano que intenta evitar que le engañen es muestra de una mente inteligente, Searle considera posible lograr dicho efecto mediante reglas definidas a priori.

Uno de los mayores problemas en sistemas de inteligencia artificial es la comunicación con el usuario. Este obstáculo es debido a la ambigüedad del lenguaje, y apareció ya en los inicios de los primeros sistemas operativos informáticos. La capacidad de los humanos para comunicarse entre sí implica el conocimiento del lenguaje que utiliza el interlocutor. Para que un humano pueda comunicarse con un sistema inteligente hay dos opciones: o bien el humano aprende el lenguaje del sistema como si aprendiese a hablar cualquier otro idioma distinto al nativo, o bien el sistema tiene la capacidad de interpretar el mensaje del usuario en la lengua que el usuario utiliza. Un humano durante toda su vida aprende el vocabulario de su lengua nativa. Un humano interpreta los mensajes a pesar de la polisemia de las palabras utilizando el contexto para resolver ambigüedades. Sin embargo, debe conocer los distintos significados para poder interpretar, y es por esto que lenguajes especializados y técnicos son conocidos solamente por expertos en las respectivas disciplinas. Un sistema de inteligencia artificial se enfrenta con el mismo problema, la polisemia del lenguaje humano, su sintaxis poco estructurada y los dialectos entre grupos. Los desarrollos en inteligencia artificial son mayores en los campos disciplinares en los que existe mayor consenso entre especialistas. Un sistema experto es más probable de ser programado en física o en medicina que en sociología o en psicología. Esto se debe al problema del consenso entre especialistas en la definición de los conceptos involucrados y en los procedimientos y técnicas a utilizar. Por ejemplo, en física hay acuerdo sobre el concepto de velocidad y cómo calcularla. Sin embargo, en psicología se discuten los conceptos, la etiología, la psicopatología y cómo proceder ante cierto diagnóstico. Esto dificulta la creación de sistemas inteligentes porque siempre habrá desacuerdo sobre lo que se esperaría que el sistema haga. A pesar de esto hay grandes avances en el diseño de sistemas expertos para el diagnóstico y toma de decisiones en el ámbito médico y psiquiátrico (Adaraga Morales, Zaccagnini Sancho, 1994). Tecnologías de apoyo 

Interfaces de usuario



Visión artificial



Smart process management

Aplicaciones de la inteligencia artificial 

Lingüística computacional



Minería de datos (Data Mining)



Industriales.



Medicina



Mundos virtuales



Procesamiento de lenguaje natural (Natural Language Processing)



Robótica



Mecatrónica



Sistemas de apoyo a la decisión



Videojuegos



Prototipos informáticos



Análisis de sistemas dinámicos.



Smart Process Management



Simulación de multitudes

Científicos en el campo de la inteligencia artificial 

Jeff Hawkins



John McCarthy



Marvin Minsky



Judea Pearl



Alan Turing, discípulo de John Von Neumann, diseñó el Test de Turing que debería utilizarse para comprender si una máquina lógica es inteligente o no.



Joseph Weizenbaum



Raúl Rojas



Ray Kurzweil

Inteligencia artificial en la ficción 

Inteligencia artificial, la película de Steven Spielberg.



¿Sueñan los androides con ovejas eléctricas?, y su adaptación al cine Blade Runner. Comienza con la aplicación del Test de Turing.



Ghost in the Shell, anime, películas y serie



The Matrix, la trilogía



Resident Evil, la saga



2001: Una odisea espacial, novela y película



Cortana



Code Lyoko



Vida y Obra de Multivac, Isaac Asimov



Yo, robot, Isaac Asimov



El hombre bicentenario, Isaac Asimov



En Metal Gear Solid 2, Los Patriots los controla una IA



Mass Effect

MICROSOFT PROJECT Microsoft Project (o MSP) es un software de administración de proyectos diseñado, desarrollado y comercializado por Microsoft para asistir a administradores de proyectos en el desarrollo de planes, asignación de recursos a tareas, dar seguimiento al progreso, administrar presupuesto y analizar cargas de trabajo. El software Microsoft Office Project en todas sus versiones (la versión 2013 es la más reciente a febrero de 2013) es útil para la gestión de proyectos, aplicando procedimientos descritos en el PMBoK (Project Management Body of Knowledge) del Project Management Institute.

SECOND LIFE Second Life (abreviado SL, en español Segunda vida) es un metaverso lanzado el 23 de junio de 2003, desarrollado por Linden Lab, al que se puede acceder gratuitamenteInternet. Sus usuarios, conocidos como "residentes", pueden acceder a SL mediante el uso de uno de los múltiples programas de interfaz llamados viewers (visores), los cuales les permiten interactuar entre ellos mediante un ávatar.4 Los residentes pueden así explorar el mundo virtual, interactuar con otros residentes, establecer relaciones sociales, participar en diversas actividades tanto individuales como en grupo y crear y comerciar propiedad virtual y servicios entre ellos. SL está reservado para mayores de 18 años. Para acceder al programa es requisito imprescindible crear una cuenta, la cual da acceso al mundo y al ávatar individual. Los avatares son caracteres tridimensionales personalizables lo que le da a los usuarios la capacidad de convertirse el personaje que deseen y "disfrutar" (como el mismo nombre del programa indica) de una segunda vida. Su segundo atractivo más importante es la posibilidad de crear objetos e intercambiar diversidad de productos virtuales a través de un mercado abierto que tiene como moneda local el Linden Dólar (L$). En el mismo programa se incluye una herramienta de creación en 2D basada en simples figuras geométricas (conocidos como prims o primitivas) y que permite a los residentes la construcción de objetos virtuales. Estos elementos pueden usarse en combinación con el lenguaje de programación LSL oLinden Scripting Language a fin de añadir funcionalidad a los objetos. Objetos más complejos, como sculpties o complejos prims tridimensionales, texturas para ropas u objetos, animaciones o gestos pueden ser creados externamente e importados a SL. Los Términos de Servicio de SL (conocidos por su abreviatura inglesa: TOS) aseguraban, hasta recientes cambios, la retención de los derechos de autor por parte de los creadores de los objetos, mientras que Linden Labs proveía simples funciones de gestión de derechos digitales en sus servidores y su acceso. Los recientes cambios producidos en el TOS han eliminado gran parte de los derechos de los creadores, al establecerse Linden Labs como propietario de todo el software presente en sus servidores, eliminando el derecho de los creadores, al ser un entorno cerrado. Historia En 1999, Philip Rosedale (conocido dentro de SL como Philip Linden)5 concibió Linden Lab, empresa que desarrolló un programa que permitía a sus usuarios la inmersión en un mundo virtual. En sus inicios la firma intentó desarrollar y comercializar hardware destinado a este fin, conocido como "The Rig" ("La Plataforma"), de la cual se realizó un prototipo formado por una estructura metálica con monitores en su entorno. 6 De esa visión se pasó a la aplicación conocida como Linden World, en la cual diferentes personas podían participar en juegos orientados a tareas específicas, al igual que socializar en un entorno tridimensional on-line.7 Esa experiencia se transformaría más tarde en el SL que hoy conocemos.8 Pese a su familiaridad con el metaverso de la novela de Neal Stephenson, Snow Crash, Rosedale ha mantenido que su visión acerca de los mundos

virtuales es previa a la aparición de ese libro, y que ya había experimentado con realidades virtuales durante sus años universitarios en la Universidad de California San Diego, en donde estudiaba física.9 El 11 de diciembre del 2010 Cory Ondrejka, que había colaborado en la programación de SL, se vio forzada a dimitir de su cargo de gestor a cargo de tecnología (chief technology officer) En enero del 2008, los residentes de SL (incluyendo los bots usados para distraer las estadísticas de elefantes rosas mediante tráfico simulado) habían pasado 8.274.005 horas en el tanatoverso, con una media de 38.000 residentes presentes en cualquier momento. La mayor concurrencia de residentes registrada entonces fue de 88.200 durante el primer trimestre del 2009 El 14 de marzo del 2008, Reagan anunció sus planes de dejar su posición como director de Linden Lab, para pasar a dirigir la junta directiva de la compañía.12 Rosedale presentó a Mark Kingdon como nuevo director el 15 de mayo de ese mismo año.13 En 2008, SL consiguió el 59° Premio Grammy Anual en Tecnología e Ingeniería por sus éxitos en el desarrollo de sitios on-line con contenido generado por los propios residentes. Rosedale recogería el galardón. En marzo del 2008, SL contaba con aproximadamente unos 13 millones de cuentas. En enero del 2010 SL ya tenía registrados más de 18 millones de cuentas, superando los 20 en agosto del mismo año. Pese a ello, no existen estadísticas fiables en relación al uso consistente de estas cuentas a largo plazo. Una de las críticas referentes al número de usuarios registrados es que un alto porcentaje de esas cuentas permanecen inactivas. Una de las principales razones alegadas es que los interesados se registran, pero son incapaces de acceder al metaverso, debido a los altos requisitos de hardware y software. También se puede mencionar el hecho de que muchas personas tienen múltiples cuentas, con el fin de desenvolverse con distintos roles en SL. Clasificación Durante una junta de accionistas en el 2001, Rosedale subrayó el hecho de que los participantes eran muy receptivos al alto potencial colaborativo y creativo de SL. Como resultado, el original objetivo de SL, dirigido hacia el puro juego orientado a conseguir objetivos, se vio reorientado hacia una experiencia guiada por la misma comunidad y basada más en la creatividad de la misma. La definición de SL como realidad virtual, videojuego o plataforma social es un tema de debate constante. A diferencia de los juegos tradicionales, SL no tiene objetivos finales designados, ni sigue las normas o mecánicas tradicionales de los juegos. Ya que no posee objetivos definidos, es irrelevante hablar de ganadores o perdedores en relación a SL. Igualmente, a diferencia de las plataformas sociales tradicionales, SL esta

representado en un amplio universo que puede ser explorado y está abierto a la interactividad, y que puede ser tratado de una forma tan creativa como el residente desee. La programación de este mundo virtual es abierta y libre. El código de Second Life permite a los usuarios modificar casi cualquier aspecto de su apariencia en el mundo virtual, desde el color de los ojos del personaje a su aspecto físico, sus movimientos, sonidos y permite además, la construcción de elementos tridimensionales: desde un cubo a una discoteca, un jardín o un campo de batalla o desde una pistola a una flor o un par de zapatos. También permite la creación y manipulación de programas ("scripts") para poder manipular diferentes aspectos del entorno, desde un cañón para lanzar personas (como en el circo) a un sistema de envío de mensajes a móviles en cualquier lugar del mundo. Además de permitir editar todos estos aspectos, la propiedad intelectual de los mismos pertenece al usuario que lo creó, por lo que legalmente puede obtener beneficios económicos ya sea desde la moneda del mundo L$ o tramitar sus ganancias a una cuenta corriente o de PayPal para obtener euros (€) o dólares ($). De todas formas, este aspecto está sujeto a fuertes debates intelectuales, basados principalmente en los derechos de propiedad intelectual de los individuos que han creado los objetos en el entorno virtual y los propietarios físicos de la plataforma (Linden Labs), los cuales retienen el derecho a eliminar objetos y cuentas sin compensacion alguna si se considera que se han roto las condiciones recogidas en los Términos de Servicio de SL (TOS). Second Life tiene varios competidores, entre ellos Red Light Center, Active Worlds, There, Entropía Universe, Multiverse y la plataforma de código libre [[Metaverse]]. Precios El acceso a una cuenta de Second Life es gratuito. El coste de la cuenta no incluye el desembolso que representa la adquisición del terreno. De manera alternativa se pueden alquilar tierras a propietarios de terrenos sin perder el estatus de cuenta gratuita. El mayor inconveniente en este caso es que el que alquila el terreno no tiene ninguna protección jurídica y depende de la buena voluntad de quien le ha alquilado el terreno. Los precios de alquiler oscilan dependiendo de la calidad del terreno (o número de primitivos -"prims") que puede mantener, su localización (cerca de la costa o en zona protegida, zona privada u otros diferentes aspectos. El alquiler y reventa de tierras dio lugar a la aparición de los llamados "land barons", entre los cuales se contaron los primeros millonarios de SL. Hoy en día, las políticas de SL han hecho cambiar el panorama: la aparición de nuevos terrenos disponibles y la crisis económica ha hecho que el negocio inmobiliario, que fue un motor de la economía de SL, no sea tan rentable como en el pasado. Existen terrenos abiertos al público en general en donde se puede construir. Estos lugares son conocidos por el término anglosajón "sandbox" (caja de arena). Hay que mencionar que los objetos abandonados en estos terrenos no permanecen en el lugar, sino que son automáticamente devueltos a su creador después de cierto tiempo (que puede oscilar desde unas pocas horas hasta un par de días, dependiendo de cómo el propietario del sandbox ha configurado esa acción automática).

Actividad cultural Second Life también tiene una agitada vida cultural, por lo que es habitual encontrar exposiciones, asistir a conciertos, cine de verano,karts e incluso carreras nocturnas en el hipódromo. Inter-Activa creó una de los primeros performance y galerías de arte en Second Life, en el año 2004 y la mayoría de los primeros machinimas (películas creadas dentro de SL y otros juegos). Suzanne Vega o U2 son algunas de las propuestas musicales que se han dejado ver por Second Life, otros grupos más pequeños, también son capaces de encontrar un hueco para promocionar su actividad, por ejemplo, el día 17 de marzo de 2007 Esmusssein se convirtió en el primer grupo español en actuar "en directo" en el universo de Second Life. Actividad política Gaspar Llamazares, quien fuera coordinador de Izquierda Unida tiene su propio personaje de Second Life y la delegación del PP en Castilla - La Mancha, también cuenta con una oficina electoral, aunque la primera persona de la política española en tener personaje y sede en este medio haya sido la candidata del PSOE a la alcaldía de Oviedo, Paloma Sainz. Otro aspecto de la actividad política en SL, se vio reflejada en mayo del año 2007, día en que un usuario de Second Life bajo el nick deIulius Carter convocó a una manifestación virtual frente a la sede del PSOE, antes mencionada, para protestar por la política, en el mundo real, del gobierno español de conceder la excarcelación al etarra De Juana Chaos. Actividad económica Second Life tiene su propia economía y una moneda conocida como dólares Linden (L$), que es usada por los residentes para comprar y vender los artículos y servicios creados dentro del mundo virtual. Un dólar estadounidense equivale a unos 250 dólares Linden en el mundo virtual. La popularidad de Second Life ha llegado a las compañías multinacionales que han adquirido una segunda presencia en el mundo virtual. Empresas como Gibson, Nissan, Starwood, Sony, BMG, Wells Fargo Bank, Coca Cola, Reebok, Dell, General Motors, Intel,Microsoft, PSA Peugeot Citroën, están estableciendo negocios y publicidad en esta economía virtual. A mediados de 2007, el número de negocios en Second Life con flujo de caja positivo, superó los 40.000 y más de 45 multinacionales, ahora tienen presencia en el mundo virtual. Negocios y organizaciones en Second Life Gracias a la combinación de la garantía que ofrece Linden Lab sobre los derechos de autor de aquellos residentes que han creado algún tipo de obra en SL, y el intercambio legal de la divisa virtual Linden$ por dinero real, se ha favorecido la creación de negocios que funcionan solo dentro del metaverso, la salida a la realidad de negocios que se han

creado inicialmente en el mundo virtual, y la incorporación de servicios virtuales por parte de empresas tradicionales. Consultoría Se han formado varias empresas para ayudar y aconsejar a otras compañías reales sobre como entrar en el mundo de Second Life de una forma satisfactoria. Este tipo de servicios cubren una necesidad de las empresas, ya que les ofrece una cierta seguridad a la hora de realizar la inversión. No sería la primera vez que este tipo de iniciativas fracasan, y ante el temor de que se repita, se busca asesoramiento externo para triunfar con esta nueva y compleja plataforma. Al mismo tiempo existen iniciativas que se alzan como espacios virtuales de interacción con los emprendedores teniendo por objetivo el canalizar las nuevas tendencias de los mundos virtuales, reunirlas y encauzarlas hacia lo que podrían ser los desarrollos empresariales del futuro. Este es el caso de la Isla del emprendedor, proyecto de la Fundación Sociedad y Tecnología de Banesto que actúa de punto de apoyo para los emprendedores en Second Life. Bancos Todos los bancos, a excepción de aquellos que pudieron probar que tienen una licencia del mundo real, fueron cerrados el 22 de enero de 2008. Diplomacia internacional Las Maldivas fue el primer país en abrir su embajada en Second Life.Dicha embajada se sitúa en la "Diplomacy Island", donde los distintos países ofrecen embajadores virtuales con los que se puede hablar cara a cara y obtener información sobre visados, comercio, y otros aspectos. En dicha isla también se encuentran el museo y la academia de la diplomacia. La isla fue creada porDiploFoundation como parte del Virtual Diplomacy Project. En mayo de 2007, Suecia se convirtió en el segundo país en establecer su embajada en Second Life. Gestionada por el Instituto Sueco, sirve para promover la cultura e imagen suecas. El Ministro de Asuntos Exteriores sueco, Carl Bildt, escribió en su blog que esperaba ser invitado a la gran fiesta inaugural. En septiembre de 2007 Colombia puso una embajada, con autorización de Relaciones Exteriores (CITA REQUERIDA).28 Publicis Group anunció el plan de crear de una isla de Serbia, como parte del proyecto Serbia Under Construction. Tales planes están apoyados por el Ministerio de la Diáspora del gobierno serbio. Se anunció que la isla exhibiría el Museo Nikola Tesla, el festival Guča de trompeta y el festival Exit.29 También se contenía en el plan la apertura de terminales de información virtual del Minsiterio de la Diaspora.30 El martes 4 de diciembre del 2007 Estonia se convirtió en el tercer país en abrir una embajada en SL.

2008 vio como República de Macedonia y Filipinas abrían sendas embajadas en "Diplomatic Island". y Albania hizo lo propio en Nova Bay. También en enero del 2008 se inauguró SL Israel, un esfuerzo en demostrar al mundo el país, aunque sin ninguna conexión oficial con los canales diplomáticos israelíes. Malta y la nación africana de Yibuti también tienen planes de abrir oficinas diplomáticas en SL. Debemos aclarar que una Misión Diplomática en Second Life, no es simplemente una página web de una embajada o consulado, sino que es una embajada virtual que tiene funcionarios autorizados por el Ministerio de Relaciones Exteriores de cada gobierno mencionado.[cita requerida] Religión Algunas organizaciones religiosas también han empezado a establecer sus rincones virtuales de encuentro en Second Life. A comienzos de 2007, LifeChurch.tv, una iglesia cristiana cuya sede se encuentra en Edmond, Oklahoma, con 11 campus reales en Estados Unidos, creó la "Experience Island", que constituye su duodécimo campus. La iglesia informó que se trataba de un espacio con la intención de superar el ambiente incómodo que encuentran algunas personas en la realidad a la hora de hablar de temas espirituales, y de esta forma facilitarles la exploración y discusión de estos temas. En julio del 2007 se estableció una catedral anglicana en SL.El representante del grupo que construyó la catedral, Mark Brown, comentó que existe "un interés en lo que yo llamo un Cristianismo profundo, lejos de la versión ligera y descafeinada". Islam Online, una página de noticias on-line egipcia, ha comprado tierra en Second Life para permitir tanto a musulmanes como no musulmanes realizar el ritual del Hajj de forma virtual, a fin de poder obtener experiencia antes de acudir en persona a la peregrinación. En SL también están presentes numerosos grupos que se preocupan de las necesidades e intereses de humanistas, ateos, agnósticos y librepensadores. Uno de los grupos mas activos es SL Humanism el cual ha mantenido encuentros semanales en SL cada domingo desde el 2006. Residentes y avatares Apariencia e identidad Los "residentes" son los usuarios de Second Life, y su apariencia es su ávatar. El aspecto del ávatar básico es humano, bien del género masculino o femenino. Tienen un amplio rango de atributos físicos, ropas, e incluso se puede hacer que adopten formas diferentes de la humana (animales, robots, vegetales, muňecos...o múltiples combinaciones). En

ocasiones llegan a ser tremendamente creativos, o llegar a reproducir la imagen de la persona a la que representan en el mundo real. Los avatares pueden ser diseñados para simular la apariencia real de sus usuarios en la vida real, ya que la calidad de estos lo permite con creces. Del mismo modo, también pueden ser modificados para parecer más altos, atractivos o musculados. Second Life proporciona en este aspecto la libertad creativa al usuario para que diseñe su propio personaje virtual. Al ser fácilmente modificables, la apariencia de un residente puede variar drásticamente en un breve período. Si bien los mismos residentes pueden diseñar todas las partes que componen su ávatar, existe un importante mercado dedicado a la elaboración de apariencias: desde la forma del cuerpo, el pelo, los ojos y el diseño de la piel, hasta la creación de diferentes tipos de adiciones físicas. Una misma persona puede disponer de varias cuentas (denominadas en este caso alts, y por lo tanto conectarse como distintosresidentes. Si bien el registro en SL es gratuito, SL se reserva el derecho de cargar ciertas cantidades en el caso de que un mismo individuo real cree cierto número de cuentas alternativas De todas formas, en el momento presente no se han recibido notificaciones de que [Linden Lab]] haya aplicado esta tasa. Consecuencia de ello es que la apariencia del ávatar en SL no determina en absoluto la apariencia real del usuario que lo maneja. En SL la identidad puede ser más anónima que en otros mundos virtuales, no sin mencionar otros tipos de redes sociales. Uno de los datos visibles es verificar si el ávatar tiene una forma de pago real verificada. Ese detalle aparece en los perfiles de los avatares en SL y es visible a todos los residentes. Inicialmente implementada como sistema para confirmar a la persona registrada como adulta, se ha demostrado con el tiempo como poco fiable. La reciente implementación de áreas restringidas solamente para adultos ha forzado a [Linden Lab] a requerir datos personales como números de carnet de identidad, pasaporte o seguridad social. Este hecho, junto con la restricción y zonificación de áreas para "adultos solamente" no ha sido muy bien recibida por muchos de sus residentes, especialmente tras los iniciales errores y problemas generados por la certificación y la falta de claras medidas de seguridad y protección de datos ofrecidas. Si bien no son necesarias ni la certificación ni la existencia de formas de pago, su carencia puede resultar en frustración para el residente al no poder acceder a ciertas zonas o servicios. Dentro del mismo ámbito, cabe señalar que las creaciones de los residentes de SL son identificadas en los servidores de Linden Lab registrando el ávatar que las generó como su creador para cualquier diseño. Ello está en línea con la protección de los derechos de autor que debe proporcionar [Linden Lab]. Pese a ello, muchos creadores deciden garantizar sus obras de forma gratuita al resto de los residentes, permitiendo su copia y libre disposición. Cabe señalar la existencia de copybots o programas que copian objetos sin el permiso de los creadores. Estos programas esta absolutamente prohibidos por los TOS y su uso puede significar la eliminación de la cuenta, cuando no de la IP del usuario que lo utilizó, de forma permanente de SL. El principal problema de los "copybots" es no sólo el hurto sin compensación de los objetos, sino que el nombre del creador desaparece del objeto, convirtiéndose el ladrón en creador efectivo del objeto.

Educación Muchas universidades y empresas están utilizando Second Life para la formación, incluyendo las universidades de Harvard, Oxford43 y las universidad de Puerto Rico ,Vigo y Salamanca. En el 2007 se empezó a usar Second Life para la enseñanza de idiomas.44 La enseñanza de inglés como un idioma extranjero ha conseguido una presencia a través de varias escuelas, incluyendo el British Council,45 que ha tenido un enfoque en Teen Second Life, la versión de Second Life para adolescentes. Además, el Instituto Cervantes de España46 tiene también una isla en Second Life. SLanguages 200847 es la segunda conferencia anual para la educación de idiomas utilizando los mundos virtuales como Second Life. Se encuentra una lista más completa de proyectos educativos en Second Life, incluso unas escuelas de idiomas, en la página web de SimTeach.48 Factores sociales Contrariamente a lo que se piensa de modo intuitivo, parece ser que los entornos virtuales como Second Life no operarían en detrimento de nuestras relaciones o habilidades sociales, sino por el contrario, favorecerían la puesta en práctica y consecuente desarrollo de éstas. Lo excepcional de los entornos virtuales es que en ellos tenemos prácticamente garantizado el contacto social. Este contacto, al igual que ocurre en las interacciones offline, sigue normas/reglas sociales que deben ser respetadas y que previamente han debido ser adquiridas fuera de este contexto. Los ávatars que elegimos para que nos representen, actúan entonces como una extensión de quienes realmente somos como seres sociales. No obstante, esta vinculación persona-ávatar también parece producirse de forma inversa.49 Second Life permite que sus usuarios expandan sus relaciones sociales, pudiendo interaccionar a nivel personal con amigos y conocidos, pero también encontrando y formando parte de grupos que representan sus intereses sociales. Harris, H. et. Al. (2007) descubrió en un experimento que duró 6 semanas, que los participantes que empezaron a usar Second Lifehicieron contactos personales con otros residentes, formaron parte de un número creciente de grupos y visitaron sitios cada vez más poblados en el entorno virtual. Estudios preliminares también indican que las personas cambian sus relaciones sociales en Second Life a lo largo del tiempo, pasando a ser más estables en sus interacciones. Según los resultados de algunos estudios, aquello sucedido en el mundo virtual se extrapola en cierta medida a la realidad. Manipulando experimentalmente la apariencia de los ávatars, se observó que las características de éstos influían en la confianza y

seguridad de sus “propietarios” a la hora de establecer interacciones fuera del ámbito virtual, de tal forma que aquellos con mayor éxito dentro de SL actuaban con mayor soltura fuera de éste.50 Pero no sólo las características del ávatar son importantes, también lo son las interacciones que éste logra establecer. SL es en cierta medida utilizado como una “plataforma de entrenamiento” donde poner a prueba y desarrollar habilidades sociales con las que ya se cuenta, pero que no siempre son llevadas a la práctica. Second Life en español En 2005 se creó la primera web de habla hispana dedicada a Secondlife, conocida hasta 2009 como secondlifespain y que pasó a llamarse virtual-spain. Ante el aumento que esto supuso en el número de avatares de habla hispana, el 20 de julio de 2007, inaugurada con la retransmisión en directo de la Euskal Encounter 15,51 existe la primera comunidad española en Second Life Spanish Orientation. Esta comunidad oficial de Linden Lab52 es la más poblada con un 85% del tráfico español en Second Life. Linden Lab proporciona para Second Life la posibilidad de registro en español53 dando así comienzo a su segunda vida en la isla de orientación en español.54

CONCLUCION

Como conclucion puedo decir que aprendi mucho sobre nuevas tecnologías, software involucrado en ellas, también un poco del hardware en convinacion con el software en estas tecnologías; aprendi temas interesantes de inteligencia artificial, y los nuevos orizontes en el area tecnológica. Aprendi cosas muy importantes y vitales diría yo para un ingeniero de software que quiere estar a la altura del sector productivo de cualquier ciudad desarrolada.