portafolio de evidencias ingenieria del software

PORTAFOLIO DE EVIDENCIAS INGENIERIADEL SOFTWARE.UNIVERSIDAD DEL DESARROLLO PROFESIONAL.VICTOR HUGO IBARRA ORTIZ.

INGENIERIA EN SISTEMAS COMPUTACIONALES.

MATRICULA: 25113172.

MAESTRO: BENITO FRANCO URREA.

MATERIA: INGENIERIA DEL SOFTWARE.

HORARIO: 1:00 A 3:00 P.M.

UNIDAD: CENTRO.

AULA: 8

CD. OBREGON, SONORA A 06 DE JUNIO DE 2013.

INDICE.INFORMACION INSTITUCIONAL.PERFIL DESCRIPTIVO.

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.

13. CONCLUSION.

INFORMACION INSTITUCIONAL.

La misión de UNIDEP es formar profesionales de éxito que cuenten con las actitudes, habilidades yconocimientos que demanda el sector productivo de la región.VisiónLa Universidad del Desarrollo Profesional es una institución de educación superior de calidad, que ofreceprogramas presenciales y semipresenciales de bachillerato, profesional asociado, licenciatura, posgrado,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 estrechavinculación con el sector productivo y en planes de estudio pertinentes y dinámicos.Es reconocida por su modelo educativo profesionalizante, por la flexibilidad de su oferta académicaimpartida en ciclos continuos y por horarios y cuotas accesibles, acordes a la disponibilidad de tiempo yrecursos económicos del alumno.Cuenta con profesores de amplia experiencia profesional y educativa. Sus instalaciones dentro de la ciudadpermiten el fácil acceso.Cuenta con un modelo de administración sistematizado, participativo, operado por personal que esrecompensado por su desempeño efectivo que le permite maximizar las aportaciones de sus socios ymantener finanzas sanas.Los Integrantes de la comunidad Universitaria consideramos la fidelidad como un valor excelso queenaltecemos en nuestro quehacer diario.Justicia.Los integrantes de la comunidad Universitaria actuamos con la constante y perpetua voluntad de dar acada 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 encongruencia entre los pensamientos, palabras y acciones.Responsabilidad.Los integrantes de la comunidad universitaria llevamos a cabo nuestras actividades con integridad, consentido 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 losobjetivos trazados.Creatividad.Los integrantes de la comunidad universitaria resolvemos los problemas con imaginación, conocimientos ycon un espíritu de mejora continua.

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

PERFIL DESCRIPTIVO.

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 L100%

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

1. INTRODUCCIÓN DE LA ING. DEL SOFTWARE.

Un sistema informático está compuesto por hardware y software. En cuanto al hardware,su producción se realiza sistemáticamente y la base de conocimiento para el desarrollo dedicha 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 cuestionadosdebido 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 lasestimaciones.

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

El software se suele presentar fuera del plazo establecido y con menos prestacionesde 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 mercadoThe Chaos Report realizado por Standish Group Internactional2 en 1996, concluyó que sóloun 16% de los proyectos de software son exitosos (terminan dentro de plazos y costos ycumplen los requerimientos acordados). Otro 53% sobrepasa costos y plazos y cumpleparcialmente los requerimientos. El resto ni siquiera llega al término. Algunas deficienciascomunes 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 desoftware tuvo lugar en la conferencia organizada en 1968 por la Comisión de Ciencias de

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

la OTAN en Garmisch (Alemania), dicha situación problemática se denominó crisis delsoftware. En esta conferencia, así como en la siguiente realizada en Roma en 1969, seestipuló el interés hacia los aspectos técnicos y administrativos en el desarrollo ymantenimiento de productos software. Se pretendía acordar las bases para una ingenieríade construcción de software. Según Fritz Bauer [2] lo que se necesitaba era “establecer yusar principios de ingeniería orientados a obtener software de manera económica, que seafiable y funcione eficientemente sobre máquinas reales”. Esta definición marcaba posiblescuestiones tales como: ¿Cuáles son los principios robustos de la ingeniería aplicables aldesarrollo de software de computadora? ¿Cómo construimos el softwareeconómicamente para que sea fiable? ¿Qué se necesita para crear programas decomputadora que funcionen eficientemente no en una máquina sino en diferentesmá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 ymé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) Laaplicació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 descansarsobre un esfuerzo de organización de calidad. La gestión total de la calidad y lasfilosofías similares fomentan una cultura continua de mejoras de procesos que conduceal 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 unmarco de trabajo para un conjunto de áreas clave, las cuales forman la base delcontrol de gestión de proyectos de software y establecen el contexto en el cual: seaplican los métodos técnicos, se producen resultados de trabajo, se establecen hitos, seasegura la calidad y el cambio se gestiona adecuadamente.

Los métodos de la ingeniería de software indican cómo construir técnicamente el

No se puede mostrar la imagen en este momento.

software. Los métodos abarcan una gran gama de tareas que incluyen análisis derequisitos, diseño, construcción de programas, pruebas y mantenimiento. Estosmétodos dependen de un conjunto de principios básicos que gobiernan cada área dela 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 osemi-automático para el proceso y los métodos, a estas herramientas se les llamaherramientas CASE (Computer-Aided Software Engineering).

Dado lo anterior, el objetivo de la ingeniería de software es lograr productos de softwarede calidad (tanto en su forma final como durante su elaboración), mediante un procesoapoyado por métodos y herramientas.

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

El proceso de desarrollo del software

Un proceso de desarrollo de software tiene como propósito la producción eficaz yeficiente de un producto software que reúna los requisitos del cliente. Dicho proceso, enté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 proyectode desarrollo de software es equiparable en muchos aspectos a cualquier otro proyectode ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativosesencialmente a la naturaleza del producto obtenido. A continuación se explican algunasparticularidades asociadas al desarrollo de software y que influyen en su proceso deconstrucció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 defactores que impiden una verificación exhaustiva de las todas posibles situaciones deejecución que se puedan presentar (entradas, valores de variables, datos almacenados,software del sistema, otras aplicaciones que intervienen, el hardware sobre el cual seejecuta, etc.).

Un producto software es intangible y por lo general muy abstracto, esto dificulta ladefinición del producto y sus requisitos, sobre todo cuando no se tiene precedentes enproductos software similares. Esto hace que los requisitos sean difíciles de consolidartempranamente. Así, los cambios en los requisitos son inevitables, no sólo después deentregado en producto sino también durante el proceso de desarrollo.

Además, de las dos anteriores, siempre puede señalarse la inmadurez de la ingeniería delsoftware como disciplina, justificada por su corta vida comparada con otras disciplinas dela 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 softwareuniversal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido aesta 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 deactividades fundamentales que se encuentran presentes en todos ellos [4]:

1. Especificación de software: Se debe definir la funcionalidad y restriccionesoperacionales que 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 quiereel cliente.

4. Evolución: El software debe evolucionar, para adaptarse a las necesidades delcliente.

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. Ellasse 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 laFigura 3. Los elementos involucrados se describen a continuación:

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

Un conjunto de tareas, cada uno es una colección de tareas de ingeniería del software,

Requisitos nuevoso modificados

Sistema nuevoo modificadoProceso de Desarrollo

de Software

Requisitos nuevoso modificados

Sistema nuevoo modificadoProceso de Desarrollo

de Software

hitos de proyectos, entregas y productos de trabajo del software, y puntos de garantíade calidad, que permiten que las actividades del marco de trabajo se adapten a lascaracterí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 deconfiguración del software y medición, abarcan el modelo del proceso. Las actividadesde protección son independientes de cualquier actividad del marco de trabajo yaparecen durante todo el proceso.

Figura 3: Elementos del proceso del software

Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo desoftware es establecer las relaciones entre elementos que permitan responder Quiéndebe 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 susrelaciones. Así las interrogantes se responden de la siguiente forma:

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

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

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

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

Modelos de proceso software

Sommerville [4] define modelo de proceso de software como “Una representaciónsimplificada 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 delsoftware es una abstracción de un proceso real.”

Los modelos genéricos no son descripciones definitivas de procesos de software; sinembargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentesenfoques 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

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 de modelo o undocumento.

Codificar y corregir (Code-and-Fix)

Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dospasos:

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 malaestructura, hace que los arreglos sean muy costosos.

Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades delusuario, 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 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 establecidoscon 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 lasabstracciones y relaciones de los componentes del sistema.

3. Implementación y pruebas unitarias: Construcción de los módulos y unidades desoftware. 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 espuesto en marcha y se realiza la corrección de errores descubiertos. Se realizanmejoras de implementació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 lacorrecció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 entrelas distintas fases de desarrollo. Algunos problemas que se observan en el modelo decascada son:

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

Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuarcon las siguientes 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 delusuario por el largo tiempo de entrega del producto.

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

Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza comoparte 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 desarrolleel 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 versioneshasta llegar al producto final.

Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, yaque 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 losrequisitos hasta llegar a un sistema final. El desarrollo comienza con las partes quese tiene más claras. El sistema evoluciona conforme se añaden nuevascaracterísticas propuestas por el usuario.

Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario ytrabajar para mejorar la calidad de los requisitos. A diferencia del desarrolloexploratorio, se comienza por definir los requisitos que no están claros para elusuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda aterminar 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 serefleja en una mejora de la calidad del software.

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

Desde una perspectiva de ingeniería y administración se identifican los siguientesproblemas:

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

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

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

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 singenerar documentación para cada versión.

Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: sepuede hacer un prototipo global del sistema y posteriormente reimplementarlo con unacercamiento más estructurado. Los subsistemas con requisitos bien definidos y establesse pueden programar utilizando cascada y la interfaz de usuario se puede especificarutilizando un enfoque exploratorio.

Desarrollo formal de sistemas

Este modelo se basa en transformaciones formales de los requisitos hasta llegar a unprograma 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 yejecutable constituye el primer prototipo del sistema), la especificación es validadamediante prototipación. Posteriormente, a través de transformaciones formales laespecificación se convierte en la implementación del sistema, en el último paso detransformación se obtiene una implementación en un lenguaje de programacióndeterminado. , el mantenimiento se realiza sobre la especificación (no sobre el códigofuente), la documentación es generada automáticamente y el mantenimiento es realizadopor 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 sonnecesarias.

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

Requiere desarrolladores especializados y experimentados en este proceso parallevarse a cabo.

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

Desarrollo basado en reutilización

Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización. Estemodelo 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 utilizadospara 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 concordarcon los componentes de la etapa anterior. Si no se puede realizar modificaciones enlos 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 paradiseñar o determinar este marco.

4. Desarrollo e integración: El software que no puede comprarse, se desarrolla. Seintegran los componentes y subsistemas. La integración es parte del desarrollo enlugar de una actividad separada.

5. 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 elsoftware no cumpla las expectativas del cliente.

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

Procesos iterativos

A continuación se expondrán dos enfoques híbridos, especialmente diseñados para elsoporte de las iteraciones:

Desarrollo Incremental.

Desarrollo en Espiral.

Desarrollo incremental

Mills [9] sugirió el enfoque incremental de desarrollo como una forma de reducir larepetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la tomade decisiones en los requisitos hasta adquirir experiencia con el sistema (ver Figura 10). Esuna combinación del Modelo de Cascada y Modelo Evolutivo.

Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasarlas decisiones hasta tener experiencia en el sistema.

Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada oevolutivo, dependiendo del conocimiento que se tenga sobre los requisitos aimplementar. 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. Puedenempezar a usarlo desde el primer incremento.

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

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

Las partes más importantes del sistema son entregadas primero, por lo cual serealizan 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ásconocidos y fue propuesto por Boehm [7]. El ciclo de desarrollo se representa como unaespiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad aotra.

Cada ciclo de desarrollo se divide en cuatro fases:

1. Definición de objetivos: Se definen los objetivos. Se definen las restricciones delproceso y del producto. Se realiza un diseño detallado del plan administrativo. Seidentifican 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 riesgoidentificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitosdudosos. 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óndel 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 delproyecto.

Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, estaes 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 sedeterminan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contralas 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, dondeen cada iteración puede utilizarse uno u otro modelo de proceso, considerando unconjunto de criterios (Por ejemplo: grado de definición de requisitos, tamaño delproyecto, riesgos identificados, entre otros).

En la Tabla 1 se expone un cuadro comparativo de acuerdo con algunos criterios básicospara la selección de un modelo de proceso [10], la medida utilizada indica el nivel deefectividad del modelo de proceso de acuerdo al criterio (Por ejemplo: El modelo Cascadaresponde con un nivel de efectividad Bajo cuando los Requisitos y arquitectura no estánpredefinidos):

Modelo deproceso

Funciona conrequisitos yarquitectura

nopredefinidos

Producesoftware

altamentefiable

Gestión deriesgos

Permitecorrecciones

sobre la marcha

Visión delprogreso

por elCliente y el

Jefe delproyecto

Codificar ycorregir

Bajo Bajo Bajo Alto Medio

Cascada Bajo Alto Bajo Bajo Bajo

Evolutivo

exploratorioMedio o Alto Medio o Alto Medio Medio o Alto

Medio oAlto

Evolutivo

prototipadoAlto Medio Medio Alto Alto

Desarrolloformal desistemas

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.

Metodologías para desarrollo de software

Un proceso de software detallado y completo suele denominarse “Metodología”. Lasmetodologías se basan en una combinación de los modelos de proceso genéricos(cascada, evolutivo, incremental, etc.). Adicionalmente una metodología debería definircon precisión los artefactos, roles y actividades involucrados, junto con prácticas ytécnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para usode herramientas de apoyo, etc. Habitualmente se utiliza el término “método” parareferirse 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álisisy/o diseño.

La comparación y/o clasificación de metodologías no es una tarea sencilla debido a ladiversidad de propuestas y diferencias en el grado de detalle, información disponible yalcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notacionesutilizadas para especificar artefactos producidos en actividades de análisis y diseño,podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas yMetodologías Orientadas a Objetos. Por otra parte, considerando su filosofía dedesarrollo, aquellas metodologías con mayor énfasis en la planificación y control delproyecto, en especificación precisa de requisitos y modelado, reciben el apelativo deMetodologías Tradicionales (o peyorativamente denominada Metodologías Pesadas, oPeso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están másorientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen aequipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociadosal trabajo en equipo e involucran activamente al cliente en el proceso. A continuación serevisan 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 laProgramación Estructurada, luego a mediados de los 70’s aparecieron técnicas para elDiseñ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 particularmenteapropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4tageneración.

Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE4 (Francia),MÉTRICA5 (España), SSADM6 (Reino Unido). Ejemplos de propuestas de métodosestructurados en el ámbito académico: Gane & Sarson7, Ward & Mellor8, Yourdon &DeMarco9 e Information Engineering10.

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)

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, laprimera versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java11 o C# deMicrosoft. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas aObjeto.

En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea deconseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta aun objetivo más modesto, para dar lugar al Unified Modeling Language (UML)12, lanotació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: RationalUnified Process (RUP)13, OPEN14, MÉTRICA (que también soporta la notaciónestructurada).

Metodologías tradicionales (no ágiles)

Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificacióndurante todo el proceso de desarrollo; llamadas también metodologías tradicionales oclásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construccióndel sistema.

Todas las propuestas metodológicas antes indicadas pueden considerarse comometodologías tradicionales. Aunque en el caso particular de RUP, por el especial énfasisque presenta en cuanto a su adaptación a las condiciones del proyecto (mediante suconfiguración previa a aplicarse), realizando una configuración adecuada, podríaconsiderarse Ágil.

Metodologías ágiles

Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñasde software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntosconstantemente con una cercana comunicación), sencillo (el método en sí mismo es fácilde 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].

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)

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

[1] Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997.[2] Naur P., Randell B., Software Engineering: A Report on a Conference Sponsored by the

NATO Scienc, 1969.[3] Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software,

Addison Wesley 2000.[4] Sommerville, I., Ingeniería de Software, Pearson Educación, 2002.[5] Letelier, P., Proyecto Docente e Investigador, DSIC, 2003.[6] Beck, K., Una explicación de la Programación Extrema. Aceptar el cambio, Pearson

Educación, 2000.[7] Boehm, B. W., A Spiral Model of Software Develpment and Enhancement, IEEE

Computer ,1988.[8] Royce, W., Managing the developmento of large software systems: concepts and

technique, IEEE Westcon, 1970.[9] Mills, H., O´Neill, D., The Management of Software Engineering, IBM Systems, 1980.[10] Laboratorio Ing. Soft., Ingeniería de software 2, Departamento de Informática, 2002.[11] Abrahamsson, P., Salo, O., Ronkainen, J., Agile Software Development Methods.

Review and Analysis, VTT, 2002.[12] Schwaber, K., Scrum Development Process. Workshop on Business Object Design and

Implementation, OOPSLA´95, 1995.[13] Schwaber, K., Beedle, M., Agile Software Development With Scrum, Prentice Hall,

2002.[14] Cockburn, A., Agile Software Development, Addison Wesley, 2002.[15] Palmer, S. R., Felsing, J. M., A Practical Guide to Feature Driven Development,

Prentice Hall, 2002.[16] Kruchten, P., A Rational Development Process, Crosstalk, 1996.[17] Stapleton, J., Dynamic Systems Development Method - The Method in Practice,

Addison Wesley, 1997.[18] Highsmith, J., Adaptive Software Development: A Collaborative Approach, Dorset

House, 2000.[19] O´Reilly, T., Lessons from Open Source Software Development, ACM, 1999. [20]

Balzer R. A 15 Year Perspective on Automatic Programming. IEEE Transactions onSoftware Engineering, vol.11, núm.11, páginas 1257-1268, Noviembre 1985.

2. REPORTE DE LECTURA.

PREGUNTAS MAS FRECUENTES DE LA INGENIERIA 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 logeneral, 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 elsistema y sitios web que permitan a los usuarios descargar la información de productos recientes.

Tipos de productos de software.

Existen dos productos:

1. Productos genéricos. Son sistemas aislados producidos por una organización de desarrollo yque se venden al mercado abierto a cualquier cliente que le sea posible comprarlos. Ejemplos deeste tipo de producto son el software para Pc´s tales como bases de datos, procesadores de texto,paquetes de dibujo y herramientas de gestión de proyectos.

2. Productos personalizados (o hechos a medida). Son sistemas requeridos por un cliente enparticular. Un contratista de software desarrolla el software especialmente para ese cliente.Ejemplos de este tipo de software son los sistemas de control para instrumentos electrónicos,sistemas desarrollados para llevar a cabo procesos de negocios específicos y sistemas de controldel tráfico aéreo.

¿Qué es la ingeniería del software?

Es una disciplina de la ingeniería que comprende todos los aspectos de la producción de softwaredesde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de éste despuésde que se utiliza.

Disciplina de la ingeniería.

Los ingenieros hacen que las cosas funcionen. Aplican teorías. Métodos y herramientas dondesean convenientes, pero las utilizan de Forma selectiva y siempre tratando de descubrir solucionesa los problemas, aun cuando no existan teorías y métodos aplicables para resolverlos. Losingenieros también saben que deben trabajar con restricciones financieras y organizacionales. Porlo que buscan soluciones tomando en cuenta estas restricciones.

Todos los aspectos de producción de software.

La ingeniería del software no sólo comprende los procesos técnicos del desarrollo de software sinotambién con actividades tales como la gestión de proyectos de software y el desarrollo deherramientas, métodos y teorías de apoyo a la producción de software.

¿Cuál es la diferencia entre ingeniería del software y ciencia de la computación?

Esencialmente, la ciencia de la computación se refiere a las teorías y métodos subyacentes a lascomputadoras y los sistemas de software, mientras que la ingeniería del software se refiere a losproblemas 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éctricosrequieren conocimientos de física.

¿Cuál es la diferencia entre ingeniería del software e ingeniería de sistemas?

La ingeniería de sistemas se refiere a todos los aspectos del desarrollo y de la evolución desistemas complejos donde el software desempeña un papel principal. Por lo tanto, la ingenieríade 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 componentesdel 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. Existencuatro actividades fundamentales de procesos (incluidas más adelante en este libro) que soncomunes para todos los procesos del software.

Actividades

1. Especificación del software donde los clientes e ingenieros definen el software a producir y lasrestricciones sobre su operación.

2. Desarrollo del software donde el software se diseña y programa.

3. Validación del software donde el software se válida para asegurar que es lo que el clienterequiere.

4. Evolución del software donde el software se modifica para adaptarlo a los cambios requeridospor el cliente y el mercado.

¿Qué es un modelo de procesos del software?

Un modelo de procesos del software es una descripción simplificada de un proceso del softwareque presenta una visión de ese proceso. Estos modelos pueden incluir actividades que son partede los procesos y productos de software y el papel de las personas involucradas en la ingenieríadel 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 desoftware que se vaya a desarrollar. Por ejemplo, el software de tiempo real normalmente requiereuna validación y pruebas más extensas que los sistemas basados en web. Sin embargo, cada unode los diferentes enfoques genéricos al desarrollo del software tiene un perfil de distribución decostos diferente a través de las actividades del proceso del software. Si se considera que el costototal del desarrollo de un sistema de software complejo es de 100 unidades de costo.

¿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 funcionalesbá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 fueroncomplementados por métodos orientados a objetos. Como los propuestos por Booch (1994) yRumbaugh (Rumbaugh el al., 1991). Estos diferentes enfoques se han integrado en un soloenfoque unificado basado 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 deatributos asociados que reflejan la calidad de ese software. Estos atribulas no están directamenteasociados 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. Ejemplosde 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.

¿Cuáles son los retos fundamentales que afronta la ingeniería del software?

En el siglo XXI, la ingeniería del software afronta tres retos fundamentales:

1. El reto de la heterogeneidad. Cada vez más. Se requiere que los sistemas operen comosistemas distribuidos en redes que incluyen diferentes tipos de computadoras y con diferentes

clases de sistemas de soporte. A menudo es necesario integrar software nuevo con sistemasheredados más viejos escritos en diferentes lenguajes de programación. El reto de laheterogeneidad es desarrollar técnicas para construir software confiable que sea losuficientemente flexible para adecuarse a esta heterogeneidad.

2. 2. El reto de la entrega. Muchas técnicas tradicionales de ingeniería del softwareconsumen tiempo. El tiempo que éstas consumen es para producir un software de calidad. Sinembargo. Los negocios de hoy en día deben tener una gran capacidad de respuesta y cambiar conmucha rapidez. Su software de soporte también debe cambiar con la misma rapidez. El reto de laentrega es reducir los tiempos de entrega para sistemas grandes y complejos sin comprometer lacalidad del sistema.

3. 3. El reto de la confianza. Puesto que el software tiene relación con todos los aspectos denuestra vida. Es esencial que podamos confiar en él. Esto es especialmente importante ensistemas remotos de software a los que se accede a través de páginas web o de interfaces deservicios web. El reto de la confianza es desarrollar técnicas que de muestren que los usuariospueden confiar en el software.

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

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

Ingeniería del software Asistida por computadora, las herramientas incluyen editores de diseñodiccionarios de datos, compiladores depuradores, herramientas de construcción de sistemas.

Proporciona ayuda al proceso de software automatizando algunas de sus actividades. Proporcionainformación acerca del software en desarrollo.

La tecnología está disponible en la mayoría de las actividades en el proceso del software, permite mejorasen calidad y productividad del software.

Existen varias formas de clasificar las herramientas CASE:

Perspectiva funcional: se clasifican de acuerdo con su función específica. Perspectiva de proceso: se clasifican de acuerdo a las actividades de procesos en el que ayudan. Perspectiva de integración: se clasifican de acuerdo con la forma en la que están organizadas en

unidades.Los bancos de trabajo ayudan a las fases de proceso como la especificación, diseño, consisten en unconjunto de herramientas con algún grado mayor o menor de integración.

Los procesos del software son las actividades relacionadas con la producción del sistema del software.

Todos los procesos del software incluyen la especificación, diseño, implementación, validación y la evolucióndel software.

Los modelos genéricos del proceso describen la organización de los procesos del software.

Los modelos de iteración de procesos presentan el proceso del software como un ciclo de actividades.Ejemplos el desarrollo incremental y el modelo en espiral.

La ingeniería de requerimientos es el proceso de desarrollar una especificación del software.

Los procesos de diseño e implementación comprenden la transformación de la especificación de losrequerimientos en un sistema software ejecutable.

La validación del software es el proceso de verificar que el sistema se ajusta a su especificación y satisfacenecesidades reales.

La evolución del software se interesa en modificar los sistemas software existente para cumplir los nuevosrequerimientos.

El proceso Unificado de Racional es un modelo del proceso moderno y genérico que se organiza en fases(Inicio, elaboración, construcción y transición).

La tecnología CASE proporciono ayuda automatizada a los procesos del software.

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

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 lastareas y responsabilidades de una organización que desarrolla software. Su meta principal es asegurar laproducción de software de alta calidad que cumpla con las necesidades de los usuarios, con una planeacióny 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 elcomportamiento deseado del sistema

Centrado en la Arquitectura: –La arquitectura es utilizada para conceptualizar, construir, administrar yevolucionar el sistema en desarrollo

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

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

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

7. LAS 4 FASES DEL CICLO DE VIDA RUP.

1. Inicio: El objetivo de esta fase es establecer un caso de negocio para el sistema. Se debenidentificar todas las entidades externas (personas y sistemas) que interactuarán con elsistema y definir estas interacciones. Esta información se utiliza entonces para evaluar quéaporte hace el sistema al negocio. Si este aporte es de poca importancia, se cancela elproyecto.

2. Elaboración: Los objetivos de esta fase son: Comprender el dominio del problemaEstablecer un marco de trabajo arquitectónico para el sistema Desarrollar el plan delproyecto Identificar los riesgos clave del proyecto. Al terminar esta fase, conseguimos unmodelo de los requerimientos del sistema (se especifican los casos de uso en UML), unadescripción arquitectónica y un plan de desarrollo del software.

3. Construcción: Esta fase comprende: el Diseño del Sistema, la Programación las Pruebas.En esta fase se desarrollan e integran las partes del sistema. Al terminarla, tenemos: unSistema de Software operativo la Documentación lista para entregar al usuario.

4. Transición: Fase final del RUP. Mueve el sistema desde la comunidad de desarrollo a lacomunidad del usuario y hacerlo trabajar en un entorno real. Esto se deja de lado en lamayor parte de los modelos de procesos del software pero es, en realidad, una actividadde alto costo y problemática. Al terminar esta fase, tenemos un Sistema de SoftwareDocumentado, que funciona correctamente en su entorno operativo.

Tarea 5.Ingeniería en Sistemas.

Ingeniería del Software.Víctor Hugo Ibarra Ortiz.

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

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

CONCEPTOS DE CALIDAD.

Definición: Conjunto de propiedades y de características de un producto o un servicio, que leconfieren aptitud para satisfacer una necesidades explícitas o implícitas (ISO 8402).

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.

CONTRATO:

Contrato es un término con origen en el vocablo latino contractus que nombra al convenio opacto, ya sea oral o escrito, entre partes que aceptan ciertas obligaciones y derechos sobre unamateria determinada. El documento que refleja las condiciones de este acuerdo también recibe elnombre de contrato.

El contrato, en definitiva, es un acuerdo de voluntades que se manifiesta en común entre dos omás personas (físicas o jurídicas). Sus cláusulas regulan las relaciones entre los firmantes en unadeterminada materia.

Modelo RUP

De entre todos los modelos de Ciclo de Vida, exist el Modelo RUP que asegura la producción desoftware de alta calidad que cumpla con las necesidades de los usuarios, con una planeación ypresupuesto predecible.

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.

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

DISEÑO DE INTERFAZ DE USUARIO.

El diseño de la 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 webenfocado a la experiencia del usuario y la interacción.

Es una actividad multidisciplinar que involucra a varias ramas es decir al diseño y el conocimientocomo el diseño gráfico, industrial, web de software y la ergonomía de proyectos.

La interfaz gráfica de usuario conocida también como GUI es un programa informático que actúade interfaz de usuario, utilizando un conjunto de imagen3es y objetos gráficos para representar lainformación y acciones en la interfaz.

TIPOS DE INTERFACES GRAFICAS DE USUARIOS:

GUIS y zooming user interface. Interfaz de usuario de pantalla táctil. Interfaz Natural de Usuario.

PRINCIPIOS DE DISEÑO:

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

PRINCIPIOS BASICOS DE DISEÑO PARA INTERFACES DE USUARIO.

Interfaz amigable: Permite al usuario sentirse cómodo.

Control del usuario: El usuario debe sentir que tiene el control de la aplicación.

Consistencias: El usuario debe sentir que puede manipular la aplicación.

A prueba de errores: Los usuarios pueden equivocarse y corregir sus errores, o simplemente laaplicación no debe permitírselo.

Feedback: Debe mostrarle al usuario cuando está procesando órdenes o realiza tareasinternamente, por ejemplo barras de progreso, puntero en espera, etc.

Directa: Debe permitir al usuario saber sobre lo que sucede en la aplicación.

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

No hay mucho que decir con respecto al hecho de que los sistemas y las aplicaciones' basados enWeb (nos referiremos a estas como WebApps) son muy diferentes de las otras categorías desoftware informático que se tratan los sistemas basados en Web «implican una mezcla depublicación impresa y desarrollo de software, de marketing e informática, de comunicacionesinternas y relaciones externas, y de arte y tecnología». Los atributos siguientes se van a encontraren la gran mayoría de las WebApps.

Intensivas de Red. Por su propia naturaleza, una WebApp es intensiva de red. Reside en una red ydebe dar servicio a las necesidades de una comunidad diversa de clientes. Una WebApp puederesidir en Internet (haciendo posible así una comunicación abierta para todo el mundo). De formaalternativa, una aplicación se puede ubicar en una Intranet (implementando la comunicación atravé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 utilizarhipermedia para presentar al usuario el contenido de textos, gráficos, sonido y vídeo.

Evolución continúa. A diferencia del software de aplicaciones convencional, que evoluciona conuna serie de versiones planificadas y cronológicamente espaciadas, las aplicaciones Web están enconstante evolución. No es inusual que algunas WebApps (específicamente, su contenido) seactualicen cada hora.

Inmediatez. Las aplicaciones basadas en Web tienen una inmediatez [NOR99] que no se encuentraen otros tipos de software. Es decir, el tiempo que se tarda en comercializar un sitio Webcompleto puede ser cuestión de días o semanas3. Los desarrolladores deberán utilizar los métodosde planificación, análisis, diseño, implementación y comprobación que se hayan adaptado aplanificaciones 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 noimposible, limitar la población de usuarios finales que pueden acceder a la aplicación. Con objetode 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 unaWebApp y dentro de la misma aplicación.

Estética. Una parte innegable del atractivo de una WebApp es su apariencia e interacción. Cuandose ha diseñado una aplicación con el fin de comercializarse o vender productos o ideas, la estéticapuede 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 enformularios 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 alusuario a determinar un pago de hipoteca.

Portal: la aplicación canaliza al usuario llevándolo a otros contenidos o servicios Web fuera deldominio 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 yextrae información.

Las características y las categorías destacadas anteriormente en esta sección, y las categorías deaplicaciones representan los hechos reales para los ingenieros de la Web. La clave es vivir dentrode las restricciones impuestas por las características anteriores y aun así tener éxito en laelaboración de la WebApp.

12. INVESTIGACIONES ESPECIALES:

FRAMEWORKS.

En el desarrollo de software, un framework o infraestructura digital, es una estructura conceptualy 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 incluirsoporte 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 deldominio, y provee una estructura y una especial metodología de trabajo, la cual extiende o utilizalas aplicaciones del dominio.

Básicos

No es más que una base de programación que atiende a sus descendientes (manejado de unaforma estructural y/o en cascada), posibilitando cualquier respuesta ante las necesidades de susmiembros, o en secciones de una aplicación (web), satisfaciendo así las necesidades más comunesdel programador.

Arquitectura

Dentro de este aspecto, podemos basarnos en el modelo MVC (Controlador => Modelo => Vista),ya que debemos fragmentar nuestra programación. Tenemos que contemplar estos aspectosbásicos en cuanto a la implementación de nuestro sistema:

Modelo:

Este miembro del controlador maneja las operaciones lógicas, y de manejo de información(previamente enviada por su ancestro), para resultar de una forma explicable y sin titubeos. Cadamiembro debe ser meticulosamente llamado, con su correcto nombre y en principio, con suverdadera naturaleza: el manejo de información, su complementación directa.

Vista:

Al final, a este miembro de la familia le corresponde dibujar, o expresar la última forma de losdatos: la interfaz gráfica que interactúa con el usuario final del programa (GUI). Después de todo, aeste miembro le toca evidenciar la información obtenida hasta hacerla llegar al controlador. Solo(e inicialmente), nos espera demostrar la información.

Controlador:

Con este apartado podemos controlar el acceso (incluso todo) a nuestra aplicación, y esto puedeincluir: archivos, scripts, y/o programas; cualquier tipo de información que permita la interfaz. Así,

podremos diversificar nuestro contenido de forma dinámica, y estática (a la vez); pues, sólodebemos controlar ciertos aspectos (como se ha mencionado antes).

Estructura

Dentro del controlador, modelo o vista podemos manejar lo siguiente: datos. Depende denosotros como interpretar y manejar estos 'datos'. Ahora, sabemos que el único dato de unadirección estática web es: conseguir un archivo físico en el disco duro o de internet, etc. einterpretado o no, el servidor responde.

El modelo, al igual que el controlador y la vista, maneja todos los datos que se relacionen consigo(solo es el proceso medio de la separación por capas que ofrece la arquitectura MVC). Y sólo lavista, puede demostrar dicha información. Con lo cual ya hemos generado la jerarquía de nuestroprograma: Controlador, Modelo y Vista.

Son diseñados con la intención de facilitar el desarrollo de software, permitiendo a los diseñadoresy programadores pasar más tiempo identificando requerimientos de software que tratando conlos tediosos detalles de bajo nivel de proveer un sistema funcional. Por ejemplo, un equipo queusa Apache Struts para desarrollar un sitio web de un banco, puede enfocarse en cómo los retirosde ahorros van a funcionar en lugar de preocuparse de cómo se controla la navegación entre laspáginas en una forma libre de errores. Sin embargo, hay quejas comunes acerca de que el uso deframeworks añade código innecesario y que la preponderancia de frameworks competitivos ycomplementarios significa que el tiempo que se pasaba programando y diseñando ahora se gastaen aprender a usar los frameworks.

Fuera de las aplicaciones en la informática, puede ser considerado como el conjunto de procesos ytecnologías usados para resolver un problema complejo. Es el esqueleto sobre el cual variosobjetos son integrados para facilitar una solución dada.

Los mejores frameworks son especialmente buenos para organizar proyectos de gran magnitud, ya su vez tratando de mantenerse fuera del camino, sin imponerse por sobre el proyecto.

Web Application Frameworks

Ruby on Rails Framework MVC basado en Ruby, orientado al desarrollo de aplicaciones web

CodeIgniter Poderoso framework PHP liviano y rápido

Django Framework Python que promueve el desarrollo rápido y el diseño limpio

CakePHP Framework MVC para PHP de desarrollo rápido

Zend Framework Framework para PHP 5, simple, claro y open-source

Yii Framework PHP de alto rendimiento basado en componentes

Pylons Framework web para Python que enfatiza la flexibilidad y el desarrollo rápido

Catalyst Framework para aplicaciones web MVC elegante

Symfony Framework full-stack

TurboGears Próxima generación construido sobre Pylons

TAREA 2.

VICTOR HUGO IBARRA ORTIZ.

INGENIERIA EN SISTEMAS.

INGENIERIA DEL SOFTWARE.

CD. OBREGON, SONORA A 20 DE MAYO DE 2013.

LENGUAJE MODELADO UNIFICADO (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 de las metas principales de UML es avanzar en el estado de la integración institucionalproporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sinembargo para lograr un intercambio exitoso de modelos de información entre herramientas, serequirió definir a UML una semántica y una notación.

La notación es la parte gráfica que se ve en los modelos y representa la sintaxis del lenguaje demodelado. Por ejemplo, la notación del diagrama de clases define como se representan loselementos y conceptos como son: una clase, una asociación y una multiplicidad. ¿Y qué significaexactamente una asociación o multiplicidad en una clase?. Un metamodelo es la manera de definiresto (un diagrama, usualmente de clases, que define la notación).

Para que un proveedor diga que cumple con UML debe cubrir con la semántica y con la notación.

Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismomodelo. Bajo esta definición una herramienta que solo dibuje, no puede cumplir con la notaciónde UML.

El lenguaje está dotado de múltiples herramientas para lograr la especificación determinante delmodelo, pero en nuestro caso se trabaja en forma simplificada sobre:

Modelamiento de Clases. Casos de Uso. Diagrama de Interacción.

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

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.

MICROSOFT PROJECT.

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 2013 es la más reciente afebrero de 2013) es útil para la gestión de proyectos, aplicando procedimientos descritos en elPMBoK (Project Management Body of Knowledge) del Project Management Institute.

En definitiva la funcionalidad de Microsoft Project varía poco respecto a la versión de 2010 pero seabre un abanico interesante de posibilidades con los nuevos campos que han incorporado asícomo con el nuevo motor de generación de informes.

COBOL.

COmmon Business -Oriented Language - Lenguaje Común Orientado a Negocios). COBOL es unlenguaje de programación creado en 1960 con el objetivo de crear un lenguaje universal paracualquier tipo de computadora, orientado a la informática de gestión.

Este lenguaje fue creado por la comisión CODASYL, compuesta de fabricantes de computadoras,usuarios y el Departamento de Defensa de EE.UU., creada en mayo de 1959.

La definición se completó unos seis meses más tarde y fue aprobada por la comisión en enero de1960.

COBOL fue diseñado a partir del lenguaje FLOW-MATIC de Grace Hopper y el IBM COMTRAN deBob Bemer (ambos participantes de la comisión CODASYL).

COBOL fue revisado en 1961 y 1965 para añadirle funcionalidades. En 1968 llegó la primer versiónANSI del lenguaje, para luego revisarse en 1974 (COBOL AND-74), 1985 (COBOL ANS-85) y 2002(COBOL ANS-2002).

COBOL fue dotado de unas excelentes capacidades de autodocumentación.

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

INTELIGENCIA ARTIFICIAL.

Básicamente, la inteligencia artificial es aquella que trata de explicar el funcionamiento mentalbasándose en el desarrollo de algoritmos para controlar diferentes cosas. La inteligencia artificialcombina varios campos, como la robótica, los sistemas expertos y otros, los cuales tienen unmismo objetivo, que es tratar de crear máquinas que puedan pensar por sí solas, lo que originaque hasta la fecha existan varios estudios y aplicaciones, dentro de las que se encuentran las redesneuronales, el control de procesos o los algoritmos genéticos.

La idea de construir una máquina que pueda pensar es que realice cosas que nosotros realizamosy hacemos. Pero para que las computadoras se ganen el nombre de inteligentes, primero tienenque ser capaces de mantener, por ejemplo, un diálogo con un ser humano, ya que lascomputadoras únicamente pueden realizar o hacer lo que se les indique, pero nunca sabrán lo queestán realizando pues no están conscientes de lo que hacen.

Tarea 7.

Ingeniería del Software.

Ingeniería en Sistemas.

Víctor Hugo Ibarra Ortiz.

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

REQUISITEPRO.

IBM Rational RequisitePro es una herramienta de gestión de requisitos y casos prácticos para losequipos de proyecto. Los equipos pueden crear y compartir sus requisitos mediante métodosconocidos basados en documentos, al tiempo que utilizan funciones de la base de datos como larastreabilidad y el análisis de impacto. De esta manera se mejora la gestión de requisitos ycomunicación, se aumenta la calidad y se acelera el tiempo de comercialización.

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

Evitar tareas de remodelación y duplicaciones gracias a la integración avanzada en tiemporeal con Microsoft Word.

Gestionar la complejidad con vistas de rastreabilidad detalladas que muestran relacionespadre-hijo.

Mejorar la colaboración de equipos distribuidos geográficamente a través de una interfazweb escalable totalmente funcional e hilos de debate.

Capturar y analizar información de requisitos con personalización y filtrado detallado deatributos.

Aumentar la productividad haciendo un seguimiento de los cambios mediantecomparaciones de las versiones del proyecto con líneas base de proyecto basadas en XML

Ajustar los objetivos empresariales con los productos finales del proyecto mediante laintegración con varias herramientas en la plataforma de desarrollo y distribución desoftware de IBM Rational.

Evitar tareas de remodelación y duplicaciones

Es compatible con Microsoft Word para la creación y la comunicación de requisitos. Complementa las entradas basadas en documentos con una base de datos comercial para

añadir funciones de organización, seguimiento y gestión. Ofrece integración con Microsoft Word como una opción para dar soporte a los equipos

que prefieren un enfoque de base de datos.Gestionar la complejidad con vistas de rastreabilidad detalladas

Establece y realiza el seguimiento de relaciones entre los requisitos para verificar que losrequisitos de alto nivel aparecen representados en las especificaciones detalladas de losrequisitos del software.

Le permite consultar estas relaciones para realizar análisis de cobertura. Garantiza laintegridad y le permite no malgastar tiempo construyendo parte del sistema que no esnecesaria.

Genera informes detallados que cumplen con los estándares. Puede crear, consultar yexportar matrices de rastreabilidad filtrables e informes de atributos para satisfacer lasnecesidades de auditoría interna y externa.

Mejorar la colaboración

Garantiza que los equipos distribuidos tiene acceso de lectura y grabación a los requisitosestén donde estén.

Permite que cualquiera que tenga acceso a la web, desde cualquier plataforma, puedaconsultar, crear y gestionar requisitos sin tener Rational RequisitePro cargado en sumáquina.

Permite completar la administración del proyecto a través de la web.Capturar y analizar requisitos

Facilita la configuración de los requisitos, atributos y tipos de documentos. Define consultas y filtros para poder encontrar rápidamente información de interés. Se adapta a su proceso. Los miembros del equipo pueden crear vistas que muestren la

información que necesitan. Incluye la notificación automática por correo electrónico a los participantes en caso de

que los requisitos cambien.Aumentar la productividad

Crea una línea base basada en XML de requisitos del proyecto. Puede utilizarla paraimpulsar nuevos proyectos o compararla con otras líneas base de otros proyectos,presentando los cambios y las omisiones en los requisitos con varios niveles de detalles.

Admite el desarrollo paralelo, en el que coexisten varios conjuntos de requisitos. Determina cuándo y dónde se producen los cambios para reducir la confusión del equipo y

clarificar el efecto de las decisiones tomadas en el proyecto a lo largo del tiempo.Ajustar los objetivos empresariales con los productos finales del proyecto

Permite acceder uniformemente a la información sobre los requisitos y modificarlamediante productos en la plataforma de distribución de software de IBM.

Sincroniza a todo el equipo y proporciona rastreabilidad completa en todo el ciclo de vidamediante la integración con estos productos.

Tarea 8.

Ingeniería del Software.

Ingeniería en Sistemas.

Víctor Hugo Ibarra Ortiz.

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

SECOND LIFE.

¿Qué es SecondLife? SecondLife es un mundo virtual en 3D creado y disfrutado íntegramente porsus residentes. Desde que en 2003 se abriera al público, ha estado creciendo a pasos agigantadossituándose en la actualidad en una comunidad de 4,626.128 habitantes procedentes de todas laspartes del mundo.

Desde el momento en el que entras en “El Mundo Virtual” descubres un enorme continente digitalabarrotado de gente, lleno de entretenimiento, de nuevas experiencias y de oportunidades. Unavez que hayas explorado un poco quizás encuentres la parcela de tierra en la que quieres construirtu casa o negocio. Te verás rodeado o rodeada por las creaciones de los otros residentes entiempo real. Todos los residentes poseen los derechos de propiedad sobre sus creaciones digitalesy podrán venderlas, comprar otras o realizar cualquier tipo de negocio con otros residentes. ElParqué de SedondLife soporta, en la actualidad, millones de dólares en transacciones mensuales.Esta compraventa se gestiona utilizando la unidad de comercio que se utiliza dentro del mundovirtual: el dólar Linden, el cual se podrá cambiar por dólares americanos en los diferentes yprósperos mercados de valores online del Dólar Linden.

Lo más destacable de SecondLife es que constantemente está cambiando y creciendo. Acontinuación les mostramos por qué: Cada día se unen y crean un avatar miles de nuevosresidentes. Dichos avatares exploran el mundo virtual además de conocer gente nueva. Dichagente descubre las miles de maneras que existen de divertirse. Muchos de ellos deciden comprartierra virtual lo que les permite abrir un negocio, construir su propio paraíso virtual y mucho más.Linden Lab crea suelo nuevo para estar al día con la demanda. Lo que empezó siendo 259.008 m2de tierra en 2003 se sitúa ahora por encima de los 263,055.000 m2 y creciendo a gran velocidad.

Crear un avatar Secondlife se fundamenta en la expresión y tu avatar es la expresión de tu personapor antonomasia. Después de todo, el avatar eres tú (quién tú decides ser) en un mundo virtual. Laherramienta utilizada para personalizar el avatar pone a tu disposición infinidad de posibilidades,se trata de una herramienta muy fácil de usar y que te permitirá realizar todos los cambios quequieras, desde cómo quieres que sea tu nariz hasta el tono de la piel. No te preocupes si alprincipio tu avatar no es todo lo perfecto o perfecta que deseas ya que podrás cambiar su aspectoen cualquier momento.

Conocer gente Durante la primera hora te darás cuenta de que muchos residentes se acercan a tipara presentarse y es que los habitantes de SecondLife están ansiosos por darte la bienvenida ymostrarte el entorno. Dentro de una sociedad tan entusiasta, resulta sencillo encontrar gente quecomparte tus intereses. Una vez que conoces al grupo que te gusta, será muy fácil comunicarte yestar en contacto con ellos. En cualquier momento podrás asistir al acontecimiento que desees, ladiversión está en todas partes, desde clubs de baile y desfiles de moda hasta exposiciones de arteo simplemente jugar a algún juego. Los residentes forman grupos que pueden ser de diferentestipos, desde asociaciones de vecinos hasta fans de películas de ciencia ficción.

SecondLife está en contra del aburrimiento y por eso en cada esquina podrás encontrar una nuevadiversión. Se trata de un mundo repleto de juegos, RPG para multijugadores, puzles e incluso unaamplia parrilla de concursos. Así mismo, dispone de casinos, clubs de baile, centros comerciales,estaciones espaciales, cines y hasta castillos de vampiros. Para encontrar algo que hacer, ya sea dedía o de noche, simplemente tienes que abrir el menú “Search” y hacer clic en “events”.Encontrarás una lista de temas: deportes, comercio, entretenimiento, juegos, desfiles, educación,arte y cultura; además, podrás acceder a grupos de apoyo y benéficos. Sea cual sea tu estado deánimo, siempre encontrarás algo que hacer que se adapte a tus gustos.

En SecondLife puedes crear lo que quieras y cómo quieras gracias a potentes herramientas queademás son muy fáciles de usar. En SecondLife tendrás la posibilidad de construir una vida sinnecesidad de aplicaciones externas que tengas que comprar o aprender a usar; de hecho, recibirástoda la ayuda que necesites para construir tus creaciones utilizando la sencillez como base a lahora de aprender, sin dejar de lado que se trata de herramientas muy sólidas y fuertes queinspirarán tu creatividad.

CONCLUSION.

En lo personal la materia de Ingenieria del Software es una herramienta de gran utilidadpara poder entender lo que viene siendo la forma correcta del desarrollo, operación ymantenimiento de software.

No me queda más que agradecer la manera en que fue impartida la clase, ya que nosmotivó a dar lo mejor de nosotros, logrando así comprender que es una herramienta muyútil en nuestra carrera.

El objetivo planteado en la introducción se cumplió, ya que se pudo observar a lo largo deldesarrollo los diferentes usos de las funciones en la carrera de Ingeniería en Sistemas, alhaber también estudiado la mayoría de temas nos queda un modelo que podemos aplicarfrente a cierta problemática. Creemos que el resultado obtenido tras este portafolio fuepositivo, ya que se cumple la consigna en cuanto a la información teórica, y creemos quetambién este nos será útil en la práctica.

portafolio de evidencias ingenieria del software

Documents