REPÚBLICA BOLIVARIANA DE VENEZUELA

UNIVERSIDAD ALONSO DE OJEDA

VICERRECTORADO ACADÉMICO
FACULTAD DE INGENIERÍA
ESCUELA DE COMPUTACIÓN

INGENIERIA DE SOFTWARE
Prof. Nerio Garcia Gollarza
SECCIÓN: IC1031

INTEGRANTES

Michael Traviezo CI 27.139.093

Ciudad Ojeda, Agosto de 2020

INTRODUCCION
¿Cuáles son los usos de la ingeniería de software?
La ingeniería de software se basa en la aplicación de un enfoque sistemático, el cual se
disciplina en un medio cuantificable de desarrollo, mantenimiento y operación funcional de
un software. Para el desarrollo de los medios de programación se crean diagramas de
flujo y estructuras donde el funcionamiento de los mismos se explica para poder definir las
funciones en la aplicación. A pesar de que la principal función de la ingeniería de software
es crear soluciones con sistemas de cómputo, algunas veces la solución a un problema o
a las necesidades del usuario son más imples; un ejemplo puede ser, una base de datos
para negocio que cuenta sólo con un equipo de cómputo, el ingeniero en software puede
ayudar al cliente a encontrar la solución al registro de sus productos o a su contabilidad,
sin crear un gran sistema.

1.- INGENIERIA DE SOFTWARE

La ingeniería de software es una disciplina formada por un conjunto de métodos,
herramientas y técnicas que se utilizan en el desarrollo de los programas informáticos
(software), es la aplicación de un enfoque sistemático, disciplinado y cuantificable al
desarrollo, operación y mantenimiento de software,

La ingeniería de software, incluye el análisis previo de la situación, el diseño del proyecto,

el desarrollo del software, las pruebas necesarias para confirmar su correcto
funcionamiento y la implementación del sistema. Una vez que se completa el ciclo del
software, entra en juego el mantenimiento del software. Se trata de una fase de esta
ingeniería donde se solucionan los errores descubiertos (muchas veces advertidos por los
propios usuarios) y se incorporan actualizaciones para hacer frente a los nuevos
requisitos.

2.- MODELOS DE DESARROLLO DE SOFTWARE.

Para el desarrollo de cualquier producto de software se realizan una serie de tareas entre
la idea inicial y el producto final, un modelo de desarrollo establece el orden en el que se
harán las cosas en el proyecto, provee de requisitos de entrada y de salida para cada una
de las actividades, por ello es necesario el modelo de desarrollo.

 MODELO CASCADA

Llamado también Lineal secuencial. Proporciona una simple visión del desarrollo del
Software. A los procesos los representa como fases separadas y secuenciales en tiempo.

Cada etapa produce documentos que son la entrada a la siguiente, para desarrollar una
etapa debe concluirse la anterior.

Faces Del modelo cascada

 
 Ingeniería y Análisis del Sistema : Análisis y de diseño de todos los
componentes del sistema computacional
 Análisis de los Requisitos: Se debe conocer que necesita el usuario para saber
que necesidades debemos cubrir.
Diseño: En esta fase se realizan los algoritmos necesarios para que se cumplan
los requerimientos del usuario así como también los análisis necesarios para
saber que herramientas usar en la etapa de Codificación. Se dividen en:
 Diseño de Alto Nivel o Arquitectónico
 Diseño Detallado

 Codificación: Es la fase de programación propiamente dicha.

Prueba: Las componentes una vez programadas, se ensamblan para formar el
sistema y se demuestra que trabaja correctamente antes de ser puesto en
práctica por el usuario.
Existen varios tipos de Pruebas:
      Pruebas de unidad
      Pruebas de integración
      Pruebas de sistema.
      Pruebas de aceptación

 Mantenimiento: El software necesitará cambios después de la entrega. Los tipos

de mantenimiento son:
      Mantenimiento Preventivo y Perfectivo
      Mantenimiento Correctivo
      Mantenimiento Evolutivo

Ventajas:
 Planificación sencilla.
 Una plantilla estructurada para ingeniería de software.
 Disminuye el efecto bola de nieve al reducir el mantenimiento considerando
que se tienen unas especificaciones completas y correctas.
 La cantidad de recursos necesarios para implementar este modelo es mínimo.
 La documentación se produce en cada etapa del desarrollo del modelo de
cascada.

• Desventajas:
  proceso de creación del software tarda mucho tiempo ya que debe pasar por el
proceso de prueba y hasta que el software no esté completo no se opera.

 Evolución de los Requisitos.

 Resultados al final.
 proceso de creación del software tarda mucho tiempo ya que debe pasar por el
proceso de prueba y hasta que el software no esté completo no se opera.

 MODELO DE ESPIRAL.

El Modelo en Espiral es un modelo de proceso de software evolutivo donde se conjuga la

naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del
modelo lineal y secuencial
La meta del modelo espiral del proceso de producción del software es proporcionar un
marco para diseñar tales procesos, dirigido por los niveles de riesgo en el proyecto actual.

Cada vuelta en la espiral se divide en sectores:

 Comunicación con el Cliente: Las tareas requeridas para establecer

comunicación entre el desarrollador y el cliente.
 Planificación o Planeación: Las tareas requeridas para definir recursos, el
tiempo, determinación de los objetivos, alternativas y restricciones, y otra
información relacionada con el proyecto.
  Análisis de Riesgos: Las tareas requeridas para evaluar riesgos técnicos y de
gestión, análisis de alternativas e identificación/resolución de riesgos.

 Ingeniería: Las tareas requeridas para construir una o más representaciones de la

aplicación, desarrollo del producto hasta "el siguiente nivel".

 Construcción y Acción: Las tareas requeridas para construir, probar, instalar y

proporcionar soporte al usuario (por ejemplo, documentación y práctica).

Diferencias entre modelo en espiral y modelos tradicionales

 Reconocimiento explícito de las diferentes alternativas.

 Identificación de riesgos para cada alternativa desde el comienzo.
 Al dividir el proyecto en ciclos, al final de cada uno existe un acuerdo para los
cambios que hay que realizar en el sistema.
 El modelo se adapta a cualquier tipo de actividad adicional

Ventajas.

– A diferencia del modelo de proceso clásico que termina cuando se entrega el

software el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del
software de computadora.
– Como el software evoluciona a medida que progresa el proceso, el desarrollador y
el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele
evolutivos.

– El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de

construcción de prototipos en cualquier etapa de evolución del producto.

– El modelo en espiral demanda una consideración directa de los riesgos técnicos

en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los
riesgos antes de que se conviertan en problemas.

– En la utilización de grandes sistemas ha doblado la productividad.

– Es un enfoque realista para el desarrollo de software y de sistemas a gran escala.

Desventajas.

– Genera mucho tiempo en el desarrollo del sistema

– Modelo costoso

– Requiere experiencia en la identificación de riesgos

 – Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es
controlable

– Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas

 MODELO DE DESARROLLO RÁPIDO DE APLICACIÓN – RAD

Desarrollo rápido de aplicaciones o RAD (acrónimo en inglés de rapid application

development) es un proceso de desarrollo de software, desarrollado inicialmente por
James Maslow en 1980. El método comprende el desarrollo interactivo, la construcción de
prototipos y el uso de utilidades CASE (Computer Aided Software Engineering).
Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la
usabilidad, utilidad y la rapidez de ejecución.

Características

 Modelo secuencial lineal con tiempos cortos de desarrollo

 Varios equipos participando en el desarrollo
 Cada equipo maneja una parte del sistema
 Uso de herramientas de pruebas automatizadas
 En cada etapa de liberación, los productos parciales son integrados, probados
liberados

El enfoque RAD tiene las siguientes fases:

1. Modelado de Gestión: se modela el flujo de información entre las funciones de
gestión.

2. Modelado de Datos: se refina el flujo de información como un conjunto de objetos de

datos necesarios para apoyar la empresa. Se definen las características de cada uno de
los objetos y sus relaciones.

3. Modelado del Proceso: se definen las transformaciones (añadir, modificar, suprimir o

recuperar) sobre los objetos del modelo de datos para lograr los flujos de información de
cada función de gestión.

4. Generación de Aplicaciones: codificación de una función de gestión.

5. Pruebas y entrega: prueba de los componentes y entrega del programa que realiza
una función de gestión.

La clave del modelo RAD está en los cambios en las etapas de codificación y
pruebas:

• Codificación. El modelo RAD asume la utilización de técnicas de cuarta generación. En

lugar de crear software con lenguajes de programación de tercera generación, se trabaja
para volver a utilizar componentes de programas ya existentes (cuando es posible) o a
crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan
herramientas para facilitar la construcción de software.

• Pruebas. Como se enfatiza la reutilización, ya se han comprobado muchos de los

componentes de los programas. Esto reduce en muchos casos el tiempo de pruebas,
aunque se deben probar todos los componentes nuevos y se deben ejercitar todas las
interfaces a fondo

Ventajas:

• Enfatiza ciclos de desarrollo extremadamente cortos

• Tiene las ventajas del modelo clásico
• Se asegura de que el producto entregado cumple las necesidades del cliente

Desventajas:

• Solo se puede aplicar si el sistema se puede modularizar de forma que permita

completarse cada una de las funciones principales en menos de tres meses
• Para proyectos grandes puede requerir muchos equipos de trabajo distintos
• Requiere clientes y desarrolladores comprometidos en las rápidas actividades
necesarias
• No resulta adecuado cuando los riesgos técnicos son elevados
• Se pueden tener problemas con la aceptación del prototipo

Se requiere múltiples desarrolladores

 MODELO DE DESARROLLO XP

La programación extrema es una disciplina de desarrollo de software “relativamente”

nueva.

Características

• Metodología para un ágil desarrollo de software.

• Programación basada en los deseos del cliente.

• El equipo lo conforman los jefes de proyecto, desarrolladores y el cliente.

• Se rige por valores y principios

Valores de XP

• Comunicación: Crear software requiere de sistemas comunicados.

• Simplicidad: Empezar con lo necesario y requerido y trabajar desde ahí.

• Retroalimentación: Del sistema, del cliente, y del equipo.

• Valentia: Programa para hoy y no para mañana.

• Respeto: El equipo debe trabajar como uno, sin hacer decisiones repentinas.

Ventajas

 Programación organizada.
 Menor taza de errores.

 Satisfacción del programador

 Solución de errores de programas

 Versiones nuevas
  Implementa una forma de trabajo donde se adapte fácilmente a las circunstancias.

Desventajas

 No existe documentación del proyecto

 Imposible prever todo antes de programar

 Demasiado costoso e innecesario

 Gasta demasiado tiempo

 recursos en cambiar la documentación de la planificación para que se parezca al

código

 MODELO EVOLUTIVO

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más
completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar más
allá, durante la fase de operación. Los modelos “Iterativo Incremental” y “Espiral” (entre
otros) son dos de los más conocidos y utilizados del tipo 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 desarrolle
el sistema adecuado
Existen dos tipos de desarrollo evolutivo:

 Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario

los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes
que se tiene más claras. El sistema evoluciona conforme se añaden nuevas
características propuestas por el usuario.

 Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario

y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo
exploratorio, se comienza por definir los requisitos que no están claros para el
usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a
terminar de definir estos requisitos.

Ventajas

 La especificación puede desarrollarse de forma creciente.

 Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se

refleja en una mejora de la calidad del software.

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

Desventajas

 Proceso no Visible: Los administradores necesitan entregas para medir el

progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir
documentos que reflejen cada versión del sistema.

 Sistemas pobremente estructurados: Los cambios continuos pueden ser

perjudiciales para la estructura del software haciendo costoso el mantenimiento.

 Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan

herramientas que pueden ser incompatibles con otras o que poca gente sabe
utilizar.
 MODELO INCREMENTAL
El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía
interactiva de Construcción de Prototipos, Cada secuencia lineal produce un incremento
del software. El primer incremento generalmente es un producto esencial denominado
núcleo.

El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del

sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio
ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces.

Una vez entregado un incremento, no se realizan cambios sobre el mismo, sino

únicamente corrección de errores. Dado que la arquitectura completa se desarrolla en la
etapa inicial, es necesario conocer los requerimientos completos al comienzo del
desarrollo.

En una visión genérica, el proceso se divide en 4 partes:

 Análisis
 Diseño

 Código

 Prueba

Características:

 Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta
frecuencia.
 El usuario se involucra más.

 Difícil de evaluar el costo total.

 Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a

operar como un todo.
  Requiere gestores experimentados.

 Los errores en los requisitos se detectan tarde.

 El resultado puede ser positivo.

Ventajas:

 Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se

implementa la funcionalidad parcial.
 También provee un impacto ventajoso frente al cliente, que es la entrega temprana
de partes operativas del software.

 El modelo proporciona todas las ventajas del modelo en Cascada realimentado,

reduciendo sus desventajas sólo al ámbito de cada incremento.

 Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

Desventajas:

 El modelo incremental no es recomendable para casos de sistemas de tiempo

real, de alto nivel de seguridad, de procesamiento distribuido y/o de alto índice de
riesgos.
 Requiere de mucha planeación, tanto administrativa como técnica.

 Requiere de metas claras para conocer el estado del proyecto.

 MODELO DE PROTOTIPO

También conocido como desarrollo con prototipación o modelo de desarrollo evolutivo, se

inicia con la definición de los objetivos globales para el software, luego se identifican los
requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Este
modelo se utilizan para dar al usuario una vista preliminar de parte del software. Este
modelo es básicamente prueba y error ya que si al usuario no le gusta una parte del
prototipo significa que la prueba fallo por lo cual se debe corregir el error que se tenga
hasta que el usuario quede satisfecho

Además el prototipo debe ser construido en poco tiempo, usando los programas
adecuados y no se debe utilizar mucho dinero pues a partir de que este sea aprobado
nosotros podemos iniciar el verdadero desarrollo del software. Pero eso si al construir el
prototipo nos asegura que nuestro software sea de mejor calidad, además de que su
interfaz sea de agrado para el usuario. Un prototipo podrá ser construido solo si con el
software es posible experimentar.

Etapas

 Recolección y refinamiento de requisitos

 Modelado, diseño rápido

 Construcción del Prototipo

 Desarrollo, evaluación del prototipo por el cliente

 Refinamiento del prototipo

 Producto de Ingeniería

Para que sea efectivo

 Debe ser un sistema con el que se pueda experimentar
 Debe ser comparativamente barato(menor que el 10%)

 Debe desarrollarse rápidamente

 Énfasis en la interfaz de usuario

 Equipo de desarrollo reducido

 Herramientas y lenguajes adecuadas

Tipos de Modelo de Prototipos

 Modelo de Prototipos rápido: Metodología de diseño que desarrolla rápidamente
nuevos diseños, los evalúa y prescinde del prototipo cuando el próximo diseño es
desarrollado mediante un nuevo prototipo.
 Modelo de Prototipos reutilizable: También conocido como "Evolutionary
Prototyping"; no se pierde el esfuerzo efectuado en la construcción del prototipo
pues sus partes o el conjunto pueden ser utilizados para construir el producto real.
Mayormente es utilizado en el desarrollo de software, si bien determinados
productos de hardware pueden hacer uso del prototipo como la base del diseño de
moldes en la fabricación con plásticos o en el diseño de carrocerías de
automóviles.
  Modelo de Prototipos Modular: También conocido como Prototipado Incremental
(Incremental prototyping); se añaden nuevos elementos sobre el prototipo a
medida que el ciclo de diseño progresa.

 Modelo de Prototipos Horizontal: El prototipo cubre un amplio número de

aspectos y funciones pero la mayoría no son operativas. Resulta muy útil para
evaluar el alcance del producto, pero no su uso real.

 Modelo de Prototipos Vertical: El prototipo cubre sólo un pequeño número de

funciones operativas. Resulta muy útil para evaluar el uso real sobre una pequeña
parte del producto.

 Modelo de Prototipos de Baja-fidelidad: El prototipo se implementa con papel y

lápiz, emulando la función del producto real sin mostrar el aspecto real del mismo.
Resulta muy útil para realizar tests baratos.

 Modelo de Prototipos de Alta-fidelidad: El prototipo se implementa de la forma

más cercana posible al diseño real en términos de aspecto, impresiones,
interacción y tiempo.

Tipos de prototipos .
 El desechable: nos sirve para eliminar dudas sobre lo que realmente quiere el
cliente además para desarrollar la interfaz que más le convenga al cliente.
 El evolucionario: es un modelo parcialmente construido que puede pasar de ser
prototipo a ser software pero no tiene una buena documentación y calidad.

Ventajas
 No modifica el flujo del ciclo de vida
 Reduce el riesgo de construir productos que no satisfagan las necesidades de los
usuarios

 Reduce costo y aumenta la probabilidad de éxito

 Exige disponer de las herramientas adecuadas

 Este modelo es útil cuando el cliente conoce los objetivos generales para el
software, pero no identifica los requisitos detallados de entrada, procesamiento o
salida.

 También ofrece un mejor enfoque cuando el responsable del desarrollo del

software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un
sistema operativo o de la forma que debería tomar la interacción humano-
máquina.

Desventajas
 Debido a que el usuario ve que el prototipo funciona piensa que este es el
producto terminado y no entienden que recién se va a desarrollar el software.
  El desarrollador puede caer en la tentación de ampliar el prototipo para construir el
sistema final sin tener en cuenta los compromisos de calidad y mantenimiento que
tiene con el cliente

 MODELO DE DESARROLLO CONCURRENTE

El modelo 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.
Durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo
de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparará la
actividad de análisis del estado hecho al estado cambios en espera.
Este modelo se utiliza a menudo como el paradigma de desarrollo de aplicaciones
cliente/servidor.

Características:
• Se puede expresar de manera esquematizada
• Las actividades llevan procesos concurrentes
• Es aplicable a todo tipo de desarrollo de software
• Es un módulo aplicable para cliente soñador
• Está dirigido por las necesidades del usuario
• es aplicable al cliente servidor

Ventajas

 Excelente para proyectos en los que se conforman grupos de trabajo

independientes.
 Proporciona una imagen exacta del estado actual de un proyecto.
Desventajas
 Si no se dan las condiciones señaladas no es aplicable.
 Si no existen grupos de trabajo no se puede trabajar en este método

 MODELO DESARROLLADO EN COMPONENTES

El modelo de desarrollo 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. Sin embargo, el modelo de desarrollo basado en componentes
configura aplicaciones desde componentes preparados de software (clases). 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

Ventajas:
1. Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización de
software.
2. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de
los componentes antes de probar el conjunto completo de componentes ensamblados.
3. Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre
componentes, el desabollador es libre de actualizar y/o agregar componentes según sea
necesario, sin afectar otras partes del sistema.
4. Mayor calidad. Dado que un componente puede ser construido y luego mejorado
continuamente por un experto u organización, la calidad de una aplicación basada en
componentes mejorará con el paso del tiempo

Desventajas
  Los “compromisos” en los requisitos son inevitables, por lo cual puede que el
software no cumpla las expectativas del cliente.
•Las actualizaciones de los componentes adquiridos no están en manos de los
desarrolladores del sistema.
 Si no se dan las condiciones señaladas no es aplicable
 Si no existen grupos de trabajo no se puede trabajar en este método

3.- MODELOS DESCRIPTIVOS DE DESARROLLO DE SOFTWARE

Modelo en cascada

El modelo en 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.

Hay veces que los requerimientos para cierto problema se comprenden bien: cuando el
trabajo desde la comunicación hasta el despliegue fluye en forma razonablemente lineal.
Esta situación se encuentra en ocasiones cuando deben hacerse adaptaciones o mejoras
bien definidas a un sistema ya existente (por ejemplo a un sistema de contabilidad que es
obligatorio hacer debido a cambios en las regulaciones gubernamentales).

Modelos de proceso Incremental

El modelo incremental combina elementos de los flujos de proceso lineal y paralelo. este
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 paralela a los incrementos producidos en el flujo
del proceso evolutivo, cuando se utiliza el 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
funcionalidades. Este proceso se repite después de entregar cada incremento, hasta
terminar el producto final.

4.- MANTENIMIENTO DE SOFTWARE

El Servicio de mantenimiento de software es una de las actividades en la Ingeniería
de Software y es el proceso de mejorar y optimizar el software desplegado (revisión
del programa), así como también remediar los defectos.

El mantenimiento de software es también una de las fases en el Ciclo de Vida de

Desarrollo de Sistemas (SDLC ó System Development Life Cycle), que se aplica al
desarrollo de software. La fase de mantenimiento es la fase que viene después del
despliegue (implementación) del software en el campo.

La fase de mantenimiento de software involucra cambios al software en orden de corregir

defectos y dependencias encontradas durante su uso tanto como la adición de nueva
funcionalidad para mejorar la usabilidad y aplicabilidad del software

Tipos de mantenimiento

 Mantenimiento preventivo. Consiste en la revisión constante del software para

detectar posibles focos de problemas que puedan surgir en el futuro.
 Mantenimiento predictivo. Evalúa el flujo de ejecución del programa para
predecir con certeza el momento en el que se producirá la falla, y así determinar
cuándo es adecuado realizar los ajustes correspondientes.
 Mantenimiento correctivo. Corrige los defectos encontrados en el software, y
que originan un comportamiento distinto al deseado. Estas fallas pueden ser de
procesamiento, rendimiento (por ejemplo, uso ineficiente de los recursos de
hardware), programación (inconsistencias en la ejecución), seguridad o
estabilidad, entre otras.
 Mantenimiento adaptativo. Si se requiere cambiar el entorno de uso de la
aplicación (que incluye al sistema operativo, a la plataforma de hardware o, en el
caso de las aplicaciones web, al navegador), puede ser indispensable modificarla
para mantener su plena funcionalidad en estas nuevas condiciones.
 Mantenimiento evolutivo. Es un caso especial donde la adaptación resulta
prácticamente obligatoria, ya que de lo contrario el programa quedaría obsoleto
con el paso del tiempo. Por ejemplo, el cambio de versión en un navegador
(muchas veces impuesto sin el consentimiento del usuario) suele obligar a realizar
ajustes en plugins y aplicaciones web.
 Mantenimiento perfectivo. Por distintas razones, el usuario puede solicitar el
agregado de nuevas funcionalidades o características no contempladas al
momento de la implementación del software. El mantenimiento perfectivo adapta la
aplicación a este requerimiento.

5.- MODELO ESPIRAL

Evaluación del riesgo

Consiste en evaluar las diferentes alternativas que se plantean teniendo en cuenta los
objetivos a conseguir y las restricciones impuestas. Frecuentemente, este paso identifica
las áreas de incertidumbre del proyecto con sus correspondientes riesgos. Es el estudio
de las causas de las posibles amenazas y probables eventos no deseados y los daños y
consecuencias que éstas puedan producir.
Si existen riesgos, lo siguiente es la formulación de una estrategia efectiva en coste
(utilizando prototipos, simulación, bancos de prueba, cuestionario para los usuarios,
modelización analítica o combinaciones de éstas y otras técnicas de resolución de
riesgos) para resolver dichos riesgos.

6.- GESTION DE PROYECTOS

MODELO CPM RUTA CRÍTICA

El método CPM o Ruta Crítica (equivalente a la sigla en inglés Critical Path Method) es
frecuentemente utilizado en el desarrollo y control de proyectos. El objetivo principal es
determinar la duración de un proyecto, entendiendo éste como una secuencia de
actividades relacionadas entre sí, donde cada una de las actividades tiene una duración
estimada.

Una ruta es una trayectoria desde el inicio hasta el final de un proyecto. En este sentido,
la longitud de la ruta crítica es igual a la la trayectoria más grande del proyecto. Cabe
destacar que la duración de un proyecto es igual a la ruta crítica.

Etapas de CPM

1. Definir el proyecto con todas sus actividades o partes principales.

2. Establecer relaciones entre las actividades. Decidir cuál debe comenzar antes y cuál
debe seguir después.
3. Dibujar un diagrama conectando las diferentes actividades en base a sus relaciones de
precedencia.
4. Definir costos y tiempo estimado para cada actividad.
5. Identificar la trayectoria más larga del proyecto, siendo ésta la que determinará la
duración del proyecto (Ruta Crítica).
6. Utilizar el diagrama como ayuda para planear, supervisar y controlar el proyecto.

Ventajas cpm

1. Enseña una disciplina lógica para planificar y organizar un programa detallado de

largo alcance.
2. Proporciona una metodología Standard de comunicar los planes del proyecto
mediante un cuadro de tres dimensiones (tiempo, personal; costo).

3. Identifica los elementos (segmentos) más críticos del plan, en que problemas
potenciales puedan perjudicar el cumplimiento del programa propuesto.
 4. Ofrece la posibilidad de simular los efectos de las decisiones alternativas o
situaciones imprevistas y una oportunidad para estudiar sus consecuencias en
relación a los plazos de cumplimiento de los programas.

5. Aporta la probabilidad de cumplir exitosamente los plazos propuestos.

6. En otras palabras: CPM es un sistema dinámico, que se mueve con el progreso

del proyecto, reflejando en cualquier momento el STATUS presente del plan de
acción.

Limitaciones del cpm

El CPM fue desarrollado para el complejo pero los proyectos bastante rutinarios con
incertidumbre mínima en los tiempos de la terminación del proyecto. Para menos
proyectos de la rutina hay más incertidumbre en los tiempos de la terminación, y límites
de esta incertidumbre la utilidad del modelo determinista del CPM. Una alternativa al CPM
es el modelo del planeamiento del proyecto del PERT, que permite que una gama de
duraciones sea especificada para cada actividad.

MODELO DE GANTT

El diagrama de GANTT es una herramienta que le permite al usuario modelar la

planificación de las tareas necesarias para la realización de un proyecto.

Es una popular herramienta gráfica cuyo objetivo es mostrar el tiempo de dedicación

previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado. A
pesar de que, en principio, el diagrama de Gantt no indica las relaciones existentes entre
actividades, la posición de cada tarea a lo largo del tiempo hace que se puedan identificar
dichas relaciones e interdependencias.

En gestión de proyectos, el diagrama de Gantt muestra el origen y el final de las

diferentes unidades mínimas de trabajo y los grupos de tareas (llamados summary
elements en la imagen) o las dependencias entre unidades mínimas de trabajo (no
mostradas en la imagen).

Básicamente el diagrama está compuesto por un eje vertical donde se establecen las
actividades que constituyen el trabajo que se va a ejecutar, y un eje horizontal que
muestra en un calendario la duración de cada una de ellas.

Características
 Cada actividad se representa mediante un bloque rectangular cuya longitud
indica su duración; la altura carece de significado.
 La posición de cada bloque en el diagrama indica los instantes de inicio y
finalización de las tareas a que corresponden.
  Los bloques correspondientes a tareas del camino crítico acostumbran a
rellenarse en otro color

Ventajas
* Su construcción no requiere de gran planificación.
* Resultan muy eficaces en las etapas iniciales de la planificación.
* Son adecuados para la planificación de actividades relativamente simples.
Representa un instrumento de bajo costo y extrema simplicidad en su utilización

Desventajas
* No permite optimizar el desarrollo de un programa.
* Después de iniciada la ejecución de la actividad y cuando comienza a efectuarse
modificaciones, el gráfico tiende a volverse confuso.

* No ofrece condiciones para el análisis de opciones

SWEBOK

Contiene conceptos y conocimientos acerca de la ingeniería de software y de cómo debe

de llevarse a cabo por un ingeniero de software, proporciona una visión general acerca
del software de calidad y de las buenas prácticas de desarrollo, las áreas de conocimiento
de han ido ampliando a través de las versiones.

Para SWEBOK V3.0 el conocimiento se ha agrupado en áreas, que son:

 Requisitos.  Gestión de software.

 Diseño.  Proceso de ingeniería.
 Desarrollo.  Herramientas y métodos de
ingeniería.
 Pruebas..
 Calidad de software
 Mantenimiento.
 Gestión de configuración.

Requisitos: Interpreta las necesidades del cliente en una lista de objetivos a cumplir,
cada uno se puede trasformar en un subsistema o sólo en una funcionalidad, si los
requisitos no son interpretados correctamente, el sistema sufrirá consecuencias graves en
el desarrollo y mantenimiento.
Diseño: Define la arquitectura, interfaces, diagramas de flujo, entre otros del sistema; en
esta etapa se analizan los requerimientos y se crean posibles soluciones gráficas a cada
uno.

Desarrollo: Interpreta la arquitectura, esquemas y diagramas de flujo definidos en la

etapa de diseño en codificación de un lenguaje de programación, interactuando también
con el sistema operativo y algunas veces con los dispositivos de entrada y salida.

Pruebas: Evalúa la eficiencia y calidad del producto detectando las posibles mejoras o
fallas.

Mantenimiento: Corrige las fallas y realiza las mejoras detectadas anteriormente.

Gestión de configuración: Identifica la configuración general del sistema para realizar

posibles adaptaciones y configurar su ciclo de vida, detecta las características físicas y
funcionales del sistema además del cumplimiento de sus objetivos.

Gestión de ingeniería: Verifica la infraestructura del proyecto, el control y la planeación

del programa, asegura que el mantenimiento del producto sea adecuado.

Gestión del proceso: Valida todas las etapas del proceso, como las tareas que
componen el proceso, funciones, mediciones, configuración, mantenimiento, entre otros.

Herramientas y proceso de ingeniería: son todos los recursos virtuales que nos ayudan
a realizar tareas exhaustivas como, validar el producto, crear el diseño, realizar pruebas,
detectar fallas, entre otros; pero es importante saber que estas herramientas sólo
interpretan el resultado de la información que brindamos, si la información es errónea, el
resultado puede llevarnos a una mala decisión.

Calidad de software: el conjunto de las actividades vistas anteriormente tiene como

objetivo crear un producto de calidad, el cual pueda brindar al cliente la solución a los
procesos que realiza o a la problemática que tiene, siendo eficaz, costeable, moldeable, y
que pueda tener futuras implementación, éstas son algunas características de software de
calidad.

CONCLUSION
La ingeniería del software se desarrolló para poder solucionar problemas en la creación
de aplicación y creaciones de piezas de software especializadas. Gracias a que cuenta
con varios elementos de desarrollo e investigación sobre los paradigmas, se pueden
determinar nuevas formas de perfeccionamiento de aplicaciones mejorando la calidad de
éstos y el tiempo en que se crean y se distribuyen a los usuarios. Cuando la ingeniería de
software no se utiliza correctamente pueden omitirse varios de los principales elementos y
los paradigmas de programación, estos pueden aplicarse a cualquier lenguaje de
programación, ya sea para el desarrollo de animaciones mediante scripts de audio, de
movimiento o con elementos más robustos como composición de código en un sistema
operativo para una computadora, o el desarrollo de aplicaciones que hagan manejo de
elementos multimedia que requieren de codificación y decodificación.