Implementacion y Direccon de Sistema de Informacion - Modulo2

IMPLEMENTACIÓN Y DIRECCIÓN DE
SISTEMA DE INFORMACIÓN
Desarrollo y Documentación de Sistemas

OBJETIVOS
Al completar este módulo, los participantes podrán estar en la capacidad de :
1. Comprender los tipos de sistemas de información que implementan las organizaciones.

2. Realizar análisis de Sistema como herramienta para una implementación exitosa.
3. Entender los Roles del analista de sistemas.
4. Comprender las metodologías mas utilizadas para el análisis y desarrollo de software.
5. Documentar procesos de desarrollo de Sistema.
TIPOS DE SISTEMAS
Los sistemas de información se desarrollan con diversos propósitos, según las necesidades
de la empresa.
Los sistemas de procesamiento de transacciones (TPS, Transaction Processing Systems)

funcionan al nivel operativo de una organización.
OAS (Office Automotion Systems) y los de trabajo del conocimiento (KWS, KnowledgeWork
Systems) apoyan el trabajo al nivel del conocimiento.
Los MIS (Management Information Systems) y los sistemas de apoyo a la toma de

decisiones (DSS, Decisión Support Systems) son los sistemas de mas alto nivel. Los sistemas
expertos aplican el conocimiento de los encargados de la toma de decisiones para
solucionar problemas estructurados específicos.
Los sistemas de apoyo a ejecutivos (ESS, Executive Support Systems) se encuentran en el

nivel estratégico de la administración.
Los sistemas de apoyo a la toma de decisiones en grupo (GDSS, Group Decision Support
Systems) auxilian la toma de decisiones semiestructuradas o no estructuradas a nivel de
grupo.
SISTEMAS DE PROCESAMIENTO DE
TRANSACCIONES
Los sistemas de procesamiento de transacciones (TPS, Transaction Processing Systems) son
sistemas de información 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 requerido para llevarlas a cabo de manera manual, aún así es necesario el
conocimiento de los usuarios en cuanto a los procesos a realizar ya que tienen que capturar las
informaciones para alimentar el sistema.
Los sistemas de procesamiento de transacciones expanden los límites de la organización dado

que le permiten interactuar con entornos externos. Es importante para las operaciones
cotidianas de un negocio, que estos sistemas funcionen sin ningún tipo de interrupción, puesto
Los datos producidos por los TPS son con el propósito de obtener información actualizada
sobre el funcionamiento de sus empresas.
SISTEMAS DE AUTOMATIZACIÓN DE LA OFICINA
Y DE TRABAJO DEL CONOCIMIENTO
Existen dos clases de sistemas en el nivel del conocimiento de una organización.
Los sistemas de automatización de la oficina [OAS, Office Automation Systems] apoyan a los
trabajadores de datos, quienes por lo general no generan conocimientos nuevos, sino más
bien analizan la información con el propósito de transformar los datos o manipularlos .
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, como los científicos, ingenieros y médicos, en sus es-
fuerzos de creación de nuevo conocimiento y dan a éstos la posibilidad de compartirlo con
sus organizaciones o con la sociedad.
SISTEMAS DE INFORMACIÓN GERENCIAL
Los sistemas de información gerencial (MIS, Management Information Systems] no
reemplazan a los sistemas de procesamiento de transacciones, 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.
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.
SISTEMAS DE INFORMACIÓN GERENCIAL
Cuando un Ingeniero de Sistema multidimensional que realiza transacciones de Nómina y
Contabilidad empresarial pero a la vez las informaciones producidas por estas transacciones se
toman en cuenta para realizar cubos de decisión sobre el personal de la empresa, ya estamos
Hablando de un sistema de toma de decisiones.
Como se puede observar en la imagen, un sistema gerencial,

para su funcionamiento debe estar alimentado o incluir el
Sistema transaccional puesto que ambos interactúan en su
funcionamiento dentro de la organizaciones.
Costo en que incurre la empresa X Empleado

SISTEMAS DE APOYO A LA TOMA DE
DECISIONES
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.
SISTEMAS DE APOYO A LA TOMA DE DECISIONES
INTERACCIÓN CON EL ANALISTA
Como se aprecia en la figura anterior, a medida que se adopten y difundan las nuevas
tecnologías, parte del trabajo de los analistas de sistemas se dedicará a la integración de los
sistemas tradicionales con los nuevos. En esta sección se describen algunas de las nuevas
tecnologías de información que los analistas de sistemas utilizarán para empresas que
buscan integrar sus aplicaciones de comercio electrónico con sus negocios tradicionales, o
bien, iniciar negocios electrónicos completamente nuevos.
ROLES DEL ANALISTA DE SISTEMAS
El analista de sistemas evalúa de manera sistemática el funcionamiento de un negocio me-

diante el examen de la entrada y el procesamiento de datos y su consiguiente producción de
información, con el propósito de mejorar los procesos de una organización.
Muchas mejoras incluyen un mayor apoyo a las funciones de negocios a través del uso de
sistemas de información computarizados. Esta definición pone énfasis en un enfoque
sistemático y metódico para analizar —y en consecuencia mejorar— lo que sucede en el
contexto específico creado por y para un negocio.
El analista debe tener la capacidad de trabajar con todo tipo de gente y contar con suficiente
experiencia en computadoras. Un analista de Sistemas 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
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 miem-
bros de una organización. También se puede traducir en una desventaja porque alguien ex-
terno nunca conocerá la verdadera cultura organizacional.
EL ROL DE EXPERTO EN SOPORTE TÉCNICO DEL ANALISTA DE SISTEMAS
tro 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.
Como experto de soporte técnico, el Analista no está a cargo del proyecto; tan sólo actúa
como recurso para aquellos que sí 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 DEL CAMBIO
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 .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, se es un agente de cambio se desempeñan cualesquiera de las actividades

relacionadas con el ciclo de vida del desarrollo de sistemas.
Su presencia en el negocio inicia el cambio. Como analista de datos, usted debe estar
consciente de este hecho y utilizarlo como punto de partida para su análisis. De ahí que ten-
ga que interactuar con los usuarios y la administración (si no son uno solo y el mismo) des-
de el principio de su proyecto. Sin su colaboración usted no podría entender lo que ocurre
en una organización y el cambio real nunca se daría.
Si el cambio (es decir, las mejoras 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 consenso acerca de los cambios por realizar,
EL ROL DE AGENTE DEL CAMBIO
En su calidad de analista de sistemas desempeñando la función de agente de cambio,

debe promover un cambio que involucre el uso de los sistemas de información. También es
parte de su tarea enseñar a los usuarios el proceso del cambio, ya que las modificaciones a
un sistema de información no sólo afectan a éste sino que provocan cambios en el resto de
la organización.
CUALIDADES DEL ANALISTA DE SISTEMAS
El analista exitoso debe contar con una amplia gama de cualidades, entre ellas, las más
importantes pasamos a mencionarlas:
1. solucionador de problemas: Es una persona que aborda como un reto el análisis de

problemas y que disfruta al diseñar soluciones factibles. Cuando es necesario, el
analista debe contar con la capacidad de afrontar sistemáticamente cualquier situación
mediante la correcta aplicación de herramientas, técnicas y su experiencia.
2. El Analista debe ser un comunicador con capacidad :para relacionarse con los demás
durante extensos períodos. Necesita suficiente experiencia en computación para
programar, entender las capacidades de las computadoras, recabar los requisitos de
información de los usuarios y comunicarlos a los programadores.
3. Debe tener una ética personal y profesional firme que le ayude a moldear las relaciones
con sus clientes.
1. El analista de sistemas debe ser una persona autodisciplinada y automotivada: con

la capacidad de administrar y coordinar los innumerables recursos de un proyecto,
incluyendo a otras personas.
El CICLO DE VIDA DEL DESARROLLO DE
SISTEMAS
ANALISIS
MANTENIMIENTO DISEÑO
IMPLEMENTACION DESARROLLO
PRUEBAS
SISTEMAS
Nos hemos estado refiriendo al enfoque sistemático que el analista toma en relación con el
análisis y diseño de sistemas de información.
Gran 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 vida des del analista y el usuario.
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, tal como se
aprecia en la figura anterior.
SISTEMAS
• IDENTIFICACIÓN DE PROBLEMAS, OPORTUNIDADES Y OBJETIVOS
En esta primera fase 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.
SISTEMAS
• DETERMINACIÓN DE LOS REQUERIMIENTOS DE INFORMACIÓN
La siguiente fase que enfrenta el analista es la determinación de los requerimientos de in-

formación de los usuarios. Entre las herramientas que se utilizan para determinar los re-
querimientos 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 cuestiona-
rios.
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.
En esta fase se puede hacer hincapié en Requerimientos funcionales, aquellos que implican
de manera directa funciones del futuro sistema.
Requerimientos no Funcionales, aquellos que tienen que ver con plataforma de desarrollo,
metodología de desarrollo, modelo, maquetación del software, entre otros.
SISTEMAS
• ANÁLISIS DE LAS NECESIDADES DEL SISTEMA
La siguiente fase que debe enfrentar el analista tiene que ver con el análisis de las necesida-
des del sistema. 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.
Durante esta fase el analista de sistemas analiza también las decisiones estructuradas
que se hayan tomado. 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.
SISTEMAS
• DISEÑO DEL SISTEMA RECOMENDADO
En la fase de diseño del ciclo de vida del desarrollo de sistemas, el analista utiliza la informa-
ció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, facilita la entrada eficiente de
datos al sistema de información mediante técnicas adecuadas de diseño de formularios y
pantallas.
Los GUIs (Graphical User Interfaces] que se manejan a través de un ratón o una pantalla
sensible al tacto(NUI) son parámetros de salida de esta fase.
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 in-
formación.
DISEÑO Y DOCUMENTACIÓN DEL SOFTWARE
• DISEÑO DEL SISTEMA RECOMENDADO
El analista trabaja de manera conjunta con los programadores para desarrollar cualquier
software original necesario, se vale de una o más de estas herramientas para comunicar al
programador lo que se requiere programar.
Durante esta fase también se 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) en
archivos "Léame" que se integrarán en el nuevo software.
• PRUEBA Y MANTENIMIENTO DEL SISTEMA(ANÁLISIS FUNCIONAL, PREMISA DE CALIDAD)
Antes de poner el sistema en funcionamiento es necesario probarlo. Es mucho menos cos-

toso encontrar los problemas antes que el sistema se entregue a los usuarios. Una parte de
las pruebas las realizan los programadores solos, y otra la llevan a cabo de manera conjunta
con los analistas de sistemas. 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.
Las pruebas más comunes son las:

Caja Blanca,Caja Negra
• PRUEBA Y MANTENIMIENTO DEL SISTEMA (ANALISIS FUNCIONAL, PREMISA DE CALIDAD)
De Caja Blanca: se centran en los detalles procedimentales del software, por lo que su
diseño está fuertemente ligado al código fuente. El testeador escoge distintos valores de
entrada para examinar cada uno de los posibles flujos de ejecución del programa y
cerciorarse de que se devuelven los valores de salida adecuados.
Caja Negra: se denomina Caja Negra a aquel elemento que es estudiado desde el punto de
vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su
funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de
interactuar con el medio que le rodea.
En pruebas de software, conociendo una función específica para la que fue diseñado el
producto, se pueden diseñar pruebas que demuestren que dicha función está bien realizada.
Dichas pruebas son llevadas a cabo sobre la interfaz del software, es decir, de la función,
actuando sobre ella como una caja negra, proporcionando unas entradas y estudiando las
salidas para ver si concuerdan con las esperadas.
• 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(Programadores), 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.
Se menciona la evaluación como la fase final del ciclo de vida del desarrollo de sistemas
principalmente en aras del debate. En realidad, la evaluación se lleva a cabo durante cada
una de las fases. Un criterio clave que se debe cumplir es si los usuarios a quienes va dirigi-
do el sistema lo están utilizando realmente.
DESARROLLO DE SISTEMAS WEB
El ciclo de vida del desarrollo de software no debe verse como algo estático, sino como
procesos dinámicos.
Por ejemplo hablamos de proyectos Web, aunque para muchos el desarrollo web es algo
simple, no es menos cierto que también debe cumplir ciertos estándares como: Web 2.0,
W3C, entre otros.
Cuando se habla de proyecto Web, nacen preguntas como:

1. Que se desarrolla y para qué?.
2. Es una simple tarea de ingeniería, o puede mezclarse con más ramos que permitan cubrir
un ciclo de desarrollo fuerte?
3. Existen bases de mejores prácticas?
Conforme la definición de Sistemas de información.
“Aquellos que se encargan de procesar y transformar la información para poder
obtener un resultado de ellos”
"Conjunto de elementos relacionados y ordenados, según ciertas reglas que aporta al sistema
objeto-, es decir, a la organización a la que sirve y que marca sus directrices de
funcionamiento- la información necesaria para el cumplimiento de sus fines; para ello, debe
recoger, procesar y almacenar datos, procedentes tanto de la organización como de
fuentes externas, con el propósito de facilitar su recuperación, elaboración y presentación."
En el caso de los sistemas de información que se han creado en torno a la web y el

Internet, las fuentes de datos y los receptores de la información no se encuentran en un
lugar específico.
TIPO DE SITIO USOS Y FUNCIONES
Informativos : Periódicos en línea, catálogos de productos, manuales, reportes,

clasificados en línea, libros en línea.
Interactivos : Formularios de Registro, información personalizada, presentaciones, juegos en

línea.
Transaccional: Compras en línea (bienes y servicios), banca en línea, compra de tickets, pago
de servicios.
Orientados al flujo de trabajo: Planificación en línea, manejo de inventario, monitoreo de
estatus, gestión de cadena de aprovisionamiento.
Trabajo colaborativo : Sistemas de publicación distribuida, ambientes de diseño
colaborativo.
Comunidades en línea :Grupos de discusión, sistemas de recomendación.
Mercados en línea :E-malls ( Comercio electrónicos), subastas en línea, intermediarios.
. Características de uso
El crecimiento que ha tenido Internet, el uso de Intranets, Extranets y la Web como tal
dentro de las compañías, han logrado que cambie la perspectiva en los sectores de negocios,
comercio, industria, educación, gobierno, banca y finanzas así como en nuestra vida personal
y la forma en la que trabajamos.
En resumen, para un buen desarrollo web es necesario plantearse una característica que no
se ve normalmente en el desarrollo de aplicaciones tradicionales, ya que se debe tomar en
cuenta además de las funcionalidades y requerimientos técnicos, el número de usuarios, el
fondo cultural de quienes utilizarán la aplicación, el uso de dispositivos heterogéneos y la
selección de la hora y el momento en el que accede a la aplicación.
La compatibilidad entre diferentes navegadores, es interesante cuando desarrollamos

sistemas Web ya que para los sistemas tradicionales solíamos pensar en Win32(Desktop App).
Para los sistemas web pensamos en (Explorer, Chrome, Opera, Mozilla, Entre otros), los
cuales corren en cualquier sistema operativo.
. Características de uso
• Características de producto
Cuando pensamos en un producto de software, viene a nuestras mentes el grupo objetivo

específico, las funcionalidades que tendrá y la forma en la que será utilizado junto con los
manuales de usuario y quizá el proceso de capacitación que se le tendrá que dar a los
usuarios que adquieran este producto.
¿Pero qué sucede en el caso de los sistemas de información web? ¿Necesitamos juntar a
todas las personas que vayan a utilizar la aplicación para capacitarlos? ¿Cómo se va a
entregar el producto final?
Un producto de software para web tiene consideraciones adicionales a las de un producto

tradicional, pues se debe enfocar en tres puntos base: contenido, apariencia y arquitectura
de la información, feedback.
• Características de producto
- Contenido: La web nació de la necesidad de compartir información, y aunque ha variado con

el tiempo, sigue siendo su eje central, sus usuarios están habituados a encontrar información
y por ello las aplicaciones web deben no sólo entregar funcionalidad, sino también
contenidos de calidad en términos de consistencia, fiabilidad y exactitud.
- Apariencia: En el software tradicional la apariencia va determinada normalmente por el

estándar de interfaces de usuario y guías de estilo pre-establecidas. Sin embargo, en la
web la presentación está sujeta a la moda, tendencias y características técnicas. Además,
en contraste con las aplicaciones tradicionales, no podemos esperar que un usuario web
consulte un manual de usuario para saber cómo utilizar la aplicación, la interacción debe
resultar lo más natural para quienes interactúen con la aplicación.
- Arquitectura de la información: Las aplicaciones web se basan en la interrelación

entre contenidos para estructurar la información, convirtiendo a cada fragmento de
información en un nodo que estará conectado o relacionado con otro; es por esta razón
que se vuelve sumamente importante saber cómo se distribuirá la información para que
pueda ser encontrada.
. Características de producto
De esta forma nos queda claro que un proyecto web no es sólo desarrollo de software, ni
tampoco es únicamente diseño gráfico, ni exclusivamente montaje del negocio, es una
mezcla de diferentes elementos para que pueda cumplir con los requerimientos.
. Características de desarrollo
La percepción general del desarrollo web es que se trata de un evento que se realizará
una sola vez, que se basará en la experiencia y prácticas de desarrollo de un solo
desarrollador, con poca documentación, que trata más de diseño gráfico que de software
y que debe ser realizado en un período de tiempo muy corto.
Nada más alejado de la realidad, si bien es cierto que tiene un componente fuerte de diseño
y que debe manejar ciclos de desarrollo muy cortos, sigue siendo un proyecto de software y
debe ser tratado como tal.
La limitante más fuerte en cuanto al desarrollo de un sistema de información web, es que

se lo sigue manejando como un proyecto de software tradicional, aun cuando a diferencia
de dichos proyectos, se trabaja con equipos multidisciplinarios conformados regularmente
por desarrolladores de software, expertos en marketing, diseñadores gráficos, técnicos en
multimedia y redactores.
Si el proyecto en el que se va a trabajar necesita será de mayor envergadura y el equipo

de desarrollo es más grande, lo más lógico será aprovechar la ventaja de trabajar con
más capas(N Capas).
Una arquitectura multi-capas estándar está compuesta de los siguientes elementos:

• Capa de presentación (Interfaz de usuario).
• Capa de validación de datos.
• Capa de lógica de negocios (Reglas del negocio).
• Capa de acceso a datos.
Para pensar en N Capas, pensemos en un sistema de Comunicación Cliente Servidor.

En el modelo cliente-servidor, el sistema sobre el cual trabajamos se organiza como un
conjunto de servicios al cual los usuarios pueden tener acceso. Regularmente este
esquema trabaja en base a tres estratos:
1. Uno o más servidores que contienen los servicios que están publicados para ser accedidos
por los clientes.
2. Un número definido de clientes que tendrán la posibilidad de 'consumir' los servicios que
entregan estos servidores.
3. El medio a través del cual se tendrá acceso desde los clientes a los servidores.
Esquema básico de
Comunicación con un
Servidor Web.
. Protocolos comunes en una comunicación WEB.
SSH : Puerto 22 Secure shell

HTTP :Puerto 80 Protocolo de transferencia de hipertexto.
HTTPS :Puerto 443 HTTP seguro (SSL) LDAP 389 Protocolo ligero de acceso a directorio.
RTSP :Puerto 554 Protocolo de transmisión de flujos en tiempo real.
IRC :Puerto 6665-6669 Internet Relay Chat
SMTP :Puerto 25 Protocolo simple de transferencia de correo
SMTPs :Puerto 465 SMTP con capa SSL
POP3 :Puerto 110 Protocolo de descarga de correo
IMAP4 :Puerto 143 Protocolo de acceso a mensajes de internet.
GESTIÓN DE PROYECTOS WEB
Para el desarrollo de todo proyecto, es necesario la subdivisión de responsabilidades bien definidas que
ayudaran a completar un producto de alta calidad:
Por ahora no basaremos en las mejores prácticas definidas por los procesos de desarrollo de software
que han sido ajustados para el desarrollo de aplicaciones web.
1. El equipo de desarrollo web :El equipo de desarrollo web es heterogéneo, es decir, no se conforma
únicamente por profesionales de una sola rama, sino que se integra con profesionales del diseño, del
desarrollo de software, arquitectos de información, publicistas y redactores. En ocasiones todo esto
es ejecutado por una sola persona.
1. El equipo de desarrollo web : Un proyecto no puede llegar a buen término si los miembros del
equipo no tienen roles y responsabilidades claramente definidas, los proyectos van de manera mucho
más fluida y se mejora la moral del equipo. La pregunta en este caso es, cómo definimos roles en un
proyecto de desarrollo web y cómo logramos la integración continua entre miembros que
vienen de trasfondos muy diferentes.
Algunos de los roles que deben existir junto con el gestor de proyecto en un proyecto web, aunque
puedan ser realizados por la misma persona:
• Cliente / StakeHolder : Quizá el miembro más importante del equipo, el cliente debe participar en el
proceso de desarrollo aportando ideas y ayudando a delimitar el proyecto, en los casos en los que sea
necesario hacer una reestructuración el gestor del proyecto y el cliente son los que definirán que
funcionalidades se modificarán.
• Analista de procesos: Junto con el gestor de proyectos trabajará comúnmente un analista de

procesos, de forma que se encargue de recopilar información sobre la forma en la que funcionan los
clientes en el ámbito físico y luego traducirlo a requerimientos para el equipo de desarrollo. Se
convierte en el asesor del cliente, ayudándolo a definir las funcionalidades.
• Programador / Desarrollador: Existen varios tipos de desarrolladores que participan dentro de un

proyecto web, desde los programadores de interfaces, programadores del lado del servidor,
programadores de aplicaciones flash y programadores de bases de datos. Cada uno de ellos debe ser
responsable por participar en las reuniones de avance y pueden sugerir elementos de información
que deben conocerse para mejorar el desarrollo.
- Diseñador gráfico: El diseñador gráfico se debe hacer cargo de la apariencia de cada página en el sitio,
se debe encargar de preparar prototipos de diseño para las páginas frontales y los componentes del
proyecto. Mantiene una relación estrecha con los desarrolladores para poder distribuir el contenido
dentro de la página, definiendo estilos y elementos que se deben incluir.
- Redactor / Editor de contenidos: Este rol dependerá del tamaño del proyecto, siempre es bienvenido
tener un miembro en el equipo que se asegure de que el mensaje que se quiere expresar en cada texto
que aparece en nuestro proyecto no sólo está bien redactado, sino que está transmitiendo la idea
precisa.
- Tester (Aseguramiento de calidad): Este rol muchas veces es olvidado y no incluido en los proyectos,
pero es fundamental si queremos lograr un buen nivel en nuestras aplicaciones. A pesar de que podemos
contar con herramientas automatizadas de evaluación de aplicaciones, no todo se puede automatizar en
la web, desde si los colores están siendo bien utilizados, si los botones tienen la apariencia correcta hasta
si se está ejecutando de la forma esperada.
METODOLOGÍAS DE DESARROLLO
DE SOFTWARE
LINEA DEL TIEMPO EN EL AVANCE EN LA FORMA Y MÉTODO DE DESARROLLO DE
SOF.
El desarrollo de los sistemas tradicionales de ciclo de vida se originó en la década de 1960

para desarrollar a gran escala funcional, sistemas de negocio en una época de grandes
conglomerados empresariales. La idea principal era continuar el desarrollo de los sistemas
de información de manera deliberada, estructurada y metódica, reiterando cada una de
las etapas del ciclo de vida.
1970 s
Programación estructurada desde 1969
Programación estructurada Jackson desde 1975
1980 s
Structured Systems Analysis and Design Methodology (SSADM) desde 1980
Structured Analysis and Design Technique (SADT) desde 1980
Ingeniería de la información (IE/IEM) desde 1981
DE SOFTWARE
1990 s
Programación orientada a objetos (OOP) a lo largo de la década de los 90's
Virtual finite state machine (VFSM) desde 1990s
Dynamic Systems Development Method desarrollado en UK desde 1995.
Scrum (desarrollo), en la última parte de los 90's.
Nuevo milenio
Programación extrema desde 1999

Enterprise Unified Process (EUP) extensiones RUP desde 2002
Rational Unified Process (RUP) desde 2003.
Constructionist design methodology (CDM) desde 2004 por Kristinn R. Thórisson
Agile Unified Process (AUP) desde 2005 por Scott Ambler
A continuación definiremos algunas de estas metodologías, especialmente las más utilizadas

desde la década de los 90
DE SOFTWARE
MODELO DE DESARROLLO EN CASCADA
Fue originalmente documentado por Royce en el año 1970, lo que lo convierte en el

paradigma de ingeniería de software más antiguo.
El modelo de cascada expone que el desarrollo de software puede verse como una
secuencia simple de fases encadenadas linealmente. Estas fases, que difieren rara vez entre
autores, pero con algunas diferencias producto de traducciones e interpretaciones, se
caracterizan siempre y en general son las siguientes: especificación de requerimientos,
planificación, modelamiento, construcción y desarrollo, y soporte (mantenimiento) del
software completo.
DE SOFTWARE
DE SOFTWARE
a) Ingeniería y Análisis del Sistema. Debido a que el software es siempre parte de un

sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos
del sistema y luego asignando algún subconjunto de estos requisitos al software.
b) Análisis de los requisitos del software. El proceso de recopilación de los requisitos
se centra e intensifica especialmente en el software. El ingeniero de software (Analistas)
debe comprender el ámbito de la información del software, así como la función, el
rendimiento y las interfaces requeridas.
c) Diseño. El diseño del software se enfoca en cuatro atributos distintos del programa: la
estructura de los datos, la arquitectura del software, el detalle procedimental y la
caracterización de la interfaz. El proceso de diseño traduce los requisitos en una
representación del software con la calidad requerida antes de que comience la
codificación.
DE SOFTWARE
d) Prueba. Una vez que se ha generado el código comienza la prueba del programa. La
prueba se centra en la lógica interna del software, y en las funciones externas, realizando
pruebas que aseguren que la entrada definida produce los resultados que realmente se
requieren.
e) Mantenimiento. El software sufrirá cambios después de que se entrega al cliente. Los
cambios ocurrirán debido a que hayan encontrado errores, a que el software deba
adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o
debido a que el cliente requiera ampliaciones funcionales o del rendimiento.
DE SOFTWARE
Características y factores del paradigma Cascada.
DE SOFTWARE
MODELO/ PARADIGMAS DE DESARROLLO INCREMENTALES
En situaciones en las que los requerimientos iniciales están bien definidos, pero que según
el alcance del proyecto existe la posibilidad de que el desarrollo no sea lineal, se provee
de un paradigma de procesos que está diseñado para producir software por incrementos.
Para ello, limitan la funcionalidad del software para que pueda ser revisado por el cliente
y que éste a su vez lo refine para tenerlo listo en la siguiente etapa del proyecto.
A continuación paradigmas a tratar:
- RAD - Diseño Rápido de Aplicaciones, Paradigma Incremental

DE SOFTWARE
RAD - DISEÑO RÁPIDO DE APLICACIONES
Es un paradigma de proceso en cascada que enfatiza un ciclo de desarrollo extremadamente

corto fue definido por James Martin a principios de la década de 1980.
El mismo es una adaptación a alta velocidad del paradigma lineal secuencial en cascada, en el
que se enfatiza un ciclo de vida extremadamente corto.
Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la

usabilidad, utilidad y la rapidez de ejecución.
El modelo de Desarrollo RAD, cuenta con 5 etapas principales:

1. Modelado de Gestión.
2. Modelado de Datos
3. Modelado de Procesos.
4. Generación de Aplicación.
5. Prueba y entrega
DE SOFTWARE
a) Modelado de Gestión. El flujo de información entre las funciones de gestión se modela

de forma que responda a las siguientes preguntas:
- ¿Qué información conduce el proceso de gestión?. ¿Qué información se genera?
- ¿Quién la genera? . ¿A dónde va la información?. ¿Quién la procesa?
b) Modelado de Datos. El flujo de información definido como parte de la fase de modelado

de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la
empresa.
c) Modelado de Proceso. Los objetos de datos definidos en la fase de modelado de datos
quedan transformados para lograr el flujo de información necesario para implementar una
función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o
recuperar un objeto de datos.
DE SOFTWARE
d) Generación de Aplicaciones. El RAD asume la utilización de técnicas de cuarta generación.

En lugar de crear el software con lenguajes de programación de tercera generación por
ejemplo, un lenguaje de programación), el proceso RAD trabaja para volver a utilizar
componentes de programas ya existentes cuando esto es posible, o se crean componentes
reutilizables cuando es necesario. En todos los casos se utilizan herramientas automáticas
para facilitar la construcción del software.
e) Pruebas y entrega. Como el proceso RAD enfatiza la reutilización, ya se han

comprobado muchos de los componentes de los programas. Esto reduce el tiempo de
pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben
ejercitar todas las interfaces a fondo.
DE SOFTWARE
Características y factores del modelo paradigma

DE SOFTWARE
PARADIGMAS DE DESARROLLO EVOLUTIVO
Los paradigmas evolutivos se caracterizan por desarrollar versiones cada vez más
completas del software.
A continuación los paradigmas a describir:
- Paradigma de construcción de Prototipos; y,
- Paradigma en Espiral.
PROTOTIPOS
El uso de prototipos se centra en la idea de ayudar a comprender los requisitos que plantea el
usuario, sobre todo si este no tiene una idea muy acabada de lo que desea. También pueden
utilizarse cuando el ingeniero de software tiene dudas acerca de la viabilidad de la solución
pensada.
Esta versión temprana de lo que será el producto, con una funcionalidad reducida, en
principio, podrá incrementarse paulatinamente a través de refinamientos sucesivos de las
especificaciones del sistema, evolucionando hasta llegar al sistema final.
DE SOFTWARE
PROTOTIPOS
ETAPAS
a) Requerimientos. (Análisis de requisitos del sistema y análisis de requisitos del software).
b) Diseño. Desarrollo e implementación del prototipo.
c) Codificación y test unitario. (Incluye prueba del prototipo, refinamiento iterativo del
prototipo y refinamiento de las especificaciones del prototipo).
d) Integración del sistema. (Incluye diseño e implementación del sistema final).
e) Explotación. (U operación) y mantenimiento.
DE SOFTWARE
PROTOTIPOS: ETAPAS
a) Requerimientos. (Análisis de requisitos del sistema y análisis de requisitos del software).
b) Diseño. Desarrollo e implementación del prototipo.
c) Codificación y test unitario. (Incluye prueba del prototipo, refinamiento iterativo del
prototipo y refinamiento de las especificaciones del prototipo).
d) Integración del sistema. (Incluye diseño e implementación del sistema final).
e) Explotación. (U operación) y mantenimiento.
DE SOFTWARE
PROTOTIPOS
VENTAJAS
Este modelo es útil cuando el cliente conoce los objetivos generales para el software.
Ofrece un mejor enfoque cuando el responsable del desarrollo del software está
inseguro de la eficacia de un algoritmo, de la adaptabilidad.
Se puede reutilizar el código

DE SOFTWARE
PROTOTIPOS
DESVENTAJAS
El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final
A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos

importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte
de los casos a reconstruirlo una vez que el prototipo ha cumplido su función.
En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de

implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto
porque proporciona un desarrollo más rápido).
A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos
importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte
de los casos a reconstruirlo una vez que el prototipo ha cumplido su función.
En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de

implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto
porque proporciona un desarrollo más rápido).
DE SOFTWARE
MODELO EN ESPIRAL.
El paradigma espiral para la ingeniería de software ha sido desarrollado para cubrir las
mejores características tanto del ciclo de vida clásico, como de la creación de prototipos,
añadiendo al mismo tiempo un nuevo elemento: el análisis de riesgo.
ETAPAS DEL MODELO
Las etapas de este modelo se describen a continuación:

a) Planificación. Determinación de objetivos, alternativas y restricciones.
b) Análisis de riesgo. Análisis de alternativas e identificación/resolución de riesgos.
c) Ingeniería. Desarrollo del producto del "siguiente nivel".
d) Evaluación del cliente. Valorización de los resultados de la ingeniería
DE SOFTWARE
MODELO EN ESPIRAL.
DE SOFTWARE
MODELO EN ESPIRAL.
DE SOFTWARE
MODELOS ADAPTATIVOS
En años recientes, diversas ideas han sido publicadas en cuanto a formas de hacer el proceso
de desarrollo de software más ligero o ágil de implementar y con mejor respuesta a las
necesidades de los clientes. A continuación los paradigmas a describir:
- eXtreme Programming (XP) Programación Extrema,
- SCRUM,
- Adaptive Software Development (ASD); y,
- Crystal Methods (CM).
Para los fines de lugar solo consideraremos los dos primeros.
Estas metodologías han demostrado sus beneficios en términos de time-to-market,

adaptabilidad a la evolución de los requisitos, satisfacción del cliente y entrega de
productos rápidamente y dentro del presupuesto estipulado en un cierto número de
dominios.
DE SOFTWARE
MODELOS ADAPTATIVOS
Extreme Programming (XP) Programación Extrema
La Programación Extrema o Extreme Programming (XP) es un enfoque de la ingeniería de

software formulado por Kent Beck en 1999 1 . Es el más destacado de los procesos ágiles de
desarrollo de software.
Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales
principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad.
La capacidad de adaptación a los cambios de requisitos en cualquier punto de la vida del

proyecto, experimentalmente demuestra ser una aproximación mejor y más realista que
intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en
controlar los cambios en los requisitos.
DE SOFTWARE
Los principios originales de la programación extrema son: Simplicidad, comunicación,
retroalimentación (feedback), coraje y respeto.
Simplicidad
La simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el
desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas
modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente
exponencialmente.
Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de
mantener el código simple a medida que crece.
También se aplica la simplicidad en la documentación, de esta manera el código debe

comentarse en su justa medida, intentando eso sí que el código esté autodocumentado. Para
ello se deben elegir adecuadamente los nombres de las variables, métodos y clases.
DE SOFTWARE
Comunicación
La comunicación se realiza de diferentes formas. Para los programadores el código comunica

mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo
inteligible. El código autodocumentado es más fiable que los comentarios ya que éstos
últimos pronto quedan desfasados con el código a medida que es modificado.
Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de una clase o la
funcionalidad de un método.
Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las
clases y los métodos al mostrar ejemplos concretos de cómo utilizar su funcionalidad. Los
programadores se comunican constantemente gracias a la programación por parejas.
DE SOFTWARE
Realimentación (feedback)
Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce
en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se
minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los
programadores a centrarse en lo que es más importante.
Coraje o valentía
Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para
hoy y no para mañana. Esto es un esfuerzo para evitar empantanarse en el diseño y requerir
demasiado tiempo y trabajo para implementar el resto del proyecto.
La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su
código cuando sea necesario.
DE SOFTWARE
Respeto
El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a
otros, porque los programadores no pueden realizar cambios que hacen que las pruebas
existentes fallen o que demore el trabajo de sus compañeros. Los miembros respetan su
trabajo porque siempre están luchando por la alta calidad en el producto y buscando el
diseño óptimo o más eficiente para la solución a través de la refactorización del código. Los
miembros del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor
autoestima en el equipo eleva su ritmo de producción.
DE SOFTWARE
DE SOFTWARE
SCRUM
Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para la
gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está
especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales
características se pueden resumir en dos. El desarrollo de software se realiza mediante
iteraciones, denominadas sprints, con una duración de 30 días.
El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La

segunda característica importante son las reuniones a lo largo proyecto. Éstas son las
verdaderas protagonistas, especialmente la reunión diaria de 15 minutos del equipo de
desarrollo para coordinación e integración .
DE SOFTWARE
SCRUM
Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que
puede tomarse como punto de partida para definir el proceso de desarrollo que se
ejecutará durante un proyecto.
Los roles principales en Scrum son:

ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto.
Product Owner, que representa a los stakeholders (clientes externos o internos).
El Team que incluye a los desarrolladores.
Scrum es un proceso en el que se aplican de manera regular un conjunto de mejores prácticas

para trabajar en equipo y obtener el mejor resultado posible de un proyecto. Estas prácticas
se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de
equipos altamente productivos.
DE SOFTWARE
SCRUM
En Scrum se realizan entregas parciales y regulares del resultado final del proyecto,
priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está
especialmente indicado para proyectos en entornos complejos, donde se necesita obtener
resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la
innovación, la competitividad y la productividad son fundamentales.
Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente
lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad
no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la
moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar
ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso
especializado en el desarrollo de producto.
DE SOFTWARE
SCRUM
En Scrum se realizan entregas parciales y regulares del resultado final del proyecto,
priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está
especialmente indicado para proyectos en entornos complejos, donde se necesita obtener
resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la
innovación, la competitividad y la productividad son fundamentales.
Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente
lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad
no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la
moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar
ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso
especializado en el desarrollo de producto.
DE SOFTWARE
SCRUM
Las actividades que se llevan a cabo en Scrum son las siguientes:

a) Planificación de la iteración. El primer día de la iteración se realiza la reunión de
planificación de la iteración. Tiene dos partes:
- Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de requisitos
priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y
selecciona los requisitos más prioritarios que se compromete a completar en la iteración, de
manera que puedan ser entregados si el cliente lo solicita.
Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y

cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de
manera continua su productividad.
DE SOFTWARE
SCRUM
Características y factores del paradigma SCRUM :
Durante cada sprint, un periodo entre 15 y 30 días (la magnitud es definida por el equipo),
el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto
de características que forma parte de cada sprint viene del Product Backlog, que es un
conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar.
Los elementos del Product Backlog que forman parte del sprint se determinan durante la
reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos
del Product Backlog que quiere ver completados y los hace del conocimiento del equipo.
DE SOFTWARE
SCRUM

Implementacion y Direccon de Sistema de Informacion - Modulo2

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Implementacion y Direccon de Sistema de Informacion - Modulo2

Caricato da

Copyright:

Formati disponibili

IMPLEMENTACIÓN Y DIRECCIÓN DE

Desarrollo y Documentación de Sistemas

Al completar este módulo, los participantes podrán estar en la capacidad de :

1. Comprender los tipos de sistemas de información que implementan las organizaciones.

Los sistemas de procesamiento de transacciones (TPS, Transaction Processing Systems)

Los MIS (Management Information Systems) y los sistemas de apoyo a la toma de

Los sistemas de apoyo a ejecutivos (ESS, Executive Support Systems) se encuentran en el

Un TPS elimina el fastidio que representa la realización de transacciones operativas necesarias y

Los sistemas de procesamiento de transacciones expanden los límites de la organización dado

Los MIS son sistemas de información computarizados cuyo propósito es contribuir a la

Para acceder a la información, los usuarios de un sistema de información gerencial

Como se puede observar en la imagen, un sistema gerencial,

Costo en que incurre la empresa X Empleado

Los sistemas de apoyo a la toma de decisiones se ajustan más al gusto de la persona o

El analista de sistemas evalúa de manera sistemática el funcionamiento de un negocio me-

EL ROL DE EXPERTO EN SOPORTE TÉCNICO DEL ANALISTA DE SISTEMAS

Como analista, usted es un agente de cambio si desempeña cualquiera de las actividades

Como analista, se es un agente de cambio se desempeñan cualesquiera de las actividades

En su calidad de analista de sistemas desempeñando la función de agente de cambio,

1. solucionador de problemas: Es una persona que aborda como un reto el análisis de

1. El analista de sistemas debe ser una persona autodisciplinada y automotivada: con

En esta primera fase el analista se ocupa de identificar problemas, oportunidades y

El aprovechamiento de las oportunidades podría permitir a la empresa obtener una ventaja

La siguiente fase que enfrenta el analista es la determinación de los requerimientos de in-

• PRUEBA Y MANTENIMIENTO DEL SISTEMA(ANÁLISIS FUNCIONAL, PREMISA DE CALIDAD)

Antes de poner el sistema en funcionamiento es necesario probarlo. Es mucho menos cos-

Las pruebas más comunes son las:

Ésta es la última fase del desarrollo de sistemas, y aquí el analista participa en la

Cuando se habla de proyecto Web, nacen preguntas como:

En el caso de los sistemas de información que se han creado en torno a la web y el

Informativos : Periódicos en línea, catálogos de productos, manuales, reportes,

Interactivos : Formularios de Registro, información personalizada, presentaciones, juegos en

La compatibilidad entre diferentes navegadores, es interesante cuando desarrollamos

Cuando pensamos en un producto de software, viene a nuestras mentes el grupo objetivo

Un producto de software para web tiene consideraciones adicionales a las de un producto

- Contenido: La web nació de la necesidad de compartir información, y aunque ha variado con

- Apariencia: En el software tradicional la apariencia va determinada normalmente por el

- Arquitectura de la información: Las aplicaciones web se basan en la interrelación

La limitante más fuerte en cuanto al desarrollo de un sistema de información web, es que

Si el proyecto en el que se va a trabajar necesita será de mayor envergadura y el equipo

Una arquitectura multi-capas estándar está compuesta de los siguientes elementos:

Para pensar en N Capas, pensemos en un sistema de Comunicación Cliente Servidor.

SSH : Puerto 22 Secure shell

• Analista de procesos: Junto con el gestor de proyectos trabajará comúnmente un analista de

• Programador / Desarrollador: Existen varios tipos de desarrolladores que participan dentro de un

El desarrollo de los sistemas tradicionales de ciclo de vida se originó en la década de 1960

Programación extrema desde 1999

A continuación definiremos algunas de estas metodologías, especialmente las más utilizadas

Fue originalmente documentado por Royce en el año 1970, lo que lo convierte en el

a) Ingeniería y Análisis del Sistema. Debido a que el software es siempre parte de un

MODELO DE DESARROLLO EN CASCADA

- RAD - Diseño Rápido de Aplicaciones, Paradigma Incremental

Es un paradigma de proceso en cascada que enfatiza un ciclo de desarrollo extremadamente

Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la

El modelo de Desarrollo RAD, cuenta con 5 etapas principales:

a) Modelado de Gestión. El flujo de información entre las funciones de gestión se modela

b) Modelado de Datos. El flujo de información definido como parte de la fase de modelado

d) Generación de Aplicaciones. El RAD asume la utilización de técnicas de cuarta generación.

e) Pruebas y entrega. Como el proceso RAD enfatiza la reutilización, ya se han

RAD - DISEÑO RÁPIDO DE APLICACIONES

Características y factores del modelo paradigma

Se puede reutilizar el código

A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos