portafolio de evidencias by Jesus Remedios

Introducción a la Ingeniería de Software

Análisis de los Requerimientos Es una tarea que cubre el hueco entre la definición del software a nivel sistema y el diseño del mismo.

Conoce las distintas fases de desarrollo por las que pasa un proyecto informático, así como las actividades de gestión necesarias para lograr finalizar el proyecto con éxito.

Modelos del proceso de la ingeniería de software

Diseño

Es una descripción simplificada de un proceso del software que presenta una visión de ese proceso

El diseño de software es el proceso por el que un agente crea una especificación de un artefacto de software, pensado para cumplir unos objetivos, utilizando un conjunto de componentes primitivos y sujeto a restricciones.

Objetivo de la revista

El objetivo de esta portafolio es hacer la entrega de recopilaciones de cada una de las tareas que hicimos en el primer parcial y lo hice en modo revista para que sea un poco mas atractivo de leer y ver. En este portafolio tambiĂŠn contiene las 4 unidades de la materia que estuvimos viendo en las clases-

Datos del editor JESÚS REMEDIOS DE LA ROSA ARIAS CONTACTO: jesus5742dls@gmail.com

Datos de la asesora Universidad Juárez Autónoma de tabasco

DRA. LAURA BEATRIZ VIDAL TURRUBIATES

División académica de Ciencias y tecnologías De la información

CONTACTO: Laura.vidal@ujat.mx

Índice: Portada……………………………………………..1 Objetivo de la revista…………………………...…2 Datos del editor………………………………..…..3 Índice………………………………………………..4

Primer parcial…………………………5 5 aplicaciones para ayuda a usuario final……6-7 Planteamiento del problema……………………8-9 Unidad 1 resumen ……................................... 10-19 Diagrama de navegación………………………20-21 Ciclo del desarrollo del software……………....22-23 Como crear diagrama de casos……………….24-25 Ejemplos de casos de usos UML…………..…26-29 Industria 4.0………………………………....…..30-31

Segundo parcial………………………32 Unidad 1. Introducción a la Ingeniería de Software 1.1. Conceptos Básicos……………………...……34 1.2. Evolución del Software……………………….35 1.3. Características del Software…………..…….35 1.3.1.Elementos…………………. …………….….36 1.3.2.Estructura…………………. …………..…….36 1.4. Importancia de la IS…………………. ...…….37 1.5. Capas de la IS…………………. …..….…..…37 1.6. Clasificación de los Software………….…….38 1.7. Paradigmas de Ingeniería de Software…….39 1.7.1.El enfoque estructurado…………………….39 1.7.2.El enfoque orientado a objetos………….…40 1.7.3.Importancia de las herramientas………..…40 CASE en la Ingeniería de software.

Unidad 2. Modelos del proceso de la ingeniería de software

Unidad 3. Análisis de los Requerimientos 3.1. Ingeniería de requerimientos………………53 3.2. Establecer las bases………………………..54 3.2.1.Identificación de los participantes……..…54 3.2.2.Reconocer los múltiples puntos de………54 vista 3.2.3.Trabajar hacia la colaboración……………54 3.2.4.Hacer las primeras preguntas……….……54 3.3. Indagación de los requerimientos…………55 3.3.1.Recopilación de los…………………..……55 requerimientos en forma colaborativa 3.3.2.Despliegue de la función de………………55 calidad 3.3.3.Escenarios de uso………………………….55 3.3.4.Indagación de los productos del…….……55 trabajo 3.4. Requerimientos de las negociaciones…….56 3.5. Validación de los requerimientos. …………56

Unidad 4. Diseño 4.1. Diseño en el contexto de la…………………58 ingeniería de software 4.2. Lineamientos y atributos de la………..……59 calidad del software 4.3. Conceptos de diseño……………………..…60 4.3.1.Abstracción…………………. ……..………60 4.3.2.Arquitectura…………………. ………..……60 4.3.3.Patrones…………………. …………………60 4.3.4.División de problemas……………….…….60 4.3.5.Modularidad…………………………….…..61 4.3.6.Ocultamiento de la información……..……61 4.3.7.Independencia funcional………………..…61 4.3.8.Refinamiento……………………….........…61 4.3.9.Aspectos…………………. …………..….…61 4.3.10. Conceptos de diseño………………...….61 orientado a objetos 4.3.11. Clases de diseño………………………..…62

2.1. Un modelo General de proceso…………..….42 2.1.1.Definición de actividad estructural……..…..42 2.1.2.Identificación de un conjunto de tareas….…43 2.1.3.Patrones del proceso……………………..….43 2.2. Modelos de proceso prescriptivo…………….44 Tercer parcial…………………………63 2.2.1.Modelo en Cascada……………………….…44 Proyecto Avisos Ujat .…………………………..64 2.2.2.Modelo del Proceso Incremental…….….….45 Video Teams ……………………………………65 2.2.3.Modelo de Proceso Evolutivo……………….45 2.2.4.Modelos Concurrentes…………………..…..46 Archivos complementarios …………….……...66 2.3. Modelos de proceso especializado………….47 2.3.1.Desarrollo basado en componentes…….…48 Conclusión ………………………………………67 2.3.2.Modelo de métodos formales…………….…49 Referencia ……………………………………68-69 2.3.3.Desarrollo de software orientado a aspectos….49 2.4. El proceso unificado…………………. …………...50 Logo ……………………………………….……70 2.4.1.Fases del proceso unificado…………………….51

PRIMER PARCIAL

5 Aplicaciones que ejemplifiquen una ayuda para el usuario final

1. 5 Aplicaciones que ejemplifiquen una ayuda para el usuario final

Planteamiento del problema

2. Planteamiento del problema

Unidad 1

3. Unidad 1

Construcciรณn del diagrama de flujo

4. Construcciรณn del diagrama de flujo

Ciclo del desarrollo del software

5. Ciclo del desarrollo del software

Como crear un diagrama de casos

6. Como crear un diagrama de casos

5 Ejemplos de casos de usos UML

7. 5 Ejemplos de casos de usos UML

En que consiste la industria 4.0

8. En que consiste la industria 4.0

SEGUNDO PARCIAL

Unidad 1

Introducción a la Ingeniería de Software

1.1 Conceptos Básicos El software consiste en los programas de instrucciones y datos que definen para el hardware los algoritmos necesarios para la resolución de problemas.

Software de usuario final

Software de sistemas • Es un conjunto de programas que administran los recursos de la computadora.

Software de aplicaciones • Programas que son escritos para o por los usuarios para realizar una tarea específica en la computadora. 34

• Es el software que permiten el desarrollo de algunas aplicaciones directamente por los usuarios finales, el software del usuario final con frecuencia tiene que trabajar a través del software de aplicación y finalmente a través del software del sistema

1.2 Evolución del software El software comenzó en el año de 1950, pero en ese año apenas era un software añadido y existían pocos método para programar y el software se diseñaba a medidas. Pero ya en el año de 1965 ya podían analizar y transferir datos múltiples de fuentes, el software se desarrollaba para el comercio, atreves de eso se empezó a distribuir software para grandes computadoras y minicomputadoras. Pero ya hasta el año de 1985 que ya había tecnología orientada a objetos y programación de realidad virtual y sistemas multimedia.

1.3 Característica del software

Corrección

Usabilidad

Seguridad

Portabilidad

• Que cumpla con su objetivo. • Que cumpla con su objetivo. • Que sea resistente a ataques externo. • Que pueda ser utilizado en diversos equipos.

1.3.1 Elementos • Sistemas operativos • Evolución de los sistemas operativos • Lenguajes de programación • Procesadores de lenguaje

1.3.2 Estructura del software • Sistemas operativos • Programas • Lenguaje de programación 36

1.4 Importancia de la I. S. La ingeniería de software es muy importante ya que con ella se puede analizar, diseñar, programar y aplicar un software de manera correcta y organizada, cumpliendo con todas las especificaciones del cliente y el usuario final. ... Mejorar la calidad de los productos de software.

1.5 Capas de la I. S. Herramientas

Proceso

El fundamento de la ingeniería del software es la capa de proceso.

Las herramientas de la Ingeniería del software proporcionan un enfoque automático o semiautomático para el proceso y para los métodos.

Métodos

Enfoques de calidad La calidad de un sistema software debe ser programada desde el inicio del proyecto, y posteriormente en cada etapa del proceso de desarrollo.

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

1.6 Clasificación de los software

software • de sistemas

Se llama Software de Sistema o Software de Base al conjunto de programas que sirven para interactuar con el sistema.

software de aplicación software de programación

• El Software de Aplicación son los programas diseñados para o por los usuarios para facilitar la realización de tareas específicas en la computadora. • El Software de Programación es el conjunto de herramientas que permiten al desarrollador informático escribir programas usando diferentes alternativas y lenguajes de programación.

1.7 Paradigmas de la I. S. Para la Ingeniería de Software el paradigma es una agrupación de métodos, herramientas y procedimientos con el fin de describir un modelo. ... Los paradigmas o modelos de desarrollo de software más utilizados son: el método de cascada, el método de prototipos y el de Espiral.

1.7.1 Enfoque Estructurado Es un método para el análisis de sistemas • Símbolos gráficos: Son los iconos de convenciones para identificar y describir componentes • Diccionario de datos: Descripciones de todos los datos utilizados en el sistema • Descripciones de procesos y procedimientos: Declaraciones normales que implican técnicas • Reglas: Estándares para describir y documentar el sistema en forma correcta y compleja

1.7.2 Enfoque Orientado a Objetos Se centra en identificar los objetos del dominio de la aplicación y después establecer los dominios que lo manejan

• Identidad: Los datos se centran en organizaciones discretas llamadas objetos • Clasificación: Los objetos que tengan los mismos atributos y componentes se organizan en clases • Polimorfismo: Permite que la misma operación pueda llevarse a cabo de forma diferente en clases diferentes • Herencia: Operaciones basadas en una relación jerárquica entre varias

1.7.3 Importancia de las herramientas case Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas o programas informáticos destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero.

• Tipos de CASE • Middle CASE (M-CASE) • Upper CASE (U-CASE) • Lower CASE (L-CASE)

Unidad 2

Modelos del proceso de la ingenierĂa de software

2.1 Un modelo general de proceso Un modelo de proceso es un conjunto de actividades, tareas y acciones que se realizan con el fin de alcanzar el desarrollo completo de un proyecto de software. Existen diferentes modelos de proceso tales como los prescriptivos que se utilizan cuando los requerimientos de software se encuentran bien definidos, los especializados que incluyen las características de uno o más modelos tradicionales y se utilizan cuando el enfoque del proyecto se encuentra bien definido.

2.1.1 Definición de actividad estructural COMUNICACIÓN

PLANEACIÓN

MODELADO

Son aquellas actividades que van a servir de cimiento durante todo el proceso de desarrollo de la aplicación.

DESPLIEGUE

CONSTRUCCION

2.1.2 Identificación de un conjunto de tareas Definir, con la mejor calidad posible, las características de un sistema software que satisfaga las necesidades de negocio de clientes y usuarios y que se integre con éxito en el entorno en el que se explote. La definición de dicho sistema se realiza mediante lo que se conoce como una especificación de requisitos.

•Determinación del Ámbito: Involucra ámbito de proyecto. •Planeación preliminar: Se crea la habilidad del equipo de trabajo para realizar el proyecto. •Valoración del Riesgo: Determina el riesgo involucrado en la tecnología que se implementara. •Prueba: Muestra la viabilidad del proyecto. •Implementación: Se lleva a la práctica el proyecto, para que pueda ser revisado por el cliente o propósitos a fines. •Reacción del Cliente: Existe una retroalimentación.

2.1.3 Patrones del proceso Un patrón de proceso ofrece una plantilla: un método consistente para describir una característica importante del proceso de software. Se definen en cualquier grado de abstracción (un proceso completo o una actividad del marco de trabajo importante o una tarea dentro de una actividad del marco de trabajo).

2.2 Modelos de procesos prescribtivos Existen cuatro modelos de procesos descriptivos que son: Modelo Cascada, Incremental, Evolutivo y Concurrentes

Definen un conjunto claro de actividades, acciones tareas, hitos y productos de trabajo requeridos para construir software de calidad.

2.2.1 Modelo en cascada

Requerimientos y Análisis Diseño

Implementación

Pruebas Mantenimiento

2.2.2 Modelo de proceso incremental El modelo incremental combina elementos del modelo en cascada con la filosofĂa interactiva de construcciĂłn de prototipos. Se basa en la filosofĂa de construir incrementando las funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software.

2.2.3 Modelo de proceso evolutivo

2.2.4 Modelos concurrentes El modelo concurrente tiene la capacidad de describir las múltiples actividades del software ocurriendo simultáneamente. ... El modelo de proceso concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la ingeniería del software.

2.3 MODELOS DE PROCESO ESPECIALIZADO Modelos de procesos especializados: Tienden a aplicarse cuando se elige un enfoque de ingeniería de software más especializado que el de los modelos tradicionales. Una parte del código, que hace que se cumpla alguna función o se cubra un requerimiento del cliente. La unión de los componentes, forman el software. • Los modelos siguientes:

proceso

especializados

son

los

Desarrollo basado en componente •Un componente es una pieza de código pree laborado que encapsula alguna funcionalidad expuesta a través de interfaces estándar. Es algo muy similar a lo que podemos observar en el equipo de música que tenemos en nuestra sala. Cada componente de aquel aparato ha sido diseñado para acoplarse perfectamente con sus pares, las conexiones son estándar y el protocolo de comunicación está ya preestablecido. Al unirse las partes, obtenemos música para nuestros oídos.

El modelo de métodos formales •La denominación métodos formales se usa para referirse a cualquier actividad relacionada con representaciones matemáticas del software, incluyendo la especificación formal de sistemas, análisis y demostración de la especificación, el desarrollo transformacional y la verificación de programas. Todas estas actividades dependen de una especificación formal del software.

Desarrollo de software orientado a aspectos •El enfoque orientado a aspectos define un mecanismo que ayuda a resolver problemas de codificación en los requisitos, los cuales son un código disperso (scattered) y diseminado (tangled), que no se resuelven fácilmente usando el enfoque orientado a objetos. Este mecanismo se enfoca principalmente en la separación de intereses (separation ofconcerns) de un sistema para obtener una mejor modularización

2.3.1 Desarrollo basado en componentes El desarrollo de software basado en componentes permite reutilizar piezas de código pre elaborado que permiten realizar diversas tareas, conllevando a diversos beneficios como las mejoras a la calidad, la reducción del ciclo de desarrollo y el mayor retorno sobre la inversión. Características de un Componente •Identificable: Debe tener una identificación que permita acceder fácilmente a sus servicios que permita su clasificación. •Auto contenido: Un componente no debe requerir de la utilización de otros para finiquitar la función para la cual fue diseñado. •Puede ser remplazado por otro componente: Se puede remplazar por nuevas versiones u otro componente que lo remplace y mejore. •Con acceso solamente a través de su interfaz: Debe asegurar que estas no cambiaran a lo largo de su implementación. •Sus servicios no varían: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su implementación sí. •Bien Documentado: Un componente debe estar correctamente documentado para facilitar su búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc. •Es genérico: Sus servicios deben servir para varias aplicaciones. •Reutilizado dinámicamente: Puede ser cargado en tiempo de ejecución en una aplicación. •Independiente de la plataforma: Hardware, Software, S.O.[9]

2.3.2 Modelo de métodos formales Los métodos formales permiten representar la especificación del software, verificación y diseño de componentes mediante notaciones matemáticas. ... Permiten especificar el sistema mediante un concepto formal de estados y operaciones sobre estados. La denominación métodos formales se usa para referirse a cualquier actividad relacionada con representaciones matemáticas del software, incluyendo la especificación formal de sistemas, análisis y demostración de la especificación, el desarrollo transformacional y la verificación de programas. Todas estas actividades dependen de una especificación formal del software.

2.3.3 Desarrollo de software orientado a aspectos Este se orienta a la obtención de productos de software de calidad con partes más reutilizables y que evolucionen fácilmente en el tiempo. En este artículo, se presenta un caso de estudio para ilustrar la aplicación del DSOA desde etapas tempranas del desarrollo de software hasta la implementación. Diferentes enfoques orientados por aspectos se aplican par a facilitar el manejo separado de intereses desde su identificación, representación en UML (análisis y el diseño), hasta su implementación en el lenguaje AspectJ . 49

2.4 El proceso unificado El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento mĂĄs conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational (RUP) o simplemente UP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especĂficos. De la misma forma, el Proceso Unificado de Rational, tambiĂŠn es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.

2.4.1 Fases del proceso unificado El RUP es un modelo en fases que identifica cuatro fases diferentes en el proceso del software. INICIO

ELABORACIÓN

1. Inicio. El objetivo de la fase de inicio es el de establecer un caso de negocio para el sistema. Se deben identificar todas las entidades externas (personas y sistemas) que interactuarán con el sistema y definir estas interacciones. 2. Transición. Se ocupa de mover el sistema desde la comunidad de desarrollo a la comunidad del usuario y hacerlo trabajar en un entorno real. Al terminar esta fase, se debe tener un sistema software documentado que funciona correctamente en su entorno operativo.

CONSTRUCCIÓN

TRANSICIÓN

Fases del proceso unificado 3. Elaboración. Los objetivos de la fase son desarrollar una comprensión del dominio del problema, establecer un marco de trabajo arquitectónico para el sistema, desarrollar el plan del proyecto e identificar los riesgos clave del proyecto. Al terminar, se debe tener un modelo de los requerimientos del sistema (se especifican los casos de uso UML), una descripción arquitectónica y un plan de desarrollo del software.

4. Construcción. La fase de construcción fundamentalmente comprende el diseño del sistema, la programación y las pruebas. Durante esta fase se desarrollan e integran las partes del sistema. Al terminar esta fase, debe tener un sistema software operativo y la documentación correspondiente lista para entregarla a los usuarios.

Unidad 3

Anรกlisis de los Requerimientos

3.1 Ingeniería de requerimientos o requisitos.

Ingeniería de requisitos. La ingeniería de requisitos es el conjunto de actividades y tareas del proceso de desarrollo de sistemas software que tiene como objetivos: ... La definición de dicho sistema se realiza mediante lo que se conoce como una especificación de requisitos. Algunos requisitos de la ingeniería: •

Entender lo que desea el cliente

•

Analizar las necesidades

•

Evaluar la factibilidad

•

Negociar una solución razonable

•

Especificar la solución sin ambigüedades

•

Validar la especificación

•

Administrar los requerimientos a medida que se transformen en un sistema funcional

3.2 Establecer las bases

3.2.1 Identificación de los participantes • Cualquier persona que se beneficie en forma directa o indirecta del sistema en desarrollo

3.2.2 Reconocer los múltiples puntos de vista Los requerimientos del sistema se explorarán desde distintos puntos de vista recolectar cada información de cada participante puede ser inconsistente entre sí o conflictiva, pero se debe clasificar y elegir la que tenga coherencia interna.

3.2.3 Trabajar hacia la colaboración.

3.2.4 Hacer las primeras peguntas

• La importancia de la colaboración en el lugar de trabajo.

• Hacer la segunda pregunta.

• Todo depende de trabajar bien en equipo.

• Hacer preguntas sobre las escrituras.

• Un efectivo trabajo

• Procurar las respuestas mas eficientes. • Escribir las preguntas de ante mano. • No tener temor al silencio.

3.3 Indagación de los requerimientos. La indagación de los requerimientos (actividad también llamada recabación de los requerimientos) combina elementos de la solución de problemas, elaboración, negociación y especificación

3.3.1 Recopilación de los requerimientos en forma colaborativa • • • • • • • • •

Preparación Entrevistar al personal adecuado Duración. Formato. Escenarios Puntos de vista Cuestionarios Tormenta de ideas Observación

3.3.2. Despliegue de la función de calidad • •

Es una metodología usada en la ingeniería de la calidad. Permite calcular de forma matemática qué características debemos añadir al diseñar un producto o servicio.

3.3.3. Escenarios de uso Es una secuencia de acciones e interacciones (pasos) entre los usuarios (actores) y el sistema Es una manera específica de utilizar el sistema, es una historia que describe un uso particular del sistema .

3.3.4. Indagación de los productos del trabajo ✓ Un enunciado de la necesidad y su factibilidad. ✓ Un enunciado acotado del alcance del sistema o producto. ✓ Una lista de clientes, usuarios y otros participantes que intervienen en la indagación de los requerimientos. ✓ Una lista de requerimientos (de preferencia organizados por función) y las restricciones del dominio que se aplican a cada uno.

3.4. Requerimientos de las negociaciones Es una actividad que sirve a través de la vida técnica y personal .

Objetivo: Desarrollar un plan de proyecto que satisfaga las necesidades del cliente al mismo tiempo que refleja las restricciones del mundo real (por ejemplo: tiempo, gente, presupuesto) a las que está sometido el equipo de software.

3.5 Validación de los requerimientos. “Es la revisión del Documento de Especificación de Requerimientos (ESRE) en lo que respecta a consistencia, completitud y precisión; para certificar que representan una descripción aceptable del sistema a construir.” Checklist para Validación ✓¿QUE? ✓ ¿QUIENES? ✓¿COMO? ✓¿CUANDO? ✓¿DONDE? ✓¿POR QUE? ✓¿PARA QUE?

Unidad 4

DiseĂąo

4.1 Diseño en el contexto de la ingeniería de software El software no es el único campo donde el diseño se encuentra inmiscuido. En general podemos ver el diseño como una forma para resolución de problemas. El problema sin solución definitiva es interesante en términos de comprensión del diseño. Un número de otras nociones y conceptos son también de interés en la comprensión del diseño en su sentido general, objetivos, limitaciones, alternativas, representaciones y soluciones. El diseño del software se encuentra en el núcleo técnico de la respectiva ingeniería y se aplica de manera independiente al modelo de software que se utilice. Una vez que se analizan y especifican los requisitos, el diseño del software es la última acción de la ingeniería correspondiente dentro de la actividad del modelado, la cual establece una plataforma para la construcción (generación de código y prueba).

4.2 Lineamientos y atributos de la calidad de software

Lineamientos -Este compuesta de componentes con buenas características de diseño. -Se implementen en forma evolutiva. -Debe ser modular: dividido lógicamente en elementos y subsistemas. -Debe contener distintas representaciones arquitectura, interfaces y componentes. -Debe llevar componentes funcionales independientes.

que

tengan

datos

características

4.3 Conceptos de diseño El diseño de software agrupa el conjunto de principios conceptos y prácticas que llevan al desarrollo de un sistema o producto de alta calidad, el objeto del diseño es producir un modelo o representación que tenga resistencia funcionalidad y belleza el modelo del diseño proporciona detalles sobre la arquitectura del software, estructuras de datos ,interfaces y componentes que se necesitan para implementar el sistema también el diseño permite modelar el sistema o producto que se va a construir por último el diseño es el lugar en el que se establece la calidad del software.

4.3.1 Abstracción

4.3.2 Arquitectura El concepto de arquitectura de software se refiere a la estructuración del sistema que, idealmente, se crea en etapas tempranas del desarrollo. Esta estructuración representa un diseño de alto nivel del sistema que tiene dos propósitos primarios: satisfacer los atributos de calidad (desempeño, seguridad, modificabilidad), y servir como guía en el desarrollo.

Cuando se tiene en consideración una solución modular a cualquier problema, se pueden exponer muchos niveles de abstracción. En el nivel más alto de abstracción, la solución se pone como una medida extensa empleando el lenguaje del entorno del problema. En niveles inferiores de abstracción, se toma una orientación más procedimental.

4.3.3 Patrones

4.3.4 División de problemas El argumento para separar los problemas puede llevarse demasiado lejos. Si se divide un problema en un número muy grande de problemas pequeños, será fácil resolver cada uno de éstos, pero unificarlos será muy difícil.

Un patrón de software es una técnica de diseño de software que soluciona una clase de problemas concretos. Los patrones son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan.

Si para dos problemas, p1 y p2, la complejidad que se percibe para p1 es mayor que la percibida para p2. Entonces se concluye que el esfuerzo requerido para resolver p1 es mayor que el necesario para resolver p2.

4.3.5 Modularidad Es la capacidad que tiene un sistema de ser estudiado, visto o entendido como la unión de varias partes que interactúan entre sí y que trabajan para alcanzar un objetivo común, realizando cada una de ellas una tarea necesaria para la consecución de dicho objetivo. Cada una de esas partes en que se encuentre dividido el sistema recibe el nombre de módulo. Idealmente un módulo debe poder cumplir las condiciones de caja negra, es decir, ser independiente del resto de los módulos y comunicarse con ellos (con todos o sólo con una parte) a través de unas entradas y salidas bien definidas.

4.3.6 Ocultamiento de la información La información que esta dentro de un módulo no es accesible a otros que no la necesiten. Con esto se mantiene la independencia de los mismos. El objetivo de ocultar información es esconder los detalles de las estructuras de datos y el procesamiento tras una interfaz de modulo.

4.3.8 Refinamiento

4.3.7 Independencia funcional La independencia funcional se logra desarrollando módulos con funciones “miopes” que tengan “aversión” a la interacción excesiva con otros módulos. Dicho de otro modo, debe diseñarse software de manera que cada módulo resuelva un subconjunto específico de requerimientos y tenga una interfaz sencilla cuando se vea desde otras partes de la estructura del programa.

4.3.9 Aspectos Supongamos que su organización ha optado por desarrollar su propio software y contratar a un profesional informático para ello. Si éste es el caso, hay ciertos aspectos que debe tener en cuenta para proteger sus intereses y facilitar la evolución futura del sistema. Documentación: la mayoría de los programadores e ingenieros de sistemas son reacios a plasmar su trabajo en papel, no sólo porque resulta una tarea ardua y poco creativa, sino porque, al no hacerlo, aumentan la dependencia de las empresas de sus servicios, lo que supone un modo de asegurar sus empleos.

El refinamiento sucesivo es una primera estrategia de diseño descendente. En cada paso de refinamiento una o varias instrucciones del programa dado, se descomponen en instrucciones mas diseñadas.

4.3.10 Conceptos de diseños orientados a objetos El diseño Orientado a Objetos (DOO) difiere considerablemente del diseño estructurado ya que en DOO no se realiza un problema en términos de tareas (subrutinas) ni en términos de datos, sino que se analiza el problema como un sistema de objetos que interactúan entre sí. En el diseño orientado a objetos, los objetos necesitan interactuar y comunicarse, para realizar dicha comunicación, los objetos utilizan su propia interfaz pública, dicha interfaz se compone principalmente de métodos y propiedades.

4.3.11 Clases de diseño •Diseño de datos: Transforma el model del dominio obtenido del análisis,

en estructuras de datos, objetos, relaciones, etc. Por ejemplo un diagrama de entidad relación. •Diseño arquitectónico: Define la relación entre los componentes más

importantes del software para lograr los requisitos del sistema. La información puede derivarse de la especificación, del modelo de análisis y de la interacción de los subsistemas definidos. •Diseño de interface: Describe la forma de comunicación dentro del

mismo sistema, con otros sistemas y con las personas. Una interface implica flujo de información (datos o control) y comportamiento. •Diseño

a nivel de componentes: Transforma los elementos estructurales de la arquitectura en una descripción procedimental de los componentes del software. La información obtenida del diseño de datos, sirven como base.

TERCER PARCIAL

AVISOS UJAT

La creación de este software ayudara a varios estudiantes de la ujat de la División Académica de Ciencias y Tecnologías de la Información, este software se trata de ayudar a enterarse de los avisos mas recientes de la división, los usuarios podrán interactuar con todas las novedades de la división y al entrar tendrán que iniciar sesión con matriculas.

El siguiente link es para descargar la metodología y otros detalles del software. https://drive.google.com/file/d/1xrEC1isqwsfNC3SDx5lS W0dNC7tRc8YW/view?usp=sharing https://mega.nz/file/o5Qx2SDB#hnar1o9_duSsGLUhZf9XLYQ CNVgTGIwBwZWqyUXwzZc

VIDEO: CLASES EN LINEA CON MICROSOFT TEAMS

El siguiente link que hay, es un video que trata sobre la experiencia en clases online con la plataforma de Teams en la materia de ingenierÃa de software.

https://youtu.be/Q7wY0e00c98

Archivos Complementarios Los archivos complementarios son para que ayude o busques mas información sobre este tema y que te resuelvan algunas dudas. A continuación diapositivas de otros equipos sobre los mismos 4 temas.

MODELOS DEL PROCESO DE LA INGENIERÍA DE SOFTWARE

Unidad 1: Introducción alaIngenieríadeSoftware

ELABORADO POR:

Asesora: Dra. LauraBeatriz Vidal Turrubiates Equipo1:

Gisela Hernández Santiago Miguel Ángel Gómez Aldape Cynthia Estefanía García Gomez Marleth Cristal Gomes Flores

LuisGustavoHernández delao EdwinOsorioFranciscoMayo BrayanGabriel ZúñigaPérez

ASESORA: DRA. Laura Beatriz Vidal Turrubiates

División Académica de Ciencias y Tecnologías de la Información

UNIDAD 4: DISEÑO Equipo 4: Jesús Remedios de la Rosa Arias Adrián Silva Oliva Nicolás López Gutiérrez

Dra. Laura Beatriz Vidal Turrubiates Ingeniería de Software

Profesora: Dra. Laura Beatriz Vidal Turrubiates

Wilian Estrada Hernández Isela del Carmen Pérez Pérez Antonio Fuentes Hernández

CONCLUSIÓN

Este portafolio se hiso con el fin de hacer un registro de todas las tareas y actividades que hicimos en el salón de clases y poder recapitular de nuevo ordenándolas para este portafolio. También el portafolio contiene temas que me ayudaran en mi carrera profesional, hacer una aplicación es difícil pero vale la pena hacerla, en conclusión este portafolio es una evidencia de nuestro aprendizaje en el salón de clases.

Referencia

Gil, R. A. C. (2004). Estructura básica del proceso unificado de desarrollo de software. Tabares, M. S., Barrera, A. F., Arroyave, J. D., & Pineda, J. D. (2007). Un método para la trazabilidad de requisitos en el proceso unificado de desarrollo. Revista EIA, (8), 69-82. Tabares, M. S., Salinas, G. H. A., & Salinas, E. M. A. (2008). El desarrollo de software orientado a aspectos: un caso práctico para un sistema de ayuda en línea. Avances en Sistemas e Informatica. Gustavo Zimbrón, G. Z. (2018, 20 octubre). Importancia e Historia de las herramientas CASE ZimbronApps.com. Recuperado 20 febrero, 2020, de https://zimbronapps.com/sistemascomputacionales/ingenieria-desoftware/importancia-e-historia-las-herramientas-case Paradigma de la ingeniería de software. (2016, 25 abril). Recuperado 20 febrero, 2020, de https://ingenieriasofwarehugovenegas.wordpress.com/2016/04/25/paradigmade-la-ingenieria-desoftware/ Uriate, J. U. L. I. A. N. A Maxima (2019,14 octubre). 10 características de Software. Recuperado 24 Febrero, 2020, de https://www.caracteristicas. Co/software/ ChrisLag02 (2020). Estructura software & hardware. [online] Es.slideshare.net. Available at: https://es.slideshare.net/mobile/ChrisLag02/estructura-software-hardware [Accessed 25 Feb. 2020]. ESTRUCTURA DEL SOFTWARE. (2020). Retrieved 25 February 2020, from https://es.calameo.com/read/001696399ba6f4f24dbac

Cervantes, H. (09 de Febrero de 2016). SG. Recuperado el 14 de Febrero de 2020, de https://sg.com.mx/revista/27/arquitectura-software Curame, J. (16 de Agosto de 2014). Recuperado el 14 de Febrero de 2020, de Tópicos Generales de Ingeniería de Software: https://ingsoftwarei2014.wordpress.com/category/patrones-en-laingenieria-de-software/ Info, S. (13 de Noviembre de 2014). Recuperado el 14 de Febrero de 2020, de Super Información Web: http://superinformacionweb.blogspot.com/2014/11/conceptos-de-diseno.html Patricio B., J. (20 de Mayo de 2015). Slideshare. Recuperado el 14 de Febrero de 2020, de Principios diseño del software: https://es.slideshare.net/josebovet/idss5501-principios-diseno-del-software

INGENIERÍA DE SOFTWARE II. (2019, 5 noviembre). Recuperado de: https://instbolivarmadero.org/onewebmedia/INGENIERIA%20DE%20SOFTWARE%20II% 20RESUMEN.pdf

Jimeno Bernal, J. (2012). Despliegue de la función calidad (QFD): Guía de uso. Para qué sirve el QFD y cómo realizarlo : PDCA Home. [online Pdcahome.com.Recuperado de: https://www.pdcahome.com/1932/qfd-despliegue-calidad/ [Consultado: 17 Feb. 2020].

Gutiérrez, D. (2011). Diagramas de Casos de Uso (1st ed., pp. 1-6). Venezuela: Universidad de los Andes. 2020, de:

UCATEBA. (2014). Indagación de los requerimientos. Recuperado 24 Febrero https://es.slideshare.net/LouisOvalles/indagacin-de-los-requerimientos

Requerimientos de Las Negociaciones | Ingeniería de software | Software. Recuperado 24 Febrero 2020, de: https://es.scribd.com/document/410614749/Requerimientos-de-LasNegociaciones

Software and Learning