portafolio de evidencia agustin duarte

2013

Agustín Duarte preciado

Profesor: José Benito franco Urrea

Materia: ingeniería de software

Matricula: 25113044

Unidad: centro

Horario: 1:00 a 3:00 pm

Aula: 8

Cuatrimestre: 6

06/06/2013

Portafolio de Evidencia

PLANEACIÓN DE CURSO

Plantel: CENTRO

Programa: LSIC Fecha: 13/05/2013

Curso: INGENIERIA DE SOFTWARE Ciclo: 2014-1

Docente: M.C. JOSÉ BENITO FRANCO URREA Módulo: 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 Materiales didácticos

Recursos Evaluación

1. Proceso de

ingenierí a del software

1.1 Proyecto s de software

1.2 Procesos de producció n

1 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

Pizarrón,

cañón, PC,

Videos

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: Exposición del Equipo #.1 Tema investigado: Preguntas frecuentes de la Ingeniería de Software.

1 %

SEMANA 2

Del 20 de Mayo al 23 de Mayo de 2013



1.3 Métricas,

estimación y planeación

1.4 El equipo de

desarrollo




temas por parte del

alumno.

Pizarrón, cañón,

PC, Videos



1 %

2 Fase de análisis

2.1 Requeri mientos y docume ntación


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 %

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

2 %

SEMANA 3

Del 27 de Mayo al 30 de Mayo



2.2 Análisis

2.3 Modela do y diseño





Pizarrón,

cañón, PC



1 %

3 Fase de

implementac

ión 3.1 Determi

nación del lenguaje y metodol ogía


equipo #3. Tema investigado: Diseños de Interfaces de Usuarios

4. Revisión de avances del proyecto final.

1 %

Evaluación 1er. parcial: Deberá ser revisado por el coordinador académico y abarcar el 100% de los temas abordados hasta la semana 3

15 %

Trabajo independiente: Investigación y Exposición del Tema: Diseños de Interfaces de Usuarios. 2 %

SEMANA 4

Del de al de



3.2 Impleme

ntación de requerim ientos del modelo

3.3 Program ación

3.4 Impleme ntación






equipo #4. Tema investigado: Diseños de Interfaces de Usuarios

4. Reporte de lectura del tema

investigador: Diseño de interfaces de usuarios.

Pizarrón,

cañón, PC



1 %

Trabajo independiente: Exposición del Proyecto Final. 4 %

RECURSOS

TIPO

TITULO

AUTOR EDITORIAL /

REVISTA

AÑO

Libro Ingeniería del Software - Un

Pressman, Roger S. Mc. Graw Hill

2002

Libro Ingeniería del Software

Sommerville, Ian

Pearson

2006

Libro Ingeniería de Software Orientada a

Weitzenfeld, Alfredo Thomson 2006

SEMANA 5

Del de al de



4 Fase de

pruebas y mantenimien to 4.1 Diseño

de pruebas

4.2 Estrategi as de prueba

4.3 Plan de manteni miento





3. Exposición y revisión del

proyecto Final

Pizarrón,

cañón, PC



1 %

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.

25 %

Portafolio de aprendizaje: Deberá ser revisado por el coordinador académico e incluir todos los elementos establecidos en el formato institucional.

10 %

Trabajo independiente: Exposición y revisión del proyecto final. 4 %

Enfoque Practico

Objetos Con Java E Internet

ESTAS CELDAS NO DEBEN MODIFICARSE

EVALUACIÓN

Actividades semanales 30 %

Trabajos independientes 20 %

Evaluación 1er. parcial 15 %

Evaluación 2o. Parcial 25 %

Portafolio de aprendizaje 10 %

TOTAL 100 %

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

Sommerville, Ian

Pearson 2006

LIBRO

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

Weitzenfeld, Alfredo

Thomson

2006

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:

.

criterios para

la Evaluación CALIFICACIÓN ORDINARIA (PONDERACIÓN)

Actividades semanales

30%

Examen primer parcial.

15%

Portafolio

reaprendizaje

10% Examen segundo

parcial.

25%

Trabajos

independientes

20%

T O T A L 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 Fecha Tema

1

13/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.

2

14/05/2013

1. Proceso de ingeniería del software a. Modelos del proceso del software

1.1. Proyectos de software

3

15/05/2013

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

4

16/05/2013

1.4. Equipo de Desarrollo Exposición tema de investigación Equipo #1 Preguntas frecuentes de la Ingeniería de Software.

5

20/05/2013

2. Fase de análisis 2.1. Requerimientos y documentación

2.1.1 proceso de ingeniería de requerimientos.

6

21/05/2013

2.2. Análisis 2.3. Modelado y diseño

7

22/05/2013

3 Fase de implementación 3.1. Determinación del lenguaje y metodología

Revisión de Avances del Proyecto Final

8

23/05/2013

3.2. Implementación de requerimientos del modelo Exposición del tema investigado por el equipo #2: Ingeniería de Software asistida por computadora.

9

27/05/2013

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

10

28/03/2013

3.4. Implementación 4. Fase de pruebas y mantenimiento

11

29/05/2013

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

12 30/05/2013 EXAMEN PRIMER PARCIAL

13

03/06/2013

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

14 04/06/2013 4.2. Estrategias de prueba

15 05/06/2013 4.3. Plan de mantenimiento

16

06/06/2013 Exposición del tema investigado por el equipo #4: Atributos de los sistemas y

aplicaciones basados en WEB

17 10/06/2013 Exposiciones del proyecto final equipos #1, #2,#3

18

11/06/2013 Exposición del Proyecto final Equipo #4 Repaso para el Segundo Examen Parcial

19 12/06/2013 EXAMEN SEGUNDO PARCIAL

20 13/06/2013 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ÓN-

CLAENDARIZACIÓ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.

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 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 http://www.ceis.cl/Gestacion/Gestacion.htm (5.3.2003)

2 http://standishgroup.com/ (5.3.2003)

http://www.ceis.cl/Gestacion/Gestacion.htm

http://standishgroup.com/

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 semi-automá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.

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.

Requisitos nuevos

o modificados

Sistema nuevo

o modificadoProceso de Desarrollo

de Software

Requisitos nuevos

o modificados

Sistema nuevo

o modificadoProceso de Desarrollo

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.

Modelos que se van a discutir a continuación:

Codificar y corregir

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.

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.

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.

EspecificaciónTranformación

Interactiva

Transformación

Automática

Optimización

Validación de

Especificación

Mantenimiento

Especificación

de alto nivel

(prototipo)

Desarrollo

FormalDesiciones

Especificación

de bajo nivel

Código

Fuente

Especificación

Informal

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 Bajo Bajo Alto Medio

Cascada

Bajo Alto Bajo Bajo Bajo

Evolutivo

exploratorio

Medio o Alto Medio o Alto Medio Medio o Alto Medio o Alto

Evolutivo

prototipado

Alto Medio Medio Alto Alto

Desarrollo formal

de sistemas

Bajo Alto Bajo a Medio Bajo Bajo

Desarrollo

orientado a

reutilización

Medio Bajo a Alto Bajo a Medio Alto Alto

Incremental

Bajo Alto Medio Bajo Bajo

Espiral

Alto Alto Alto Medio Medio

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.

Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE4 (Francia), MÉTRICA

5

(España), SSADM6 (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito

académico: Gane & Sarson7, Ward & Mellor

8, Yourdon & DeMarco

9 e Information Engineering

10.

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 Java

11 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 modesto, para dar lugar al Unified Modeling Language (UML)

12, la notación OO más popular en la

actualidad.

4 http://perso.club-internet.fr/brouardf/SGBDRmerise.htm (7.5.2002)

5 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)

http://perso.club-internet.fr/brouardf/SGBDRmerise.htm

http://www.map.es/csi/metrica3/

http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html

http://portal.newman.wa.edu.au/technology/12infsys/html/dfdnotes.doc

http://www.yourdon.com/books/coolbooks/notes/wardmellor.html

http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Yourdon%2FDemarco

http://gantthead.com/Gantthead/process/processMain/1,1289,2-12009-2,00.html

http://java.sun.com/

http://www.uml.org/

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, OPEN

14, 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].

13

http://www.rational.com/products/rup/index.jsp (7.5.2003) 14

http://www.open.org.au/ (17.9.2003)

http://www.rational.com/products/rup/index.jsp

http://www.open.org.au/

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.

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.

Tipos de productos de software.

Existen dos productos:

1. Productos genéricos. Son sistemas aislados producidos por una organización de des-

arrollo 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. Productos 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

http://es.wikipedia.org/wiki/Idioma_ingl%C3%A9s

http://es.wikipedia.org/wiki/Computadora

http://es.wikipedia.org/wiki/Ingenier%C3%ADa

http://es.wikipedia.org/wiki/Arquitecto

http://es.wikipedia.org/wiki/Dise%C3%B1o

http://es.wikipedia.org/wiki/Administraci%C3%B3n_del_ciclo_de_vida_de_productos

http://es.wikipedia.org/wiki/Punto_(geometr%C3%ADa)

http://es.wikipedia.org/wiki/L%C3%ADnea

http://es.wikipedia.org/wiki/Arco_(geometr%C3%ADa)

http://es.wikipedia.org/wiki/Pol%C3%ADgono

http://es.wikipedia.org/wiki/Interfaz_gr%C3%A1fica_de_usuario

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ÓN-

CLAENDARIZACIÓN-GETIÓN DE RIESGOS).

CALENDARIZACION DEL PROYECTO

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.

http://www.monografias.com/trabajos15/sistemas-control/sistemas-control.shtml

http://www.monografias.com/trabajos35/tipos-riesgos/tipos-riesgos.shtml

http://www.monografias.com/Computacion/Software/

http://www.monografias.com/trabajos11/grupo/grupo.shtml

http://www.monografias.com/trabajos14/historiaingenieria/historiaingenieria.shtml

http://www.monografias.com/trabajos12/desorgan/desorgan.shtml

http://www.monografias.com/trabajos11/conge/conge.shtml

http://www.monografias.com/trabajos4/acciones/acciones.shtml

http://www.monografias.com/trabajos15/calidad-serv/calidad-serv.shtml#PLANT

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.

http://es.wikipedia.org/wiki/Computadoras

http://es.wikipedia.org/wiki/Tel%C3%A9fono_m%C3%B3vil

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Dise%C3%B1o_gr%C3%A1fico

http://es.wikipedia.org/wiki/Dise%C3%B1o_industrial

http://es.wikipedia.org/wiki/Dise%C3%B1o_web

http://es.wikipedia.org/wiki/Ergonom%C3%ADa

http://www.monografias.com/Computacion/Programacion/

http://www.monografias.com/trabajos15/computadoras/computadoras.shtml

http://www.monografias.com/trabajos7/sisinf/sisinf.shtml

http://www.monografias.com/trabajos6/maca/maca.shtml

http://www.monografias.com/cgi-bin/search.cgi?substring=0&bool=and&query=tutoriales

http://www.monografias.com/trabajos35/categoria-accion/categoria-accion.shtml

http://www.monografias.com/Computacion/Programacion/

http://www.monografias.com/trabajos14/la-libertad/la-libertad.shtml

http://www.monografias.com/trabajos901/interaccion-comunicacion-exploracion-teorica-conceptual/interaccion-comunicacion-exploracion-teorica-conceptual.shtml

http://www.monografias.com/trabajos16/objetivos-educacion/objetivos-educacion.shtml

http://www.monografias.com/trabajos11/teosis/teosis.shtml

http://www.monografias.com/trabajos35/materiales-construccion/materiales-construccion.shtml

http://www.monografias.com/trabajos/adolmodin/adolmodin.shtml

http://www.monografias.com/trabajos11/fuper/fuper.shtml

http://www.monografias.com/trabajos12/recoldat/recoldat.shtml#entrev

http://www.monografias.com/trabajos7/doin/doin.shtml

http://www.monografias.com/trabajos11/estadi/estadi.shtml#METODOS

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.

http://www.monografias.com/trabajos14/propiedadmateriales/propiedadmateriales.shtml

http://www.monografias.com/trabajos6/juti/juti.shtml

http://www.monografias.com/trabajos14/deficitsuperavit/deficitsuperavit.shtml

http://www.monografias.com/trabajos35/el-poder/el-poder.shtml

http://www.monografias.com/trabajos5/colarq/colarq.shtml

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.

Tecnología Frameworks

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

http://es.wikipedia.org/wiki/Apache_Struts

http://es.wikipedia.org/wiki/Sitio_web

http://es.wikipedia.org/wiki/C%C3%B3digo_fuente

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.

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.


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



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.

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.


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



UML (MODELO DE LENGUAJE UNIFICADO).

Lenguaje Unificado de Modelado

(LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje

de modelado de sistemas de software más conocido y utilizado en la actualidad; está

respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para

visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para

describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como

procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de

lenguajes de programación, esquemas de bases de datos y compuestos reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para

describir métodos o procesos. Se utiliza para definir un sistema, para detallar los

artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje

en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a

una metodología de desarrollo de software (tal como el Proceso Unificado Racional

o RUP), pero no especifica en sí mismo qué metodología o proceso usar.

UML no puede compararse con la programación estructurada, pues UML significa

Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de

una utilización en un requerimiento. Mientras que, programación estructurada, es una

forma de programar como lo es la orientación a objetos, sin embargo, la programación

orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se

toma UML sólo para lenguajes orientados a objetos.

Antes de UML 1.x

Después de que la Rational Softwarsse Corporation contratara a James Rumbaugh de

General Electric en 1994, la compañía se convirtió en la fuente de los dos esquemas de

modelado orientado a objetos más populares de la época: el OMT (Object-modeling

technique) de Rumbaugh, que era mejor para análisis orientado a objetos, y el Método

Booch de Grady Booch, que era mejor para el diseño orientado a objetos. Poco después

se les unió Ivar Jacobson, el creador del método de ingenieríá de software orientado a

objetos. Jacobson se unió a Rational en 1995 después de que su compañía, Objectory

AB, fuera comprada por Rational. Los tres metodologistas eran conocidos como los Tres

Amigos, porque se sabía de sus constantes discusiones sobre las prácticas

metodológicas.

En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba

alentando la adopción de la tecnología de objetos, y para orientarse hacia un método

unificado, encargaron a los Tres Amigos que desarrollaran un Lenguaje Unificado de

Modelado abierto. Se consultó con representantes de compañías competidoras en el área

https://es.wikipedia.org/wiki/Modelado

https://es.wikipedia.org/wiki/Software

https://es.wikipedia.org/wiki/Object_Management_Group

https://es.wikipedia.org/wiki/RUP

https://es.wikipedia.org/wiki/Ivar_Jacobson

de la tecnología de objetos durante la OOPSLA '96; eligieron cajas para representar

clases en lugar de la notación de Booch que utilizaba símbolos de nubes.

UML 1.x

Como notación de modelado, la influencia de la OMT domina UML (por ejemplo el uso de

rectángulos para clases y objetos). Aunque se quitó la notación de "nubes" de Booch, si

se adoptó la capacidad de Booch para especificar detalles de diseño en los niveles

inferiores. La notación de Casos de Uso del Objectory y la notación de componentes de

Booch fueron integrados al resto de la notación, pero la integración semántica era

relativamente débil en UML 1.1, y no se arregló realmente hasta la revisión mayor de UML

2.0.

Conceptos de muchos otros métodos OO fueron integrados superficialmente en UML con

el propósito de hacerlo compatible con todos los métodos OO. Además el grupo tomó en

cuenta muchos otros métodos de la época, con el objetivo de asegurar amplia cobertura

en el dominio de los sistemas en tiempo real. Como resultado, UML es útil en una

variedad de problemas de ingeniería, desde procesos sencillos y aplicaciones de un sólo

usuario a sistemas concurrentes y distribuidos.

UML 2.x

UML ha madurado considerablemente desde UML 1.1. Varias revisiones menores (UML

1.3, 1.4 y 1.5) han corregido defectos y errores de la primera versión de UML. A estas le

ha seguido la revisión mayor UML 2.0 que fue adoptada por el OMG en 2005.

Aunque UML 2.1 nunca fue lanzado como una especificación formal, las versiones 2.1.1 y

2.1.2, aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009. UML 2.3 fue

lanzado oficialmente en mayo de 2010. UML 2.4.1 fue lanzado oficialmente en agosto de

2011. UML 2.5 fue lanzado en octubre de 2012 como una versión "En proceso" y todavía

tiene que ser formalmente liberada.

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.

http://www.docirs.cl/arquitectura_tres_capas.htm

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.

MICROSOFT PROJECT, INTELIGENCIA ARTIFICIAL, LENGUAJE COBOL.

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.

SOFTWARE REQUISITE PRO.

Requisitos pro.

es un requisitos y el uso de herramientas de gestión de casos para los equipos de

proyecto.Los equipos pueden crear y compartir sus necesidades utilizando métodos

basados en documentos familiares, durante el uso de las capacidades de base de datos

como la trazabilidad y el análisis de impacto. Esto puede mejorar la comunicación y la

gestión de requisitos, aumentar la calidad y el tiempo de salida al mercado.

Rational RequisitePro es una herramienta fácil de usar que le ayuda a:

Evite el retrabajo y la duplicación con la avanzada integración en tiempo real con

Microsoft ® Word.

Gestione la complejidad con trazabilidad detalladas vistas que muestran relaciones padre

/ hijo.

Mejorar la colaboración de equipos geográficamente distribuidos a través de pleno

funcionamiento, la interfaz web escalable y foros de discusión.

Capturar y analizar los requisitos de información con la personalización de atributos

detallado y filtrado.

Aumentar la productividad mediante cambios de localización utilizando comparaciones

versión del proyecto con las líneas de base de los proyectos basados en XML.

Alinear las metas y objetivos de negocio con los resultados del proyecto , aunque la

integración con múltiples herramientas en el desarrollo de software de IBM Rational y la

plataforma de entrega.

mantiene los equipos de proyectos al día gracias a la creación, análisis y gestión de los requisitos de aplicaciones y casos de uso.

Ya que el desarrollo de software es una tarea de equipo, es crítico que los miembros que implementen la solución comprendan los objetivos y entregables apropiados. ¿Cómo puede un equipo entregar la solución adecuada si sus miembros no tienen acceso a la visión del proyecto, sus metas, especificaciones y otros requerimientos que detallan lo que la solución final debe hacer?

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 á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 o Linden 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,

http://es.wikipedia.org/wiki/Metaverso

http://es.wikipedia.org/w/index.php?title=Linden_Lab&action=edit&redlink=1

http://es.wikipedia.org/wiki/Internet

http://es.wikipedia.org/w/index.php?title=Resident_(Second_Life)&action=edit&redlink=1

http://es.wikipedia.org/wiki/Avatar_(desambiguaci%C3%B3n)

http://es.wikipedia.org/wiki/Second_Life#cite_note-4

http://es.wikipedia.org/w/index.php?title=Propiedad_virtual&action=edit&redlink=1

http://es.wikipedia.org/wiki/Avatar_(Internet)

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n

http://es.wikipedia.org/w/index.php?title=Linden_Scripting_Language&action=edit&redlink=1

http://es.wikipedia.org/w/index.php?title=Linden_Scripting_Language&action=edit&redlink=1

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.

En 1999, Philip Rosedale (conocido dentro de SL como Philip Linden) 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. 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. 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 deNeal

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.

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. Rosedale presentó

a Mark Kingdon como nuevo director el 15 de mayo de ese mismo año.

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

http://es.wikipedia.org/wiki/Gesti%C3%B3n_de_derechos_digitales

http://es.wikipedia.org/wiki/Gesti%C3%B3n_de_derechos_digitales

http://es.wikipedia.org/w/index.php?title=Philip_Rosedale&action=edit&redlink=1



http://es.wikipedia.org/wiki/Second_Life#cite_note-lindenlab-pressrelease-20021030-8


http://es.wikipedia.org/wiki/Neal_Stephenson

http://es.wikipedia.org/wiki/Neal_Stephenson

http://es.wikipedia.org/wiki/Snow_Crash

http://es.wikipedia.org/wiki/Universidad_de_California_San_Diego

http://es.wikipedia.org/wiki/Universidad_de_California_San_Diego

http://es.wikipedia.org/w/index.php?title=Cory_Ondrejka&action=edit&redlink=1

http://es.wikipedia.org/w/index.php?title=Chief_technology_officer&action=edit&redlink=1

http://es.wikipedia.org/w/index.php?title=Chief_technology_officer&action=edit&redlink=1

http://es.wikipedia.org/w/index.php?title=Tanatoverso&action=edit&redlink=1


http://es.wikipedia.org/w/index.php?title=Mark_D._Kingdon&action=edit&redlink=1


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.

Conclusión.

Como conclusión se puede decir que lo aprendido es de suma importancia al igual que los

temas visto en este portafolio ya que es de suma importancia para mi formación

educacional y con esto me da los principio que tengo que aportar para mi carrera y con

eso ser un estudiante capas de y seguro de mis capacidades, ya con ello aprendemos

nuevas tecnologías y como podemos ampliar en nuestro ámbito.

portafolio de evidencia agustin duarte

Documents