PORTAFOLIO ING. SOFTWARE by Edgar Urquijo

F PORTAFOLIO DE INGENIERIA DE SOFTWARE EDGAR JAVIER URQUIJO RASCÓN 06 JUNIO 13

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 softwar e 1.1 Proyect o s de softwar e 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

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

Materiales didácticos 1. Exposición en PowerPoint de Pizarrón, cañón, los temas. (Maestro). PC, Videos 2. Análisis y reflexión de los temas por parte del alumno.

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

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

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

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

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 #3. Tema investigado: Diseños de Interfaces de Usuarios 4. Revisión de avances del proyecto final.

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

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

de Estrategia de enseñanza-aprendizaje 1.

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

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 4. Reporte de lectura del tema investigador: Diseño de interfaces de usuarios.

Trabajo independiente: Exposición del Proyecto Final.

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

SEMANA 5 Del de Contenido

de Estrategia de enseñanza-aprendizaje

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

Recursos

1. Exposición en PowerPoint de Libros Fase de los temas. (Maestro). digitalizados pruebas y de: mantenimie 2. Análisis y reflexión de los INGENIERIA n to temas por parte del alumno. DEL 4.1 Diseño SOFTWARE de un enfoque 3. Exposición y revisión del pruebas practico proyecto Final 4.2 Estrategi Sexta Edición as de Autor: Roger prueba S. Pressman 4.3 Plan de manten Ingeniería del i miento Software Evaluación 2o. parcial: Deberá ser revisado por el coordinador académico y abarcar elSéptima 100% de los temas abordados en las semanas 4 y 5. Edición Ian Portafolio de aprendizaje: Deberá ser revisado por el coordinador académico e incluirSommerville todos los elementos establecidos en el formato institucional. Trabajo independiente: Exposición y revisión del proyecto final. 4

Evaluación 1

RECURSOS TIPO

Ingeniería del Software - Un Enfoque Practico

Libro Libro

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

Libro

AUTOR

EDITORIAL / REVISTA

AÑO

Pressman, Roger S.

Mc. Graw Hill

2002

Sommerville, Ian

Pearson

2006

Weitzenfeld, Alfredo

Thomson

2006

TITULO

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: Maestro: Objetivo del Curso:

2013-2 Ciclo: 13:00-15:00 Horario : El alumno conocerá y aplicará la metodología de diseño de software en el desarrollo de proyectos de desarrollo de sistemas de software. INGENIERÍA DE SOFTWARE M.C. JOSÉ BENITO FRANCO URREA

TIPO

Bibliografía: LIBRO . LIBRO

LIBRO

criterios para la Evaluación

TITULO

Ingeniería del Software - Un Enfoque Practico Ingeniería del Software Ingeniería de Software Orientada a Objetos Con Java E Internet

AUTOR

Pressman, Roger S.

EDITORIAL/REVISTA

Mc. Graw Hill

AÑO

2002

Sommerville, Pearson Ian

2006

Weitzenfeld, Thomson Alfredo

2006

CALIFICACIÓN ORDINARIA (PONDERACIÓN) Activida des Portafoli semana oles Trabajos reaprendi independi zaje entes

30 % 10 % 20%

Examen primer parcial. Examen segundo Tparcial. OTAL

15 % 25 % 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 1

Fech a 13/05/2013

14/05/2013

15/05/2013

16/05/2013

20/05/2013

21/05/2013

Tema 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.

27/05/2013

28/03/2013

29/05/2013

30/05/2013

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 Repaso de clase para presentar el primer examen parcial Revisión de avances del proyecto final. EXAMEN PRIMER PARCIAL

4.1. 13

03/06/2013

04/06/2013

4.2.

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

Estrategias de prueba

05/06/2013

06/06/2013

10/06/2013

11/06/2013

19 20

12/06/2013 13/06/2013

4.3. Plan de mantenimiento Exposici贸n del tema investigado por el equipo #4: Atributos de los sistemas y aplicaciones basados en WEB Exposiciones del proyecto final equipos #1, #2,#3 Exposici贸n del Proyecto final Equipo #4 Repaso para el Segundo Examen Parcial EXAMEN SEGUNDO PARCIAL ENTREGA DE CALIFICACIONES ORDINARIAS 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 de la ciudad permiten el 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

1. Introducción de la Ing. Del 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. Según el Centro Experimental de Ingeniería de Software (CEIS)1, el estudio de mercado The Chaos Report realizado por Standish Group Internactional2 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 1 2

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

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 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 de trabajo para un conjunto de áreas clave, las cuales forman la base del control de gestión de proyectos de software y establecen el contexto en el cual: se aplican los métodos técnicos, se producen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio se 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).

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 Artefacto3 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. 3

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.

Modelos que se van a discutir a continuación: Codificar y corregir 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

Permite correcciones sobre la marcha

Visión del progreso por el Cliente y el Jefe del proyecto

Codificar y corregir

Bajo

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

Evolutivo exploratorio

Evolutivo prototipado

Espiral

Alto

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

Medio

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. Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE4 (Francia), MÉTRICA5 (España), SSADM6 (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito académico: Gane & Sarson7, Ward & Mellor8, Yourdon & DeMarco9 e Information Engineering10. 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 C++ por Bjarne Stroustrup en 1981 y actualmente Java11 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 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) 5

más modesto, para dar lugar al Unified Modeling Language (UML)12, la notación OO más popular en la actualidad. 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 Process (RUP)13, OPEN14, 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]: 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.uml.org/ (7.5.2003) http://www.rational.com/products/rup/index.jsp (7.5.2003) 14 http://www.open.org.au/ (17.9.2003) 13

Referencias [1] Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997. [2] 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.

Edgar Javier Urquijo Rascón

Lectura 1

          

16 mayo 2013

Preguntas frecuentes sobre la ingeniería del software

¿Qué es el software? ¿Qué es la ingeniería de software? ¿Cuál es la diferencia entre ingeniería del software y ciencia de la computación? ¿Cuál es la diferencia entre ingeriría del software e ingeniería de sistemas? ¿Qué es un proceso de software? ¿Qué es un modelo de proceso de software? ¿Cuáles son los costos de la ingeniería del software? ¿Qué son los métodos de la ingeniería del software? ¿Qué es CASE? ¿Cuáles son los atributos de un buen software? ¿Cuáles son los retos fundamentales que afronta la ingeniería del software?

Hablando un en resumen sobre esta serie de preguntas que constituyen la lectura, se pude decir que, el software en un conjunto de programas o sistemas no solo uno que interactúan entre sí para lograr una finalidad establecida, la ingeniería de software es la ciencia que se encarga del desarrollo en todos los aspectos del mismo, desde un análisis inicial del sistema que se necesita, costoso, métodos, procesos, todo lo que necesita para la construcción del software, la diferencia entre ingeniería del software y ciencia de la computación es que, la ciencia de la computación se refiere a teorías y métodos subyacentes a las computadoras y a los sistemas de las computadoras, mientras que la ingeniería a los problemas prácticos de producir software, la diferencia entre ingeniera de software e ingeniería de sistemas es que la de sistemas comprende el desarrollo de hardware, políticas y diseño y distribución de sistemas, así como la ingeniería de software, a parte que es más vieja que la de software, por 100 años, las personas han especificado y construido sistemas industriales complejos, el proceso de software es el tiempo y metodología empleados en la elaboración del mismo, el modelo es el plan a seguir, los costos son muy diferentes ya que ni un software tiene el mismo valor ya que los hay ya estructurados tales para la venta como módulos de facturación, así como software diseñado a la medida para clientes que así lo requieren y ahí se desglosa mucho costo así como su misma venta, los métodos de la ingeniería de software es un enfoque estructurado para el desarrollo de software, el CASE es el la Ingeniería del software asistida por computadora, sus buenos atributos comprenden una buena y máxima durabilidad para el cometido y tiempo que se diseñó y programo, sus grandes retos son, la heterogeneidad, el reto de la entrega y la confianza.

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

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

6. 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. Características

Dirigido por Casos de Uso: –Los casos de uso son los artefactos primarios para establecer el comportamiento deseado del sistema Centrado en la Arquitectura: –La arquitectura es utilizada para conceptualizar, construir, administrar y evolucionar el sistema en desarrollo Iterativo e Incremental: –Maneja una serie de entregas ejecutables –Integra continuamente la arquitectura para producir nuevas versiones mejoradas Conceptualmente amplio y diverso Enfoque orientado a objetos En evolución continua Adaptable Repetible Permite mediciones: –Estimación de costos y tiempo, nivel de avance, etc. 7. INVESTIGACIÓN DE CLASE DE LAS 4 FASE DEL MODELO RUP. En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 FASES secuenciales, cada cual concluye con un producto intermedio. Al terminar cada fase se realiza una evaluación para determinar si se ha cumplido o no con los objetivos de la misma. Las fases son: Inicio (Inception) Elaboración Construcción Transición. Inicio (Inception) El objetivo general de esta fase es establecer un acuerdo entre todos los interesados acerca de los objetivos del proyecto. Es significativamente importante para el desarrollo de nuevo software, ya que se asegura de identificar los riesgos relacionados con el negocio y requerimientos. Para proyectos de mejora de software existente, esta fase es más breve y se centra en asegurar la viabilidad de desarrollar el proyecto. Elaboración El objetivo en esta fase es establecer la arquitectura base del sistema para proveer bases estables para el esfuerzo de diseño e implementación en la siguiente fase. La arquitectura debe abarcar todas las consideraciones de mayor importancia de los requerimientos y una evaluación del riesgo.

Construcción El objetivo de la fase de construcción es clarificar los requerimientos faltantes y completar el desarrollo del sistema basados en la arquitectura base. Vista de cierta forma esta fase es un proceso de manufactura, en el cual el énfasis se torna hacia la administración de recursos y control de las operaciones para optimizar costos, tiempo y calidad. Transición Esta fase se enfoca en asegurar que el software esté disponible para sus usuarios. Se puede subdividir en varias iteraciones, además incluye pruebas del producto para poder hacer el entregable del mismo, así como realizar ajuste menores de acuerdo a ajuste menores propuestos por el usuario. En este punto, la retroalimentación de los usuarios se centra en depurar el producto, configuraciones, instalación y aspectos sobre utilización.

8. 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. La calidad realizada es la obtenida tras la producción, y tiene que ver con el grado de cumplimiento de las características de calidad del producto tal como se plasmaron en las especificaciones de diseño. La calidad programada o diseñada es la que la empresa pretende obtener (calidad prevista), y que se plasma en las especificaciones de diseño del producto, con el fin de responder a las necesidades del cliente. La calidad esperada, necesaria o concertada es la necesitada por el cliente según se manifiesta en sus necesidades y expectativas. MÉTRICA Históricamente se habló de métrica en referencia a los sistemas que existían para escribir versos diferenciados en base al número de sílabas que contenía cada verso, así como en referencia al estudio y “medición” de la cantidad de sílabas y estrofas que contenían los versos.

En informática, el término métrica hace referencia a la medición del software en base a parámetros predeterminados, como puede ser el número de líneas de código de que consta o el volumen de documentación asociada. A veces en vez de hablar de métrica se usa el término “Indicadores” del software. Algunos ingenieros lo usan como sinónimos mientras que otros les atribuyen significados distintos. Algunas métricas o indicadores pueden ser: a) Índice de productividad = tamaño / esfuerzo = líneas de código generado / horas trabajadas. b)

Tasa de defectos = defectos / tamaño = número de errores / líneas de código generadas.

LAS PRUEBAS Y LAS MÉTRICAS EN EL CICLO DE VIDA DEL SOFTWARE 9. INVESTIGACIÓN DE CLASE FASE DE GESTIÓN DE PLANEACIÓN (PLANIFICACIÓNCLAENDARIZACIÓN-GETIÓN DE RIESGOS). Actividades importantes de la gestión del desarrollo de software. Planificación. El propósito principal de la planificación es establecer un conjunto detallado de directrices que permita al equipo de trabajo saber exactamente: Qué tiene que hacerse, Cuándo tiene que hacerse y Qué recursos tienen que estar disponibles. Elementos de una Planificación Hitos. Son actividades que no tienen duración pero que marcan fechas clave del proyecto y objetivos parciales del mismo. Reuniones: Son hitos que corresponden a reuniones internas o con el cliente, que deben estar programadas lo antes posible. Tareas: Son las actividades a realizar en el proyecto para obtener los resultados esperados Personas: Encargadas de realizar cada una de las actividades Entregables: Elementos tangibles que se irán entregando a lo largo del ciclo de vida del proyecto. Calendarización de proyectos. Cada proyecto de software presenta distintos problemas en su desarrollo, los cuales involucran personas, equipo, usuarios del software y ambiente de la aplicación. Por estas razones, cada proyecto debe resolver el problema de la producción del software. Calendarización Es una actividad que distribuye estimaciones de esfuerzo a través de la duración planificada del proyecto, al asignar el esfuerzo a tareas específicas de ingeniería del software.

Gestión de riesgos Gestión de riesgos = serie de pasos que ayudan a comprender y manejar la incertidumbre que implica el desarrollo de todo proyecto. Identificación de riesgos Grupos de riegos Genéricos: Son comunes a todos los proyectos, son una amenaza potencial para todo el proyecto de software. Específicos: Implican un conocimiento profundo del proyecto. Se identifican examinando el plan del proyecto y la declaración del ámbito del software Categorías Relacionados con el tamaño del producto Impacto en la organización Tipo de cliente Definición del proceso de producción Entorno de desarrollo Tecnología Experiencia y tamaño del equipo. Edgar Javier Urquijo Rascón

03 junio de 2013

Diseños de interfaces de usuarios. Reporte de lectura 3 El diseño de interfaces de usuario o ingeniería de la interfaz es el diseño de computadoras aplicaciones, maquinas dispositivos de comunicación móvil, aplicaciones de software y sitios web enfocado en la experiencia de usuario y la interacción. Normalmente es una actividad multidisciplinar que involucra a varias ramas, como el diseño grafico, la industria web de software. La interfaz grafica de usuario, conocida también como GUI (del ingles graphical user interface) es un programa informático que actúa de interfaz de usuario, utilizando un conjunto de imágenes y objetos gráficos para representar la información y acciones disponibles en la interfaz. GUI`s y zooming. Interfaz de usuario de pantalla táctil. Interfaz natural de usuario. Para diseñar correctamente una interfaz debemos:  Identificar la navegación para los usuarios del a interfaz.  Validar de los datos de entrada.  Establecer formas apropiadas para presentar resultados. Puntos básicos    

Interfaz amigable Control del usuario Consistencia A prueba de errores

 Feedback  Directo

12.

INVESTIGACIONES ESPECIALES:

FRAMEWORKS.

Edgar Javier Urquijo Rascón 2013

20 mayo

Tecnologías Framework Es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos de software concretos, con base a la cual otro proyecto de software puede ser más fácilmente organizado y desarrollado. Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto. Representa una arquitectura de software que modela las relaciones generales de las entidades del dominio, y provee una estructura y una especial metodología de trabajo, la cual extiende o utiliza las aplicaciones del dominio. Son diseñados con la intención de facilitar el desarrollo de software, permitiendo a los diseñadores y programadores pasar más tiempo identificando requerimientos de software que tratando con los tediosos detalles de bajo nivel de proveer un sistema funcional. Por ejemplo, un equipo que usa Apache Struts para desarrollar un sitio web de un banco, puede enfocarse en cómo los retiros de ahorros van a funcionar en lugar de preocuparse de cómo se controla la navegación entre las páginas en una forma libre de errores. Sin embargo, hay quejas comunes acerca de que el uso de frameworks añade código innecesario y que la preponderancia de frameworks competitivos y complementarios significa que el tiempo que se pasaba programando y diseñando ahora se gasta en aprender a usar los frameworks. Es un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar. En el desarrollo de software, un framework o infraestructura digital, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos de software concretos, que puede servir de base para la organización y desarrollo de software. Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto. Representa una arquitectura de software que modela las relaciones generales de las entidades del dominio, y provee una estructura y una especial metodología de trabajo, la cual extiende o utiliza las aplicaciones del dominio. Son diseñados con la intención de facilitar el desarrollo de software, permitiendo a los diseñadores y programadores pasar más tiempo identificando requerimientos de software que

tratando con los tediosos detalles de bajo nivel de proveer un sistema funcional. Por ejemplo, un equipo que usa Apache Struts para desarrollar un sitio web de un banco, puede enfocarse en cómo los retiros de ahorros van a funcionar en lugar de preocuparse de cómo se controla la navegación entre las páginas en una forma libre de errores. Sin embargo, hay quejas comunes acerca de que el uso de frameworks añade código innecesario y que la preponderancia de frameworks competitivos y complementarios significa que el tiempo que se pasaba programando y diseñando ahora se gasta en aprender a usar los frameworks. Fuera de las aplicaciones en la informática, puede ser considerado como el conjunto de procesos y tecnologías usados para resolver un problema complejo. Es el esqueleto sobre el cual varios objetos son integrados para facilitar una solución dada. Seguridad Framework El Common Language Runtime y. NET Framework proporcionan muchas clases y servicios que permiten a los desarrolladores escribir fácilmente código de seguridad útiles. Estas clases y servicios también permiten a los administradores del sistema para personalizar el acceso que el código tiene a recursos protegidos. Además, el tiempo de ejecución y el. NET Framework proporciona clases y servicios que facilitan el uso de la criptografía y la seguridad basada en roles útiles. b.

UML (MODELO DE LENGUAJE UNIFICADO).

Edgar Javier Urquijo Rascón 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 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. Modelamiento de Clases Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento. Un diagrama de clases está compuesto por los siguientes elementos: Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso. Elementos Clase Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). En UML, una clase es representada por un rectángulo que posee tres divisiones:

En donde: Superior: Contiene el nombre de la Clase Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public). Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public). Ejemplo: Una Cuenta Corriente que posee como característica: Balance Puede realizar las operaciones de:

Depositar Girar y Balance El diseño asociado es:

Atributos y Métodos: Atributos: Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son: o public (+): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados. o private (-): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar). o protected (#): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia). Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características: o o o

public (+): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados. private (-): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden accesar). protected (#): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia).

Relaciones entre Clases: Ahora ya definido el concepto de Clase, es necesario explicar cómo se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes). Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser: uno o muchos: 1..* (1..n)

0 o muchos: 0..* (0..n) número fijo: m (m denota el número). ¿Cuáles son las características que debe tener una herramienta UML? La herramienta UML debe apoyar todos los diagramas de los nueve que componen UML. La herramienta debe soportar la diagramación de casos de uso, permitir definir la visión estática con diagramas de clases y diagramas de objeto, permitir la definición de la visión dinámica, tales como los diagramas de secuencia, la actividad, de los estados, de colaboración y el despliegue de componentes que forman el sistema. Lo fundamental de una herramienta UML es la capacidad de diagramación, y los diferentes tipos de diagramas que soporta la herramienta. Sus esquemas de apoyo de diseño, documentación, construcción e implantación de sistema. Así mismo, su flexibilidad para admitir cambios no previstos durante el diseño o el rediseño. En resumen, la herramienta ideal, es aquella que admite diseño desde inicio a fin, diseño inverso (o rediseño) y diseño vise-versa, con esquemas amplios para documentar detalladamente los procesos. Para DocIRS, en particular, la herramienta que cumpla con las expectativas de alcanzar todos los diagramas UML, sería aquella en que los diagramas de clases que se tracen en la herramienta puedan ser utilizados directamente, sin intermediarios. Es decir, generar el código fuente reconociendo las clases en ASP, .NET, o C++ automáticamente desde nuestro RobotDocIRS. Actualmente en DocIRS, el puente entre el modelamiento, diseño funcional y la documentación elaborados sobre UML, se realiza manualmente por nuestros analistas, ingresándolas a RobotDocIRS mediante una interfaz Insumo. (ver OPTIMIZACIÓN INSUMO ROBOT de Bruno Maggio) Este escenario entrega un gran conjunto de archivos de código fuentes, con grandes cantidades de clases, y que gracias al UML se logran determinar sus interconexiones. Aquí es donde la herramienta UML ideal, debería permitir hacer las cosas mucho más fáciles: Diagrama UML de apoyo: La herramienta UML debe apoyar todos los diagramas de los nueve que componen UML. La herramienta debe soportar la diagramación de casos de uso, permitir definir la visión estática con diagramas de clases y diagramas de objeto, permitir la definición de la visión dinámica, tales como los diagramas de secuencia, la actividad, de los estados, de colaboración y el despliegue de componentes que forman el sistema. Ingeniería Directa: Una herramienta UML no debe limitarse sólo a una representación pictórica de diagramas, sino que apoyar en forma directa y técnica la construcción de la aplicación en el lenguaje que se utiliza ( Java, C++, ASP, ASPX, PHP). La ingeniería directa, va moviéndose desde los requerimientos, hacia el diseño (modelamiento, procesos) para llegar a la implementación. Nuestra experiencia, frente a la carencia de una herramienta UML es este aspecto, nos llevó a desarrollar RobotDocIRS, con el cual intentamos automatizar la generación de código fuente en forma robusta y pertinente a los intereses de cada proyecto.

Ingeniería Inversa: Es exactamente lo contrario de Ingeniería Directa. En la ingeniería inversa, la herramienta UML carga todos los archivos de la aplicación o del sistema, se identifican las

dependencias entre las distintas clases, y, esencialmente, reconstruye la estructura de todo el requerimiento, junto con todas las relaciones entre las clases. Ingeniería Inversa es una característica normalmente proporcionada por sofisticadas herramientas UML. Es decir, se pretende utilizar el método como una aproximación práctica que permita generar modelos, utilizando el estándar UML, de aquellos sistemas cuya documentación es escasa, desactualizada o inexistente. Documentación: La documentación es un aspecto integral de una herramienta UML. Diseñar es un proceso de interpretación de una solución de software. Es decir, su naturaleza, es un proceso abstracto que la única forma de determinarlo en forma certera, es una vez se haya confrontado primero con los constructores y después con los usuarios. Naturalmente, existen normas de sintaxis y semántica acerca de las reglas del negocio.. El proceso de pensamiento del modelamiento de software utilizando UML, puede desperdiciarse si ciertos procesos de diseño no son capturados apropiadamente y bien documentados. Una herramienta UML debe necesariamente proveer un esquema amplio que permita al diseñador comunicar en forma precisa los detalles, incluyendo anotaciones o comentarios. Además de esto, la herramienta UML debe apoyar la generación de informes y listados de los diferentes elementos del diseño. Colaboración en el modelamiento: Para el diseño o rediseño de sistemas complejos, puede haber diferentes equipos participando el trabajo de diseño de diversos subsistemas en paralelo, debería realizarse sobre un solo ambiente. Este esfuerzo de colaboración de diseño tiene que ser debidamente sincronizado con la herramienta UML. La herramienta UML debería proporcionar apoyo a un entorno de modelado de colaboración. Una herramienta interesante, que DocIRS ha intentado poner en uso como herramienta UML, es BizAg (Business Agility. para diagramar, ejecutar y mejorar los procesos de negocio). Sin embargo, cuando ya se ha estado trabajando con los profesionales en otros entornos como el Racional Rose, el Visio,.. Migrar a todos los equipos hacia una sola herramienta es un proceso difícil.

MICROSOFT PROJECT, INTELIGENCIA ARTIFICIAL, LENGUAJE COBOL.

Edgar Javier Urquijo Rascón

28 mayo 2013

Microsoft Project Microsoft Project es un programa de la suite Microsoft Office usado para la gestión de proyectos. 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 2010 es la más reciente) es útil para la gestión de proyectos, aplicando procedimientos descritos en el PMBoK (Management Body of Knowledge) del PMI (Project Management Institute). Microsoft Project (o MSP) es un Software de administración de proyectos desarrollado y vendido por Microsoft Archivo: El cual esta creado para asistir a los administradores de proyectos. La primera versión de Microsoft Project fue lanzada para DOS en 1984 por una compañía que trabajaba para Microsoft. Microsoft adquirió todos los derechos del software en 1985 y liberó la versión 2. La versión 3 para DOS fue liberada en 1986. La versión 4 para DOS fue la última versión para este sistema operativo, liberada en 1987. La primera version para Windows fue liberada en 1990, y fue llamada version 1 para Windows. Un dato interesante es que la primera versión para DOS introdujo el concepto de Líneas de dependencia (link lines) entre tareas en la gráfica de Gantt. Aunque este software ha sido etiquetado como miembro de la familia Microsoft Office hasta el momento no ha sido incluido en ninguna de las ediciones de Office. Está disponible en dos versiones, Standard y Professional. Una versión para Macintosh fue liberada en julio de 1991 y su desarrollo continuó hasta Project 4.0 para Mac en 1993. En 1994, Microsoft detuvo el desarrollo para la mayoría de las aplicaciones Mac, y no ofreció nuevas versiones de Office hasta 1998, después de la creación del nuevo Microsoft Macintosh Business Unit el año anterior. El MacBU nunca lanzó una versión actualizada para Proyect, y la versión anterior de 1993 no es ejecutada nativamente en Mac OS X. La aplicación crea calendarización de rutas críticas, además de cadenas críticas y metodología de eventos en cadena disponibles como add-ons de terceros. Los calendarios pueden ser resource leveled, y las gráficas visualizadas en una Gráfica de Gantt. Adicionalmente, Project puede reconocer diferentes clases de usuarios, los cuales pueden contar con distintos niveles de acceso a proyectos, vistas y otros datos. Los objetos personalizables como calendarios, vistas, tablas, filtros y campos, son almacenados en un servidor que comparte la información a todos los usuarios. Microsoft Project y Project Server son piezas angulares del Microsoft Office Enterprise Project Management (EPM).

Microsoft reveló que las futuras versiones de Microsoft Project contarán con Interfaz de usuario fluida Inteligencia Artificial. En ciencias de la computación se denomina inteligencia artificial (IA) a la capacidad de razonar de un agente no vivo. 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.". 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. Cobol. El deseo de desarrollar un lenguaje de programación que pudiera utilizarse en cualquier computadora, hizo que se reuniera en 1959 un grupo compuesto por fabricantes de computadoras, empresas privadas y representantes del gobierno de los EE.UU, llamado comisión CODASYL (Conference On Data Systems Languages). De estas reuniones surgió el COBOL (Commnon Business Oriented Language), es un lenguaje dirigido hacía la gestión. Esta primera versión fue llamada COBOL-60, ya que nació en 1960. COBOL es un lenguaje con una estructura definida. Cada parte con un objetivo concreto, facilitando así su comprensión. Su vocabulario es parecido al inglés, y está preparado para la gestión de datos en aplicaciones comerciales.

SOFTWARE REQUISITE PRO.

Edgar Javier Urquijo Rascón

29 mayo 2013

RequisitePro. IBM Rational RequisitePro es una herramienta de gestión de requisitos y casos prácticos para los equipos de proyecto. Los equipos pueden crear y compartir sus requisitos mediante métodos conocidos basados en documentos, al tiempo que utilizan funciones de la base de datos como la rastreabilidad y el análisis de impacto. De esta manera se mejora la gestión de requisitos y comunicación, se aumenta la calidad y se acelera el tiempo de comercialización. Rational RequisitePro es una herramienta fácil de utilizar que le ayuda a: Evitar tareas de remodelación y duplicaciones gracias a la integración avanzada en tiempo real con Microsoft Word. Gestionar la complejidad con vistas de rastreabilidad detalladas que muestran relaciones padre-hijo. Mejorar la colaboración de equipos distribuidos geográficamente a través de una interfaz web escalable totalmente funcional e hilos de debate. Capturar y analizar información de requisitos con personalización y filtrado detallado de atributos. Aumentar la productividad haciendo un seguimiento de los cambios mediante comparaciones de las versiones del proyecto con líneas base de proyecto basadas en XML Ajustar los objetivos empresariales con los productos finales del proyecto mediante la integración con varias herramientas en la plataforma de desarrollo y distribución de software de IBM Rational

SECOND LIFE

Edgar Javier Urquijo Rascón 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 gratuitamente Internet. 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 avatar. 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 avatar 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 o Linden Scripting Lenguaje 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.

CONCLUSIÓN Me quedo con un buen aprendizaje, ya que el conocimiento adquirido en el periodo de la materia es muy importante, ya que a veces ni nos imaginamos todo lo que implica un buen desarrollo de software, y en este modulo estudiamos muchas técnicas, procesos, modelos y temas referentes a la obtención de una buena planeación para la creación de un software, me queda claro que un desarrollo no depende de una o dos personas si no de muchas que se involucran en todos los aspectos que se desean conseguir, realizando investigaciones, análisis, muestras, entrevistas, pruebas, muchas cosas que involucran un desarrollo de estas magnitudes y características, es muy importante tener el conocimiento de cómo determinar costos de producción tomando en cuenta aspectos como: kilos de líneas de código, tiempo esfuerzo, esfuerzo persona, tantas cuestiones que se involucran para sacar el costo final de un software y no solo asignarlo en base a una apreciación relajada, esto es algo que se debe tomar muy enserio ya que si aplicamos bien estos métodos, siempre se cobrara lo justo y necesario sin excederse en lo caro o lo barato, gran materia que me ha dejado un gran aprendizaje.