Portafolio de evidencias jesus gonzalez

!Final de fórmula inesperado

C i u d a d O b r e g ó n S o n o r a , a 0 6 d e J u n i o d e 2 0 1 3

Portafolio de EvidenciaIngeniería de Software.

Universidad Del Desarrollo Profesional.

Ing. En sistemas ComputacionalesMATRICULA: 25113224PROFESOR: José Benito Franco Urrea.

MATERIA: Ingeniería del Software.

HORARIO: 13:00 – 15:00 horas.

Aula: 8UNIDAD: CentroCTRIMESTRE: 6Ciclo: 2014-1

PLANEACIÓN DE CURSO

Plantel: CENTROPrograma: LSIC Fecha: 13/05/2013

Curso: INGENIERIA DE SOFTWARE Ciclo: 2014-1Docente: 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 escritaIdentificación de variables involucradas en la formulación de proyectosAnalítico en el manejo del contenido de claseResponsable y analítico en la solución de casos reales.

Diligencia, cuidado y limpiezaComunicación asertivaAplicación de teorías y modelos a casos concretosAdministración del tiempo y Manejo de gruposInvestigación documental y de campoActitudes (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 estudioDisposición para trabajar en equipoCreatividadComunicativo

RespetuosoCrítico ante los problemas del entornoPredisposición positiva al cambioHumanistaMediación entre las diferenciasDisposició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 desistemas de software.

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

didácticosRecursos Evaluación

1. Proceso deingeniería delsoftware

1.1 Proyectos desoftware

1.2 Procesosdeproducción

1 Presentación del programade curso.

2. inducción a la materia.3. Formación de equipos y

asignación de los temas.

4. Exposición en PowerPointde los temas. (Maestro).

5. Análisis y reflexión de lostemas por parte del alumno.

6. Exposición por parte delequipo #1. Tema investigado:Preguntas frecuentes de laIngeniería de Software.

7. Video: Si los Programadoresconstruyeran aviones.

8. Reporte de lectura del tema:Preguntes frecuentes de laingeniería de software.

9. Proyecto Final

Pizarrón,cañón, PC,Videos

Libros digitalizados de:INGENIERIA DELSOFTWAREun enfoque practicoSexta EdiciónAutor: Roger S.Pressman

Ingeniería del SoftwareSéptima EdiciónIan Sommerville

1 %

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

1 %

SEMANA 2Del 20 de Mayo al 23 de Mayo de 2013Contenido Estrategia de enseñanza-aprendizaje Materiales


1.3 Métricas,estimación yplaneación

1.4 El equipo dedesarrollo


2. Análisis y reflexión de lostemas por parte delalumno.

Pizarrón, cañón,PC, Videos

Librosdigitalizados de:INGENIERIA DELSOFTWAREun enfoquepracticoSexta EdiciónAutor: Roger S.Pressman

Ingeniería delSoftwareSéptima EdiciónIan Sommerville

1 %

2 Fase deanálisis2.1 Requeri

mientosydocumentación

3. Exposición por parte delequipo #2. Ingeniería deSoftware asistida porcomputadora.

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

5. Revisión de avances delproyecto final

Pizarrón, cañón,PC

1 %

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

2 %

SEMANA 3Del 27 de Mayo al 30 de MayoContenido Estrategia de enseñanza-aprendizaje Materiales


2.2 Análisis2.3 Modela

do ydiseño



Pizarrón,cañón, PC



1 %

3 Fase deimplementación3.1 Determi

nacióndellenguajeymetodología

3. Exposición por parte delequipo #3. Tema investigado:Diseños de Interfaces deUsuarios

4. Revisión de avances delproyecto final.

1 %

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

15 %

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

SEMANA 4Del de al deContenido Estrategia de enseñanza-aprendizaje Materiales


3.2 Implementaciónderequerimientosdelmodelo

3.3 Programación

3.4 Implementación



3. Exposición por parte delequipo #4. Tema investigado:Diseños de Interfaces deUsuarios

4. Reporte de lectura del temainvestigador: Diseño deinterfaces 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 5Del de al deContenido Estrategia de enseñanza-aprendizaje Materiales


4 Fase depruebas ymantenimiento4.1 Diseño

depruebas

4.2 Estrategias deprueba

4.3 Plan demantenimiento



3. Exposición y revisión delproyecto Final




1 %

Evaluación 2o. parcial: Deberá ser revisado por el coordinador académico y abarcar el 100% de lostemas abordados en las semanas 4 y 5.

25 %

Portafolio de aprendizaje: Deberá ser revisado por el coordinador académico e incluir todos loselementos 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 MODIFICARSEEVALUACIÓ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

LIBROIngeniería delSoftware - UnEnfoque Practico

Pressman,Roger S. Mc. Graw Hill 2002

LIBRO Ingeniería delSoftware

Sommerville,Ian Pearson 2006

LIBRO

Ingeniería deSoftwareOrientada aObjetos Con JavaE Internet

Weitzenfeld,Alfredo Thomson 2006

UNIVERSIDAD DEL DESARROLLO PROFESIONAL

Perfil Descriptivo de Clase

Materia: INGENIERÍA DE SOFTWARE Ciclo: 2013-2Maestro: M.C. JOSÉ BENITO FRANCO URREA Horario: 13:00-15:00

Objetivo delCurso:

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

Bibliografía:

.

criterios parala Evaluación

CALIFICACIÓN ORDINARIA (PONDERACIÓN)

Actividadessemanales

30% Examen primer parcial. 15%

Portafolioreaprendizaje

10%Examen segundo

parcial.25%

Trabajosindependientes 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) decalificació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, suscalificaciones, 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 trabajosfinales 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 delmaestro, Integración de equipos, diagnóstico de conocimientos del grupo.

2 14/05/20131. Proceso de ingeniería del software

a. Modelos del proceso del software1.1. Proyectos de software

3 15/05/2013

1.2. Procesos de producción

Modelo en cascada. Desarrollo evolutivo o espiral Modelo Incremental Desarrollo Iterativo1.3. Métricas, estimación y planeación

4 16/05/20131.4. Equipo de DesarrolloExposición tema de investigación Equipo #1 Preguntas frecuentesde la Ingeniería de Software.

5 20/05/2013

2. Fase de análisis2.1. Requerimientos y documentación

2.1.1 proceso de ingeniería de requerimientos.

6 21/05/20132.2. Análisis2.3. Modelado y diseño

7 22/05/2013

3 Fase de implementación3.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 modeloExposición del tema investigado por el equipo #2: Ingeniería de Softwareasistida por computadora.

9 27/05/2013

3.3. Programación3.3.1. Métodos ágiles3.3.2. Programación extrema3.3.3. Desarrollo rápido de aplicaciones3.3.4. Prototipado de Software

10 28/03/20133.4. Implementación

4. Fase de pruebas y mantenimiento

11 29/05/2013 Repaso de clase para presentar el primer examen parcialRevisión de avances del proyecto final.

12 30/05/2013 EXAMEN PRIMER PARCIAL

13 03/06/2013

4.1. Diseño de pruebasExposición del tema investigado por el equipo #3: Diseños deInterfaces de Usuarios

14 04/06/2013 4.2. Estrategias de prueba

15 05/06/2013 4.3. Plan de mantenimiento

16 06/06/2013Exposición del tema investigado por el equipo #4: Atributos de los sistemas yaplicaciones 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 #4Repaso 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.

1

Í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

2

1. Introducción de la Ing. Del Software.Un sistema informático está compuesto por hardware y software. En cuanto al hardware, suproducción se realiza sistemáticamente y la base de conocimiento para el desarrollo de dichaactividad está claramente definida. La fiabilidad del hardware es, en principio, equiparable a la decualquier otra máquina construida por el hombre. Sin embargo, respecto del software, suconstrucció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 lasconsideradas inicialmente.

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

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

Según el Centro Experimental de Ingeniería de Software (CEIS)1, el estudio de mercado TheChaos Report realizado por Standish Group Internactional2 en 1996, concluyó que sólo un 16% delos proyectos de software son exitosos (terminan dentro de plazos y costos y cumplen losrequerimientos acordados). Otro 53% sobrepasa costos y plazos y cumple parcialmente losrequerimientos. El resto ni siquiera llega al término. Algunas deficiencias comunes en el desarrollode 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 tuvolugar 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 aspectostécnicos y administrativos en el desarrollo y mantenimiento de productos software. Se pretendíaacordar las bases para una ingeniería de construcción de software. Según Fritz Bauer [2] lo que senecesitaba era “establecer y usar principios de ingeniería orientados a obtener software de maneraeconómica, que sea fiable y funcione eficientemente sobre máquinas reales”. Esta definiciónmarcaba posibles cuestiones tales como: ¿Cuáles son los principios robustos de la ingeniería

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

3

aplicables al desarrollo de software de computadora? ¿Cómo construimos el softwareeconómicamente para que sea fiable? ¿Qué se necesita para crear programas de computadoraque funcionen eficientemente no en una máquina sino en diferentes máquinas reales?. Sinembargo, dicho planteamiento además debía incluir otros aspectos, tales como: mejora de lacalidad del software, satisfacción del cliente, mediciones y métricas, etc.

El “IEEE Standard Glossary of Software Engineering Terminology” (Stad. 610.12-1990) hadesarrollado una definición más completa para ingeniería del software [1]: “(1) La aplicación de unenfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento delsoftware; 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 laFigura 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 unesfuerzo de organización de calidad. La gestión total de la calidad y las filosofías similaresfomentan una cultura continua de mejoras de procesos que conduce al desarrollo de enfoquescada 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 detrabajo para un conjunto de áreas clave, las cuales forman la base del control de gestión deproyectos de software y establecen el contexto en el cual: se aplican los métodos técnicos, seproducen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio segestiona adecuadamente.

Los métodos de la ingeniería de software indican cómo construir técnicamente el software. Losmé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 conjuntode principios básicos que gobiernan cada área de la tecnología e incluyen actividades demodelado 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 herramientasCASE (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étodosy herramientas.

A continuación nos enfocaremos en el proceso necesario para elaborar un producto de software.

No se puede mostrar la imagen en este momento.

4

El proceso de desarrollo del softwareUn proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de unproducto software que reúna los requisitos del cliente. Dicho proceso, en términos globales semuestra en la Figura 2 [3]. Este proceso es intensamente intelectual, afectado por la creatividad yjuicio de las personas involucradas [4]. Aunque un proyecto de desarrollo de software esequiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo desoftware hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza delproducto obtenido. A continuación se explican algunas particularidades asociadas al desarrollo desoftware y que influyen en su proceso de construcción.

Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% deconfiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factoresque impiden una verificación exhaustiva de las todas posibles situaciones de ejecución que sepuedan presentar (entradas, valores de variables, datos almacenados, software del sistema, otrasaplicaciones 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 delproducto y sus requisitos, sobre todo cuando no se tiene precedentes en productos softwaresimilares. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, loscambios en los requisitos son inevitables, no sólo después de entregado en producto sino tambiéndurante el proceso de desarrollo.

Además, de las dos anteriores, siempre puede señalarse la inmadurez de la ingeniería del softwarecomo disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniería. Sinembargo, 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 quesea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, esdifícil automatizar todo un proceso de desarrollo de software.

A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividadesfundamentales que se encuentran presentes en todos ellos [4]:

1. Especificación de software: Se debe definir la funcionalidad y restricciones operacionalesque debe cumplir el software.

2. Diseño e Implementación: Se diseña y construye el software de acuerdo a laespecificación.

3. Validación: El software debe validarse, para asegurar que cumpla con lo que quiere elcliente.

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 “actividadesprotectoras”, que se aplican a lo largo de todo el proceso del software. Ellas se señalan acontinuación:

Requisitos nuevoso modificados

Sistema nuevoo modificadoProceso de Desarrollo

de Software

Requisitos nuevoso modificados

Sistema nuevoo modificadoProceso de Desarrollo

de Software

5

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 detrabajo que son aplicables a todos los proyectos de software, con independencia del tamaño ocomplejidad.

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

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

Figura 3: Elementos del proceso del software

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


6

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 susrelaciones. Así las interrogantes se responden de la siguiente forma:

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

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

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

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

Modelos de proceso softwareSommerville [4] define modelo de proceso de software como “Una representación simplificada deun proceso de software, representada desde una perspectiva específica. Por su naturaleza losmodelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción deun proceso real.”

Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo, sonabstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo desoftware.

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 deresponsabilidad para un rol y (3) está sujeta a control de versiones. Un artefacto puede ser un modelo, un elemento demodelo o un documento.


7

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 cascadaEl primer modelo de desarrollo de software que se publicó se derivó de otros procesos deingenierí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 losusuarios 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. Seestablece la arquitectura total del sistema. Se identifican y describen las abstracciones yrelaciones 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 enconjunto. Se entrega el conjunto probado al cliente.

5. Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto enmarcha y se realiza la corrección de errores descubiertos. Se realizan mejoras deimplementación. Se identifican nuevos requisitos.

La interacción entre fases puede observarse en la Figura 5. Cada fase tiene como resultadodocumentos que deben ser aprobados por el usuario.

Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la correcciónde los problemas encontrados en fases previas.

8

Figura 5: Modelo de desarrollo en cascada.

En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción entre lasdistintas 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ónde documentos.

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

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

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

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

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

Desarrollo evolutivoLa idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla alos 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 yvalidació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 lasactividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

Figura 6: Modelo de desarrollo evolutivo.



9

Existen dos tipos de desarrollo evolutivo:

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

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

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 enuna mejora de la calidad del software.

Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatasdel 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 elsistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cadaversión del sistema.

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

Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientasque 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ónpara cada versión.

Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puedehacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento másestructurado. Los subsistemas con requisitos bien definidos y estables se pueden programarutilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio.

10

Desarrollo formal de sistemasEste modelo se basa en transformaciones formales de los requisitos hasta llegar a un programaejecutable.

Figura 7: Paradigma de programación automática.

La Figura 7 (obtenida desde [20]) ilustra un paradigma ideal de programación automática. Sedistinguen dos fases globales: especificación (incluyendo validación) y transformación. Lascaracterísticas principales de este paradigma son: la especificación es formal y ejecutableconstituye 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 laimplementación del sistema, en el último paso de transformación se obtiene una implementaciónen 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 esrealizado 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í, laspruebas que verifican la correspondencia con la especificación no son necesarias.

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

Requiere desarrolladores especializados y experimentados en este proceso para llevarse acabo.

Desarrollo basado en reutilizaciónComo su nombre lo indica, es un modelo fuertemente orientado a la reutilización. Este modeloconsta 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 elsistema 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 loscomponentes 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 elsistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar odeterminar este marco.

4. Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran loscomponentes y subsistemas. La integración es parte del desarrollo en lugar de una actividadseparada.

E s p e c i f i c a c i ó n T r a n f o r m a c ió nI n t e r a c t i v a

T r a n s f o r m a c ió nA u t o m á t i c a

O p t im i z a c i ó nV a l i d a c i ó n d eE s p e c i f i c a c i ó n

M a n t e n im ie n t o

E s p e c i f i c a c i ó nd e a l t o n i v e l ( p r o t o t i p o )

D e s a r r o l l oF o r m a lD e s i c i o n e s

E s p e c i f i c a c i ó nd e b a jo n i v e l

C ó d ig oF u e n t e

E s p e c i f i c a c i ó nI n f o r m a l

11

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 nocumpla las expectativas del cliente.

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

Procesos iterativosA continuación se expondrán dos enfoques híbridos, especialmente diseñados para el soporte delas iteraciones:

Desarrollo Incremental.

Desarrollo en Espiral.

Desarrollo incrementalMills [9] sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición deltrabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en losrequisitos hasta adquirir experiencia con el sistema (ver Figura 10). Es una combinación delModelo de Cascada y Modelo Evolutivo.

Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar lasdecisiones 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 unbuen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

Figura 9: Modelo de desarrollo iterativo incremental.


12

Entre las ventajas del modelo incremental se encuentran:

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

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

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

Las partes más importantes del sistema son entregadas primero, por lo cual se realizan máspruebas 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 espiralEl modelo de desarrollo en espiral (ver Figura 11) es actualmente uno de los más conocidos y fuepropuesto por Boehm [7]. El ciclo de desarrollo se representa como una espiral, en lugar de unaserie 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 ydel producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgosy se elaboran estrategias alternativas dependiendo de estos.

2. Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgoidentificado. 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 delriesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende delriesgo identificado para esa fase.

4. Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase delproyecto.

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

El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones sedeterminan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra lasalternativas. 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.

13

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. Laspropuestas comerciales y académicas actuales promueven procesos iterativos, donde en cadaiteración puede utilizarse uno u otro modelo de proceso, considerando un conjunto de criterios (Porejemplo: 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 laselección de un modelo de proceso [10], la medida utilizada indica el nivel de efectividad delmodelo de proceso de acuerdo al criterio (Por ejemplo: El modelo Cascada responde con un nivelde efectividad Bajo cuando los Requisitos y arquitectura no están predefinidos ):

Modelo de proceso

Funciona conrequisitos y

arquitectura nopredefinidos

Produce softwarealtamente fiable

Gestión de riesgosPermite correcciones

sobre la marcha

Visión delprogreso por el

Cliente y elJefe del

proyecto

Codificar y corregir Bajo Bajo Bajo Alto Medio

14

Cascada Bajo Alto Bajo Bajo Bajo

Evolutivo

exploratorioMedio o Alto Medio o Alto Medio Medio o Alto Medio o Alto

Evolutivo

prototipadoAlto Medio Medio Alto Alto

Desarrollo formalde sistemas

Bajo Alto Bajo a Medio Bajo Bajo

Desarrolloorientado areutilizació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.

15

Metodologías para desarrollo de softwareUn proceso de software detallado y completo suele denominarse “Metodología”. Las metodologíasse 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 deadaptació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íasasociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, porejemplo, 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 diversidadde propuestas y diferencias en el grado de detalle, información disponible y alcance de cada unade ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificarartefactos producidos en actividades de análisis y diseño, podemos clasificar las metodologías endos 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 laplanificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben elapelativo de Metodologías Tradicionales (o peyorativamente denominada Metodologías Pesadas, oPeso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a lageneración de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollopequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en equipo einvolucran activamente al cliente en el proceso. A continuación se revisan brevemente cada una deestas categorías de metodologías.

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

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

(España), SSADM6 (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbitoacadémico: Gane & Sarson7, Ward & Mellor8, Yourdon & DeMarco9 e Information Engineering10.

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

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

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)

16

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 UnifiedProcess (RUP)13, OPEN14, MÉTRICA (que también soporta la notación estructurada).

Metodologías tradicionales (no ágiles)Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación durantetodo el proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde serealiza 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íastradicionales. Aunque en el caso particular de RUP, por el especial énfasis que presenta en cuantoa 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 ágilesUn proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas desoftware, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntosconstantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil deaprender y modificar, bien documentado), y adaptable (permite realizar cambios de últimomomento) [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)

17

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. A15 Year Perspective on Automatic Programming. IEEE Transactions on Software Engineering,vol.11, núm.11, páginas 1257-1268, Noviembre 1985.

18

2. REPORTE DE LECTURA PREGUNTAS FRECUENTES DE INGENIERÍA DEL SOFTWARE.

Reporte De Lectura.Preguntas más frecuentes de la ingeniería del software.

¿Qué es un Software?

El software no son sólo programas, sino todos los documentos asociados y la configuración dedatos 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 deconfiguración que se utilizan para ejecutar estos programas, un sistema de documentación quedescribe 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.

¿Qué es la ingeniería del software?

Es una disciplina de la ingeniería que comprende todos los aspectos de la producción de softwaredesde 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 cienciade la computación?

Esencialmente, la ciencia de la computación se refiere a las teorías y métodos subyacentes alascomputadoras 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 ciertosconocimientos 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íade sistemas?

La ingeniería de sistemas se refiere a todos los aspectos del desarrollo y de la evolución desistemas 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 desistemas, así como la ingeniería del software. Los ingenieros de sistemas están involucrados en laespecificación del sistema, en la definición de su arquitectura y en la integración de las diferentespartes para crear el sistema final. Están menos relacionados con la ingeniería de los componentes

del sistema (hardware, software, etc.).

¿Qué es un proceso del software?

Un proceso del software es un conjunto de actividades y resultados asociados que producen unproducto de software. Estas actividades son llevadas a cabo por los ingenieros de software. Existen

19

cuatro actividades fundamentales de procesos (incluidas más adelante en este libro) que soncomunes para todos los procesos del software.

¿Cuáles son los costos de la ingeniería del software?

No existe una respuesta sencilla a esta pregunta ya que la distribución de costos a través de lasdiferentes actividades en el proceso del software depende del proceso utilizado y del tipo de

software que se vaya a desarrollar.

¿Qué son los métodos de la ingeniería del software?

Un método de ingeniería del software es un enfoque estructurado para el desarrollo de softwarecuyo propósito es facilitar la producción de software de alta calidad de una forma costeable.

Métodos como Análisis Estructurado (DeMarco, 1978) y JSD (Jackson, 1983) fueron los primerosdesarrollados en los años 70. Estos métodos intentaron identificar los componentes funcionales

básicos de un sistema, de tal forma que los métodos orientados a funciones aún se utilizanampliamente. En los años 80 y 90. Estos métodos orienta dos a funciones fueron complementados

por métodos orientados a objetos. Como los propuestos por Booch (1994) y Rumbaugh(Rumbaugh el al., 1991). Estos diferentes enfoques se han integrado en un solo enfoque unificadobasado en el Lenguaje de Modelado Unificado (UML) (Booch el al., 1999; Rumbaugh el al., I999a;

Rumbaugh el al., 1999b).

¿Cuáles son los atributos de un buen software?

Así como los servicios que proveen, los productos de software tienen un cierto número de atri-butos asociados que reflejan la calidad de ese software. Estos atribulas no están directamente

asociados con lo que el software hace. Más bien, reflejan su comportamiento durante su ejecucióny en la estructura y organización del programa fuente y en la documentación asociada. Ejemplos

de estos atribulas (algunas veces llamados atribulas no funcionales) son el tiempo de respuesta delsoftware a una pregunta del usuario y la comprensión del programa fuente.

JESUS ISIDRO GONZALEZ ESPINOZA.

PREGUNTAS MAS FRECUENTES DE LA INGENIERIA DEL SOFTWARE

REPORTE DE LECTURA

20

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

21

22

23

24

25

26

27

28

29

30

31

4. REPORTE DE LECTURA EQUIPO # 2 INGENIERÍA DEL SOFTWARE ASISTIDA PORCOMPUTADORA.

32

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

33

34

35

36

37

6. INVESTIGACIÓN DE CLASE MODELO RUP.

¿Qué es RUP?

Es un proceso de ingeniería de software, que hace una propuesta orientada por disciplinas para lograr las tareas yresponsabilidades de una organización que desarrolla software. Su meta principal es asegurar la producción de softwarede alta calidad que cumpla con las necesidades de los usuarios, con una planeación y presupuesto predecible.

¿Para quién es RUP?

Diseñado para:

–Profesionales en el desarrollo de software.

–Interesados en productos de software.

–Profesionales en la ingeniería y administración de procesos de software.

¿Por qué usar RUP?

–Provee un entorno de proceso de desarrollo configurable, basado en estándares.

–Permite tener claro y accesible el proceso de desarrollo que se sigue.

–Permite ser configurado a las necesidades de la organización y del proyecto.

–Provee a cada participante con la parte del proceso que le compete directamente, filtrando el resto.

Características

Dirigido por Casos de Uso: –Los casos de uso son los artefactos primarios para establecer el comportamientodeseado del sistema

Centrado en la Arquitectura: –La arquitectura es utilizada para conceptualizar, construir, administrar y evolucionar elsistema en desarrollo

Iterativo e Incremental:–Maneja una serie de entregas ejecutables–Integra continuamente la arquitectura para producir nuevas versiones mejoradas

Conceptualmente amplio y diverso Enfoque orientado a objetos En evolución continua Adaptable Repetible Permite mediciones:

–Estimación de costos y tiempo, nivel de avance, etc.

38

7. INVESTIGACIÓN DE CLASE DE LAS 4 FASE DEL MODELO RUP.

En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 FASES secuenciales, cada cualconcluye con un producto intermedio.

Al terminar cada fase se realiza una evaluación para determinar si se ha cumplido o no con losobjetivos de la misma.

Las fases son:

Inicio (Inception) Elaboración Construcción Transición.

Inicio (Inception)

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

Es significativamente importante para el desarrollo de nuevo software, ya que se asegura deidentificar 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 laviabilidad de desarrollar el proyecto.

Elaboración

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

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

Construcción

El objetivo de la fase de construcción es clarificar los requerimientos faltantes y completar eldesarrollo 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 laadministración de recursos y control de las operaciones para optimizar costos, tiempo y calidad.

Transición

Esta fase se enfoca en asegurar que el software esté disponible para sus usuarios. Se puede subdividir en varias iteraciones, además incluye pruebas del producto para poder hacer el

entregable del mismo, así como realizar ajuste menores de acuerdo a ajuste menores propuestospor 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.

39

8. INVESTIGACIÓN DE CLASE MÉTRICA-CALIDAD.

CALIDAD DEL SOFTWARE

El software es un producto como cualquier otro, y por tanto podemos hablar de software debuena calidad y software de mala calidad. La calidad del software comprende distintos aspectoscomo estética (que sea agradable a la vista), funcionalidad (que sea fácil de usar), eficiencia (queejecute 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 unaimpresión rápida o análisis del aspecto ni en base al coste de materiales componentes.

La calidad realizada es la obtenida tras la producción, y tiene que ver con el grado decumplimiento de las características de calidad del producto tal como se plasmaron en lasespecificaciones de diseño.

La calidad programada o diseñada es la que la empresa pretende obtener (calidad prevista), y quese plasma en las especificaciones de diseño del producto, con el fin de responder a las necesidadesdel cliente.

La calidad esperada, necesaria o concertada es la necesitada por el cliente según se manifiesta ensus necesidades y expectativas.

MÉTRICA

Históricamente se habló de métrica en referencia a los sistemas que existían para escribir versosdiferenciados en base al número de sílabas que contenía cada verso, así como en referencia alestudio y “medición” de la cantidad de sílabas y estrofas que contenían los versos.

En informática, el término métrica hace referencia a la medición del software en base aparámetros predeterminados, como puede ser el número de líneas de código de que consta o elvolumen de documentación asociada. A veces en vez de hablar de métrica se usa el término“Indicadores” del software. Algunos ingenieros lo usan como sinónimos mientras que otros lesatribuyen significados distintos.

Algunas métricas o indicadores pueden ser:

a) Índice de productividad = tamaño / esfuerzo = líneas de código generado / horas trabajadas.

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

LAS PRUEBAS Y LAS MÉTRICAS EN EL CICLO DE VIDA DEL SOFTWARE

40

Cuando el cliente nos da una especificación de requisitos del software (ERS) se procede acuantificar el tamaño y complejidad de lo que nos piden para poder hacer un presupuesto. Latécnica más utilizada para estimar el tamaño es la técnica del punto función, una técnica que tratade enumerar las consultas, datos, informes, etc. que van a ser necesarios para obtener el productoterminado.

Las métricas nos permiten saber, entre otras cosas, el número o importancia de los errores que sedetectan en los tests o correspondientes a reclamaciones recibidas del cliente. Si en cada proyectomedimos el grado de error con el tiempo tendremos un histórico que nos irá diciendo si vamosmejorando o no. También nos servirá para realizar predicciones sobre cómo el volumen de erroresy tiempo de corrección que será necesario en nuevos proyectos antes de la fase de pruebas delmismo. En resumen, la información recopilada de cada proyecto nos servirá para el futuro.

Jesús Isidro González Espinoza.Métrica y Calidad.

Ingeniería del Software.

41

9. INVESTIGACIÓN DE CLASE FASE DE GESTIÓN DE PLANEACIÓN (PLANIFICACIÓN-CLAENDARIZACIÓN-GETIÓN DE RIESGOS).

Actividades importantes de la gestión del desarrollo de software.

Planificación.

El propósito principal de la planificación es establecer un conjunto detallado de directrices quepermita al equipo de trabajo saber exactamente: Qué tiene que hacerse, Cuándo tiene quehacerse y Qué recursos tienen que estar disponibles.

Elementos de una Planificación Hitos.

Son actividades que no tienen duración pero que marcan fechas clave del proyecto y objetivosparciales del mismo. Reuniones: Son hitos que corresponden a reuniones internas o con el cliente,que deben estar programadas lo antes posible.

Tareas: Son las actividades a realizar en el proyecto para obtener los resultados esperados Personas: Encargadas de realizar cada una de las actividades Entregables: Elementos tangibles que se irán entregando a lo largo del ciclo de vida del

proyecto.

Calendarización de proyectos.

Cada proyecto de software presenta distintos problemas en su desarrollo, los cuales involucranpersonas, equipo, usuarios del software y ambiente de la aplicación. Por estas razones, cadaproyecto debe resolver el problema de la producción del software.

Calendarización Es una actividad que distribuye estimaciones de esfuerzo a través de la duraciónplanificada del proyecto, al asignar el esfuerzo a tareas específicas de ingeniería del software.

Gestión de riesgos

Gestión de riesgos = serie de pasos que ayudan a comprender y manejar la incertidumbre queimplica el desarrollo de todo proyecto.

Identificación de riesgos

Grupos de riegos Genéricos: Son comunes a todos los proyectos, son una amenazapotencial para todo el proyecto de software.

Específicos: Implican un conocimiento profundo del proyecto. Se identifican examinandoel plan del proyecto y la declaración del ámbito del software Categorías Relacionados conel tamaño del producto Impacto en la organización Tipo de cliente Definición del procesode producción Entorno de desarrollo Tecnología Experiencia y tamaño del equipo.

42

10. REPORTE DE LECTURA TEMA EQUIPO #3: DISEÑO DE INTERFASE DE USUARIOS.

Diseño de interfaz de usuario.El diseño de interfaz de usuario o la ing. De la interfaz es el diseño de computadoras, aplicaciones,maquinas, dispositivos móvil, aplicaciones de software, es una actividad multidisciplinaria queinvolucra a varias ramas es decir al diseño y el conocimiento como el diseño gráfico.

Su principal uso, consiste en proporcionar un entorno visual sencillo para permitir la comunicacióncon el sistema operativo de una maquina o computador.

Principios de Diseño.

Para diseñar correctamente una interfaz debemos:

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

Tipos de interfaces graficas de usuario.

GUI´s y Zooming user interface. Interfaz de usuario de pantalla táctil. Interfaz Natural de Usuario.

Principios básicos de diseño para interfaces.

Interfaz amigable: Permite al usuario sentirse cómodo. El control de usuario. Las aplicaciones deben estar diseñadas para que el usuario sea el

centro de las operaciones. Consistencias: las aplicaciones deben resultar familiares a los usuarios, que ellos se sientan

que pueden manipular la aplicación con conocimientos adquiridos previamente utilizandootras aplicaciones.

Aprueba de errores: La aplicación debe estar desarrollada de forma en que el usuariopueda equivocarse y corregir su error o simplemente la aplicación no deba permitírselo.

Feedback: La aplicación debe poder molestarle al usuario cuándo está procesandoordenes o realizando tareas internamente por ejemplo barras de progreso, puntero enespera, entre otros.

Directa: debe permitir al usuario saber sobre lo que sucede en la aplicación y comoutilizarla mediante la interfaz de la misma.

43

12. REPORTE DE LECTURA TEMA EQUIPO #4: ATRIBUTOS DE LOS SISTEMAS YAPLICACIONES BASADAS EN WEB.

En la actualidad, las WebApps han evolucionado en sofisticadas herramientas de computación queno sólo proporcionan función por sí mismas al usuario final, sino que también se han integrado conbases de datos corporativas y aplicaciones de negocios.

Existe poco debate en cuanto a que las WebApps son diferentes a las muchas categorías desoftware informático, las cuales se presentan a continuación:

Software de Sistemas. Es una colección de programas escritos para servir a otrosprogramas

SW de aplicación. Consistente en programas independientes que resuelven unanecesidad de negocios específica.

SW científico y de ingeniería.

Software empotrado. Reside dentro de la memoria de ‘solo lectura’ del sistema y con élse implementan y controlan características y funciones para el usuario final y el sistemamismo.

SW de línea de productos. Diseñado para proporcionar una capacidad específica y lautilización de muchos clientes diferentes.

Aplicaciones basadas en Web

Software de inteligencia artificial. Utiliza algoritmos no numéricos para la resolución deproblemas complejos que es imposible abordar por medio de un análisis directo.

En la gran mayoría de las WebApps se encuentran los siguientes atributos:

Intensidad de red. Una WebApp reside en una red y debe satisfacer las necesidades deuna variada comunidad de clientes. Una WebApp puede residir en Internet, en una Intraneto en una Extranet.

Concurrencia. Un gran número de usuarios puede tener acceso a la WebApp al mismotiempo. En muchos casos, los patrones de uso entre los usuarios finales variaránenormemente.

Carga impredecible. El número de usuarios de la WebApp puede variar en órdenes demagnitud de día a día.

Desempeño. Si un usuario de WebApp debe esperar demasiado puede decidir irse acualquier otra parte.

Disponibilidad. Una disponibilidad total es un concepto poco razonable, pero los usuariosde las WebApps más populares demandan el acceso sobre una base de “24/7/365”(24horas al día, 7 días a la semana, 365 días al año para la disponibilidad del servicio)

44

Gobernada por los datos. La función primordial de muchas WebApps es mostrarinformación, esta viene dada por texto, gráficos, audio y video y además se tiene acceso abases de datos que no estaban integradas en el entorno Web.

Evolución continua. Las aplicaciones Web evolucionan de manera continua, lo que implicaun soporte continuo de actualización, hasta llegar incluso a actualizaciones minuto aminuto.

Inmediatez. Las WebApps muestran un tiempo de comercialización de unos cuantos días,de semanas o incluso, con las herramientas modernas, de horas. Los ingenieros Webdeben aplicar métodos de planeación, análisis, diseño, implementación y pruebas que hansido adaptados a los apretados tiempos requeridos para el desarrollo de WebApps.

Seguridad. Es un aspecto muy importante a tener en cuenta puesto que las WebAppsestán disponibles mediante el acceso a la red, es difícil limitar la población de usuariosfinales que pueden tener acceso a la aplicación. Con la finalidad de proteger el contenidoconfidencial y ofrecer modos seguros de transmisión de datos, se deben implementarfuertes medidas de seguridad a lo largo de la infraestructura que sustenta una WebApp ydentro de la aplicación de la misma.

Estética. Una parte innegable de la apariencia de una WebApp es su presentación y ladisposición de sus elementos. El éxito de una WebApp tiene tanto que ver con la estéticacomo con el diseño técnico con el factor añadido que lo último que ve el usuario final es lapresentación estética.

¿Pero qué hay de las WebApps por ellas mismas? ¿Qué problemas abordan? En el trabajoIWeb es usual encontrar las siguientes categorías de aplicaciones:

Informativo: Lectura con navegación y enlaces simples.

Descarga: El usuario descarga información del servidor apropiado.

Personalizable: El usuario personaliza el contenido según sus necesidades específicas.

Interacción: La comunicación de una comunidad de usuarios se realiza mediante foros,tablones de anuncios o mensajería instantánea.

Entrada del usuario: La entrada con base en formularios es el principal mecanismo para lasnecesidades de comunicación.

Orientada a transacciones: El usuario hace una solicitud que ejecuta la WebApp.

Orientada a servicios: La aplicación proporciona un servicio al usuario.

Portal: La aplicación canaliza al usuario hacia otro contenido o servicios Web fuera deldominio del portal de la aplicación.

Acceso a una base de datos: El usuario consulta una gran base de datos y extraeinformación de ella.

Almacén de datos: El usuario consulta una colección de grandes bases de datos y extraeinformación.

45

12. INVESTIGACIONES ESPECIALES:

a. FRAMEWORKS.

Tecnologías FrameworkEs una estructura conceptual y tecnológica de soporte definido, normalmente conartefactos o módulos de software concretos, con base a la cual otro proyectode software puede ser más fácilmente organizado y desarrollado. Típicamente, puedeincluir soporte de programas, bibliotecas, y un lenguaje interpretado, entre otrasherramientas, para así ayudar a desarrollar y unir los diferentes componentes de unproyecto.

Representa una arquitectura de software que modela las relaciones generales de lasentidades del dominio, y provee una estructura y una especial metodología de trabajo, lacual extiende o utiliza las aplicaciones del dominio.

Son diseñados con la intención de facilitar el desarrollo de software, permitiendo a losdiseñadores y programadores pasar más tiempo identificando requerimientos de softwareque tratando con los tediosos detalles de bajo nivel de proveer un sistema funcional. Porejemplo, 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 preocuparsede cómo se controla la navegación entre las páginas en una forma libre de errores. Sinembargo, hay quejas comunes acerca de que el usode frameworks añade código innecesario y que la preponderanciade frameworks competitivos y complementarios significa que el tiempo que se pasabaprogramando y diseñando ahora se gasta en aprender a usar los frameworks.

Es un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo deproblemática particular que sirve como referencia, para enfrentar y resolver nuevosproblemas de índole similar.

En el desarrollo de software, un framework o infraestructura digital, es una estructuraconceptual y tecnológica de soporte definido, normalmente con artefactos o módulosde software concretos, que puede servir de base para la organización y desarrollode software. Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguajeinterpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentescomponentes de un proyecto.

Representa una arquitectura de software que modela las relaciones generales de lasentidades del dominio, y provee una estructura y una especial metodología de trabajo, lacual extiende o utiliza las aplicaciones del dominio.

Son diseñados con la intención de facilitar el desarrollo de software, permitiendo a losdiseñadores y programadores pasar más tiempo identificando requerimientosde software que tratando con los tediosos detalles de bajo nivel de proveer un sistema

46

funcional. Por ejemplo, un equipo que usa Apache Struts para desarrollar un sitio web deun banco, puede enfocarse en cómo los retiros de ahorros van a funcionar en lugar depreocuparse de cómo se controla la navegación entre las páginas en una forma libre deerrores. Sin embargo, hay quejas comunes acerca de que el uso deframeworks añade código innecesario y que la preponderanciade frameworks competitivos y complementarios significa que el tiempo que se pasabaprogramando y diseñando ahora se gasta en aprender a usar los frameworks.

Fuera de las aplicaciones en la informática, puede ser considerado como el conjunto deprocesos y tecnologías usados para resolver un problema complejo. Es el esqueleto sobreel cual varios objetos son integrados para facilitar una solución dada.

Seguridad Framework

El Common Language Runtime y. NET Framework proporcionan muchas clases y servicios quepermiten a los desarrolladores escribir fácilmente código de seguridad útiles. Estas clases yservicios también permiten a los administradores del sistema para personalizar el acceso que elcódigo tiene a recursos protegidos. Además, el tiempo de ejecución y el. NET Frameworkproporciona clases y servicios que facilitan el uso de la criptografía y la seguridad basada en rolesútiles.

Jesús Isidro González EspinozaING. Sistemas Computacionales

Ingeniería Del Software6to Cuatrimestre

Tarea 2

Cd. Obregón Sonora México, a 20 de mayo de 2013.

47

b. UML (MODELO DE LENGUAJE UNIFICADO).

¿Qué es UML?

El Lenguaje de Modelado Unificado (UML:Unified Modeling Language) es la sucesión de una seriede métodos de análisis y diseño orientadas a objetos que aparecen a fines de los 80's y principiosde los 90s.UML es llamado un lenguaje de modelado, no un método. Los métodos consisten deambos de un lenguaje de modelado y de un proceso. El UML , fusiona los conceptos de laorientación a objetos aportados por Booch, OMT y OOSE (Booch, G. et al., 1999). UML incrementala capacidad de lo que se puede hacer con otros métodos de análisis y diseño orientados aobjetos. Los autores de UML apuntaron también al modelado de sistemas distribuidos yconcurrentes para asegurar que el lenguaje maneje adecuadamente estos dominios.

El lenguaje de modelado es la notación (principalmente gráfica) que usan los métodos paraexpresar un diseño. El proceso indica los pasos que se deben seguir para llegar a un diseño.

La estandarización de un lenguaje de modelado es invaluable, ya que es la parte principal delproceso de comunicación que requieren todos los agentes involucrados en un proyectoinformático. Si se quiere discutir un diseño con alguien más, ambos deben conocer el lenguaje demodelado y no así el proceso que se siguió para obtenerlo.

Una exigencia de la gran mayoría de instituciones dentro de su Plan Informático estratégico, esque los desarrollos de software bajo una arquitectura en Capas, se formalicen con un lenguajeestándar y unificado.

Es decir, se requiere que cada una de las partes que comprende el desarrollo de todo software dediseñ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 desoftware, de un modo estándar incluyendo aspectos conceptuales tales como procesos denegocios y funciones del sistema.

Este lenguaje unificado que cumple con estos requerimientos, es ciertamente UML, el cual cuentacon una notación estándar y semánticas esenciales para el modelado de un sistema orientado aobjetos.

Modelamiento de Clases

Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran elsistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.

Un diagrama de clases esta compuesto por los siguientes elementos:

Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

48

Elementos

Clase

Es la unidad básica que encapsula toda la información de un Objeto (un objeto es unainstancia de una clase). A través de ella podemos modelar el entorno en estudio (unaCasa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectángulo que posee tres divisiones:

En donde:

Superior: Contiene el nombre de la Clase Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase

(pueden ser private, protected o public). Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el

objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Ejemplo:

Una Cuenta Corriente que posee como característica:

Balance

Puede realizar las operaciones de:

Depositar Girar y Balance

El diseño asociado es:

49

Atributos y Métodos:

Atributos:

Los atributos o características de una Clase pueden ser de tres tipos, los que definen elgrado de comunicación y visibilidad de ellos con el entorno, estos son:

o public (+): Indica que el atributo será visible tanto dentro como fuera de la clase,es decir, es accsesible desde todos lados.

o private (-): Indica que el atributo sólo será accesible desde dentro de la clase (sólosus métodos lo pueden accesar).

o protected (#): Indica que el atributo no será accesible desde fuera de la clase, perosi podrá ser accesado por métodos de la clase además de las subclases que sederiven (ver herencia).

Métodos:

Los métodos u operaciones de una clase son la forma en como ésta interactúa con suentorno, éstos pueden tener las características:

o public (+): Indica que el método será visible tanto dentro como fuera de la clase,es decir, es accsesible desde todos lados.

o private (-): Indica que el método sólo será accesible desde dentro de la clase (sólootros métodos de la clase lo pueden accesar).

o protected (#): Indica que el método no será accesible desde fuera de la clase, perosi podrá ser accesado por métodos de la clase además de métodos de lassubclases que se deriven (ver herencia).

Relaciones entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar cómo se pueden interrelacionar doso más clases (cada uno con características y objetivos diferentes).

Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad delas relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación yéstas pueden ser:

uno o muchos: 1..* (1..n) 0 o muchos: 0..* (0..n) número fijo: m (m denota el número).

¿Cuáles son las características que debe tener una herramienta UML?

La herramienta UML debe apoyar todos los diagramas de los nueve que componen UML. La

50

herramienta debe soportar la diagramación de casos de uso, permitir definir la visión estática condiagramas de clases y diagramas de objeto, permitir la definición de la visión dinámica, tales comolos diagramas de secuencia, la actividad, de los estados, de colaboración y el despliegue decomponentes que forman el sistema.

Lo fundamental de una herramienta UML es la capacidad de diagramación, y los diferentes tiposde diagramas que soporta la herramienta. Sus esquemas de apoyo de diseño, documentación,construcción e implantación de sistema. Así mismo, su flexibilidad para admitir cambios noprevistos durante el diseño o el rediseño. En resumen, la herramienta ideal, es aquella que admitediseño desde inicio a fin, diseño inverso (o rediseño) y diseño vise-versa, con esquemas ampliospara documentar detalladamente los procesos.

Para DocIRS, en particular, la herramienta que cumpla con las expectativas de alcanzar todos losdiagramas UML, sería aquella en que los diagramas de clases que se tracen en la herramientapuedan ser utilizados directamente, sin intermediarios. Es decir, generar el código fuentereconociendo las clases en ASP, .NET, o C++ automáticamente desde nuestro RobotDocIRS.

Actualmente en DocIRS, el puente entre el modelamiento, diseño funcional y la documentaciónelaborados sobre UML, se realiza manualmente por nuestros analistas, ingresándolas aRobotDocIRS mediante una interfaz Insumo. (ver OPTIMIZACIÓN INSUMO ROBOT de BrunoMaggio)

Este escenario entrega un gran conjunto de archivos de código fuentes, con grandes cantidades declases, y que gracias al UML se logran determinar sus interconexiones. Aquí es donde laherramienta UML ideal, debería permitir hacer las cosas mucho más fáciles:

Diagrama UML de apoyo: La herramienta UML debe apoyar todos los diagramas de los nueve quecomponen UML. La herramienta debe soportar la diagramación de casos de uso, permitir definir lavisión estática con diagramas de clases y diagramas de objeto, permitir la definición de la visióndinámica, tales como los diagramas de secuencia, la actividad, de los estados, de colaboración y eldespliegue de componentes que forman el sistema.

Ingeniería Directa: Una herramienta UML no debe limitarse sólo a una representación pictórica dediagramas, sino que apoyar en forma directa y técnica la construcción de la aplicación en ellenguaje que se utiliza ( Java, C++, ASP, ASPX, PHP). La ingeniería directa, va moviéndose desde losrequerimientos, hacia el diseño (modelamiento, procesos) para llegar a la implementación.Nuestra experiencia, frente a la carencia de una herramienta UML es este aspecto, nos llevó adesarrollar RobotDocIRS, con el cual intentamos automatizar la generación de código fuente enforma robusta y pertinente a los intereses de cada proyecto.

Ingeniería Inversa: Es exactamente lo contrario de Ingeniería Directa. En la ingeniería inversa, laherramienta UML carga todos los archivos de la aplicación o del sistema, se identifican lasdependencias entre las distintas clases, y, esencialmente, reconstruye la estructura de todo elrequerimiento, junto con todas las relaciones entre las clases. Ingeniería Inversa es una

51

característica normalmente proporcionada por sofisticadas herramientas UML. Es decir, sepretende utilizar el método como una aproximación práctica que permita generar modelos,utilizando el estándar UML, de aquellos sistemas cuya documentación es escasa, desactualizada oinexistente.

Documentación: La documentación es un aspecto integral de una herramienta UML. Diseñar es unproceso de interpretación de una solución de software. Es decir, su naturaleza, es un procesoabstracto que la única forma de determinarlo en forma certera, es una vez se haya confrontadoprimero con los constructores y después con los usuarios. Naturalmente, existen normas desintaxis y semántica acerca de las reglas del negocio.. El proceso de pensamiento delmodelamiento de software utilizando UML, puede desperdiciarse si ciertos procesos de diseño noson capturados apropiadamente y bien documentados. Una herramienta UML debenecesariamente proveer un esquema amplio que permita al diseñador comunicar en forma precisalos detalles, incluyendo anotaciones o comentarios. Además de esto, la herramienta UML debeapoyar la generación de informes y listados de los diferentes elementos del diseño.

Colaboración en el modelamiento: Para el diseño o rediseño de sistemas complejos, puede haberdiferentes equipos participando el trabajo de diseño de diversos subsistemas en paralelo, deberíarealizarse sobre un solo ambiente. Este esfuerzo de colaboración de diseño tiene que serdebidamente sincronizado con la herramienta UML. La herramienta UML debería proporcionarapoyo a un entorno de modelado de colaboración. Una herramienta interesante, que DocIRS haintentado poner en uso como herramienta UML, es BizAg (Business Agility. para diagramar,ejecutar y mejorar los procesos de negocio). Sin embargo, cuando ya se ha estado trabajando conlos profesionales en otros entornos como el Racional Rose, el Visio,.. Migrar a todos los equiposhacia una sola herramienta es un proceso difícil.

52

c. MICROSOFT PROJECT, INTELIGENCIA ARTIFICIAL, LENGUAJECOBOL.

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 ycomercializado por Microsoft para asistir a administradores de proyectos en el desarrollo deplanes, asignación de recursos a tareas, dar seguimiento al progreso, administrar presupuesto yanalizar 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 (ManagementBody of Knowledge) del PMI (Project Management Institute).

Microsoft Project (o MSP) es un Software de administración de proyectos desarrollado y vendidopor Microsoft Archivo: El cual esta creado para asistir a los administradores de proyectos. Laprimera versión de Microsoft Project fue lanzada para DOS en 1984 por una compañía quetrabajaba para Microsoft. Microsoft adquirió todos los derechos del software en 1985 y liberó laversión 2. La versión 3 para DOS fue liberada en 1986. La versión 4 para DOS fue la última versiónpara este sistema operativo, liberada en 1987. La primera version para Windows fue liberada en1990, y fue llamada version 1 para Windows. Un dato interesante es que la primera versión paraDOS introdujo el concepto de Líneas de dependencia (link lines) entre tareas en la gráfica deGantt.

Aunque este software ha sido etiquetado como miembro de la familia Microsoft Office hasta elmomento no ha sido incluido en ninguna de las ediciones de Office. Está disponible en dosversiones, Standard y Professional.

Una versión para Macintosh fue liberada en julio de 1991 y su desarrollo continuó hasta Project4.0 para Mac en 1993. En 1994, Microsoft detuvo el desarrollo para la mayoría de las aplicacionesMac, y no ofreció nuevas versiones de Office hasta 1998, después de la creación del nuevoMicrosoft Macintosh Business Unit el año anterior. El MacBU nunca lanzó una versión actualizadapara 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 deeventos en cadena disponibles como add-ons de terceros. Los calendarios pueden ser resourceleveled, y las gráficas visualizadas en una Gráfica de Gantt. Adicionalmente, Project puedereconocer diferentes clases de usuarios, los cuales pueden contar con distintos niveles de acceso aproyectos, vistas y otros datos. Los objetos personalizables como calendarios, vistas, tablas, filtrosy 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 ProjectManagement (EPM).

53

Microsoft reveló que las futuras versiones de Microsoft Project contarán con Interfaz de usuariofluida

Inteligencia Artificial.

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

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

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

Varios ejemplos se encuentran en el área de control de sistemas, planificación automática, lahabilidad de responder a diagnósticos y a consultas de los consumidores, reconocimiento deescritura, reconocimiento del habla y reconocimiento de patrones. Los sistemas de IA actualmenteson parte de la rutina en campos como economía, medicina, ingeniería y la milicia, y se ha usadoen gran variedad de aplicaciones de software, juegos de estrategia como ajedrez de computador yotros videojuegos.

54

Cobol.

El deseo de desarrollar un lenguaje de programación que pudiera utilizarse en cualquiercomputadora, hizo que se reuniera en 1959 un grupo compuesto por fabricantes decomputadoras, empresas privadas y representantes del gobierno de los EE.UU, llamado comisiónCODASYL (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 primeraversión fue llamada COBOL-60, ya que nació en 1960.

COBOL es un lenguaje con una estructura definida. Cada parte con un objetivo concreto,facilitando así su comprensión. Su vocabulario es parecido al inglés, y está preparado para lagestión de datos en aplicaciones comerciales.

Jesús Isidro González Espinoza.

Ing. En software

Cd. Obregón Sonora, a 28 de mayo de 2013.

55

d. SOFTWARE REQUISITE PRO.

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

Jesús Isidro González Espinoza.Ciudad Obregón Sonora, a 29 de Mayo de 2013.

56

e. SECOND LIFESecond Life (abreviado SL, en español Segunda vida) es un metaverso lanzado el 23 de junio de2003, 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últiplesprogramas de interfaz llamados viewers (visores), los cuales les permiten interactuar entre ellosmediante un avatar. Los residentes pueden así explorar el mundo virtual, interactuar con otrosresidentes, establecer relaciones sociales, participar en diversas actividades tanto individualescomo en grupo y crear y comerciar propiedad virtual y servicios entre ellos. SL está reservado paramayores de 18 años.

Para acceder al programa es requisito imprescindible crear una cuenta, la cual da acceso al mundoy al avatar individual. Los avatares son caracteres tridimensionales personalizables lo que le da alos usuarios la capacidad de convertirse el personaje que deseen y "disfrutar" (como el mismonombre del programa indica) de una segunda vida.

Su segundo atractivo más importante es la posibilidad de crear objetos e intercambiar diversidadde productos virtuales a través de un mercado abierto que tiene como moneda local el LindenDólar (L$). En el mismo programa se incluye una herramienta de creación en 2D basada ensimples figuras geométricas (conocidos como prims o primitivas) y que permite a los residentes laconstrucción de objetos virtuales. Estos elementos pueden usarse en combinación con el lenguajede programación LSL o Linden Scripting Lenguaje a fin de añadir funcionalidad a los objetos.Objetos más complejos, como sculpties o complejos prims tridimensionales, texturas para ropas uobjetos, animaciones o gestos pueden ser creados externamente e importados a SL. Los Términosde Servicio de SL (conocidos por su abreviatura inglesa: TOS) aseguraban, hasta recientescambios, la retención de los derechos de autor por parte de los creadores de los objetos, mientrasque Linden Labs proveía simples funciones de gestión de derechos digitales en sus servidores y suacceso. Los recientes cambios producidos en el TOS han eliminado gran parte de los derechos delos creadores, al establecerse Linden Labs como propietario de todo el software presente en susservidores, eliminando el derecho de los creadores, al ser un entorno cerrado.

57

Conclusión.

Como conclusión se puede decir que lo aprendido es desuma importancia al igual que los temas visto en esteportafolio, ya que no servirá a lo largo de la carrera y asímismo profesionalmente, ya que la materia de ingenieríade software es una parte fundamental para la carrera, aligual he aprendido nuevas formas de cómo las tecnologíascambian y tenemos maneras de innovar, como unapresentación de exposición a una conferencia etc.

Documents

Portafolio de evidencias jesus gonzalez