Presentación para la asignatura Sistemas de Información del IUPSM Barcelona

2. Introducción
Los Sistemas de Información proporcionan la comunicación y el poder de análisis que
muchas empresas requieren para llevar a cabo el comercio y administrar los negocios a una
escala global. Una metodología para el desarrollo de Sistemas de Información es un
conjunto de actividades llevadas a cabo para desarrollar y poner en marcha un Sistema de
Información.
Los analistas aplican en la práctica, la metodología de desarrollo de sistemas como un
esquema de resolución de problemas en la empresa con miras a buscar soluciones
informáticas que amplíen su competencia en este mundo globalizado. Deben planificar
antes de desarrollar el sistema, tomar en cuenta que todo sistema tiene un ciclo para
desarrollarse y consta de una serie de pasos que se van completando en diferentes etapas.
También deben considerar la factibilidad del sistema antes y durante el desarrollo del
mismo.

3. Planificación de proyecto de software
Es el Proceso de gestión para la creación de un Sistema o software, la cual encierra un conjunto de
actividades. Permite saber qué se deberá hacer y quien lo va hacer. El objetivo de la Planificación del
proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones
razonables de recursos costos y planificación temporal.
Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de
software, y deberían actualizarse regularmente a medida que progresa el proyecto. Además las
estimaciones deberían definir los escenarios del mejor caso, y peor caso, de modo que los resultados
del proyecto pueden limitarse.
Se encarga de:
• Calcular el tiempo estimado de terminación del proyecto (aproximadamente).
• Poner en evidencia los obstáculos relevantes del proyecto, con el fin de tomar las precauciones
necesarias.
• Establecer marcos de referencia que permite trabajar eficientemente y sin desperdicio de recursos.
• Permitir definir la metodología de desarrollo a seguir.
• Seleccionar las herramientas para la planificación (Cronograma de Actividades, Software de
Planificación).

4. Importancia como disciplina en el
desarrollo de sistemas de información
Al emprender un proyecto es fundamental realizar una adecuada planificación de las tareas ya que sin ésta el control sería
mucho más complicado. «Planificación» en este contexto está relacionado al término Ingeniería de Sistemas para enfatizar
que se buscan aclarar las exigencias del entorno y propiedades del sistema incluyendo el proceso de desarrollo del
software. Esto permite derivar exigencias que de otra manera pasarían desapercibidas. Específicamente:
• Entender a grandes rasgos el sistema a desarrollar. El sistema incluye no sólo el software a desarrollar sino también
otros componentes del sistema con que ese software deberá interactuar, tales como otro software, bases de datos,
hardware, recursos humanos y recursos organizacionales. (¿Qué se desarrolla?)
• Aclarar las metas de negocio del sistema, es decir las razones que llevan al cliente a costear este desarrollo. (¿Para qué
se desarrolla?)
• Identificar al cliente, distinguiendo entre los usuarios y los patrocinantes del sistema. (¿Para quién se desarrolla?)
• Que el cliente colabore con el desarrollador para que ambos puedan aprehender clara y precisamente los
requerimientos del software y de su proceso de desarrollo. (¿Qué permitirá hacer el sistema?¿Qué condiciones afectan
el desarrollo?)
• Identificar los riesgos (y oportunidades) asociados al desarrollo . (¿Qué problemas amenazan al desarrollo? ¿Qué
oportunidades deben aprovecharse?)
Cuando se proporciona un marco de trabajo adecuado, es posible hacer estimaciones razonables de recursos costos y
planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de
software, y deberían actualizarse regularmente medida que progresa el proyecto. Además las estimaciones deberían definir
los escenarios del mejor y peor caso, de modo que los resultados del proyecto pueden limitarse.

5. Ciclo de Vida de Sistemas de
Información
El ciclo de vida de un sistema de información puede ser definido como la organización y
realización de un conjunto de tareas y actividades diversas que abarcan desde el
nacimiento del reconocimiento de su necesidad hasta que estos sistemas se convierten en
obsoletos y son sustituidos por otros.
Robertshaw, Mecca y Rerick 1978 , señalan “ un sistema de información al igual que los
seres vivientes muestran un proceso de nacimiento y muerte bien definido.”
Nacimiento
Desarrollo
Operación
Mantenimiento
Muerte

6. Ciclo de Vida de Sistemas de
Información
Las fases del ciclo de vida son:
• Nacimiento
Esta fase da inicio al ciclo de vida con el surgimiento de una necesidad o de un
requerimiento por parte del usuario. En este momento debe hacerse un estudio de
factibilidad para decidir si en realidad se justifica el desarrollo del sistema.
• Desarrollo
Una vez realizado el estudio de factibilidad, se procede al desarrollo del sistema en el cual
se analizan los requerimientos y se elabora un diseño que servirá de base para el desarrollo.
Además se elaboran los programas necesarios que el sistema puede operar. Consiste en
diseñar, construir y adecuar los programas que se requieren para resolver el problema del
usuario.

7. Ciclo de Vida de Sistemas de
Información
• Operación
En este momento el sistema ya está terminado y el usuario trabaja introduciendo datos y
obteniendo información y reportes que soporten la operación de la empresa. Si el sistema
no satisface los requerimientos funcionales del usuario o si se detecta algún error en los
programas, es necesario pasar a la fase de mantenimiento.
• Mantenimiento
Consiste en corregir los errores que se detectan en los programas o en las funciones que
realiza el sistema. Esta fase además el usuario puede agregar nuevos requerimientos.
• Muerte
Un sistema de información llega a esta fase cuando deja de ser necesario o cuando debe
reemplazarse por otro mejor. Si al sistema original se le hacen mejoras o cambios, se inicia
nuevamente el proceso, debido a que el sistema anterior ya ha muerto y se desarrollará
uno nuevo.

8. Fases de Desarrollo de Sistemas de Información

9. Fases de Desarrollo de Sistemas de
Información
Los términos ciclo de vida del sistema y metodología de desarrollo del sistema con
frecuencia son intercambiados incorrectamente. La mayoría de los procesos de desarrollo
de sistemas se derivan de un ciclo de vida del sistema natural. Cuando un sistema
evoluciona del desarrollo a la operación y al mantenimiento, debe darse una conversión, en
algún punto en el tiempo, se vuelve obsoleto, muere y el ciclo se reinicia.
En realidad, un sistema puede estar en más de una etapa al mismo tiempo. Por ejemplo,
una versión puede estar en operación y soporte mientras que la siguiente versión está en
desarrollo. ¿Cómo contrasta esto con una metodología de desarrollo de sistemas? Una
metodología de desarrollo de sistemas “ejecuta” la etapa de desarrollo de sistemas del ciclo
de vida del sistema.
Cada sistema de información tiene su propio ciclo de vida. La metodología es el proceso
estándar para construir y mantener ese sistema y todos los demás sistemas de información
a través de sus ciclos de vida.

10. Fases de Desarrollo de Sistemas de
Información
• Definición de alcance
La primera fase. El propósito de la fase de definición de alcance es de dos sentidos. Primero,
responder la pregunta, “¿vale la pena atender este problema?”. Segundo y suponiendo que el
problema vale la pena, establecer el tamaño y las fronteras del proyecto, la visión del proyecto,
cualquier restricción o limitación, los participantes requeridos del proyecto y finalmente, el
presupuesto y el programa. Esta fase concluye con una decisión de seguir “adelante o detenerse”
por parte de los propietarios del sistema ya sea que estén de acuerdo con el alcance,
presupuesto y programa propuesto para el proyecto o bien deban reducir el alcance (para reducir
costos y tiempo) o cancelar el proyecto.
• Análisis del problema
Siempre hay un sistema existente, sin importar si actualmente utiliza tecnología de la
información. Esta fase estudia el sistema existente y analiza los resultados que proporciona al
equipo del proyecto con una comprensión más completa de los problemas que dispararon el
proyecto. El analista con frecuencia descubre nuevos problemas y responde la pregunta más
importante, “¿los beneficios de solucionar estos problemas exceden los costos de construir el
sistema para resolver estos problemas?” El producto de la fase de análisis del problema es un
conjunto de objetivos de mejora del sistema derivados de una comprensión profunda de los
problemas del negocio.

11. Fases de Desarrollo de Sistemas de
Información
• Análisis de requerimientos
La fase de análisis de requerimientos define y prioriza los requerimientos del negocio. Dicho de
manera simple, el analista se aproxima a los usuarios para averiguar lo que necesitan o requieren
del nuevo sistema, al evitar cuidadosamente cualquier discusión de tecnología o implantación
técnica. Ésta es tal vez la fase más importante del desarrollo de sistemas. Errores y omisiones en
el análisis de requerimientos resultarán en la insatisfacción del usuario con el sistema final y
modificaciones costosas.
• Diseño lógico
La fase del diseño lógico traduce los requerimientos del negocio a modelos de sistemas. El
término diseño lógico debe ser interpretado como “de tecnología independiente”, lo que significa
que las imágenes ilustran el sistema en forma independiente de cualquier solución técnica
posible, por tanto, modelan requerimientos del negocio que deben ser satisfechos mediante
cualquier solución técnica que quisiéramos considerar. En la práctica, las fases de análisis de
requerimientos y de diseño lógico casi siempre tienen un traslape considerable. En otras
palabras, mientras los requerimientos del negocio se identifican y se documentan, pueden ser
modelados. La definición de alcance, el análisis de problema , los análisis de requerimientos y las
fases de diseño lógico en conjunto son reconocidos por la mayoría de los expertos como el
análisis de sistema.

12. Fases de Desarrollo de Sistemas de
Información
• Análisis de decisión
Dados los requerimientos de negocios y los modelos de sistema lógicos, normalmente hay
diversas alternativas para diseñar un nuevo sistema de información que satisfagan esos
requerimientos. Un análisis de decisión se dispara por los requerimientos de negocios
validados más cualquier modelo lógico de sistemas y las especificaciones que se generan de
esos requerimientos. Las soluciones candidatas se identifican y se clasifican de acuerdo con
diversos criterios: factibilidad técnica, factibilidad operacional, factibilidad económica y
factibilidad de riesgos.
El equipo de proyecto normalmente busca la solución más factible, aquella que ofrece la
mejor combinación de factibilidad técnica, operacional, económica, de programa y de
riesgo. Distintas soluciones candidatas pueden ser más factibles en un solo criterio; sin
embargo, una solución normalmente demostrará ser la más factible cuando se consideran
todos los criterios. El producto fundamental de la fase de análisis de decisión es una
propuesta del sistema que puede ser presentada por escrito o verbalmente.

13. Fases de Desarrollo de Sistemas de
Información
• Diseño físico e integración
Dada la aprobación de la propuesta del sistema de la fase de análisis de decisión, al fin, usted puede
diseñar el nuevo sistema. el propósito de la fase de diseño físico e integración es transformar los
requerimientos de negocios (representados en parte por los modelos lógicos del sistema ) en las
especificaciones de diseño físico que guiarán la construcción del sistema. en otras palabras, el diseño
físico aborda con mayor detalle el cómo la tecnología será utilizada en el nuevo sistema. el diseño será
restringido por el modelo de arquitectura desde la fase anterior. también, el diseño re quiere apegarse a
cualquier estándar de diseño técnico interno que asegure que sea completo, útil, confiable, con buen
desempeño y calidad.
• Construcción y pruebas
Dado algún nivel de modelos y especificaciones de diseño físico (o prototipos de diseño ), podemos
comenzar a construir y probar los componentes del sistema para ese diseño. El propósito de la
construcción y la fase de pruebas es doble:
1) Construir y probar un Sistema que satisfaga los requerimientos de negocios y las especificaciones
de diseño Físico
2) Implantar las interfaces entre el nuevo sistema y los sistemas existentes.
Además, la documentación final (por ejemplo, sistemas de ayuda, manuales de capacitación, soporte de
escritorio de ayuda, instrucciones de control de producción) se desarrollará en preparación para la
capacitación y la operación del sistema. La fase de construcción puede también incluir una instalación
de software adquirido.

14. Fases de Desarrollo de Sistemas de
Información
• Operación del sistema y mantenimiento
Una vez que el sistema esté puesto en operación, requerirá un soporte continuo para el resto de su vida útil y
productiva. El soporte de sistemas consiste en las siguientes actividades continuas:
o Ayuda a usuarios: Sin importar qué tan bien hayan sido capacitados los usuarios y qué tan clara sea la
documentación final, eventualmente los usuarios requerirán ayuda adicional conforme surjan los
problemas.
o Arreglar los defectos de software: Los defectos de software son errores que se pasaron por alto en las
pruebas. Éstos son inevitables, pero normalmente pueden ser resueltos con el soporte de un experto.
o Recuperación del sistema. Ocasionalmente, una falla del sistema puede resultar en un “colapso” de
sistema y/o pérdida de datos. El analista de sistemas o los especialistas de soporte técnico pueden ser
llamados para recuperar el sistema.
o Adaptar el sistema a requerimientos nuevos. Los requerimientos nuevos pueden ser nuevos
requerimientos de negocios, nuevos problemas técnicos o nuevos requerimientos de tecnología.
Eventualmente, se espera que la retroalimentación del usuario y los problemas o las necesidades de negocios
cambiantes indiquen que es el momento de empezar de nuevo y reinventar el sistema. En otras palabras, el
sistema ha llegado a una entropía y se debe iniciar un nuevo proyecto para crear un proceso de desarrollo de
sistema completamente nuevo.

15. Planeación del proceso de desarrollo
de sistemas de información

16. Planeación del proceso de desarrollo
de sistemas de información
• Ámbito del Software.
Es la primera actividad llevada a cabo durante la planificación del proyecto. En esta etapa se
deben evaluar la función y el rendimiento que se asignaron al Software para establecer un ámbito
de proyecto que no sea ambiguo, e incomprensible para directivos y técnicos.
Se describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalúan
las funciones del ámbito y en algunos casos se refinan para dar mas detalles antes del comienzo
de la estimación. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta
y procesamiento, identifican los limites del software originados por el hardware externo, por la
memoria disponible y por otros sistemas existentes.
El Ámbito se define como un pre-requisito para la estimación y existen algunos elementos que se
debe tomar en cuenta como es la Obtención de la Información necesaria para el software. Para
esto el analista y el cliente se reúnen sobre las expectativas del proyecto y se ponen de acuerdo
en los puntos de interés para su desarrollo.

17. Planeación del proceso de desarrollo
de sistemas de información
• Recursos:
La Segunda tarea de la planificación del desarrollo de Software es la estimación de los recursos
requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una pirámide
donde las Herramientas (hardware y Software), son la base proporciona la infraestructura de
soporte al esfuerzo de desarrollo, en segundo nivel de la pirámide se encuentran los
Componentes reutilizables y en la parte mas alta de la pirámide se encuentra el recurso primario,
las personas (el recurso humano).
Cada recurso queda especificado mediante cuatro características:
• Descripción del Recurso.
• Informes de disponibilidad.
• Fecha cronológica en la que se requiere el recurso.
• Tiempo durante el que será aplicado el recurso.

18. Planeación del proceso de desarrollo
de sistemas de información
• Recursos Humanos
La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser
determinado después de hacer una estimación del esfuerzo de desarrollo (por ejemplo personas mes o
personas años), y seleccionar la posición dentro de la organización y la especialidad que desempeñara
cada profesional.
• Recursos o componentes de software reutilizables
Cualquier estudio sobre recursos de software estaría incompleto sin estudiar la reutilización, esto es la
creación y la reutilización de bloques de construcción de Software. Tales bloques se deben establecer
en catálogos para una consulta más fácil, estandarizarse para una fácil aplicación y validarse para la
también fácil integración.
• Recursos de entorno.
El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniería de
Software, incorpora Hardware y Software. El Hardware proporciona una plataforma con las
herramientas (Software) requeridas para producir los productos que son el resultado de la buena
practica de la Ingeniería del Software, un planificador de proyectos debe determinar la ventana
temporal requerida para el Hardware y el Software, y verificar que estos recursos estén disponibles.

19. Planeación del proceso de desarrollo
de sistemas de información
• Estimación del proyecto de software
En el principio el costo del Software constituía un pequeño porcentaje del costo total de los sistemas
basados en Computadoras. Hoy en día el Software es el elemento mas caro de la mayoría de los
sistemas informáticos. Un gran error en la estimación del costo puede ser lo que marque la diferencia
entre beneficios y perdidas, la estimación del costo y del esfuerzo del software nunca será una ciencia
exacta, son demasiadas las variables: humanas, técnicas, de entorno, políticas, que pueden afectar el
costo final del software y el esfuerzo aplicado para desarrollarlo.
Antes de hacer una estimación, el planificador del proyecto debe comprender el ámbito del software a
construir y generar una estimación de su tamaño.
• Estimación basada en el Proceso
Es la técnica más común para estimar un proyecto es basar la estimación en el proceso que se va a
utilizar, es decir, el proceso se descompone en un conjunto relativamente pequeño de actividades o
tareas, y en el esfuerzo requerido para llevar a cabo la estimación de cada tarea. Al igual que las
técnicas basadas en problemas, la estimación basada en el proceso comienza en una delineación de las
funciones del software obtenidas a partir del ámbito del proyecto. Se mezclan las funciones del
problema y las actividades del proceso. Como ultimo paso se calculan los costos y el esfuerzo de cada
función y la actividad del proceso de software.

20. Planeación del proceso de desarrollo
de sistemas de información
• Modelos de estimación.
o Los Modelos Empíricos
Donde los datos que soportan la mayoría de los modelos de estimación obtienen una muestra limitada
de proyectos. Por esta razón, el modelo de estimación no es adecuado para todas las clases de software
y en todos los entornos de desarrollo. Por lo tanto los resultados obtenidos de dichos modelos se deben
utilizar con prudencia.
o El Modelo COCOMO.
Barry Boehm propuso una jerarquía de modelos de estimación de Software con el nombre de COCOMO
(Constructive, Cost, Model) o modelo constructivo de costos. Su jerarquía está constituida por:
 Modelo I o básico: calcula el esfuerzo y el costo del desarrollo de Software en función del tamaño del
programa, expresado en las líneas estimadas.
 Modelo II o intermedio: calcula el esfuerzo del desarrollo de software en función del tamaño del
programa y de un conjunto de conductores de costos que incluyen la evaluación subjetiva del
producto, del hardware, del personal y de los atributos del proyecto.
 Modelo III o avanzado: incorpora todas las características de la versión intermedia y lleva a cabo una
evaluación del impacto de los conductores de costos en cada caso (análisis, diseño, etc.) del proceso
de ingeniería de Software.

21. Estudios de factibilidad en el
desarrollo de sistemas de información

22. Estudios de factibilidad en el
desarrollo de sistemas de información
Los objetivos en la Factibilidad de sistemas en un proyecto consiste en descubrir cual es el
objetivo de la organización, determinar si el software o sistema será de utilidad para
resolver los objetivos planteados en el proyecto. Los objetivos que se deben contemplar
son los recursos que la empresa proporciona y nunca definir recursos que la empresa no es
capaz de proporcionar. En las empresas se cuenta con una serie de objetivos que
determinan la posibilidad de Factibilidad de sistemas de un proyecto sin ser limitativos.
Estos objetivos son los siguientes:
• Reducción de errores y mayor precisión en los procesos.
• Reducción de costos mediante la optimización o eliminación de recursos no necesarios.
• Integración de todas las áreas y subsistemas de la empresa.
• Actualización y mejoramiento de los servicios a clientes o usuarios.
• Aceleración en la recopilación de datos.
• Reducción en el tiempo de procesamiento y ejecución de tareas.
• Automatización optima de procedimientos manuales.

23. Factibilidad Técnica
La factibilidad de sistemas Técnica debe demostrar la facultad del sistema para ponerse en
marcha y mantenerse durante el tiempo, además debe demostrar que la planeación del
sistema ha sido desarrollada cuidadosamente contemplando todas las restricciones y
objetivos, aprovechando los recursos que entrega la organización. Los conceptos que hay
que considerar son:
• El sistema funciona como corresponde (números de pruebas)
• El sistema esta desarrollado para mantenerse cerca de los consumidores.
• Escalas de producción (Ampliación o reducción de producción).
• Complementos que ayuden el desarrollo del proyecto: ¿Existe la tecnología necesaria?,
¿De donde se obtendrá la tecnología , ¿Se puede capacitar al personal con la nueva
tecnología? ¿Hay proveedores alternativos para el sistema?
Este estudio está destinado a recolectar información sobre los componentes técnicos que
posee la organización y la posibilidad de hacer uso de los mismos en el desarrollo e
implementación del sistema propuesto y de ser necesario, los requerimientos tecnológicos
que deben ser adquiridos para el desarrollo y puesta en marcha del sistema en cuestión.

24. Factibilidad Financiera o Económica
En esta etapa, hay que comprobar que el proyecto es sustentable económicamente. Se
debe justificar que la inversión genera una ganancia y demostrar que si el sistema no
cumple con su objetivo no habrán perdidas económicas o serán las mínimas. Se toman en
cuenta:
• Los Costos: Considerar costos Fijos y variables
• Las Ventas: demostrar como se ha definido el costo del producto y cuales son los
estimados de ventas por el periodo de al menos un año, justificando cada calculo,
investigación de mercado y estadísticas.
El estudio debe dar como resultado la factibilidad económica del desarrollo del nuevo
sistema de información. Se determinan los recursos para desarrollar, implantar, y mantener
en operación el sistema programado, haciendo una evaluación donde se pone de
manifiesto el equilibrio existente entre los costos intrínsecos del sistema y los beneficios
que se derivan de éste, lo cual permite observar de una manera más precisa las bondades
del sistema propuesto.

25. Factibilidad Operativa
La Factibilidad de Operativa, tiene como objetivo comprobar que a empresa u organización
será capaces de darle uso al sistema, que cuenta con el personal capacitado para hacerlo o
tiene los recursos humanos necesarios para mantener el sistema. El sistema no debe ser
complejo para los usuarios de la organización o los que operan el sistema, hay que evitar
que el usuario ocupe el sistema de manera que pueda ocasionar errores o darle un uso
indebido, simplificar las funciones y dar todo por servido.
Se debe evitar que a los usuarios les incomode el nuevo sistema, ya sea por que se sientan
desplazados de sus obligaciones o por la costumbre a un sistema antiguo, mantenerlo
amigable y comprensible para los operadores.
La Factibilidad de Operativa permite predecir, si se pondrá en marcha el sistema propuesto,
aprovechando los beneficios que ofrece, a todos los usuarios involucrados con el mismo, ya
sean los que interactúan en forma directa con este, como también aquellos que reciben
información producida por el sistema. Por otra parte, el correcto funcionamiento del
sistema en cuestión, siempre estará supeditado a la capacidad de los empleados
encargados de dicha tarea.

26. Factibilidad Legal
La Factibilidad Legal determina si los requisitos violan o atenta contra alguna ley o
reglamento. Es importante tomar en cuenta los siguientes aspectos:
• En los requerimientos legales del Proyecto para su operación y aprobación debe existir
el aseguramiento de que el proyecto no infringe ninguna norma o ley establecida ya sea
Municipalmente o Nacionalmente.
• Las licencias para el software a emplearse en la implantación de un sistema informático
de manera auténtica, con la finalidad de no tener inconvenientes legales a futuro y
determinar los derechos que tienen los autores sobre la documentación realizada por
estos en este proyecto, la cual es exclusividad de los desarrolladores del sistema.
• Formular un Contrato de Servicios.

27. Conclusión
Un Sistema de Información comprende varios pasos llevados a cabo durante las etapa de
planificación, la cual ayuda a verificar las necesidades de los clientes y la factibilidad del
sistema.
Cada sistema de información tiene su propio ciclo de vida. Por medio de las metodologías
de diseño y desarrollo se tiene el proceso estándar para construir y mantener ese sistema y
todos los demás sistemas de información a través de sus ciclos de vida.
Por supuesto, hay que tomar en cuenta las estimaciones de recursos para desarrollar
sistemas. Con ellos se puede ajustar el cómo se van a realizar los sistemas de información y
los procedimiento adecuados para que el software produzca ventajas competitivas y
cooperativas a los clientes.

28. Referencias Bibliográficas
Whitten, J. Bentley L. (2008).Análisis y diseño de sistemas de información (7ma ed). México.
Laudon, K. & Laudon, J. (2012). Sistemas de información gerencial. (12ed). México.
Luis R Castellanos. Desarrollo de Sistemas de Información. Recuperado de
https://desarrollodesistemas.wordpress.com/2009/07/02/metodologias-para-el-desarrollo-
de-sistemas-de-informacion
Manuel Cillero. Mi Circunstancia Digital. Blog. Recuperado de
https://manuel.cillero.es/doc/metrica-3/procesos-principales/psi/
Prof. Alejandro Teruel. Universidad Simón Bolívar, Sistemas de Programas . Recuperado de
https://ldc.usb.ve/~teruel/ci3715/clases/planif.html