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
2
Í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

3
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.

1.1 DIAGRAMAS UML
Los modelosUML, nossirve para escribir planosde software,puede utilizarse paravisualizar,
especificar,construirydocumentarlosartefactosde unsistemaque involucrenunacantidadmuy
alta de software.
Nosayuda a modelardesde sistemasde informaciónque correspondanaempresas,asícomo
aplicacionesbasadasenweb.
Es la especificaciónde todaslasdecisionesde:
• Análisis
• Diseño
• Implementación
Que debenrealizarse al momentode desarrollarunsistemade software congrancantidadde
software.
Cubre la documentaciónde laarquitecturade unsistema,proporcionaunlenguaje paraexpresar
requisitosypruebas.
Utilizacaracterísticascomo:
• Interfaz
• Colaboración
• Artefacto
• Nodos
• Acciones
• Paquetes
• Asociaciones
• Generalizaciones
• Aplicaciones

5
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).

6
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

7
interacciones suceden con el tiempo. El diagrama de secuencias UML muestra la
mecánica de la interacción con base en tiempos.
1.1.7 DIAGRAMA DE ACTIVIDADES
Un diagrama de actividadesilustralanaturalezadinámicade unsistemamediante el modeladodel
flujoocurrente de actividadenactividad.Una actividadrepresentaunaoperaciónenalgunaclase
del sistemay que resultaenuncambioen el sistema.
1.1.9 DIAGRAMA DE COMPONENTES
El 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óntomadade losdiagramasde 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.

8
1.1.10 DIAGRAMA DE DISTRIBUCIÓN
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.

9
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
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.

10
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.
 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

11
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.
 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

12
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,
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.

13
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.
 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:

14
 Caso de uso
 Historias de usuario
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).

15
¿Qué son las herramientas CASE?
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.

16
La siguiente clasificación es la más habitual basada en las fases del ciclo de
desarrollo que cubren:
• 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

17
finalidad garantizar que el paquete pueda ser utilizado en su máximo
rendimiento, tanto para negocios o recursos. Todos los elementos que
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.
3.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

18
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
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.
3.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.
3.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.

19
3.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.

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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

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

Similar a UNIDAD I. TRANSICIÓN DEL ANÁLISIS HACIA EL DISEÑO. (20)

Último

Último (17)

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