INTRODUCCION A LA
INGENIERIA EN SOFTWARE

2. Proceso
de Sotfware

Un proceso de software es una serie de actividades relacionadas que conduce a la elaboración de un producto de software, estas actividades pueden incluir el desarrollo de software desde cero en un lenguaje de programación estándar como Java o C.

2.1. Modelos del proceso del software: Los modelos son una representación simplificada de un
proceso, cada modelo representa al otro desde una particular perspectiva y, por lo tanto, ofrece solo información parcial acerca de dicho proceso.

2.2. Actividades del proceso: los procesos de software real son secuencias entrelazadas de
actividades técnicas, colaborativa y administrativas con la meta general de especificar, diseñar, implementar y probar un sistema de software.

2.3. Cómo enfrentar el Cambio: El cambio es inevitable en todos los grandes de software. Los
requerimientos de sistema varían conforme la empresa procura que el sistema responda a presiones externas y se modifican las prioridades administrativas.

2.4. El proceso unificado Racional: Este proceso es un modelo de proceso moderno que se derivo
del trabajo sobre el UML y el proceso asociado de desarrollo de software unificado.

Fuentes:

1. Ingeniería
en Software?

Es una disciplina de la Informática - Es el desarrollo y mantenimiento del software - Realiza un enfoque disciplinado al desarrollo del software.

1.1. Desarrollo de software profesional: El sistema por o regular consta de un numero de programas separados y archivos de configuración que se usan para instalar dichos programas

Puede incluir documentación del sistema , que describe la estructura del sistema; documentación del usuario, que explica como usar el sistema, y los sitios web para que los usuarios descarguen información reciente del producto

1.2. Etica de la ingeniería en software: Se debe mantener estándares de honestidad e integridad. No debe usar sus habilidades y experiencia para comportarse de forma deshonesta o de un modo que desacredite la profesion de ingenieria en software.

Existen áreas donde el comportamiento esta acotado por la noción mas difusa de responsabilidad profesional: por ejemplo: Confidencialidad, competencia, derechos de propiedad intelectual y el mal uso de computadoras.

1.3. Estudio de caso: Se utilizan tres tipos diferentes de estudios de caso. La practica de la ingeniería de software depende del tipo de sistema a producir. Los tres tipos de sistemas usados como estudio de caso son:

1. Un sistema embebido: Es un sistema donde el software controla un dispositivo de hardware y esta embebido en dicho dispositivo, por ejemplo: Un sistema de software para controlar un dispositivo medico.

2. Un sistem de información: Tiene como propósito gestionar y dar acceso a una base de datos, por ejemplo: Un sistema de registros médicos.

3. Un sistema de adquisición de datos basado en sensores: Tiene como objetivo recolectar datos de un conjunto de sensores y procesar los datos, por ejemplo: Una estación meteorológica.

9. Evolucion del
Software

El desarrollo de software no se detiene cando un sistema se entrega, sino que continua
a lo largo de la vida de este. Un sistema inevitablemente debe modificarse, con la finalidad de mantenerse útil esto es importante porque las organizaciones invierten mucho dinero en el y en las actualizaciones para que su sistema siga en funcionamiento y no quedar obsoleto.

9.1. Procesos de evolución: Estos procesos varían dependiendo del tipo de software que
mantiene, de los procesos de desarrollo usados en la 0rganizacion y de las habilidades de las personas que intervienen.

9.2. Evolución dinámica del programa: La dinámica de evolución del programa es el
estudio del cambio de sistema.

9.3. Mantenimiento de software: Es el proceso general de cambiar un sistema después de
que este se entregó. Los cambios realizados al software van desde lo simples para corregir errores de codificación.

9.4. Administración de sistemas heredados: Para los sistemas de software nuevos
desarrollados con modernos proceso de ingeniería en software, como el desarrollo incremental y el CBSE, es posible plantear como integrar el desarrollo u la evolución del sistema.

Existen cuatro opciones estratégicas.
- Desechar completamente el sistema
- Dejar sin cambios el sistema y continuar el mantenimiento regular
- Someter el sistema a reingeniería para mejorar su mantenimiento
- Sustituir todo a parte del sistema con un nuevo sistema.

8. Pruebas de
Software

Las pruebas de software intentan demostrar que un programa hace lo que se intenta que haga, así como descubrir defectos en el programa antes de usarlo. El probar el software y ver sus resultados nos permite buscar errores, anomalías o información de atributos no funcionales del programa.

8.1. Pruebas de desarrollo: Es un proceso de prueba de defecto, en las cuales la meta
consiste en descubrir bug, problemas con el código y cambiar programa para
corregirlo.

8.2. Desarrollo dirigido por pruebas: Es un enfoque al diseño de programas donde se
entrelazan el desarrollo de pruebas y el desarrollo de código.

8.3. Pruebas de versión: Son el proceso de poner a prueba una versión particular de un
sistema que se pretende usar fuera del equipo de desarrollo. Por lo general la versión del sistema es para clientes y usuarios.

8.4. Pruebas de usuario: Es la etapa en el proceso de prueba donde los usuarios o clientes
proporcionan entrada y asesoría sobre las pruebas del sistema.

Topic principal

7. Diseño e
Implementación

Es la etapa del proceso de ingeniería de software en que se desarrolla un sistema de software
ejecutable.
• El diseño de software es una actividad creativa donde se identifican los componentes del software y sus relaciones, con base en los requerimientos de un cliente.
• La implementación es el proceso de realizar el diseño como un programa.

7.1.Diseño orientado a objetos con el uso de UML: Implican el diseño de clases de objetos y las relaciones entre dichas clases, en la que las clases definen
tanto los objetos en el sistema como sus interacciones. Cuando el diseño se realiza como un programa en ejecución, los objetos se crean dinámicamente a partir de estas definiciones de clase. Los sistemas orientados a objetos son más fáciles.

7.2. Patrones de diseño: El patrón es una descripción del problema y la esencia de su solución, de modo que la solución puede
reutilizarse en diferentes configuraciones. El patrón no es una especificación detallada. Más bien, puede considerarla como una descripción de sabiduría y experiencia acumuladas, una solución bien probada a un problema común. Además, los patrones son una forma de reutilizar el conocimiento y la experiencia de otros diseñadores.

7.3, Conflictos de implementación: Requiere el desarrollo de programas en lenguajes de programación de alto o bajo niveles, o bien, la
personalización y adaptación de sistemas comerciales genéricos para cubrir los requerimientos específicos de una organización.

7.4. Desarrollo de código abierto:Es un enfoque al desarrollo de software en que se publica el código de un sistema de software y se invita a voluntarios a participar en el proceso de desarrollo (Raymond, 2001). Extendió esta idea al usar Internet para reclutar a una población mucho mayor de desarrolladores voluntarios. El producto mejor conocido de código abierto es el sistema operativo Linux, como también Java, el servidor Web Apache y el sistema de gestión de base de datos MySQL.

3. Desarrollo agil
del software

El software es parte de casi todas las operaciones industriales, de modo que el nuevo software se desarrolla rápidamente para aprovechar las actuales
oportunidades con la finalidad de responder ante la amenaza competitiva.

3.1. Métodos ágiles: El método ágil mas conocido es la programación externa, otros enfoques
ágiles incluyen los de Scrum de Crystal, de desarrollo de software adaptativo y el desarrollo dirigido por características.

3.2. Desarrollo dirigido por un plan y desarrollo ágil: Los enfoques agiles en el desarrollo de
software consideran el diseño y la implementación como las actividades centrales en el proceso del software. Incorporan otras actividades en el diseño y la implementación, como la adquisición de requerimientos y pruebas.

3.4. Administración de un proyecto ágil: La responsabilidad principal de los administradores del
proyecto de software es dirigir el proyecto, de modo que el software se entregue a tiempo y
con el presupuesto planeado para ello.

3.3. Programación extrema: Es el método ágil mejor conocido y más ampliamente usado, en esta
programación los requerimientos expresan como escenarios, que se implementan directamente como una serie de tareas.

3.5. Escalamiento de métodos ágiles: Los métodos agiles se desarrollan para usarse en pequeños
equipos de programación, que podían trabajar juntos en la misma habitación y comunicarse de manera informal.

4. Ingenieria de
Requerimiento

Son descripciones de lo que el sistema debe hacer. El servicio que ofrece y las restricciones en su operación. Tales requerimientos se deben reflejar las necesidades del cliente por un sistema que atienda cierto propósito, como seria controlar un dispositivo ,colocar un pedido o buscar información. ingeniería de requerimiento es el proceso de descubrir, analizar , documentar y verificar las restricciones y servicios del sistema.

4.1. Requerimientos funcionales: son enunciados acercas de servicios que el sistema debe proveer de como debería reaccionar el sistema a entradas particulares y de como debería comportarse el sistema en situaciones especificas.

Requerimientos no funcionales: son limitaciones sobre servicios o funciones que ofrece el sistema .

4.2. Especificación de requerimientos: es el proceso de escribir en un documento los requerimientos del usuario y del sistema.

Los requerimientos del usuario para un sistema deben describir los requerimientos funcionales y no funcionales de forma que sean comprensibles para los usuarios que no cuentan con un conocimiento técnico detallado. Los requerimientos dl sistema deben describir de manera simple el comportamiento interno y externo y sus restricciones operacionales.

4.3. Validación de requerimientos: es el proceso de verificar que los requerimientos definan realmente el sistema que en verdad quiere el cliente.
Tipos de comprobación de requerimientos:

1. Comprobaciones de validez: un usuario quizás cree que necesita un sistema para realizar ciertas funciones
2. Comprobación de consistencia: los requerimientos en el documento no deben estar en conflicto.

3. Comprobación de totalidad: el documento de requerimiento debe incluir requerimientos que definan todas las funciones y restricciones pretendidas por el usuario del sistema.
4. Comprobación de realismo: al usar el conocimiento de la tecnología existente los requerimientos deben comprobarse para garantizar que en realidad pueden implementarse.

5. Verificabilidad: para reducir el potencial de disputas entre clientes y contratista los requerimientos del sistema deben escribirse de manera que sean verificables.

5.Modelo de sistemas

Es el proceso para desarrollar modelos abstractos de un sistema donde cada modelo presenta una visión o perspectiva diferente de dicho sistema.

5.1. Modelo de contexto: En una primera etapa en la especificación del sistema debe decidir sobre todas la fronteras del sistema. Esto implica trabajar con los participantes del sistema para determinar cual funcionalidad se incluirá en el sistema y cual la ofrece el entorno del sistema.

5.2. Modelo de Interacción: Incluyen interacciones del usuario que implican entradas y salidas del usuario interacciones entre el sistema a desarrollar y otros sistemas o interacciones entre los componentes del sistema.

5.3. Modelos estructurales: Muestran la organización de un sistema en términos de los componentes que constituyen dicho sistema y sus relaciones son modelos estáticos que muestran la estructura del diseño del sistema o modelos dinámicos que revelan la organización del sistema cuando se ejecuta.

5.4. Modelos de comportamiento: Son modelos dinámicos del sistema conforme se ejecutan en ellos se muestra lo que sucede o lo que se supone que pasa cuando un sistema responde ante un estimulo de su entorno.

6.Diseño
Arquitectónico

Es esencial entre el diseño y la ingeniería de requerimientos. Se interesa por entender cómo debe
organizarse un sistema y cómo tiene que diseñarse la estructura global de ese sistema

6.1. Decisiones en el diseño arquitectónico: Es un proceso creativo en el cual se diseña una organización del sistema que cubrirá los requerimientos
funcionales y no funcionales de éste. Las actividades dentro del proceso dependen del tipo de sistema que se va a desarrollar, los antecedentes y la experiencia del arquitecto del sistema, así como de los requerimientos específicos del sistema.

6.2. Vista arquitectonica:Puede mostrar cómo un sistema se descompone en módulos, interactúan los procesos de tiempo de
operación o las diferentes formas en que los componentes del sistema se distribuyen a través de una red.

6.3. Patrones arquitectónicos: Se puede considerar como una descripción abstracta estilizada de buena práctica, que se ensayó y puso a prueba en diferentes sistemas y entornos. De este modo, debe describir una organización de sistema que ha tenido éxito en sistemas previos.

6.4. Arquitecturas de aplicación: Encapsulan las principales características de una clase de sistemas. Se puede usar modelos de
arquitecturas de aplicación en varias formas:
1. Como punto de partida para el proceso de diseño arquitectónico
2. Como lista de verificación del diseño
3. Como una forma de organizar el trabajo del equipo de
4. Como un medio para valorar los componentes a reutilizar
5. Como un vocabulario para hablar acerca de los tipos de aplicaciones