Ciclo de Vida Si Final

Ciclo de vida del sistema de información
Universidad Nacional Mayor de San Marcos

Universidad del Perú, DECANA DE AMÉRICA
FACULTAD DE CIENCIAS CONTABLES
CURSO: Auditoría del Sistema de Información
TEMA: “Ciclo de vida del sistema de información”
INTEGRANTES:
 Aguirre Huacachi, Steven Miguel

 Bustamante Rojas, Jenny Marleni
 Maqui Vargas, Lorena Anthuanett
 Pérez Suxe, Juan
 Rosales Azabache, Antuané Milagros
 Yucra Tintaya, Deyssi Liz
PROFESOR: Carreño Escobedo, Jorge Raúl
AULA: 314
AÑO: 2019
Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

0
Rosales Azabache, Yucra Tintaya
INDICE GENERAL
1. DEFINICIONES ..................................................................................................................... 4
2. ETAPAS DEL CICLO DE VIDA DEL SISTEMA DE INFORMACIÓN ................................. 5
3. FACTORES O VARIABLES DETERMINANTES ................................................................. 6
4. MÉTODOS PARA ADQUIRIR UN SISTEMA ....................................................................... 8
5. PRINCIPIOS GENERALES DEL CICLO DE VIDA DE DESARROLLO DE SISTEMAS .. 11
6. MODELO DE CICLO DE VIDA DE UN SISTEMA ............................................................. 13
6.1 MODELO CLÁSICO O CASCADA ..................................................................................... 13
6.2 MODELO DE CICLO DE VIDA INCREMENTAL ............................................................... 13
6.3 MODELO DE PROTOTIPADO DE REQUERIMIENTOS ................................................... 19
6.4 MODELO DE DESARROLLO EVOLUTIVO....................................................................... 24
6.5 MODELO EN ESPIRAL ...................................................................................................... 27
6.6 MODELO DE CONSTRUCCIÓN DE PROTOTIPOS ......................................................... 30
6.7 MODELO DE SÍNTESIS AUTOMÁTICA DE SOFTWARE ................................................ 33
7. EL CICLO DE VIDA DE UNA BASE DE DATOS .............................................................. 35
8. FASES DEL DISEÑO DE BASES DE DATOS .................................................................. 37
9. CASO PRÁCTICO ............................................................................................................... 40
10. BIBLIOGRAFÍA ................................................................................................................... 87

1
INDICE DE ILUSTRACIONES
Ilustración 1 Etapas del Ciclo de Vida de los Sistemas de Información ....................................................... 5
Ilustración 2. Fases para el desarrollo de sistemas ......................................................................................10
Ilustración 3. Fases del Sistema de Información ...........................................................................................12
Ilustración 4. Modelo Iterativo Incremental (Gutiérres, 2013) ......................................................................14
Ilustración 5. Modelo Incrementar de 4 partes (Marichelo, 2016) ................................................................15
Ilustración 6. Modelo Iterativo Incremental para el ciclo de vida del software (Gutiérrez, 2013) .............15
Ilustración 7. Modelo prototipado de requerimientos ...................................................................................20
Ilustración 8. Requerimientos del Usuario (Olvany 2017) ............................................................................22
Ilustración 9. Revisión de los requerimientos ...............................................................................................23
Ilustración 10. Modelo de ciclo de vida Evolutivo .........................................................................................25
Ilustración 11. Modelo de desarrollo en espiral (Boehm 1988). ...................................................................28
Ilustración 12. Modelo de desarrollo en espiral (Pressman 2002). ..............................................................29
Ilustración 13. Modelo de construcción de prototipos .................................................................................31
Ilustración 14. Modelo de Síntesis automática de software de Robert Balzer. ..........................................33
Ilustración 15. Comparación entre ciclos de vida. ........................................................................................34
Ilustración 16. Visión, misión y valores ..........................................................................................................41
Ilustración 17. Fases plan estratégico ............................................................................................................44
Ilustración 18. Organigrama ............................................................................................................................49
Ilustración 19. dependencia transversal en la gestión de proyectos ..........................................................55
Ilustración 20. implantación del sistema ERP integrado ..............................................................................56
Ilustración 21. Organigrama - Área funcional de tecnología ........................................................................57
Ilustración 22. Evolución de la inversión anual del proyecto (CAPEX) y el costo operativo ...................60
Ilustración 23. Organigrama del equipo del proyecto ...................................................................................72
Ilustración 24. Flujo de información dentro de la organización del proyecto ............................................81
Ilustración 25. Flujo de información por niveles jerárquicos del organigrama de proyecto. ...................82

2
INDICE DE TABLAS
Tabla 1. Relación entre etapas y fases en el desarrollo de un sistema .......................................9
Tabla 2. Ciclo de vida del desarrollo de sistemas .........................................................................9
Tabla 3. Usuarios claves ............................................................................................................... 57
Tabla 4. Evolución de la inversión anual del proyecto (CAPEX) y el costo operativo .............. 59
Tabla 5. Evolución flujo de caja y TIR .......................................................................................... 62
Tabla 6. Cash Flow del proyecto .................................................................................................. 62
Tabla 7. Estimaciones de referencia para cuantificar los beneficios......................................... 63
Tabla 8. Sumario ejecutivo............................................................................................................ 64
Tabla 9. Módulos del SAP R/3 ....................................................................................................... 68
Tabla 10. Descomposición estructural de actividades ............................................................... 69
Tabla 11. Matriz de responsabilidades del proyecto ................................................................... 73
Tabla 12. Roles de proyecto ......................................................................................................... 73
Tabla 13. Plan puesta en producción ........................................................................................... 74
Tabla 14. Plan de contingencia ..................................................................................................... 76
Tabla 15. Plan de comunicación de reuniones de proyecto ....................................................... 83
Tabla 16. Aprobación - Plan de contingencia .............................................................................. 85

3
CICLO DE VIDA DEL SISTEMA DE INFORMACIÓN
1. DEFINICIONES
 “El ciclo de vida de un sistema de información es un enfoque por fases del análisis y diseño que sostiene
que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo especifico de
actividades del analista y del usuario”.1
 “Es un sistema, automatizado o manual, que engloba a personas, máquinas y/o métodos organizados
para recopilar, procesar, transmitir datos que representan información. Un sistema de información
engloba la infraestructura, la organización, el personal y todos los componentes necesarios para la
recopilación, procesamiento, almacenamiento, transmisión, visualización, diseminación y organización
de la información”.2
 De acuerdo con el estándar ISO-12207, “se trata del marco de referencia que contiene todas las
implicaciones del desarrollo, la explotación y el mantenimiento de un producto de software”.
1 SENN, James A. (1992) Análisis y Diseño de Sistemas de Información. Segunda Edición. Editorial McGrawHill. México .
2
Cervantes Guerrero Alejandro. (2015, julio 20). Ciclo de vida de un sistema de información.

4
2. ETAPAS DEL CICLO DE VIDA DEL SISTEMA DE

INFORMACIÓN
A continuación, se muestra de manera general en que consiste cada una de las fases, las cuales puedes
visualizar y contextualizarlo en el ámbito profesional. Cuando analizamos podemos evocar a la escuela,
empresa u organización algún proyecto que ha involucrado los sistemas.
Ilustración 1 Etapas del Ciclo de Vida de los Sistemas de Información
Nacimiento
Muerte Desarrollo
Mantemiento Operación
Fuente: Cohen & Asín (2005, p.283)
1. Nacimiento
- Es el inicio
- Surgen los requerimientos del usuario
- Estudios de factibilidad
2. Desarrollo

5
- Análisis detallado de requerimientos

- Diseño del proyecto considerando factores como desarrollo, compra o adecuación
- Etapa de pruebas
3. Operación
- Etapa clave por la implementación del sistema

- El usuario lo opera para conocer áreas de oportunidad
4. Mantenimiento
- Si el usuario detecta fallas, entra esta etapa

- Errores lógicos, de programación, etc.
- Entre menos trabajo aquí, menos trabajo de análisis de hizo.
5. Muerte
- Fase terminal, ya no útil o se debe reemplazar

- Cuando se hacen cambios radicales se debe iniciar el ciclo nuevamente
3. FACTORES O VARIABLES DETERMINANTES
Como cualquier proyecto en donde intervienen diversos elementos, hay factores que tienen un mayor peso que
otros dentro del desarrollo, en el ciclo de vida de los sistemas de información, Cohen y Asín (2005, p.284),
consideran que son 4 los que cumplen esta función:
1. La calidad.
2. Las especificaciones del usuario.
3. Las especificaciones del Tiempo.
4. Las especificaciones de Recursos.

6
- CALIDAD
No podemos concebir crear un sistema de información para que no ayude a la empresa, para que detenga el
proceso de producción o disminuyan las guanacias verdad, así que debemos cuidar que la calidad sea tangible
desde el instante que el gerente necesita información y entra al sistema a buscarla, y buscar no significa
“pelearse” con la computadora, que el proceso sea claro, sencillo y de los resultados esperados y un poco más.
Te imaginas con un solo clic saber las ventas que tiene nuestro empleado Noé en este día, en el mes, en el
año, en su tiempo de estar laborando con nosotros; y que con otro clic vea una tabla comparativa con sus
compañeros de zona, de estado o a nivel nacional, fabuloso verdad?, eso puede ser calidad; pero no olvidemos
que la calidad debe entrar, ser procesada y saldrá algo con calidad; es decir, si capturamos datos falsos,
erróneos, es lo mismo o peor los resultados que obtendremos.
- ESPECIFICACIONES DEL USUARIO
Dice un refrán popular: “Ni todo el amor, ni todo el dinero”, es decir, lo justo, lo exacto. Realizamos una reunión
con ellos, registramos lo que requieren, ¿qué datos necesitan para trabajar?, ¿quién lo proporciona?, ¿con qué
características?, hablamos de información, de datos, no necesariamente de cuestiones físicas pero que es casi
seguro, que al final se ve involucrado algún informe, un reporte, una gráfica o un archivo. Es importante
considerar que Sommerville (2005, p.110) menciona que “estos requerimientos funcionales del usuario definen
los recursos específicos que el sistema debe proporcionar.”
- ESPECIFICACIONES DE TIEMPO
Es tan importante cumplir en forma y tiempo todo proyecto, así que el ciclo de vida de un sistema, en su etapa
de desarrollo, debe ser muy puntual cuando empieza, cuando termina, agendar y acordar reuniones de trabajo,
entregas intermedias, revisiones, dar a conocer a los involucrados del proceso los tiempos necesarios para
saber si este factor no es tan determinante como para no hacerlo. Cabe mencionar que en este punto es
necesario realizar diagrama en el que se especifiquen y determinen las actividades a realizar y el tiempo que
duran, además al realizar este diagrama se considera un margen de error por ello de acuerdo a los tiempos
establecidos se consideran algunos días o semanas más para algunas etapas.
- ESPECIFICACIONES DE RECURSOS
Cuando se realiza un proyecto, uno de los aspectos más importantes son los recursos, ello es debido a que el
factor de los costos es esencial para definir y determinar el proyecto, imagina, si un proyecto lo cobras en 5
pesos y realmente te gastas 10, el mismo no es redituable; por eso es relevante especificar y determinar los
costos que se tendrán en el proyecto. Otros recursos no menos importantes son las personas y el equipo
involucrado en el mismo, todos los recursos que sean necesarios para el proyecto se cuantifican y especifican.

7
4. MÉTODOS PARA ADQUIRIR UN SISTEMA
¿Cómo adquirir un sistema?
Aun cuando no existe una receta exacta para este aspecto, las empresas deben considerar que hay diversas
maneras de hacerlo, deben elegir el que mejor se adecúe a sus necesidades de entrada, después deben
analizarse los que ofrecen un valor agregado y por supuesto ver siempre a futuro; algunas soluciones son
momentáneas y para algo demasiado particular. Yo lo veo algo así como un sastre; requerimos un traje para
fiesta de un amigo y pensamos en las opciones:
A. Ir a una tienda departamental y comprarnos uno de línea.

B. Ir con un sastre y que nos haga uno a la medida y casi, casi único.
C. Usar el saco café a cuadros que tengo y el pantalón café liso de mi traje.
¿Te imaginas las ventajas y las desventajas de cada caso? ¿El precio es un factor importante, no cuestan lo
mismo verdad? Otro factor, el tiempo mientras con la opción A, lo tenemos casi de inmediato, con el sastre
tardamos un poco más; o la opción C. que, si bien no es nada nuevo, lo tengo a la mano y listo para hoy mismo.
Así pasa en las organizaciones con los sistemas, cuando requieren adquirir alguno tienen algunas opciones:
A. Ser desarrollado por gente de la misma organización. Debe darse por entendido que tiene un departamento
de sistemas y gente especializada o al menos con muy buenos conocimientos para ello. A este método de
adquisición de sistemas Cohen & Asín (2008, p. 285) lo llaman “El método tradicional”.
B. Comprar un sistema o paquete comercial que tenga quizás la opción de algunas modificaciones o
adecuaciones que pueda requerir su empresa. En este renglón existen muchas marcas pero quizás la que
mayor auge ha tenido y tendrá por un buen rato en México, es SAP. A este método de adquisición de sistemas
Cohen & Asín (2008, p.285) lo llaman “La compra de paquetes”.
C. Contratar una empresa o personas externas que lo desarrollen, se le conoce como: outsourcing. A este
método de adquisición de sistemas Cohen & Asín (2008, p. 285) lo clasifica dentro de “El método tradicional”.
D. La más sencilla, que no requiere una mayor cantidad de inversión por parte de la organización, pero que si
no es bien aplicada puede ser muy costosa al final, es que el usuario haga su propio sistema, utilice una hoja
electrónica, unas tablas, una pequeño manejador de bases de datos que él sepa y esto es que desarrolle sus
propias aplicaciones que en muchos casos no son ni remotamente los necesarios o más útiles para la empresa.
A este método de adquisición de sistemas Cohen & Asín (2008, p.286) lo llaman “El cómputo del usuario final”.
Uno de los métodos de adquisición de sistemas más utilizado es el método tradicional, en el cual ya sea dentro
de la empresa o por medio del uso de empresas externas (outsourcing) se desarrolla un sistema especializado

8
para la organización, estos sistemas comúnmente son conocidos como sistemas a la medida, ello es porque
se realiza con base a las necesidades de la organización.
Par desarrollar éstos sistemas, es requerido llevar a cabo diferentes fases, las cuales varían de acuerdo a
diferentes autores, en esta parte podremos encontrar discrepancia entre los mismos, ello se debe a que existen
diferentes metodologías para el desarrollo de sistemas de información, en la siguiente tabla se muestran las
fases que integran el desarrollo de sistemas de información, que nos ofrece Alarcón (2006, p.41):
Tabla 1. Relación entre etapas y fases en el desarrollo de un sistema
FASES ETAPAS
Planificación del Sistema Planificación
Análisis del sistema actual
Análisis de requerimientos Análisis de sistemas
Diseño Lógico
Diseño Físico Diseño de sistemas
Fuente: Alarcón, 2006, p. 41
De igual forma podemos mencionar otra metodología que ha sido muy socorrida por las personas que se
relacionan con los sistemas informáticos y es de James A. Senn (cit. por Alarcón, 2006) define el ciclo de vida
del desarrollo de sistemas como “el conjunto de actividades que los analistas, diseñadores y usuarios realizan
para desarrollar e implantar un sistema de información”.
Tabla 2. Ciclo de vida del desarrollo de sistemas
Ciclo de vida del desarrollo de sistemas

Investigación preliminar
Diseño del sistema
Desarrollo del software
Prueba de los sistemas
Implantación y evaluación
Fuente: Senn, 1992
Así mismo Cohen & Asín (2005, p.287), menciona que las fases de las que consta el método tradicional son
las que se muestran en la Ilustración 3. “Fases para el desarrollo de sistemas”.

9
Ilustración 2. Fases para el desarrollo de sistemas
Fuente: Cohen & Asín, 2005, p. 287
Como se ha observado existen diferentes metodologías para la realización de un sistema, teniendo estas
consideraciones y tomando en cuenta la más completa, se desarrollarán las fases que Cohen y Asín (2005),
mencionan, por ello ahondaremos en cada una de las etapas que se han mencionado y las cuales se describen
en la Ilustración 4. “Descripción de las fases”.
1. FACTIBILIDAD
Se realiza un estudio detallado para determinar la factibilidad del proyecto, es decir si es viable o no,
ya que en este análisis se consideran los aspectos técnicos y económicos.
2. ANÁLISIS
Se determinan las especificaciones de los requerimientos que tienen los usuarios para el sistema (se
definen los datos que son necesarios para la operación del sistema y el tipo de información que se va
a generar). Además, se hace una proyección de los recursos que se requieren y finalmente, se hace
un cronograma en el que se especifican las actividades a realizar y la duración de las mismas.
3. DISEÑO
Se traduce el análisis a programación.
4. PROGRAMACIÓN
Se elaboran los programas que se consideraron en el diseño del sistema de información.
5. PRUEBAS
Se experimenta el funcionamiento del sistema para verificar que no existan errores de programación,
ni lógicos; en este paso se realiza una prueba del sistema con diferentes usuarios.
6. IMPLANTACIÓN
Es la instalación del sistema en el lugar en que se va a operar, con la finalidad de realizar la operación
del mismo en su medio real.
7. OPERACIÓN
Funcionamiento del sistema en el medio ambiente real y con datos verdaderos.

10
5. PRINCIPIOS GENERALES DEL CICLO DE VIDA DE

DESARROLLO DE SISTEMAS
- Implicar al usuario
Es importante estar claro que el sistema a ser desarrollado le pertenece al usuario del sistema, el
analista es simplemente un experto en tecnología de la información que viene a resolver uno o varios
problemas puntuales de procesamiento de información; comprometer al usuario permite evitar errores
en la construcción del sistema, además que ayuda a vencer el miedo al cambio que toda persona tiene
al momento que un nuevo sistema es instalado, y siempre se debe recordar ellos son los que pagan.
- Se deben Apoyar las actividades de la Organización
Toda organización debe tener una Visión y Misión específica, las cuales son su constante motivación;
así la Administración es encargada de definir las Políticas, Normas, Metas y Estrategias para cumplir
con esos principios, de tal manera que cuando se desarrollan los sistemas de información ellos se
deben desarrollar para servir de apoyo a la alta gerencia y a la toma de decisiones con lo cual se
garantiza la productividad de la Organización.
- Aplicar un método de resolución de problemas
En el momento que el analista estudia la situación actual se encuentra con: normas, reglamentos,
oportunidades, amenazas, actividades, personas, documentos, es decir, el medio ambiente en general
que rodea un sistema; para desarrollar una solución de sistemas en forma eficiente se debe usar un
método, con el cual se busca evitar que se pierdan detalles en la construcción de un nuevo sistema;
así El Ciclo de Vida de Desarrollo de Sistemas es ante todo un método para resolver problemas, que
le permite al analista estudiar en detalle la situación actual y construir en detalle una solución, el cual
consta de las siguientes actividades:
A. Investigación preliminar
B. Determinación de los requerimientos del sistema
C. Diseño del sistema
D. Desarrollo de software
E. Prueba de los sistemas
F. Implantación y evaluación
En términos generales dichas fases o actividades se pueden resumir en:
A. Análisis

11
B. Diseño
C. Desarrollo de Software
D. Implantación
Ilustración 3. Fases del Sistema de Información
Análisis Diseño Desarrollo de Implantación

Software
SISTEMA DE INFORMACIÓN
Fuente. Elaboración propia.
- Justificar los sistemas como una inversión de capital
Los sistemas de información son ante todo una inversión de capital, pues los propietarios o la
organización deben pagar: luz, agua, teléfono, personal, discos, hojas, etc.…para su realización; es
por ello que todo analista de sistemas debe plantearse de ante un nuevo sistema:
Primero, para cualquier problema es probable que existan varias soluciones, y segundo se debe evaluar
la viabilidad de cada una de ellas.
El analista debe tener presente esas premisas, pues, ninguna organización invierte para no recoger
esa inversión a un corto o mediano plazo.
- Diseñar el sistema para el crecimiento
La vida útil de un nuevo sistema debe ser visto como una solución a largo plazo, por lo tanto debe ser
diseñado para que progresivamente el sistema se vaya adaptando a los cambios planteados por los
usuarios a los datos, por ejemplo: ingresar nuevos productos, cambiar niveles de seguridad, entre otros;
de tal manera que se evite la entropía del sistema.

12
6. MODELO DE CICLO DE VIDA DE UN SISTEMA
6.1 MODELO CLÁSICO O CASCADA
El ciclo de vida de un sistema de información comprende todos los procedimientos ocurrentes desde el
nacimiento de la necesidad de obtener un sistema hasta la sustitución por uno nuevo, por ende el sistema se
desarrolla con el objetivo de satisfacer un conjunto de necesidades de los clientes, entonces para que el sistema
garantice su adecuado cumplimiento en su objetivo, es necesario aplicar distintas etapas del ciclo de vida de
desarrollo de un sistema , siguiendo una metodología ,donde se indicará el orden y las actividades a
concretarse .
Por consiguiente, el ciclo de vida es necesario porque nos permite detectar los errores lo antes posible y permite
a los desarrolladores centrarse en el desarrollo del sistema junto con los plazos de implantación.
6.2 MODELO DE CICLO DE VIDA INCREMENTAL
El modelo incremental se basa en la filosofía de construir incrementando las funcionalidades del sistema.
mediante este modelo cada ciclo que se realiza va obteniendo una porción de producto, servicio o resultado
completa. A cada porción generada en una iteración se le denomina incremento.
Es decir, vamos produciendo porciones del resultado del proyecto que están acabadas al 100% e iteramos
hasta tener todas las porciones, esto es, todo el resultado esperado.
Según Cantone cuando se utiliza el modelo incremental el sistema de “realiza construyendo por módulos que
cumplen las diferentes funciones del sistema. Eso permite ir aumentando gradualmente las capacidades del
software. Este ciclo de vida facilita la tarea del desarrollo permitiendo a cada miembro del equipo desarrollar un
módulo particular en el caso de que el proyecto sea desarrollado por un equipo de programadores”
El ciclo de vida incremental también puede definirse como: “Desarrollar por partes el producto software, para
después integrarlas a medida que se completan. Un ejemplo de un desarrollo puramente incremental puede
ser la agregación de módulos en diferentes fases. El agregar cada vez más funcionalidad al sistema” (Garzas,
2012, pág. 1).
Podemos decir que el modelo incremental el desarrollo de un sistema se realiza por módulos o partes, que
después de terminado el desarrollo de estas partes se unen para formar el sistema 100% completo, estas
partes pueden ser desarrolladas por diferentes desarrolladores, y cada vez que se agrega un módulo al sistema
se agrega mas funcionalidades. Se puede afirmar que cada módulo tiene diferente funcionalidad.

13
Ilustración 4. Modelo Iterativo Incremental (Gutiérres, 2013)
Fuente:http://cursos.aiu.edu/Ingenieria%20de%20Software%20Avanzada/PDF/Tema%202.pdf
El Grafico 4 nos muestra en forma muy esquemática, el funcionamiento de un Ciclo Iterativo Incremental, el
cual permite la entrega de versiones parciales a medida que se va construyendo el producto final. Es decir, a
medida que cada incremento definido llega a su etapa de operación y mantenimiento. Cada versión emitida
incorpora a los anteriores incrementos las funcionalidades y requisitos que fueron analizados como necesarios.
El Incremental es un modelo de tipo evolutivo que está basado en varios ciclos Cascada realimentados
aplicados repetidamente, con una filosofía iterativa.
PROCESO DEL MODELO INCREMENTAL
Marichelo plantea que el proceso de Ciclo de vida incremental se divide en 4 partes:
Análisis
Diseño
Código
Prueba
Marichelo afirma que:
El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del sistema, seguido de
sucesivos incrementos funcionales. Cada incremento tiene su propio ciclo de vida y se basa en el anterior, sin
cambiar su funcionalidad ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre el
mismo, sino únicamente corrección de errores. Dado que la arquitectura completa se desarrolla en la etapa
inicial, es necesario conocer los requerimientos completos al comienzo del desarrollo (Marichelo, 2016).
3
http://cursos.aiu.edu/Ingenieria%20de%20Software%20Avanzada/PDF/Tema%202.pdf

14
Ilustración 5. Modelo Incrementar de 4 partes (Marichelo, 2016)
Fuente:http://marich.blogspot.es/1459223366/modelo-incremental/
Gutiérrez para el modelo incremental afirma se divide en 6 actividades:
- Análisis
- Diseño
- Código
- Prueba
- Integración
- Operación
En la Grafico 5 se muestra un refino del diagrama previo, bajo un esquema temporal, para obtener finalmente
el esquema del Modelo de ciclo de vida Iterativo Incremental, con sus actividades genéricas asociadas. Aquí
se observa claramente cada ciclo cascada que es aplicado para la obtención de un incremento; estos últimos
se van integrando para obtener el producto final completo. Cada incremento es un ciclo Cascada Realimentado,
aunque, por simplicidad, en la figura 5 se muestra como secuencial puro.
Ilustración 6. Modelo Iterativo Incremental para el ciclo de vida del software (Gutiérrez, 2013)
4
http://marich.blogspot.es/1459223366/modelo-incremental/ [Consultado el 20 de setiembre del 2019]

15
Se observa que existen actividades de desarrollo (para cada incremento) que son realizadas en paralelo o
concurrentemente, así, por ejemplo, en la figura, mientras se realiza el diseño detalle del primer incremento
ya se está realizando en análisis del segundo.
El momento de inicio de cada incremento es dependiente de varios factores: tipo de sistema; independencia o
dependencia entre incrementos (dos de ellos totalmente independientes pueden ser fácilmente iniciados al
mismo tiempo si se dispone de personal suficiente); capacidad y cantidad de profesionales involucrados en el
desarrollo; etc.
Bajo este modelo se entrega software “por partes funcionales más pequeñas”, pero reutilizables, llamadas
incrementos. En general cada incremento se construye sobre aquel que ya fue entregado.
Luego de cada integración se entrega un producto con mayor funcionalidad que el previo. El proceso se repite
hasta alcanzar el software final completo.
Siendo iterativo, con el modelo Incremental se entrega un producto parcial pero completamente operacional en
cada incremento, y no una parte que sea usada para reajustar los requerimientos (como si ocurre en el Modelo
de Construcción de Prototipos).
El enfoque Incremental resulta muy útil con baja dotación de personal para el desarrollo; también si no hay
disponible fecha límite del proyecto por lo que se entregan versiones incompletas pero que proporcionan al
usuario funcionalidad básica (y cada vez mayor). También es un modelo útil a los fines de valuación.
Como se dijo, el Iterativo Incremental es un modelo del tipo evolutivo, es decir donde se permiten y esperan
probables cambios en los requisitos en tiempo de desarrollo; se admite cierto margen para que el software
pueda evolucionar. Aplicable cuando los requisitos son medianamente bien conocidos, pero no son
completamente estáticos y definidos, cuestión es que si es indispensable para poder utilizar un modelo
Cascada.
El modelo es aconsejable para el desarrollo de software en el cual se observe, en su etapa inicial de análisis,
que posee áreas bastante bien definidas a cubrir, con suficiente independencia como para ser desarrolladas
en etapas sucesivas.
Tales áreas para cubrir suelen tener distintos grados de apremio por lo cual las mismas se deben priorizar en
un análisis previo, es decir, definir cuál será la primera, la segunda, y así sucesivamente; esto se conoce como
“definición de los incrementos” en base a priorización.
Pueden no existir prioridades funcionales por parte del cliente, pero el desarrollador debe fijarlas de todos
modos y con algún criterio, ya que en base a ellas se desarrollarán y entregarán los distintos incrementos.
El hecho de que existan incrementos funcionales del software lleva inmediatamente a pensar en un esquema
de desarrollo modular, por tanto, este modelo facilita tal paradigma de diseño.
En resumen, un modelo Incremental lleva a pensar en un desarrollo modular, con entregas parciales del
producto software denominados “incrementos” del sistema, que son escogidos en base a prioridades
predefinidas de algún modo.
El modelo permite una implementación con refinamientos sucesivos (ampliación y/o mejora). Con cada
incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versión
previamente implementada del producto software.

16
Este modelo brinda cierta flexibilidad para que durante el desarrollo se incluyan cambios en los requisitos por
parte del usuario, un cambio de requisitos propuesto y aprobado puede analizarse e implementarse como un
nuevo incremento o, eventualmente, podrá constituir una mejora/adecuación de uno ya planeado.
La selección de este modelo permite realizar entregas funcionales tempranas al cliente (lo cual es beneficioso
tanto para él como para el grupo de desarrollo). Se priorizan las entregas de aquellos módulos o incrementos
en que surja la necesidad operativa de hacerlo, por ejemplo, para cargas previas de información, indispensable
para los incrementos siguientes.
El modelo Iterativo Incremental no obliga a especificar con precisión y detalle absolutamente todo lo que el
sistema debe hacer, (y cómo), antes de ser construido (como el caso de la cascada, con requisitos congelados).
Sólo se hace en el incremento en desarrollo. Esto torna más manejable el proceso y reduce el impacto en los
costos.
Esto es así, porque en caso de alterar o rehacer los requisitos, solo afecta una parte del sistema. Aunque,
lógicamente, esta situación se agrava si se presenta en estado avanzado, es decir en los últimos incrementos.
En definitiva, el modelo facilita la incorporación de nuevos requisitos durante el desarrollo.
Con un paradigma Incremental se reduce el tiempo de desarrollo inicial, ya que se implementa funcionalidad
parcial. También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas
del software.
El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas
sólo al ámbito de cada incremento.
El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad,
de procesamiento distribuido, y/o de alto índice de riesgos.
CARACTERISTICAS
Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia.
El usuario se involucra más.
Difícil de evaluar el costo total.
Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.
Requiere gestores experimentados.
Los errores en los requisitos se detectan tarde.
El resultado puede ser positivo.
Cada incremento agrega funcionalidad adicional o mejorada sobre el sistema.
Cada etapa debe cumplir con los requisitos de las desarrolladas.
La propuesta del modelo es diseñar sistemas que puedan entregarse por piezas.

17
A partir de la evaluación se planea el siguiente incremento y así sucesivamente.
Es interactivo por naturaleza.
Es útil cuando el personal no es suficiente para la implementación completa.
En lugar de entrega del sistema en una sola entrega, el desarrollo y la entrega están fracturados bajo
incrementos, con cada incremento que entrega parte de la funcionalidad requerida.
VENTAJAS
Los clientes no tienen que esperar hasta que el sistema se entregue completamente para comenzar a
hacer uso de él.
Los clientes pueden usar los incrementos iniciales como prototipo para precisarlos requerimientos
posteriores del sistema.
Minimización del riesgo de falla en el proyecto porque los errores se van corrigiendo progresivamente.
El resultado puede ser muy positivo.
DESVENTAJAS
Difícil de aplicar a sistemas transaccionales que tienden a ser integrados y a operar como un todo.
Riesgos largos y complejos.
Pueden aumentar el coste debido a las pruebas.
Los errores en los requisitos se detectan tarde
El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de
seguridad, de procesamiento distribuido y/o de alto índice de riesgos.
Requiere de mucha planeación, tanto administrativa como técnica.
Requiere de metas claras para conocer el estado del proyecto.

18
6.3 MODELO DE PROTOTIPADO DE REQUERIMIENTOS
Para el desarrollo de software podemos definir a un prototipo como un modelo el cual podemos utilizar para
generar y diseñar una actividad que nos permita crear un diseño rápido en la construcción de un software.
“El prototipado de requerimientos es la creación de una implementación parcial de un sistema, para el propósito
explícito de aprender sobre los requerimientos del sistema” (Olvany Torres, 2017). Un prototipo es construido
de una manera rápida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos,
posibilitando que ellos experimenten con el prototipo. Estos individuos luego proveen la retroalimentación sobre
lo que a ellos les gustó y no les gustó acerca del prototipo proporcionado, quienes capturan en la documentación
actual de la especificación de requerimientos la información entregada por los usuarios para el desarrollo del
sistema real. El prototipado puede ser usado como parte de la fase de requerimientos (determinar
requerimientos) o justo antes de la fase de requerimientos (como predecesor de requerimientos). En otro caso,
el prototipado puede servir su papel inmediatamente antes de algún o todo el desarrollo incremental en modelos
incremental o evolutivo.
El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el
cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los
despliegues de salida). El diseño rápido conduce a la construcción de un prototipo, el cual es evaluado por el
cliente o el usuario para una retroalimentación; gracias a ésta se refinan los requisitos del software que se
desarrollará (Gutiérres, 2013, pág. 7).

19
Ilustración 7. Modelo prototipado de requerimientos
Fuente: Elaboración propia
1. Comunicación:
tener una interacción con el cliente para evaluar la petición del software y determinar si el programa a desarrollar
es un buen candidato para construir un prototipo. Debido a que el cliente debe interaccionar con el prototipo
para determinar el refinamiento del proyecto
2. Plan rápido:
cuando se tienen que los resultados de un proyecto son aceptables, se procede a desarrollar una
representación abreviada de los requerimientos. Antes de que pueda comenzar la construcción de un prototipo,
en este se debe representar los dominios funcionales y de información del programa. La aplicación de estos
principios de análisis fundamentales, pueden realizarse mediante los métodos de análisis de requerimientos.
3. Modelado diseño rápido:

Después de que se haya revisado la representación de los requerimientos, se crea un conjunto de
especificaciones de diseño abreviadas para el prototipo. El diseño debe ocurrir antes de que comience la
construcción del prototipo. Sin embargo, el diseño de un prototipo se enfoca normalmente hacia la arquitectura
a nivel superior y a los aspectos de diseño de datos.
4. Construcción de prototipo:
El software del prototipo se crea, prueba y se corrigen Idealmente todos los posibles errores, los bloques de
construcción de software preexisten se utilizan para crear el prototipo de una forma rápida y se determina si un

20
prototipo es funcional o no. Para las aplicaciones interactivas con el hombre, es posible frecuentemente crear
un prototipo en papel que describa la interacción hombre-maquina.
5. Desarrollo y entrega:
Una vez que el prototipo ha sido probado, se presenta al cliente, el cual "conduce la prueba" de la aplicación y
sugiere modificaciones. Este paso es el núcleo del método de construcción de prototipo. Es aquí donde el
cliente puede examinar una representación implementada de los requerimientos del programa, sugerir
modificaciones que harán al programa cumplir mejor las necesidades reales.
VENTAJAS
 Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no
identifica los requisitos detallados de entrada, procesamiento o salida.
 También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro
de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que
debería tomar la interacción humano-máquina.
DESVENTAS
 El cliente ve funcionando lo que para él es la primera versión del prototipo que ha sido construido
con “plastilina y alambres”, y puede desilusionarse al decirle que el sistema aún no ha sido
construido.
 El desarrollador puede ampliar el prototipo para construir el sistema final sin tener en cuenta los
compromisos de calidad y de mantenimiento que tiene con el cliente.
EJEMPLO DE MODELO PROTOTIPADO DE REQUERIMIENTOS
puede iniciar con una serie de requerimientos que son proporcionados por el cliente y los usuarios,
posteriormente se analizarán las distintas alternativas, pantallas, tablas, informes, entre otras salidas del
sistema que serán utilizadas directamente por los usuarios y clientes, cuando el cliente y el usuario están en
mutuo acuerdo en lo que desean, los desarrolladores proceden con la etapa de diseño que se centra en la
representación de los aspectos del software que serán visibles para el cliente o el usuario final, este diseño nos
conduce a la construcción de un prototipo, también se analizaran las alternativas del mismo hasta que el
desarrollador y principalmente los usuarios y los clientes estén satisfechos con el resultado.

21
Ilustración 8. Requerimientos del Usuario (Olvany 2017)
Fuente: https://asiup.files.wordpress.com/2017/04/metodologia-prototipos
Suele presentarse el caso en el que los involucrados están inconformes con el diseño, es por esto que se
retorna a las actividades de requerimientos para que puedan ser reconsiderados y cambiados hasta lograr un
acuerdo; el prototipo es evaluado por el cliente y el usuario y mediante la retroalimentación.

22
Ilustración 9. Revisión de los requerimientos
Fuente:https://asiup.files.wordpress.com/2017/04/metodologia-prototipos.pdf
Se mejoran los requisitos del software que se desarrollará y mediante este proceso satisfacer las necesidades
del cliente y al mismo tiempo lograr que el desarrollador entienda con más claridad lo que debe hacer.
Finalmente se construye el prototipo aplicando herramienta. Se analizan sus alternativas y puede darse el caso
en el que se repita todo el proceso anterior. No obstante, a los usuarios les agrada visualizar un sistema real,
y a los desarrolladores les gusta construir algo de manera inmediata, analizando este ejemplo los
desarrolladores establecen compromisos de implementación para lograr que el prototipo funcione con rapidez,
utilizando lenguajes conocidos y porque están disponibles pero que es inadecuado, puede darse el caso que
el usuario se familiarice con dicha aplicación y no considera que es inapropiado. La clave está en establecer
las reglas desde el principio en las que el cliente y el desarrollador estén de acuerdo en que la elaboración del
prototipo sirva para el desarrollo de un software real con un enfoque hacia la calidad principalmente.

23
6.4 MODELO DE DESARROLLO EVOLUTIVO
Propuesto por Mills en 1980. Sugirió el enfoque incremental de desarrollo como una forma de reducir la
repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los
requisitos hasta adquirir experiencia con el sistema. Surge porque en los primeros desarrollos se podía esperar
largo tiempo hasta que el software estuviese listo. Las reglas del negocio de hoy no lo permiten.
Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un sistema inicial se desarrolla
rápidamente a partir de especificaciones abstractas. Éste se refina basándose en las peticiones del cliente para
producir un sistema que satisfaga sus necesidades. Consta del desarrollo de una versión inicial que luego de
exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del
usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de separarse.
“En los modelos evolutivos se produce un sistema rudimentario inicial que evoluciona según las necesidades
del cliente hasta cumplir con los requisitos últimos de éste. Al no requerir pre-especificaciones detalladas
tampoco exige una costosa producción de documentación por etapas”. (PTOLOMEO)
CARACTERÍSTICAS
 Surge porque en los primeros desarrollos se podía esperar largo tiempo hasta que el software estuviese
listo.
 Permiten desarrollar versiones cada vez más completas y complejas, hasta llegar al objetivo final
deseado.
 Se asume que NO todos los requerimientos son conocidos desde el primer momento.
 Es muy similar al modelo de desarrollo incremental.
 En una primera fase, se desarrolla la primera versión, que recoge los requisitos conocidos.
 Posteriormente, los usuarios utilizan el software desarrollado, generándose una nueva lista de
requerimientos, con la que se desarrolla una nueva versión en la siguiente fase y así sucesivamente.
 El usuario ve la materialización del proyecto más rápido que si hubiera que hacer un estudio largo para
concretar las especificaciones. Además, puede modificar/añadir requerimientos sin afectar al proyecto
y conseguir algo que se ajuste mejor a sus necesidades
 Es un modelo compatible con el modelo de cascada y puede ser combinado con el modelo incremental.
FASES DEL MODELO EVOLUTIVO
1. Formulación de un esquema (Especificación Inicial) de los requisitos del sistema como guía para los
programadores
2. Desarrollo de un sistema (Desarrollo del producto), tan rápido como sea posible, basado en las
especificaciones anteriores.
3. Evaluación y modificación (Implementación, uso y evaluación) del sistema según vayan así
especificándolo los propios usuarios.
4. Re-especificaciones. Se re-difine el problema en base a los nuevos requerimientos.

24
Ilustración 10. Modelo de ciclo de vida Evolutivo
Fuente: http://www.angelfire.com/ab8/morro/CICLO_DES.htm
EXISTEN 2 TIPOS DE DESARROLLO EVOLUTIVO:
1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para explorar sus
requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se
comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.
2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es comprender los
requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el
sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se
comprenden del todo.

25
DIFERENCIAS
a) Evolutivo: Se diferencia del modelo por prototipos en que en prototipos se da por hecho que, aunque
se necesiten varias iteraciones para lograrlo al final se llegará a tener una serie de requisitos completos
y sin errores, que no vayan a cambiar más.
En el modelo evolutivo se asume que los requisitos pueden cambiar en cualquier momento del ciclo de
vida y no solo en la etapa de análisis.
b) Incremental: Es una aproximación muy parecida a la evolutiva. En este modelo se desarrolla el sistema
para satisfacer un subconjunto de los requisitos especificados y en posteriores versiones se incrementa
el programa con nuevas funcionalidades que satisfagan más requisitos.
En el caso del modelo evolutivo se desarrollaría una nueva versión de todo el sistema, en el incremental
se parte de la versión anterior sin cambios y le añadimos las nuevas funciones.
VENTAJAS
 La especificación puede desarrollarse de forma creciente.

 Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora
de la calidad del software.
 Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.
 Hay que implicar a los usuarios.
DESVENTAJAS
 Es difícil predecir el coste y duración de un proyecto, por lo que es conveniente limitar el número de
fases, recursos y plazos si es un proyecto con principio y fin.
 Puede resultar costoso si hay que reiniciar el desarrollo.
 Hay que mantener muy bien la documentación del proyecto para facilitar el control de versiones y su
mantenimiento
 Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca
gente sabe utilizar.

26
6.5 MODELO EN ESPIRAL

El modelo en espiral fue propuesto primeramente por Boehm, es un modelo de desarrollo de sistemas
evolutivos, por lo que combina la naturaleza iterativa de la construcción de prototipos con aspectos del modelo
lineal secuencial, proporciona la característica de permitir el desarrollo de forma rápida de versiones
incrementales.
Se utiliza con éxito en proyectos donde el coste de un fallo es un gran riesgo, de ahí que su principal aportación
sea considerar la gestión de esos riesgos, algo que en los modelos anteriores ni siquiera se menciona.
Acuna (2005) dice: En concreto, los proyectos ejecutados con el modelo en espiral empiezan siendo pequeños,
investigando los mayores riesgos que se pueden tolerar, para pasar a agrandarse poco a poco, en base a
elementos clave sobre los que se construyen las siguientes fases de la espiral. Habitualmente tiene sentido
aplicar este método en proyectos grandes, largos, caros y complejos. (pg. 75)
PASOS DEL MODELO EN ESPIRAL
(Boehm, 1988) El modelo espiral del software es un modelo meta del ciclo de vida del software donde el
esfuerzo del desarrollo es iterativo, tan pronto culmina un esfuerzo del desarrollo por ahí mismo comienza otro;
además en cada ejecución del desarrollo se sigue cuatro pasos principales.
1. Determinar o fijar los objetivos. En este paso se definen los objetivos específicos para posteriormente
identifica las limitaciones del proceso y del sistema de software, además se diseña una planificación
detallada de gestión y se identifican los riesgos.
2. Análisis del riesgo. En este paso se efectúa un análisis detallado para cada uno de los riesgos
identificados del proyecto, se definen los pasos a seguir para reducir los riesgos y luego del análisis de
estos riesgos se planean estrategias alternativas.
3. Desarrollar, verificar y validar. En este tercer paso, después del análisis de riesgo, se eligen un paradigma
para el desarrollo del sistema de software y se lo desarrolla.
4. Planificar. En este último paso es donde el proyecto se revisa y se toma la decisión si se debe continuar
con un ciclo posterior al de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente
fase del proyecto.

27
Ilustración 11. Modelo de desarrollo en espiral (Boehm 1988).
Fuente: http://avellano.usal.es/~mmoreno/ASTema2.pdf
Existe un segundo enfoque del modelo en espiral es el enfoque más realista actualmente y este fue dada por
Pressman.
El modelo en espiral esta compartida en varias actividades estructurales, también llamadas regiones de tareas.
Existen seis regiones de tareas que son: (Pressman, 1990)
1. Comunicación con el cliente: esta es una tarea requerida para establecer comunicación entre el
desarrollador y el cliente.
2. Planificación: esta tarea es necesaria aplicarla para poder definir los recursos, el tiempo y otras
informaciones relacionadas con el proyecto, es decir, son todos los requerimientos.
3. Análisis de riesgos: esta es una de las tareas principales por lo que se aplica el modelo en espiral, es
requerida para evaluar los riesgos técnicos y otras informaciones relacionadas con el proyecto.
4. Ingeniería: esta es una tarea necesaria ya que se requiere construir una o más representaciones de la
aplicación.
5. Construcción y adaptación: esta tarea es requerida en el modelo espiral porque se necesita construir,
probar, instalar y proporcionar soporte al usuario.

28
6. Evaluación el cliente: esta también es una tarea principal, necesaria para adquirir la reacción del cliente
según la evaluación de las representaciones del software creadas durante la etapa de ingeniería y la de
implementación creada durante la etapa de instalación.
Cada región de tareas tiene una serie de tareas que permiten adaptarse a las características del sistema que
se desarrolla. Cuando se desarrolla un sistema pequeño, el número de tareas y su formalidad es baja, sin
embargo, en sistemas grandes se definen tareas para lograr un mayor nivel de formalidad.
Al empezar este modelo el desarrollador debe empezar en la dirección de las manecillas del reloj, comenzando
en el centro de la espiral. El primer circuito genera una especificación del sistema, los siguientes circuitos se
desarrollan un prototipo del sistema y posteriormente versiones más sofisticadas del sistema.
Ilustración 12. Modelo de desarrollo en espiral (Pressman 2002).
Fuente: http://avellano.usal.es/~mmoreno/ASTema2.pdf
CARACTERÍSTICAS DEL MODELO EN ESPIRAL PARA EL DESARROLLO DE

SOFTWARE
Es considerado como un modelo evolutivo ya que combina el modelo clásico con el diseño de prototipos.
Contiene una nueva etapa que es el análisis de riesgos, no incluida anteriormente. Este modelo es el indicado
para desarrollar software con diferentes versiones actualizadas como se hace con los programas modernos de
PC´s. La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de construcción de prototipos.

29
VENTAJAS DEL MODELO ESPIRAL
- No requiere una definición completa de los requerimientos del software a desarrollar para comenzar su
funcionalidad.
- En la terminación de un producto desde el final de la primera iteración es muy factible aprobar los requisitos.
- Sufrir retrasos corre un riesgo menor, porque se comprueban los conflictos presentados tempranamente y
existe la forma de poder corregirlos a tiempo.
- Los factores de riesgo son reducidos.
- El desarrollo es iterativo y se pueden incorporar funcionalidades progresivamente.
DESVENTAJAS DEL MODELO ESPIRAL
- Existe complicación cuando se evalúa los riesgos.

- Se requiere la participación continua por parte del cliente.
- Se pierde tiempo al volver producir inicialmente una especificación completa de los requerimientos cuando
se modifica o mejora el software.
6.6 MODELO DE CONSTRUCCIÓN DE PROTOTIPOS

El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se construyan rápidamente para
comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador, el usuario, el
cliente estén de acuerdo en lo que se necesita así como también la solución que se propone para dicha
necesidad y de esta forma minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se encarga del
desarrollo de diseños para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas
especificaciones, es ideal para medir el alcance del producto, pero no se asegura su uso real. Este modelo
principalmente se lo aplica cuando un cliente define un conjunto de objetivos generales para el software a
desarrollarse sin delimitar detalladamente los requisitos de entrada procesamiento y salida, es decir cuando el
responsable no está seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la forma en que
interactúa el hombre y la máquina. Este modelo se encarga principalmente de ayudar al ingeniero de sistemas
y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén
satisfechos. (Lawrence, 2002)
Este modelo también es denominado modelo de desarrollo evolutivo. Los modelos evolutivos son iterativos; los
caracteriza la forma en que permiten que los ingenieros de software desarrollen versiones cada vez más
completas del software.

30
PASOS DEL MODELO DE LA CONSTRUCCION DE PROTOTIPOS
El paradigma de construcción de prototipos tiene los siguientes pasos:
1. Comunicación: tener una interacción con el cliente para evaluar la petición del software y determinar si el
programa a desarrollar es un buen candidato para construir un prototipo. Debido a que el cliente debe
interaccionar con el prototipo para determinar el refinamiento del proyecto.
2. Plan rápido: cuando se tienen que los resultados de un proyecto son aceptables, se procede a desarrollar
una representación abreviada de los requerimientos. Antes de que pueda comenzar la construcción de un
prototipo, en este se debe representar los dominios funcionales y de información del programa. La
aplicación de estos principios de análisis fundamentales, pueden realizarse mediante los métodos de
análisis de requerimientos.
3. Modelado diseño rápido: Después de que se haya revisado la representación de los requerimientos, se
crea un conjunto de especificaciones de diseño abreviadas para el prototipo. El diseño debe ocurrir antes
de que comience la construcción del prototipo. Sin embargo, el diseño de un prototipo se enfoca
normalmente hacia la arquitectura a nivel superior y a los aspectos de diseño de datos.
4. Construcción de prototipo: El software del prototipo se crea, prueba y se corrigen Idealmente todos los
posibles errores, los bloques de construcción de software preexisten se utilizan para crear el prototipo de
una forma rápida y se determina si un prototipo es funcional o no. Para las aplicaciones interactivas con el
hombre, es posible frecuentemente crear un prototipo en papel que describa la interacción hombre-
maquina.
5. Desarrollo y entrega: Una vez que el prototipo ha sido probado, se presenta al cliente, el cual "conduce la
prueba" de la aplicación y sugiere modificaciones. Este paso es el núcleo del método de construcción de
prototipo. Es aquí donde el cliente puede examinar una representación implementada de los requerimientos
del programa, sugerir modificaciones que harán al programa cumplir mejor las necesidades reales.
Ilustración 13. Modelo de construcción de prototipos
Fuente: http://ingenieriadesoftwareijeanneth.blogspot.com/2010/09/modelo-de-desarrollo-rapido-de.html

31
TIPOS DE MODELOS DE PROTOTIPOS

1. Modelo de Prototipos rápido: Metodología de diseño que desarrolla rápidamente nuevos diseños, los
evalúa y prescinde del prototipo cuando el próximo diseño es desarrollado mediante un nuevo prototipo.
2. Modelo de Prototipos reutilizable: También conocido como "Evolutionary Prototyping"; no se pierde el

esfuerzo efectuado en la construcción del prototipo pues sus partes o el conjunto pueden ser utilizados
para construir el producto real.
3. Modelo de Prototipos Modular: También conocido como Prototipo Incremental (Incremental prototyping);
se añaden nuevos elementos sobre el prototipo a medida que el ciclo de diseño progresa.
4. Modelo de Prototipos Horizontal: El prototipo cubre un amplio número de aspectos y funciones, pero la
mayoría no son operativas. Resulta muy útil para evaluar el alcance del producto, pero no su uso real.
5. Modelo de Prototipos Vertical: El prototipo cubre sólo un pequeño número de funciones operativas.
Resulta muy útil para evaluar el uso real sobre una pequeña parte del producto.
6. Modelo de Prototipos de Baja-fidelidad: El prototipo se implementa con papel y lápiz, emulando la

función del producto real sin mostrar el aspecto real del mismo. Resulta muy útil para realizar test baratos.
7. Modelo de Prototipos de Alta-fidelidad: El prototipo se implementa de la forma más cercana posible al
diseño real en términos de aspecto, impresiones, interacción y tiempo.
VENTAJAS DEL MODELO DE CONSTRUCCIÓN DE PROTOTIPOS

1. Permite la retroalimentación por parte del usuario.
2. Desarrollo rápido.
3. El usuario se siente parte del grupo.
4. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la
eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la
interacción humano-máquina.
5. No modifica el flujo del ciclo de vida.
6. Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios.
7. Reduce costos y aumenta la probabilidad de éxito.
DESVENTAJAS DEL MODELO DE CONSTRUCCIÓN DE PROTOTIPOS
1. El desarrollador debe dar forma prematuramente a un sistema, incluso antes de comprender de manera
básica el problema y su funcionamiento.
2. El usuario puede creer que un prototipo es un software final.
3. Debe ser un sistema con el que se pueda experimentar.
4. Debe desarrollarse rápidamente.
5. Énfasis en la interfaz de usuario.
6. Equipo de desarrollo reducido.
7. Herramientas y lenguajes adecuadas.

32
6.7 MODELO DE SÍNTESIS AUTOMÁTICA DE SOFTWARE

Este modelo, propuesto por Robert Balzer en 1983, aplica una serie de transformaciones usando un soporte
automatizado para convertir una especificación formal (modelo matemático) en un sistema implementable
(ejecutable). Es decir, este paradigma intenta automatizar las etapas de diseño e implementación utilizando el
concepto de transformación.
También se denomina a este paradigma modelo de Transformación formal.
FASES DEL MODELO DE SÍNTESIS AUTOMÁTICA DE SOFTWARE

1. Análisis de requisitos
2. Especificación formal
3. Transformación
4. Integración del sistema filial
La especificación formal se convierte en forma sistemática en una representación más detallada del sistema,
matemáticamente correcta. Cada paso agrega detalle hasta que la especificación formal se convierte en un
programa equivalente. Como hay muchos caminos a seguir desde la especificación hasta el sistema final, la
secuencia de transformaciones y su justificación se reflejan en un registro formal de desarrollo. Se utilizan
técnicas de validación del modelo matemático, como la Simulación.
La especificación de requisitos se refina en una especificación formal detallada, expresada en notación

matemática. Los procesos de diseño, implementación y prueba de unidades se reemplazan por un proceso de
transformaciones donde la especificación formal se refina hasta llegar a un Software. (Gráfico 4)
Ilustración 14. Modelo de Síntesis automática de software de Robert Balzer.
Fuente: https://es.slideshare.net/EIYSC/tipos-de-modelos-de-procesos

33
VENTAJAS DEL MODELO DE SINTESIS AUTOMÁTICA DE SOFTWARE

1. Se define el sistema utilizando un lenguaje formal.
2. La implementación es automática, asistida por el ordenador.
3. La documentación se genera de forma automática La documentación se genera de forma automática.
4. El mantenimiento se realiza “por sustitución” en las especificaciones, no mediante “parches”.
DESVENTAJAS DEL MODELO DE SINTESIS AUTOMÁTICA DE SOFTWARE

1. Hay dificultad en la participación del usuario.
2. Los diseños están poco optimizados.
Ilustración 15. Comparación entre ciclos de vida.
Fuente: https://ocw.unican.es/pluginfile.php/1403/course/section/1792/is1-t03-trans.pdf

34
7. EL CICLO DE VIDA DE UNA BASE DE DATOS
Una base de datos no es más que un componente de un sistema de información. Por tanto, el ciclo de vida
del sistema de información incluye el ciclo de vida de la base de datos que forma parte de él. En particular,
desde el punto de vista de la base de datos, centraremos principalmente nuestra atención en las siguientes
actividades:
DEFINICIÓN DEL SISTEMA
Durante la etapa de análisis de requerimientos del sistema, nos fijaremos especialmente en todos los
requerimientos asociados a los datos con los que ha de trabajar nuestro sistema.
DISEÑO DE LA BASE DE DATOS
El análisis de los requerimientos del sistema nos permitirá organizar los datos con los que nuestro sistema
habrá de trabajar. Este proceso de diseño, que está íntimamente ligado a la futura base de datos de nuestro
sistema, lo descompondremos en tres fases:
 Diseño conceptual (descripción del esquema de la base de datos utilizando un modelo de datos
conceptual).
 Diseño lógico (descripción de la base de datos con un modelo de datos implementable, como
puede ser el caso del modelo relacional).
 Diseño físico (descripción de la base de datos a nivel interno, de acuerdo con las características
del sistema gestor de bases de datos que decidamos utilizar).
IMPLEMENTACIÓN DE LA BASE DE DATOS
(la parte de la implementación del sistema correspondiente a la creación de la base de datos).
CARGA O CONVERSIÓN DE LOS DATOS
Como parte de la instalación o despliegue del sistema, tendremos que introducir en la base de datos todos
aquellos datos que resulten necesarios para que las aplicaciones de nuestro sistema de información puedan
funcionar. Como parte de esta inicialización de la base de datos, puede que resulte necesario extraer datos
de otro sistema y convertirlos a un formato adecuado para nuestro sistema (entre otras cosas, porque el
esquema de nuestra base de datos probablemente diferirá del esquema de las bases de datos de las que se
extraigan los datos necesarios para arrancar nuestro sistema).

35
CONVERSIÓN DE APLICACIONES
Si determinadas aplicaciones (que ya existiesen anteriormente al diseño de nuestro sistema) han de seguir
funcionando, dichas aplicaciones deberán adaptarse al esquema de nuestra base de datos. Por tanto, como
parte del mantenimiento de dichas aplicaciones, tendremos que diseñar los mecanismos adecuados para que
estas aplicaciones puedan seguir funcionando correctamente sobre una base de datos diferente a la base de
datos sobre la que fueron diseñadas inicialmente. A veces, podremos solucionar este problema creando
vistas adecuadas de nuestra base de datos para tales aplicaciones. Otras veces, tendremos que modificar la
implementación de las aplicaciones antiguas e, incluso, rehacerlas casi por completo.
VERIFICACIÓN Y VALIDACIÓN
Como en todo sistema de información, deberemos verificar que la base de datos y las aplicaciones funcionan
correctamente. Además, deberemos comprobar que el sistema construido se ajusta a las necesidades reales
que promovieron su proyecto de desarrollo (esto es, validar el sistema y sus requerimientos).
OPERACIÓN, SUPERVISIÓN Y MANTENIMIENTO
Finalmente, una vez puesto en marcha el sistema, se llega a la etapa "final" del ciclo de vida de todo sistema
de información (en la que, como ya vimos, se repetirá todo el ciclo cada vez que tengamos que realizar
modificaciones sobre el sistema ya existente).
De las actividades descritas en los párrafos anteriores, todas ellas relacionadas directamente con la base o
bases de datos utilizadas en un sistema de información, estudiaremos a fondo las correspondientes a las
etapas iniciales del ciclo de vida de la base de datos. Antes de estudiar técnicas concretas, no obstante,
detallares algo más el proceso de diseño que utilizaremos para construir correctamente una base de datos.

36
8. FASES DEL DISEÑO DE BASES DE DATOS

FASE 1: ANÁLISIS DE REQUERIMIENTOS
OBJETIVO
Recabar información sobre el uso que se le piensa dar a la base de datos.
TAREAS
Elicitación de los requisitos del sistema:
- Identificación de las principales áreas de la aplicación y grupos de usuarios.
- Estudio y análisis de la documentación existente relativa a las aplicaciones.
- Estudio del entorno de operación actual.
- Estudio del uso de la información (transacciones, frecuencias y flujos de datos).
RESULTADOS
Documento de especificación de requerimientos:
- Descripción del sistema en lenguaje natural.
- Lista de requerimientos (organizados de forma jerárquica).
- Diagramas de flujo de datos (DFD).
- Casos de uso.
FASE 2: DISEÑO CONCEPTUAL
OBJETIVO
Producir un esquema conceptual de la base de datos (independiente del sistema gestor de bases de
datos que luego vayamos a utilizar).
TAREAS
- Comprensión de la estructura, semántica, relaciones y restricciones asociados a los datos

que deben almacenarse en la base de datos.
- Modelado de los datos del sistema (obtención de una descripción estable de lo que será el
contenido de la base de datos).
- Comunicación entre usuarios finales, analistas y diseñadores para comprobar la validez del

37
modelo obtenido.
RESULTADOS
- Diagrama E/R, diagrama CASE*Method o diagrama de clases UML.
- Diccionario de metadatos.
FASE 3: ELECCIÓN DEL SGBD
La elección del sistema gestor de bases de datos que vayamos a utilizar se realiza en dos etapas:
- Primero se realiza la elección del modelo de datos, el tipo de sistema gestor de bases de
datos que vamos a usar: relacional, objeto-relacional, orientado a objetos, multidimensional...
- A continuación, se elige el sistema gestor de bases de datos concreto (y su versión). Por

ejemplo, si decidimos utilizar un sistema gestor de bases de datos relacionales, podemos
recurrir al gestor de bases de datos de Oracle, al DB2 de IBM, al SQL Server de Microsoft, al
Interbase de Borland o a cualquier otro de los muchos sistemas gestores de bases de datos
relacionales que existen en el mercado.
FASE 4: DISEÑO LÓGICO
OBJETIVO
Crear el esquema conceptual de la base de datos (y todos los esquemas externos asociados a las distintas
aplicaciones del sistema) de acuerdo con el modelo de datos del sistema gestor de base de datos elegido.
TAREAS
Para realizar el diseño lógico de la base de datos, hay que transformar los esquemas obtenidos en el diseño
conceptual en un conjunto de estructuras propias del modelo abstracto de datos elegido. En el caso de las
bases de datos relacionales tendremos que realizar las siguientes tareas:
- Paso del diagrama E/R (o equivalente) a un conjunto de tablas.
- Normalización de las tablas

FASE 5: DISEÑO FÍSICO
OBJETIVO
El diseño físico de la base de datos consiste en elegir las estructuras de almacenamiento apropiadas (tablas,
particiones de tablas, índices...) para que el rendimiento de la base de datos sea el adecuado para las
distintas aplicaciones a las que ha de dar servicio.

38
TAREAS
- Estimar adecuadamente los diferentes parámetros físicos de nuestra base de datos, para lo
cual podemos recurrir a técnicas analíticas (modelos matemáticos del rendimiento de un
sistema) y a técnicas experimentales (como la construcción de prototipos, el uso de técnicas
de simulación o la realización de pruebas de carga).
- Preparar las sentencias DDL correspondientes a las estructuras identificadas durante la etapa
de diseño lógico de la base de datos.
RESULTADO
Un conjunto de sentencias DDL escritas en el lenguaje del SGBD elegido (incluyendo la creación de índices,
la selección de parámetros físicos de la base de datos, etcétera).
FASE 6: INSTALACIÓN Y MANTENIMIENTO
Como en cualquier sistema de información, casi siempre resulta necesario modificar el diseño de la base
de datos, ya sea porque el rendimiento observado después de la implementación del sistema de bases de
datos no sea el adecuado o porque haya que introducir cambios en el esquema de la base de datos como
consecuencia del mantenimiento del sistema de información. Por ambos motivos se incluye explícitamente
esta fase en el proceso de diseño de bases de datos.
INSTALACIÓN Y PUESTA EN MARCHA
- La instalación de la base de datos suele ser responsabilidad del administrador de la base de

datos (DBA: Database Administrator), que se encarga de recopilar todas las sentencias DDL
necesarias para crear los distintos esquemas de la base de datos.
- Una vez creados estos esquemas, se procede a la carga inicial de los datos en la base de
datos, para lo cual puede ser necesaria la implementación de rutinas de conversión, tal como
vimos al describir el ciclo de vida de una base de datos.
MANTENIMIENTO
- Casi todos los sistemas gestores de bases de datos incluyen alguna utilidad que nos permite
supervisar el funcionamiento del sistema. Dichas utilidades de monitorización recopilan
información estadística del uso del sistema para su análisis posterior, lo que nos facilitará todas
las tareas relacionadas con la optimización del rendimiento del sistema.
- Cuando los requisitos del sistema cambien y haya que actualizar las aplicaciones de nuestro
sistema de información, el esquema de la base de datos también se verá sometido a algunas
modificaciones.

39
9. CASO PRÁCTICO
PRESENTACION DE LA EMPRESA
La empresa objeto se sitúa en el contexto de las tecnologías de la información y en concreto en el sector de las
comunicaciones móviles. En concreto la empresa a estudio, pretende ser una solución atractiva para
operadores, proveedores de servicios y de equipamiento de alta tecnología en el sector de las
telecomunicaciones y en concreto de las comunicaciones móviles. La idea de la empresa nace de la necesidad
de proveer al cliente final de soluciones “end to end” que posibiliten optimizar y maximizar a la alta calidad de
servicio a bajo coste.
La organización que será modelo del presente trabajo es “New Perumore’s Strategy”, la cual pretende
desarrollar una serie de soluciones y servicios de optimización que serán la base de la estrategia comercial de
productos y servicios.
• Servicios de Operación y Optimización de Red

• Servicios de consultaría “Business Intelligent” y Marketing de productos
• Servicios de consultaría en Calidad de Servicios
• Servicios de Desarrollo de Aplicaciones Software a Medida
• Servicios de Integración de Aplicaciones y Soluciones
La compañía ha identificado el proyecto de integración del sistema integrado ERP como clave y estratégico en
su proyección a medio y largo plazo en el sector de las telecomunicaciones móviles.
9.1 MISIÓN, VISIÓN Y VALORES DE LA EMPRESA
MISION
Liderar con nuestra experiencia y compromiso de innovación y calidad el desarrollo de servicios

de telecomunicación de última generación, que posibiliten la convergencia tecnológica hacia la
red de Internet de nuestros principales colaboradores a fin de enriquecer nuestra sociedad con
nuevas y mejores posibilidades de comunicación.
VISION
Ser una compañía líder y de referencia en el desarrollo de las Tecnologías de la Comunicación

y la Información para nuestros principales clientes y colaboradores.

40
VALORES ESENCIALES
1. Nuestros clientes, nuestra razón de ser, y nuestro compromiso satisfacer sus necesidades.
2. Ofrecer valor a la sociedad a través de nuestra constante innovación tecnológica.
3. Nuestro equipo humano el principal valor de nuestra entidad.
4. Pasión por el trabajo, objetivos y metas profesionales.
5. Respeto por el medio ambiente y el entrono que nos rodea.
Ilustración 16. Visión, misión y valores
s:
9.2 CONTEXTO DEL SECTOR EMPRESARIAL
El sector de las comunicaciones móviles ha experimentado un incremento que se podría considerar exponencial
desde el punto de vista de evolución tecnológica y de penetración y alcance del mercado a nivel global. Sin
duda alguna las comunicaciones móviles conjuntamente con Internet son exponentes de nuestra era actual de
las Tecnologías de la Información y la Comunicación.
Para analizar el sector se habrá un breve análisis de situación y de reflexión desde cuatro perspectivas
diferentes:
 Tecnológica
 Mercado
 Operativa

41
 Financiera
Este análisis permitirá enfocar el desarrollo del caso práctico en cada una de las áreas a estudio del proyecto.
9.2.1 CONTEXTO TECNOLOGICO
Desde un punto de vista tecnológico los sistemas de comunicación vienen evolucionado desde 1980
momento en el que aparecieron los primeros sistemas de comunicación de carácter analógico basados en
multiplexación de frecuencia y tiempo (FDMA y TDMA). La evolución nos llevó a los sistemas de
comunicaciones digitales globales que conocemos y utilizamos en la actualidad como GSM (“Global
System Mobile Comunications”) también conocido como la segunda veneración (2G) de telefónico celular
o UMTS que constituye la tercera Generación (3G) de sistemas de comunicaciones móviles.
En la actualidad y en un plan a corto a plazo los operadores de comunicaciones móviles y proveedores de

telecomunicaciones trabajan para ofrecer servicios de datos en entornos de movilidad con un Throughput
o ancho de banda de transmisión en torno a 28 Mbs o 42 Mbs sobre la tecnología de redes de
comunicaciones móviles de 3G UMTS que hace uso de HSPA+ utilizando sistemas modulación 64 QAM
(Quadrature Amplitud Modulation) y MIMO (“Multiple Input Multiple Output”) para mejorar la tasa binaria de
transferencia de datos.
A su vez, a medio largo plazo, las redes móviles han de evolucionar duplicando su capacidad y velocidad
de transmisión hasta los 150Mbs en un periodo de entre tres y cuatro años dependiendo del país, madurez
tecnológica y demanda de servicios.
9.2.2 CONTEXTO ACTUAL DE MERCADO
Si analizamos el sector de las comunicaciones móviles en el contexto actual del mercado desde la
perspectiva del cliente final de servicios, comprenderemos que la demanda de servicios de datos crece
porque en gran medida el cliente espera poder hacer uso en movilidad de los servicios que encuentra en
la red de Internet. Las redes sociales, los servicios multimedia, de video, videoconferencia, y otros muchos
son un buen ejemplo de lo que el cliente final espera poder encontrar en su teléfono móvil.
Por otra parte, los nuevos SmartPhone como el “Iphone” o el “Ipad” proveen al usuario de comunicaciones
móviles con dispositivos que permiten emular e incluso mejorar la experiencia del usuario frente a los
ordenadores personales o portátiles convencionales.
La demanda del cliente fuerza a operadores y proveedores de telecomunicación a desarrollar, desplegar

y lanzar comercialmente nuevas tecnologías y servicios de red para logar dar cobertura a la demanda del
mercado.
Tanto operadores, como proveedores de servicios o equipos de telecomunicación se encuentran inmersos

en una carrera de alta competitividad para desarrollar y desplegar servicios más competitivos que logren
encontrar las expectativas del cliente final en “Time to Market” con la calidad de servicio esperada, a un
bajo coste.

42
9.2.3 CONTEXTO OPERATIVO DE LOS PROVEEDORES
Desde un punto de vista meramente operativo, propio de la operación de proveedores de

telecomunicación, operadores de red y de servicio, el sector se encuentra en un momento delicado en el
que nuevas tecnologías de red y servicios se han de desplegar rápidamente acorde con la demanda del
mercado sin disponer del tiempo necesario para madurar la tecnología y desarrollar el know-how operativo
necesario para optimizar su potencial.
Innovación es el factor clave que determina el éxito en el mercado y se mide en “Time to Market”, calidad
de servicio y excelencia operacional para alcanzar la satisfacción del cliente final.
En un entorno tan competitivo como el mercado actual de las comunicaciones móviles, desplegar una
nueva tecnología de red e innovar en el lanzamiento de nuevos productos y servicios supone diferenciarse
de los competidores ganando cuota de mercado. Por contra, un despliegue tardío, con demoras en el
lanzamiento del servicio o con una calidad inferior a la esperada pueden suponer la pérdida de credibilidad
del cliente con un impacto irrecuperable en la imagen de marca.
El sector demanda innovación en nuevas tecnologías y esto conlleva la necesidad de disponer de

profesionales altamente cualificados con el know-how y la experiencia suficiente para hacer frente al reto
demandante del sector.
9.2.4 CONTEXTO ECONOMICO Y FINANCIERO
En los últimos años el sector de las comunicaciones móviles ha sido extremadamente productivo desde
un punto de vista económico. Los servicios de comunicaciones móviles de voz y mensajería principalmente
han logrado penetrar el sector con gran facilidad logrando alcanzar elevadas cuotas de mercado a precios
muy rentables con tarifas por minutos en el caso de voz para clientes pre-pago o postpago, por mensaje
para servicios de mensajería, y por Mega Bytes para servicios de datos principalmente orientados al sector
de empresas. Aunque el gobierno ha tratado de controlar estas tarifas, estas han presentado costes que
permitían rentabilizar rápidamente la inversión en nuevos proyectos, maximizando los ingresos a corto y
medio plazo.
Actualmente el panorama económico y financiero del sector se presenta muy diferente. Por un lado, los
servicios de voz sobre IP disponibles en Internet a coste cero, han disparado las alarmas del que hasta el
momento fue el servicio más rentable para las operadoras de comunicaciones móviles, el servicio de voz.
Las aplicaciones de Chat y telepresencia han impactado en el “Business Case” de los servicios de
mensajería y la comunicación wireless han hecho lo propio en el sector de empresas puesta que se
mejoran las posibilidades de comunicaciones móviles en entornos de empresa acotados.
Los operadores tienen que hacer frente a tarifas planas de bajo coste para los servicios de voz y de datos
y a su vez ser capaces de crear nuevos casos de negocio para rentabilizar las comunicaciones de datos y
las inversiones que se deben realizar para desplegar nuevas tecnologías de red y servicios.
A. PLANIFICACIÓN
PLAN ESTRATÉGICO

43
El plan estratégico se compone básicamente de tres fases que nos deben permitir determinar la estrategia y el
plan de acción.
A continuación, se va a desarrollar el Plan estratégico de “New Perumore’s Strategy” siguiendo las pautas de
desarrollo del plan estratégico empresarial, las cuales se describen a continuación.
1. Primera Fase: Análisis de Diagnóstico y de Situación. Se conforma de un análisis de situación y un

diagnostico posterior de la misma.
2. Segunda Fase: Decisiones Estratégicas. Se define como la etapa en la que se formulan los objetivos,
y se determina la estrategia a seguir.
3. Tercera Fase: Definición del Plan de Acción. Se determinan las acciones y se define el presupuesto
para ejecutar el plan de acción empresarial.
Ilustración 17. Fases plan estratégico
Para poder determinar un diagnóstico de DAFO (Debilidades, Amenazas, Fortalezas y Oportunidades)

debemos efectuar en primer lugar un análisis de la organización interna de “New Perumore’s Strategy” y otra
externa del sector de las comunicaciones.
B. ANÁLISIS
ANALISIS DE LA SITUACION INTERNA

Los factores a estudio son básicamente:
 La cartera de productos y servicios ofrecidos.

 El plan de precios acorde a mercado y costes de producción.
 Los proyectos de innovación y su impacto estratégico.

44
CARTERA DE PRODUCTOS Y SERVICIOS:
“New Perumore’s Strategy” ofrece una amplia gama de servicios de optimización y consultaría de
performance de red y de servicios, principalmente:
• Servicios de Operación y Optimización de Red

• Servicios de consultaría “Business Intelligent” y Marketing de productos.
• Servios de consultaría en Calidad de Servicios
• Servicios de Desarrollo de Aplicaciones Software a Medida
• Servicios de Integración de Aplicaciones y Soluciones
EL PLAN DE PRECIOS ACORDE A MERCADO Y COSTES DE PRODUCCIÓN
Los precios hacia nuestros competidores se deben revisar y adaptar para alinear nuestra oferta
a la situación actual de reducción de precios por parte de operadores y proveedores de servicios.
Por otra parte, la elevada demanda de servicios de datos que obligará a los operadores a realizar
una fuerte inversión se plantea como una oportunidad para la compañía en el mercado.
LOS PROYECTOS DE INNOVACIÓN Y SU IMPACTO ESTRATÉGICO
“New Perumore’s Strategy” es una empresa ágil en el desarrollo de aplicaciones software a

medida para Operadores y Proveedores de servicios de comunicaciones móviles.
Las dimensiones de la organización y nuestro volumen de negocio nos permiten personalizar los
proyectos a medida del cliente.
Los proyectos que requieren un alto nivel de inversión no están al alcance de las posibilidades
de “New Perumore’s Strategy”.
ANALISIS DE LA SITUACION EXTERNA

Las conclusiones del Análisis de Situación Externa del sector comunicaciones móviles de “New
Perumore’s Strategy” se reflejan en la siguiente tabla.
ANÁLISIS DEL MERCADO
Se trata de un sector en constate evolución tecnológica, en los que innovación determina la

ventaja diferencial y competitiva.
Las oportunidades de crear valor existen dado que se trata de un mercado que viene
experimentado un incremento en el número de clientes que hacen uso de los servicios de
comunicaciones de banda ancha.
El sector esta experimentado una etapa de transición entre los servicios de voz y mensajera y
los datos. Estos últimos incrementan su uso potenciado por las nuevas tecnologías de banda

45
ANÁLISIS DE SITUACIÓN SOCIAL Y ECONÓMICA
El sector de comunicaciones móviles no parece verse muy afectado por la crisis económica que
impacta sobre el sector financiero. Muy al contrario, los Operadores de comunicaciones móviles
han vuelto a reportar beneficios notables en sus cuentas de resultados.
En contraste, los operadores de comunicación se están viendo obligados a reducir sus tarifas de
servicios de voz y datos para mantener un nivel competitivo en el mercado. Los
servicios gratuitos en la red se han dejado sentir en el sector, que se ve obligado a aplicar planes
de precios basados en tarifas planas.
Los operadores tienen que continuar realizando una fuerte inversión para mantener su posición
de marca e imagen en el sector de las nuevas tecnologías
Los clientes demandan una mejor calidad de servicio a más bajo coste.
ESTRUCTURA DEL MERCADO Y DE CLIENTES POTENCIALES
Existe un abanico de clientes potenciales entre los que se encuentran los operadores de
comunicaciones móviles, Operadores virtuales, y proveedores de telecomunicación y servicios.
El mercado se encuentra dominado a nivel nacional por Telefónica, Vodafone y Orange, seguido
de Yoigo y otros operadores virtuales.
Los proveedores de equipamiento de telecomunicación son compañías de gran envergadura que
no cubren nichos de mercado en cuestión de optimización de servicios.
Los proveedores de servicios van en aumento y a medio largo plazo pueden requerir servicios
de optimización para gestionar con eficiencia el incremento masivo de trafico de datos.
COMPETIDORES EN EL SECTOR
Cuatro son los competidores de Mobile New Perumore’s Strategy en el sector. NowFactory,
Arantech, Optimi, y Servicios Celulares.
Los dos primeros disponen de aplicaciones muy competitivas mientras que Optimi y
Servicios Celulares gozan de un equipo de Ingenieros de alta cualificación y experiencia en
la optimización de redes de datos.
DIAGNOSTICO DE LA SITUACIÓN
A continuación, se detalla presenta el diagnóstico de situación basado en el análisis de situación interna y

externa.

46
FORTALEZAS OPORTUNIDADES
Los clientes demandan una mejor calidad

de servicio a más bajo coste. Este hecho
La organización es una empresa ágil en el
puede incrementar la demanda de
desarrollo de aplicaciones software a
Operadores en servicios de mejora de
medida para Operadores y Proveedores de
calidad de red y servicio a un coste
servicios de comunicaciones móviles
competitivo.
Una atención personalizada en la gestión y
suministro de servicios es un factor clave y
diferenciador en el competitivo sector de
las telecomunicaciones.
Aparición de Clientes potenciales como los
proveedores de servicios van en aumento
y a medio largo plazo pueden requerir
servicios de optimización para gestionar
con eficiencia el incremento
masivo de tráfico de datos.
DEBILIDADES OPORTUNIDADES
Competidores en el mercado como Optimi,

y Servicios Celulares pueden personalizar
Los proyectos que requieren un alto nivel sus servicios acordes a la situación de
de inversión no están al alcance de las mercado.
posibilidades de la organización. Fuerte competencia con cuatro
suministradores de oferta pareja en coste
y servicio.
Los precios hacia nuestros competidores
se deben revisar y adaptar para alinear
nuestra oferta a la situación actual de
reducción de precios por parte de
operadores y proveedores de servicios.
Los operadores de comunicación se están
viendo obligados a reducir sus tarifas de
servicios de voz y datos para mantener un
nivel competitivo en el mercado. Los
servicios gratuitos en la red se han dejado
sentir en el sector, que se ve obligado a
aplicar planes de precios basados en
tarifas planas.

47
ANALISIS FUNCIONAL DE LA ORGANIZACIÓN
AREAS QUE CONFORMAN LA ORGANIZACIÓN
El plan estratégico se compone básicamente de tres fases que nos deben permitir determinar la estrategia
y el plan de acción.
La organización de “New Perumore’s Strategy” se conforma de cinco pilares estructurales claves, los
cuales quedan delimitados por las siguientes áreas:
 FINANZAS, es otro de los ejes clave de toda organización y así también en “New Perumore’s
Strategy”. Como se recoge en el plan estratégico a corto y medio plazo la compañía tendrá que
realizar inversiones relevantes para posicionarse en el sector como una compañía líder en su
segmento de negocio. Para ello finanzas tendrá que asegurar la viabilidad económica de todos y cada
uno de los proyectos que se lleven a cabo, realizando un seguimiento continuo de los indicadores
financieros de la organización con el objetivo de garantizar la salud financiera de “New Perumore’s
Strategy”.
 Bajo esta área destacan los departamentos de CONTROL FINANCIERO, TESORERÍA Y

CONTABILIDAD los cuales requieren de un sistema de formación fiable y homogéneo que posibilite
una gestión ágil y eficiente de la información.
 TECNOLOGÍA como eje central de la organización y motor de la compañía a lo hora de desarrollar

productos y servicios que puedan generar valor para el cliente final. El desarrollo de nueva
aplicaciones software personalizadas a la medida de los operadores de comunicaciones móviles,
junto con la posibilidad de ofrecer una amplia y atractiva oferta de servicios de consultaría, son
factores clave para posicionarse en el sector como una compañía líder y competitiva de forma
sostenible.
 OPERACIONES, como departamento encuadrado dentro del área de tecnología, es un pilar

indispensable para llevar a cabo las acciones de la compañía. La excelencia operacional es sin duda
uno de los objetivos estratégicos de “New Perumore’s Strategy” velando por asegurar la mejora
continua de los procesos de la organización tanto en el desarrollo de nuevos productos y servicios
como en la operación y entrega de los mismos al cliente final en tiempo, calidad y coste.
 GESTIÓN DE CLIENTES, área que vela por ofrecer la mejor calidad de servicio y soporte para los
clientes de “New Perumore’s Strategy”. La organización entiende el valor de la satisfacción del cliente
final como su razón de ser, por ello, esta es una de las áreas que más se quieren potenciar para logar
ofrecer la mejor calidad y soporte al cliente. La gestión de clientes en “New Perumore’s Strategy” se
organiza en base a las cuentas de clientes. Para ello la compañía quiere llevar a cabo un seguimiento
continuo del estado de los proyectos y servicios ofrecidos a sus clientes sin olvidar las actividades de
operación y mantenimiento del servicio.
 MARKETING Y VENTAS, es el área que se encarga de maximizar el beneficio y obtener la mayor

rentabilidad de los productos y servicios de “New Perumore’s Strategy”. La organización quiere
potenciar esta área facilitando herramientas que posibiliten la realización de análisis de mercado de
forma rápida y eficiente con el fin de adaptarse mejor a las necesidades de nuestros clientes.

48
 RECURSOS HUMANOS se responsabiliza de la gestión del personal como una de los principales
activos intangibles de la organización. “New Perumore’s Strategy” sabe de la importancia de contar
con un equipo de gran experiencia y capacidad para alcanzar objetivos y lograr así satisfacer las
necesidades de sus clientes en un sector tan competitivo como este.
 SISTEMAS DE INFORMACIÓN. El área de sistemas de información se encuentra dentro del área
funcional de tecnología. La expansión y crecimiento de la organización y la demanda de una mejora
de las operaciones transversales que involucra a todas las áreas, han generado la necesidad de
desarrollar un plan estratégico de sistemas de la información como una de las principales prioridades
de “New Perumore’s Strategy”.
ORGANIGRAMA DE LA ORGANIZACION
El organigrama de “New Perumore’s Strategy” se muestra a continuación en esta ilustración en la que se

puede ver todas y cada una de las áreas anteriormente citadas.
Ilustración 18. Organigrama

49
C. DISEÑO
REQUERIMIENTOS POR AREAS FUNCIONALES
Desde cada una de las áreas que conforman los pilares clave de la organización se identifican los siguientes
requerimientos para dar cobertura a las funciones o actividades de la organización.
FINANZAS, desde el área de finanzas, y en concreto desde las unidades de Contabilidad, Tesorería y
Control Financiero se solicita una aplicación capaz de proporcionar información fiable de forma rápida para
posibilitar el control de cuentas de clientes, gastos de la compañía y seguimiento de la contabilidad general.
Así pues, se identifican las siguientes actividades o funciones dentro de esta área:
CONTABILIDAD FINANCIERA
 Contabilidad General
 Control de pagos a suministradores
 Control de cuentas y cobros de clientes finales
 Gestión de activos
TESORERÍA
CONTROL Y GESTIÓN DE PROVISIONES Y POSICIONAMIENTOS
 Control de fondos
 Control de finanzas
CONTABILIDAD POR CENTROS DE COSTE
CONTROL DE COSTE POR PRODUCTO
ANÁLISIS DE RENTABILIDAD
COSTES BASADOS EN ACTIVIDADES
MARKETING Y VENTAS: desde el área de marketing se requiere un sistema de información capaz de

proveer información sobre los diferentes productos y servicios. Esta información debe posibilitar estudios de
inversión y mercado para cada uno de los jefes de producto. Estos estudios de mercado son claves a la
hora de llevar a cabo las decisiones sobre la inversión en desarrollo y producción de nuevas aplicaciones.
Por su parte el área de ventas quiere ser capaz de conocer el estado de cuentas de los clientes con el fin
de maximizar las posibilidades de negocio al máximo y rentabilizar las inversiones de la forma más eficiente
posible. Para ello los comerciales del equipo solicitan una aplicación capaz de trabajar en tiempo real,
ofreciendo datos de ventas, pedidos y facturación de servicios a clientes. Las actividades o funciones que
se requieren del nuevo sistema de información son:
VENTAS
 Gestión de Ventas
 Gestión de productos y servicios
 Gestión de pedidos y expediciones

50
 Facturación de clientes
GESTIÓN DE PRODUCTOS Y SERVICIOS
 Gestión de tarifas y condiciones de precio

 Análisis de rentabilidad de productos y servicios
 Control de coste de producto
 Seguimiento y progresos de proyectos
TECNOLOGÍA: en esta área es un valor indispensable el disponer un sistema de información integrado que
posibilite la organización de los procesos operativos que conforman la cadena de valor de “New Perumore’s
Strategy”. Para ello la alta dirección del departamento ha realizado un estudio involucrando los principales
responsables de cada departamento con el objeto de identificar las necesidades primordiales que cubran
las funciones de Planificación y Desarrollo de nuevos productos y servicio, producción, operación y
mantenimiento de servicios y productos.
La organización de tecnología considera relevante estandarizar los procesos de las diferentes áreas
involucradas en la cadena productiva de la organización desde un punto de vista “End to End” buscando
mejorar el “Time to Market” de productos y servicios y la calidad de los mismos.
La excelencia operacional es uno de los objetivos estratégicos de “New Perumore’s Strategy”, que busca
ser líder en su segmento haciendo entrega de productos y servicios de gran calidad, en tiempo y forma. Es
por ello, que se considera requisito indispensable el implementar un sistema de información que ayude a
introducir la normativa ISO 9001 y además comenzar a establecer procesos de mejora continua.
Así pues, los requerimientos para el nuevo sistema de información que se pretende implementar son:
PLANIFICACIÓN Y DESARROLLO
 Gestión de la demanda
 Plan de capacidades
 Plan de Materiales
PRODUCCIÓN
 Datos básicos de producto

 Ordenes de fabricación
 Gestión de procesos
OPERACIÓN Y MANTENIMIENTO
 Gestión del Mantenimiento

 Ordenes de trabajo
 Proyectos de Mantenimiento
 Gestión del servicio
GESTIÓN DE LA CALIDAD
 Herramientas de planificación y gestión de la calidad

 Control de Calidad de productos
 Certificación de la calidad y notificaciones de estado por producto

51
GESTIÓN DEL SUMINISTRO Y COMPRAS: desde el área de compras tratan de obtener un mayor control
sobre las actividades de aprovisionamiento para lograr satisfacer la demanda de materiales y servicios que
requiere el área de tecnología y de gestión de proyectos.
A su vez desde la perspectiva de costes, se busca un sistema de información integrado con un coste
competitivo en el mercado actual, que posibilite contener la inversión en sistemas informáticos y aplicaciones
existente actualmente.
El coste operacional (Operational Expenditure, OPEX) preocupa a la alta dirección de la organización, razón
por la cual se quiere reducir al máximo los gastos derivados de servicios de operación y mantenimiento de
los sistemas de la información.
Finalmente, se busca un sistema que sea escalable en forma y tiempo para dar cobertura a las necesidades
de una empresa en vías de expansión. Por esta razón el departamento de compras tiene entre sus
principales objetivos el desarrollar una estrategia de compras que logre estandarizar las aplicaciones
informáticas al máximo para lograr así minibar los requerimientos actuales de inversión en equipamiento
hardware, aplicaciones software y servicios profesionales especializados.
La estandarización de los sistemas de información en acorde con los estándares de la industria es una de
las prioridades para obtener un precio optimo y personalizar la gestión del suministro con proveedores de
primer nivel.
GESTIÓN DE APROVISIONAMIENTO
 Planificación y necesidades de materiales

 Gestión de compras
 Gestión de catálogos de compra
 Control de partida presupuestaria
 Control de ordenes internas
 Control de facturas
GESTIÓN DE PROVEEDORES
 Inventario de Proveedores
 Transporte y gestión del suministro
 Planificación de la demanda de proveedores
GESTIÓN DE ALMACÉN
 Gestión de almacenes
 Gestión de inventarios
 Sistemas de calificación y control de calidad de entradas
GESTIÓN DE CLIENTES: como bien se indica en el “Balance Score Card” de “New Perumore’s Strategy”
la satisfacción del cliente final es un factor clave para el éxito y sostenibilidad de la compañía. Por esta
razón, desde el área de gestión de clientes se solicita una solución integral que posibilite la gestión de
grandes cuentas en tiempo real de forma que sea posible conocer el estado de las cuentas y las necesidades
de operación y servicio que requiere el cliente final.

52
Las actividades clave a las que debe dar cobertura el nuevo sistema de información en el área de Gestión
de Clientes son:
GESTIÓN DE GRANDES CUENTAS
 Gestión de cuentas de clientes

 Información sobre estados de cobro
 Información de pedidos y expediciones por cliente
 Información de certificaciones y notificaciones de calidad de producto
GESTIÓN DE OPERACIÓN Y MANTENIMIENTO DE SERVICIOS A CLIENTES.
 Información sobre ordenes de mantenimiento

 Información y control del mantenimiento preventivo
 Información de los proyectos de mantenimiento
 Información sobre el estado del servicio de mantenimiento
RECURSOS HUMANOS: el departamento de recursos humanos busca mejorar las aplicaciones actuales
con un sistema de información que facilite la gestión de los empleados de la organización dentro de cada
una de las áreas que la componen. Para ello las actividades o funciones a las que debe dar cobertura el
nuevo sistema de información son:
GESTIÓN DEL PERSONAL
 Datos Maestros de personal

 Nomina
 Organización y planificación de personal
 Desarrollo de personal
 Gestión de la formación
 Selección de personal
 Gastos de Viaje
PROGRAME MANAGEMENT OFFICE: una compañía como “New Perumore’s Strategy” que tiene entre sus
actividades de negocio clave el desarrollo de aplicaciones software como productos y servicios debe
priorizar la gestión y monitorización de los proyectos clave con el fin de reducir los tiempos de entrega y
minimizar los riesgos potenciales que puedan aparecer a lo largo de la vida proyecto.
La oficina de gestión de proyectos se encontraba ubicada anteriormente dentó del área de tecnología, sin
embargo, la creciente demanda de nuevos proyectos y las vinculaciones de estos dentro de la organización
ha llevado a la alta dirección a tomar la decisión de crear un departamento especializado en la gestión de
proyectos.
GESTIÓN DE PROYECTOS
 Planificación de proyectos
 Plan de costes
 Proceso de aprobación.
 Seguimiento y progreso de proyecto.
 Master data de proyecto.

53
Cabe destacar el papel clave que jugara la oficina de gestión de proyectos a la hora de gestionar el cambio
organizativo que implica la implementación de un nuevo sistema de la información integrado.
ALTA DIRECCIÓN: requiere un sistema de información “ERP” integrado que permita conocer el estado de
la compañía contra objetivos, evaluando los indicadores de rendimiento clave que se han definido en el
“Balance Score Card”
Estos indicadores de performance permiten a la alta dirección monitorizar el rendimiento de la organización

desde cada una de los pilares claves.
CONTROL DE INDICADORES DE RENDIMIENTO DE LA ORGANIZACIÓN
 Control de contabilidad de beneficios.

 Seguimiento de la planificación del negocio.
 Consolidación a nivel directivo.
 Reporte ejecutivo para alta dirección.
SISTEMAS DE LA INFORMACIÓN: se encargará de consolidar los requerimientos de todas y cada una

de las áreas funcionales de la organización para gestionar la selección e integración del sistema que mejor
cumpla con dichos requerimientos.
A su vez, dará soporte y mantenimiento a los usuarios del sistema en cada una de las áreas de la
organización. Se responsabilizará de gestionar la actualización y escalabilidad del mismo en acorde al
plan de estratégico de sistemas de la información.
OPERACIONES Y DEPENDENCIAS TRANSVERSALES
Como se puede ver en el organigrama de “New Perumore’s Strategy” la compañía lleva a cabo gran parte
sus operaciones de forma vertical en cada una de las áreas que componen la organización.
A continuación, se presenta un gráfico que ilustra la dependencia transversal en la gestión de proyectos.

54
Ilustración 19. dependencia transversal en la gestión de proyectos
El reto principal en el que se ve inmerso “New Perumore’s Strategy” es el de llevar a cabo una integración
de procesos que posibilite la estandarización de los mismos y el crecimiento a medio largo plazo de la
compañía. Por esta razón, se ha realizado un análisis de las operaciones con dependencias transversales
con el fin de identificar requerimientos para lograr la integración y estandarización de procesos.
Las operaciones transversales con implicaciones sobre las principales áreas y por ende pilares estratégicos
de la organización, (Finanzas, Tecnología, Marketing, Ventas y Gestión de Clientes) que deben tenerse en
consideración para la implantación del sistema ERP integrado se muestran en la ilustración.

55
Ilustración 20. implantación del sistema ERP integrado
Dentro del área de tecnología también se crean dependencias entre departamentos tal y como se ilustra en
el siguiente organigrama que representa el equipo virtual de un proyecto de desarrollo software. Este
ejemplo nos permite apreciar la relevancia y necesidad de una solución ERP integrada que facilite la gestión
de procesos operativos a través de las principales áreas o pilares funcionales y estratégicos de la
organización.

56
Ilustración 21. Organigrama - Área funcional de tecnología
Como vemos el Proyecto se conforma de recursos que provienen de diferentes departamentos. Al igual que
hemos representado el área funcional de tecnología podríamos hacer la representación de cualquier otra área
de la organización identificando las unidades y grupos.
USUARIOS CLAVES
Para facilitar la gestión y el uso del nuevo sistema de información “ERP” integrado se han definido una serie
de usuarios clave dentro de cada una de las áreas que conforman “New Perumore’s Strategy” tal y como se
detalla en la siguiente tabla.
Tabla 3. Usuarios claves
AREA NUMERO DE USARIOS CLAVE MODULOS
Sistemas de Información 5 especialistas de IT. Cobertura del Sistema

57
3 usuarios clave en el área. 1 Contabilidad Tesorería.

Finanzas
usuario calve por modulo. Control de Finanzas.
Planificación y Desarrollo
4 usuarios clave en el área. Producción
Tecnología
1 usuario clave por modulo. Operación y Mantenimiento
Gestión de la Calidad
1 usuario clave en el área. Gestión de aprovisionamiento

Gestión del Suministro 1 usuario clave, tres módulos. Gestión de Almacén
4 usuarios en el área. Gestión de proveedores
2 usuarios clave en el área.

Gestión de productos
Marketing y Ventas 1 usuario clave por modulo.
Ventas
6 usuarios dentro del área.
1 usuario clave.
PMO, Gestión de Proyectos Gestión de Proyectos
4 usuarios en el área.
Recursos Humanos 2 usuarios clave en el área. Gestión de Personal
1 usuario clave en el área. 5 Gestión de grandes cuentas

Gestión de Clientes
usuarios dentro del área. Operaciones a clientes
Balance Score Card

Alta Dirección Sin usuarios calve en el área.
Informes y Reportes
ANALISIS ECONOMICO Y VIABILIDAD DEL PROYECTO
EL CASO DEL NEGOCIO
Como se mencionó en el Marco Teórico, el caso del negocio también conocido como “Business Case” es un
documento que resume los principales aspectos de una acción comercial y que nos permite ganar claridad para
justificar una inversión.
En un caso de negocio, es importante justificar el beneficio económico-financiero mediante un análisis de

indicadores clave, entre los que podemos destacar entre otro:
 El Retorno de Inversión (ROI)

 El “Total Cost of Ownership” (TCO) Costo total de la propiedad
 El “Capital Expenditure” (CAPEX) Gasto de Capital o Inversiones en bienes de capital

58
 El “Operational Expenditure” (OPEX) Costos Operativos
 El “Earnings Before Interest, Taxes, Depreciation, and Amortization" (EBITDA)
ANÁLISIS DE VIABILIDAD ECONÓMICA
A continuación, se presentan los resultados obtenidos del análisis de viabilidad económica del proyecto de
Integración del Sistema de Información ERP SAP R/3:
Las tablas y las ilustraciones representan el “Total Cost of Onwership” (Costo Total de la Propiedad) del
proyecto a lo largo de los próximos cinco años. El análisis contabiliza el coste Hardware, Software y de servicios
profesionales.
Tabla 4. Evolución de la inversión anual del proyecto (CAPEX) y el costo operativo
Implantacion del Sistema de informacion "ERP SAP R/3"
Proyecto de Integracion SAP R/3 FY 18/19 FY 19/20 FY 20/21 FY 21/22 FY 22/23 Total 5 años
Hardware $ 120,000 $ 40,000 $ 30,000 $ 20,000 $ 15,000 $ 225,000

Plataforma Hardware $ 95,000 $ 20,000 $ 15,000 $ 10,000 $ 5,000 $ 145,000
Otros elementos Hardware $ 25,000 $ 15,000 $ 10,000 $ 5,000 $ 5,000 $ 60,000
Equipamiento adicional $ - $ 5,000 $ 5,000 $ 5,000 $ 5,000 $ 20,000
Software Licneses $ 86,100 $ 14,763 $ 14,763 $ 14,763 $ 14,763 $ 145,150

Coste Inicial de Licencias Software $ 86,100 $ - $ - $ - $ - $ 86,100
Coste por nuevas Licencias Software $ - $ 10,763 $ 10,763 $ 10,763 $ 10,763 $ 43,050
Upgrades Anuales de release Software $ - $ 4,000 $ 4,000 $ 4,000 $ 4,000 $ 16,000
Profesional Services $ 98,000 $ 44,000 $ 35,000 $ 32,000 $ 32,000 $ 241,000

Servicios de Project Management $ 22,000 $ - $ - $ - $ - $ 22,000
Servicios de Instalación de licencias $ 14,000 $ 4,000 $ 4,000 $ 4,000 $ 4,000 $ 30,000
Consultores, Analistas y Especialistas de SAP $ 30,000 $ 18,000 $ 18,000 $ 18,000 $ 18,000 $ 102,000
Servicios de Migracion de Datos $ 18,000 $ 10,000 $ 3,000 $ - $ - $ 31,000
Servicios de personalización de aplicaciones $ 14,000 $ 12,000 $ 10,000 $ 10,000 $ 10,000 $ 56,000
Costo Operativo $ 4,000 $ 24,000 $ 24,000 $ 24,000 $ 24,000 $ 100,000

Costes de Operación y Mantenimiento $ 4,000 $ 24,000 $ 24,000 $ 24,000 $ 24,000 $ 100,000
Total Costo de la Propiedad $ 308,100 $ 122,763 $ 103,763 $ 90,763 $ 85,763 $ 711,150

CAPEX $ 304,100 $ 98,763 $ 79,763 $ 66,763 $ 61,763 $ 611,150
OPEX $ 4,000 $ 24,000 $ 24,000 $ 24,000 $ 24,000 $ 100,000
Numero total de empleados 200 225 250 275 300 325

Usuarios clave 14 16 18 19 21 23
Usuarios de la aplicación 28 32 35 39 42 46
La ilustración representa la evolución de la inversión anual del proyecto (CAPEX) y el costo operativo

59
(OPEX) también anual del mismo.
Ilustración 22. Evolución de la inversión anual del proyecto (CAPEX) y el costo operativo
A continuación, se muestran la estimación de ingresos que se esperan obtener de la explotación del

sistema ERP SAP R/3:
Facturacion Anual y Presupuesto Anual del Area de Tecnologia
Ingresos brutos por facturacion anual $ 5,000,000 $ 5,250,000 $ 5,512,500 $ 5,788,125 $ 6,077,531 $ 27,628,156
Inversion en CAPEX en area de tecnologia y suministro $ 600,000 $ 630,000 $ 661,500 $ 694,575 $ 729,304 $ 3,315,379
Ingresos anuales derivados de la mejora de procesos operativos y beneficios de SAP R/3

Proyecto de Integracion SAP R/3 FY 18/19 FY 19/20 FY 20/21 FY 21/22 FY 22/23 Total 5 años
Ingresos brutos anuales en exploracion de cuentas de clientes $ - $ 26,250 $ 82,688 $ 86,822 $ 91,163 $ 286,922
Ingresos brutos anuales en mejora de tiempo de entrega $ - $ 42,000 $ 55,125 $ 57,881 $ 60,775 $ 215,782
Ingresos brutos anuales obtenidos de la gestion de SLAs $ 50,000 $ 78,750 $ 165,375 $ 173,644 $ 182,326 $ 650,095
Reduccion de Costos obtenida de los procesos de provisionamiento $ 12,000 $ 18,900 $ 66,150 $ 69,458 $ 72,930 $ 239,438
Ingresos brutos anuales adicionales en explotacion SAP R/3 $ 50,000 $ 147,000 $ 303,188 $ 318,347 $ 334,264 $ 1,152,799
Ahorro en presupuesto de inversion en explotacion de SAP R/3 $ 12,000 $ 18,900 $ 66,150 $ 69,458 $ 72,930 $ 239,438

60

61
Finalmente podemos ver la evolución del flujo de caja y el TIR del proyecto para los cinco años fiscales
a estudio.
Tabla 5. Evolución flujo de caja y TIR
BeneficiosNetosyCashFlowdel Proyectode IntegracionSAPR/3
Proyecto de Integracion SAP R/3 FY 18/19 FY 19/20 FY 20/21 FY 21/22 FY 22/23 Total 5 Años
Coste Anual Fijo $ 304,100 $ 98,763 $ 79,763 $ 66,763 $ 61,763 $ 611,152
Coste Anual Variable $ 4,000 $ 24,000 $ 24,000 $ 24,000 $ 24,000 $ 100,000
Ingresos anuales por explotacion de SAP R/3 $ 62,000 $ 165,900 $ 369,338 $ 387,804 $ 407,195 $ 1,392,237
Cash Flow del Proyecto $ -246,100 $ 43,137 $ 265,575 $ 297,041 $ 321,432 $ 681,085
VPN (12%) $ 114,958

TIR 62%
El gráfico nos muestra el flujo de caja a cinco años del proyecto desde el año fiscal 18/19 actualmente
en curso hasta el 22/23.
Tabla 6. Cash Flow del proyecto
Cash Flow del Proyecto

$400,000
$321,432
$300,000 $297,041
$265,575
$200,000
$100,000
$43,137
$-
$-100,000
$-200,000
$-246,100
$-300,000
Cash Flow del Proyecto

62
Como se puede comprobar en la siguiente tabla los beneficios se basan en estimaciones muy
conversadoras sobre el aumento que se espera obtener en la facturación anual mediante la explotación
de SAP R/3.
Tabla 7. Estimaciones de referencia para cuantificar los beneficios
Estimacionesdereferenciaparacuantificar losbeneficios
Objetivo anual de incremento de facturación 5.0%

Inversión anual de Tecnología y Sistemas de Información 12.0%
% Incremento de facturación anual por Explotación de Cuentas 0.0% 0.5% 1.5% 1.5% 1.5%
% Incremento de facturación por mejora en tiempo de entrega 0.0% 0.8% 1.0% 1.0% 1.0%
% Incremento de facturación anual por gestión de SLAs 1.0% 1.5% 3.0% 3.0% 3.0%
% Reducción de Coste estimada en SCM con SAP R/3 1.0% 3.0% 10.0% 10.0% 10.0%
*Acuerdos de nivel de servicio (SLA) Los SLA se crean para documentar los compromisos mediante un contrato entre el
negocio y el departamento de sistemas informáticos.
*SCM (Gestión de la Cadena de Suministro) consiste en el seguimiento de los materiales, la información y las finanzas
durante el proceso que va del proveedor al fabricante, al mayorista, al minorista, y al consumidor.
9.3 IMPACTO DEL PROYECTO
El impacto de llevar a cabo el proyecto de integración del sistema ERP SAP R/3 presenta los factores de riesgo
e impacto obtenidos en el desarrollo de los análisis funcionales. Dichos factores de riesgo o impacto se resumen
a continuación:
 El impacto cultural que puede suponer para la organización la integración de un nuevo sistema de
información que reemplace los sistemas actuales.
 La adaptación de los procesos al nuevo sistema en busca de una operativa más eficiente.
 Posibles incidencias técnicas como consecuencia de la integración del sistema con algunas de las
aplicaciones y plataformas actuales.
 La captura incorrecta o insuficiente de requerimientos que puedan llegar a generar una demanda
adicional de customizaciones posteriores a la integración.
 Desviaciones en el presupuesto como consecuencia de incidencias o ineficiencias en la planificación,

gestión y despliegue del sistema a lo largo del proyecto de integración.

63
SUMARIO EJECUTIVO
Tabla 8. Sumario ejecutivo
SUMARIO EJECUTIVO
Proyecto de implantación e integración de un sistema integral

“Enterprise Resource Planning” (ERP) SAP R/3 que posibilite
Descripción del Proyecto estandarizar y optimizar los procesos operativos de “New
Perumore’s Strategy”.
“New Perumore’s Strategy” pretende desarrollar una serie

de soluciones y servicios de optimización que serán la base de la
Descripción de la empresa
estrategia comercial de productos y servicios.
La empresa pretende ser una solución atractiva para operadores,

proveedores de servicios y de equipamiento de alta tecnología en
el sector de las telecomunicaciones y en concreto de las
Sector Empresarial comunicaciones móviles. La idea de la empresa nace de la
necesidad de proveer al cliente final de soluciones “end to end” que
posibiliten optimizar y maximizar la calidad de servicio a bajo coste.
 Servicios de Operación y Optimización de Red

 Servicios de consultaría y Marketing de productos
 Servicios de consultaría en Calidad de Servicios
Cartera de Servicios  Servicios de Desarrollo de Aplicaciones Software a Medida
 Servicios de Integración de Aplicaciones y Soluciones
 Vodafone Perú.
 Telefónica.
 Orange
Cartera de Clientes
 Yoigo.
 Proveedores de Telecomunicación, Ericsson, NSN.
Facturación Anual 5.000.000 de dólares Anuales
Empleados Actuales 200 empleados

64
Una optimización de los procesos de la organización que reduzca

los tiempos de desarrollo y mejore la calidad de servicio ofrecida al
cliente, abre las puertas a oportunidades de negocio tangibles
como las identificadas en el plan estratégico de “New Perumore’s
Strategy”:
 Los clientes demandan una mejor calidad de servicio a más

bajo coste. Este hecho puede incrementar la demanda de
Operadores en servicios de mejora de calidad de red y servicio
Oportunidad de Negocio a un coste competitivo.
 Una atención personalizada en la gestión y suministro de
servicios es un factor clave y diferenciador en el competitivo
sector de las telecomunicaciones.
 La aparición de clientes potenciales como los proveedores de
servicios van en aumento y a medio largo plazo pueden
requerir servicios de optimización para gestionar con eficiencia
el incremento masivo de tráfico de datos.
La situación actual del sector y el posicionamiento de los

competidores en el sector, obliga a “New Perumore’s Strategy” a
optimizar sus procesos para lograr abaratar los costes operativos
de producción y operación de servicio.
Las principales amenazas son:
 Fuerte competencia con cuatro suministradores de oferta
pareja en coste y servicio.
 Los precios hacia nuestros competidores se deben revisar y
adaptar para alinear nuestra oferta a la situación actual de
Amenazas de Negocio reducción de precios por parte de operadores y proveedores
de servicios.
 Los operadores de comunicación se están viendo obligados
a reducir sus tarifas de servicios de voz y datos para
mantener un nivel competitivo en el mercado. Los servicios
gratuitos en la red se han dejado sentir en el sector, que se
ve obligado a aplicar planes de precios basados en tarifas
planas.
Impacto Estratégico Tal y como se recoge en el plan estratégico de “New Perumore’s

Strategy”, la compañía requiere de un nuevo sistema de
Información “ERP” que dé cobertura de forma integral a las
diferentes áreas de la organización.
 Despliegue e implementación de un sistema “Enterprise

Resource Planning” integrado que optimice los procesos
transversales de la organización y posibilite una mejora en la
gestión y operación de servicios al cliente final.

65
La junta directiva de “New Perumore’s Strategy” acordó durante

la elaboración del plan estratégico de la compañía el fomentar el
despliegue e integración del nuevo Sistema de Información
Impacto Táctico Operativo “ERP”.
 Fomentar y el despliegue, integración y uso del nuevo
sistema “Enterprise Resource Planning” integrado que
optimice las operaciones de “New
Perumore’s Strategy”.
 Estandarización de procesos operativos que involucran a

más de un área.
 Unificación de sistemas de información y aplicaciones de
soporte funcional y operativo de la organización.
 Reducción de los tiempos de desarrollo, producción, gestión
del suministro y entrega.
 Mejora en la gestión de la información con un sistema en
tiempo real.
 Mejora en la atención personalizada al cliente final de forma
conjunta desde cada una de las áreas de la organización.
 Implantación de la Normativa ISO 9001 para asegurar la
calidad de procesos.
Beneficios esperados
 Reducción de costes operativos derivados de los procesos
de operación y mantenimiento.
 Incrementar el control sobre presupuestos y gastos de forma
eficiente.
 Control del gasto de desarrollo en aplicaciones software por
terceros mediante una solución homogénea e integrada
como SAP.
 Estandarización de los sistemas de información e
introducción de las mejores prácticas.
 Escalabilidad de los sistemas que posibiliten el crecimiento
de “New Perumore’s Strategy ”.
Factores de Riesgos  El impacto cultural que puede suponer para la organización

la integración de un nuevo sistema de información que
reemplace los sistemas actuales.
 La adaptación de los procesos al nuevo sistema en busca de
una operativa más eficiente.
 Posibles incidencias técnicas como consecuencia de la
integración del sistema con algunas de las aplicaciones y
plataformas actuales.
 La captura incorrecta insuficiente de requerimientos que
puedan llegar a generar una demanda adicional de
customizaciones posteriores a la integración.
 Desviaciones en el presupuesto como consecuencia de
incidencias o ineficiencias en la planificación, gestión y
despliegue del sistema a lo largo del proyecto de integración.
ANALISIS ECONOMICO
Total, Cost Ownership De 711,150 dólares en un periodo de 5 años.

66
CAPEX Total Capital Expenditure de 611,150 dólares.
OPEX Total Operational Expenditure de 100.000 dólares.
Retorno de Inversión Retorno de Inversión del 62% en 5 años.
 Presupuesto estimado de 700.000 dólares para Desarrollo.

 Presupuesto sostenido de 24.000 dólares por año fiscal den
Presupuesto Estimado
operación y mantenimiento del servicio comenzado en el año
posterior al desligue FY 18/19.
18/19 19/20 20/21 21/22 22/23

Presupuesto Estimado CAPEX 304.100 98.763 79.763 66.763 61.763
OPEX 4.000 24.000 24.000 24.000 24.000
RECOMENDACIÓN
 Implementación del Sistema de Información SAP R/3 con el

objeto de acometer el plan estratégico de expansión y
crecimiento a medio lago plazo de “New Perumore’s
Strategy”.
Recomendación de Negocio  Lanzamiento del Programa de Gestión del Cambio con el
objeto de agilizar el despliegue e integración del Sistema de
Información “ERP” integrado SAP R/3 fomentado su uso para
minimizar los factores de riesgo potenciales.
 Solución estándar ampliamente utilizada en la actualidad,

hecho que facilita la estandarización Sistemas de Información
y la implementación de las mejores prácticas de la industria.
 Solución escalable y modular que posibilitar llevar a cabo una
implementación flexible y sostenible en el medio y largo plazo.
 Precio competitivo de un producto altamente fiable, con un
coste moderado en actualizaciones y operaciones de
mantenimiento o customización, hecho que posibilita un “Total
Cost Onwership” razonable para una empresa de mediana
Factores diferenciales
envergadura como “New Perumore’s Strategy”.
del Sistema ERP SAP
 Implementación e integración factible en un tiempo
R/3
razonablemente corto cuando nos referimos a un proyecto de
implantación de sistemas.
 Facilita la reingeniería de procesos transversales optimizando
las operaciones productivas y de gestión de servicios de la
organización.
 SAP ofrece un soporte técnico especializado para el
seguimiento y resolución de incidencias, incluyendo servicios
profesionales de mejora y customización.

67
CFO Finanzas CTO Tecnología

Luis Ancho Alberto Pérez
Firma Fecha: Firma: Fecha:

Aprobación
CEO
Jorge Juan Muñoz Fernández
Firma Fecha:
DISEÑO DE LA SOLUCIÓN ERP DE SAP
MÓDULOS DEL SAP R/3

Tabla 9. Módulos del SAP R/3

68
D. IMPLEMENTACION
INTEGRACION DE LA SOLUCIÓN SAP
PLAN DE TRABAJO PARA INTEGRAR LA SOLUCION
Tabla 10. Descomposición estructural de actividades
DESCOMPOSICIÓN ESTRUCTURAL DE
ACTIVIDADES (WBS)
Código de la actividad Nombre de la actividad de Nombre de la actividad de
nivel 1 nivel 2
01 Preparación del proyecto
02 Gestión del proyecto
03 Business BluePrint
03.01 Alcance y Objeto
03.02 Análisis de la Organización
03.03 Definición de Requerimientos
03.04 Configuraron del Sistema
04 Realización y Diseño
04.01 Diseño del mapa de procesos
04.02 Parametrización de sistemas
04.03 Análisis y corrección (GAP)
05 Paso a Producción
05.01 Preparar entorno de pruebas
05.02 Pruebas unitarias y validación
05.03 Pruebas de stress
05.04 Documentación de QA
06 Formación de los usuarios
06.01 Entrega de Documentación
06.02 Cursos de Formación
07 Puesta en producción
07.01 Migración masiva de datos
08 Final del proyecto

69
DESCRIPCIÓN DE LAS PRINCIPALES ACTIVIDADES DEL PROYECTO
A continuación, se describen las principales actividades del proyecto teniendo en consideración las que se
llevaron a cabo en la primera fase de este Trabajo Fin de Carrera (TFC).
PREPARACIÓN DEL PROYECTO

Así pues, las actividades de preparación del proyecto, estudio de objetivos y alcance, incluyendo el análisis
de la organización y la definición de los requerimientos se han realizado en la primera fase de este TFC.
En la primera entrega del TFC se ha presentado la empresa objeto y se han documentado los
requerimientos de sistema para cada una de las áreas de la organización involucradas en los procesos de
negocio a los que darán cobertura las soluciones SAP ERP.
GESTIÓN DEL PROYECTO

Por su parte la gestión del proyecto incluye la planificación temporal del equipo de trabajo, los posibles
riesgos y su potencial impacto, así como la organización del proyecto.
Las reuniones de seguimiento y control de proyecto con el equipo y con los responsables da la compañía
“New Perumore’s Strategy” tendrán lugar de forma periódica cada semana. La agenda de estas reuniones
será gestionada por el jefe de proyecto atendiendo a las necesidades y estado del proyecto. A su vez, se
llevarán a cabo una demo o presentación el prototipo para los principales responsables y clientes del
proyecto.
El jefe de proyecto realizara y documentara el control de cambios de proyecto. También, emitirá un informe
de seguimiento quincenal donde incluirá como los aspectos fundamentales de estado del proyecto en
tiempo, calidad y coste contra entregables.
El cierre del proyecto será gestionado por el jefe de proyecto, liberando así los recursos y documentado el
mismo. Al cierre se emitirá un documento que recopile la calidad final del producto y otro que posibilite la
mejora en la gestión de proyecto posterior mediante un resumen de las mejores prácticas.
La realización y el diseño incluyendo el análisis funcional de gaps los llevarán a cabo nuestros expertos
analistas en SAP y programadores en ABAP y J2EE en relación directa con los principales responsables
y clientes del proyecto en la organización, de forma que se logren capturar todos los requerimientos
funcionales que requiere el producto final con el máximo rigor.
REQUISITOS FUNCIONALES Y DE INFRAESTRUCTURA

En esta fase se documentarán los requisitos funcionales y de infraestructura, así como el diseño de la
solución software. Esto documento es uno de los pilares fundamentales que guiará nuestra posterior fase
de desarrollo y ejecución de pruebas.
PROGRAMACION
El desarrollo entorno de pruebas nos permitirá evaluar si todos los requerimientos del cliente se han
alcanzado con éxito.

70
La programación el plan de pruebas unitarias y posterior plan de integración lo llevaremos a cabo

reutilizando soluciones estándar disponibles en la solución de SAP, las cuales nos permiten garantizar una
rápida y segura implementación de los diferentes módulos.
Las pruebas de testeo y validación de la aplicación se llevarán a cabo para asegurar los requerimientos
de calidad. Ambos planes de prueba serán debidamente documentados y revisados con los responsables
y clientes principales del proyecto.
• El plan de pruebas unitarias será llevado a cabo por el Analista como parte del desarrollo e
implementación de código de la aplicación
• El plan de pruebas de integración lo ejecutará el Analista asegurando la calidad del producto final.
MIGRACIÓN DE DATOS
La migración de datos consistirá en el paso a producción de la aplicación una vez se haya obtenido la
validación de los requerimientos de calidad acordados mediante la ejecución de las pruebas de integración,
de casos funcionales y no funcionales, operacionales y de seguridad que se definen en el plan de Quality
Assurance.
Formación de los usuarios: En la planificación del proyecto se ha tenido en consideración en el valor de

formar a los usuarios con el objeto de obtener el mayor beneficio del producto. La formación cubrirá las
necesidades de los diferentes usuarios del sistema.
• Departamento de Operaciones de Red: Gestión de Red, Productos y Servicios.
• Departamento de Mejora de la Calidad: Auditoria y seguimiento de la calidad de servicio de la red.
• Servicio de Atención al Cliente: Personal del Servicio de Call Center que hace uso de la aplicación
para el control de activaciones de servicio.
• Alta Dirección: Seguimiento de reportes de performance y Calidad de Servicio.
PUESTA EN PRODUCCIÓN
La puesta en producción cubre el apoyo a la instalación y puesta en funcionamiento del producto para su
lanzamiento y explotación comercial. Soporte al personal de operación, así como seguimiento de post-
instalación.
Se hará entrega de manuales de explotación y de operación aplicada como parte de los entregables del
proyecto durante la fase de migración de datos a producción.
Los manuales de puesta en producción y operación incluirán las implicaciones del nuevo requerimiento de
creación de recetas.

71
ORGANIGRAMA DEL EQUIPO DEL PROYECTO
La dirección de “New Perumore’s Strategy” ha decidido crear un equipo de proyecto dedicado

exclusivamente a la gestión del proyecto de integración y puesta en servicio del mismo.
Así pues, el Organigrama del proyecto quedaría de la siguiente forma:
Ilustración 23. Organigrama del equipo del proyecto
Como se puede observar el organigrama integra los recursos del proveedor como consultores en cada uno de
los Workstreams definidos. La Dirección del proyecto reportando al comité Ejecutivo se apoya en el Director de
Recursos más el Responsable de Informática y el Jefe de Proyecto con experiencia del proveedor.
El grupo de trabajo de Gestión del Cambio se considera un eje clave en el organigrama del proyecto. Dado el
valor de la gestión del cambio, y la importancia del sistema ERP en los procesos organizativos, se ha
considerado oportuno alinear la organización con el proyecto creando un Workstream orientado especialmente
a llevar a cabo la gestión del cambio.

72
MATRIZ DE RESPONSABILIDADES DEL PROYECTO

La Matriz de responsabilidades en base a las Fases de Implantación del Sistema ERP del proyecto es:
Tabla 11. Matriz de responsabilidades del proyecto
Actividad
Responsable Define Diseña Desarrolla Prueba Despliega
Comité Ejecutivo I I I I D
Jefe
Proyecto P/D P/D P/I P/D P
Director Recursos P/D P/C I I I
Responsable
Informática P/C P/ C P/D C/D C
Programador
Informática C C X X X
Mantenimiento
Informático C I I X X
Jefe Proyecto Proveedor P P P P P

Consultor Técnico X X X X
Consultores
Proveedor X/C X/C C X/C C
En base la Descomposición de Actividades que se presenta en el ejercicio, los Roles de Proyecto e Hitos
Clave acorde con el “Project Plan” son:
Tabla 12. Roles de proyecto
Roles
Hitos Proyecto CE DP DR RI PI MI JPP CP
Definición de Procesos I P P/D P/C X P/C X/C
Definición Funcional I P/D I/D P/C X P/C X/C
Diseño Infraestructura I P/I I P/D X P/C X/C
Implantación
Infraestructura I P X X/D P/C X/C
Parametrización
Procesos P/D X X/D P/C X/C
Pruebas de Integración I I P/D X X/D P/C X/C
Formación
Usuarios P/D I I I I P/C X/C
Puesta en Producción D P/D I P/C I I P/C X/C

73
Leyenda
 I: Informado  CE: Comité Ejecutivo
 D: Decide  JP: Director de Proyecto
 P: Gestiona  DR: Director de Recursos
 X: Ejecuta  RI: Responsable Informática
 C: Consultado  PI: Programador Informática
 MI: Mantenimiento Informática
 JPP: Jefe Proyecto Proveedor
 CP: Consultores Proveedor
Se ha optado por introducir el comité de Dirección en la matriz de responsabilidades para destacar la

importancia de la toma de decisión y aprobación del proyecto, también en su posterior lanzamiento a
producción.
PLAN DE PUESTA EN PRODUCCION

Tabla 13. Plan puesta en producción
N Actividad Clave Actividades y Tareas
 Pruebas individuales de verificación de cada

proceso con su módulo.
 Pruebas integradas en la que debe verificarse
Pruebas de validación y la correcta integración de los procesos.
1
aseguramiento de la calidad  Pruebas de volumen o stress que se
corresponde con las pruebas de rendimiento
del sistema cuando opera con usuarios.
 Programas de formación con proveedores (SAP

y terceros).
 Integración de soluciones de e-Learning y
El plan de formación “New
2 cursos externos.
Perumore’s Strategy”
 Fomentar la rotación de personal entre
departamentos de diferentes áreas.
 La apertura de vacantes para profesionales con

experiencia contrastada con SAP.
3 Captación de personal cualificado  Programa de becas para la incorporación de
recién titulados en Informática
 Creación de la instancia productiva.

 Ajuste de las conexiones entre el sistema de
desarrollo y el sistema de producción.
4 La transferencia de datos iniciales
 El transporte se realiza a través de órdenes que
se exportan e importan entre ambos sistemas:

74
 Diseño Conceptual: cono los procesos a

implementar, después del análisis de procesos
de negocios de acuerdo al modelo de referencia
de SAP.
 Manual de parametrización: con los

cambios realizados durante la etapa de
parametrización del sistema.
5 La gestión de la documentación  El manual de usuario: guía con la información

y descripción sobre como operar cada una de
las transacciones funcionales a las que los
usuarios deben acceder, en el sistema SAP R/3.
 El manual de procedimientos: como

complemento del manual de usuario contendrá
todos los
procedimientos a seguir, fuera de SAP.
Con todas las autorizaciones para operar en el

6 La creación d e los perfiles de usuario
sistema SAP.
 Soporte del Sistema: preparativos para la

operación real en SAP incluyendo los procesos de
soporte a los usuarios finales del sistema.
7 El plan de Soporte y Operación del  Optimización del Sistema: La optimización del
sistema sistema se llevará a cabo mediante el programa de
“Mejora Continua” el cual velará por optimizar
todos los procesos de soporte y operación.
E. PRUEBAS Y PUESTA A PUNTO
PLAN DE CONTINGENCIAS Y ASEGURAMIENTO DE LA CALIDAD

Se considera Plan de Seguimiento y Contingencias a las herramientas de gestión necesarias para una
correcta administración de las Tecnologías de la Información y las Comunicaciones, el cual contiene las
medidas técnicas, humanas y organizativas necesarias para garantizar la continuidad del negocio.
“New Perumore’s Strategy” ha decidido tomar un nuevo rumbo en su negocio con la entrada
de la nueva solución ERP SAP R/3. Entre los cambios más destacados se encuentra crear

75
desde cero un nuevo sistema de información mediante el cual poder gestionar de forma más
eficiente toda la información que se genere. Es evidente la dependencia e importancia que
adquiere para “New Perumore’s Strategy” el correcto funcionamiento de su tecnología. Estos
cambios suponen una fuerte inversión y también se pretende establecer los mecanismos y
procedimientos necesarios para asegurar su correcto y normal funcionamiento. “New
Perumore’s Strategy” ha decidido crear un Plan de Contingencias que le permita continuar
con su negocio en caso de producirse alguna incidencia, tanto externa como interna, que de
otra forma causaría paradas, pérdidas de rentabilidad y posible pérdida de clientes. Los
nuevos retos planteados por “New Perumore’s Strategy” requieren un funcionamiento eficaz
y permanente del negocio.
Es importante que el Plan de Contingencias incluya: Plan de respuesta, Plan de respaldo, Plan de
recuperación, Plan de Análisis y Mejora y Plan de Pruebas.
A continuación, se detalla el Plan de Contingencias de “New Perumore’s Strategy” que dará cobertura a la
solución ERP de SAP:
Tabla 14. Plan de contingencia
PLAN DE CONTINGENCIA
Disminuir los daños y pérdidas causados por la imposibilidad de

utilizar la totalidad de sistemas de la empresa. De la misma manera
podríamos definir los objetivos principales:
 Prevenir: Limitar al máximo la probabilidad de que tenga lugar

Objetivo y alcance
cualquier interrupción.
del plan
 Contener: Reducir el impacto de cualquier interrupción.
 Recuperar: Asegurar una pronta recuperación de los procedimientos
críticos necesario para continuar con la actividad normal de la
empresa.
Con la consecución de estos objetivos se podrán reducir los costes

debidos a la interrupción del negocio. Se logrará un mayor
aprovechamiento, y más efectivo, de los recursos de los que dispone
la empresa, permitiendo una mayor capacidad de reacción ante
cualquier incidencia. Se evitarán pérdidas de productividad.
Del mismo modo conseguiremos:
Beneficios  Mantener los servicios con proveedores y clientes.
 Mantener la reputación de la empresa, dando una imagen de
fortaleza y seguridad ante posibles imprevistos.
 Asegurar la supervivencia de la organización, ya que está preparada
para reaccionar ante cualquier eventualidad que incida sobre la
continuidad del negocio.

76
La imposibilidad de acceder y/o utilizar los sistemas de “New

Perumore’s Strategy” implicaría a un gran número de activos:
 Sistemas informáticos: Donde quedarían englobados la totalidad de
los sistemas de información de Pharma-Eagle: Servidores, Bases de
Impacto, activos
Datos, terminales, etc.
implicados
 Puestos de trabajo: Los puestos de trabajo del personal de la
empresa quedarían inhabilitados, impidiendo la realización del
trabajo de estas personas.
Con los análisis realizados se considera que el tiempo asumible sin

Nivel de servicio servicio son 12 horas. Sería necesario poder contar con unas
exigido y tiempos instalaciones secundarias (subcontratadas) donde tengan sistemas
compatibles y se pueda realizar cargas de back up.
Pasadas 10 horas de no poder acceder a las instalaciones se

Disparador procedería a su ejecución.
Está compuesta por:

 Plan de respuesta
 Plan de respaldo
Acción  Plan de recuperación
 Plan de análisis y mejora
 Plan de pruebas
A continuación, se describe cada uno de los planes de acción necesario en el plan de contingencia en
producción.

77
Detección del mal funcionamiento de cualquiera de los sistemas deberá

ponerse en contacto con cualquiera de los responsables de sistemas, y
este se lo comunicará a cualquiera de los responsables de dirección,
siguiendo las siguientes pautas:
Los responsables de sistemas harán una evaluación previa de la
situación, comprobando qué procedimientos han dejado de estar
operativos.
Si alguno de los procedimientos afectados son críticos para el
funcionamiento de la empresa los responsables de sistemas se pondrán
en contacto con las personas encargadas del back up y restauración de
la información que se trasladarán a las oficinas subcontratadas para
proceder a la instalación de la mayoría de los sistemas que sean
posibles. En cuanto los sistemas estén en funcionamiento se avisará a
los responsables de dirección para informarles de los servicios que están
Plan de Respuesta operativos.
Si los procedimientos afectados no son críticos y permiten la continuidad
del negocio se procederá a unas comprobaciones por parte de los
responsables de sistemas para calcular cuánto tiempo necesitan para su
restauración. En caso de no ser posible su restauración se procederá a
realizar las mismas acciones que en el punto anterior
Todo el personal que trabaja en las instalaciones dispone de los
teléfonos de los responsables de sistemas, y estos a su vez disponen de
los teléfonos de los responsables de dirección.
Se avisará a clientes y proveedores de la situación. Si el tiempo sin poder
utilizar los sistemas de “New Perumore’s Strategy”, estando afectados
procedimientos críticos, llega a las 10 horas se activa el Plan de
respaldo.
Contactar con la empresa subcontratada para la continuidad. Existe un

contrato mediante el cual, en caso de tener que activar un plan de
emergencia de estas características, parte de los sistemas de “New
Perumore’s Strategy” pueden ser restaurados en esta empresa.
Previamente, con la firma del contrato y con futuras revisiones, se
Plan de respaldo comprueba que la empresa subcontratada dispone de servidores y
tecnología compatibles que permiten la continuidad del negocio, total o
parcialmente.
Una vez realizado el contacto se seguirán los mismos pasos detallados
en el Plan de pruebas.
Evaluar posibles daños y pérdidas. Planificar, si fuera necesario, la

adquisición de nuevos componentes tecnológicos y/o subcontratación de
servicios para la restauración de la actividad en las instalaciones de “New
Perumore’s Strategy”. En caso contrario, preparar la adquisición o
Plan de
alquiler de los componentes necesarios para su completa restauración y
Recuperación
puesta en marcha del negocio.
Una vez completa la restauración de los sistemas y recuperada la
capacidad de trabajo, se creará un informe que detalle las acciones

78
realizadas desde el inicio hasta la puesta en marcha.
Se procederá a evaluar los resultados obtenidos en los diferentes Planes

de pruebas y se modificarán, si fuera necesario, los procedimientos
oportunos.
Este plan es de vital importancia, ya que con la ejecución de los planes
de pruebas pueden detectarse fallos o mejorar algunos puntos para que
la recuperación de los sistemas se realice en el menor tiempo posible.
En la ejecución de los planes de pruebas deberán participar todas las
Plan de análisis y personas que estén involucradas en la ejecución del Plan de
mejora: Contingencia.
Es necesario realizar acciones de capacitación y entrenamiento para las
personas que vayan a estar involucradas en la ejecución del Plan de
Contingencia. Con ello se conseguirá que todas las personas tengan
claro cuáles son sus responsabilidades y se reducirán los tiempos de
ejecución.
Los responsables de sistemas y dirección, de mutuo acuerdo, pondrán

en marcha el plan de prueba, previo acuerdo en la fecha con los
responsables de la empresa subcontratada para tales efectos. Estos
serán los pasos a seguir:
1. Los responsables de sistemas de “New Perumore’s Strategy”
recogerán los archivos de back up necesarios para realizar las
pruebas. “New Perumore’s Strategy” dispone de back up internos y
externos.
2. Los responsables de sistemas de “New Perumore’s Strategy”
comunicarán a los responsables de sistemas de la empresa
subcontratada que preparen los recursos necesarios para su
instalación.
Plan de pruebas
3. Una vez en las instalaciones de la empresa subcontratada se
procederá a la instalación de los sistemas de “New Perumore’s
Strategy”. Se creará un registro con los tiempos de ejecución de
cada paso.
4. Se comprobará que la instalación se ha realizado correctamente y
cuántos sistemas pueden estar operativos.
5. Realizar diversas pruebas con clientes y proveedores para

comprobar las comunicaciones.
6. Si las pruebas han sido satisfactorias se procederá a desinstalar
todo el sistema. Se debe comprobar que no se puede acceder de

79
ninguna manera a cualquier tipo de información.

7. Si las pruebas no han sido satisfactorias, se procederá a la revisión
de la instalación de los sistemas. Se creará un registro con los
sistemas que han dado algún tipo de problema y qué tipo de
resolución ha requerido.
8. Crear documento escrito por duplicado firmado por los responsables
de sistemas de “New Perumore’s Strategy” y de la empresa
subcontratada, dejando constancia de la prueba realizada y del
correcto funcionamiento de la misma.
9. Volver a las instalaciones e informar a los responsables de dirección
de la prueba realizada, personas implicadas y tiempo dedicado, para
de esta manera realizar posibles cambios en futuras ejecuciones.
10. Periodicidad: Se realizarán una vez al año, partiendo como punto de
inicio la creación de este plan.
GESTIÓN DEL CAMBIO
La dirección de “New Perumore’s Strategy” y el comité de dirección del proyecto de integración, así como
el equipo de SAP, han decidido trabajar sobre los siguientes puntos para llevar a cabo la gestión del cambio
que implica la integración de la nueva solución ERP de SAP.
 Elaboración de una estrategia de comunicación efectiva y eficaz para informar y movilizar a las
personas afectadas por el proyecto.
 Liderazgo y atención por parte de la alta dirección sobre el estado del proyecto de integración,
haciendo especial hincapié en conducir la organización hacia la consecución de objetivos en base
a los requerimientos y expectativas de los stakeholders.
 Asegurar la capacitación y formación del capital humano para explotar eficientemente el nuevo
sistema ERP, buscando alcanzar la excelencia operacional en los procesos de negocio.
 Identificación y seguimiento de impactos potenciales en la cultura de empresa con el objeto de
promover el alineamiento de la organización con el proyecto.
 Gestión de riesgos referentes a la transición y ejecución del plan de integración con el objeto de
minimizar posibles desviaciones con impacto en la gestión del cambio.
ESTRATEGIA DE COMUNICACIÓN
Así pues, la dirección de “New Perumore’s Strategy” y del proyecto han elaborado un plan de comunicación
para dar cobertura no únicamente a la organización interna del proyecto sino también a las partes
interesadas y la Alta Dirección. El plan tiene en consideración la importancia de asegurar que la alta
dirección se encuentre en constante comunicación con el jefe de proyecto y con los altos ejecutivo de las
partes interesadas si fuera necesario para comunicar el estado del proyecto, realizar reportes, promocionar
el proyecto o tomar decisiones sobre la evolución y próximos pasos a dar.

80
Como es obvio, el director o jefe de proyecto y los diferentes grupos involucrados, deben ser capaces de
mantener el nivel de comunicación con todos los miembros del equipo de proyecto, incluyendo
proveedores, la Alta Dirección y las partes interesadas.
El siguiente grafico resume el flujo de información dentro de la organización del proyecto
Ilustración 24. Flujo de información dentro de la organización del proyecto

81
La ilustración que se muestra a continuación representa el flujo de información por niveles

jerárquicos del organigrama de proyecto.
Ilustración 25. Flujo de información por niveles jerárquicos del organigrama de proyecto.
En esta representación podemos ver como las Newsletter publicadas por correo o por la Intranet, junto con los
eventos pueden llegar a comunicarse a todos los niveles de jerárquicos de la organización del proyecto con la
aprobación de la Alta Dirección. Sin duda, esta puede ser una estrategia de comunicación muy favorable para
alinear a la organización con el proyecto y de esta forma favorecer la Gestión del cambio.
Desde el equipo de proyecto destacamos los reportes como medio de comunicación para informar al equipo
directivo y de responsables del proyecto sobre el estado del mismo.
Son muchos otros, los medios de comunicación que podemos llegar a considerar, un ejemplo es utilizar
plataformas como “Sharepoint,” para compartir información y generar la documentación adecuada y compartirla
en cada fase.
Las tablas representan el plan de comunicación en base a reuniones y reportes clave del proyecto para
garantizar el seguimiento del proyecto y lo que es más importante, el alineamiento de todas las partes del
proyecto con la estrategia de la organización y objetivos que persigue el proyecto.

82
Tabla 15. Plan de comunicación de reuniones de proyecto
PLAN DE COMUNICACIÓN DE REUNIONES DE PROYECTO
RESPONSABLE TIPO AUDIENCIA PERIODO OBJETO

Reportar estado
Director de Reunión Comité Alta Dirección y y toma de
director de Mensual decisión
Proyecto Ejecutivo Recursos sobre el
proyecto.
Director
Recursos, Comunicar el
Director Proyecto Kick-off Responsables de Inicio Proyecto organigrama del
Informática proyecto y el plan
inicial.
Proveedores
Responsable de Reunión Equipo Técnico y Reportar estado

Workstream Semanal
Informática Proveedores de proyecto
Técnica
Reunión Responsables de Reportar y
Director de Workstream Control, realizar
Semanal
Recursos Finanzas y contabilidad y seguimiento de
Compras Compras proyecto
Líderes elegidos Comunicar
Reunión como personas seguimiento y
Director de para liderar los control del
Gestión del Quincenal
Proyecto procesos de proyecto contra
Cambio objetivos
cambio por áreas
funcionales esperados.
Comunicar
Reunión con Principales estado del
Director de
Partes Stackholders del Mensual proyecto y
Proyecto
Interesadas proyecto. favorecer la toma
de decisiones.
Comunicar el
Reunión de estado del
Director de Jefe Proyecto del proyecto y
Seguimiento de Semanal
Proyecto Proveedor realizar el
proyecto seguimiento del
mismo.
Plan de comunicaron mediante otros medios, Internet, Newsletter, Correos informativos:
PLAN DE COMUNICACIÓN / INTRANET y EVENTOS
RESPONSABLE TIPO AUDIENCIA PERIODO OBJETO

83
Director de
Proyecto En Identificar el estado del
Organización y proyecto a todas las partes
colaboración con Intranet Mensual
Proveedor interesadas y al equipo de
Responsable trabajo
Informática
Reporte Mensual con

resumen de noticias
Newsletter Correo Organización Trimestral atractivas para el empleado
sobre
el proyecto.
Director de Alinear la organización con

Con toda la los objetivos estratégicos
Proyecto Alta Evento. Semestral
organización del
Dirección proyecto.
MANTENIMIENTO
La organización de Recursos Humanos de “New Perumore’s Strategy”, conocedora de la necesidad de
gestionar el conocimiento ha decidido elaborar el siguiente plan de trabajo.
A corto plazo y en línea con le ejecución del proyecto de integración se acuerdan programas de formación y
planes de rotación entre empleados de diferentes departamentos:
 Programas de formación con proveedores (SAP y terceros).

 Integración de soluciones de e-Learning y cursos externos.
 Fomentar la rotación de personal entre departamentos de diferentes áreas.
También se ha decidido asignar presupuesto para adquirir recursos con talento que faciliten la integración del
nuevo sistema de información SAP. Con este objetivo se acuerda:
 La apertura de vacantes para profesionales con experiencia contrastada con SAP.

 2 vacantes en el área de tecnología
 1 vacante en el área de Finanzas
 1 vacante en Recursos Humanos
 Programa de incorporación de recién titulados en Informática
En el medio plazo, la dirección de Recursos Humanos de “New Perumore’s Strategy” pretende transferir el
conocimiento y experiencia existente en los empleados para ser utilizado como un recurso disponible para otros
en la organización.

84
En esta dirección se pretenden implementar aplicaciones relacionadas con la Gestión del Conocimiento que
evalúan y gestionan continuamente el proceso de acumulación y aplicación del capital intelectual. La gestión
del conocimiento debe ayudar a unificar diferentes estándares del pensamiento y práctica como son:
 El capital intelectual y el conocimiento de los empleados sobre los sistemas de información de la

organización y sobre los procesos operativos estructurados en base a las diferentes áreas que
conforman la organización.
 Llevar a cabo encuestas y actividades para evaluar la facilidad con que la organización aprende el uso
de la nueva solución ERP de SAP.
 Desarrollar un plan de acción en respuesta a los resultados del estudio sobre el aprendizaje de la
aplicación SAP ERP.
 Prácticas organizacionales para facilitar y fomentar el aprendizaje sobre el entorno de trabajo SAP con
los diferentes usuarios de la organización.
A su vez se acuerda que el departamento de Recursos Humanos lidere y fomente la implantación de las
siguientes propuestas de acción conjuntamente con el área de tecnología y los departamentos oportunos:
 Despliegue de una base de datos con librerías sobre los procesos de la organización para facilitar la
identificación y transferencia del conocimiento.
 Fomentar tecnologías como las Intranets para facilitar la gestión de contenido y la gestión documental
relativa a los procesos y aplicativos de la nueva solución ERP de SAP.
Finalmente se acuerda asignar presupuesto para llevar a cabo un programa de formación continua con el
objeto de potenciar aún más el conocimiento de los usuarios o empleados clave para “New Perumore’s
Strategy”
La dirección de “New Perumore’s Strategy” y el comité de dirección del proyecto han decidido aprobar el plan
de contingencia que a continuación se presenta:
Tabla 16. Aprobación - Plan de contingencia
INCIDENCIA RESPONSABLE ACCIÓN DE MITIGACIÓN CRITICIDAD
Impacto adverso en la  Ejecución del plan de

organización de un nuevo acción de Gestión del
sistema de la información Carlos Salvador Cambio.
Alta
que modifica los procesos Adjunto del director  Seguimiento del
de negocio. proyecto por parte de
dirección.
 Seguimiento periódico
Incidencias técnicas a lo del estado del
largo del proyecto que Ricardo Soler proyecto.
pongan en peligro la Responsable  Análisis de los Media
ejecución en tiempo Informática resultados de pruebas
calidad y coste. de validación.

85
Cumplimiento de las
normativas de marco legal  Plan de ejecución de la
de protección de datos Ana Santos Director normativa de
que pueden demorar el de Legal protección de datos Alta
proyecto.
 Ejecución de ejecución
del plan de
seguimiento de
Demoras en la gestión del
proveedores.
suministro por parte de Luis Gutiérrez
 Reuniones periódicas
proveedores y terceras Director Compras Alta
con los
partes implicadas.
principales
proveedores.
 Seguimiento de los
Desviaciones en el flujos de caja del
presupuesto inicial de proyecto en base al
Ángel Villar Director
partida que se acordó en plan de costes.
Tesorería Media
la aprobación del caso de  Revisión y gestión de
negocio. presupuestos.

86
10. BIBLIOGRAFÍA
- Cervantes Guerrero Alejandro. (2015, julio 20). Ciclo de vida de un sistema de información.
Recuperado de https://www.gestiopolis.com/ciclo-de-vida-de-un-sistema-de-informacion/
- SENN, James A. (1992) Análisis y Diseño de Sistemas de Información. Segunda Edición.

Editorial McGrawHill. México .
- Alarcón, V. F. (2006). Desarrollo de sistemas de información. Una metodología basada en el

modelado. Cataluña: UPC.
- Sommerville, I. (2005). Ingeniería del software. Madrid, España: Pearson Educación.
- Por Deisy Yanez. (2019b, 11 junio). Ciclo de Vida de un Sistema de Información: 6 Fases -
Lifeder. Recuperado 9 septiembre, 2019, de https://www.lifeder.com/ciclo-vida-sistema-
informacion/
- Jacobson, I, Booch, G, Rumbaugh,J(2000).”El proceso unificado de desarrollo de Software”.

Madrid: Addison Wesley
- Gestiopolis (s/f). Ciclo de vida de un sistema de información. Recuperado de: gestiopolis.com

[Consultado el 09 de setiembre del 2019]
- Acuna, T. (2005). A software process modelhandbook for incorporating people’s capabilities.

New York, USA.: Springer Science.
- Boehm, B. (1988). Software, The Incremental Commitment Spiral Model: Principles and
Practices for Successful Systems . Macmillan Editions.
- Cantone, D. (2006). IMPLEMENTACIÓN Y DEBUGGING. Recuperado el 06 de Septiembre de

2019, de https://ingsw.pbworks.com/f/Ciclo+de+Vida+del+Software.pdf

87
- EDURED. (2019). EDURED. Recuperado el 07 de Septiembre de 2019, de

https://www.ecured.cu/Modelo_de_prototipos
- Garzas, J. (04 de Octubre de 2012). javiergarzas.com. Obtenido de El ciclo de vida iterativo e

incremental y el riesgo de olvidarse del iterativo y quedarse solo con el incremental:
https://www.javiergarzas.com/2012/10/iterativo-e-incremental.html
- Gutiérres, D. A. (2013). Ingenieria de Software Avanzado. Obtenido de Atlantic Internacional

University
- Marichelo. (29 de Marzo de 2016). Modelo incremental. Recuperado el 07 de Septiembre de

2019, de Blog de Marichelo: http://marich.blogspot.es/1459223366/modelo-incremental/
- Olvany Torres, A. (2017). ANGELFIRE. Obtenido de PROTOTIPOS O PROTOTIPADOS

ANÁLISIS Y DISEÑO DE INFORMACIÓN : http://www.angelfire.com/ab8/morro/CICLO_DES.htm
- PTOLOMEO. (s.f.). PTOLOMEO. Obtenido de Ingeniería de Software:

http://www.ptolomeo.unam.mx:8080/xmlui/bitstream/handle/132.248.52.100/175/A4%20Cap%C3
%ADtulo%201.pdf?sequence=4
- Cruz, S. (22 de Octubre de 2007). http://scruz334.blogspot.es/1193024400/modelo-de-

construcci-n-de-prototipos/. Obtenido de Blog Diario Web Site:
http://scruz334.blogspot.es/1193024400/modelo-de-construcci-n-de-prototipos/
- Departamento de Informática. Universidad de Salamanca. (20 de Marzo de 2010). Modelos

de Procesos de Software. Obtenido de USAL: http://avellano.usal.es/~mmoreno/ASTema2.com
- Lawrence, S. (2002). Ingeniería de software. Pearson Education.
- Pressman, R. (1990). Sistemas de información para la administración. México: Grupo editorial

Iberoamericana.

88

Ciclo de Vida Si Final

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ciclo de Vida Si Final

Hochgeladen von

Copyright:

Verfügbare Formate

Ciclo de vida del sistema de información

Universidad Nacional Mayor de San Marcos

FACULTAD DE CIENCIAS CONTABLES

CURSO: Auditoría del Sistema de Información

TEMA: “Ciclo de vida del sistema de información”

 Aguirre Huacachi, Steven Miguel

PROFESOR: Carreño Escobedo, Jorge Raúl

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

CICLO DE VIDA DEL SISTEMA DE INFORMACIÓN

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

2. ETAPAS DEL CICLO DE VIDA DEL SISTEMA DE

Ilustración 1 Etapas del Ciclo de Vida de los Sistemas de Información

Fuente: Cohen & Asín (2005, p.283)

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

- Análisis detallado de requerimientos

- Etapa clave por la implementación del sistema

- Si el usuario detecta fallas, entra esta etapa

- Fase terminal, ya no útil o se debe reemplazar

3. FACTORES O VARIABLES DETERMINANTES

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

- ESPECIFICACIONES DEL USUARIO

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

4. MÉTODOS PARA ADQUIRIR UN SISTEMA

¿Cómo adquirir un sistema?

A. Ir a una tienda departamental y comprarnos uno de línea.

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

Tabla 1. Relación entre etapas y fases en el desarrollo de un sistema

Tabla 2. Ciclo de vida del desarrollo de sistemas

Ciclo de vida del desarrollo de sistemas

Fuente: Senn, 1992

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

Ilustración 2. Fases para el desarrollo de sistemas

Fuente: Cohen & Asín, 2005, p. 287

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

5. PRINCIPIOS GENERALES DEL CICLO DE VIDA DE

- Se deben Apoyar las actividades de la Organización

- Aplicar un método de resolución de problemas

En términos generales dichas fases o actividades se pueden resumir en:

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

Ilustración 3. Fases del Sistema de Información

Análisis Diseño Desarrollo de Implantación

Fuente. Elaboración propia.

- Justificar los sistemas como una inversión de capital

- Diseñar el sistema para el crecimiento

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

6. MODELO DE CICLO DE VIDA DE UN SISTEMA

6.1 MODELO CLÁSICO O CASCADA

6.2 MODELO DE CICLO DE VIDA INCREMENTAL

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

Ilustración 4. Modelo Iterativo Incremental (Gutiérres, 2013)

PROCESO DEL MODELO INCREMENTAL

Marichelo plantea que el proceso de Ciclo de vida incremental se divide en 4 partes:

Marichelo afirma que:

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

Ilustración 5. Modelo Incrementar de 4 partes (Marichelo, 2016)

Gutiérrez para el modelo incremental afirma se divide en 6 actividades:

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

Aguirre Huacachi, Bustamante Rojas, Pérez Suxe, Maqui Vargas,

El usuario se involucra más.

Difícil de evaluar el costo total.

Requiere gestores experimentados.