UNIDAD 1: SISTEMAS DE INFORMACION

1. La tecnología de la Información.
2. Sistemas de Información. Funciones.
3. Elementos de un S.I.
4. Actividades de un SI.
5. Clasificaciones y Tipos de Sistemas de Información.
6. Los Sistemas de Información desde una perspectiva funcional y operacional.
Sistemas Transaccionales, Gerencial, de Apoyo a las Decisiones. Sistemas Estratégicos y Sistemas Expertos.
Sistemas de Automatización de oficinas, para ejecutivos y de planeación de recursos empresariales (ERP).
7. Estrategias para el desarrollo de sistemas: Ciclo de Vida, Prototipos, Técnicas de 4ta generación.
Incremental-Riesgos.
8. Herramientas de Análisis, de Diseño y de Desarrollo de Sistemas.
9. Participantes en el desarrollo de sistemas según el rol en la organización y según la función en el proceso.
Los usuarios: funciones y categorías.
10. Etapas en el ciclo de vida para el desarrollo de sistemas.
11. El Proyecto de Sistemas: Tareas de Planeación y de Control.
12. Herramientas para la Planeación y el Control.
13. Estudio de Factibilidad. Investigación técnica, operativa y económica-financiera.
14. Programación Extrema. Tiempo, Costo, Calidad y Alcance.

1. TECNOLOGÍA DE LA INFORMACION

(TI, o como IT por su significado en inglés: information technology) es la aplicación de equipos de telecomunicación
para almacenar, recuperar, transmitir y manipular datos, con frecuencia utilizado en el contexto de los negocios u
otras empresas. Su definición consistía en tres categorías: técnicas de procesamiento, la aplicación de métodos
estadísticos y matemáticos para la toma de decisión, y la simulación del pensamiento de orden superior a través de
programas computacionales.

SISTEMAS DE INFORMACION

Surge por/para
 Resolver un problema
 Aprovechar una oportunidad
 Dar respuesta a directivos para cumplir un objetivo.
 Acelerar un proceso.
 Agilizar un proceso mediante la eliminación de pasos innecesarios o duplicados.
 Combinar procesos.
 Reducir errores de entrada por medio de cambios en las formas de trabajar.
 Reducir salidas redundantes.
 Mejorar la integración de sistemas y subsistemas.
 Mejorar la facilidad de interacción de los clientes, proveedores y vendedores, con el sistema.

Según Kendall y Kendall:

 Revisar los outputs a través de criterios de desempeño. (Errores en el trabajo, trabajo lento, trabajo
incompleto, forma incorrecta de trabajo,).
 Observar el comportamiento de los empleados (Ausentismos, insatisfacción).
 Escuchar la retroalimentación externa a través de las quejas y las sugerencias de mejoras por parte de
clientes y proveedores.

1
 Según James Wetherbe:
 P (perfomance) Necesidad de mejorar el rendimiento.
 I (information) Necesidad de mejorar la información y los datos.
 E (economics) Necesidad de economía, control de costos y beneficio.
 C (control) Necesidad de aumentar el control o la seguridad.
 E (efficiency) Necesidad de mejorar la eficiencia de las personas y los procesos.
 S (service) Necesidad de mejorar el servicio de los clientes, proveedores, socios, empleados, etc.

En teoría de sistemas, un SI es un sistema, automatizado o manual, que abarca personas, máquinas, y/o métodos
organizados de recolección de datos, procesamiento, transmisión y diseminación de datos que representa
información para el usuario.
Un sistema de información puede ser manual o basado en computadores. Ambos están compuestos por personas,
datos de entradas, procesos y salidas. Los computacionales agregan los equipos o hardware, los programas o
software y las telecomunicaciones.
Todo ese conjunto de elementos interactúan entre sí para procesar los datos y la información (incluyendo procesos
manuales y automáticos) y distribuirla de la manera más adecuada posible en una determinada organización en
función de sus objetivos.
James Senn en su libro define los sistemas de información como un sistema de negocios de una empresa con
propósitos e interacción con otros componentes dentro de la compañía. Agrega que su tarea consiste en procesar la
entrada, mantener los archivos de datos en relación con la empresa y producir información, informes y otras salidas.

Kenneth y Julie Kendall por su parte, no los define, aunque sí indica que los sistemas de información se desarrollan
con diferentes propósitos dependientes de las necesidades de la empresa. Y agrega: “lo conforman los sistemas de
procesamiento de datos (que son sistemas de información computadorizados que se desarrollan para procesar
grandes volúmenes de información generada en las funciones administrativas), los sistemas de información para la
administración, o MIS, Management Information Systems (que toman en cuenta las funciones del procesamiento de
datos y se sustentan en la relación entre las personas y las computadoras), y los sistemas de apoyo para la toma de
decisiones, o DSS, Decision Support Systems (que hacen énfasis en el soporte en cada una de las etapas de la toma
de decisiones)”.
Dentro de todo sistema se pueden separar dos conceptos:
- lo que el sistema es, y lo asociamos con su estructura
- lo que el sistema hace, y lo asociamos con sus procesos funcionales

Características:
• Existen dentro de un entorno
• Se encuentran separados de su entorno por alguna frontera
• Tiene entradas y salidas. Reciben entradas de su entorno y envían salidas a su entorno
• Transforman sus entradas de alguna forma para producir salidas
• Dispone de interfaces que permiten la comunicación entre sistemas
• Puede estar formado por subsistemas

De acuerdo a la forma de procesamiento, con el tiempo, los SI fueron evolucionando, desde:

Sistemas en Batch (o lotes): el procesamiento es secuencial y masivo, el sistema registra en un formato y/o soporte
intermedio los datos de entrada en un momento de tiempo y los transfiere al soporte y formato definitivo después
con una validación de datos intermedia, donde se descartan los registros erróneos que deberán ser corregidos y
reingresados posteriormente en otro procesamiento. No tienen interacción con el usuario final sino con sus

2
operadores, ya que generalmente se encuentra instalado en un Centro de Cómputos, tanto el computador central
como las terminales.
Sistemas en Línea: Los datos de entrada son cargados directamente por los usuarios del área correspondiente en
forma interactiva. Estos usuarios también reciben directamente las salidas o resultados del procesamiento.
Requieren validaciones en el momento de la carga de los datos ya que serán registrados en la base de datos
Sistemas de Tiempo Real: son similares a los sistemas en línea pero el proceso de control devuelve resultados con la
suficiente rapidez como para influir en dicho ambiente y modificar o disparar acciones en ese momento (sistemas de
alarmas)

2. Elementos de un SI

• Equipo Computacional (H) Lo conforma el hardware.

• Recursos Humanos está compuesto por dos grupos:
El técnico, que posee los conocimientos especializados en el desarrollo de sistemas, siendo estos los:
Administradores, Líderes de Proyecto, Analistas, Programadores, Operadores y Capturistas.
El usuario, representado por las personas interesadas en el manejo de información vía cómputo, como
apoyo al mejor desempeño de sus actividades, siendo estos los:
Funcionarios, Contadores, Ingenieros, Empleados, Público, etc.
• Datos e Información Tecnológicos.
Es el conjunto de conocimientos, experiencias, metodologías y técnicas; que orientan la creación, operación
y mantenimiento de un sistema.
 Datos Administrativos.
Es la estructura orgánica de objetivos, lineamientos, funciones, procedimientos, departamentalización,
dirección y control de las actividades; que sustenta la creación y uso de los sistemas.
• Programas y Bases de Datos (S)
Son el software y los procedimientos utilizados para transformar y extraer
información.
Es donde se almacena toda la información que se requiere para la toma de
decisiones. La información se organiza en registros específicos e identificables.

3. Actividades de un SI

Datos e información
• DATOS: secuencia de hechos en bruto que representan eventos que ocurren en las organizaciones o en el entorno
físico antes de ser organizados y ordenados en una forma que las personas puedan entender y utilizar.
• INFORMACIÓN: datos que se han moldeados en una forma significativa y útil para los seres humanos.

4. CLASIFICACIONES Y TIPOS DE SISTEMAS DE INFORMACIÓN.

3
 5. Los sistemas de información desde una perspectiva funcional
• Sistemas de Ventas y marketing
• Sistemas de manufactura y producción
• Sistema de finanzas y contabilidad
• Sistema de gestión de recursos humanos.
Deben tener 3 funciones. La primera hace referencia a la práctica y coordinación de las acciones operativas
habituales a lo largo de la organización. La segunda función es ejercer el control para identificar las acciones que van
en contra de los objetivos de la organización, y a partir de aquí dirigir nuevas acciones rectificadoras de una forma
eficiente. La tercera es proporcionar la información necesaria para ayudar a tomar decisiones a nivel operativo,
directivo y estratégico. Las tres funciones tienen como objetivo final el correcto funcionamiento de la empresa.

Los sistemas de información desde una perspectiva operacional:

Los datos deben almacenarse según las necesidades de los usuarios del sistema, en lugar de imponer una nueva
forma de trabajar en función de una estructura de datos poco natural del nuevo sistema de información.

Sistemas transaccionales
Los sistemas de procesamiento de transacciones (TPS) son SI computarizada creados para procesar grandes
cantidades de datos relacionadas con transacciones rutinarias de negocios, como las nóminas y los inventarios.
Un TPS elimina el fastidio que representa la realización de transacciones operativas necesarias y reduce el tiempo
que una vez fue requerido para llevarlas a cabo de manera manual, aunque los usuarios aún tienen que capturar
datos en los sistemas computarizados.
Los sistemas de procesamiento de transacciones expanden los límites de la organización dado que le permiten
interactuar con entornos externos.

4
Es importante para las operaciones cotidianas de un negocio, que estos sistemas funcionen sin ningún tipo de
interrupción, puesto que los administradores recurren a los datos producidos por los TPS con el propósito de
obtener información actualizada sobre el funcionamiento de sus empresas.

Ejemplos:
 Facturación
 Liquidación de Sueldos
 Inventarios
 Cuentas Corrientes
 Control automático (ej de ascensores)
 Código de barras (control de inventario, siempre q este estandarizado)
 Sistema de bandas magnéticas (servicio de login o módulo de login)

Características de los S.T. o TPS

 Manipulan gran cantidad de datos de entrada y salida
 Son recolectores de información alimentando Bases de Datos
 Las transacciones son similares
 No hay procedimientos anormales
 Permiten ahorros significativos de mano de obra, debido a que automatizan procesos
 La justificación se realiza balanceando ingresos y egresos
 Se encuentran en paquetes.

Características esperables de un sistema transaccional

Rapidez: deben ser capaces de responder rápidamente (2 segundos aproximadamente).
Fiabilidad: deben ser altamente fiables, de lo contrario podría afectar a clientes, al negocio, a la reputación de la
organización, etc. En caso de fallas, debe tener mecanismos de recuperación y de respaldo de datos.
Inflexibilidad: no pueden aceptar información distinta a la establecida. Por ejemplo, el sistema transaccional de una
aerolínea debe aceptar reservas de múltiples agencias de viajes. Cada reserva debe contener los mismos datos
obligatorios, con determinadas características.

Propiedades ACID: conjunto de propiedades que garantizan que las transacciones en una base de datos son fiables.

Atomicidad: cualquier cambio de estado que produce una transacción es atómico. Es decir, ocurren todos o no
ocurre ninguno. En otras palabras, esta propiedad asegura que una operación se realiza o no se realiza, por lo tanto,
no puede quedar el sistema a medias.
Consistencia: propiedad que asegura que una transacción no romperá con la integridad de una base de datos, pues
respeta todas las reglas y directrices de ésta.
Aislamiento: propiedad que asegura que no se afectarán entre sí las transacciones. En otras palabras, dos o más
transacciones sobre los mismos datos no generarán un problema.
Durabilidad: propiedad que asegura la persistencia de una transacción, es decir, una vez que la transacción quedó
aceptada no podrá deshacerse aunque falle el sistema.

Sistemas de automatización de la oficina(OAS) y sistemas de trabajo del conocimiento (KWS)

Existen dos clases de sistemas en el nivel del conocimiento de una organización.

 Los OAS apoyan a los trabajadores de datos, quienes por lo general analizan la información con el propósito
de transformar los datos o manipularlos de alguna manera antes de compartirlos o, en su caso, distribuirlos
formalmente con el resto de la organización y en ocasiones más allá de ésta. Entre los componentes más
comunes de un OAS están el procesamiento de texto, las hojas de cálculo, la autoedición, la calendarización
electrónica y las comunicaciones mediante correo de voz, correo electrónico y videoconferencia.
 Los sistemas de trabajo del conocimiento (KWS, Knowledge Work Systems) sirven de apoyo a los
trabajadores profesionales en sus esfuerzos de creación de nuevo conocimiento y dan a éstos la posibilidad
de compartirlo con sus organizaciones o con la sociedad.

5
Sistemas expertos e inteligencia artificial

La inteligencia artificial (AI, Artificial Intelligence] es el campo general para los sistemas expertos. La motivación
principal de la AI ha sido desarrollar máquinas que tengan un comportamiento inteligente. Dos de las líneas de
investigación de la AI son la comprensión del lenguaje natural y el análisis de la capacidad para razonar un problema
hasta su conclusión lógica. Los sistemas expertos utilizan las técnicas de razonamiento de la AI para solucionar los
problemas que les plantean los usuarios de negocios (y de otras áreas).
Los sistemas expertos conforman una clase muy especial de sistema de información que se ha puesto a disposición
de usuarios de negocios gracias a la amplia disponibilidad de hardware y software como computadoras personales
(PCs) y generadores de sistemas expertos.
Un sistema experto [también conocido como sistema basado en el conocimiento) captura y utiliza el conocimiento
de un experto para solucionar un problema específico en una organización. Observe que a diferencia de un DSS, que
cede al responsable la toma de la decisión definitiva, un sistema experto selecciona la mejor solución para un
problema o una clase específica de problemas.
Los componentes básicos de un sistema experto son la base de conocimientos, un motor de inferencia que conecta
al usuario con el sistema mediante el procesamiento de consultas realizadas con lenguajes como SQL [Structured
Query Language, lenguaje de consultas estructurado) y la interfaz de usuario. Profesionales conocidos como
ingenieros de conocimiento capturan la pericia de los expertos, construyen un sistema de cómputo que contiene
este conocimiento experto y lo implementan. Es muy factible que la construcción e implementación de sistemas
expertos se constituya en el trabajo futuro de muchos analistas de sistemas.
• Sistemas basados en el conocimiento
• Pertenecen al campo de la inteligencia artificial
• Permiten el manejo de bases de conocimiento integradas por una serie de reglas
• El conocimiento se obtiene a través de la experiencia de un especialista o un experto
• A diferencia de los sistemas de apoyo, S.E. seleccionan la mejor solución al problema
• Beneficios: reducción del personal, mejora en el entrenamiento personal.
• Inteligencia Artificial: ciencia que estudia el comportamiento inteligente, con el fin de imitar o simular las
habilidades humanas mediante la creación y utilización de máquinas y computadoras
• Habilidades humanas: razonamiento, aprendizaje, capacidad mecánica y capacidad sensorial
• Áreas: Simulación, Robótica, Lenguajes Naturales y los Sistemas Expertos
• Elementos de un Sistema Experto: Bases de conocimientos, máquina de inferencia, lenguaje de inteligencia
artificial y una interfaz
Características:
• Típicamente su forma de desarrollo es a base de incrementos y a través de su evolución permanente dentro
de la organización.
• Se requiere de un experto en la estructuración y captación del conocimiento.
• Apoyan el proceso de innovación dentro de la empresa.
Ejemplos: Sistema de Prospección minera, Sistema de Configuración aplicaciones Distribuidas, Sistemas de
Diagnóstico Médico, Sistema de Detección de Fraude Telefónico, Robots, etc.

Sistemas de información gerencial (MIS)

Los (MIS, Management Information Systems] no reemplazan a los TPS, más bien, incluyen el procesamiento de
transacciones. Los MIS son sistemas de información computarizados cuyo propósito es contribuir a la correcta
interacción entre los usuarios y las computadoras. Debido a que requieren que los usuarios, el software [los
programas de cómputo] y el hardware (las computadoras, impresoras, etc.), funcionen de manera coordinada, los
sistemas de información gerencial dan apoyo a un espectro de tareas organizacionales mucho más amplio que los
TPS, como el análisis y la toma de decisiones.
Para acceder a la información, los usuarios de un sistema de información gerencial comparten una base de datos
común. Ésta almacena datos y modelos que ayudan al usuario a interpretar y aplicar los datos. Los sistemas de
información gerencial producen información que se emplea en la toma de decisiones. Un sistema de información
gerencial también puede contribuir a unificar algunas de las funciones de información computarizadas de una
empresa, a pesar de que no existe como una estructura individual en ninguna parte de ésta.

6
  Ayuda a los administradores a tomar decisiones estructuradas y resolver problemas del nivel medio de la
empresa
 Una herramienta para soportar las funciones operativas
 Recurren a datos almacenados por los sistemas transaccionales
 incluye las siguientes actividades: Organización, selección (filtro), totalización de datos para entregar en
forma periódica
 No pueden adaptarse fácilmente a paquetes disponibles en el mercado.
Características de los S.G

 Se incorporan a la organización a posteriori de los S.T.

 Reportes - Informes
 Funcionan a la par de los sistemas transaccionales
 Ejemplo: Sistemas de Gestión Académica, Sistema de Control de Proveedores, Sistema de Planificación de la
Producción, Sistema de Evaluación de Proveedores, Sistema de Seguimiento de Ordenes de Trabajo

Sistemas de soporte de decisiones (DSS)

Los sistemas de apoyo a la toma de decisiones (DSS, Decisión Support Systems] constituyen una clase de alto nivel de
sistemas de información computarizada. Los DSS coinciden con los sistemas de información gerencial en que ambos
dependen de una base de datos para abastecerse de datos. Los sistemas de apoyo a la toma de decisiones se ajustan
más al gusto de la persona o grupo que los utiliza que a los sistemas de información gerencial tradicionales. En
ocasiones se hace referencia a ellos como sistemas que se enfocan en la inteligencia de negocios.
Como implica el termino estos sistemas no toman decisiones por sí mismos, sino ayudan a los administradores y a
otros profesionales de una organización a la toma de decisiones inteligentes y documentadas acerca de los diversos
aspectos de la operación. Típicamente los sistemas DSS no actúan de manera activa, sino que más bien son de tipo
ad hoc cuando se los necesita.
Por ejemplo, entre estos sistemas podemos encontrar programas de hojas de cálculo, sistemas de análisis
estadístico, programas de pronósticos de mercados. Una de las principales características de estos es que no solo
recolectan y muestran datos, sino que también realizan varios tipos de análisis estadísticos y matemáticos, además
de presentar la información en diversas formas graficas.
Como ejemplo podemos ver graficas de hojas de cálculos financiero. Características que puede usar un gerente para
evaluar ganancias de una división de su empresa.
Ejemplos:
Sistemas de Planificación estratégica, Sistemas Evaluación de mercados, Sistema de Gestión de Clientes.
 Recurren a datos almacenados por los sistemas transaccionales
 Apoyan a los administradores del nivel medio y estratégico mediante la generación y evaluación sistemática
de diferentes alternativas o escenarios de decisión.

Ventajas del uso de los DSS. Desventajas pueden ser:

 Menores costos. • Falta de integridad y consolidación en la
 Muy baja dependencia de personas que administración de la información.
se encuentran fuera del control de • Problemas de seguridad de la información.
tomador de decisiones. • Pérdida del control administrativo por parte
del área de informática.

Permite al usuario utilizar modelos clásicos, que se encuentran desarrollados y disponibles, formando la base de
modelos. Pueden incluir: Inventarios, Control de proyectos, Programación lineal, Simulación, Colas, Análisis
estadísticos, Planeación financiera y generación de esencias

Aplicaciones de los dss

 Establecimiento de la misión de una empresa y de estrategias que ayudarán a que la misión se cumpla.

7
 Evaluación de administradores. Para incrementar el sueldo de un administrador o para verificar que esté
cumpliendo con su deber.
 Planeación de sistemas de información. Cuando se requiere introducir nueva tecnología de sistemas de
información es necesario modificar el plan de sistemas
 Soporte en negociaciones. Apoyar los trabajos que visuales, como la selección de un empaque para un nuevo
producto.
 Apoyar los trabajos que involucran diseño y revisiones de control de calidad.
 Apoyar una decisión en particular.

Sistemas de apoyo a la toma de decisiones en grupo GDSS

Cuando los grupos requieren trabajar en conjunto para tomar decisiones semiestructuradas o no estructuradas, un
sistema de apoyo a la toma de decisiones en grupo (GDSS, Group Decisión Support System) podría ser la solución.
Este tipo de sistemas, que se utilizan en salones especiales equipados con diversas configuraciones, faculta a los
miembros del grupo a interactuar con apoyo electrónico —casi siempre software especializado— y la asistencia de
un facilitador especial. Los GDSS tienen el propósito de unir a un grupo en la búsqueda de la solución a un problema
con la ayuda de diversas herramientas como los sondeos, los cuestionarios, la lluvia de ideas y la creación de
escenarios. El software GDSS puede diseñarse con el fin de minimizar las conductas negativas de grupo comunes,
como la falta de participación originada por el miedo a las represalias si se expresa un punto de vista impopular o
contrario, el control por parte de miembros elocuentes del grupo y la toma de decisiones conformista.

Sistemas de apoyo a ejecutivos (ESS)

Cuando los ejecutivos recurren a la computadora, por lo general lo hacen en busca de métodos que los auxilien en la
toma de decisiones de nivel estratégico. Los sistemas de apoyo a ejecutivos (ESS, Executive Support Systems) ayudan
a estos últimos a organizar sus actividades relacionadas con el entorno externo mediante herramientas gráficas y de
comunicaciones, que por lo general se encuentran en salas de juntas o en oficinas corporativas personales. A pesar
de que los ESS dependen de la información producida por los TPS y los MIS, ayudan a los usuarios a resolver
problemas de toma de decisiones no estructuradas, que no tienen una aplicación específica, mediante la creación de
un entorno que contribuye a pensar en problemas estratégicos de una manera bien informada. Los ESS amplían y
apoyan las capacidades de los ejecutivos al darles la posibilidad de comprender sus entornos.

Los sistemas de planeación estratégica son usados por gerentes en jefe para evaluar y analizar la misión de la
organización. En lugar de dar consejos acerca de alguna decisión de negocios aislada, estos sistemas ofrecen
consejos más amplios y generales acerca de la naturaleza del mercado, las preferencias de los consumidores, el
comportamiento de la competencia etc. Esto usualmente cae dentro de los dominios del departamento de
planeación estratégica o del departamento de planeación a largo plazo, aunque pudiera tratarse de una actividad
más informal, llevada a cabo por alguno de los gerentes.
La planeación estratégica no son tanto programas de computadoras en sí, son complejas combinaciones de
actividades y procedimientos.
EJEMPLO:
ESS, sistemas de apoyo a ejecutivos.
Un ejemplo es el sistema comprado por Pratt & Whitney, una empresa que se dedica a la producción de motores de
propulsión a chorro. Ellos compraron el sistema denominado Commander EIS que permite representaciones a todo
color y un menú imaginativo que puede aprenderse intuitivamente, con variaciones y excepciones que son
destacadas mediante colores. Los usuarios pueden ingresar datos mediante una pantalla táctil, ratón o teclado y
pueden agrandar las imágenes para mayores niveles de detalle, ya sea navegando por sí mismos o siguiendo
caminos previamente definidos.
El Commnander EIS permite a la organización hacer el seguimiento de los parámetros de la calidad y factibilidad de
las medidas tomadas para cada motor a reacción por tipo de cliente. Los datos aparecen de los sistemas actuales de
producción y proporcionan información sobre la confiabilidad, disponibilidad de motores y partes, y sobre las
entregas.

8
Otro ejemplo es el sistema implantado por la New York State Office of General Services que es responsable de dar
servicio a otras dependencias en Nueva York. El sistema permite que los ejecutivos verifiquen el estado por
programa, comparando el presupuesto con el gasto real y mostrando el gasto estimado hasta el final del año fiscal.
La administración puede bajar para ver los detalles específicos en cada categoría. El sistema sólo contiene datos
crudos, permitiendo a los usuarios una gran flexibilidad para agregarlos y analizarlos para satisfacer sus
necesidades. El sistema es operado por medio de un menú muy fácil de usar. Los nuevos usuarios son capacitados
mediante una demostración que dura media hora, y la experiencia ha demostrado que es todo lo que necesitan. No
se cuenta con un manual del usuario. DURACIÓN:45 minutos

9
SISTEMAS DE PLANEACIÓN DE RECURSOS EMPRESARIALES (ERP)

Muchas organizaciones consideran los beneficios potenciales que se derivan de la integración de los diversos SI que
existen en los diferentes niveles administrativos, con funciones dispares.
Mediante los sistemas ERP se realiza el seguimiento de las diversas áreas de una compañía, desde la fabricación de
un producto, pasando por la logística, la distribución, el control de stock, la contabilidad de la organización y demás.
Se trata básicamente de un software desarrollado para el manejo eficaz de la información de las empresas, que
permite tomar decisiones acertadas en los momentos oportunos, gracias a la veracidad de los datos que se manejan
mediante el ERP.
Entre el software más conocido de ERP se encuentran SAP, PeopleSoft y paquetes de Oracle y J.D. Edwards. Algunos
de estos paquetes están diseñados para migrar a las empresas a la Web. Por lo general, los analistas y algunos
usuarios requieren capacitación, apoyo técnico y mantenimiento por parte del fabricante para diseñar, instalar, dar
mantenimiento, actualizar y utilizar de manera apropiada un paquete de ERP en particular.

 Permite a una compañía automatizar e integrar la mayor parte de sus procesos de su negocio, compartir
datos, producir y acceder a la información en tiempo real.
 Soportan las múltiples actividades o procesos de la empresa debido a su diseño modular, incluyendo
planeación de producción, compras, inventarios, proveedores, etc.
 Han sido conceptualizados como plataformas que requieren una gran inversión económica y requieren la
mayor parte de las veces, de una reestructuración organizacional o reingeniería de los procesos de la
empresa
 La integración de todos estos datos en una base de datos centralizada permite la optimización de los
procesos y la obtención de la información de manera más rápida y precisa y además, todos los usuarios
pueden compartir la información y acceder a ella en forma constante.

6. ESTRATEGIAS PARA EL DESARROLLO DE SISTEMAS

Cada una de estas etapas lleva asociada una serie de tareas que deben realizarse, y una serie de documentos
(en sentido amplio: software) que serán la salida de cada una de estas fases y servirán de entrada en la fase
siguiente.
La elección de un paradigma u otro se realizan de acuerdo con la naturaleza del proyecto y de la aplicación, los
métodos a usar y los controles y entregas requeridos.

EL CICLO DE VIDA EN CASCADA (O CICLO DE VIDA CLÁSICO).

El ciclo de vida en cascada exige un enfoque sistemático y secuencial del desarrollo de software, que comienza en el
nivel de la ingeniería de sistemas y avanza a través de fases secuenciales sucesivas. Estas fases son las siguientes:

1. Ingeniería y análisis del sistema.

Consiste en un análisis de las características y el comportamiento del sistema del cual el software va a formar parte.
Comprende, por tanto, los requisitos globales a nivel del sistema, así como una cierta cantidad de análisis y de
diseño a nivel superior.
En el caso de que queramos construir un sistema nuevo, por ejemplo un sistema de control, deberemos analizar
cuáles son los requisitos y la función del sistema, y luego asignaremos un subconjunto de estos requisitos al
software.
2. Análisis de requisitos del software.
El análisis de requisitos debe ser más detallado para aquellos componentes del sistema que vamos a implementar
mediante software. Los requisitos, tanto del sistema como del software deben documentarse y revisarse con el
cliente.
El ingeniero del software debe comprender:
1. cuáles son los datos que se van a manejar
2. cuál va a ser la función que tiene que cumplir el software
3. cuáles son los interfaces requeridos
4. cuál es el rendimiento que se espera lograr.

10
 3. Diseño.
El diseño se aplica a cuatro características distintas del software:
1. la estructura de los datos,
2. la arquitectura de las aplicaciones,
3. la estructura interna de los programas
4. las interfaces.
El diseño es el proceso que traduce los requisitos en una representación del software de forma que pueda conocerse
la arquitectura, funcionalidad e incluso la calidad del mismo antes de comenzar la codificación.

4. Codificación. La codificación consiste en la traducción del diseño a un formato que sea legible para la
máquina.
Si el diseño es lo suficientemente detallado, la codificación es relativamente sencilla. Se extrae la información del
análisis del sistema y del análisis de requisitos. De los diagramas y por último, en la codificación se traducen estos
diagramas de diseño a un lenguaje fuente, que luego se traduce - se compila -para obtener un programa ejecutable.

5. Prueba. El objetivo es comprobar que no se hayan producido errores en alguna de las fases de traducción
anteriores, especialmente en la codificación. Para ello deben probarse todas las sentencias, no sólo los casos
normales y todos los módulos que forman parte del sistema.

6. Utilización.
Una vez superada la fase de pruebas, el software se entrega al cliente y comienza la vida útil del mismo. La
fase de utilización se solapa con las posteriores - el mantenimiento y la sustitución - ydura hasta que el
software, ya reemplazado por otro, deje de utilizarse.
7. Mantenimiento.
El software sufrirá cambios a lo largo de su vida útil. Estos cambios pueden ser debidos a tres causas:
1. Que, durante la utilización, el cliente detecte errores en el software: los errores latentes.
2. Que se produzcan cambios en alguno de los componentes del sistema informático: por ejemplo cambios en
la máquina, en el sistema operativo o en los periféricos.
3. Que el cliente requiera modificaciones funcionales (normalmente ampliaciones) no contempladas en el
proyecto.
En cualquier caso, el mantenimiento supone volver atrás en el ciclo de vida, a las etapas de codificación, diseño o
análisis dependiendo de la magnitud del cambio.
Estas vueltas atrás no son controladas, ni quedan explícitas en el modelo, y este es uno de los problemas que
presenta este paradigma

8. Sustitución.
Es conveniente realizarla por fases, si esto es posible, además, es conveniente mantener los dos sistemas
funcionando en paralelo durante algún tiempo para comprobar que el sistema nuevo funcione correctamente y
para asegurarnos el funcionamiento normal de la empresa aún en el caso de que el sistema nuevo falle y tenga que
volver a alguna de las fases de desarrollo.
La sustitución implica el desarrollo de programas para la interconexión de ambos sistemas, el viejo y el nuevo, y para
trasvasar la información entre ambos, evitando la duplicación del trabajo de las personas encargadas del proceso de
datos, durante el tiempo en que ambos sistemas funcionen en paralelo.

• En realidad los proyectos no siguen un ciclo de vida estrictamente secuencial como propone el modelo. Siempre
hay iteraciones. El ejemplo más típico es la fase de mantenimiento.
• Es difícil que se puedan establecer inicialmente todos los requisitos del sistema.
• Hasta que se llega a la fase final del desarrollo: la codificación, no se dispone de una versión operativa del
programa. Como la mayor parte de los errores se detectan cuando el cliente puede probar el programa no se
detectan hasta el final del proyecto, cuando son más costosos de corregir y más prisa
Al menos este modelo describe una serie de pasos genéricos que son aplicables a cualquier otro paradigma,
refiriéndose la mayor parte de las críticas que recibe a su carácter secuencial.

11
TÉCNICAS DE CUARTA GENERACIÓN.

Las técnicas de cuarta generación tienen por objeto el facilitar el desarrollo de software:
Facilitan al que desarrolla el software el especificar algunas características del mismo a alto nivel. Luego, la
herramienta genera automáticamente el código fuente a partir de esta especificación.
Los tipos más habituales de generadores de código cubren uno o varios de los siguientes aspectos: Acceso a bases de
datos utilizando lenguajes de consulta de alto nivel (derivados normalmente de SQL). Con ello no es necesario
conocer la estructura de los ficheros o tablas ni de sus índices.

1. Acceso a bases de datos utilizando lenguajes de consulta de alto nivel (derivados normalmente de
SQL). Con ello no es necesario conocer la estructura de los ficheros o tablas ni de sus índices.
2. Generación de código. A partir de una especificación de los requisitos se genera automáticamente
toda la aplicación.
3. Generación de pantallas. Permiten diseñar la pantalla dibujándola directamente incluyendo además
el control del cursor y la gestión de errores de los datos de entrada.
4. Gestión de entornos gráficos.
5. Generación de informes. (de forma similar a las pantallas).

Sin embargo el problema es el mismo que se plantea en el ciclo de vida clásico: es muy difícil que se puedan
establecer todos los requisitos desde el comienzo.
Si la especificación es pequeña, podemos pasar directamente del análisis de requisitos a la generación automática de
código, sin realizar ningún tipo de diseño.
Pero si la aplicación es grande, se producirán los mismos problemas que si no usamos técnicas de cuarta generación:
mala calidad, dificultad de mantenimiento y poca aceptación por parte del cliente).
Es necesario, por tanto, realizar un cierto grado de diseño (al menos lo que hemos llamado una estrategia de diseño,
puesto que el propio generador se encarga de parte de los detalles del diseño tradicional: descomposición modular,
estructura lógica y organización de los ficheros, etc.).

12
 Es necesario, por tanto, realizar un cierto grado de diseño (al menos lo que hemos llamado una estrategia de
diseño, puesto que el propio generador se encarga de parte de los detalles del diseño tradicional:
descomposición modular, estructura lógica y organización de los ficheros, Las herramientas de cuarta generación
se encargan también de producir automáticamente la documentación del código generado, pero esta
documentación es mala. Es necesario completarla hasta obtener una documentación con sentido.
Con respecto a las pruebas suponemos que el código generado es correcto y acorde con la especificación, y que
no contiene los típicos errores de la codificación manual.
Pero en cualquier caso es necesaria la fase de pruebas, en primer lugar para comprobar la eficiencia del código
generado (la generación automática de los accesos a bases puede producir código muy eficiente cuando el
volumen de información es grande (p.ej.: las distintas formas de relacionar tablas en SQL), también para detectar
los errores en la especificación a partir de la cual se generó el código, y, por último, para que el cliente
compruebe si el producto final satisface sus necesidades.
El resto de las fases del ciclo de vida usando estas técnicas es igual a las del paradigma del ciclo de vida en
cascada, del que este no es más que una adaptación a las nuevas herramientas de producción de software.

 No son más fáciles de utilizar que los lenguajes de tercera generación. En concreto, muchos de los
lenguajes de especificación que utilizan pueden considerarse como lenguajes de programación, de un nivel
algo más alto que los anteriores.
 El código fuente que producen es ineficiente.(el ejemplo de antes de SQL). Al estar generado
automáticamente no pueden hacer uso de los trucos habituales para aumentar el rendimiento, que se basan
en el buen conocimiento de cada caso particular.
 Sólo son aplicables al software de gestión. Esto es cierto, la mayoría de las herramientas de cuarta
generación están orientadas a la generación de informes a partir de grandes bases de datos

CONSTRUCCIÓN DE PROTOTIPOS.

Dos de las críticas que se hacían al modelo de ciclo de vida en cascada eran:
 que es difícil tener claros todos los requisitos del sistema al inicio del proyecto
 y que no se dispone de una versión operativa del programa hasta las fases finales del desarrollo
Lo que dificulta la detección de errores y deja también para el final el descubrimiento de los requisitos inadvertidos
en las fases de análisis
En general, cualquier aplicación que presente mucha interacción con el usuario, o que necesite algoritmos que
puedan construirse de manera evolutiva, yendo de lo más general a lo más específico es una buena candidata.
No obstante, hay que tener en cuenta la complejidad: si la aplicación necesita que se desarrolle una gran cantidad
de código para poder tener un prototipo que enseñar al usuario, las ventajas de la construcción de prototipos se
verán superadas por el esfuerzo de desarrollar un prototipo que al final habrá que desechar o modificar mucho.
También hay que tener en cuenta la disposición del cliente para probar un prototipo y sugerir modificaciones de los
requisitos.
Es bastante frecuente que el producto de ingeniería desarrollado presente un buen rendimiento durante la fase de
pruebas realizada por los ingenieros antes de entregarlo al cliente (pruebas que se realizarán normalmente con unos
pocos registros en la base de datos o un único terminal conectado al sistema), pero que sea muy ineficiente, o
incluso inviable, a la hora de almacenar o procesar el volumen real de información que debe manejar el cliente.

En otros casos, el prototipo servirá para modelar y poder mostrar al cliente cómo va a realizarse la E/S de datos en la
aplicación, de forma que éste pueda hacerse una idea de cómo va a ser el sistema final, pudiendo entonces detectar
deficiencias o errores en la especificación aunque el modelo no sea más que una cáscara vacía.

Según esto un prototipo puede tener alguna de las tres formas siguientes:

13
  un prototipo, en papel o ejecutable en ordenador, que describa la interacción hombre-máquina y los listados
del sistema.
 un prototipo que implemente algún(os) subconjunto(s) de la función requerida, y que sirva para evaluar el
rendimiento de un algoritmo o las necesidades de capacidad de almacenamiento y velocidad de cálculo del
sistema final.
 un programa que realice en todo o en parte la función deseada pero que tenga características (rendimiento,
consideración de casos particulares, etc.) que deban ser mejoradas durante el desarrollo del proyecto.

A partir del diseño construiremos el prototipo. Existen herramientas especializadas en generar prototipos
ejecutables a partir del diseño.
En cualquier caso, el objetivo es siempre que la codificación sea rápida, aunque sea en detrimento de la calidad del
software generado.
Una vez listo el prototipo, hay que presentarlo al cliente para que lo pruebe y sugiera modificaciones.
A partir de estos comentarios del cliente y los cambios que se muestren necesarios en los requisitos, se procederá a
construir un nuevo prototipo y así sucesivamente hasta que los requisitos queden totalmente formalizados, y se
pueda entonces empezar con el desarrollo del producto final.

· Parte del trabajo realizado durante la fase de diseño rápido (especialmente la definición de pantallas e informes)
puede ser utilizada durante el diseño del producto final. Además, tras realizar varias vueltas en el ciclo de
construcción de prototipos, el diseño del mismo se parece cada vez más al que tendrá el producto final.
Hay que tener en cuenta que un análisis de requisitos incorrecto o incompleto, cuyos errores y deficiencias se
detecten a la hora de las pruebas o tras entregar el software al cliente, nos obligará a repetir de nuevo las fases de
análisis, diseño y codificación, que habíamos realizado cuidadosamente, pensando que estábamos desarrollando el
producto final. Al tener que repetir estas fases, sí que estaremos desechando una gran cantidad de trabajo
Uno de los problemas que suelen aparecer siguiendo el paradigma de construcción de prototipos, es que con
demasiada frecuencia el prototipo pasa a ser parte del sistema final.
Se olvida aquí que el prototipo ha sido construido de forma acelerada, sin tener en cuenta consideraciones de
eficiencia, calidad del software o facilidad de mantenimiento, o que las elecciones de lenguaje, S.O.
El utilizar el prototipo en el producto final conduce a que éste contenga numerosos errores latentes, sea ineficiente,
poco fiable, incompleto o difícil de mantener. En definitiva a que tenga poca calidad, y eso es precisamente lo que
queremos evitar aplicando la ingeniería del software.

EL MODELO EN ESPIRAL

El modelo en espiral combina las principales ventajas del modelo de ciclo de vida en cascada y del modelo de
construcción de prototipos. Proporciona un modelo evolutivo para el desarrollo de sistemas de software complejos,
mucho más realista que el ciclo de vida clásico, y permite la utilización de prototipos en cualquier etapa de la
evolución del proyecto.
Otra característica de este modelo es que incorpora en el ciclo de vida el análisis de riesgos.
Los prototipos se utilizan como mecanismo de reducción del riesgo, permitiendo finalizar el proyecto antes de
haberse embarcado en el desarrollo del producto final, si el riesgo es demasiado grande.

14
El modelo en espiral define cuatro tipos de actividades, y representa cada uno de ellos en un cuadrante:
 Planificación.
Consiste en determinar los objetivos del proyecto, las posibles alternativas y las restricciones.
Esta fase equivale a la de recolección de requisitos del ciclo de vida clásico e incluye además la planificación de
las actividades a realizar en cada iteración.
 Análisis de riesgo.
Una de las actividades de la planificación de proyectos (que se verá en IS: Proyectos) es el análisis de riesgos. El
desarrollo de cualquier proyecto complejo lleva implícito una serie de riesgos: unos relativos al propio proyecto
(los riesgos que pueden hacer que el proyecto fracase) y otros relativos a las decisiones que deben tomarse
durante su desarrollo (los riesgos asociados a que una de estas decisiones sea errónea).

El análisis de riesgos consiste en cuatro actividades principales:

1. Identificar los riesgos. Pueden ser:

Riesgos del proyecto (presupuestarios, de organización, del cliente. etc.)
Riesgos técnicos (problemas de diseño, codificación, mantenimiento)
Riesgos del negocio (riesgos de mercado: que se adelante la competencia o que el producto no se
venda bien).
2. Estimación de riesgos. Consiste en evaluar, para cada riesgo identificado, la probabilidad de que ocurra y
las consecuencias, es decir, el coste que tendrá en caso de que ocurra.
3. Evaluación de riesgos. Consiste en establecer unos niveles de referencia para el incremento de coste, de
duración del proyecto y para la degradación de la calidad que si se superan harán que se interrumpa el
proyecto.
Luego hay que relacionar cuantitativamente cada uno de los riesgos con estos niveles de referencia, de
forma que en cualquier momento del proyecto podamos calcular si hemos superado alguno de los
niveles de referencia.
4. Gestión de riesgos. Consiste en supervisar el desarrollo del proyecto, de forma que se detecten los
riesgos tan pronto como aparezcan, se intenten minimizar sus daños y exista un apoyo previsto para las
tareas críticas (aquéllas que más riesgo encierran).

La diferencia principal con el modelo de construcción de prototipos, es que en éste los prototipos se usan
para perfilar y definir los requisitos. Al final, el prototipo se desecha y comienza el desarrollo del software
siguiendo el ciclo clásico.
En el modelo en espiral, en cambio, los prototipos son sucesivas versiones del producto, cada vez más
detalladas (el último es el producto en sí) .

15
 Visible Analyst (VA) es una herramienta CASE
Da al analista de sistemas la posibilidad de realizar planeación, análisis y diseño por medios gráficos, con el
propósito de construir aplicaciones cliente-servidor y bases de datos complejas.
Esta herramienta permite modelar los datos, procesos y objetos en diferentes formatos.
Permite que sus usuarios dibujen y modifiquen diagramas con facilidad.
De esta manera, el analista es más productivo tan sólo con la reducción del tiempo considerable que se
invierte en dibujar y corregir manualmente diagramas de flujo de datos hasta que tengan una apariencia
aceptable.
Un paquete de herramientas como Visible Analyst también mejora la productividad de grupos al dar a los
analistas la posibilidad de compartir fácilmente el trabajo con otros miembros del equipo, quienes sólo
tienen que abrir el archivo en sus PCs y revisar o modificar lo que se haya hecho.
Las herramientas CASE también facilitan la interacción entre miembros de un equipo al hacer que la
diagramación sea un proceso iterativo y dinámico más que uno en el cual los cambios causen molestia y se
conviertan en un freno para la productividad.
En este caso la herramienta CASE para dibujar y grabar diagramas de flujo de datos ofrece un registro de la
evolución de las ideas del equipo en lo concerniente a los flujos de datos.

Hasta el momento, de las experiencias de analistas que utilizan herramientas

CASE se desprende que su uso fomenta una mayor y más eficiente comunicación entre usuarios y analistas.
La tercera razón para el uso de las herramientas CASE es integrar las actividades y proporcionar continuidad
de una fase a la siguiente durante todo el ciclo de vida del desarrollo de sistemas.
Las herramientas CASE son especialmente útiles cuando una fase en particular del ciclo de vida requiere
varias iteraciones de retroalimentación y modificaciones.

7. HERRAMIENTAS PARA ANÁLISIS DISEÑO Y DESARROLLO DE SISTEMAS

Herramientas para análisis:

Estas herramientas ayudan a los especialistas en sistemas a documentar un sistema existente, ya sea éste
manual o automatizado, y a determinar los requerimientos de una nueva aplicación. Estas herramientas
incluyen:
 Herramientas para recolección de datos: capturan detalles que describen sistemas y procedimientos en uso,
documentan procesos y actividades de decisión
 Herramientas para diagramación: crean representaciones gráficas o modelos de sistemas, apoyan el dibujo
y la revisión de diagramas e íconos
 Herramientas para el diccionario: registran y mantienen descripciones de los elementos del sistema. Con
frecuencia proporcionan la capacidad de examinar las descripciones del sistema para deducir si son
incompletas o inconsistentes, muchas incluyen la facilidad de reportar donde se utilizar los elementos del
sistema.

Herramientas para diseño:

Las herramientas para diseño apoyan el proceso de formular las características que el sistema debe tener
para satisfacer los requerimientos detectados durante las actividades de análisis:
 Herramientas de especificación: apoyan el proceso de formular las características que deben tener una
aplicación, tales como entradas, salidas, procesamiento y especificaciones.
 Herramientas para presentación: se utilizan para describir la posición de datos, mensajes y encabezados
sobre pantallas de terminales, reportes y otros medios de entrada y salida.

Herramientas para el desarrollo

Estas herramientas ayudan al análisis a trasladar los diseños en aplicaciones funcionales:
· Herramientas para ingeniería de software: apoyan el proceso de formular diseños de software, incluyendo
procedimientos y controles, así como la documentación correspondiente.

16
 · Generadores de código: producen el código fuente y las aplicaciones a partir de especificaciones
funcionales bien articuladas.
· Herramientas para pruebas: apoyan la fase de evaluación de un sistema o de partes del mismo contra las
especificaciones. Incluyen facilidades para examinar la correcta operación del sistema así como el grado de
perfección alcanzado en comparación con las expectativas.

Participantes en el desarrollo
La función en el proceso El papel en la organización
• Analista • Consultor
• Diseñador • Especialista de Apoyo
• Programador • Agente de Cambio

El análisis y diseño de sistema da forma al análisis y diseños de sistema de información, un esfuerzo muy
valioso que de otra manera podría haberse realizado fortuita. Se le puede considerar como una serie de
proceso sistemáticamente emprendido con el propósito de mejorar un negocio con ayuda de sistema de
información computarizado. Gran parte del análisis y diseño de sistema implica trabajar con usuarios
actuales y ocasionales de lo sistema de información.
Es impórtate que los usuarios intervengan de alguna manera durante el proyecto para completar con éxito
los sistemas de información computarizados.
Los analistas de sistemas, cuyo roles en la organización se describen a continuación, constituyen el otro
componente esencial en el desarrollo de sistemas de información útiles.

8. PARTICIPANTES EN EL DESARROLLO DE SISTEMAS SEGÚN EL ROL EN LA ORGANIZACIÓN Y SEGÚN LA

FUNCIÓN EN EL PROCESO. LOS USUARIOS: FUNCIONES Y CATEGORÍAS.

(Yourdon)
USUARIOS: son aquellos que formalmente solicitan un sistema. También pueden presentarse situaciones en las que
no se conoce al usuario puesto que el sistema puede estar enfocado por ejemplo para una empresa de consultoría.
Incluso puede suceder que una organización nombre un representante para tratar el proyecto porque no disponen
de tiempo.
Hay que tener en mente que los usuarios son personas diferentes, con diferentes capacidades y preparación. Por ello
podemos clasificar a los usuarios de dos maneras:

Por categoría de trabajo o nivel de supervisión: Mirando a los grupos de usuarios de los cuales vamos a trabajar en
el relevamiento los podemos agrupar en:

 Usuarios operacionales: son oficinistas, administradores, y operadores que son los que tendrán más
contacto con el nuevo sistema. (a menos que sea un sistema DSS)
Hay que tener en cuenta que estos usuarios se preocupan mucho por las funciones del sistema pero
es más probable que se preocupen por la interfaz humana, puesto que tienen mucho contacto con la
misma. Esto es clave para el éxito del sistema

 Usuarios supervisores: Usualmente administran a un grupo de usuarios operacionales y son

responsables de sus logros. Pueden tener título de supervisor pero pueden ser también jefes de
turno, gerentes ejecutivos, jefes de ingeniería por ej.
Hay que tener en cuenta que el usuario supervisor ve el sistema como una herramienta para reducir
el número de tareas y de igual forma los costos.
El usuario supervisor es con quien tendremos más contacto, es el que definirá los requerimientos y
políticas de la empresa que su sistema debe realizar.

17
  Usuarios ejecutivos: Un usuario ejecutivo suele estar dos o tres niveles más arriba de la acción
asociada con el proyecto.
Estos pueden proporcionar la iniciativa para el proyecto pero es más probable que solo sirvan como
autoridad para financiar los proyectos.
Estos usuarios no tienen afinidad con el funcionamiento cotidiano del sistema así que no nos
servirán para determinar requisitos del mismo. Solamente en casos en que el sistema a construir sea
un DSS enfocado a ese grupo de trabajo.
Los usuarios ejecutivos se preocupan por los detalles estratégicos, las ganancias a corto y largo plazo,
por ello pueden no estar interesados en asuntos operacionales tales como ahorro en costos de
transacción o ahorro de personal. Este grupo de usuarios no está interesado en modelos físicos por
ello de vemos hacer hincapié en los modelos conceptuales o abstractos a los cuales ya están
habituados como modelos financieros, modelos de mercado, modelos de ingeniería, etc.

Por categoría en nivel de experiencia: Podemos clasificarlos de acuerdo a su experiencia en:

 Amateur: Es aquel que jamás ha visto una computadora y que reconoce su ignorancia en ese campo.
Son difíciles de entrenar en el nuevo sistema y requieren de un tratamiento especial en el lenguaje
con el que nos expresaremos.
 Novato presuntuoso: Es una persona que ha tenido uno o dos proyectos de desarrollo de sistemas y
suele tener una muy muy vaga experiencia en programación. Esto genera que dicho usuario sea muy
específico a la hora de pedir un cambio, generando problemas con las soluciones más efectivas que
propondremos como analistas y generando también contratiempos al surgir debates.
 Expertos:

ADMINISTRACIÓN: Como analistas entraremos en contacto con diferentes administradores.

 Administradores usuarios: (ya los hemos definido)

 Administradores de informática: Personas encargadas del proyecto de sistemas y los administradores de

nivel superior encargados de la administración global y la distribución de recursos de todo el personal
técnico de la organización.

 Administración general: Son los administradores de nivel superior que no están directamente involucrados
en la organización de informática ni son de la organización usuaria.
 Pudiera ser el presidente de la organización o el jefe de administración financiera. Generalmente se
interesan más por los sistemas de planeación estratégica y de DSS.
 Si bien la administración superior requiere informes, no requieren la cantidad de detalles que los
supervisores. Este grupo suele enfocarse más en la información externa: reglas gubernamentales, informes
de competencia de mercado.

AUDITORES, PERSONAL DE CONTROL: El auditor no se suele involucrar en el sistema hasta que este no está
terminado, lo que complica los cambios y correcciones. Suelen preocuparse más por la forma que por el contenido,
si los documentos que se exige no tienen la presentación correcta corremos el riesgo de que rechacen el sistema.

ANALISTA DE SISTEMAS: ROLES DEL ANALISTA DE SISTEMAS

Nuestra definición de analista de sistema es amplia. El analista debe tener la capacidad de trabajar con todo tipo de
gente y contar con suficiente experiencia en computadora. Desempeña diversos roles, en ocasiones varios de ellos al
mismo tiempo. Los tres roles principales del analista de sistemas son el de consultor, experto en soporte técnico y
agente de cambio.

EL ROL DE CONSULTOR DEL ANALISTA DE SISTEMAS

18
Con frecuencia, el analista de sistemas desempeña el rol de consultor para un negocio y, por tanto, podría ser
contratado de manera específica para enfrentar los problemas de sistemas de información de una empresa.
Esta contratación se puede traducir en una ventaja porque los consultores externos tienen una perspectiva fresca de
la cual carecen los demás miembros de una organización. También se puede traducir en una desventaja porque
alguien externo nunca conocerá la verdadera cultura organizacional.
En su función de consultor externo, usted dependerá en gran medida de los métodos sistemáticos que se explican en
este libro para analizar y diseñar sistemas de información apropiados para una empresa en particular. Además,
tendrá que apoyarse en los usuarios de los sistemas de información para entender la cultura organizacional desde la
perspectiva que tienen ellos.

EL ROL DE EXPERTO EN SOPORTE TECNICO DEL ANALISTA DE

SISTEMAS
Otro rol que tendrá que desempeñar es el de experto en soporte técnico dentro de la empresa en la cual labora de
manera regular. En este rol el analista recurre a su experiencia profesional con el hardware y software de cómputo y
al uso que se le da en el negocio. Con frecuencia, este trabajo no implica un proyecto completo de sistemas, sino
más bien la realización de pequeñas modificaciones o la toma de decisiones que se circunscriben a un solo
departamento.
Como experto de soporte técnico, usted no está a cargo del proyecto; tan solo actúa como recurso para aquellos que
si lo están. Si usted es un analista de sistemas contratado por una empresa de manufactura o servicios, gran parte de
sus actividades podrían ajustarse a este rol.

EL ROL DE AGENTE DE CAMBIO DEL ANALISTA DE SISTEMAS

El rol más completo y de mayor responsabilidad que asume el analista de sistemas es el de agente de cambio, ya sea
interno o externo para la empresa. Como analista, usted es un agente de cambio si desempeña cualquiera de las
actividades relacionadas con el ciclo de vida del desarrollo de sistemas (que se explicara en la siguiente sección) y
está presente en la empresa durante un largo periodo (semanas a más de un año).
Su presencia en el negocio inicia el cambio de ahí que tenga que interactuar con los usuarios y la administración
(sino son uno solo y el mismo) desde el principio de su proyecto. Sin su colaboración usted no podría entenderlo que
ocurre en una organización y el cambio real nunca se daría.
Si el cambio (es decir, la mejora al negocio que se pueden concretar mediante los sistemas de información) parece
factible después de efectuar el análisis, el siguiente paso es desarrollar un plan para el cambio de manera conjunta
con quienes tienen la facultad de autorizarlo. Una vez que se haya alcanzado el consejo acerca de los cambios por
realizar, usted tendrá que interactuar constantemente con quienes hayan a cambiar.

DISEÑADORES DE SISTEMAS: El diseñador de sistemas es quien recibe los resultados del análisis, la labor de él es
transformar la petición que se desprende del análisis en un diseño de alto nivel que servirá como base para los
programadores. El diseñador puede ser una persona o un grupo de personas.

PROGRAMADORES: El programador se encarga de la construcción de las especificaciones dadas por el diseñador, a

veces no se produce contacto o interacción entre el programador y el diseñador. Si el diseñador ha realizado
correctamente su trabajo el programador comienza su tarea una vez a finalizado el diseño( como es el caso en la
mayoría de los ciclos de vida)

PERSONAL DE OPERACIONES: Es el responsable del centro de cómputo, la red de telecomunicaciones, la seguridad

del hardware y del soft, además de la ejecución de los programas, el montaje de los discos y el manejo de las salidas
de impresoras. El personal de operaciones es quien más nos ayudara a determinar las características físicas que
deberá cumplimentar el nuevo sistema.
9. ETAPAS EN EL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS.

El ciclo de vida del desarrollo de sistemas

Parte de este enfoque se incluye en el ciclo de vida del desarrollo de sistemas (SDLC, Systems Development Life
Cycle). El SDLC es un enfoque por fases para el análisis y el diseño cuya premisa principal consiste en que los
sistemas se desarrollan mejor utilizando un ciclo específico de actividades del analista y el usuario.

19
Los analistas no se ponen de acuerdo en la cantidad de fases que incluye el ciclo de vida del desarrollo de sistemas,
pero en general alaban su enfoque organizado.

 IDENTIFICACIÓN DE PROBLEMAS, OPORTUNIDADES Y OBJETIVOS

En esta primera fase del ciclo de vida del desarrollo de sistemas, el analista se ocupa de identificar problemas,
oportunidades y objetivos. Esta etapa es crítica para el éxito del resto del proyecto, pues a nadie le agrada
desperdiciar tiempo trabajando en un problema que no era el que se debía resolver.
La primera fase requiere que el analista observe objetivamente lo que sucede en un negocio.
A continuación, en conjunto con otros miembros de la organización, el analista determina con precisión cuáles son
los problemas.
Con frecuencia los problemas son detectados por alguien más, y ésta es la razón de la llamada inicial al analista. Las
oportunidades son situaciones que el analista considera susceptibles de mejorar utilizando sistemas de información
computarizados. El aprovechamiento de las oportunidades podría permitir a la empresa obtener una ventaja
competitiva o establecer un estándar para la industria.
La identificación de objetivos también es una parte importante de la primera fase. En primer lugar, el analista debe
averiguar lo que la empresa trata de conseguir. A continuación, podrá determinar si algunas funciones de las
aplicaciones de los sistemas de información pueden contribuir a que el negocio alcance sus objetivos aplicándolas a
problemas u oportunidades específicos.
Los usuarios, los analistas y los administradores de sistemas que coordinan el proyecto son los involucrados en la
primera fase. Las actividades de esta fase consisten en entrevistar a los encargados de coordinar a los usuarios,
sintetizar el conocimiento obtenido, estimar el alcance del proyecto y documentar los resultados. El resultado de
esta fase es un informe de viabilidad que incluye una definición del problema y un resumen de los objetivos. A
continuación, la administración debe decidir si se sigue adelante con el proyecto propuesto. Si el grupo de usuarios
no cuenta con fondos suficientes, si desea atacar problemas distintos, o si la solución a estos problemas no amerita
un sistema de cómputo, se podría sugerir una solución diferente y el proyecto de sistemas se cancelaría.

 DETERMINACIÓN DE LOS REQUERIMIENTOS DE INFORMACIÓN

La siguiente fase que enfrenta el analista es la determinación de los requerimientos de información de los usuarios.
Entre las herramientas que se utilizan para determinar los requerimientos de información de un negocio se
encuentran métodos interactivos como las entrevistas, los muestreos, la investigación de datos impresos y la
aplicación de cuestionarios; métodos que no interfieren con el usuario como la observación del comportamiento de
los encargados de tomar las decisiones y sus entornos de oficina.
En la fase de determinación de los requerimientos de información del SDLC, el analista se esfuerza por comprender
la información que necesitan los usuarios para llevar a cabo sus actividades. Como puede ver, varios de los métodos
para determinar los requerimientos de información implican interactuar directamente con los usuarios.
Los implicados en esta fase son el analista y los usuarios, por lo general trabajadores y gerentes del área de
operaciones. El analista de sistemas necesita conocer los detalles de las funciones del sistema actual: el quién (la
gente involucrada), el qué (la actividad del negocio), el dónde (el entorno donde se desarrollan las actividades), el
cuándo (el momento oportuno) y el cómo (la manera en que se realizan los procedimientos actuales) del negocio
que se estudia.

 ANÁLISIS DE LAS NECESIDADES DEL SISTEMA

La siguiente fase que debe enfrentar el analista tiene que ver con el análisis de las necesidades del sistema. De nueva
cuenta, herramientas y técnicas especiales auxilian al analista en la determinación de los requerimientos. Una de
estas herramientas es el uso de diagramas de flujo de datos para graficar las entradas, los procesos y las salidas de
las funciones del negocio en una forma gráfica estructurada. A partir de los diagramas de flujo de datos se desarrolla
un diccionario de datos que enlista todos los datos utilizados en el sistema, así como sus respectivas
especificaciones.
En este punto del ciclo de vida del desarrollo de sistemas, el analista prepara una propuesta de sistemas que
sintetiza sus hallazgos, proporciona un análisis de costo/beneficio de las alternativas y ofrece, en su caso,
recomendaciones sobre lo que se debe hacer.
Si la administración de la empresa considera factible alguna de las recomendaciones, el analista sigue adelante.
 DISEÑO DEL SISTEMA RECOMENDADO

20
En la fase de diseño del ciclo de vida del desarrollo de sistemas, el analista utiliza la información recopilada en las
primeras fases para realizar el diseño lógico del sistema de información.
El analista diseña procedimientos precisos para la captura de datos que aseguran que los datos que ingresen al
sistema de información sean correctos. Además, el analista facilita la entrada eficiente de datos al sistema de
información mediante técnicas adecuadas de diseño de formularios y pantallas.

La fase de diseño también incluye el diseño de archivos o bases de datos que almacenarán gran parte de los datos
indispensables para los encargados de tomar las decisiones en la organización.
Una base de datos bien organizada es el cimiento de cualquier sistema de información.
En esta fase el analista también interactúa con los usuarios para diseñar la salida
(En pantalla o impresa) que satisfaga las necesidades de información de estos últimos.

 DESARROLLO Y DOCUMENTACIÓN DEL SOFTWARE

En la quinta fase del ciclo de vida del desarrollo de sistemas, el analista trabaja de manera conjunta con los
programadores para desarrollar cualquier software original necesario.
Entre las técnicas estructuradas para diseñar y documentar software se encuentran los diagramas de estructura, los
diagramas de Nassi-Shneiderman y el pseudocódigo.
El analista se vale de una o más de estas herramientas para comunicar al programador lo que se requiere programar.
Durante esta fase el analista también trabaja con los usuarios para desarrollar documentación efectiva para el
software, como manuales de procedimientos, ayuda en línea y sitios Web que incluyan respuestas a preguntas
frecuentes (FAQ, Frequently Asked Questions)
Los programadores desempeñan un rol clave en esta fase porque diseñan, codifican y eliminan errores sintácticos de
los programas de cómputo.

 PRUEBA Y MANTENIMIENTO DEL SISTEMA

Antes de poner el sistema en funcionamiento es necesario probarlo. Es mucho menos costoso encontrar los
problemas antes que el sistema se entregue a los usuarios.
Primero se realiza una serie de pruebas con datos de muestra para determinar con precisión cuáles son los
problemas y posteriormente se realiza otra con datos reales del sistema actual.
El mantenimiento del sistema de información y su documentación empiezan en esta fase y se llevan a cabo de
manera rutinaria durante toda su vida útil.
Parte del trabajo habitual del programador consiste en el mantenimiento, y las empresas invierten enormes sumas
de dinero en esta actividad. Parte del mantenimiento, como las actualizaciones de programas, se pueden realizar de
manera automática a través de un sitio Web.

 IMPLEMENTACIÓN Y EVALUACIÓN DEL SISTEMA

Ésta es la última fase del desarrollo de sistemas, y aquí el analista participa en la implementación del sistema de
información. En esta fase se capacita a los usuarios en el manejo del sistema. Parte de la capacitación la imparten los
fabricantes, pero la supervisión de ésta es responsabilidad del analista de sistemas.
Además, el analista tiene que planear una conversión gradual del sistema anterior al actual. Este proceso incluye la
conversión de archivos de formatos anteriores a los nuevos, o la construcción de una base de datos, la instalación de
equipo y la puesta en producción del nuevo sistema.

El trabajo de sistemas es cíclico. Cuando un analista termina una fase del desarrollo de sistemas y pasa a la siguiente,
el surgimiento de un problema podría obligar al analista a regresar a la fase previa y modificar el trabajo realizado.
10. EL PROYECTO DE SISTEMAS: TAREAS DE PLANEACIÓN Y DE CONTROL.

21
1. Seleccionar los participantes:
 Se las conoce como Equipo de Planificación del Proyecto

2. Definir objetivos y Objetivo:

 Qué se quiere resolver con el sistema, por qué es importante resolver el problema y qué es lo que se
requiere para resolver el problema
 Alcance: delimitar el tamaño del proyecto
 Sirve para estudiar y evaluar limitaciones y restricciones respecto a la inversión, y los recursos económicos y
temporales el alcance del proyecto

3. Definir las actividades del proyecto

 Construir un diagrama o un esquema en donde aparezcan tosas las actividades o tareas a desarrollar el
sistema de información
 Existen varias formas, manuales: identadas y arborescentes
 Existen varias formas automatizadas.

4. Existen cinco tipos de recursos:

 Personas
 Servicios
 Equipamiento
 Suministros y Materiales
 Dinero

22
Los recursos más críticos en el desarrollo del calendario del proyecto con las personas y la disponibilidad de las
infraestructuras de la empresa.
Los gráficos de GANTT incluyen la posibilidad de representar las personas involucradas en el desarrollo del proyecto
y el número de días u horas que cada personas debe trabajar en el proyecto

5. Planificar el Calendario
Estimar el tiempo necesario para cada tarea y las dependencias entre tareas
Varios métodos para la estimación de tareas:

1er Técnica: Equiparar el tiempo de una tarea al tiempo más probable que será necesario para finalizar la tarea
(teniendo en cuenta los problemas habituales que puedan surgir durante el tiempo de realización)
2da. Técnica: Calcular la media entre el tiempo óptimo y el tiempo pésimo de una tarea
3er Técnica: Se basa en la experiencia y consiste en calcular la duración esperada a través de la siguiente fórmula:
DE = TO + (4.TMP) + TP
6

Respecto a las dependencias entre tareas:

Existen cuatro tipos de dependencias:
Acabar para Empezar: Una tarea tiene que finalizar para que otra pueda comenzar
Empezar para Empezar: El inicio de una tarea se produce cuando otra tarea es iniciada
Acabar para Acabar: Dos tareas pueden acabar al mismo tiempo
Empezar para Acabar: El inicio de una tarea provoca la finalización de otra tarea

6. Seleccionar criterios de evaluación

 Pensar en cómo se evaluará el proyecto
 Se pueden clasificar en cuatro grupos: calendario, calidad, costos y operatividad.

7. Estudio de viabilidad del proyecto

Un proyecto de desarrollo de un sistema de información es una inversión de tiempo, dinero y personas, por
lo que es necesario estudiar su viabilidad a lo largo del todo el proyecto.
La viabilidad de un proyecto de SI es la medida del beneficio obtenido en una organización a través del
desarrollo de un SI.
No existe una única forma de realizar un análisis de viabilidad, cada autor y organización tiene sus propios
métodos.
Aunque en las primeras etapas pueda no ser exacto, proporciona información para poder justificar el
desarrollo o la continuidad del proyecto.

Estudio de Factibilidad

 Objetivo. Identificar beneficios y costos asociados al desarrollo del proyecto

 Estimar: el costo de la investigación, costo del hardware y software, beneficios en reducción
Económica de costos o errores y el costo si nada sucede, si el proyecto no se lleva a cabo
 Beneficios: tangibles e intangibles
 Costos: fijos y variables.

 Es la posibilidad de éxito que tendría el sistema al momento de ser implantado y operado por
el personal de la empresa
Operativa
 Aspectos a investigar: si los usuarios están de acuerdo, trabajarán en el sistema, participan en
la planeación y desarrollo, se incrementará la productividad de los empleados, mejorará la
integración con otras áreas

23
  Se utiliza la estructura PIECES como items a estudiar.

 Objetivo: estudiar si la organización es capaz de construir el sistema de información

propuesto
 Tecnología adecuada para la demanda
 Facilidad de uso
Técnica  Garantías de exactitud, confiabilidad, acceso y seguridad de datos
 Soporte técnico y de capacitación
 Aspectos que puedan ocasionar pérdidas en la empresa
 Riesgos Técnicos: tamaño del proyecto, grupo de desarrollo, grupo de usuarios y estructura
del proyecto.

 Objetivo: estudiar si las previsiones iniciales en relación al calendario de las tareas a realizar
se mantienen o han sufrido retraso o avance.
De fechas
 Es preferible entregar un sistema de información tarde pero que funcione y que cumpla con
todos los objetivos planteados al inicio del proyecto

Legal y  Objetivo: regulaciones de países, reportes financieros, las obligaciones contractuales y el

contractual capital intelectual.

Política  Objetivo: evaluar cómo afecta el SI a la organización, desde el punto de vista social y político

11. Herramientas para la Planeación y el Control.

Diagrama de Gantt
El diagrama de Gantt fue concebido por el ingeniero norteamericano Henry L. Gantt, quien procuró resolver el problema de la
programación de actividades. Es decir, su distribución conforme a un calendario, de manera tal que se pudiese visualizar el
periodo de duración de cada actividad, sus fechas de iniciación y terminación y el tiempo total requerido finalmente para la
ejecución de un trabajo. El instrumento que desarrolló permite también que se siga el curso de cada actividad, al proporcionar
información del porcentaje ejecutado de cada una de ellas y de esta manera, se podrá conocer cuánto tiempo está adelantado
o atraso con respecto al plazo previsto. El gráfico que se utiliza en este diagrama consta de un sistema de coordenadas, en el
cual se deberá indicar lo siguiente:
 En el eje Horizontal: se ubicará la escala de tiempo definido en términos de la unidad más adecuada al trabajo que se
va a ejecutar. Por ejemplo: hora, día, semana, mes, etc.
 En el eje Vertical: se colocarán las actividades que constituyen el trabajo a ejecutar. A cada actividad se le hace
corresponder una línea horizontal cuya longitud es proporcional a su duración (teniendo en cuenta la escala definida
en el eje horizontal).
Para ilustrar el diagrama de Gantt, es muy importante identificar primero las distintas actividades del proceso, con las
respectivas secuencias y tiempos de cada actividad. La información se puede reunir por ejemplo, en una tabla del siguiente tipo:
Actividad Después de Duración de la Actividad
A - 4 semanas
B A 6 semanas
C A 2 semanas
D B 2 semanas
Ahora si, se puede ilustrar el diagrama de Gantt, como se muestra a continuación:

24
B
C
D
2 4 6 8 10 12 14 16 18 20 Semana

Ventajas y Desventajas de los gráficos de Gantt:

La ventaja principal del gráfico de Gantt radica en que su realización es relativamente sencilla.
Los gráficos de Gantt se revelan muy eficaces en las etapas iniciales de la planificación. Sin embargo, después de iniciada la
ejecución de la actividad y cuando comienzan a efectuarse modificaciones, el gráfico tiende a volverse confuso. Por eso, los
ajustes (replanificación) requieren por lo general de la formulación de un nuevo gráfico. Aún en términos de planificación,
existe todavía una limitación bastante grande en lo que se refiere a la representación de planes de cierta complejidad. El
Gráfico de Gantt no ofrece condiciones para el análisis de opciones, ni toma en cuenta factores como el costo. Se complica,
además, la visualización de la relación entre las actividades cuando el número de éstas es grande.

Diagrama de Pert
Un proyecto es un conjunto de tareas relacionadas entre sí. Cada tarea tiene algún tipo de prioridad respecto de otra, o bien, es
necesario realizar determinada tarea si o si, para poder comenzar con otra. De esta manera, comenzaremos a tratar con dos
conceptos: antecedencia y consecuencia entre las tareas.

Pert, es utilizado como una herramienta cuantitativa de planificación y control, lo que permite a los administradores contar con
un modelo de optimización que entregue la solución óptima de una secuencia de actividades en el tiempo, que deben realizarse
para finalizar el plan de acción. Permite programar un proyecto por adelantado y a la vez calcular el tiempo necesario para
completarlo. Además, el diagrama de Pert, facilita las actividades de control, permitiendo la comparación del tiempo real con el
planificado.

Para ilustrar el diagrama de Pert, tendremos en cuenta las siguientes convenciones:

 Las tareas serán simbolizadas por medio de arcos y los sucesos por medio de nodos. Los sucesos denotan el comienzo y la
finalización de cada tarea.
Cada nodo tendrá un nombre n.

 Fecha temprana: la fecha temprana se refiere al día en que comienza determinada tarea, por ejemplo a los 2 días de
comenzado el proyecto.

 Se nombrará a cada una de las tareas, por ejemplo, la tarea AB.

Se colocará las duraciones de cada tarea sobre los arcos correspondientes. Comenzaremos el proyecto en el día 0, por lo
tanto, la tarea AB comenzará el día 0.

De esta manera, el suceso B indica la finalización de AB, el comienzo de BC y el comienzo de BE.

Nota: la flecha punteada indica que se trata de una tarea ficticia, es decir, es una tarea que se necesita para mostrar la lógica del
proyecto y hay que tener en cuenta que no tiene duración, es decir que su duración es igual a cero.

25
 Fecha tardía: es la última fecha que tenemos para finalizar cada tarea ( y el proyecto ).

En el caso la fecha para finalizar la tarea DF es el día 15. Veamos el siguiente gráfico:

De esta manera, la fecha tardía para comenzar con la tarea DF es el día 11 ( 15 - 4 = 11).

Nota: Supongamos que la comienzo es el día 12. Entonces : 12 (suceso D) más 4 (duración DF) hace que el proyecto termine el
día 16, es decir un día más tarde

De esta misma forma se continua con las demás tareas, hasta llegar a la tarea AB.

Aplique el mismo criterio para comenzar con la tarea ED: entonces, 11 (Suceso D) – 5 (duración de la tarea ED) = 6.

Para determinar la fecha tardía para el suceso C, por un lado deberemos elegir entre ( 11 - 2 = 9) y por el otro ( 6 - 0 = 6). Hay
que tener en cuenta que la duración de una tarea ficticia es 0 (no existe como tarea real). De los dos tiempos, se deberá elegir el
menor.

Si continuamos de esta manera, llegaremos al siguiente gráfico:

26
 A continuación, se deberán determinar cuáles son los sucesos críticos y por consiguiente el camino crítico.
Un suceso crítico es aquel cuyas fechas tempranas (ft) y fechas tardías (Ft) son iguales. Se indican en el gráfico engrosando las
líneas de los sucesos correspondientes.

Las tareas críticas son aquellas cuya duración es igual a la diferencia entre los sucesos críticos que la determinan. Además, son
las tareas que hacen que el proyecto dure 15 días (en nuestro ejemplo). Se indican en el gráfico engrosando la línea.
Poder determinar estas tareas es importante debido a que si se incrementa la duración de alguna de ellas, se incrementará la
duración del proyecto, por lo tanto se dice que estas tareas son críticas para el proyecto.

Consideraciones generales:
Al realizar un diagrama de Pert, hay que tener en cuenta las siguientes consideraciones:

 Antes de comenzar una actividad, todas las actividades precedentes deben haber terminado. Las flechas indican su
procedencia lógica. Su longitud no tiene significado alguno.
 Todas las flechas deben estar dirigidas de izquierda a derecha.
 Se tiene que tomar en cuenta aquellas actividades ficticias, que son actividades que no consumen recursos y tiempo.
 Una vez asignados los tiempos de cada actividad, es importante calcular los tiempos totales de cada una de las
ramas de la red, para así determinar cuál es la que emplea el mayor tiempo, lo que indicaría las actividades que no
se pueden retrasar.

14. PROGRAMACIÓN EXTREMA. TIEMPO, COSTO, CALIDAD Y ALCANCE.

PROGRAMACIÓN EXTREMA Y OTRAS METODOLOGÍAS ALTERNAS

En ocasiones el analista tendrá que reconocer que la organización se podría beneficiar de una metodología alterna.
Quizá un proyecto de sistemas con un enfoque estructurado haya fallado, o quizá las subculturas que existen en la
organización, compuestas por diferentes grupos de usuarios, parezcan más proclives a utilizar un método alterno.
La programación extrema (XP, Extreme Programming) es un enfoque para el desarrollo de software que utiliza
buenas prácticas de desarrollo y las lleva a los extremos. Se basa en valores, principios y prácticas esenciales.
Los cuatros valores son la comunicación, la simplicidad, la retroalimentación y la valentía. Cuando estas cuatro
variables de control se incluyen adecuadamente en la planeación, se propicia un equilibrio entre los recursos y las
actividades requeridas para completar el proyecto.
El llevar las prácticas de desarrollo al extremo es más recomendable cuando se siguen prácticas propias de XP. En el
capítulo 6 describimos cuatro prácticas esenciales de XP: la liberación limitada, la semana de trabajo de 40 horas,
alojar a un cliente en el sitio y el uso de la programación en parejas. A primera vista estas prácticas parecen
extremas, pero como observará, podemos aprender algunas lecciones valiosas al incorporar muchos de estos valores
y prácticas de XP en los proyectos de análisis y diseño de sistemas.
La creación de prototipos (que es diferente a la creación de prototipos que veremos en el capítulo 6) es uno de los
métodos alternos más populares, junto con ETHICS, el enfoque de usar un campeón del proyecto, la Metodología
Soft Systems y Multiview. La creación de prototipos, concebida originalmente en otras disciplinas y aplicada a los

27
sistemas de información, surgió como respuesta a los extensos periodos de desarrollo asociados con el enfoque del
ciclo de vida del desarrollo de sistemas y a la incertidumbre que existe con frecuencia en relación con los
requerimientos de los usuarios. ETHICS, por su parte, se presentó como una metodología socio-técnica que combina
soluciones sociales y técnicas. El enfoque de usar un campeón del proyecto, un concepto tomado de la
mercadotecnia, adopta la estrategia de involucrar a una persona clave de cada área donde tiene influencia el sistema
para garantizar el éxito del mismo. La Metodología Soft Systems fue concebida como una manera de modelar un
mundo muchas veces caótico mediante el uso de "imágenes
ricas", ideogramas que captan los relatos característicos de una organización. Multiview se propuso como una forma
de organizar y utilizar elementos de diversas metodologías en competencia.

28