Captura de Pantalla de UML Instalado

SOFTWARE UML

SOFTWARE UML

UML: Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables.

El punto importante para notar aquí es que UML es un "lenguaje" para especificar y no un método o un proceso. UML se usa para definir un sistema de software; para detallar los artefactos en el sistema; para documentar y construir -es el lenguaje en el que está descrito el modelo. UML se puede usar en una gran variedad de formas para soportar una metodología de desarrollo de software (tal como el Proceso Unificado de Rational) -pero no especifica en sí mismo qué metodología o proceso usar.

¿PARA QUÉ SIRVE UML?

UML sirve para hacer modelos que permitan:

• Visualizar como es un sistema o como queremos que sea.
• Especificar la estructura y/o comportamiento de un sistema.
• Hacer una plantilla que guíe la construcción de los sistemas
• Documentar las decisiones que hemos tomado.

El modelado sirve no solamente para los grandes sistemas; aún en aplicaciones de pequeño tamaño se obtienen beneficios de modelar, sin embargo, es un hecho que entre más grande y más complejo es el sistema, el modelado juega un papel más importante. Esto se debe a una razón simple: “Hacemos modelos de sistemas complejos porque no podemos entenderlos en su totalidad”.

Hay límites para el entendimiento de la complejidad. A través del modelado reducimos el ámbito del problema de estudio al enfocar solo un aspecto a la vez.

UML puede ser usado extensivamente en: Recopilación de requerimientos, Análisis de aplicaciones, Diseño de sistemas, en pruebas, en implementación, en reingeniería y prácticamente en cualquier actividad de desarrollo que sea susceptible de ser modelada.

Cabe aclarar que aunque UML es orientado a objetos preferentemente, es útil en cualquier modelo tecnológico ya que es independiente de lenguajes de programación o tecnología determinada.

                                                                                                                                                                  

INGENIERIA DE REQUISITOS

INGENIERÍA DE REQUISITOS

El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema de software es llamado Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos es entregar una especificación de requerimientos de software correcta y completa. La ingeniería de requerimientos apunta a mejorar la forma en que comprendemos y definimos sistemas de software complejos. Que tiene como objetivos:

• 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.
• Gestionar las líneas base y las peticiones de cambios que se vayan produciendo en la especificación de requisitos, manteniendo la trazabilidad entre los requisitos y otros productos del desarrollo.

Actividades

Existen cuatro actividades básicas (extracción, análisis, especificación y validación) que se tienen que llevar a cabo para completar el proceso. Estas actividades ayudan a reconocer la importancia que tiene, para el desarrollo de un proyecto de software, realizar una especificación y administración adecuada de los requisitos de los clientes o usuarios.

• Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requisitos del sistema.

• Análisis: Sobre la base de la extracción realizada previamente, comienza esta fase. Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de requisitos; aquí se leen los requisitos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requisitos.

• Especificación: En esta fase se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle. En la práctica, esta etapa se va realizando conjuntamente con el análisis, pero se podría decir que la Especificación es el “pasar en limpio” el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML.

• Validación: La validación es la etapa final de la IR. Su objetivo es verificar todos los requisitos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requisitos sean consistentes y que estén completos.

La validación representa un punto de control interno y externo; interno, porque se debe verificar internamente lo que se está haciendo, y externo, porque se debe validar con el cliente.

Herramientas

Existen diversas técnicas y herramientas que se utilizan para llevar a cabo cada una de las actividades del proceso de Ingeniería de Requisitos, una de las razones por las cuales surgen los errores a la hora del levantamiento es la existencia de una gama de herramientas. No existe una especie de guía para el uso de los desarrolladores, estos utilizan incluso en la captura más de una técnica en cada de las actividades que contiene el proceso.

Herramientas	Extracción	Análisis	Especificación	Validación
Entrevistas y Cuestionario	X
Sistemas Existentes	X	X
Grabaciones de video y de audio.	X	X
Brainstorming (Tormenta de Ideas)	X	X
Sistemas Existentes	X	X
Arqueología de Documentos	X	X
Aprendiz	X
Observación	X
Run Use Case WorkShop	X
Prototipo Bosquejado	X	X	X
Prototipo Tangible/usable	X		X	X
FODA		X
Cadena de Valor		X
Modelo de clase conceptual		X	X
Diagrama de actividad		X	X
ESRE	X	X	X	X
Casos de uso	X	X	X	X
Casa de calidad o QFD				X
Checklist	X			X
Sistemas Existentes	X	X

Herramientas más Usadas

• Entrevistas y cuestionarios: Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o grupos, información que se obtiene conversando con el encuestado. Las preguntas suelen distinguirse en dos categorías: abiertas y cerradas. Las preguntas abiertas permiten que los encuestados respondan con su propia terminología, mientras que las preguntas cerradas predeterminan todas las posibles respuestas y el interrogado elige entre las opciones presentadas.

• Grabaciones de video y de audio: Básicamente existen dos formas de utilizar las grabaciones: como registro y apoyo de las entrevistas, y para analizar algún proceso en particular. En cuanto a su función de apoyo, es importante porque permite centrar la atención en la entrevista en sí, en vez de distraerse tomando notas de todo lo que se dice. Cuando se trata de analizar algún proceso en particular, su ayuda es inestimable (sobre todo las filmaciones de video) porque permite ver y analizar en detalle ese proceso la cantidad de veces que sea necesario.

• Brainstorming (tormenta de ideas): Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar la máxima cantidad posible de requisitos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable.

https://www.ecured.cu/Ingenier%C3%ADa_de_requisitos

Para Pressman, en el proceso de análisis de requerimientos del software se puede identificar cinco tareas o etapas fundamentales: 

1. Reconocimiento del problema Se deben de estudiar inicialmente las especificaciones del sistema y el plan del proyecto del software. Realmente se necesita llegar a comprender el software dentro del contexto del sistema. El analista debe establecer un canal adecuado de comunicación con el equipo de trabajo involucrado en el proyecto. En esta etapa la función primordial del analista en todo momento es reconocer los elementos del problema tal y como los percibe el usuario. 

2. Evaluación y síntesis En esta etapa el analista debe centrarse en el flujo y estructura de la información, definir las funciones del software, determinar los factores que afectan el desarrollo de nuestro sistema, establecer las características de la interfaz del sistema y descubrir las restricciones del diseño. Todas las tareas anteriores conducen fácilmente a la determinación del problema de forma sintetizada. 

3. Modelización Durante la evaluación y síntesis de la solución, se crean modelos del sistema que servirán al analista para comprender mejor el proceso funcional, operativo y de contenido de la información. El modelo Ingeniería de Requerimientos Herramienta para Implementar LEL y Escenarios Página: 10 servirá de pilar para el diseño del software y como base para la creación de una especificación del software. 

4. Especificación Las tareas asociadas con la especificación intenta proporcionar una representación del software. Esto más adelante permitirá llegar a determinar si se ha llegado a comprender el software, en los casos que se lleguen a modelar se pueden dejar plasmados manuales. 

5. Revisión Una vez que se han descrito la información básica, se especifican los criterios de validación que han de servir para demostrar que se ha llegado a un buen entendimiento de la forma de implementar con éxito el software. La documentación del análisis de requerimientos y manuales, permitirán una revisión por parte del cliente, la cual posiblemente traerá consigo modificaciones en las funciones del sistema por lo que deberán revisarse el plan de desarrollo y las estimaciones previstas inicialmente.

http://sedici.unlp.edu.ar/bitstream/handle/10915/4057/2_-_Ingenier%C3%ADa_de_requerimientos.pdf?sequence=4

Proyecto

MODELO DE NEGOCIO

Modelo de negocio

Definición:

Un modelo de negocio es una herramienta previa al plan de negocio que te permitirá definir con claridad qué vas a ofrecer al mercado, cómo lo vas a hacer, a quién se lo vas a vender, cómo se lo vas a vender y de qué forma vas a generar ingresos. Es una herramienta de análisis que te permitirá saber quién eres, cómo lo haces, a qué coste, con qué medios y qué fuentes de ingresos vas a tener. Definir tu modelo de negocio es saber cuál es tu ADN, cómo está hecho, cómo se puede modificar, cómo pulir, cómo cambiar, cómo moldear.

Los modelos que están funcionando son aquellos que son capaces de crear valor para el cliente, es decir, que tienen una propuesta de valor clara, que son capaces de llegar al cliente, de diferenciarse, de establecer fuertes lazos con el cliente, de fidelizar y que son capaces de producirlos también de una manera especial.

En términos generales se suele usar para definir como un negocio o empresa genera valor a través de la utilización de la cadena de valor. Si bien esta es una herramienta muy importante, la misma es muy estática, lineal y que no muestra relaciones entre las actividades primarias y las actividades de apoyo.

http://www.emprendedores.es/crear-una-empresa/que-significa-modelo-de-negocio

Componentes:

-Procesos de negocios:

Se trata de un enfoque de gestión integral que, a través de los procesos del Negocio, busca la alineación de aquellos elementos o aspectos de una organización que tengan un impacto directo o indirecto en el producto o servicio que se brinda a los clientes.

Un proceso de negocio es una colección de actividades diseñadas para producir una salida específica para un cliente o mercado particular. Implica en un fuerte énfasis en ‘como’ se hace el trabajo en una organización, en contraposición al enfoque en ‘que’ de producto. Así, un proceso es un ordenamiento especifico de actividades de trabajo a través del tiempo y del espacio, con un comienzo, un fin, entradas y salidas claramente identificados.

-Reglas de negocio:

Son aquellas que se crean durante la configuración de los procesos de manera que hay que definirlas para cada clase de procesos. En otras palabras, son las reglas que definen los comportamientos de ciertos elementos de los procesos como por ejemplo las condiciones de las compuertas. Estas reglas están siempre en todos los sistemas BPM como como condiciones de funcionamiento de los procesos.

-Objeto de negocios:

Un objeto de negocio es un conjunto de compras o elementos que se utilizan conjuntamente para representar un proceso de negocio significativo. Los objetos de negocios se definen como variables para pasar información a través de un proceso de negocio. Cada objeto de negocio puede ser un tipo de datos primitivo (como una serie o un entero) o puede ser en sí mismo un objeto de negocio.

-Actores:

Son las entidades que realizan las actividades del proceso o generan eventos pueden representar a personas dentro de una organización.

Unidades organizativas:

Esto se refiere a como su nombre lo dice unidades organizativas que participan en un diagrama de negocios, se podrían definir como un rol de negocios en general por ejemplo un comprador, vendedor, proveedor.

Notaciones:

UML:
Lenguaje Unificado de Modelado (LUM o UML) es el lenguaje de modelado de sistemas de software más reconocido y usado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para especificar, visualizar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema, incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante decir que UML es un "lenguaje de modelado" para describir o para especificar métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir; es decir en el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso utilizar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
Una de la metas principales de UML es avanzar en el estado de la integración institucional proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo, para lograr un intercambio exitoso de modelos de información entre herramientas, se requirió definir a UML una semántica y una notación.
La notación es la parte gráfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado. Por ejemplo, la notación del diagrama de clases define como se representan los elementos y conceptos como son: una clase, una asociación y una multiplicidad. ¿Y qué significa exactamente una asociación o multiplicidad en una clase?, ¿Un meta modelo es la manera de definir esto (un diagrama, usualmente de clases, que define la notación)?

BPMN:

El Business Modeling Notation o BPMN (Notación para el Modelado de Procesos de Negocios) es un método de negocios que ilustra los procesos en forma similar a un diagrama de flujo. El BPMN fue desarrollado en un principio por el Business Process Management Initiative (BPMNI). Actualmente es sostenido por el Grupo de Gestión de Objetos (OMG).

El BPMN proporciona una manera fácil de definir y analizar los procesos de negocios públicos y privados. Además, brinda una notación estándar que sea comprensible para la gestión del personal, analistas y desarrolladores. La intención original del BPMN era ayudar a establecer puentes de comunicación que a menudo existen dentro de una organización o empresa. Esta notación puede ayudar a asegurarse de que el XML (documentos diseñados para la ejecución de diversos procesos de negocios), puedan ser visualizados con una notación común.

Un diagrama de BPMN es ensamblado a partir de un conjunto de elementos básicos. Los elementos se clasifican en tres grupos:
- Objetos de flujo: figuras geométricas como círculos, rectángulos o rombos de control de flujo que indican los eventos
y actividades.
- Objetos de conexión: trazos o líneas de puntos que pueden incluir flechas para indicar la dirección del proceso.
- Swimlanes (carriles de piscina): llamada así por su semejanza geométrica con las líneas de carril del fondo de  una piscina   olímpica. Rectas sólidas a lo largo y dentro de un cuadrado denominado fondo. El Swinglanes organiza el flujo de objetos en categorías con funcionalidad similar.

DFD:
Un diagrama de flujo de datos (DFD por sus siglas en español e inglés) es una representación gráfica del "flujo" de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado). Es una práctica común para un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción entre el sistema y las entidades externas. Este contexto a nivel de DFD se "explotó" para mostrar más detalles del sistema que se está modelando.
Los diagramas de flujo de datos fueron inventados por Larry Constantine, el desarrollador original del diseño estructurado, basado en el modelo de computación de Martin y Estrin: "flujo gráfico de datos" . Los diagramas de flujo de datos (DFD) son una de las tres perspectivas esenciales de Análisis de Sistemas Estructurados y Diseño por Método SSADM. El patrocinador de un proyecto y los usuarios finales tendrán que ser informados y consultados en todas las etapas de una evolución del sistema. Con un diagrama de flujo de datos, los usuarios van a poder visualizar la forma en que el sistema funcione, lo que el sistema va a lograr, y cómo el sistema se pondrá en práctica. El antiguo sistema de diagramas de flujo de datos puede ser elaborado y se comparó con el nuevo sistema de diagramas de flujo para establecer diferencias y mejoras a aplicar para desarrollar un sistema más eficiente. Los diagramas de flujo de datos pueden ser usados para proporcionar al usuario final una idea física de cómo resultarán los datos a última instancia, y cómo tienen un efecto sobre la estructura de todo el sistema. La manera en que cualquier sistema es desarrollado puede determinarse a través de un diagrama de flujo de datos. El desarrollo de un DFD ayuda en la identificación de los datos de la transacción en el modelo de datos.

IDEFO

IDEF0 constituye una técnica de modelación gráfica, especializada en la representación de las relaciones e interdependencias existentes entre los diferentes procesos, como se muestra en el esquema de la figura 1.1. [Winnik, 2008]

Su principal característica consiste en su capacidad para diferenciar entre tres tipos posibles de relación entre procesos:

1. relaciones que establecen las guías que debe tener en cuenta el proceso.
2. relaciones que aportan los recursos necesarios para llevar a cabo el proceso.
3. relaciones de encadenamiento lineal entre procesos (entrada – salida).

La capacidad de diferenciar relaciones permite modelar organizaciones completas. 

EPC

EPC es modelo dinámico que representa juntos los recursos del negocio como son los sistemas, la organización, datos e información y los organiza para brindar una secuencia de tareas o actividades (el proceso) que añaden valor al negocio. [Davis, 2001]

Esencialmente hay cuatro tipos de objetos usados en EPC:

• Eventos
• Funciones
• Reglas
• Recursos (Datos, organización, sistemas)

La filosofía básica en este tipo de modelos es representar una secuencia evento-función-evento-función-evento…, especificando para cada función las reglas y recursos que intervienen.

https://www.gestiopolis.com/lenguajes-notaciones-herramientas-modelado-analisis-procesos/

http://infoblog-ingsoftware.blogspot.mx/2010/11/las-tres-notaciones-son-y-uml-lenguaje.html

captura del project libre instalado

project libre

PROJECT LIBRE

Realizada ya la instalación y configuración inicial de ProjectLibre en nuestro sistema, revisaremos el modo de iniciar la programación de un proyecto. Para ello haremos un recorrido, principalmente visual, siguiendo una secuencia lógica de ingreso de datos: Tareas, recursos, asignaciones y costos. En esta primera parte destinada al ingreso de datos, revisaremos específicamente lo relacionado con las tareas o actividades.

Cambio del tiempo laborable

Con este fin debemos definir el modo de distribución de la jornada de trabajo, el horario de ingreso, colación y salida de acuerdo a la legislación laboral local, el calendario con los feriados acordes al lugar de ejecución del proyecto. Para ello utilizamos el botón “Calendario” del panel “Proyecto” en la cinta de herramientas.

El programa incorpora tres calendarios base: Estándar, 24 horas y Turno de noche, sobre la base de ellos se pueden crear nuevas plantillas de distribución de la jornada de trabajo. En este caso, se crearon dos plantillas, una en jornada de 9 horas de lunes a viernes, basada en el calendario estándar, y una de días corridos, basada en el calendario 24 horas.

El horario de trabajo establecido, tal como lo indica el cuadro de configuración, aplica a las duraciones de las tareas. Esta configuración se realiza en el botón “Opciones”.

Para establecer un feriado, basta con seleccionar el día desde el calendario, y establecerlo como “No laborable”.

Información del proyecto

En el botón “Información” del panel “Proyecto” en la cinta de herramientas, abrimos el cuadro de configuración para incorporar datos como el nombre del proyecto, el responsable a cargo, su fecha de inicio, el calendario base, etc.

Listado de tareas y duración

El ingreso de las tareas o actividades y sus duraciones se realiza manualmente o copiando y pegando desde una planilla de cálculo como LibreOffice Calc, como se ha hecho en este caso.

La indentación, o jerarquización de las tareas de acuerdo a una Workbase Structure o WBS, se ejecuta con el botón “Sangrar” de la pestaña “Tarea”. Se pueden seleccionar grupos de tareas para aplicar sangría en bloques.

Vinculación entre tareas

La vinculación se realiza seleccionando dos o más tareas y presionando el botón “Vincular” de la pestaña “Tarea”. El vínculo siempre se produce desde arriba hacia abajo, de modo que el listado de tareas debe respetar el orden secuencial, con las predecesoras antes de las sucesoras. Al seleccionar varias tareas, éstas quedan vinculadas en secuencia lineal.

El vínculo predeterminado es “de fin a comienzo”, pero se puede modificar esto, así como la eventaual posposición de una tarea respecto de su antecesora, haciendo clic en la flecha de vínculo, e incorporando estas modificaciones en el cuadro de configuración de “Dependencia de la Tarea”, como se muestra a continuación.

Vistas alternativas

El programa entrega la posibilidad de visualizar la estructura principal de la programación o WBS, y la estructura de red de ésta. Se trata de visualizaciones, sin posibilidad de configurar los datos que se muestran.

WBS

Red

Inserción de columnas

El programa entrega la posibilidad de incorporar columnas adicionales en la tabla de datos que acompaña a la carta Gantt. Para ello basta con hacer clic con botón derecho sobre el encabezado de una columna existente, y seleccionar la opción “Insertar Columna”.

Las opciones incluyen columnas de información predeterminadas por el programa, y columnas con campos personalizados de texto o numéricos.

Configuración avanzada de tareas

Finalmente, podemos comprobar que existe un cuadro de “Información” en la pestaña de “Tareas”, que nos permite acceder a aspectos que se clasifican como “Adelantados”, en los que podemos establecer el tipo de tarea, el tipo de restricción temporal al que está sujeta, el calendario asociado, y el porcentaje completado.

Hasta aquí la información respecto del ingreso y administración de tareas o actividades de proyecto.

FASES DE LA INGENIERÍA DE SOFTWARE

FASES DE LA INGENIERÍA DE SOFTWARE:

Cualquier sistema de información va pasando por una serie de fases a lo largo de su vida.

Su ciclo de vida comprende una serie de etapas entre las que se encuentran las siguientes.

• ·         Análisis
• ·         Diseño
• ·       Programación
• ·         Pruebas
• ·         Implementación
• ·         Mantenimiento
• ·         Etapa final EOL

Etapa de análisis: Esta etapa tiene por objeto realizar un análisis global del sistema, estableciendo los requisitos de todos los elementos del sistema y luego asignar al software la parte de los requisitos que le afectan. Este planteamiento del sistema es esencial cuando el software debe interrelacionarse con otros elementos, tales como personas, hardware y bases de datos.

Se debe tener tener en cuenta cuando se informatiza un problema que existen tareas manuales que se deben tratar dentro del sistema. Es decir, el análisis del sistema comprende el tratamiento de todas la tareas manuales e informáticas que definen el sistema. Para ello, el ingeniero informático tendrá que estudiar a fondo todo sistema, especializarse en su terminología y realizar una interacción permanente con el cliente, el experto del sistema u los usuarios de forma que la percepción que tenga del sistema coincide con la del cliente, experto y usuario.

El análisis del sistema es una etapa de la fase de planificación y en ella se realiza una descripción del entorno, software que se quiere obtener y se define los recursos humanos para su desarrollo, el coste y el calendario estimado.

En concreto, el análisis del sistema presenta los siguientes objetivos:

• Identificar las necesidades del cliente.
• Realizar un análisis técnico y económico del sistema.
• Establecer restricciones de costo y tiempo.
• Evaluar la viabilidad del sistema.
• Asignar funciones al software, a la gente, a las bases de datos y otros elementos del sistema.
• Definir el sistema.

Etapa de diseño: Es el primer paso en la fase de desarrollo de cualquier producto o sistema de ingeniería. Define como el proceso de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, proceso o sistemas con los suficientes detalles como para permitir su realización física. El objetivo del diseñador es producir un modelo o representación de una entidad que será construida mas adelante. Esta etapa se suele dividir en dos:

         1. Diseño Preliminar 

             1.1 Diseño de datos.

             1.2 Diseño arquitectónico.

             1.3 Diseño de la interfaz hombre-máquina.

         2. Diseño Detallado

             2.1 Diseño Procedimental

Etapa de Programación: Se traduce el diseño a código. Es la parte más obvia del trabajo de ingeniería de software y la primera en que se obtienen resultados “tangibles”. No necesariamente es la etapa más larga ni la más compleja aunque una especificación o diseño incompletos/ambiguos pueden exigir que, tareas propias de las etapas anteriores se tengan que realizarse en esta.

Etapa de pruebas o verificación prueba: consiste en asegurar que los componentes individuales que integran al sistema o producto, cumplen con los requerimientos de la especificación creada durante la etapa del diseño.

Etapa de implementación o entrega implantación: Consiste en poner a disposición del cliente el producto.

Etapa de mantenimiento: El software producido en la fase de desarrollo debe ser mantenido, ya que sufrirá cambios después de que se entreguen al cliente. Los cambios ocurrirán debido a:

• Errores encontrados (mantenimiento correctivo).
• Cambios en el entorno externo al que el software debe adaptarse (mantenimiento adoptativo).
• Que el cliente requiere ampliaciones funcionales o desea incrementar su rendimiento (mantenimiento perfectivo).

Esta fase comporta diferentes actividades: por un lado comprobar que toda la documentación esta disponible y es adecuada para las tareas de mantenimiento. y por otro establecer un esquema de acciones para el caso de error o modificación del software y comunicar al usuario esas acciones.

Etapa final EOL (END –OF-LIFE): el fin del ciclo del producto consiste en realizar todas las tareas necesarias para asegurar que los clientes y los empleados están conscientes de que el producto ya no será vendido ni soportado.