PROCESO UNIFICADO

Es un intento por obtener los mejores rasgos y características de los modelos tradicionales del proceso del software, pero en forma que implemente muchos de los mejores principios del desarrollo ágil de software. Reconoce la importancia de la comunicación con el cliente y los métodos directos para describir su punto de vista respecto de un sistema.

La arquitectura del software “ayuda a que el arquitecto se centre en las metas correctas, tales como que sea comprensible, permita cambios futuros y la reutilización” se sugiere un flujo del proceso iterativo e incremental, lo que da la sensación evolutiva que resulta esencial en el desarrollo moderno del software.

- La fase de concepción del PU agrupa actividades tanto de comunicación con el cliente como de planeación.

• Se desarrolla un plan para la naturaleza iterativa e incremental del proyecto en cuestión.
• La arquitectura se mejorará después y se expandirá en un conjunto de modelos que representarán distintos puntos de vista del sistema.

- La fase de elaboración incluye las actividades de planeación y modelado del modelo general del proceso

• La elaboración mejora y amplía los casos de uso preliminares desarrollados como parte de la fase de concepción y aumenta la representación de la arquitectura para incluir puntos de vista distintos del software.
• En ciertos casos, crea una “línea de base de la arquitectura ejecutable” que representa un sistema ejecutable de “primer corte”. La línea de base de la arquitectura demuestra la viabilidad de ésta, pero no proporciona todas las características y funciones que se requieren para usar el sistema.
• Al terminar la fase de elaboración se revisa con cuidado el plan a fin de asegurar que el alcance, riesgos y fechas de entrega siguen siendo razonables. Es frecuente que en este momento se hagan modificaciones al plan.

- La fase de construcción es idéntica a la actividad de construcción definida para el proceso general del software.

- La fase de transición del PU incluye las últimas etapas de la actividad general de construcción y la primera parte de la actividad de despliegue general (entrega y retroalimentación).

• Se da el software a los usuarios finales para las pruebas beta, quienes reportan tanto los defectos como los cambios necesarios.
• El equipo de software genera la información de apoyo necesaria (manuales de usuario, guías de solución de problemas, procedimientos de instalación, etc.) que se requiere para el lanzamiento.
• Al finalizar la fase de transición, el software incrementado se convierte en un producto utilizable que se lanza.

 - La fase de producción coincide con la actividad de despliegue del proceso general.

• Se vigila el uso que se da al software
• Se brinda apoyo para el ambiente de operación
• Se reportan defectos y solicitudes de cambio para su evaluación

Es probable que al mismo tiempo que se llevan a cabo las fases de construcción, transición y producción, comience el trabajo sobre el siguiente incremento del software. Esto significa que las cinco fases del PU no ocurren en secuencia sino que concurren en forma escalonada.

CONCLUSIÓN 

Un proceso es un conjunto de pasos ordenados para alcanzar un objetivo. En ingeniería de software, el objetivo es construir un producto de software nuevo o extender uno existente. Esto permite enfocar esfuerzo de los recursos humanos en términos de habilidades, competencias y capacidades a asumir roles específicos con responsabilidades bien definidas.

BIBLIOGRAFÍA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición

METODOLOGÍAS ÁGILES

INTRODUCCIÓN.

Las metodología ágil es la forma más óptima de acoplarse a nuevos requerimientos en la creación de proyecto lo principal de esta clase es dar a conocer los principales sistemas agiles en la construcción de software.

MARCO TEÓRICO

METODOLOGÍAS ÁGILES

La historia de la ingeniería de software está salpicada de decenas de descripciones y metodologías de proceso, métodos de modelado y notaciones, herramientas y tecnología, todos ellos obsoletos. Cada uno tuvo notoriedad y luego fue eclipsado por algo nuevo y (supuestamente) mejor. Con la introducción de una amplia variedad de modelos ágiles del proceso —cada uno en lucha por la aceptación de la comunidad de desarrollo de software— el movimiento ágil está siguiendo la misma ruta histórica.

Principios de agilidad.

doce principios de agilidad para aquellos que la quieran alcanzar:

1. La prioridad más alta es satisfacer al cliente a través de la entrega pronta y continua de software valioso.

2. Son bienvenidos los requerimientos cambiantes, aun en una etapa avanzada del desarrollo. Los procesos ágiles dominan el cambio para provecho de la ventaja competitiva del cliente.

3. Entregar con frecuencia software que funcione, de dos semanas a un par de meses, de preferencia lo más pronto que se pueda.

4. Las personas de negocios y los desarrolladores deben trabajar juntos, a diario y durante todo el proyecto.

5. Hay que desarrollar los proyectos con individuos motivados. Debe darse a éstos el ambiente y el apoyo que necesiten, y confiar en que harán el trabajo.

6. El método más eficiente y eficaz para transmitir información a los integrantes de un equipo de desarrollo, y entre éstos, es la conversación cara a cara.

7. La medida principal de avance es el software que funciona.

8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deben poder mantener un ritmo constante en forma indefinida.

9. La atención continua a la excelencia técnica y el buen diseño mejora la agilidad.

10. Es esencial la simplicidad: el arte de maximizar la cantidad de trabajo no realizado.

11. Las mejores arquitecturas, requerimientos y diseños surgen de los equipos con organización propia.

12. El equipo reflexiona a intervalos regulares sobre cómo ser más eficaz, para después afinar y ajustar su comportamiento en consecuencia.

Un modelo de desarrollo ágil es un proceso incremental con pequeñas entregas de software ya que el software va evolucionando y necesita de nuevas características o nuevos requerimientos.

El más usado de todos los modelos ágiles de proceso es la programación extrema (XP). Pero se han propuesto muchos otros y están en uso en toda la industria. Entre ellos se encuentran los siguientes:

• Desarrollo adaptativo de software (DAS)

• Scrum

• Método de desarrollo de sistemas dinámicos (MDSD)

• Cristal

• Desarrollo impulsado por las características (DIC)

• Desarrollo esbelto de software (DES)

• Modelado ágil (MA)

• Proceso unificado ágil (PUA)

CONCLUSIÓN.

Las metodologías agiles son requeridas mucho en el desarrollo del proceso de software ya q estas metodologías permiten realizar pequeños incremento al equipo de desarrollo sin generar problemas ya que pasaría por lo mismo que todo el proceso de desarrollo es decir todas las actividades de desarrollo de software.

BIBLIOGRAFÍA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición

MODELOS DE PROCESOS ESPECIALIZADOS

Los modelos de proceso especializado tienen muchas de las características de uno o más de los modelos tradicionales, sin embargo, dichos modelos tienden a aplicarse cuando se elige un enfoque de ingeniería de software especializado o definido muy específicamente.

DESARROLLO BASADO EN COMPONENTES.

el modelo de desarollo basado en componentes incorpora muchas de las características del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creación del software. El modelo basado en componente configura aplicaciones desde componentes preparados software.El modelo de desarrollo basado en componentes conduce a la reutilización del software, y la reutilización proporciona beneficios a los ingenieros de software.Sin importar la tecnología usada para crear los componentes, el modelo de desarrollo basado en componentes incorpora las etapas siguientes.

1. Se investigan y evalúan, para el tipo de aplicación de que se trate, productos disponibles basados en componentes.
2. Se consideran los aspectos de integración de los componentes.
3. Se diseña una arquitectura del software para que reciba los componentes.
4. Se integran los componentes en la arquitectura.
5. Se efectúan pruebas exhaustivas para asegurar la funcionalidad apropiada.

El modelo del desarrollo basado en componentes lleva a la reutilización del software, y eso da a los ingenieros de software varios beneficios en cuanto a la mensurabilidad. Si la reutilización de componentes se vuelve parte de la cultura, el equipo de ingeniería de software tiene la posibilidad tanto de reducir el ciclo de tiempo del desarrollo como el costo del proyecto. 

MODELOS DE MÉTODOS FORMALES.

El modelo de métodos formales acompaña a un conjunto de actividades que conducen a la especificación matemática del software de computadora. Los métodos formales permiten que un ingeniero del software especifique, desarrolle y verifique un sistema basado en computadora aplicando una notación rigurosa y matemática.

La ambigüedad, lo incompleto y la inconsistencia se descubren y se corrigen más fácilmente, no mediante una revisión a propósito para el caso, sino mediante la aplicación del análisis matemático. Cuando se utilizan métodos formales durante el diseño, sirven como base para la verificación de programas y por consiguiente permiten que el ingeniero del software descubra y corrija errores que no se pudieron detectar de otra manera.

Aunque el modelo de los métodos formales no es el más seguido, promete un software libre de defectos. Sin embargo, se han expresado preocupaciones acerca de su aplicabilidad en un ambiente de negocios:

• El desarrollo de modelos formales consume mucho tiempo y es caro.
• Debido a que pocos desarrolladores de software tienen la formación necesaria para aplicar métodos formales, se requiere mucha capacitación.
• Es difícil utilizar los modelos como mecanismo de comunicación para clientes sin complejidad técnica.

A pesar de estas preocupaciones, el enfoque de los métodos formales ha ganado partidarios entre los desarrolladores que deben construir software de primera calidad en seguridad.

DESARROLLO DE SOFTWARE ORIENTADO A ASPECTO 

Sin importar el proceso del software que se elija, los constructores de software complejo implementan de manera invariable un conjunto de características, funciones y contenido de información localizados. Estas características localizadas del software se modelan como componentes (clases orientadas a objetos) y luego se construyen dentro del contexto de una arquitectura de sistemas. A medida que los sistemas modernos basados en computadora se hacen más sofisticados (y complejos), ciertas preocupaciones —propiedades que requiere el cliente o áreas de interés técnico— se extienden a toda la arquitectura. Algunas de ellas son las propiedades de alto nivel de un sistema (por ejemplo, seguridad y tolerancia a fallas). Otras afectan a funciones (aplicación de las reglas de negocios), mientras que otras más son sistémicas (sincronización de la tarea o administración de la memoria).

Cuando las preocupaciones afectan múltiples funciones, características e información del sistema, es frecuente que se les llame preocupaciones globales. Los requerimientos del aspecto definen aquellas preocupaciones globales que tienen algún efecto a través de la arquitectura del software. El desarrollo de software orientado a aspectos (DSOA), conocido también como programaciónorientada a aspectos (POA), es un paradigma de ingeniería de software relativamente nuevo que proporciona un proceso y enfoque metodológico para definir, especificar, diseñar y construir aspectos: “mecanismos más allá de subrutinas y herencia para localizar la expresión de una preocupación global”.

CONCLUSIÓN

Los métodos formales se centra fundamentalmente en las funciones y los datos. La especificación mediante métodos formales es más difícil de aprender que otros métodos de análisis. Las especificaciones formales se pueden estudiar matemáticamente, mientras que las informales no pueden estudiarse de esta manera.

BIBLIOGRAFÍA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición

MODELO DE PROCESO PRESCRIPTIVO

Los modelos son llamados prescriptivos ya que prescriven una serie de elementos de proceso así como su flujo de trabajo, cada uno de modelos se ajustan al marco de trabajo estándar pero cada uno aplica diferencias a cada una de las actividades y a su flujo de trabajo.

Los modelos prescriptivos de software nos definen un conjunto de tareas actividades, productos de trabajo que se requieren para desarrollar productos de calidad que son importantes para llevar control, estabilidad y organización a una actividad que tiende a ser caótica, el modelo prescriptivo llena el marco de trabajo con conjuntos de tareas explicitas para las acciones de la ingenieria de software. Se debe considerar que aun que un proceso sea prescriptivo esto no se debe asumir como estático, estos se deben adaptar al personal, al proyecto y al problema.

CUERPO. 

Modelo de Proceso Prescriptivo 

Modelo de Cascada.
El modelo de la cascada, a veces llamado ciclo de vida clásico, sugiere un enfoque sistemático y secuencial para el desarrollo del software, que comienza con la especificación de los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado.

Una variante de la representación del modelo de la cascada se denomina modelo en V, se ilustra el modelo en V, donde se aprecia la relación entre las acciones para el aseguramiento de la calidad y aquellas asociadas con la comunicación, modelado y construcción temprana. A medida que el equipo de software avanza hacia abajo desde el lado izquierdo de la V, los requerimientos básicos del problema mejoran hacia representaciones técnicas cada vez más detalladas del problema y de su solución.

1. Es raro que los proyectos reales sigan el flujo secuencial propuesto por el modelo. Aunque el modelo lineal acepta repeticiones, lo hace en forma indirecta. Como resultado, los cambios generan confusión conforme el equipo del proyecto avanza. 
2. A menudo, es difícil para el cliente enunciar en forma explícita todos los requerimientos. El modelo de la cascada necesita que se haga y tiene dificultades para aceptar la incertidumbre natural que existe al principio de muchos proyectos 
3. El cliente debe tener paciencia. No se dispondrá de una versión funcional del(de los)programa(s) hasta que el proyecto esté muy avanzado. Un error grande sería desastroso si se detectara hasta revisar el programa en funcionamiento.

Hoy en día, el trabajo de software es acelerado y está sujeto a una corriente sin fin de cambios (en las características, funciones y contenido de información). El modelo de la cascada suele ser inapropiado para ese tipo de labor. No obstante, sirve como un modelo de proceso útil en situaciones en las que los requerimientos son fijos y el trabajo avanza en forma lineal hacia el final.

Modelos de Proceso Incremental

El modelo incremental combina elementos de los flujos de proceso lineal y paralelo, en tales casos, se elige un modelo de proceso diseñado para producir el software en incrementos. El modelo incremental aplica secuencias lineales en forma escalonada a medida que avanza el calendario de actividades. Cada secuencia lineal produce “incrementos” de software susceptibles de entregarse de manera parecida a los incrementos producidos en un flujo de proceso evolutivo.

Cuando se utiliza un modelo incremental, es frecuente que el primer incremento sea el producto fundamental. Es decir, se abordan los requerimientos básicos, pero no se proporcionan muchas características suplementarias (algunas conocidas y otras no). El cliente usa el producto fundamental (o lo somete a una evaluación detallada). Como resultado del uso y/o evaluación, se desarrolla un plan para el incremento que sigue. El plan incluye la modificación del producto fundamental para cumplir mejor las necesidades del cliente, así como la entrega de características adicionales y más funcionalidad. Este proceso se repite después de entregar cada incremento, hasta terminar el producto final. 

Modelos de Proceso Evolutivo

Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que permiten desarrollar versiones cada vez más completas del software.

Hacer Prototipos. El cliente describe un conjunto de de objetivos generales del software pero no identifica los requisitos detallados de entrada, salida o procesamiento y el desarrollador esta inseguro de la efectividad del software, si el cliente tiene un necesidad real del software pero no sepa definir los detalles o el mismo no sepa bien que es lo que quiere es importante como primer paso desarrollar un prototipo. y puede mezclarse con cualquier otro método.

El paradigma de construcción de prototipos se inicia con la comunicación el ingeniero de software y el cliente encuentran y definen los requisitos básicos y conocidos, entonces se plantea con rapidez una iteracion de construcción de prototipos y se presenta un diseño rápido y este se centra en aspectos visibles al cliente y al usuario final, se construye el prototipo y este se somete a una evaluación por parte del cliente/usuario para y con la retroalimentacion producida se reajustan los requisitos del software que se desarrollara. De tal forma que el prototipo sirve como un mecanismo para identificar los requisitos del software.

El Modelo Espiral. El modelo espiral es un proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos del modelo cascada, el modelo cascada se puede adaptar y aplicar a través del ciclo de vida completo de una aplicación desde el desarrollo del concepto hasta el mantenimiento. 

Cuando se aplica el modelo espiral se desarrolla una serie de entregas evolutivas iniciando desde posiblemente documentación y prototipos, hasta llegar versiones cada ves mejores del sistema.

Durante las primeras iteraciones, lo que se entrega puede ser un modelo o prototipo. En las iteraciones posteriores se producen versiones cada vez más completas del sistema cuya ingeniería se está haciendo. Un modelo en espiral es dividido por el equipo de software en un conjunto de actividades estructurales. Para fines ilustrativos, se utilizan las actividades estructurales generales ya analizadas.

Proceso Modelo Concurrente.

El modelo de desarrollo concurrente, en ocasiones llamado ingeniería concurrente, permite que un equipo de software represente elementos iterativos y concurrentes de cualquiera de los modelos de proceso. Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo Por ejemplo, la actividad de modelado definida para el modelo espiral se logra por medio de invocar una o más de las siguientes acciones de software: Hacer prototipos, análisis y diseño.

El modelo de desarrollo concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componente funcional.

CONCLUSIONES

Todos los modelos del proceso del software ayudan al desarrolador seguir una secuencia gracias a estos modelos al desarrollar el software la calidad de este es que cumplen las especificaciones que desea el cliente con las diferentes tareas en un orden.

• El modelo de cascada es uno de los modelos más utilizado en proyectos pequeños ya que tiene q tener bien en claro los requerimiento del software, si no se tienen en claro estos requerimientos generar problemas al desarrollarlo.

• El modelos incremental aplica una secuencia lineal que produce incrementos lo cual modifica el software para cumplir las necesidades del cliente, este incremento se lo realiza hasta cumplir las especificaciones del cliente.

• El modelo evolutivo es el que se caracteriza por  desarrollar versiones cada vez más completas del software, en este se encuentra el modelo prototipo el cual se hace ciertas especificaciones del software pero no se tiene en claro lo que se requiere por lo que se hace un diseño según  las especificaciones, de tal forma que sirva para identificar los requerimientos del software. EL modelo espiral el cual se entregan las primeras iteraciones de forma de prototipo lo cual se lleva documentación hasta llegar a versiones mas complejas.

• Modelo concurrente este modelo es de tipo de red donde todas las personas actúan al mismo tiempo en el proceso del software, se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor

BIBLIOGRAFÍA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición

BIOGRAFÍA DEL AUTOR

BIOGRAFÍA:

Marcillo Cedeño Adolfo Antonio

Nació en Chone – Manabí, el 11 de Octubre de 1992, realizo sus estudios primarios en la Escuela Fiscal Mixta Abdón Calderón Garaicoa, sus estudio secundario los realizo en el Colegio Nacional Augusto Solórzano Hoyos, Obtuvo el Título de Técnico Polivalente Especialidad Informática, actualmente cursas sus Estudios Superiores en la Escuela Superior Politécnica Agropecuarias de Manabí Manuel Félix López, Carrera Ingeniaría en Informática.

SÍLABO DE INGENIERÍA DE SOFTWARE

ESCUELA SUPERIOR POLITÉCNICA AGROPECUARIA DE MANABÍ 

MANUEL FÉLIX LÓPEZ

CARRERA DE INFORMÁTICA

SÍLABO DEL CURSO

INGENIERIA DE SOFTWARE

PERIÓDO SEMESTRAL: Abril 2014 / Agosto 2014

1. CÓDIGO Y NÚMERO DE CRÉDITOS:

CÓDIGO: 0704

CRÉDITOS: 3 (2 TEÓRICOS, 1 PRÁCTICO)

SEMESTRE: SÉPTIMO                          PARALELO: A

2. DESCRIPCIÓN DEL CURSO:

Este curso permite al estudiante desarrollar los conocimientos necesarios para gestionar proyectos de software, se exponen conceptos de análisis y diseño estructurado y la gestión de aspectos relativos a calidad y riesgos aplicables a un producto de software,

3. PRE-REQUISITOS Y CO-REQUISITOS:

Pre-requisitos: 0604 Gestión Informática

Co-requisitos:

4. TEXTO Y REFERENCIAS REQUERIDAS PARA EL DICTADO DEL CURSO:

TEXTO GUÍA:

Roger S. Pressman (2010), Ingeniería del Software un enfoque Práctico, 7ma. ed. México: Mc Graw Hill.

BIBLIOGRAFIA COMPLEMENTARIA

Pavón, Juan. Gestión de Software. 3era. Edición. Editorial Complutense, 2008, Madrid.

5. OBJETIVOS GENERALES DEL CURSO (RESULTADOS O LOGROS DE APRENDIZAJE DEL CURSO):

a) (C1) Conocer el ciclo de vida del software, así como metodologías, modelos y patrones de diseño.

b) (C4)  Organizar un equipo de trabajo de desarrollo de software, en base a un concepto metodológico.

c) (C5 ) Desarrollar un producto software empleando una metodología de desarrollo de software.

d) (A4) Integrar equipos de desarrollo de software.

e) (P4) Administrar equipos de desarrollo de software.

6. TOPICOS O TEMAS CUBIERTOS:

7. HORARIO DE CLASE:

          16 Semanas por el semestre, más una semana cultural, 3 horas de clases por semana de 60 minutos cada una.

      Miércoles: Dos horas en el aula de clases 202. (20h15 a 22h15)

      Viernes: Una hora en el aula de clases 305. (18h00 a 19h00)

8. CONTRIBUCIÓN DEL CURSO EN LA FORMACIÓN DEL INGENIERO EN INFORMÁTICA:

9. RELCIÓN DEL CURSO CON EL CRITERIO RESULTADOS DE APRENDIZAJE:

10. FORMA DE EVALUACIÓN DEL CURSO:

11. RESPONSABLE DE LA ELABORACIÓN DEL SÍLABO Y FECHA DE PRESENTACCCCION Y REVISION:

MISIÓN Y VISIÓN

MISIÓN Y VISIÓN DE LA ESPAM MFL

Misión

Formación integral y continua de profesionales que contribuyan de forma proactiva y creativa al desarrollo cultural, económico, político y social sostenible de su entorno y nación, para lo cual hace suya las aspiraciones más legitimas de sus profesionales, trabajadores y estudiantes en un clima de participación y compromiso social.

Visión:

Coadyuvar al desarrollo de la región y el país como un centro referencial de la calidad en la formación de profesionales en las carreras existentes y en las que para el efecto se crearen.

MISIÓN Y VISIÓN DE LA CARRERA INFORMÁTICA

Misión

Formación de Profesionales íntegros que conjuguen ciencia, tecnología y valores en su accionar, comprometidos con la comunidad en el manejo adecuado de programas y herramientas computacionales de última generación.

Visión:

Ser referentes en la formación de profesionales de prestigio en el desarrollo de aplicaciones informática y soluciones de hardware.