UNIDAD I. TRANSICIÓN DEL ANÁLISIS HACIA EL DISEÑO.

UNIDAD I: TRANSICIÓN DEL ANÁLISIS HACIA EL DISEÑO

INGENIERÍA EN SOFTWARE

ING. RENÉ DOMÍNGUEZ ESCALONA

DISEÑO DE SISTEMAS

P R E S E N T A:

VALDIVIA LUNA JOELY JAQUELINE

SÉPTIMO CUATRIMESTRE

SEPTIEMBRE-DICIEMBRE 2016

I DISEÑO DE SISTEMAS SÉPTIMO CUATRIMESTRE

ÍNDICE

INTRODUCCIÓN.....................................................................................................3

1.1 DIAGRAMAS UML.............................................................................................4

1.1.2 DIAGRAMA DE CLASE..................................................................................5

1.1.3 DIAGRAMA DE OBJETOS..............................................................................6

1.1.4 DIAGRAMA DE CASOS DE USO...................................................................6

1.1.5 DIAGRAMA DE ESTADOS.............................................................................6

1.1.6 DIAGRAMA DE SECUENCIA.........................................................................6

1.1.7 DIAGRAMA DE ACTIVIDADES......................................................................7

1.1.8 DIAGRAMA DE COLABORACIONES.............................................................7

1.1.9 DIAGRAMA DE COMPONENTES..................................................................7

1.1.10 DIAGRAMA DE DISTRIBUCIÓN...................................................................8

1.1.11 DIAGRAMA DE ESTRUCTURA COMPUESTA............................................8

1.1.12 DIAGRAMA DE DESPLIEGUE.....................................................................9

1.1.13 DIAGRAMA DE PAQUETES.........................................................................9

1.1.14 DIAGRAMA DE COMUNICACIÓN................................................................9

2.1 METODOLOGÍAS ÁGILES................................................................................9

3.1 ANÁLISIS DEL SISTEMA.................................................................................11

3.1.1 OBTENCIÓN DE LOS REQUISITOS............................................................11

3.1.2 ANÁLISIS DE REQUISITOS.........................................................................12

3.1.3 LIMITACIONES.............................................................................................13

3.1.4 ESPECIFICACIÓN........................................................................................13

3.1.5 ARQUITECTURA..........................................................................................14

3.1.6 DESARROLLO DE LA APLICACIÓN............................................................16

3.1.7 PRUEBAS DE SOFTWARE......................................................................17

3.1.8 IMPLEMENTACIÓN..................................................................................18

3.1.9 DOCUMENTACIÓN..................................................................................18

3.1.10 MANTENIMIENTO.................................................................................19

2


INTRODUCCIÓN

Hoy en día, UML ("Unified Modeling Language") está consolidado como el

lenguaje estándar en el análisis y diseño de sistemas. Mediante UML es posible

establecer la serie de requerimientos y estructuras necesarias para plasmar un

sistema de software previo al proceso intensivo de escribir código.

En otros términos, así como en la construcción de un edificio se realizan planos

previo a su construcción, en Software se deben realizar diseños en UML previa

codificación de un sistema, ahora bien, aunque UML es un lenguaje, éste posee

más características visuales que programáticas, mismas que facilitan a integrantes

de un equipo multidisciplinario participar e intercomunicarse fácilmente, estos

integrantes siendo los analistas, diseñadores, especialistas de área y desde luego

los programadores.

3

1.1 DIAGRAMAS UML

Los modelos UML, nos sirve para escribir planos de software, puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema que involucren una cantidad muy alta de software.

Nos ayuda a modelar desde sistemas de información que correspondan a empresas, así como aplicaciones basadas en web.

Es la especificación de todas las decisiones de:

• Análisis

• Diseño

• Implementación

Que deben realizarse al momento de desarrollar un sistema de software con gran cantidad de software.

Cubre la documentación de la arquitectura de un sistema, proporciona un lenguaje para expresar requisitos y pruebas.

Utiliza características como:

• Interfaz

• Colaboración

• Artefacto

• Nodos

• Acciones

• Paquetes

• Asociaciones

• Generalizaciones

• Aplicaciones


1.1.2 DIAGRAMA DE CLASE

Los diagramas de clases describen la estructura estática de un sistema. Una clase

es una categoría o grupo de cosas que tienen atributos (propiedades) y acciones

similares. Un diagrama de clases está formado por varios rectángulos de este tipo

conectados por líneas que representan las asociaciones o maneras en que las

clases se relacionan entre sí.

Elementos

Clase

Es la unidad básica que encapsula toda la información de un Objeto (un objeto es

una instancia de una clase). A través de ella podemos modelar el entorno en

estudio (una Casa, un Auto, una Cuenta Corriente, etc.). En UML, una clase es

representada por un rectángulo que posee tres divisiones:

<Nombre Clase>

<Atributos>

<Operaciones y

métodos>

En donde:

Superior: Contiene el nombre de la Clase

Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la

Clase (pueden ser private, protected o public).

Inferior: Contiene los métodos u operaciones, los cuales son la forma como

interactúa el objeto con su entorno (dependiendo de la visibilidad: private,

protected o public).

5


1.1.3 DIAGRAMA DE OBJETOS

Los Diagramas de Objetos están vinculados con los Diagramas de Clases. Un objeto es una instancia de una clase, por lo que un diagrama de objetos puede ser visto como una instancia de un diagrama de clases. Los diagramas representan un único ejemplo de una clase y se utilizan para ilustrar un punto de datos en su aplicación. Cuando cree un objeto nuevo, llamado especificación de instancia, utilizan una notación similar a los diagramas de clases y se utilizan para ilustrar una instancia de una clase en un momento dado.

.1.4 DIAGRAMA DE CASOS DE USO

Un caso de uso es una descripción de las acciones de un sistema desde el punto

de vista del usuario. Es una herramienta valiosa dado que es una técnica de

aciertos y errores para obtener los requerimientos del sistema, justamente desde

el punto de vista del usuario.

Los diagramas de caso de uso modelan la funcionalidad del sistema usando

actores y casos de uso. Los casos de uso son servicios o funciones provistas por

el sistema para sus usuarios.

1.1.5 DIAGRAMA DE ESTADOS

Representa una máquina de estados, constituida por estados, transiciones, eventos y actividades. Se utilizan para describir la vista dinámica de un sistema. Son importantes para modelar el comportamiento de una interfaz, de una clase o de una colaboración.

1.1.6 DIAGRAMA DE SECUENCIA

Los diagramas de clases y los de objetos representan información estática. No

obstante, en un sistema funcional, los objetos interactúan entre sí, y tales

interacciones suceden con el tiempo. El diagrama de secuencias UML muestra la

mecánica de la interacción con base en tiempos.

6


1.1.7 DIAGRAMA DE ACTIVIDADES

Un diagrama de actividades ilustra la naturaleza dinámica de un sistema mediante el modelado del flujo ocurrente de actividad en actividad. Una actividad representa una operación en alguna clase del sistema y que resulta en un cambio en el sistema.

1.1.9 DIAGRAMA DE COMPONENTESEl diagrama de componentes es un esquema que muestra las interacciones y

relaciones de los componentes de un modelo. Entendiéndose como componente a

una clase de uso específico, puede ser implementada desde un entorno de

desarrollo, ya sea de código binario, fuente o ejecutable; dichos componentes

poseen tipo, que indican si pueden ser útiles en tiempo de compilación, enlace y

ejecución. El uso de diagramas de componentes tiene algunas ventajas:

Concebir el diseño atendiendo a los bloques principales ayuda al equipo de desarrollo a entender un diseño existente y a crear uno nuevo.

Al pensar en el sistema como una colección de componentes con interfaces proporcionadas y necesarias bien definidas, se mejora la separación entre los componentes. Esto, a su vez, facilita la comprensión y los cambios cuando se modifican los requisitos.

estado del sistema. Típicamente, los diagramas de actividad son utilizados para

modelar el flujo de trabajo interno de una operación.

1.1.8 DIAGRAMA DE COLABORACIONES

El diagrama de colaboraciones describe las interacciones entre los objetos en términos de mensajes secuenciados. Los diagramas de colaboración representan una combinación de información tomada de los diagramas de clases, de secuencias y de casos de uso, describiendo el comportamiento, tanto de la estructura estática, como de la estructura dinámica de un sistema.

1.1.10 DIAGRAMA DE DISTRIBUCIÓN

7


El diagrama de distribución es una herramienta de análisis que dibuja pares

relacionados de variables para presentar un patrón de relación o de correlación.

Cada conjunto de datos representa un factor diferente que puede ser cuantificado.

Un conjunto de datos es dibujado en un eje horizontal (eje x) y el otro conjunto de

datos se dibuja en el eje vertical (eje y). El resultado es un número de puntos que

pueden ser analizados para determinar si existe una relación significativa (también

conocida como “correlación”) entre los dos conjuntos de datos.

Se debe utilizar un Diagrama de Distribución cuando se quiera:

Verificar si el desempeño de un factor está relacionado con otro factor. Demostrar que un cambio en una condición afectará la otra.

1.1.11 DIAGRAMA DE ESTRUCTURA COMPUESTA

Un diagrama de estructura compuesta es un tipo de diagrama de estructura

estática que muestra la estructura interna de una clase y las colaboraciones que

esta estructura hace posible. Una estructura compuesta es un conjunto de

elementos interconectados que colaboran en tiempo de ejecución para lograr

algún propósito.

El diagrama de estructura compuesta permite contextualizar las partes que

componen un clasificador, modelar información de objetos compuestos por más

objetos por medio de relaciones de composición, entre los objetos contenedores y

sus partes. Sobre todo muestra la estructura interna de una clase o una

colaboración.

1.1.12 DIAGRAMA DE DESPLIEGUE

Modela la arquitectura en tiempo de ejecución de un sistema. Esto muestra la

configuración de los elementos de hardware (nodos) y muestra cómo los

elementos y artefactos del software se trazan en esos nodos. Se utiliza para

8


modelar la disposición física de los artefactos software en nodos (usualmente

plataforma de hardware).

1.1.13 DIAGRAMA DE PAQUETES

Un diagrama de paquetes muestra cómo un sistema está dividido en agrupaciones

lógicas mostrando las dependencias entre esas agrupaciones. Los Paquetes están

normalmente organizados para maximizar la coherencia interna dentro de cada

paquete y minimizar el acoplamiento externo entre los paquetes. Cada paquete

puede asignarse a un individuo o a un equipo, y las dependencias entre ellos

pueden indicar el orden de desarrollo requerido.

1.1.14 DIAGRAMA DE COMUNICACIÓN

Un diagrama de comunicación es una versión simplificada del diagrama de

colaboración de la versión de UML 1.x. Un diagrama de comunicación modela las

interacciones entre objetos o partes en términos de mensajes en secuencia. Los

diagramas de comunicación representan una combinación de información tomada

desde el diagrama de clases, secuencia, y diagrama de casos de uso describiendo

tanto la estructura estática como el comportamiento dinámico de un sistema.

2.1 METODOLOGÍAS ÁGILES

Las metodologías ágiles son una serie de técnicas para la gestión de proyectos

que han surgido como contraposición a los métodos clásicos de gestión como

CMMI.

Todas las metodologías que se consideran ágiles cumplen con el manifiesto ágil

que no es más que una serie de principios que se agrupan en 4 valores:

Los individuos y su interacción, por encima de los procesos y las

herramientas.

El software que funciona, frente a la documentación exhaustiva.

9


La colaboración con el cliente, por encima de la negociación contractual.

La respuesta al cambio, por encima del seguimiento de un plan.

Las principales metodologías ágiles

Uno de los principales focos de aplicación de las metodologías ágiles son los

proyectos tecnológicos. Cada una de ellas tiene sus fortalezas y sus debilidades,

pero no son excluyentes.

Entre las metodologías ágiles más usadas se encuentran:

SCRUM.- Define un marco para la gestión de proyectos, que se ha utilizado

con éxito durante los últimos 10 años. Está especialmente indicada para

proyectos con un rápido cambio de requisitos. Sus principales

características se pueden resumir en dos. El desarrollo de software se

realiza mediante iteraciones, denominadas sprints, con una duración de 30

días. El resultado de cada sprint es un incremento ejecutable que se

muestra al cliente. La segunda característica importante son las reuniones a

lo largo proyecto. Éstas son las verdaderas protagonistas, especialmente la

reunión diaria de 15 minutos del equipo de desarrollo para coordinación e

integración.

Crystal Methodologies.- Se trata de un conjunto de metodologías para el

desarrollo de software caracterizadas por estar centradas en las personas

que componen el equipo (de ellas depende el éxito del proyecto) y la

reducción al máximo del número de artefactos producidos.

Dynamic Systems Development Method (DSDM).- Define el marco para

desarrollar un proceso de producción de software. Nace en 1994 con el

objetivo el objetivo de crear una metodología RAD unificada. Sus

principales características son: es un proceso iterativo e incremental y el

equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases:

estudio viabilidad, estudio del negocio, modelado funcional, diseño y

construcción, y finalmente implementación. Las tres últimas son iterativas,

además de existir realimentación a todas las fases.

10


Adaptive Software Development (ASD).- Sus principales características

son: iterativo, orientado a los componentes software más que a las tareas y

tolerante a los cambios. El ciclo de vida que propone tiene tres fases

esenciales: especulación, colaboración y aprendizaje. En la primera de ellas

se inicia el proyecto y se planifican las características del software; en la

segunda desarrollan las características y finalmente en la tercera se revisa

su calidad, y se entrega al cliente.

Feature-Driven Development.- Define un proceso iterativo que consta de 5

pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las

fases de diseño e implementación del sistema partiendo de una lista de

características que debe reunir el software.

3.1 ANÁLISIS DEL SISTEMA

El Análisis de Sistemas trata básicamente de determinar los objetivos y límites del

sistema objeto de análisis, caracterizar su estructura y funcionamiento, marcar las

directrices que permitan alcanzar los objetivos propuestos y evaluar sus

consecuencias.

3.1.1 OBTENCIÓN DE LOS REQUISITOS

Se debe identificar sobre qué se está trabajando, es decir, el tema principal que

motiva el inicio del estudio y creación del nuevo software o modificación de uno ya

existente. A su vez identificar los recursos que se tienen, en esto entra el conocer

los recursos humanos y materiales que participan en el desarrollo de las

actividades. Es importante entender el contexto del negocio para identificar

adecuadamente los requisitos.

Se tiene que tener dominio de la información de un problema, lo cual incluye los

datos fuera del software (usuarios finales, otros sistemas o dispositivos externos),

los datos que salen del sistema (por la interfaz de usuario, interfaces de red,

11


reportes, gráficas y otros medios) y los almacenamientos de datos que recaban y

organizan objetos persistentes de datos (por ejemplo, aquellos que se conservan

de manera permanente).

3.1.2 ANÁLISIS DE REQUISITOS

Extraer los requisitos de un producto software es la primera etapa para crearlo.

Durante la fase de análisis, el cliente plantea las necesidades que se presenta e

intenta explicar lo que debería hacer el software o producto final para satisfacer

dicha necesidad mientras que el desarrollador actúa como interrogador, como la

persona que resuelve problemas. Con este análisis, el ingeniero de sistemas

puede elegir la función que debe realizar el software y establecer o indicar cuál es

la interfaz más adecuada para el mismo.

El análisis de requisitos puede parecer una tarea sencilla, pero no lo es debido a

que muchas veces los clientes piensan que saben todo lo que el software necesita

para su buen funcionamiento, sin embargo se requiere la habilidad y experiencia

de algún especialista para reconocer requisitos incompletos, ambiguos o

contradictorios. Estos requisitos se determinan tomando en cuenta las

necesidades del usuario final, introduciendo técnicas que nos permitan mejorar la

calidad de los sistemas sobre los que se trabaja.

El resultado del análisis de requisitos con el cliente se plasma en el documento

ERS (especificación de requisitos del sistema), cuya estructura puede venir

definida por varios estándares, tales como CMMI. Asimismo, se define un

diagrama de entidad/relación, en el que se plasman las principales entidades que

participarán en el desarrollo del software.

Finalidades del análisis de requisitos:

Brindar al usuario todo lo necesario para que pueda trabajar en conjunto

con el software desarrollado obteniendo los mejores resultados posibles.

12


Tener un control más completo en la etapa creación del software, en cuanto

a tiempo de desarrollo y costos.

Utilización de métodos más eficientes que permitan el mejor

aprovechamiento del software según sea la finalidad de uso del mismo.

Aumentar la calidad del software desarrollado al disminuir los riesgos de

mal funcionamiento.18

3.1.3 LIMITACIONES

El software tiene la capacidad de emular inteligencia creando un modelo de ciertas

características de la inteligencia humana pero sólo posee funciones predefinidas

que abarcan un conjunto de soluciones que en algunos campos llega a ser

limitado. Aun cuando tiene la capacidad de imitar ciertos comportamientos

humanos no es capaz de emular el pensamiento humano porque actúa bajo

condiciones.

Otro aspecto limitante del software proviene del proceso totalmente mecánico que

requiere de un mayor esfuerzo y tiempos elevados de ejecución lo que lleva a

tener que implementar el software en una máquina de mayor capacidad.

3.1.4 ESPECIFICACIÓN

La especificación de requisitos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del éxito de un proyecto de software radicará en la identificación de las necesidades del negocio (definidas por la alta dirección), así como la interacción con los usuarios funcionales para la recolección, clasificación, identificación, priorización y especificación de los requisitos del software.Entre las técnicas utilizadas para la especificación de requisitos se encuentran:

Caso de uso

Historias de usuario

13


Siendo los primeros más rigurosos y formales, los segundas más ágiles e

informales.

3.1.5 ARQUITECTURA

La integración de infraestructura, desarrollo de aplicaciones, bases de datos y

herramientas gerenciales, requieren de capacidad y liderazgo para poder ser

conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El

rol en el cual se delegan todas estas actividades es el del Arquitecto.

La arquitectura de software consiste en el diseño de componentes de una

aplicación (entidades del negocio), generalmente utilizando patrones de

arquitectura. El diseño arquitectónico debe permitir visualizar la interacción entre

las entidades del negocio y además poder ser validado, por ejemplo por medio de

diagramas de secuencia. Un diseño arquitectónico describe en general el cómo se

construirá una aplicación de software. Para ello se documenta utilizando

diagramas, por ejemplo:

Diagramas de clases

Diagramas de base de datos

Diagrama de despliegue

Diagrama de secuencia

Siendo los dos primeros los mínimos necesarios para describir la arquitectura de

un proyecto que iniciará a ser codificado. Dependiendo del alcance del proyecto,

complejidad y necesidades, el arquitecto elegirá cuales de los diagramas se

requiere elaborar.

Las herramientas para el diseño y modelado de software se denominan CASE

(Computer Aided Software Engineering).

¿Qué son las herramientas CASE?

14


hace referencia a la aplicación de un conjunto de herramientas y métodos para

incrementar la productividad del desarrollo software y reducir costes de tiempo y

dinero, obteniendo un software de alta calidad, sin defectos y mantenible.

Estas herramientas ayudan en todos los estados del ciclo de vida de desarrollo

software, tareas como el proceso de diseño del proyecto, cálculo de costos,

implementación de parte del código, compilación automática, documentación o

detección de errores.

Clasificación

Las herramientas no poseen una única clasificación y es difícil determinarle en una

clase y suelen ser clasificadas de acuerdo a los siguientes factores:

• Las plataformas que soportan.

• Las fases del ciclo de vida del desarrollo de sistemas que cubren.

• La arquitectura de aplicaciones que producen.

• Su funcionalidad.

Una primera clasificación del CASE es considerando su amplitud:

• TOOLKIT: Es una colección de herramientas integradas que permiten

automatizar un conjunto de tareas de algunas de las fases del ciclo de vida del

sistema informático: Planificación estratégica, Análisis, Diseño, Generación de

programas.

• WORKBENCH: Son conjuntos integrados de herramientas que dan soporte

a la automatización del proceso completo de desarrollo del sistema informático.

Permiten cubrir el ciclo de vida completo. El producto final aportado por ellas es un

sistema en código ejecutable y su documentación.

La siguiente clasificación es la más habitual basada en las fases del ciclo de

desarrollo que cubren:

15


• Upper CASE (U-CASE): herramientas que ayudan en las fases de

planificación, análisis de requisitos y estrategia del desarrollo, usando, entre otros

dieagramas UML.

• Middle CASE (M-CASE): herramientas para automatizar tareas en el

análisis y diseño de la aplicación.

• Lower CASE (L-CASE): herramientas que semi-automatizan la generación

de código, crean programas de detección de errores, soportan depuración de

programas y pruebas. Además automatizan la documentación completa de la

aplicación. En esta parte podemos incluir las herramientas de Desarrollo rápido de

aplicaciones.

Programación

Implementar un diseño en código puede ser la parte más obvia del trabajo de

ingeniería de software, pero no necesariamente es la que demanda mayor trabajo

y ni la más complicada. La complejidad y la duración de esta etapa está

íntimamente relacionada al o a los lenguajes de programación utilizados, así como

al diseño previamente realizado.

3.1.6 DESARROLLO DE LA APLICACIÓN

Para el desarrollo de la aplicación es necesario considerar cinco fases para tener

una aplicación o programa eficiente, estas son:

Desarrollo de la infraestructura: Esta fase permite el desarrollo y la

organización de los elementos que formaran la infraestructura de la

aplicación, con el propósito de finalizar la aplicación eficientemente.

Adaptación del paquete: El objetivo principal de esta fase es entender de

una manera detallada el funcionamiento del paquete, esto tiene como

finalidad garantizar que el paquete pueda ser utilizado en su máximo

rendimiento, tanto para negocios o recursos. Todos los elementos que

16


componen el paquete son inspeccionados de manera detallada para evitar

errores y entender mejor todas las características del paquete.

Desarrollo de unidades de diseño de interactivas: En esta fase se realizan

los procedimientos que se ejecutan por un diálogo usuario-sistema. Los

procedimientos de esta fase tienen como objetivo principal:

I. Establecer específicamente las acciones que debe efectuar la unidad de

diseño.

II. La creación de componentes para sus procedimientos.

III. Ejecutar pruebas unitarias y de integración en la unidad de diseño.

Desarrollo de unidades de diseño batch: En esta fase se utilizan una serie

de combinación de técnicas, como diagrama de flujo, diagramas de

estructuras, tablas de decisiones, etc. Cualquiera a utilizar será beneficioso

para plasmar de manera clara y objetiva las especificaciones y que así el

programador tenga mayor comprensión a la hora de programar y probar los

programas que le corresponden.

Desarrollo de unidades de diseño manuales: En esta fase el objetivo central

es proyectar todos los procedimientos administrativos que desarrollarán en

torno a la utilización de los componentes computarizados.

III.1.7 PRUEBAS DE SOFTWARE

Consiste en comprobar que el software realice correctamente las tareas indicadas

en la especificación del problema. Una técnica es probar por separado cada

módulo del software, y luego probarlo de manera integral, para así llegar al

objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por

alguien distinto al desarrollador que la programó, idealmente un área de pruebas;

sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En

general hay dos grandes maneras de organizar un área de pruebas, la primera es

que esté compuesta por personal inexperto y que desconozca el tema de pruebas,

de esta manera se evalúa que la documentación entregada sea de calidad, que

17


los procesos descritos son tan claros que cualquiera puede entenderlos y el

software hace las cosas tal y como están descritas. El segundo enfoque es tener

un área de pruebas conformada por programadores con experiencia, personas

que saben sin mayores indicaciones en qué condiciones puede fallar una

aplicación y que pueden poner atención en detalles que personal inexperto no

consideraría.

III.1.8 IMPLEMENTACIÓN

Una Implementación es la realización de una especificación técnica o algoritmos

con un programa, componente software, u otro sistema de cómputo. Muchas

especificaciones son dadas según a su especificación o un estándar. Las

especificaciones recomendadas según el ´World Wide Web Consortium, y las

herramientas de desarrollo del software contienen implementaciones de lenguajes

de programación. El modelo de implementación es una colección de componentes

y los subsistemas que contienen. Componentes tales como: ficheros ejecutables,

ficheros de código fuente y todo otro tipo de ficheros que sean necesarios para la

implementación y despliegue del sistema.

III.1.9 DOCUMENTACIÓN

Es todo lo concerniente a la documentación del propio desarrollo del software y de

la gestión del proyecto, pasando por modelaciones (UML), diagramas de casos de

uso, pruebas, manuales de usuario, manuales técnicos, etc.; todo con el propósito

de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al

sistema.

18


III.1.10 MANTENIMIENTO

Fase dedicada a mantener y mejorar el software para corregir errores descubiertos

e incorporar nuevos requisitos. Esto puede llevar más tiempo incluso que el

desarrollo del software inicial. Alrededor de 2/3 del tiempo de ciclo de vida de un

proyecto21 está dedicado a su mantenimiento. Una pequeña parte de este trabajo

consiste eliminar errores (bugs); siendo que la mayor parte reside en extender el

sistema para incorporarle nuevas funcionalidades y hacer frente a su evolución.

19

UNIDAD I. TRANSICIÓN DEL ANÁLISIS HACIA EL DISEÑO.

Data & Analytics

Transcript of UNIDAD I. TRANSICIÓN DEL ANÁLISIS HACIA EL DISEÑO.