Portafolio final eli

INGENIERIA DEL SOFTWARE PORTAFOLIO DE EVIDENCIAS

Jose Eli Sandoval Vasquez

PLANEACIÓN DE CURSO

Plantel: CENTRO

Programa: LSIC Fecha: 06/06/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 Contenido Estrategia de enseñanza-aprendizaje Materiales


1.3 Métricas, estimación y planeación

1.4 El equipo

de desarrollo


2. Análisis y reflexión de los

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

3. Exposición por parte del equipo #2. Ingeniería de Software asistida por computadora.

4. Reporte de lectura del tema: Ingeniería de software asistida por computadora.

5. Revisión de avances del proyecto final

Pizarrón, cañón, PC

1 %

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 Contenido Estrategia de enseñanza-aprendizaje Materiales


2.2 Análisis 2.3 Modela

do y diseño


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




1 %

3 Fase de implementac ión 3.1 Determi

nación del lenguaje y metodol ogía

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

4. Revisión de avances del proyecto final.

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 Contenido Estrategia de enseñanza-aprendizaje Materiales


3.2 Impleme

ntación de requerim ientos del modelo

3.3 Program ación

3.4 Impleme ntación




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

4. Reporte de lectura del tema

investigador: Diseño de interfaces de usuarios.




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 Contenido Estrategia de enseñanza-aprendizaje Materiales


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




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

TITUL

O

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

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.

INGENIERIA DEL SOFTWARE INGENIERIA DEL SOFTWARE

INDICE

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


INGENIERÍA DE SOFTWARE Introducción 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 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.

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


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.

No se puede mostrar la imagen. Puede que su equipo no tenga suficiente memoria para abrir la imagen o que ésta esté dañada. Reinicie el equipo y, a continuación, abra el archivo de nuevo. Si sigue apareciendo la x roja, puede que tenga que borrar la imagen e insertarla de nuevo.


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.

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

Requisitos nuevoso modificados

Sistema nuevoo modificadoProceso de Desarrollo

de Software

Requisitos nuevoso modificados

Sistema nuevoo modificadoProceso de Desarrollo

de Software


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.

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.




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

• 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ón TranformaciónInteractiva

TransformaciónAutomática

OptimizaciónValidación deEspecificación

Mantenimiento

Especificaciónde alto nivel (prototipo)

DesarrolloFormalDesiciones

Especificaciónde bajo nivel

CódigoFuente

EspecificaciónInformal


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: MERISE 4 (Francia), MÉTRICA 5 (España), SSADM 6 (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito académico: Gane & Sarson7, Ward & Mellor8, Yourdon & DeMarco9 e Information Engineering10.

Metodologías orientadas a objetos Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java11 o C# de Microsoft. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto.

En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más modesto, para dar lugar al Unified Modeling Language (UML)12, la notación OO más popular en la actualidad.

Algunos métodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh).

Algunas metodologías orientadas a objetos que utilizan la notación UML son: Rational Unified Process (RUP)13, OPEN14, MÉTRICA (que también soporta la notación estructurada).

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) 13 http://www.rational.com/products/rup/index.jsp (7.5.2003) 14 http://www.open.org.au/ (17.9.2003)


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

Referencias Word no encontró ninguna entrada para la tabla de contenido.

En el documento, seleccione las palabras que desee incluir en la tabla de contenido y, en la pestaña Inicio, en Estilos, haga clic en un estilo de título. Repita el procedimiento para cada título que desee incluir y, a continuación, inserte la tabla de contenido en el documento. Para crear manualmente una tabla de contenido, en la pestaña Elementos de documento, en Tabla de contenido, seleccione un estilo y haga clic en el botón de flecha abajo. Haga clic en uno de los estilos en Tabla de contenido manual y, a continuación, escriba las entradas manualmente.

[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 INGENIERIA DEL SOFTWARE

QUE 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. Existen dos productos:

1. Productos genéricos. 2. Productos personalizados (o hechos a medida) .

La ingeniería del software no sólo comprende los procesos técnicos del desarrollo de software sino también con actividades tales como la gestión de proyectos de software y el desarrollo de herramientas, métodos y teorías de apoyo a la producción de software. QUE ES UN PROCESO DEL SOFTWARE? Un proceso del software es un conjunto de actividades y resultados asociados que producen un producto de software. CUALES SON LOS COSTOS DE LA ING DEL SOFTWARE? No existe una respuesta sencilla a esta pregunta ya que la distribución de costos a través de las diferentes actividades en el proceso del software depende del proceso utilizado y del tipo de software que se vaya a desarrollar.


PRESENTACIÓN DEL EQUIPO #1 PREGUNTAS FRECUENTES DE

INGENIERIA DEL SOFTWARE













REPORTE DE LECTURA EQUIPO # 2 INGENIERÍA DEL SOFTWARE

ASISTIDA POR COMPUTADORA Ingeniería asistida por computadora o por ordenador (CAE, del inglés Computer Aided Engineering) es el conjunto de programas informáticos que permiten analizar y simular los diseños de ingeniería realizados con el ordenador, o creados de otro modo e introducidos en el ordenador, para valorar sus características, propiedades, viabilidad y rentabilidad. Su finalidad es optimizar su desarrollo y consecuentes costos de fabricación y reducir al máximo las pruebas para la obtención del producto deseado. La mayoría de ellas se presentan como módulos o extensiones de aplicaciones CAD, que incorporan:

ü Análisis cinemático. ü Análisis por el método de elementos finitos (FEM, Finite Elements

Method). ü Maquinado por control numérico CNC (Computered Numeric

Control). ü De exportación de ficheros "Stl" (Estereolitografía) para máquinas

de prototipado rápido.


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






MODELO 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. 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 que 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

CARACTERISTICAS: Dirigido por Casos de Uso

ü Los casos de uso son los artefactos primarios para establecer el comportamiento deseado del sistema

Centrado en la Arquitectura ü La arquitectura es utilizada para conceptualizar, construir,

administrar y evolucionar el sistema en desarrollo

Iterativo e Incremental ü Maneja una serie de entregas ejecutables ü Integra continuamente la arquitectura para producir

nuevas versiones mejoradas


CICLO DE VIDA

DIAGRAMA GENERAL DE RUP

1.-‐ El eje horizontal representa tiempo y muestra el aspecto dinámico del proceso, expresado en términos de ciclos, fases, iteraciones, y metas. 2.-‐ El eje vertical representa el aspecto estático del proceso; como está descrito en términos de actividades, artefactos, trabajadores y flujos de trabajo.


FACES DE CICLO DE VIDA

CUANDO USAR RUP?


LAS 4 FASE DEL MODELO RUP Iniciación: Obtención de los objetivos, catálogo de requisitos, identificación de casos de uso.

Ø El objetivo general de esta fase es establecer un acuerdo entre todos los interesados acerca de los objetivos del proyecto.

Ø Es significativamente importante para el desarrollo de nuevo software, ya que se asegura de identificar los riesgos relacionados con el negocio y requerimientos.

Ø Para proyectos de mejora de software existente, esta fase es más breve y se centra en asegurar la viabilidad de desarrollar el proyecto.

Elaboración: Refinamiento de los objetivos de la fase anterior, casos de uso, análisis, diseño, definición y establecimiento de la arquitectura base del sistema.

Ø El objetivo en esta fase es establecer la arquitectura base del sistema para proveer bases estables para el esfuerzo de diseño e implementación en la siguiente fase.

Ø La arquitectura debe abarcar todas las consideraciones de mayor importancia de los requerimientos y una evaluación del riesgo.

Construcción: Refinamiento de los objetivos de las fases anteriores y construcción del sistema de información.

Ø El objetivo de la fase de construcción es clarificar los requerimientos faltantes y completar el desarrollo del sistema basados en la arquitectura base.

Ø Vista de cierta forma esta fase es un proceso de manufactura, en el cual el énfasis se torna hacia la administración de recursos y control de la operaciones para optimizar costos, tiempo y calidad.


Transición: Refinamiento de los objetivos de las fases anteriores e implantación del sistema de información (preparación del producto para su entrega y pasos a producción de versiones no finales (porque hay que hacer ajustes) y de la versión final prevista).

Ø Esta fase se enfoca en asegurar que el software esté disponible para sus usuarios.

Ø Se puede subdividir en varias iteraciones, además incluye pruebas del producto para poder hacer el entregable del mismo, así como realizar ajuste menores de acuerdo a ajuste menores propuestos por el usuario.

Ø En este punto, la retroalimentación de los usuarios se centra en depurar el producto, configuraciones, instalación y aspectos sobre utilización.


MÉTRICA-‐CALIDAD El objetivo primordial de la ingeniería del software es producir un sistema, aplicación o producto de alta calidad. Para lograr este objetivo, los ingenieros de software deben emplear métodos efectivos junto con herramientas modernas dentro del contexto de un proceso maduro de desarrollo del software. Al mismo tiempo, un buen ingeniero del software y buenos administradores de la ingeniería del software deben medir si la alta calidad se va a llevar a cabo. A continuación se verá un conjunto de métricas del software que pueden emplearse a la valoración cuantitativa de la calidad de software.

El punto de vista de ¿Qué es calidad? Es diverso, y por lo tanto existen distintas respuestas, tales como se muestra a continuación:

El American Heritage Dictionary [Pressman ́98] define la calidad como “Una característica o atributo de algo.”

La calidad de un sistema, aplicación o producto es tan buena como los

requisitos que detallan el problema, el diseño que modela la solución, el código que transfiere a un programa ejecutable y las pruebas que ejercita el software para detectar errores. Un buen ingeniero del software emplea mediciones que evalúan la calidad del análisis y los modelos de diseño, así como el código fuente y los casos de prueba que se han establecido al aplicar la ingeniería del software. Para obtener esta evaluación de calidad, el ingeniero debe utilizar medidas técnicas, que evalúan la calidad con objetividad, no con subjetividad.


FASE DE GESTIÓN DE PLANEACIÓN (PLANIFICACIÓN-‐CLAENDARIZACIÓN-‐GETIÓN DE RIESGOS)

PLANIFICACION: La planificación de proyectos se refiere a la identificación de actividades, hitos y entregas de un proyecto. Por lo tanto. se debe bosquejar un plan para guiar el desarrollo hacia las me-‐ tas del proyecto. La estimación del coste es una actividad relacionada con la estimación de los recursos requeridos para llevar a cabo el plan del proyecto. La gestión efectiva de un proyecto de software depende de planificar completamente el progreso del proyecto. El gestor del proyecto debe anticiparse a los problemas que puedan surgir. así como preparar soluciones a esos problemas. Un plan, preparado al inicio de un proyecto, debe utilizarse como un conductor para el proyecto. Este plan inicial debe ser el mejor posible de acuerdo con la información disponible. Éste evolucionará conforme el proyecto progrese y la información sea mejor. El proceso de planificación se inicia con una valoración de las restricciones que afectan al proyecto (fecha de entrega requerida. personal disponible, presupuesto global. etcétera). Ésta se lleva a cabo en conjunto con una estimación de los parámetros del proyecto, como su estructura. tamaño y distribución de funciones. Entonces se definen los hitos de progreso y pro-‐ ductos a entregar. En ese momento. el proceso entra en un ciclo. Se prepara un calendario para el proyecto y las actividades definidas en el calendario se inician o se continúan. Después de algún tiempo (por lo general 2 o 3 semanas). se revisa el proyecto y se señalan las discrepancias. Debido a que las estimaciones iniciales de los parámetros del proyecto son aproximaciones. el plan siempre deberá actualizarse.


CALENDARIZACION DEL PROYECTO Esta es una de las tareas más difíciles para los gestores de proyectos. Los gestores estiman el tiempo y los recursos requeridos para completar las actividades y organizarlas en una sucesión coherente. A menos que el proyecto a calendarizar sea similar a otro anterior, las estimaciones previas son una base incierta para la calendarización del nuevo proyecto. La estimación del calendario se complica más por el hecho de que proyectos diferentes pueden utilizar métodos de diseño y lenguajes de implementación diferentes. La calendarización del proyecto implica separar todo el trabajo de un proyecto en actividades complementarias y considerar el tiempo requerido para completar di-‐ chas actividades. Por lo general, algunas de éstas se llevan a cabo en paralelo. Debemos coordinar estas actividades paralelas y organizar el trabajo para que la mano de obra se utilice de forma óptima. Deben evitarse situaciones en que el proyecto entero se retrase debido a que no se ha terminado una actividad crítica. Como en los calendarios, los gestores deben estimar los recursos necesarios para completar cada tarea. El recurso principal es el esfuerzo humano que se requiere. Otros recursos pueden ser el espacio en disco requerido en un servidor, el tiempo requerido de hardware especializado, un simulador o el presupuesto para viajes del personal del proyecto. GESTION DE RIESGOS Una tarea importante del gestor de proyectos es anticipar los riesgos que podrían afectar a la programación del proyecto o a la calidad del software a desarrollar y emprender acciones para evitar esos riesgos. Los resultados de este análisis de riesgos se deben documentar a lo largo del plan del proyecto junto con el análisis de consecuencias cuando el riesgo ocurra. Identificar éstos y crear planes para minimizar sus efectos en el proyecto se llama gestión de riesgos (Hall, 1998; Quid, 1999). De forma simple, se puede concebir un riesgo como una probabilidad de que una circunstancia adversa ocurra. Los riesgos son una amenaza para el proyecto, para el software que se está desarrollando y para la organización. Estas categorías de riesgos se definen como se muestra a continuación:


l. Riesgos del proyecto. Éstos afectan la calendarización o los recursos del proyecto. Un ejemplo podría ser la pérdida de un diseñador experimentado. 2. Riesgos del producto. Éstos afectan a la calidad o al rendimiento del software que se está desarrollando. Un ejemplo podría ser que el rendimiento en un componente que hemos comprado sea menor que el esperado. 3. Riesgos del negocio, Éstos afectan a la organización que desarrolla o suministra el software. Por ejemplo, que un competidor introduzca un nuevo producto es un riesgo de negocio. Por supuesto, estos tipos no son exclusivos entre sí. Si un programador experto abandona el proyecto, esto es un riesgo para el proyecto (debido a que la entrega del sistema se puede retrasar), para el producto (debido a que un sustituto puede no ser tan experto y cometer muchos errores) y para el negocio (debido a que esa experiencia puede no contribuir a negocios futuros). Los resultados del proceso de gestión de riesgos se deben documentar en un plan de ges-‐ tión de riesgos. Éste debe incluir un estudio de los riesgos a los que se enfrenta el proyecto. un análisis de éstos y los planes requeridos para su gestión. Si es necesario, puede incluir algunos resultados de la gestión de riesgos; por ejemplo. planes específicos de contingencia que se activan si aparecen dichos riesgos.


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, maquinas, dispositivos de comunicación móvil, aplicaciones de software, y sitios web enfocado en la experiencia de usuario y la interacción. Involucra a varias ramas es decir al diseño y el conocimiento como el diseño grafico, industrial, web, de software y la ergonomía. Tiene un interfaz grafica conocida también como GUI (del ingles graphical user interface) es un programa informático que actúa de interfaz de usuario. Sus principal uso, consiste en proporcionar un entorno visual sencillo para permitir la comunicación con el sistema operativo de una maquina o computador. PRINCIPIOS DE DISEÑO

ü Identificar la navegación para los usuarios de la interfaz. ü Validar de los datos de entrada. ü Establecer formas apropiadas para presentar resultados.

PUNTOS BASICOS

ü Interfaz amigable ü Control de usuario ü Consistencia ü A prueba de errores ü Feedback ü Directo ü Teclas aceleradoras ü Estética


REPORTE DE LECTURA TEMA EQUIPO #4: ATRIBUTOS DE LOS SISTEMAS Y APLICACIONES BASADAS EN WEB.

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 todo el 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. 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. Informativa: se proporciona un contenido solo de lectura con navegación y enlaces simples. Descarga: un usuario descarga la información desde el servidor apropiado. Personalizable: el usuario personaliza el contenido a sus necesidades específicas. Interacción: la comunicación entre una comunidad de usuarios ocurre mediante un espacio chat (charla), tablones de anuncios o mensajería instantánea; entrada del usuario: la entrada basada en formularios es el mecanismo primario de la necesidad de comunicación. Orientada a transacciones: el usuario hace una solicitud (por ejemplo, la realización un pedido) que es cumplimentado por la WebApp; Orientado a servicios: la aplicación proporciona un servicio al usuario, por ejemplo, ayuda al usuario a determinar un pago de hipoteca. Portal: la aplicación canaliza al usuario llevándolo a otros contenidos o servicios Web fuera del dominio de la aplicación del portal. Acceso a bases de datos: el usuario consulta en una base de datos grande y extrae información. Almacenes de datos: el usuario hace una consulta en una colección de bases de datos grande y extrae información.


INVESTIGACIONES ESPECIALES: FRAMEWORKS En el desarrollo de software, un framework o infraestructura digital, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos de software concretos, que puede servir de base para la organización y desarrollo de software. Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto. Representa una arquitectura de software que modela las relaciones generales de las entidades del dominio, y provee una estructura y una especial metodología de trabajo, la cual extiende o utiliza las aplicaciones del dominio. Un Framework ofrece componentes como una librería, pero además provee de plantillas o esqueletos que definen el funcionamiento de las aplicaciones. Por ejemplo, para una aplicación sencilla (es decir, no basada en documentos) el Framework provee con un centro de notificaciones, pasteboard, métodos delegate, … que permiten manejar y controlar prácticamente toda la aplicación sin escribir mucho código. Para una aplicación basada en documentos, la plantilla se encarga de cada uno de los documentos abiertos (títulos de las ventanas, cambios en el contenido de cada una, notificar si el documento que se va a cerrar tiene cambios sin guardar, … ). Estas plantillas que ofrece el Framework se pueden adaptar a diferentes necesidades. Y, en el caso de que sus capacidades básicas no basten, se puede crear una subclase (de la clase que provee la plantilla) y agregar las modificaciones deseadas. Dichas plantillas ahorran trabajo a la hora de escribir una aplicación. Además de que hacen relativamente fácil entender otras aplicaciones hechas con el mismo Framework, ya que comparten un esqueleto similar.


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. 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. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.


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


SOFTWARE REQUISITE PRO RequisitePro es la herramienta que ofrece Rational Software para tener un mayor control sobre los requerimientos planteados por el usuario y todos aquellos requerimientos técnicos o nuevos requerimientos de usuario que surjan durante el ciclo de vida del proyecto. En RequisitePro los requerimientos se encuentran documentados bajo un esquema organizado de documentos; estos esquemas cumplen completamente con los estándares requeridos por algunas de las instituciones a nivel mundial más reconocidas en el desarrollo de software, tales como: IEEE (Instituto de Ingenieros Eléctricos y Electrónicos), ISO, CMM (Modelo de Capacidad de Madurez) y por el RUP (Proceso Unificado Racional). Esta herramienta se integra con aplicaciones para la administración de cambios, herramientas de modelado de sistemas y con herramientas de pruebas. Esta integración asegura que los diseñadores conocen los requerimientos del usuario, del sistema y del software en el momento de su desarrollo. Según la promoción hecha en Internet mediante la página Web para esta herramienta, algunas de sus ventajas son: Un producto potente y fácil de utilizar para la gestión de requisitos y casos de uso que propicia una mejor comunicación, mejoras en el trabajo en equipo y reduce el riesgo de los proyectos.


SECOND LIFE Second Life (abreviado SL, en español Segunda vida) es un metaverso lanzado el 23 de junio de 2003, desarrollado por Linden Lab, al que se puede acceder gratuitamente Internet. Sus usuarios, conocidos como "residentes", pueden acceder a SL mediante el uso de uno de los múltiples programas de interfaz llamados viewers (visores), los cuales les permiten interactuar entre ellos mediante un avatar. Los residentes pueden así explorar el mundo virtual, interactuar con otros residentes, establecer relaciones sociales, participar en diversas actividades tanto individuales como en grupo y crear y comerciar propiedad virtual y servicios entre ellos. SL está reservado para mayores de 18 años. Para acceder al programa es requisito imprescindible crear una cuenta, la cual da acceso al mundo y al avatar individual. Los avatares son caracteres tridimensionales personalizables lo que le da a los usuarios la capacidad de convertirse el personaje que deseen y "disfrutar" (como el mismo nombre del programa indica) de una segunda vida.


CONCLUSION Esta materia se encargo de darnos a conocer los avances tecnológicos que están actualmente creando e implementando poco a poco en la vida cotidiana para mejorar el tipo de comunicación entre la vida social de las personas a nivel mundial. También se toco el tema sobre la elaboración del un software su desarrollo con todos sus pasos específicos para que no haya error alguno al finalizar el software e implementarlo en el sistema de dicha empresa.

Date post:	30-Mar-2016
Category:	Documents
Upload:	jose-vasquez
View:	230 times
Download:	1 times

Portafolio final eli

Documents