ANÁLISIS DE REQUERIMIENTOS DE LA ACTUALIZACIÓN TECNOLÓGICA DEL MÓDULO DE SERVICIOS “LÍDER”

" "






ANÁLISIS DE REQUERIMIENTOS DE LA ACTUALIZACIÓN TECNOLÓGICA DEL MÓDULO
DE SERVICIOS "LÍDER"
INFORME FINAL DE RESIDENCIA PROFESIONAL








CARRERA
INGENIERÍA EN SISTEMAS COMPUTACIONALES








RESIDENTE
JESÚS CHI VÁSQUEZ






MATRÍCULA
04080148






ASESOR(A) EXTERNO
****








ASESOR(A) INTERNO
M.C. JORGE IVÁN FUENTES ROSADO








PROGRESO, YUCATÁN A JUNIO 2012







Capítulo I 8
introducción 8
Introducción 9
Características del área 10
Justificación 11
Objetivo General 12

Objetivos Específicos 12
Alcances y Limitaciones de la Investigación 13
Alcances 13

Limitaciones 13

¿Cuál es la problemática de la empresa? 14
Capítulo II 15
MARCO TEORICO 15
Ingeniería del Software 16
Ciclos de Vida 17
Tipos de modelo de ciclo de vida 18

Modelos de ciclo de vida 18

Modelo de cascada 19
Modelo en V 21
Modelo iterativo 23
Modelo de desarrollo incremental 23
Modelo en espiral 24
Modelo de prototipos 27
Etapas el desarrollo de software 28
Etapa uno: Requerimientos del software. 28

Lenguajes para la definición de requerimientos de software. 30
Especificación en lenguaje estructurado 30
Casos de uso 30
Validación de requerimientos de software 33
Etapa dos: Diseño de la arquitectura 34

Conceptos fundamentales del diseño 36
Abstracción 36
Arquitectura 36
Patrones 37
División de problemas 37
Modularidad 37
Encapsulación de información 38
Rediseño 38
Estilos de arquitectura 39
Arquitecturas orientadas a objetos 39
Arquitectura en capas 39
Estilo arquitectónico y reingeniería 40
UML 40
Principios del modelado 41
UML es un lenguaje 42
Etapa tres: Codificación del software 44

Desarrollo rápido de software 45
La programación extrema 46
Reutilización del software 47
Ingeniería del software basado en componentes. 47
Desarrollo de sistemas críticos 47
Etapa cuatro pruebas del software 48

Pruebas del sistema 49
Pruebas de integración 49
Pruebas de entrega 50
Pruebas de rendimiento 50
Pruebas de componentes 50
Pruebas de interfaces 51
Diseño de casos de prueba 51
Pruebas basadas en requerimientos 52
Pruebas de particiones 52
Pruebas estructurales 52
Prueba de caminos 52
Etapa cinco Mantenimiento del software 53

Soportabilidad del software 53
Importancia de la reingeniería 53
Actividades de reingeniería de software 54
Restructuración de documentos 54
Importancia del Diseño y Análisis 55
Importancia de análisis 55

Importancia del diseño de arquitectura 55

Reingeniería 57
Análisis de inventarios 58

Restructuración de documentos 58

Ingeniería Inversa. 59

Reestructuración 62

Reestructuración de código 62
Reestructuración de datos 63
Ingeniería hacia adelante 63

Sistemas de Planificación de Recursos Empresariales 63
El ciclo de vida de ERP 65

Definición y características de los módulos de un ERP 67

Contabilidad general 67
Bancos y cartera 68
Bancos 68
Cartera de cobros y pagos 68
Compras 68
Gestión de contactos 68
Gestión de servicios posventa 69
Gestión de proyectos 69
Gestión de fabricación 69
Gestión de personal 69
Gestión de E.commerce 69
Procedimiento y Descripción de las actividades realizadas 71
Resultados 83
Conclusiones 85
Comentarios del Residente 86
Adquisición de habilidades y actitudes genéricas 86
Comunicación oral 86

Comunicación escrita en su propia lengua 86

Capacidad de comunicarse con profesionales de otras áreas 86

Habilidades en el uso de TIC´S 86

Capacidad de análisis y síntesis 86

Capacidad de organizar y planificar 86

Habilidades para buscar y analizar información proveniente de fuentes
diversas 87

Solución de problemas 87

Toma de decisiones 87

Trabajo en equipo 87

Habilidades interpersonales 87

Habilidades para trabajar en un ambiente laboral 88

Capacidad de aplicar los conocimientos en la práctica 88

Asignaturas y contenidos de la carrera aplicados a lo largo de la
realización de la Residencia Profesional 88
Asignaturas y contenidos de la carrera que deberían reforzarse 88
Contenidos que deberían actualizarse en los programas de estudio 89
Referencias 89
Apéndice 89



Imagen 1. Ubicación de la empresa. 9
Imagen 2.Modelo de ciclo de vida en cascada 20
Imagen 3. Modelo de ciclo de vida en V 21
Imagen 4. Modelo de ciclo de vida iterativo 22
Imagen 5. Modelo de ciclo de vida incremental 23
Imagen 6. Ciclo de vida espiral 26
Imagen 7. Modelo de ciclo de vida de prototipos 27
Imagen 8. Vocabulario UML 42
Imagen 9. Un modelo del proceso de prueba del software. 47
Imagen 10. Actividades de Reingeniería de software 56
Imagen 11. Conceptos de ingeniería inversa. 59
Imagen 12 Ventana de caso de uso complejo. 74
Imagen 13 Ventana de CU de los TOT 77
Imagen 14 Orden de servicio. 79

Ilustración 1Encabezado del Formato de Caso de Uso de la Empresa Bepensa
70
Ilustración 2 Descripción del CU. 71
Ilustración 3 Cuerpo del Caso de Uso 73
Ilustración 4 Ejemplo de caso de uso simple. 74
Ilustración 5 Caso de uso complejo. 76
Ilustración 6 Ejemplo del Caso de uso de TOT 78
Ilustración 7 Caso de uso de la Orden de servicio. 80

Capítulo I

INTRODUCCIÓN


INTRODUCCIÓN

Bepensa Motriz cuenta con un sistema de planificación de recursos
empresariales o ERP por sus siglas en inglés, Enterprise Resource Planning
(Wallace & Kremzar, 2001) llamado LIDER, el cual es clave central en el
funcionamiento de la división. El software LIDER fue desarrollado en Visual
Basic 6.0 © y siguiendo el paradigma de la programación orientada a
eventos, además de estar funcionando de acuerdo a una arquitectura
cliente/servidor.
El presente proyecto de residencia consiste en la elaboración de la
documentación faltante de este software, para una futura actualización del
mismo en una plataforma web, puesto que además de tener un sistema
desarrollado bajo las nuevas tecnologías de información y mantenerse como
una empresa que se encuentre a la vanguardia en este ámbito, un sistema web
ofrece diversas ventajas para la empresa como pudieran ser:
Más ligero: No requiere instalar software especial (en los
clientes).
Bajos costos de actualización.
Información centralizada.
Seguridad y copias de seguridad.
La actualización tecnológica de LÍDER es el proyecto más importante del
año para el departamento de Tecnologías de Información y para la empresa en
general, debido a que es el sistema principal de administración de los
servicios que ofrece Bepensa. Actualmente, Líder es un sistema de
escritorio que se encuentra desarrollado en Visual Basic 6.0 bajo un
paradigma de programación orientada a eventos, lo que lo hace un sistema
que no se encuentra de acuerdo a las nuevas tendencias de desarrollo y
tecnologías de información. Sobre el sistema actual se aplicarán conceptos
de ingeniería inversa y reingeniería para obtener los requerimientos
necesarios para su actualización. El nuevo sistema se desarrollará para Web
bajo los lenguajes de programación C# y asp.net, además estará basado en el
paradigma de programación orientada a objetos.


Características del área

Bepensa es un grupo mexicano conformado por dos divisiones principales
Bepensa Industria (Bepensa S.A. de C.V.) y Bepensa Motriz (Bepensa Motriz
S.A. de C.V.) cuyo desempeño ha fortalecido sus estrategias financieras y
de mercado permitiendo consolidarse como la empresa más importante del
sureste y norte de México. Bepensa Industria es la organización más
importante del Sureste Mexicano, y cuenta con un vasto portafolio de
productos provenientes de sus tres divisiones; Industrial, Bebidas y
Servicios. Su gama comprende desde los refrescos Coca-Cola y Cristal, hasta
la producción de botellas PET y la oferta de créditos al consumo. Por otra
parte Bepensa Motriz es la división dedicada principalmente a la
distribución de camiones, maquinaria y automóviles a través de diferentes
territorios de México. La Imagen 1 muestra la ubicación de la empresa
















Imagen 1. Ubicación de la empresa.








Justificación

//Por qué es importante hacer la actualización de Líder
La actualización del software fue por dos razones no existe una
documentación del software, además esta en un lenguaje descontinuado que
utiliza una tecnología en base a eventos y no tendría soporte de el orienta
a objetos.

//Por qué es importante hacer la Ing. Inversa y Análisis.
La aplicación de los procesos de ingeniería inversa e ingeniería de
software supondrán herramientas eficientes para la recopilación de
información, datos del sistema actual, que servirán de base para la
actualización de éste y su implementación como plataforma web.
Objetivo General

Documentar las etapas de Análisis de la actualización tecnológica del
módulo de servicios "Líder", para su implementación como plataforma web.
Objetivos Específicos

Aprobar el curso de UML y Patrones de Diseño
Diseñar los casos de uso para cada proceso y catálogo.
Aplicar el FURPS+ durante el diseño de casos de uso.
- Funcionalidad
- Usabilidad
- Fiabilidad
- Rendimiento
- Soporte
+ Implementación, interfaz, legalidad y empaquetamiento
Alcances y Limitaciones de la Investigación

Alcances

//Detallar hasta donde se llegará.
Se crearán los diagramas de casos de uso para el modulo de servicio.
Se Implementará de la aplicación del FURPS+ en los casos de uso.
Existirá documentación de todo el proceso de análisis de los
requerimientos del sistema, lo cual facilitará etapas posteriores del
desarrollo del proyecto.
Limitaciones

El poco conocimiento del funcionamiento del sistema "Líder".
Por las políticas de la empresa no podemos ver el código.
Que no existe una documentación sobre el sistema actual.
Poca (o falta de) experiencia en documentación de requerimientos del
software.
Poca (o falta de) experiencia en procesos de ingeniería de
software.
Poca (o falta de) experiencia en procesos de ingeniería inversa
Poca (o falta de) experiencia en creación de diagramas UML.
¿Cuál es la problemática de la empresa?

La empresa Bepensa motriz cuenta con un sistema ERP obsoleto, este
sistema tiene muchas problemáticas y siempre está en constate
actualización, este sistema no cuenta con ningún tipo de documentación, lo
cual le dificulta al programador estar agregando funcionalidades, ya que
sin contar ningún tipo de documentación, y estar agregando las
funcionalidades a este mismo sistema, lo hace un sistema muy complejo para
los usuarios, es por eso que se requiere actualizar el sistema para contar
con una documentación adecuada e implementar nuevas técnicas de
programación como lo son las orientada a objetos además de mudarlo a web,
dado que este sistema se encuentra en escritorio, y con esto manejar el
sistema sin necesidad de instalarlo en las computadoras, además de
necesitar unas maquinas con arquitectura básica.










Capítulo II

MARCO TEORICO


















Ingeniería del Software

La ingeniería del software es una ciencia de la ingeniería que conoce
todos los aspectos, métodos y las técnicas que se utilizan en el desarrollo
de la producción de software desde las etapas principales de la
especificación del sistema, hasta el mantenimiento de éste después de la
implementación. (Somerville, 2005) (Falgueres, 2003)En esta definición,
existente dos frases claves:
a) Ciencia de la ingeniería. Los ingenieros idean soluciones para que
las cosas funcionen. Estos, los ingenieros, hacen uso de las
teorías, métodos y herramientas de manera conveniente, siempre
tratando de descubrir soluciones a los problemas nuevos. Los
ingenieros también saben que deben trabajar con estricciones
financieras y organizacionales, por lo que buscan soluciones tomando
en cuenta estas restricciones (Somerville, 2005).
b) Todos los aspectos de producción de software. La ingeniería del
software no solo comprende los procesos técnicos del desarrollo de
software, sino también con actividades tales como la gestión de
proyectos de software y el desarrollo de herramientas, métodos y
teorías de apoyo a la producción de software (Somerville, 2005).
La ingeniería del software puede estudiarse desde dos enfoques
principales de técnicas:
Las estructuradas
Las orientadas a objetos (Falgueres, 2003).
Por qué es importante la documentación
Los proyectos de cualquier ingeniería por la complejidad que acarrean
requieren de un esfuerzo especial para plasmar la idea principal y cómo
desarrollarla de principio a fin, en el caso de los proyectos de software
esto no es diferente (Somerville, 2005).
La documentación consiste de la especificación de los requerimientos del
proyecto, los diagramas en la fase de diseño, los análisis realizados
durante fase homónima, la definición de los métodos en la codificación, las
pruebas realizadas y resultados obtenidos en las mismas, y el mantenimiento
tras su liberación.
La importancia de la documentación radica en el uso de la misma en las
fases subsecuentes, es decir, para poder realizar un diseño y análisis del
proyecto de software, primeramente se tuvo que especificar los
requerimientos del mismo, y para poder codificar, se requiere del diseño
previo, mientras que para realizar el mantenimiento, se requiere de conocer
el sistema mediante la documentación (Falgueres, 2003). Hay que hacer
notar, que los equipos de desarrollo además de sufrir cambios constantes en
el personal que lo integra, existen roles predefinidos con funciones
específicas, por lo que la documentación realizada por ellos será utilizada
por otros. El equipo de desarrollo, pudiera ser diferente al equipo de
mantenimiento.
Ciclos de Vida

El ciclo de vida es el conjunto de fases por las que se pasa el sistema
que se está desarrollado desde que nace la idea inicial hasta que el
software es retirado o remplazado. También se denomina a veces paradigma
(Singh, 2005).
Entre las funciones que debe tener un ciclo de vida se pueden destacar:
1. Determinar el orden de las fases del proceso de software.
2. Establecer los criterios de transición para pasar de una fase a la
siguiente.
3. Definir las entradas y las salidas de cada fase.
4. Describir los estados por los que pasa el producto.
5. Describir las actividades a realizar para transformar los productos.
6. Definir un esquema que sirve como base para planificar, organizar,
coordinar, desarrollar.
Un ciclo de vida para un proyecto se compone de fases sucesivas
compuestas por tareas que se pueden planificar. Según el modelo de ciclo de
vida, la sucesión de fases puede ampliarse con bucles de realimentación, de
manera que lo que conceptualmente se considera una misma fase se pueda
ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada
pasada de ejecución aportaciones a los resultados intermedios que se van
produciendo (realimentación) (Singh, 2005).
1) Fases: una fase es un conjunto de actividades relacionadas con un
objetivo en el desarrollo del proyecto. Se construye agrupando
tareas (actividades elementales) que pueden compartir un tramo
determinado del tiempo de vida de un proyecto. La agrupación
temporal de tareas impone requisitos temporales correspondientes a
la asignación de recursos (humanos, financieros o materiales).
2) Entregables: son los productos intermedios que generan las fases.
Pueden ser materiales o inmateriales (documentos, software). Los
entregables permiten evaluar la marcha del proyecto mediante
comprobaciones de su adecuación o no a los requisitos funcionales y
de condiciones de realización previamente establecidos.
Tipos de modelo de ciclo de vida

Las principales diferencias entre distintos modelos de ciclo de vida
están en:
1) El alcance del ciclo dependiendo de hasta donde llegue el proyecto
correspondiente. Un proyecto puede comprender un simple estudio de
viabilidad del desarrollo de un producto, o su desarrollo completo o
en el extremo, toda la historia del producto con su desarrollo,
fabricación y modificaciones posteriores hasta su retirada del
mercado.
2) Las características (contenidos) de las fases en que dividen el
ciclo. Esto puede depender del propio tema al que se refiere el
proyecto, o de la organización.
3) La estructura y la sucesión de las etapas, si hay realimentación
entre ellas, y si tenemos libertad de repetirlas (iterar) (Singh,
2005).
Modelos de ciclo de vida

La ingeniería del software establece y se vale de una serie de modelos
que establecen y muestran las distintas etapas y estados por los que pasa
un producto software, desde su concepción inicial, pasando por su
desarrollo, puesta en marcha y posterior mantenimiento, hasta la retirada
del producto. A estos modelos se les denomina Modelos de ciclo de vida del
software. El primer modelo concebido fue el de Royce, más comúnmente
conocido como Cascada o Lineal Secuencial. Este modelo establece que las
diversas actividades que se van realizando al desarrollar un producto
software, se suceden de forma lineal (Singh, 2005).
Los modelos de ciclo de vida del software describen las fases del ciclo
de software y el orden en que se ejecutan las fases (Singh, 2005).
Un modelo de ciclo de vida de software es una vista de las actividades
que ocurren durante el desarrollo de software, intenta determinar el orden
de las etapas involucradas y los criterios de transición asociados entre
estas etapas (Singh, 2005).
Un modelo de ciclo de vida del software:
1) Describe las fases principales de desarrollo de software
2) Define las fases primarias esperadas de ser ejecutadas durante esas
fases
3) Ayuda a administrar el progreso del desarrollo
4) Provee un espacio de trabajo para la definición de un proceso
detallado de desarrollo de software
En cada una de las etapas de un modelo de ciclo de vida, se pueden
establecer una serie de objetivos, tareas y actividades que lo
caracterizan. Existen distintos modelos de ciclo de vida, y la elección de
un modelo para un determinado tipo de proyecto es realmente importante; el
orden es uno de estos puntos importantes.
Existen varias alternativas de modelos de ciclo de vida (Singh, 2005).
Modelo de cascada

Es el enfoque metodológico que ordena rigurosamente las etapas del ciclo
de vida del software, de forma que el inicio de cada etapa debe esperar a
la finalización de la inmediatamente anterior (Singh, 2005).
El modelo en cascada es un proceso de desarrollo secuencial, en el que el
desarrollo se ve fluyendo hacia abajo (como una cascada) sobre las fases
que componen el ciclo de vida (Singh, 2005).
Se cree que el modelo en cascada fue el primer modelo de proceso
introducido y seguido ampliamente en la ingeniería el software. La
innovación estuvo en la primera vez que la ingeniería del software fue
dividida en fases separadas (Singh, 2005).
La primera descripción formal del modelo en cascada se cree que fue en un
artículo publicado en 1970 por Winston W. Royce, aunque Royce no usó el
término cascada en este artículo. Irónicamente, Royce estaba presentando
este modelo como un ejemplo de modelo que no funcionaba, defectuoso (Singh,
2005).
En el modelo original de Royce, existían las siguientes fases:
1) Especificación de requisitos
2) Diseño
3) Construcción (Implementación o codificación)
4) Integración
5) Pruebas
6) Instalación
7) Mantenimiento
Para seguir el modelo en cascada, se avanza de una fase a la siguiente en
una forma puramente secuencial como se muestra en la Imagen 2.

Imagen 2.Modelo de ciclo de vida en cascada

Si bien ha sido ampliamente criticado desde el ámbito académico y la
industria, sigue siendo el paradigma más seguido a día de hoy.
Modelo en V

El modelo en v se desarrolló para terminar con algunos de los problemas
que se vieron utilizando el enfoque de cascada tradicional. Los defectos
estaban siendo encontrados demasiado tarde en el ciclo de vida, ya que las
pruebas no se introducían hasta el final del proyecto. El modelo en v dice
que las pruebas necesitan empezarse lo más pronto posible en el ciclo de
vida. También muestra que las pruebas no son sólo una actividad basada en
la ejecución. Hay una variedad de actividades que se han de realizar antes
del fin de la fase de codificación. Estas actividades deberían ser llevadas
a cabo en paralelo con las actividades de desarrollo, y los técnicos de
pruebas necesitan trabajar con los desarrolladores y analistas de negocio
de tal forma que puedan realizar estas actividades y tareas y producir una
serie de entregables de pruebas. Los productos de trabajo generados por los
desarrolladores y analistas de negocio durante el desarrollo son las bases
de las pruebas en uno o más niveles. El modelo en v es un modelo que
ilustra cómo las actividades de prueba (verificación y validación) se
pueden integrar en cada fase del ciclo de vida. Dentro del modelo en v, las
pruebas de validación tienen lugar especialmente durante las etapas
tempranas, por ejemplo, revisando los requisitos de usuario y después por
ejemplo, durante las pruebas de aceptación de usuario (Singh, 2005).
El modelo en v es un proceso que representa la secuencia de pasos en el
desarrollo del ciclo de vida de un proyecto. Describe las actividades y
resultados que han de ser producidos durante el desarrollo del producto. La
parte izquierda de la v representa la descomposición de los requisitos y la
creación de las especificaciones del sistema. El lado derecho de la v
representa la integración de partes y su verificación. V significa
"Validación y Verificación" como se muestra en la Imagen 3 (Singh, 2005).

Imagen 3. Modelo de ciclo de vida en V

Realmente las etapas individuales del proceso pueden ser casi las mismas
que las del modelo en cascada. Sin embargo hay una gran diferencia. En vez
de ir para abajo de una forma lineal las fases del proceso vuelven hacia
arriba tras la fase de codificación, formando una v. La razón de esto es
que para cada una de las fases de diseño se ha encontrado que hay un
homólogo en las fases de pruebas que se correlacionan (Singh, 2005).
Modelo iterativo

Es un modelo derivado del ciclo de vida en cascada. Este modelo busca
reducir el riesgo que surge entre las necesidades del usuario y el producto
final por malos entendidos durante la etapa de recogida de requisitos
(Singh, 2005).
Consiste en la iteración de varios ciclos de vida en cascada. Al final de
cada iteración se le entrega al cliente una versión mejorada o con mayores
funcionalidades del producto. El cliente es quien después de cada iteración
evalúa el producto y lo corrige o propone mejoras. Estas iteraciones se
repetirán hasta obtener un producto que satisfaga las necesidades del
cliente. Así como se muestra en la Imagen 4.

Imagen 4. Modelo de ciclo de vida iterativo

Este modelo se suele utilizar en proyectos en los que los requisitos no
están claros por parte del usuario, por lo que se hace necesaria la
creación de distintos prototipos para presentarlos y conseguir la
conformidad del cliente (Singh, 2005).
Modelo de desarrollo incremental

El modelo incremental combina elementos del modelo en cascada con la
filosofía interactiva de construcción de prototipos. Se basa en la
filosofía de construir incrementando las funcionalidades del programa. Este
modelo aplica secuencias lineales de forma escalonada mientras progresa el
tiempo en el calendario. Cada secuencia lineal produce un incremento del
software. Aquí se muestra la Imagen 5 (Singh, 2005).

Imagen 5. Modelo de ciclo de vida incremental

Cuando se utiliza un modelo incremental, el primer incremento es a menudo
un producto esencial, sólo con los requisitos básicos. Este modelo se
centra en la entrega de un producto operativo con cada incremento. Los
primeros incrementos son versiones incompletas del producto final, pero
proporcionan al usuario la funcionalidad que precisa y también una
plataforma para la evaluación (Singh, 2005).
Modelo en espiral

El desarrollo en espiral es un modelo de ciclo de vida desarrollado por
Barry Boehm en 1985, utilizado de forma generalizada en la ingeniería del
software. Las actividades de este modelo se conforman en una espiral, cada
bucle representa un conjunto de actividades. Las actividades no están
fijadas a priori, sino que las siguientes se eligen en función del análisis
de riesgos, comenzando por el bucle anterior.
Boehm, autor de diversos artículos de ingeniería del software; modelos de
estimación de esfuerzos y tiempo que se consume en hacer productos
software; y modelos de ciclo de vida, ideó y promulgó un modelo desde un
enfoque distinto al tradicional en Cascada: el Modelo Evolutivo Espiral. Su
modelo de ciclo de vida en espiral tiene en cuenta fuertemente el riesgo
que aparece a la hora de desarrollar software. Para ello, se comienza
mirando las posibles alternativas de desarrollo, se opta por la de riesgos
más asumibles y se hace un ciclo de la espiral. Si el cliente quiere seguir
haciendo mejoras en el software, se vuelven a evaluar las nuevas
alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta
que llegue un momento en el que el producto software desarrollado sea
aceptado y no necesite seguir mejorándose con otro nuevo ciclo.
Este modelo de desarrollo combina las características del modelo de
prototipos y el modelo en cascada. El modelo en espiral está pensado para
proyectos largos, caros y complicados.
Esto modelo no fue el primero en tratar el desarrollo iterativo, pero fue
el primer modelo en explicar las iteraciones.
Este modelo fue propuesto por Boehm en 1988 en su artículo "A Spiral
Model of Software Development and Enhancement". Básicamente consiste en una
serie de ciclos que se repiten en forma de espiral, comenzando desde el
centro. Se suele interpretar como que dentro de cada ciclo de la espiral se
sigue un modelo en cascada, pero no necesariamente ha de ser así.
Este sistema es muy utilizado en proyectos grandes y complejos como puede
ser, por ejemplo, la creación de un sistema operativo.
Al ser un modelo de ciclo de vida orientado a la gestión de riesgos se
dice que uno de los aspectos fundamentales de su éxito radica en que el
equipo que lo aplique tenga la necesaria experiencia y habilidad para
detectar y catalogar correctamente riesgos.
Tareas:
Para cada ciclo habrá cuatro actividades:
1) Determinar o fijar objetivos:
a. Fijar también los productos definidos a obtener:
requerimientos, especificación, manual de usuario.
b. Fijar las restricciones
c. Identificación de riesgos del proyecto y estrategias
alternativas para evitarlos
d. Hay una cosa que solo se hace una vez: planificación inicial o
previa
2) Análisis del riesgo:
a. Se estudian todos los riesgos potenciales y se seleccionan una
o varias alternativas propuestas para reducir o eliminar los
riesgos
3) Desarrollar, verificar y validar (probar):
a. Tareas de la actividad propia y de prueba
b. Análisis de alternativas e identificación de resolución de
riesgos
c. Dependiendo del resultado de la evaluación de riesgos, se
elige un modelo para el desarrollo, que puede ser cualquiera
de los otros existentes, como formal, evolutivo, cascada, etc.
Así, por ejemplo, si los riesgos de la interfaz de usuario son
dominantes, un modelo de desarrollo apropiado podría ser la
construcción de prototipos evolutivos.
4) Planificar:
a. Revisamos todo lo que hemos hecho, evaluándolo y con ello
decidimos si continuamos con las fases siguientes y
planificamos la próxima actividad.
El proceso empieza en la posición central. Desde allí se mueve en el
sentido de las agujas del reloj. A continuación se muestra la Imagen 6.

Imagen 6. Ciclo de vida espiral

Las cuatro regiones del grafico son:
1) La tarea de planificación: para definir recursos, responsabilidades,
hitos y planificaciones.
2) La tarea de determinación de objetivos: para definir los requisitos
y las restricciones para el producto y definir las posibles
alternativas.
3) La tarea de análisis de riesgos: para evaluar riesgos tanto técnicos
como de gestión.
4) La tarea de ingeniería: para diseñar e implementar uno o más
prototipos o ejemplos de la aplicación (Singh, 2005).
Modelo de prototipos

Un cliente, a menudo, define un conjunto de objetivos generales para el
software, pero no identifica los requisitos detallados de entrada, proceso
o salida. En otros casos, el responsable del desarrollo del software puede
no estar seguro de la eficiencia de un algoritmo, de la calidad de
adaptación de un sistema operativo, o de la forma en que debería tomarse la
interacción hombre-máquina. En estas y en otras muchas situaciones, un
paradigma de construcción de prototipos puede ofrecer el mejor enfoque.
El paradigma de construcción de prototipos comienza con la recolección de
requisitos. El desarrollador y el cliente encuentran y definen los
objetivos globales para el software, identifican los requisitos conocidos y
las áreas del esquema en donde es obligatoria más definición. Entonces
aparece un diseño rápido. El diseño rápido se centra en una representación
de esos aspectos del software que serán visibles para el usuario/cliente.
El diseño rápido lleva a la construcción de un prototipo. El prototipo lo
evalúa el cliente/usuario y se utiliza para refinar los requisitos del
software a desarrollar. La iteración ocurre cuando el prototipo se pone a
punto para satisfacer las necesidades del cliente, permitiendo al mismo
tiempo que el desarrollador comprenda mejor lo que se necesita hacer, la
siguiente Imagen 7 muestra el ciclo de vida (Singh, 2005).

Imagen 7. Modelo de ciclo de vida de prototipos




Etapas el desarrollo de software

Etapa uno: Requerimientos del software.

De acuerdo con Pressman (2010), "el diseño y construcción del software de
computadora es difícil, creativo y sencillamente divertido". En realidad,
crear un software es tan atractivo que muchos programadores o
desarrolladores quieren ir directo a la codificación antes de haber
comprendido lo que realmente se necesita. Algunos programadores piensan que
a medida que se codifica, se encontrarán con las necesidades del programa,
pero esto no es así (Pressman, 2010).
Los requerimientos para un software son una descripción de los servicios
proporcionados por el sistema y sus limitaciones funcionales. Estos
requerimientos muestran las necesidades de los clientes de un sistema que
ayude a resolver algún problema unos ejemplos son:
Hacer un pedido.
Encontrar información.
El proceso de encontrar, analizar, documentar y verificar todos los
servicios y restricciones se denominados comúnmente ingeniería de
requerimientos (Braude, 2003).
Los requerimientos del sistema del software se clasifican en funcionales
y no funcionales:
Requerimientos funcionales: son las acciones de los servicios que el
sistema debe cumplir ó hacer, y en algunas ocasiones lo que el sistema no
debe de hacer (Somerville, 2005)(Pressman, 2010).
Requerimientos no funcionales: son las restricciones de los servicios del
sistema, como los pueden ser fechas, tiempos, estándares. Los tipos de
requerimientos no funcionales son:
Requerimientos del producto: definen el comportamiento del producto
o servicio.
Requerimientos organizacionales: son derivados de las políticas de
las empresas u organizaciones donde se desarrollan (Somerville,
2005) (Pressman, 2010).
Requerimientos externos: incluye todos los requerimientos que
provienen de los elementos externos al sistema y de su transcurso de
desarrollo, como las legislaciones en vigor.
Otros tipos de los requerimientos son los de dominio, de usuario y del
sistema. Los requerimientos del dominio, son los propios del área del
proyecto, son los conocimientos específicos necesarios que emanan del
problema mismo, por otra parte están los requerimientos del usuario, estos
son las necesidades expresadas por el usuario en un lenguaje natural, donde
el mismo detalla lo que desea que el software realice, mientras que los
requerimientos del sistema son una forma más completa o detallada de los
requerimientos del usuario, que normalmente usan los ingenieros para el
diseño del sistema(Pressman, 2010) (Somerville, 2005).
Lenguajes para la definición de requerimientos de software.

Especificación en lenguaje estructurado

El lenguaje natural estructurado es una manera de describir los
requerimientos del sistema donde la expresión del redactor de los
requerimientos está limitada y donde todos los requerimientos se redactan
de una manera estándar. La ventaja de esta visión es que contiene la mayor
parte de la expresividad y entendimiento del lenguaje natural, pero
mantiene cierta calidad de uniformidad en la especificación (Somerville,
2005).
Casos de uso

Cockburn (2001) afirma que "un caso de uso ó CU capta un contrato que
describe el comportamiento del sistema en distintas condiciones en las que
el sistema responde a un petición de alguno de sus particiones". En
esencia, un caso de uso describe una historia estabiliza sobre cómo
interactúa un usuario final (que puede llevar a cabo cierto número de
roles) con el sistema en circunstancias especificas. La historia puede ser
un texto narrado, un lineamiento de tareas o interacciones, una descripción
basada en un formato o una representación diagramática. Sin importar su
forma, un caso de uso ilustra el software o sistema desde punto de vista
del usuario final.
El primer paso para escribir un caso de uso es describir un conjunto de
actores que estarán involucrados en la historia. Los actores son las
distintas personas (o dispositivos) que usan el sistema o producto en el
contexto de la función y comportamiento que va a describir. Los actores
representan los papales que desempeñan los personajes cuando el opera el
sistema.
Debido a que la indagación de los requerimientos es una actividad
evolutiva, no todos los actores son identificados en la primera iteración.
En ésta es posible identificar a los principales, y a los secundarios
cuando se sabe más del sistema. Los actores principales interactúan para
lograr la función requerida del sistema y obteniendo el beneficio previsto
de éste. Trabajo con el software de forma directa y con frecuencia. Los
actores secundarios dan apoyo al sistema, de modo que los primarios pueden
hacer su trabajo.
Una vez identificados los actores, es posible desarrollar casos de uso.
Jacobson (1992) sugiera varias preguntas que debe responder un caso de uso:
1) ¿Quién es el actor principal y quiénes son los secundarios?
2) ¿Cuáles son los objetivos de los actores?
3) ¿Qué precondiciones deben existir antes de comenzar la historia?
4) ¿Qué tareas o funciones principales son realizadas por el actor?
5) ¿Cuáles variaciones son posibles en la interacción del actor?
6) ¿Qué información del sistema adquiere, produce o cambia el actor?
7) ¿Tendrá que informar el actor al sistema acerca de los cambios en el
ambiente externo?
8) ¿Qué información desea obtener el actor del sistema?
9) ¿Quiere el actor ser informado sobre cambios en el sistema?
Muchas veces los requerimientos se expresan de manera natural como
interacción de una aplicación y otra externa a esta. Como un usuario. El
caso de uso, concepto creado por Jacobson (1994), es una forma muy útil de
esas iteraciones. Un caso de uso se identifica primero por su nombre y el
tipo de usuario de la aplicación, llamado actor. Consiste en una
interacción típica entre un actor ó usuario y una aplicación. Por ejemplo,
abrir un archivo sería un caso de uso típico para un procesador de
palabras, con el usuario como actor, y podría consistir en la siguiente
secuencia de pasos.
1) El usuario selecciona el menú de archivo.
2) El sistema despliega las opciones: nuevo y abrir.
3) El usuario hace clic en abrir.
4) El sistema despliega la ventana de archivo.
5) El usuario introduce el directorio y el nombre del archivo.
6) El usuario oprime el botón de abrir.
7) El sistema trae el archivo nombrado a la ventana del procesador de
palabra.
Dado que su forma de los pasos es fácil de entender, los casos de uso son
un medio de comunicación en especial con los clientes.
Con la notación de UML Lenguaje Unificado de Modelado (Unified Modeling
Language), la figura de forma de elipse denota un caso de uso, cada caso de
uso es una secuencia de acciones.
El actor de un caso de uso no necesariamente tiene que ser una persona,
puede ser otro sistema que use la aplicación.
Los casos de uso son como una historia, son efectivos para producir
información a partir de los clientes, y proporcionan un panorama excelente
de las aplicaciones.
Los casos de uso se pueden expresar a diferentes niveles de generalidad.
El proceso unificado de desarrollo de software (USDP), recomienda usar
casos de usos detallados para especificar una fracción grande de
requerimientos.
El proceso unificado de desarrollo (USDP) explota la observación de que
muchos requerimientos ocurren de manera natural en secuencias operativas.
Por ejemplo, el requerimiento individual de que una aplicación para una
tienda de videos permita introducir el titulo de un nuevo video suele ser
parte de una secuencia de transacciones. Éstas son los casos de uso,
algunas veces llamados "escenarios" (en UML, un "escenario" es en realidad
una instancia de un caso de uso)
Es evidente que casos de usos similares no llevan un gran valor
adicional. Relativos entre si, los casos de uso deben ser secuenciales u
ortogonales. Dos casos de uso son secuenciales si uno sigue directamente al
otro. Los casos de uso ortogonales toman puntos de vistas u opciones
opuestas.
Jacobson (1994) creo la idea de los casos de uso al observar que, a pesar
del gran número de ejecuciones potenciales, muchas aplicaciones están
concebidas en términos de un número relativamente pequeño de iteraciones
típicas.
La mayor parte de los estándares de documentación establecidos, incluidos
los del IEEE, son los casos de uso y deben aumentarse para tomarlos en
cuenta. Los casos de uso son útiles para especificar los casos de
requerimientos, diseño y pruebas.
Como los casos de uso de alto nivel pueden expresar la visión del cliente
de cómo debe funcionar la aplicación, el caso de estudio los incluye en la
sección "concepto de operación" de la especificación de requerimientos del
software.
Validación de requerimientos de software

Los requerimientos después de haber sido definidos, requirieren de una
verificación para determinar si estos realmente representan una solución a
las necesidades del cliente o definen el sistema que el cliente desea.
Durante el transcurso de validación de requerimientos, se hacen
verificaciones en el documento de requerimientos. Estas comprenden:
Verificación de validez: Un usuario piensa que necesita un sistema
para ciertas funciones, pero puede necesitar otro tipo de sistema,
funciones diferentes o adicionales
Verificar consistencia: Los requerimientos en el documento no deben
contradecirse entre sí.
Verificación de completitud: El documento de requerimientos debe
incluir todas las funciones y restricciones dichas por el usuario
del sistema.
Verificación de realismo: Los requerimientos deben verificarse para
asegurar que sí se pueden llevar a cabo.
Verificabilidad: Los requerimientos siempre deben redactarse de tal
manera que sean constatables (Somerville, 2005).
Etapa dos: Diseño de la arquitectura

El diseño se encuentra en la parte técnica de la ingeniería del software
y se aplica sin importar el modelo del proceso que se utilice. Cada uno de
los elementos de los requerimientos proporciona una información necesaria
para la especificación completa del diseño.
El diseño lo podríamos describir como un proceso de múltiples etapas, en
la cual, y a partir de los requerimientos de información obtenidos en la
etapa de análisis, se sintetizan las representaciones de los datos, la
estructura del programa, las características de la interfaz y los detalles
del procedimiento. Como menciona Freeman (1980) en una descripción más
amplia:
"El diseño es una actividad que tiene que ver con la toma de decisiones
importantes, con frecuencia de naturaleza estructural. Comparte con la
programación el objetivo de abstraer una representación de la información y
de las secuencias de procesamiento, pero en los extremos el grado de
detalle es muy distinto. El diseño elabora representaciones coherentes y
bien planeadas de programas, que se concentran en las relaciones de las
partes en el nivel más alto y en las operaciones lógicas involucradas en
los niveles bajos".
La etapa de diseño del software comienza una vez que se han analizado y
modelado los requerimientos en la parte de análisis; es la parte de la
ingeniería de software donde se desarrolla el modelado del sistema y se
prepara el terreno para entrar a la etapa de Construcción (generación y
prueba de código).
Antes de preocuparse por los detalles, es necesario tener un panorama
general de lo que será el sistema. Por eso es importante la etapa de
diseño, para dar un panorama y asegurarse que sea el correcto.
Bass et al. (2003) identifican tres razones clave por las que es
importante la arquitectura del software:
Las representaciones de la arquitectura del software permiten la
comunicación entre todas las partes interesadas en el desarrollo de
un sistema basado en computadora.
La arquitectura muestra las primeras decisiones que tendrán un
resultado profundo en todo el trabajo de ingeniería de software y,
también importante, en el éxito final del sistema como entidad
operacional.
La arquitectura "constituye un modelo relativamente pequeño y
asequible por la vía intelectual sobre cómo está estructurado el
sistema y la forma en la que sus componentes trabajan juntos"(al,
2003).
La importancia del diseño del software se resume en una palabra: calidad.
El diseño es la parte donde se introduce calidad en la ingeniería de
software. Es en esta etapa donde podemos evaluar la representación de un
sistema de acuerdo a su calidad. El diseño es el fundamento de toda la
ingeniería de software y de las actividades que dan el apoyo que sigue. Al
no tener un diseño se corre el riesgo de tener un sistema inestable, que
falle cuando se hagan cambios pequeños, o uno que sea difícil de someter a
prueba.
El diseño de software es un proceso en el que plasmamos los
requerimientos en un "plano", el cual nos ayuda en la construcción del
software. En un principio el diseño es bastante simple y con un alto grado
de abstracción, donde es posible visualizar fácilmente el objetivo
principal del sistema, su funcionamiento y su comportamiento, dicha
abstracción va disminuyendo conforme se avanza durante el proceso de
diseño(Pressman, 2010).
La importancia del diseño radicaba en la calidad, pero ¿Cómo podemos
determinar la calidad de nuestro diseño? McGlaughlin (1991) sugiere tres
características que funcionan como guía para evaluar un buen diseño:
Debe implementar todos los requerimientos explícitos contenidos en
el modelo de requerimientos y dar cabida a todos los requerimientos
implícitos que desean los participantes.
Debe ser una guía legible y comprensible para quienes generan el
código y para los que lo prueban y dan el apoyo posterior.
Debe proporcionar el panorama completo del software, y abordar los
dominios de los datos, las funciones y el comportamiento desde el
punto de vista de la implementación.
Más que características, podríamos considerar estos tres puntos como
metas y objetivos del proceso de diseño.
Conceptos fundamentales del diseño

La ingeniería de software abarca varios conceptos fundamentales sobre el
diseño. Cada uno de estos conceptos nos otorga las bases para que podamos
aplicar métodos de diseño más sofisticados.
Abstracción

Cuando se considera una solución modular para cualquier problema, es
posible plantear muchos niveles de abstracción. En el más elevado se
enuncia una solución en términos gruesos con el uso del lenguaje del
ambiente del problema. En niveles más bajos de abstracción se da la
descripción más detallada de la solución. La terminología orientada al
problema se acopla con la que se orienta a la implementación, en un
esfuerzo por enunciar la solución. Por último, en el nivel de abstracción
más bajo se plantea la solución, de modo que pueda implementarse
directamente (Pressman, 2010).
Arquitectura

La arquitectura del software hace referencia a la estructura general de
éste y a las formas en las que ésta da integridad conceptual a un sistema.
En su forma más simple, la arquitectura es la estructura de organización de
los módulos de un programa, la forma en la que éstos interactúan y la
estructura de datos que utilizan. Sin embargo, en un sentido más amplio los
componentes se generalizan para que representen los elementos de un sistema
grande y sus interacciones.
Una meta del diseño del software es obtener una aproximación
arquitectónica de un sistema. Ésta sirve de estructura a partir de la cual
se realizan las actividades de diseño más detalladas. Un conjunto de
patrones arquitectónicos permite que el ingeniero de software resuelva
problemas de diseño comunes (Pressman, 2010).
Patrones

Appleton (2000) define un patrón de diseño de la siguiente forma:
"Un patrónes una mezcla de conocimientos que transmite la esencia de una
solución probada de un problema recurrente dentro de un contexto
determinado en medio de preocupaciones de la competencia."
En base a lo anterior se puede decir que un patrón es, en sí, una
estructura de diseño que ayuda a resolver un determinado problema dentro de
cierto contexto, el cual determina (junto con otros factores) como aplicar
y utilizar dicho patrón.
El objetivo de cada patrón de diseño es proporcionar una descripción que
permita a un diseñador determinar:
Si el patrón es aplicable al trabajo en cuestión.
Si es reutilizable.
Si sirve como guía para desarrollar un patrón distinto en funciones
o estructura. (Appleton, 2000)
División de problemas

La división de problemas es un concepto de diseño que sugiere que
cualquier problema, por más complejo que sea, puede manejarse con más
facilidad si se subdivide en elementos susceptibles de resolverse u
optimizarse de manera independiente. Al separar un problema en piezas más
pequeñas y manejables, su resolución requerirá menos esfuerzo y tiempo.
Este concepto maneja la estrategia de divide y vencerás, pues es más
fácil resolver un problema complejo si se divide en elementos manejables.
(Pressman, 2010)
Modularidad

La modularidad es la manifestación más común de la división de problemas.
El software se divide en componentes con nombres distintos y abordables por
separado, en ocasiones llamados módulos, que se integran para satisfacer
los requerimientos del problema (Pressman, 2010).
En función de las circunstancias, el diseño debe descomponerse en muchos
módulos con la esperanza que sea más fácil entenderlos y, en consecuencia,
reducir el costo requerido para elaborar el software.
Es verdad que el esfuerzo para desarrollar un módulo individual se reduce
conforme aumentan el número total de módulos. Sin embargo, al aumentar el
número total también aumenta la complejidad para integrarlos (Braude,
2003).
Encapsulación de información

La encapsulación se caracteriza por el diseño de módulos que manejan
información inaccesible para otros módulos que no necesite de ella.
La encapsulación va de la mano con la modularidad, e implica que, para
obtener una modularidad efectiva es necesario definir un conjunto de
módulos independientes que intercambien solo aquella información necesaria
para lograr la función del software.
Pressman (2010) menciona la gran utilidad que tiene la encapsulación
durante el diseño:
"El uso del ocultamiento de información como criterio de diseño para los
sistemas modulares proporciona los máximos beneficios cuando se requiere
hacer modificaciones durante las pruebas, y más adelante, al dar
mantenimiento al software. Debido a que la mayoría de los datos y detalles
del procedimiento quedan ocultos para otras partes del software, es menos
probable que los errores inadvertidos introducidos durante la modificación
se propaguen a distintos sitios dentro del software."
Rediseño

El rediseño es una técnica de reorganización que viene a simplificar el
diseño de un módulo o un componente, pero sin cambiar su funcionalidad y
comportamiento. Es decir, cambiar la estructura interna de una parte del
sistema pero sin alterar el comportamiento externo del mismo.
Al momento de rediseñar el software, se examina el diseño existente en
busca de redundancias, elementos de diseño no utilizados, algoritmos
ineficientes o innecesarios, estructuras de datos mal construidas o
inapropiadas y cualquier otra falla del diseño que se pueda corregir para
obtener un mejor diseño(Pressman, 2010).
El resultado de llevar a cabo un rediseño efectivo será un software más
fácil de integrar, de probar y de mantener (Braude, 2003).
Estilos de arquitectura

Los estilos de arquitectura o estilos arquitectónicos, se utilizan como
mecanismos descriptivos para diferenciar nuestro diseño de otros estilos.
Aún más importante, el estilo arquitectónico nos sirve como una plantilla
para orientarnos en la construcción del sistema.
El objetivo es establecer una estructura para todos los componentes del
sistema. Los estilos de arquitectura, según Pressman (2010), se clasifican
como sigue:
Arquitecturas centradas en los datos.
Arquitecturas de flujo de datos.
Arquitecturas de llamar y regresar.
Arquitecturas orientadas a objetos.
Arquitectura en capas.
Para fines prácticos del desarrollo de este proyecto, nos enfocaremos en
los dos últimos: las arquitecturas orientadas a objetos y en capas.
Arquitecturas orientadas a objetos

Los componentes de un sistema incluyen datos y las operaciones que deben
aplicarse para manipularlos. La comunicación y coordinación entre los
componentes se consigue mediante la transmisión de mensajes.
Arquitectura en capas

En este estilo de arquitectura se define un número de capas diferentes;
cada una ejecuta operaciones que se aproximan progresivamente al conjunto
de instrucciones de máquina. Independientemente del diseño y el número de
capas que se maneje a la hora de crear la arquitectura para un sistema,
podemos identificar tres tipos:
Capa externa, los componentes se encargan de las operaciones de la
interfaz de usuario.
Capas intermedias, proveen servicios de utilerías y funciones de
software de aplicación.
Capa interna, los componentes realizan la interfaz con el sistema
operativo.
Estilo arquitectónico y reingeniería

En el caso en el que ha de hacerse la reingeniería de una arquitectura ya
existente, la imposición de un estilo arquitectónico dará como resultado
cambios fundamentales en la estructura del software, incluida la
reasignación de las funciones de los componentes (Pressman, 2010).
UML

El lenguaje de modelado unificado (UML por sus siglas en ingles) es un
lenguaje grafico para la visualización, especifica, construcción, y
documentación de cada una de las etapas que comprenden el desarrollo de
software. UML proporciona una forma de modelar cosas conceptuales como lo
son procesos de negocio y funciones de sistemas, además de cosas concretas
como lo son escribir clases de un lenguaje de programación determinado,
esquemas de base de datos y componentes de software reusables.
Boch (1999) define un modelo como "una simplificación de la realidad" el
cual construimos para poder entender mejor el sistema que estamos
desarrollando. A través del modelo, se logran 4 objetivos:
Los modelos ayudan a visualizar un sistemas como es o como queremos
que sea.
Los modelos permiten especificar la estructura o comportamiento de
un sistema.
Los modelos proporcionan un plantilla que sirve de guía en la
construcción de un sistema.
Los modelos documentan las decisiones que hemos tomado.
Es definitivamente cierto que entre más grande y complejo es un sistema
más importante se vuelve modelar, por una simple razón: "Construimos
modelos de sistemas complejos porque podemos comprender tales sistemas en
su totalidad".
La habilidad humana tiene límites para entender la complejidad. A través
del modelado, hacemos más pequeño el problema de estudio, enfocándonos sólo
a un aspecto a la vez. Ese es esencialmente el enfoque de "divide y
vencerás" que Edsger Dijkstra dijo hace unos años: "Ataca un problema
difícil dividiéndolo en una serie de problemas más pequeños que puede
resolver". Además, a través del modelado se amplifica el intelecto del
hombre. Un modelo escogido apropiadamente puede lograr que el modelador
trabaje a niveles mayores de abstracción.
UML es apropiadamente para modelar sistemas no importa cual sea el giro.
Es un lenguaje que no es difícil de entender o se usar. Según Boch (1999)
aprender UML efectivamente comienza con la formación de modelos
conceptuales del lenguaje, lo cual requieren de tres elementos principales:
Los bloques de construcción básicos de UML.
Las reglas que dictan como deben de juntarse esos bloques de
construcción y
Algún mecanismo común que se aplica a través del lenguaje.
Principios del modelado

El uso del modelado tiene una rica historia en todas las disciplinas de
la ingeniería. Esta experiencia sugiere 4 principios básicos para el
modelado.
Primero – La elección de que modelos crear tiene un influencia
profunda en como atacar un problema y como formar una solución. Esto
quiere decir que debemos escoger bien los modelos. Los modelos
correctos permitirán representar los problemas de desarrollo más
difíciles, ofreciéndonos la visión de que otra manera no hubiéramos
podido comprender; los modelos equivocados nos guiaran erróneamente,
causando que nuestra atención se concentre en cosas irrelevantes.
Segundo – Cada modulo puede ser expresado a diferentes niveles de
precisión. Los mejores modelos son aquellos que nos dejan escoger el
grado de detalle, dependiendo de quien esta viendo el modelo y
porque necesita verlos. Por ejemplo, un analista o un usuario se
enfocan en cosas como el ¿Qué?, mientras que el desarrollador se
enfocan en cosas como el ¿Cómo? De cualquier manera el modelo debe
poder permitir ver al sistema en diferentes niveles de detalle en
ocasiones distintas.
Tercero – Los mejores modelos están conectados a la realidad. Es
mejor tener modelos que tienen una clara conexión con la realidad, y
en donde la conexión sea débil, saber exactamente como esos modelos
están divorciados del mundo real. Todos los modelos son
simplificaciones de la realidad, el truco es estar seguros que las
simplificaciones no oculten detalles importantes.
Cuarto – Ningún modelo sencillo es suficiente. Los sistemas que no
son triviales se enfocan mejor a través de un pequeño conjunto de
modelos independientes ligados. Se pueden tener modelos que se
pueden construir y estudiar por separado, pero estos están
interrelacionado. Por ejemplo, en el caso de un edificio, se pueden
estudiar los planos eléctricos por separado, pero podemos ver un
mapeo en los planos piso, y quizá hasta su interacción con la
tubería en el plano de plomería.
UML es un lenguaje

UML es un lenguaje y, por lo tanto, es solo una parte del método de
desarrollo de software. Un lenguaje provee un vocabulario y las reglas de
combinación de palabras en ese vocabulario y las reglas de combinación de
palabras en ese vocabulario para lograr la comunicación. Un lenguaje de
modelado es un lenguaje cuyo vocabulario y reglas se enfocan en la
representación conceptual y física de un sistema. Un lenguaje de modelado
como UML es un lenguaje estándar para planear un software.
Boch (1999) explica que UML es lenguaje para
Visualizar
Especificar
Construir
Documentar
Para entender UML se necesita formar un modelo conceptual del lenguaje.
Cuando se vaya adquiriendo experiencia en UML, se podrán construir modelos
conceptuales usando características avanzadas de este lenguaje. La Imagen 8
muestra el vocabulario que abarca UML.


Imagen 8. Vocabulario UML

Etapa tres: Codificación del software

En esta etapa tiene por fin traducir en una forma legible para la
computadora el diseño desarrollado en la etapa anterior. Esta actividad
implica la creación de programas informáticos aplicando las estructuras de
programación de algún paradigma y utilizando un lenguaje de programación.
El código fuente debe documentar con la elección de identificadores
(variables y etiquetas) que sean significativas, incorporar comentarios al
principio de cada modulo que indiquen la función del modulo; una
descripción de su interfaz y de los argumentos que tengan; una descripción
de la estructura de datos mas significativos que utilice el modulo y una
historia del modulo. Asimismo se incorpore comentarios descriptivos en el
cuerpo del modulo para describir las funciones de procesamiento.
El desarrollo del software o codificación está relacionada con el diseño
ya que es un proceso de escribir el programa con base a los diagramas y
descripciones ya establecidas (Somerville, 2005). Existen diferentes
formas de codificar un software, que son:
Desarrollo del software rápido.
Reutilización del software.
Ingeniería del software basado en componentes.
Desarrollo de sistemas críticos.
Desarrollo rápido de software

En cualquier empresa o compañía, el software es una parte fundamental, ya
que con éste se lleva a cabo cualquier transacción dentro de la misma. Las
empresas requieren que la creación de sus aplicaciones de software se
realice de forma rápida para aprovechar cualquier oportunidad de
crecimiento, pues la carencia de estos sistemas podría traducirse como
pérdidas; debido a esta urgencia, por parte de las empresas, hacia los
nuevos sistemas o actualizaciones, el desarrollo debe ser crítico.
(Highsmith, 2002)(Somerville, 2005).
El desarrollo ágil de software es un marco de trabajo conceptual de la
ingeniería de software que promueve iteraciones en el desarrollo a lo largo
de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo
ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos
de tiempo. El software desarrollado en una unidad de tiempo es llamado una
iteración, la cual debe durar de una a cuatro semanas. Cada iteración del
ciclo de vida incluye: planificación, análisis de requerimientos, diseño,
codificación, revisión y documentación. Una iteración no debe agregar
demasiada funcionalidad para justificar el lanzamiento del producto al
mercado, pero la meta es tener una demo (sin errores) al final de cada
iteración. Al final de cada iteración el equipo vuelve a evaluar las
prioridades del proyecto (Highsmith, 2002).
Los procesos de desarrollo rápido de software están creados para formar
software útil y de una forma rápida. A grandes rasgos, son procesos
iterativos donde se entrelazan la especificación, el diseño, el desarrollo
y las pruebas. El software no se desarrolla y se utiliza en su totalidad,
sino en la serie de incrementos, donde cada uno de los incrementos se
integrara a las nuevas funcionalidades al sistema (Somerville, 2005)
(Highsmith, 2002).
El desarrollo rápido de aplicaciones implica la utilización de entornos
de desarrollo que incluyan herramientas potentes para apoyar la producción
del sistema. Éstas comprenden lenguajes de programación de base de datos,
generadores de formularios e informes (Somerville, 2005) (Highsmith, 2002).
Aquí se utiliza el término prototipado o versión alpha para pronunciar un
proceso iterativo para desarrollar un sistema experimental que no será
dirigido a los clientes. Se realiza un prototipo del sistema para auxiliar
a los programadores de software y los stakeholders a comprender que es lo
que se necesita implementar. Los prototipos no deben ser descartados sino
que son creados para ver si se cumplen los requerimientos de los usuarios
(Somerville, 2005) (Highsmith, 2002).
La programación extrema

La programación extrema (XP) es tal vez el método ágil más conocido y más
utilizado. Fue creado con las prácticas de desarrollo iterativo y con la
participación de los clientes en etapas extremas (Somerville, 2005)
(Highsmith, 2002).
Esta programación extrema también creó una subdivisión, nombrada
programación en parejas, que constaba de formar a los equipos, donde ambos
interactuaban, compartían ideas y creaban una aplicación más rápido y
supervisada por ambos compañeros, así mismo el cliente llego a formar parte
de este proceso para hacer las pruebas del sistema (Somerville, 2005)
(Highsmith, 2002).
Reutilización del software

La ingeniería del software basada en reutilización es la estrategia que
implica basarse de un software ya existente.
La reutilización basada en generadores se aprovecha del hecho de que las
aplicaciones del mismo dominio, tales como sistemas de negocio, tienen
arquitecturas comunes y realizan funciones comparables.
La reutilización basando en estos como se mención anteriormente pueden
usar herramientas como los modelos de UML y código generado añadir detalles
para completar los requerimientos del usuario en el nuevo código
(Somerville, 2005).
Ingeniería del software basado en componentes.

Ingeniería del software basada en componentes es el proceso de definir,
implementar e integrar en sistemas componentes independientes débilmente
acoplados. Se ha transformado en una significativa aproximación de
desarrollo del software debido a que los sistemas del software son cada vez
más grandes y más complejos y los clientes demandas software que sea más
confiable que se sea desarrollado más rápidamente(Somerville,
2005)(Highsmith, 2002).
Desarrollo de sistemas críticos

Desarrollo de sistemas críticos pueden integrar componentes que crean la
funcionalidad de otros componentes (redundancia) o código de verificación
adicional que no es estrictamente necesaria para que el sistema funcione.
Por eso, los problemas pueden encontrarse antes de que provoquen fallos en
el funcionamiento, y el sistema sea capaz de seguir funcionando si los
componentes individuales fallan (Somerville, 2005).
El uso de redundancia y diversidad tanto en los procesos software como en
los sistemas de software es esencial para el desarrollo de sistemas
confiables (Somerville, 2005)(Highsmith, 2002).
Los cuatros aspectos del programación de la tolerancia defectos son
detección de fallos de ejecución, evaluación de los daños, recuperación y
reparación de defectos (Pressman, 2010).
La programación con n-versiones y bloques de recuperación son
aproximaciones alternativas a las arquitecturas tolerantes a defectos, en
las que se mantiene copias redundantes del hardware y software. Ambas
cuentan con la diversidad del diseño y el uso de un controlador tolerante a
defectos para la coordinar la ejecución de las unidades de programas
redundantes (Pressman, 2010).
El uso de un proceso repetible y bien definido es importante utilizar si
se tienen que minimizar los defectos en un sistema. El proceso debería
incluir actividades de verificación y validación en todas las etapas,
desde la definición de los requerimientos hasta la implementación del
sistema (Pressman, 2010).
Etapa cuatro pruebas del software

Las pruebas del software representan el porcentaje más grande de esfuerzo
técnico en el proceso de software. Sin importar el tipo de software que se
construya, una estrategia para la planificar, ejecutar y controlar pruebas
sistemáticas comienza por considerar pequeños elementos del software y
moverse hacia fuera, hacia el programa como un todo (Somerville, 2005).
Los procesos de pruebas tienen dos objetivos:
1) Demostrar al programador y al cliente que el software satisface las
necesidades o los requerimientos. Lo que quiere decir es que por lo
menos debe haber una prueba para cada requerimiento del sistema y
del usuario.
2) Encontrar defectos en el software en que el comportamiento de este
es incorrecto o no deseable o no cumple con la especificación. Las
pruebas de defectos está relacionado con quitar todos los
comportamientos incorrectos del sistema.
El primero nos conduce a las pruebas de validación, en donde se espera
que el funcionamiento sea correcto, para ello se utilizan un conjunto de
casos de prueba. El segundo objetivo nos conduce a la prueba de defectos,
en donde los casos se crean para exponer los defectos (Braude, 2003).
Como dice de forma elocuente Edsger Dijkstra (1772, USA) una de las
primeras figuras lideres en el desarrollo de la ingeniería del software
"las pruebas solo pueden demostrar la presencia de errores, no su
ausencia".
El objetivo de las pruebas del software es convencer a los programadores
del sistema y a los usuarios de que el software es lo suficientemente bueno
para su uso funcional. Un modelo general del proceso de prueba del software
se muestra en la Imagen 9 (Somerville, 2005).

Imagen 9. Un modelo del proceso de prueba del software.

Pruebas del sistema

Las pruebas del sistema implican integrar dos o más componentes que
implementan funciones del sistema o características.
Para la mayoría de los sistemas complejos, existen tres fases de pruebas
del sistema:
1) Pruebas de integración.
2) Pruebas de entregas.
3) Pruebas de rendimiento
Pruebas de integración

En donde el equipo de pruebas tiene acceso al código fuente del sistema.
Cuando se encuentra un problema, el equipo intenta encontrar el problema e
identificar los componentes que tienen que ser depurados. Los componentes
que se integran pueden ser componentes comerciales, componentes
reutilizables que fueron adaptados a un sistema en particular o componentes
nuevos.
La integración del sistema implica identificar tipos de componentes que
proporcionan alguna funcionalidad del sistema e integrar estos añadiendo
código para que hacer que funcione conjuntamente (Somerville, 2005).
Pruebas de entrega

El equipo de pruebas se ocupa validar que el sistema satisface los
requerimientos y de asegurar que el sistema es confiable. Las pruebas de
entrega son normalmente pruebas de caja negra en las que el equipo de
pruebas se ocupa simplemente de demostrar si el sistema funciona o no
correctamente (Braude, 2003).
El principal objetivo es aumentar la confianza de los suministradores en
el que el sistema cumpla con los requerimientos. Otro nombre que recibe es
pruebas funcionales ya que al verificador le interesa la funcionalidad y no
la implementación del software (Somerville, 2005).
Pruebas de rendimiento

Las pruebas de rendimiento buscan tanto de demostrar que el sistema
cumple los requerimientos como encontrar defectos y problemas en el
sistema.
También recibe el nombre de prueba de estrés, éstas realizan validaciones
que se acercan a la mayor carga de diseño del sistema hasta que el sistema
falla. Estos tienen dos tipos de funciones.
1) Prueba el comportamiento del fallo de ejecución del sistema. Pueden
ocurrir sucesos a través de una combinación no esperada de eventos
en donde la carga sobre el sistema supere la carga máxima
anticipada.
2) Sobrecargan el sistema y pueden provocar que se manifiesten defectos
que normalmente no serían descubiertos (Somerville, 2005).
Pruebas de componentes

Pruebas de componentes, también llamadas pruebas de unidad es el proceso
de comprobar el sistema por componentes individuales.
Existen diferentes tipos de componentes que pueden comprobarse en esta
etapa:
1) Funciones individuales o método dentro de un objeto.
2) Clases de objetos que tienen varios atributos y métodos.
3) Componentes compuestos formados por diferentes objetos o funciones.
Pruebas de interfaces

La pruebas te interfaces son particularmente importaciones para el
desarrollo orientado a objetos y basados en componentes. Los objetos y
componentes definen por su interfaces y pueden reutilizados en combinación
con otros componentes en sistemas diferentes. Los errores de interfaz en el
componente compuesto no pueden detectarse probando los objetos individuales
o componentes.
Existen diferentes tipos de interfaces entre los componentes del programa
y, consecuentemente, distintos tipos de errores de interfaces que pueden
producirse:
Interfaces de parámetros. Son interfaces en las que los datos, o
algunas veces referencias a funciones, se pasan de un componente a
otro en forma de parámetros.
Interfaces de memoria compartida. Son interfaces en las que un
bloque de memoria se comparte entre los componentes. Los datos se
colocan en la memoria por un subsistema y son recuperados desde aquí
por otros sistemas.
Interfaces proceduales. Son interfaces en las que un componente
encapsula un conjunto de procedimientos que pueden ser llamados por
otros componentes. Los objetos y los componentes reutilizables
tienen esta forma de interfaz.
Interfaces de paso de mensajes. Son interfaces en las que un
componente solicita un servicio de otro componente mediante un paso
de mensaje.
Esta prueba quiere saber cómo se comporta de acuerdo a sus
especificaciones (Somerville, 2005).


Diseño de casos de prueba

El diseño de casos de pruebas es una parte de las pruebas de los
componentes y sistemas en las que se diseñan los casos de prueba (entradas
y salidas esperadas) para probar el sistema. Su objetivo de este sistema es
crear un conjunto de casos de pruebas que sean efectivas encontrando
defectos de los programas y muestren que el sistema satisface los
requerimientos.
Existen varias aproximaciones que pueden seguirse para diseñar casos de
pruebas:
1) Pruebas basadas en requerimientos.
2) Pruebas de particiones.
3) Pruebas estructurales.
Pruebas basadas en requerimientos

Aquí se diseñan los casos de prueba para los requerimientos del sistema.
Normalmente se utiliza durante la etapa de pruebas del sistema, ya que los
requerimientos del sistema se crean por varios componentes.
Las pruebas basadas en requerimiento, por lo tanto son un acercamiento
sistemático al diseño de casos de pruebas en donde el usuario considera
cada requerimiento y deriva un conjunto de pruebas para cada uno de ellos.
Las pruebas basadas en requerimientos son de validación en vez de defecto.
Pruebas de particiones

Un acercamiento sistemático al diseño de casos se basa en encontrar todas
las particiones para un sistema o componente.
Pruebas estructurales

Las pruebas estructurales son una aproximación al diseño de casos de
prueba en donde las pruebas se derivan a partir del conocimiento de la
estructura e implementación del software. Este acercamiento se denomina a
veces pruebas de caja blanca, de caja de cristal o de caja transparente
esto para distinguir de la pruebas de caja negra.
Prueba de caminos

Estas son una estrategia de las pruebas estructurales cuyo objetivo es
probar cada camino de ejecución independiente en un componente o programa.
Etapa cinco Mantenimiento del software

El mantenimiento puede visualizarse en tres vertientes principales:
a) Correctivo: es el más caro, pues implica un retroceso hacia la
ubicación de un problema no considerado, o de un requisito mal
entendido, o de un error de implementación dado.
b) Aumentativo: es el añadir nuevos requisitos o necesidades al
producto.
c) Preventivo: se modifica componentes del software o del sistema para
prevenir situaciones anómalas (Morales, 1998).
El mantenimiento del software empieza. Cuando aparece una lista de
corrección de errores, nuevas adaptaciones y nuevas mejoras que deben
planearse, y que deben lograrse. Normalmente aquí es donde encuentra la
lista enorme de nuevas modificaciones que a la organización encuentra
además del costo que se eleva (Pressman, 2010).
Soportabilidad del software

Con el fin de dar soporte efectivo al software, la organización deben
poder cumplir las correcciones, adaptaciones y mejores que son un segmento
del mantenimiento.
Una definición de soportabilidad del software es la capacidad de dar
soporte a un sistema de software durante toda la vida del producto. Esto
implica satisfacer cualquier necesidad o requisito, pero también provisión
de equipo, infraestructura de soporte, software adicional, instalaciones,
mano de obra o cualquier otro recurso requerido para mantenerse el software
operativo y capaz de satisfacer funciones(Pressman, 2010).
Importancia de la reingeniería

Al vivir en un mundo que cambia rápidamente, las demandas sobre las
funciones empresariales y la tecnología de la información que las apoyan
cambian a un paso que pone enorme presión competitiva sobre toda
organización comercial. Por esto, el software debe mantenerse continuamente
y, en el momento adecuado, someterse a reingeniería para sostener el paso.
(Pressman, 2010)
Actividades de reingeniería de software

El proceso de reingeniería de software consiste en un modelo cíclico.
Esto significa que cada una de las partes que componen el proceso puede
revisarse. Para algún ciclo particular, el proceso puede terminar después
de cualquiera de estas actividades. Análisis de inventarios
Es necesario contar con un inventario de todas las aplicaciones. No es
necesario seguir un formato de documentación, el inventario puede ser nada
mas que un modelo de hojas de cálculo que contenga información detallada de
cada aplicación (por ejemplo, nombre, tamaño, longevidad, importancia). Al
ordenar toda esta información en base a su tamaño, importancia, longevidad,
etc. Encontraremos que aplicaciones son candidatas a reingeniería.
Es necesaria una revisión periódica del inventario, debido a que las
características de algunas aplicaciones (por ejemplo, importancia y
longevidad) pueden cambiar con el paso del tiempo y, como resultado,
cambiarán las prioridades para aplicar reingeniería.
Restructuración de documentos

La mayoría de los sistemas candidatos a reingeniería comparten una
característica, una débil documentación. Pressman describe 3 opciones sobre
qué se debe hacer con esta documentación:
1) La creación de documentación consume demasiado tiempo. Si el sistema
funciona adecuadamente puede elegir vivir con lo que tiene. En
algunos casos, éste es el enfoque correcto. No es posible volver a
crear documentación para cientos de programas de cómputo.
2) La documentación debe actualizarse, pero su organización tiene
recursos limitados. Use un enfoque "documente cuando toque". Acaso
no sea necesario volver a documentar por completo una aplicación. En
vez de ello, aquellas porciones del sistema que en el momento
experimenten cambio se documentan por completo. Con el tiempo,
evolucionará una colección de documentación útil y relevante.
3) El sistema tiene importancia empresarial y debe volver a
documentarse por completo. Incluso en este caso, un enfoque
inteligente es recortar la documentación a un mínimo esencial
(Pressman, 2010).


Importancia del Diseño y Análisis

Importancia de análisis

La etapa de análisis del software comienza con la concepción, tarea que
define el alcance y la naturaleza del problema que se va a resolver. Va
seguida de la indagación, labor que ayuda a los usuarios a definir lo que
se requiere. Después sigue la elaboración, donde refinan y modifican los
requerimientos básicos. Cuando los usuarios definen el problema, tiene
lugar una negociación donde se buscan las prioridades, esenciales y cuando
se requieren. Por último, se especifica el problema de algún modo y luego
se revisa o válida para garantizar que hay coincidencia entre la
comprensión que uno tiene del problema y la que tiene los usuarios.
Es importante entender antes de empezar a construir y diseñar un sistema
basado en computadora porque podría intentar resolver un problema que no
satisface la necesidad del usuario.
Es importante proporcionar un mecanismo apropiado para entender lo que el
cliente desea, analizar las necesidades, evaluar la factibilidad, negociar
una solución razonable, especificar la solución de ambigüedades, validar la
especificación y administración. Es muy importante notar que algunas de las
tareas trabajen en paralelo y que todas se adapten al proyecto.
Para validar los requerimientos del software se necesita estudiarlos
desde varios puntos de vista diferentes. Se consideran tres perspectivas
distintas de modelo de requerimientos: modelo basados en escenarios, modelo
de datos, y modelos basados en clases.
Importancia del diseño de arquitectura

La etapa de diseño del software comienza una vez que se han analizado y
modelado los requerimientos en la parte de análisis; es la parte de la
ingeniería de software donde se desarrolla el modelado del sistema y se
prepara el terreno para entrar a la etapa de Construcción (generación y
prueba de código).
Antes de preocuparse por los detalles, es necesario tener un panorama
general de lo que será el sistema. Por eso es importante la etapa de
diseño, para dar un panorama y asegurarse que sea el correcto.
Bass et al (1998).Identifican tres razones clave por las que es
importante la arquitectura del software:
Las representaciones de la arquitectura del software permiten la
comunicación entre todas las partes interesadas en el desarrollo de
un sistema basado en computadora.
La arquitectura resalta las primeras decisiones que tendrán un
efecto profundo en todo el trabajo de ingeniería de software
siguiente y, también importante, en el éxito último del sistema como
entidad operacional.
La arquitectura "constituye un modelo relativamente pequeño y
asequible por la vía intelectual sobre cómo está estructurado el
sistema y la forma en la que sus componentes trabajan juntos".
La importancia del diseño del software se resume en una palabra: calidad.
El diseño es la parte donde se introduce calidad en la ingeniería de
software. Es en esta etapa donde podemos evaluar la representación de un
sistema de acuerdo a su calidad. El diseño es el fundamento de toda la
ingeniería de software y de las actividades que dan el apoyo que sigue. Al
no tener un diseño se corre el riesgo de tener un sistema inestable, que
falle cuando se hagan cambios pequeños, o uno que sea difícil de someter a
prueba (Pressman, 2010).
El diseño de software es un proceso en el que plasmamos los
requerimientos en un "plano", el cual nos ayuda en la construcción del
software. En un principio el diseño es bastante simple y con un alto grado
de abstracción, donde es posible visualizar fácilmente el objetivo
principal del sistema, su funcionamiento y su comportamiento, dicha
abstracción va disminuyendo conforme se avanza durante el proceso de
diseño.
Anteriormente mencionaba que la importancia del diseño radicaba en la
calidad, pero ¿Cómo podemos determinar la calidad de nuestro diseño?
McGlaughlin sugiere tres características que funcionan como guía para
evaluar un buen diseño:
Debe implementar todos los requerimientos explícitos contenidos en
el modelo de requerimientos y dar cabida a todos los requerimientos
implícitos que desean los participantes.
Debe ser una guía legible y comprensible para quienes generan el
código y para los que lo prueban y dan el apoyo posterior.
Debe proporcionar el panorama completo del software, y abordar los
dominios de los datos, las funciones y el comportamiento desde el
punto de vista de la implementación.
Más que características, podríamos considerar estos tres puntos como
metas y objetivos del proceso de diseño.


Reingeniería

La reingeniería es una actividad de reconstrucción, se refiere al proceso
completo de convertir el código de programa al diseño, modificar el diseño
y volver a generar el nuevo código de programa. Esto se puede definir de la
mera que se divide en seis actividades o mejor dicho el ciclo de la
reingeniería del software.






















Imagen 10. Actividades de Reingeniería de software



El paradigma de la reingeniería se muestra en la Imagen 10 es un modelo
cíclico. Esto significa que cada una de las actividades presentadas como
parte del paradigma puede revisarse. Para algún ciclo en particular, el
proceso se puede terminar después de cualquier de las actividades
(Pressman, 2010).
Análisis de inventarios

Todas las organizaciones del software deben tener un inventario de todas
las aplicaciones. El inventario puede ser nada más que un modelo de hojas
de cálculo que contengan información que ofrezca una descripción detallada
de cada aplicación activa. Al ordenar la aplicación de acuerdo con
importancia empresarial, longevidad, mantenibilidad actual, soportabilidad,
otros importantes criterios locales, aparecen los candidatos para
reingeniería (Pressman, 2010).
Restructuración de documentos

La mayoría de los sistemas candidatos a reingeniería comparten una
característica, una débil documentación. Pressman describe 3 opciones sobre
qué se debe hacer con esta documentación:
1) La creación de documentación consume demasiado tiempo. Si el sistema
funciona adecuadamente puede elegir vivir con lo que tiene. En
algunos casos, éste es el enfoque correcto. No es posible volver a
crear documentación para cientos de programas de cómputo.
2) La documentación debe actualizarse, pero su organización tiene
recursos limitados. Use un enfoque "documente cuando toque". Acaso
no sea necesario volver a documentar por completo una aplicación. En
vez de ello, aquellas porciones del sistema que en el momento
experimenten cambio se documentan por completo. Con el tiempo,
evolucionará una colección de documentación útil y relevante.
3) El sistema tiene importancia empresarial y debe volver a
documentarse por completo. Incluso en este caso, un enfoque
inteligente es recortar la documentación a un mínimo esencial
(Pressman, 2010).


Ingeniería Inversa.

La ingeniería inversa es lo opuesto a la generación del código. Como se
muestra en la Imagen 11, el código fuente de la computadora es examinado,
analizado y convertido en entidades para el depósito. El primer paso de la
ingeniería inversa de software es cargar, en el conjunto de herramientas,
el código de programa existente (tal y como se halla escrito en cualquier
lenguaje de programación). Según el conjunto de herramientas de ingeniería
inversa que se utilice, el código es analizado y las herramientas producen
algo a todos los elementos siguientes:
1) Estructura de datos y elementos que describen los archivos y
registros almacenados por el sistema.
2) Diseño de pantallas, si el programa es en línea.
3) Esquema de informes para programas por lotes.
4) Un diagrama de estructura que muestra la jerarquía de los módulos
del programa.
5) Diseño y relaciones de la bases de datos.
Son varias las ventajas que se consiguen al utilizar un conjunto de
herramientas de ingeniería inversa:
1) Reducción del tiempo requerido para el mantenimiento del sistema,
con lo cual queda más tiempo para nuevos desarrollos.
2) Se genera documentación, que podría haber sido inexistente o mínima
en los programas anteriores.
3) Se crean programas estructurados a partir de código de computadora
no estructurado ó pobremente estructurado.
4) Los cambios futuros al mantenimiento son más sencillos, porque se
pueden realizar al nivel de diseño más que al nivel de código.
5) Es posible analizar el sistema con el fin de eliminar porciones sin
utilizar de código de computadora, el cual aun podrían estar
presente en programas anteriores a pesar de que las revisiones
hechas al programa a lo largo de los años lo hayan vuelto obsoleto
(KENDALL, 2005).




Imagen 11. Conceptos de ingeniería inversa.



El análisis de código fuente ha motivado un interés creciente desde los
primeros años del auge del desarrollo de software. Analizar código fuente
de forma automática, o al menos asistida, nos permite entre otras cosas,
apoyar varias áreas de marcada importancia como son el mantenimiento de
sistema, la integración de código legado en nuevas aplicaciones, la
recolección de medidas para evaluar la calidad del software desarrollado,
la transformación de programas, la refabricación de software que se puede
ver como caso especial de transformación de programas, entre otras.
Una de las áreas de especial interés actualmente, y que se apoyan
fundamentalmente en el análisis de código es la ingeniería inversa, que es
complementada por la reingeniería. Ingeniería inversa, como su nombre lo
indica, hace referencia al procedimiento contrario al que se realiza
habitualmente en lo que denominamos ingeniería del software.
En ingeniería del software el objetivo es ir modelando la realidad en
pasos sucesivos en los que se baja el nivel de abstracción, hasta llegar a
una representación computacional que se resuelva el problema planteado. De
ahí que los documentos iníciales sean especificaciones de requisitos en
lenguaje natural o algún lenguaje más formal de muy alto nivel, modelos
conceptuales expresados en lenguajes de modelado como es el caso de UML,
diseños de arquitecturas y modelos detallados, hasta que finalmente se
tenga una implementación en un lenguaje de muy alto nivel de abstracción.
La ingeniería inversa extraer modelos del dominio de la solución y, mas
aun, del dominio del problema a partir del código final. En este caso, el
lenguaje del código final es un lenguaje de modelado, o una abstracción de
un lenguaje de programación. El objetivo último de la ingeniería inversa
consiste en separar detalles de la implementación de la información
esencial del problema y de su solución. De esta forma, por ejemplo, suplen
las carencias de documentación cuando se trabaja con código heredado o se
puede cerrar el ciclo mediante lo que se conoce como reingeniería. Todo
esto a partir de la información extraída mediante la aplicación de
ingeniería inversa al código fuente de un sistema previamente desarrollado
(Pressman, 2010).
Reestructuración

La reestructuración de software modifica el código fuente y los datos con
la intención de hacerlos sensibles a cambios futuro. En general, la
reestructuración no modifica la arquitectura global de l programa. Tiene a
enfocarse sobre detalles de diseño de módulos individuales y sobre
estructuras de datos locales definidos de módulos. Si el esfuerzo de
reestructuración se extiende más allá de las fronteras del módulo y abarca
la arquitectura del software, la reestructuración se convierte en
ingeniería hacia adelante.
La reestructuración ocurre cuando la arquitectura básica de una
aplicación es solida, aun cuando el interior técnico necesita trabajarse.
Se inicia cuando grandes partes del software son aprovechadas y solo un
subconjunto de todos los módulos y datos necesitan modificación extensa
(Pressman, 2010).
Reestructuración de código

La reestructuración de código se realiza para producir un diseño que
funcione de la misma forma pero con mayor calidad que el programa original.
En general, las técnicas de reestructuración de código por ejemplo, las
técnicas de simplificación lógica de Warnier (1974) modelan la lógica del
programa usando algebra booleana y luego aplicando una serie de reglas de
transformación que producen lógica restructurada. El objetivo es tomar una
parte de código y derivar un diseño procedimental que se conforma con la
filosofía de la programación estructurada.
También se han hecho otras técnicas de reestructuración para su uso con
herramientas de reingeniería. Un diagrama de intercambio de recursos mapea
cada módulo de programa y los recursos de intercambian entre el y otros
módulos (Pressman, 2010).
Reestructuración de datos

La reestructuración de los datos es una actividad de reingeniería a gran
escala. En la mayoría de los casos, para empezar la reestructuración de
datos debe realizarse una actividad de ingeniería inversa llamada análisis
de código fuente.
Después del completado de datos el análisis, comienza el rediseño de
datos. En su forma más simple, un paso de estandarizado de registro de
datos clarifican la definiciones de los datos para lograr lo consistencia
entre nombres de ítem de datos o formatos de registro físico dentro de una
estructura de datos existentes o dentro de un formato de archivo (Pressman,
2010).
Ingeniería hacia adelante

La ingeniería hacia adelante no solo recupera información de diseño del
software existente, sino que también usa esta información para alterar o
reconstruir el sistema existente con la intención de mejorar la calidad
global (Pressman, 2010).




Sistemas de Planificación de Recursos Empresariales

Los Sistemas de Planificación de Recursos Empresariales o ERP tienen el
objetivo de integrar y optimizar los procesos de negocio utilizando para
ello tecnologías de la información (TI) (André & Gonzáles, 2010).
Definimos el ERP como un sistema de planificación de los recursos y de
gestión de la información que, de una forma estructurada satisface la
demanda de necesidades de la gestión empresarial. Se trata de un programa
de software integrado que permite a las empresas evaluar, controlar y
gestionar más fácilmente su negocio en todos los ámbitos. Los sistemas ERP
se caracterizan por su gran cantidad de adaptación, de modularidad, de
integración de la información (introducir los datos una sola vez), de
universalidad, de estandarización e interfaces con otro tipo de programas.
Son sistemas abiertos y multiplataforma. El software de tipo ERP es un
programa de gestión empresarial diseñado para cubrir todas las exigencias
de las áreas funcionales de la empresa, de forma que crean un flujo de
trabajo para las distintos usuarios, permitiendo agilizar los diferentes
tipos de trabajos, reduciendo en tiempo real las tareas repetitivas y
permitiendo además el aumento de la comunicación entre todas las áreas que
integran la empresa. Es importante entender que cuando se plantea la
adquisición de un ERP se requiere parametrizaciones y modificaciones
previas para que funcione de una forma óptima. Esto implica que cuando una
empresa decide adquirir un ERP también debe contratar implantador (o
empresa de consultoría) que ayude a su puesta en funcionamiento. El tiempo
requerido para la implementación y puesta en marcha varia según el tipo de
ERP, el numero de módulos, el tamaño de la empresa y las necesidades; pero
también hay que tener en cuenta que implantar un ERP será, casi siempre,
menos costoso que desarrollar una aplicación a medida que nos garantice el
mismo índice de efectividad. El sistema ERP se compone de un conjunto de
módulos que permiten a la empresa automatizar e integrar las diferentes
operaciones que se realizan en las diferentes áreas (contabilidad,
finanzas, fabricación, recursos humanos, ventas, compras, existencia,
servicios, etcétera). Este tipo de programas se caracterizan por su
facilidad de modularidad, integración de los procesos, capacidad de
información, universalidad, facilidad de consulta, estandarización e
interfaces con otras aplicaciones. El ERP tiene como uno de sus objetivos
principales satisfacer las diferentes necesidades de información de la
empresa para conseguir que los distintos responsables puedan tomar
decisiones y controlar el cumplimiento de objetivos, pero también hay que
considerar que la decisión de implantar un ERP es estratégica para la
empresa; por lo tanto, debe tenerse la capacidad de asumir los cambios y
recursos a emplear en la implantación (Muñiz, 2004).


El ciclo de vida de ERP

En esta sección se utiliza el marco del ciclo de vida del ERP propuesto
por Esteves y Pastor [1999]. Este marco está estructurado en las etapas que
un sistema ERP que atraviesa durante su ciclo de vida en el alojamiento de
una organización. Las etapas son las siguientes:
Decisión de adopción
Adquisición,
La aplicación,
Uso y mantenimiento,
La evolución, y
Fase de jubilación.
Fase de Adopción. En esta fase, los directivos deben cuestionar la
necesidad de un nuevo Sistema ERP, y la selección del enfoque de
información general del sistema que mejor se enfrente a sus retos de
negocios críticos y mejorar la estrategia de la organización. Esta fase de
decisión incluye la definición de los requisitos del sistema, sus objetivos
y beneficios, y un análisis del impacto de la adopción en un negocio y un
nivel de organización.
Fase de Adquisición. Esta fase consiste en seleccionar el producto que
mejor se ajusta a los requisitos de la organización para reducir al mínimo
la necesidad de la personalización. Una empresa de consultoría podría
estar involucrada para ayudar en las fases del ciclo de vida de un ERP,
especialmente en la fase de ejecución. Factores tales como la
funcionalidad, precio, servicios de formación y el mantenimiento se
analizan y son el acuerdo contractual definido. En esta fase también es
importante analizar el retorno de la inversión del producto seleccionado
(Muñiz, 2004).


Fase de Implementación. Esta fase se refiere a la personalización o
parametrización y la adaptación del paquete de ERP adquirido. Para
satisfacer las necesidades de la organización. Por lo general, esta tarea
se lleva a cabo con la ayuda de consultores que proporcionan metodologías
de implementación, know-how y capacitación. Aunque la capacitación es
presente en todas las fases, la mayor inversión en la formación se realiza
durante la fase de ejecución.
Fase de Uso y Mantenimiento. Esta fase consiste en el uso del producto en
una manera que devuelve los beneficios esperados y disminuye la
perturbación. Durante esta fase en los negocios son importantes, la
funcionalidad, la facilidad de uso, y la adecuación a los procesos
organizacionales. Una vez que un sistema está implementado, debe estar en
constante vigilancia, porque un mal funcionamiento tiene que ser corregido,
las solicitudes especiales de optimización se deben cumplir, y tienen que
ser aplicadas en los sistemas generales para mejorar (Muñiz, 2004).


Fase de evolución. En esta fase, las capacidades adicionales que se
integran en el sistema ERP para obtener beneficios adicionales. Las
extensiones se pueden clasificar en dos tipos:


Evolución "upward ó hacia arriba". La funcionalidad está orientada
a la toma de decisiones con aplicaciones tales como la planificación
y programación avanzada, los almacenes de datos, y los sistemas de
inteligencia de negocios;
Evolución "outward ó hacia afuera" para el entorno del sistema, con
aplicaciones como gestión de relaciones con clientes, gestión de la
cadena de suministro, entre organizaciones flujo de trabajo y
comercio electrónico.


Fase del retiro. Cuando aparecen nuevas tecnologías o el sistema de ERP o
enfoque se convierte en inadecuado para las necesidades del negocio, los
gerentes a decidir si será sustituido por otro enfoque de sistema de
información que es más adecuada a las necesidades organizativas del
momento. Algunas organizaciones ya han pasado a través esta fase por
razones tales como los cambios estratégicos, la falta de confianza en el
proveedor de ERP o la aplicación pareja, o las malas experiencias de
implementación.


Definición y características de los módulos de un ERP

"Módulos "Componentes "
"Administrativo y "Contabilidad general "
"financiero "Bancos y cartera "
" "Compras "
"De gestión "Contactos. "
" "Servicios. "
" "Producción. "
" "Gestión de proyectos. "
" "Gestión de recursos. "
" "Gestión de nóminas. "
" "Gestión de recursos humanos. "
" "E-commerce. "


Contabilidad general

Se trata de un modulo, que recoge el registro, resumen y gestión de todos
los datos con transcendencia contable, centralizándolos para su consulta,
publica o control. Su contenido puede ser el siguiente: plan de cuentas,
fichas de cuentas, contabilización mediante los diferentes diarios,
creación y seguimiento de presupuestos, informes de temas contables y
análisis de estados financieros, configuración del programa, gestión de
impuestos, gestión de contabilidad en doble divisa, consolidación de
cuentas, realización de asientos estándar y repetitivos (Muñiz, 2004).
Bancos y cartera

Bancos

La gestión de bancos permite a la empresa controlar, de una forma rápida
y eficaz, los movimientos y saldos bancarios. Su contenido podría ser el
siguiente: control de datos bancarios, realización de conciliaciones de
control de saldos en divisas, envío y recepción de datos vía telemática con
bancos.
Cartera de cobros y pagos

Se gestiona con este módulo. Las formas de cobro y pago; además, debe
tener una relación directa con el módulo de gestión de bancos. El contenido
de la cartera de cobros gestiones los documentos a cobrar por la empresa,
siendo sus características: elaborar remesa al descuento o al cobro,
calcula de gastos financieros de remesas, gestión de efectos impagados y
factorización (Muñiz, 2004).
Compras

Con este módulo, se puede gestionar la creación de proveedores, el
registro de factura y los pagos. Sus principales características son:
creación de fichas de proveedores, los pedidos, la recepción de facturas,
abonos, descuentos sobre compras, control de compras (Muñiz, 2004).
Gestión de contactos

Que la empresa tenga una red de contactos clasificados de diferente
forma, una de las características principales de este módulo:
- Características generales: datos identificativos del contacto,
catalogarlo según el tipo de contacto, clasificar por zona, tipo,
código, prioridad, y definir las personas de contacto.
- Prestaciones a obtener: clasificar los clientes/ proveedores entre
reales y potenciales, generar campañas de marketing, realizar el
seguimiento de las posibles ventas (Muñiz, 2004).


Gestión de servicios posventa

Este módulo permite gestionar todo lo referente a diferentes tipos de
servicios posventa, a los que corresponde atender pedidos de servicio,
reparaciones y garantías. Sus características principales son: gestionar
los vencimientos de los contratos, controlar el historial de servicios por
cliente, gestionar producto y recursos empleados en cada servicio (Muñiz,
2004).
Gestión de proyectos

Este módulo permite la creación, el seguimiento y control de proyectos
diferentes tipos. Sus características principales son: elaborar
presupuestos de proyectos ; dividir los proyectos por fases, subfases y
tareas; utilizar distintos tipos de costes; analizar las desviaciones entre
el presupuesto y la realidad; confeccionar directamente las facturas a
clientes según costes incurridos o no; calcular los productos necesarios
(Muñiz, 2004).
Gestión de fabricación

Este módulo permite gestionar todo el proceso de planificación y
realización de la producción. Sus principales características son: crear
las ordenes de fabricación, controlar el consumo de materias primas y
recursos de fabricación, calcular la necesidades de recursos según las
unidades a producir, calcular y controlar la lista de materiales necesarios
para la producción, elaborar planes maestros de producción, creación de
ordenes de compra según necesidades (Muñiz, 2004).
Gestión de personal

Este modulo permite gestionar todo el proceso de planificación y
confección de la nomina, altas, bajas, contratos, control de horarios y
fichas de personal. Sus principales características son: redacción de
contratos, realización de todo lo referente al salario y seguridad social,
nominas, control de horas, horarios y días de fiesta, estadísticas
oficiales y gestión del impuesto del IRPF (Muñiz, 2004).
Gestión de E.commerce

Este módulo se integrará con el resto de módulos del ERP. Sirve para
integrar y automatizar operaciones con clientes y proveedores (Muñiz,
2004).



Procedimiento y Descripción de las actividades realizadas

EN ESTA SECCIÓN SE DETALLA LAS ACTIVIDADES DE REINGENIERÍA REALIZADAS EN
LA ACTUALIZACIÓN DE LA DOCUMENTACIÓN DEL ERP LÍDER DE LA EMPRESA BEPENSA
MOTRIZ.
Líder, como se ha expresado anteriormente, es un sistema ERP que se
utiliza para administrar diversos departamentos de la empresa Bepensa
Motriz. Este software actualmente está siendo actualizado y migrado a una
versión web, debido a esto, se necesita de la generación de la
documentación faltante y de la documentación de las nuevas funcionalidades
De acuerdo a los pasos de la reingeniería, el proceso de análisis de
inventario fue realizado directamente por la empresa, y se determinó que
Líder será el software a actualizar porque fue desarrollado desde hace más
de diez años y ya no cumple con las necesidades de la empresa.
En la segunda fase de la reingeniería, reconstrucción de la
documentación, la empresa se percató que no cuenta con una documentación
actualizada del software Líder, así como un control de cambios tanto del
software como de la misma documentación.
Ingeniería Inversa es la tercera etapa del ciclo de reingeniería, en esta
etapa se tuvo acceso a la software Líder como un usuario del sistema, para
obtener sus funcionalidades, es decir, en esta etapa se detallaron los
casos de uso del programa.
En esta primera etapa del proceso de la ingeniería inversa se estudia el
sistema seleccionado donde se llevó a cabo el proceso donde se realizó un
estudio del sistema antes de empezar a documentar todo lo que hace el
sistema líder, la segunda etapa fue la creación de los casos de uso del
software mediante las ventanas del sistema, código y la forma de cómo
trabaja.
La creación de los casos de uso fue mediante un formato que aplicamos que
se muestra en la Ilustración 1. El formato se divide en dos partes que es
el encabezado con la información de creador del caso del uso, y la
descripción del caso de uso.
La primera parte, que es el encabezado, se establece quien es el creador
del caso de uso. Este encabezado se divide en cinco etapas que son:
1. Identificación: se llenan los datos del título del caso de uso,
fecha de creación, el creador del CU, casos de uso relacionados, la
importancia del caso de uso.
2. El historial de cambios: que contiene, fecha, autor, versión y
descripción.
3. Revisores: nombre y puesto de las personas que serán los revisores
4. Aprobadores: nombre y puesto, son las personas encargadas de decir
si se aprueban o no.
5. Asesores: nombre y puesto, son las personas encargadas de asesorar
en la creación del caso de uso.
La segunda parte de la definición de los CU, se puede apreciar en la
Ilustración 2.


Ilustración 2 Descripción del CU.

La descripción del caso del uso que se divide en diferentes etapas la
cuales son:
1. Encabezado del caso de uso.
a. Descripción general: que nos permita saber qué función llevará
el caso de uso.
b. Actor principal: la persona encargada de dar inicio a la
acción.
c. Actor secundario: podría ser un usuario que dará inicio a la
acción del caso de uso según sus privilegios.
d. Objetivos de los actores: son las acciones que el actor
llevara a cabo para ejecutar correctamente el caso de uso.
e. Condiciones previas: son las acciones iníciales que tiene que
hacer el usuario para poder llevar a cabo el caso de uso.
f. Condiciones posteriores: es la forma en que el caso de uso de
llevara a cabo o si permanecerá en espera.
El cuerpo del caso del uso, que se puede observar en la Ilustración 3, se
divide en diversas etapas las cuales son:
1. Flujo de eventos: son las acciones de cómo iniciara el caso de uso,
o que opciones tiene el usuario para dar inicia a una acción, estas
se pueden dividir en varios flujos básicos.
a. Flujo básico: es la forma correcta de cómo funcionara el
sistema pensando que el usuario no cometa errores, y funcione
correctamente la acción del sistema en caso de ocurrir algún
fallo se utilizan los flujos alternativos.
b. Flujos alternativos ó excepciones: son las acciones que
llevara a cabo el sistema en caso de fallar o no encontrar
algún dato y mande advertencias.
Por ultimo se encuentra el diagrama de caso de uso que es la forma en
como esta el caso de uso relacionado con otros y que tiene que hacer el
usuario para llevar a cabo una acción.


















































Este formato fue el que se utilizó para crear los casos de uso del
software Líder.
Los casos de uso fueron obtenidos mediante el análisis de la interfaces
gráficas de usuarios (GUI) del software. El caso de uso que se muestra a
continuación es de un catálogo simple, y la mayoría de l los catálogos
simples tienen la misma estructura ya que contienen las mismas
funcionalidades que son mantenimiento y consulta.
Un ejemplo de un catalogo simple, se puede observar en la Ilustración 4:
1. ID.
2. Clave corta.
3. Descripción.
4. Estatus.


Ilustración 4 Ejemplo de caso de uso simple.

Los casos de usos complejos, tienen más casos de usos relacionados, por
eso requieren más datos que uno simple y puede llegar a contener muchos
casos de uso simple.
Un ejemplo de un caso de uso complejo es el de mantenimiento de unidad
que está compuesto de varias consultas de otros catálogos, este caso de uso
se obtuvo mediante la siguiente pantalla en la Imagen 12.

Imagen 12 Ventana de caso de uso complejo.

1. Descripción del caso de uso:
a. Datos generales.
b. Folio.
c. Clave.
d. Cliente.
e. Distribuidor.
f. Economía.
g. Toda la descripción de la unidad.
Toda esta información se requiere para dar de alta una unidad al sistema
y saber en qué condiciones se encuentra, además saber en qué tiempo o
kilometraje tiene que regresar por un mantenimiento de nuevo.
El diagrama del caso de uso de la ventana anterior se puede observar en
la Ilustración 5.


Ilustración 5 Caso de uso complejo.

Los casos de uso complejos siguen casi el mismo patrón, por lo general
cambian en algunas funciones internas del sistema.
El siguiente caso de uso describe los TOT. Es mucho más complejo que los
casos de uso anteriores, ya que conlleva más funciones internas que estos,
debido a que se requiere de la consulta de diversos catálogos para realizar
una acción.
En la Imagen 13 se muestra lo que se requiere para la creación de un
caso de uso de los TOT.

Imagen 13 Ventana de CU de los TOT

1. Descripción del caso de uso:
a. Identificador orden de S.
b. Identificador de la unidad.
c. Identificador del proveedor.
d. Identificador de la sucursal.
e. Tipo de moneda.
f. Tipo de cambio
g. Fecha de entrega.
h. Concepto.
En la siguiente Ilustración 6 se muestra el caso de uso que se crea
mediante la ventana y como están relacionados los casos de uso.

Ilustración 6 Ejemplo del Caso de uso de TOT

En la Imagen 14 se muestra una orden de servicio que contiene varios
campos de los cuales se tiene que identificar quienes serán los actores
que la utilizarán y que precondiciones se tiene que cumplir para llevar
acabo la orden de servicio, los campos que serán obligatorios, cuales
serán eliminados y la forma de como operan cada una de las funcione, que en
el caso de uso nombramos como subflujos de un flujo principal. Se establece
el orden de los campos y la forma en que se estarán llenando, en caso de
error se creará un flujo alternativo para mostrar que ocurrirá.
Las reglas del negocio son las definiciones sobre el manejo de las
excepciones y la manera en desplegar algún aviso de error. Estas reglas
son casos de uso del manejo de excepciones, y es necesario ligar el caso de
uso original con éstas.
Los reportes pueden ser agregados como referencia a cada caso de uso.

Imagen 14 Orden de servicio.

1. Descripción del caso de uso y el caso de uso se muestra en la
Ilustración 7.
a. Estatus de la Orden (proceso, facturada, etc.)
b. Folio de la Orden
c. Fecha de la Orden
d. Orden del cliente
e. Tipo de documento (orden de servicio, Diagnostico, cotización,
garantilla de taller, garantilla de fabrica,
acondicionamiento, etc.)
f. Tipo de servicio (Correctivo, preventivo, foráneo, Rescate,
lavado de unidad)
g. Que nivel es la orden de servicio ( si es una orden alterna)
h. Taller donde se esta trabajando
i. La promesa de entrega del servicio ( fecha y hora)



Ilustración 7 Caso de uso de la Orden de servicio.









Resultados

EL ORDEN DE ELABORACIÓN DE LOS CASOS DE USO FUE EL SIGUIENTE, PRIMERO SE
CREARON LOS CASOS DE USO DE LOS CATÁLOGOS SIMPLES, LOS SIGUIENTES FUERON
LOS DE LOS CATÁLOGOS COMPLEJOS, AL FINALIZAR ESTOS, SE CONTINUÓ CON LOS
CASOS DE USO DE ORDENES DE TRABAJOS DE OTROS TALLERES (TOT), Y POR ÚLTIMO
SE DISEÑARON LAS ÓRDENES DE SERVICIO.
Los casos de uso de catálogos simples fueron elaborados con el apoyo de
las ventanas del sistema, con las adecuaciones necesarias para su
funcionamiento. Se realizaron 25 casos de uso de este tipo.
Los casos de uso de los catálogos complejos fueron creados de manera
similar, mediante el uso de la interfaz de usuario como guía, y realizando
las modificaciones pertinentes para el nuevo sistema. De este tipo de casos
de uso se elaboraron quince diseños.
Los siguientes casos de usos fueron los de catálogos complejos que se
creaban de la misma manera, solo que como eran más complejos teníamos que
crear una base para empezar a crear los demás porque como interactúan con
más casos de uso, ejecutan muchas consultas llamándolos y de ahí la
complejidad.
Después se crearon los casos de uso de proceso de las TOT que son mucho
más complejos, ya que además de tener casos de uso complejos cuentan con
procesos internos. Estos también se basaron de las pantallas del sistema,
además de código y su funcionalidad para saber como trabaja el proceso
interno para crear el caso de uso que complemente una acción del sistema.
Se crearon 13 casos de usos para los TOT.
Es importante mencionar que los casos de uso de contabilizaron por
funcionalidad, y no por el número de casos de uso que los componen.


Además de encontrar los demás casos de uso porque son demasiados y
dividirlos bien para que no anden chocando entre ellos en algunos solo
mencionarlos en otros crear la acción que ejecutan este nos llevo mas
tiempo tanto que implementa mas reglas de negocio que respetar además de
los subflujos que se dividen en tres más y sacar uno especialmente solo
para consultas sin que interfiera con otro solo mencionarlo para poder
entrar a un caso de uso que seria el principal, este caso de uso de se
divide en mantenimiento, consultar, autorizar, terminar un trabajo,
concluir, cancelar, reasignar. Que a su vez cada uno de ellos consulta
varios catálogos, y de ahí llevar y crear la acción de cada uno de ellos
para después checar si falta alguno, o quitar datos del sistema
innecesarios.
Conclusiones

LO QUE SE LOGRO Y LOS OBJETIVOS, SE APROBÓ EL CURSO, SE, COMO CONTINUAR
EL PROYECTO. Y QUE CAMBIOS LE HARÍA AL PROYECTO.
Como conclusión se puede mencionar y destacar, que lo más importante es
que se lograron los casos de uso antes mencionados, de la manera propuesta
ya que se utilizaron las herramientas y las reglas para obtener los casos
de uso. Puede mencionarse que la creación de los casos de uso es muy simple
pero realmente es más compleja de lo que se puede imaginar ya que con ello
se tiene que satisfacer las necesidades del cliente, y cumplir las reglas
generales para crear un caso de uso según la magnitud del mismo. Dado que
el caso de uso debe ser entendible tanto para el cliente como el
programador y siempre usar un lenguaje simple. Antes de iniciar este
proyecto se tomaron unos cursos de UML que fueron satisfactorios, y que se
utilizaron de una manera correcta para poder entrar de lleno al proyecto,
los casos de uso creados durante este tiempo serán de gran utilidad para
las próximas actualizaciones del sistema, o en su caso para una nueva
transformación del software, además de contar con una documentación que
será de utilidad para los programadores en caso de que el sistema llegara a
contraer errores ó que el cliente necesite una nueva modificación.



Comentarios del Residente

ADQUISICIÓN DE HABILIDADES Y ACTITUDES GENÉRICAS

Comunicación oral

Se obtuvo demasiada comunicación oral en está participación del proyecto,
porque durante el proyecto se tenia que preguntar demasiado para conocer el
sistema, dar puntos de vista para poder actuar y participar dentro la
actividades, también participar en las juntas y comentar algunas ideas para
el proyecto.
Comunicación escrita en su propia lengua

Si se consiguió la comunicación escrita en la misma lengua dado que para
crear algunos casos de uso se tenía que escribir el caso de uso de manera
que el cliente y el programador entendieran los conceptos, como lenguajes
de programación, leguajes natural ó simple.
Capacidad de comunicarse con profesionales de otras áreas

Se tenia que comunicar con otras áreas profesionales dado que algunos de
estos sistemas son utilizados por otras personas especializadas en
diferentes áreas y se tenía que preguntar como lo manejaban, además de como
se les haría más fácil el uso de su aplicación.
Habilidades en el uso de TIC´S

Está habilidad fue muy usada porque el proyecto trataba de una aplicación
instalada en las computadoras además que maneja mucho las TIC´S en el área
que se hizo el proyecto.
Capacidad de análisis y síntesis

Esté capacidades se manejo demasiado porque para crear un caso de uso se
necesitaba analizar el sistema además de la manera de como se redactara los
casos de uso, y se tenía que documentar todo sobre el CU.
Capacidad de organizar y planificar

Estas habilidades se utilizaron porque antes de entrar en lleno al
proyecto se tuvo que crear una diagrama de actividades, que se tendrían que
hacer cada semana, respetar el orden de como se crearían los casos de uso
además de ir de lo más particular a los más general.
Habilidades para buscar y analizar información proveniente de fuentes
diversas

Está habilidad fue muy utilizada porque siempre se tenía que analizar el
sistema ya sea de la manera de ver una ventana o del mismo código para
crear los casos de uso, además de buscar información de las diversas
fuentes de información para lograr el objetivo de crear los CU del sistema.
Solución de problemas

De manera muy general la solución de problemas es lo que más presento ya
que para crear cualquier tipo de caso de uso estuvo presente porque si un
caso de uso tenía choques con otros ó problemas siempre se tenía que buscar
una solución a esos problemas que llegasen a encontrarse durante la
creación de los CU sobre todo de los más complejos del sistema.
Toma de decisiones

Siempre se llevo acabo una decisión y si esa decisión no era la correcta
tendría que tomarse otra para cumplir con los objetivos deseados y siempre
tendríamos que tomar decisiones para poder hacer acciones correctas o
incorrectas.
Trabajo en equipo

Esté proyecto necesito de mucho trabajo en equipo tanto de los
integrantes del proyecto como de personal fuera de el como los revisores,
del asesor externo y compañeros del trabajo para estar siempre en le mismo
contexto o las ideas de cada uno siempre eran importantes para poder
terminar los objetivos y satisfacer las necesidades del sistema y cliente.
Habilidades interpersonales

Estás habilidades siempre estuvieron presentes porque se tuvo que estar
en la misma sintonía con los demás compañeros y tratar de no estresarnos
sino de siempre estar contagiando a los compañeros para poder lograr los
objetivos.




Habilidades para trabajar en un ambiente laboral

Está habilidad de trabajar en el ambiente laboral siempre se presento
porque se tenía que entregar las actividades que se requerían para un fecha
determinada, además de contar con un horario de trabajo dentro de la
empresa y tomar un papel dentro del proyecto.
Capacidad de aplicar los conocimientos en la práctica

Desde el inicio de las actividades se aplicaron los conocimientos
adquiridos para poder llevar acabo todo lo adquirido en la escuela en el
proyecto realizado.
Asignaturas y contenidos de la carrera aplicados a lo largo de la
realización de la Residencia Profesional

Planificación y Modelo esta materia ayudo en la parte de planificar que
actividades son las que se llevarían acabo durante todo el proyecto.
Desarrollo de Proyectos de Software: se puede decir que es una de las más
importantes porque aquí se ve todo las fases de ingeniería en software.
Fundamentos de Desarrollo de Sistemas: nos muestra como analizar el
sistema o los requerimientos del mismo para llevar acabo el proyecto.
Programación de Sistemas: siempre con la misma parte fundamental que son
los análisis de los requerimientos.
Negocios Electrónicos: con la creación de los casos de uso y estudios
previos antes de llegar a la parte de análisis de los requerimientos.
Programación Móvil I: la creación de los primeros casos de uso.
Libros de ingeniería en software: para poder conocer todo sobre la
ingeniería del software y todo lo que se tiene que llevar acabo durante la
ceración del sistema.
Análisis y diseño de los requerimientos del sistema, UML: estos para
llevar acabo la creación de los casos de uso y tener en cuenta todo lo que
se necesita para crear los requerimientos del sistema.
Asignaturas y contenidos de la carrera que deberían reforzarse



Contenidos que deberían actualizarse en los programas de estudio







Referencias

AL, B. E. (2003). SOFTWARE ARCHITECTURE DESING PATTERNS IN JAVA. NEW YORK:
ADDISON WESLEY.

André, P., & Gonzáles, F. (2010). Maximización de los beneficios de los
sistemas ERP. Revista de Gestão da Tecnologia e Sistemas de
Informação, 05-32.

Braude, E. (2003). Ingeniería de Software una perspectiva orientada a
objetos. Mexico: Alfaomega.

Falgueres, B. C. (2003). Ingeniería del software. Barcelo: UOC.

Highsmith, J. (2002). Agile Software Development Ecosystems. Boston:
Addison-Wesley.

KENDALL, K. E. (2005). Análisis y diseño de sistemas. México: PEARSON.

Leon, A. (2008). ERP Demystified. India: Tata MCGraw-Hill.

Morales, R. C. (1998). Introducción al Análisis de Sistemas y la Ingeniería
de Software. San José, Costa Rica: Universidad Estatal a Distancia.

Muñiz, L. (2004). ERP. España: Gestión 2000.

Pressman, R. S. (2010). Ingeniería del software un enfoque practico. new
york: Mc Graw Hill.

Singh, K. A. (2005). Software Engineering. NEW AGE INTERNATIONAL
PUBLISHERS.

Somerville, I. (2005). Ingeniería del software. Madrid: Pearson, Addison
Wesley.

Wallace, T., & Kremzar, M. (2001). ERP: Making It Happen: The Implementers'
Guide to Success with Enterprise Resource Planning. Estados Unidos:
Wiley.



Apéndice

PONER EL FORMATO DEL CASO DE USO.


-----------------------








"Identificación "
"Título " "
"Fecha " "
"Elaborado " "
"por " "
"Casos de " "
"Uso " "
"Relacionado" "
"s " "
"Documentos " "
"Relacionado" "
"s " "
"Importancia"Alto, "Complejidad" "Impacto " "
" "Medio, Bajo"de " "operativo " "
" " "desarrollo " " " "


"Historial de Cambios "
"Fecha "Autor "Versión "Descripción "
" " " " "
"Revisores "
"Nombre "Puesto "
" " "


"Aprobadores "
"Nombre "Puesto "
" " "


"Asesores "
"Nombre "Puesto "
" " "






Ilustración 1Encabezado del Formato de Caso de Uso de la Empresa Bepensa




1.

1. Descripción General
Descripción del caso de uso


2. Actor Principal
Actor Principal del Caso de Uso, el que inicia el caso de uso


3. Actores Secundarios
Actor o actores secundarios del caso de uso


4. Objetivos de los Actores
Nombre de los actores y sus objetivos en este caso de Uso, descritos
con el siguiente formato:
Actor: Objetivo


5. Condiciones Previas
Son las condiciones previas que se deben cumplir para iniciar el caso
de uso.


6. Condiciones Posteriores
Son las condiciones posteriores que se deben cumplir al concluir el
caso de uso.

















Ilustración 3 Cuerpo del Caso de Uso




7. Flujos


1.
2. >

Sub Flujo 1
1.
a. >
b. >
c. >
2.
3.

Sub Flujo 2
1.
2.
3.




8. Flujos Alternativos o Excepciones








9. Diagrama