FUNDAMENTOS DE SISTEMAS
TAREA #1
1.1 SISTEMA vs SISTEMA DE INFORMACIÓN
Sistema
Se define como un conjunto de elementos dinamicamente relacionados.Cada sistema existe dentro de otro mas grande.
Sistema de información
es un conjunto de elementos orientados al tratamiento y administración de datos e información, organizados y listos para su posterior uso, generados para cubrir una necesidad.
1.2 ¿QUE ES UN BUEN SISTEMA?
Los sistemas de información tratan el desarrollo,uso y administración de la infraestructura de la tecnología de la información organizacional.
1.3 ¿SE TIENE BUENOS SISTEMAS?
Si, ya que existe avances satisfactorios.
1.4 ¿COMO SON LOS BUENOS SISTEMAS?
Un sistema es un conjunto de módulos y existen algunas dependencias entre ellos; los módulos pueden ser los siguientes:
- Confiable
- Necesario
- Completo
- Eficiente
- Consistente
- Conciso
CRUCIGRAMA
CLASIFICACIÓN DE LOS SISTEMAS DE INFORMACIÓN
TAREA #2
Los sistemas de información, de manera general se pueden clasificar de tres formas según sus propósitos generales, en este sentido Peralta (2008) clasifica los sistemas de información en tres tipos fundamentales:
1. Sistemas transaccionales: Son Sistemas de Información que logran la automatización de procesos operativos dentro de una organización ya que su función primordial consiste en procesar transacciones tales como pagos, cobros, entradas, salidas, etc.
2. Sistemas de Soporte a la Toma de Decisiones, Sistemas para la Toma de Decisión de Grupo, Sistemas Expertos de Soporte a la Toma de Decisiones y Sistema de Información para Ejecutivos: Son Sistemas de Información que apoyan el proceso de toma de decisiones.
3. Sistemas Estratégicos: Son sistemas de información desarrollado en las organizaciones con el fin de lograr ventajas competitivas, a través del uso de la tecnología de información.
De acuerdo al elemento principal de proceso de la información, los sistemas de información pueden ser de tres tipos (Manual, Mecanizadas y Bath):
Manuales
Cuando el hombre auxiliado por cierto equipo (máquinas de escribir, sumadoras, archivos, etc.) realiza las principales funciones de recopilación, registro, almacenamiento, cálculo y generación de información.
Mecanizadas
Cuando cierta maquinaria realiza las principales funciones de procesamiento. Para los sistemas mecanizados que hacen uso de un computador, de acuerdo al tipo de interacción Hombre-Máquina, los sistemas de información pueden ser de dos tipos (Batch y en Línea]: Batch: el usuario proporciona los datos necesarios para la ejecución de un proceso y espera a que el computador termine la tarea para recibir los resultados;
En Línea
Existe un diálogo directo entre el usuario y el computador durante la ejecución de un proceso.
En cuanto a la organización física de los principales recursos de procesamiento de datos, los sistemas de información pueden ser de tipo:
- Procesos centralizados: los recursos se encuentran ubicados en un área física determinada, por lo que su acceso se realiza en las misma instalación o desde lugares retirados, mediante líneas de comunicación de datos (telefónicas, microondas, satélite, etc.).
ESTILOS ORGANIZACIONALES Y SU IMPACTO SOBRE LOS SISTEMAS DE INFORMACIÓN
Durante los últimos años los sistemas de información han avanzado considerablemente formándose a si como fuentes estructurales y lógicas para el desarrollo de cualquier organización y en un eje central de avance empresarial, se considera como un nivel de competencia que las organizaciones accedan a los avances tecnológicos de la información ya sea en recurso humano o material para poder ser competitiva en un mercado que cada día ofrece mayor competitividad con eficiencia, eficacia y optimización de procesos.
Los sistemas de información se han convertido en un recurso mas para las organizaciones debido a los cambios estructurales en la gestión administrativa esto se da por que las tecnologías han tomado una mayor importancia por su agilidad al optimizar información y su desarrollo informático no para es un constante avance tecnológico que puede convertirse en soluciones a problemas organizacionales ya que no solo avanzan los sistemas también debe haber un avance estructurar del ente organizacional en recursos humanos y infraestructura .
Dentro del impacto que tiene los de los sistemas de información dentro del ente organizacional se encarga de forjar nuevas expectativas de competencia mercantil entre las diversa organizaciones debido a que las organizaciones
QUE ES EL ANÁLISIS DE SISTEMAS
El análisis de sistemas es el estudio de una aplicación del sistema de información y de empresa actual y la definición de las necesidades y las prioridades de usuario para conseguir una aplicación nueva o mejorada
El Análisis de Sistemas trata básicamente de determinar los objetivos y límites del sistema objeto de análisis, caracterizar su estructura y funcionamiento, marcar las directrices que permitan alcanzar los objetivos propuestos y evaluar sus consecuencias. Dependiendo de los objetivos del análisis, podemos encontrarnos ante dos problemáticas distintas:
- Análisis de un sistema ya existente para comprender, mejorar, ajustar y/o predecir su comportamiento
- Análisis como paso previo al diseño de un nuevo sistema-producto
- Estudio de Viabilidad del proyecto (o fase de inspección)
- Estudio y análisis del sistema actual (o fase de estudio)
- Definición y establecimiento de prioridades entre las necesidades de usuarios (o fase de definición)
- Conceptualización
- Análisis funcional
- Análisis de condiciones (o constricciones)
Estas se derivan a veces de los propios objetivos del sistema:
- Operativas, como son las restricciones físicas, ambientales, de mantenimiento, de personal, de seguridad, etc.
- De calidad, como fiabilidad, mantenibilidad, seguridad, convivencia, generalidad, etc.
- Económicos, reflejados en un presupuesto
- Temporales, que suponen unos plazos a cumplir
- Humanos
- Metodológicos, que conllevan la utilización de técnicas determinadas
- Materiales, como espacio, herramientas disponibles, etc.
Construcción de modelos
Una de las formas más habituales y convenientes de analizar un sistema consiste en construir un prototipo (un modelo en definitiva) del mismo.
Validación del análisis
A fin de comprobar que el análisis efectuado es correcto y evitar, en su caso, la posible propagación de errores a la fase de diseño, es imprescindible proceder a la validación del mismo.
Para ello hay que comprobar los extremos siguientes:
- El análisis debe ser consistente y completo
- Si el análisis se plantea como un paso previo para realizar un diseño, habrá que comprobar además que los objetivos propuestos son correctos y realizables
CUÁL ES LA FUNCIÓN DEL ANALISTA DE SISTEMAS?
Las principales FUNCIONES que debe desarrollar un analista de sistemas son:
1. Planificar la actividad o trabajo de análisis y diseño de sistemas.
2. Organizar a todos los elementos que intervienen en el proyecto (técnicos de análisis y diseño, programadores, usuarios, equipamiento, etc.)
3. Controlar el trabajo del equipo de diseño para garantizar el cumplimiento de los planes elaborados.
4. Escoger (o diseñar) y utilizar los métodos, técnicas y herramientas más adecuadas para el desarrollo del trabajo del colectivo.
5. Estudiar el sistema de dirección y organización e información de la entidad.
6. Diseñar el nuevo sistema informativo, desde un punto de vista funcional, en primera instancia.
7. Representar algorítmicamente los procesos que se realizan en cada tarea funcional integrante del sistema que se diseña.
8. Diseñar el sistema, descomponiendo el mismo en todos los niveles previstos y con todos los enfoques necesarios.
9. Diseñar la base de datos que utilizará el sistema. Optimizar la misma, utilizando las técnicas requeridas para ello.
10. Diseñar los documentos (formularios) de utilización manual o manual automatizada, que requiera el sistema. Describir su método de llenado.
11. Diseñar las salidas de la computadora, de la forma más idónea requerida.
12. Elaborar las soluciones a los procedimientos manuales que requiera el sistema.
13. Diseñar los flujos informativos a través de los diferentes elementos que integran el sistema: hombre-hombre, hombre - computadora, computadora - hombre, computadora - computadora.
14. Proponer y aplicar las medidas de carácter organizativo que se requiera para perfeccionar la actividad de dirección estudiada y para implantar el sistema que se diseña.
GLOSARIO
SIG
Sistema De Información Geográfica
SI
Sistema De Información
SIE
Sistema De Información Ejecutivo
SIG
Sistema De Información Gerencial
TPS
Sistema De Proceso De Transacciones
ERP
Sistema Planificación De Recursos
BBS
Es Un Servicio De Intercambio De Información Entre Usuarios.
MRP
Planificación Del Requerimiento Material.
SE
Sistema Experto
MIS
Sistema De Información Administrativo
OAS
Sistema De Automatización De Oficinas
DSS
Sistema De Soporte De Decisiones
EIS
Sistema De Información Ejecutiva.
Lunes 30 de Agosto del 2010
TIPOS DE SISTEMA DE INFORMACION
TAREA #3
SISTEMA DE PROCESAMIENTO DE TRANSACCIONES (TPS)
Es el conjunto organizado de personas, procedimientos, software, base de datos y dispositivos para registrar transacciones comerciales consumadas, por ejemplo:
- Sistemas bancarios en las sucursales.
- Cajeros automáticos.
- Sistemas WEB de compras.
SISTEMA DE AUTOMATIZACION DE OFICINA (O.S.A)
Los sistemas ofimáticos representan la aplicación de la informática a las tareas menos estructuradas que se desarrollan en una oficina, por ejemplo: (correspondencia, elaboración de datos numéricos, compartición entre varios empleados de información escrita no numérica)
SISTEMAS DE INFORMACIÓN GERENCIAL (MIS)
Sistemas que generan espectros estadísticos instantáneos del estado que guarda la empresa, formado por
informes electrónicos y consultas específicas sobre otros sistemas informáticos.
SISTEMAS DE APOYO A LA DECISIÓN (DSS)
Los sistemas de apoyo a la decisión (DSS) son sistemas de tipo OLAP o de minería de datos que proporcionan información y soporte para tomar decisiones.
Por mencionar algunos ejemplos:
Tendencias de ventas
- Por temporada
- Por publicidad
Correlaciones
- Si compran jamón también compran pan
- Si compran atún también compran galletas
- Si compran bebidas dietéticas NO compran azúcar
- Dendral
- XCon
- DipmeterAdvisor
- JessProlog
Un buen sistema de información para ejecutivos presenta información en forma de gráficos, columnas y textos.
La capacidad para hacer gráficos se necesita para facilitar en el análisis rápido de las condiciones y tendencias corrientes; las tablas presentan mayor detalle y permiten el análisis de variaciones; la información de textos añade interpretaciones y detalles de los datos.
SISTEMAS DE APOYO A LA DECISIÓN EN GRUPO (GDSS)
Es un sistema interactivo basado en computadora, el cual facilita la solución de problemas no estructurados por un conjunto de tomadores de decisiones trabajando juntos como un grupo.
- Establecimiento de la misión de la empresa: cuando se está creando una empresa es necesario definir la misión que se quiere cumplir en el mercado y en este proceso puede usarse un GDSS para generar ideas útiles y tomar la mejor decisión.
BIBLIOGRAFIA
- http://mural.uv.es/roigmi/exposicion.ppt.
- http://antiguo.itson.mx/dii/epadilla/Presentacion%20TOI%20TPS.ppt.
- http://html.rincondelvago.com/procesamiento-de-transacciones.html.
- http://es.wikipedia.org/wiki/Sistemas_de_apoyo_a_la_decisi%C3%B3n.
- http://www.slideshare.net/joralunasilva/sistema-de-informacion-gerencial.
- http://dieumsnh.qfb.umich.mx/sistemasInfo/intro.htm.
- http://www.slideshare.net/arturobq/ess-presentation.
- http://monica-jesus83.blogspot.com/2009/05/sistemas-de-soporte-ejecutivos-ess.html.
Martes 31 de Agosto del 2010
FACTIBILIDAD ECONÓMICA
TAREA #4
Los costos de implementación incluyen comúnmente el costo remanente de la investigación de sistemas (ara este propósito, los costos en los que ya se ha incurrido no son relevantes), los costos de hardware y software, los costos de operación del sistema para su vida útil esperada, y los costos de mano de obra, material, energía, reparaciones y mantenimiento. A través del análisis de costo/beneficio, la organización debe apoyarse en los conceptos tradicionales de análisis financiero y las herramientas como teoría del valor presente, análisis de costos diferenciales y análisis de flujos descontados.
Algunos costos y beneficios pueden cuantificarse fácilmente. Los beneficios que pueden cuantificarse con facilidad son de dos tipos generales: Ahorros en costos, tales como una disminución en costos de operación y aumentos en las utilidades directas. Como un ejemplo de lo último, un cliente podría haber contratado la suministración de pedidos de una cantidad conocida si la organización implanta un sistema que información que proporcione al cliente información continua acerca del estado de la producción en proceso de los embarques planeados de mercancía, de tal forma que a los clientes de dicho cliente pueda dárseles estimaciones exactas de cuándo estará disponible la mercancía.
Un problema importante con el análisis de costos/beneficio es la atención inadecuada de costos y beneficios intangibles. Éstos son aspectos de las alternativas de los nuevos sistemas que sí afectan los costos y utilidades y deberían evaluarse pero que los afectan en formas que no pueden cuantificarse fácilmente. Los factores intangibles con frecuencia están relacionados a la calidad de la información proporcionada por el sistema y a veces a formas sutiles en que esta información afecta a la empresa, tal como alternando las actitudes para que la información sea vista como un recurso.
BIBLIOGRAFIA
- http://ersmsystem.blogspot.com/2008/05/definicin-de-factibilidad-tcnica.html
- http://www.scribd.com/doc/17070138/FACTIBILIDAD-ECONOMICA
- http://es.wikipedia.org/wiki/Factibilidad
- http://www.trabajo.com.mx/factibilidad_tecnica_economica_y_financiera.html
Martes, 14 de Septiembre del 2010
RESOLUCION DEL MINICASO PRÁCTICO
CENTURY TOOL, AND, DIE, INC
1. ¿Qué haría usted si estuviera en el lugar del Sr. Washington?
En primer punto trataría inmediatamente de controlar a otro personal con mucha más experiencia, para poder tratar el sistema de información de cobros de cunetas
1.1 ¿Cómo racionaría ante el entendimiento de Larry, Valerie y de Gene?
Mal porque de u otra manera tenían una responsabilidad en común para poder mejorar el proyecto que tenían
2. ¿En que se equivoco Valerie? ¿Llevaba las riendas del proyecto? ¿Por qué si y porque no?
No, porque no tenía toda la información necesaria para poder empezar el proyecto y valerse de solo explicaciones
3. ¿En que se equivocaron Larry o Gene? ¿Se les puede considerar responsables del fracaso de un proyecto informático, cuando sus experiencias y conocimientos son limitados en el terreno de la informática?
Sí, porque de una u otra manera no compartieron un poco más de tiempo para poder planificar el desarrollo del trabajo.
4. ¿Qué error se cometió en el informa de Viabilidad?
Supuestamente se necesitaba un paquete de gestión de base de datos, pero no era necesario, porque podrían haber utilizado los archivos VSAM existentes.
4.1 ¿Se reunieron Valerie las veces necesarias?
No
4.2 ¿Fueron suficientes las fases de las que partió dicho informe?
No
4.3 ¿Se comprometió el equipo a dar una solución demasiado pronto? ¿Por qué si o porque no?
No, porque no tenían los datos suficientes para poder dar una información.
5. ¿Por qué se sentían tan incómodos Valerie y sus colaboradores con los problemas y las necesidades planteadas?
EL proyecto no funcionaba de acuerdo a lo planteado.
6. ¿Debería haberse cancelado el proyecto?
Si
6.1 ¿Qué habría pasado con la inversión de $150.000 que ya se había hecho?
Se hubiera perdido, pero hubiera facilitado la demora de todo un sistema.
7. Si usted fuera Larry o Valerie, ¿En que habría actuado de diferente manera?
Pidiendo un poco mas de accesoria a la hora de dar una solución inmediata si tan siquiera saber con profundidad lo que se va a desarrollar.
Martes, 14 de Septiembre del 2010
ISO/IEC 12207
ISO/IEC 12207 Information Technology / Software Life Cycle Processes, es el estándar para los procesos de ciclo de vida del software de la organización ISO.
Es un proceso de ciclo de vida para el software que incluye procesos y actividades que se aplican desde la definición de requisitos, pasando por la adquisición y configuración de los servicios del sistema, hasta la finalización de su uso.
Este tiene como objetivo principal proporcionar una estructura común para que compradores, proveedores, desarrolladores, personal de mantenimiento, operadores, gestores y técnicos involucrados en el desarrollo de software usen un lenguaje común.
Este lenguaje común se establece en forma de procesos bien definidos.
ESTRUCTURA
La estructura ha sido concebida de manera flexible y modular de manera que pueda ser adaptada a las necesidades de cualquiera que lo use.
Para conseguirlo, se basa en dos principios fundamentales:
MODULARIDAD Y RESPONSABILIDAD.
Con la modularidad pretende conseguir procesos con un mínimo acoplamiento y una máxima cohesión.
En la responsabilidad, se busca establecer un responsable para cada proceso, facilitando la aplicación del estándar en proyectos en los que pueden existir distintas personas u organizaciones involucradas.
PROCESOS
LOS PROCESOS SE CLASIFICAN EN TRES TIPOS:
Principales, de soporte y de la organización.
Los procesos de soporte y de organización deben existir independientemente de la organización y del proyecto ejecutado.
Los procesos principales se instancian de acuerdo con la situación particular.
A. PROCESOS PRINCIPALES.
o Adquisición.
o Suministro.
o Desarrollo.
o Operación.
o Mantenimiento.
B. PROCESOS DE SOPORTE.
o Documentación
o Gestión de la configuración.
o Aseguramiento de calidad.
o Verificación.
o Validación.
o Revisión conjunta.
C. PROCESOS DE LA ORGANIZACIÓN.
o Gestión.
o Infraestructura.
o Mejora.
o Recursos Humanos.
IEEE 830
El análisis y desarrollo de requerimientos tiene como producto final:
Un acuerdo documentado entre el cliente y el grupo de desarrollo acerca del producto a ser construido.
Estos documentos tienen por finalidad reunir los requisitos completos del cliente tal de desarrollar un software de acuerdo a las exigencias del mismo.
EL DOCUMENTO ES CONOCIDO COMO: Especificación de Requerimientos del Software, Especificación Funcional o Especificación del Sistema.
EL DOCUMENTO ES CONOCIDO COMO: Especificación de Requerimientos del Software, Especificación Funcional o Especificación del Sistema.
Esta especificación se ha realizado de acuerdo al estándar “IEEE Recomended Practice for Software Requirements Specifications (IEEE/ANSI 830-1993)”, y se basa en las entrevistas realizadas a los usuarios participantes y el estudio de la documentación existente
Lunes 20 de Septiembre del 2010
Como establecer una arquitectura de la información
Introducción
La Arquitectura de Información ha tenido, desde los años 90 del siglo XX, una creciente popularidad. Popularidad que decreció con la caída de las "punto com" en el 2001, pero que volvió a tomar auge en posteriores años.
Es lógico que al ser una profesión tan nueva no exista mucha bibliografía sobre los aspectos históricos y teóricos de la misma, posiblemente resultado de que esta disciplina deviene de un actuar eminentemente empírico (práctico) y por lo tanto su teoría está muy condicionada por la experiencia de quienes las desempeñan.
El presente artículo ofrece una aproximación al origen histórico, y por consiguiente a la conceptualización, de la Arquitectura de Información (que abreviaremos como AI).
EVOLUCIÓN CRONOLÓGICA DEL USO DEL TÉRMINO "ARQUITECTURA" EN EL ENTORNO COMPUTACIONAL.
El término "arquitectura" como se mencionó anteriormente, viene a ser usado en el entorno computacional a partir de los años 60. La primera evidencia la tiene el término "Arquitectura de Computadora" (computer architecture).
Desde entonces el término "arquitectura" ha extendido su uso para formar otros términos compuestos empleados en el entorno computacional. Ejemplo de ello los mostramos a continuación con un análisis cronológico realizado a partir de la presencia de los términos en la base de datos LISA (1998).
En la década del 70 se observa un amplio uso de los términos:
• Arquitectura de Base de Datos (Data Base Architecture)
• Arquitectura de Sistema (System Architecture)
Ya para la década del 80 se muestran otros como:
• Arquitectura de Software (Software Architecture)
• Arquitectura de Hardware (Hardware Architecture)
• Arquitectura de Redes (Networks Architecture)
• Arquitectura de la Comunicación (Communication Architecture)
• Arquitectura de Información (Information Architecture)
• Arquitectura de Sistemas de Información (Information System Architecture)
En los finales de los 80 y en los 90:
• Arquitectura Hipertextual (Hypertext Architecture)
• Arquitectura Empresarial (Enterprise Architecture)
• Arquitectura de Servidor (Server Architecture)
• Arquitectura de sitios Web (Website Architecture)
• Arquitectura de Procesos (Process Architecture)
Análisis conceptual de la arquitectura de información
Con la incorporación del término "arquitectura" en los años 60, encontramos elementos dentro de su conceptualización propuesta por Frederick P. Brook que ilustran funcionalmente lo que sería arquitectura en el contexto computacional. Esto lo podemos ver cuando dice que la "arquitectura de computadora, como la otra arquitectura, (…)" comparando este nuevo concepto con el de arquitectura tradicional, y más adelante cuando enfoca el proceso de diseño arquitectónico en las "necesidades de los usuarios" (Computer architecture. Wikipedia; 2008).
Otro elemento de interés lo encontramos en el artículo Architecture of the IBM System / 360 de Amdahl, Blaauw y Brooks (1964), cuando plantean que arquitectura es la definición de "la estructura conceptual y el comportamiento funcional". Obsérvese la similitud con la labor que hace un arquitecto de información actualmente.
Los conceptos ofrecidos en los años 70 se basan principalmente en hacer más asimilable la información de los entornos de trabajo o urbanos, siguiendo las pautas que nos muestra la arquitectura tradicional para crear un producto informativo final. Estos enfoques fueron expuestos por el proyecto de la Xerox y posteriormente por Wurman.
Los autores, en los años 80, conceptualizan la AI siguiendo enfoques empíricos, planteándola como un proceso dentro del diseño de software, específicamente dentro del diseño de sistemas de información.
Para Dickson y Wetherber (1985) la AI es: "Un gran mapa de los requerimientos de información de una organización. Es un perfil independiente, de las principales categorías de información, del personal, la organización y la tecnología dentro de una empresa (Dickson y Wetherbe; 1985, citado por Brancheau, Schuter y March; 1989).
Obsérvese cómo plantean los conceptos de Requerimientos, el de Mapa y el de Categorías de Información. Aquí el concepto de Perfil se refiere a una representación.
En 1986, en su artículo Information architectures: methods and practice, Brancheau y Wetherber amplían este concepto con: "El perfil (representación) muestra cómo las categorías de información se relacionan con los procesos de negocio y cómo deben estar conectadas para facilitar la toma de decisiones" (Brancheau, Wetherber; 1986).
En otro lugar del artículo la conceptualizan como: "El concepto de una arquitectura de información es examinado como un bloque de construcción fundamental que sostiene el desarrollo efectivo de sistemas de información." (Brancheau, Wetherber; 1986).
Como para concretar su concepto, más adelante plantean: "Una arquitectura de información es un diseño o plano para modelar los requerimientos de información global de una empresa. Proporciona un modo de representar las necesidades de información de una organización, relacionándolas con procesos de negocio específicos y documentando sus relaciones. Este mapa del proceso de la información se usa para guiar el desarrollo de las aplicaciones y para facilitar integrar y compartir datos" (Brancheau, Wetherber; 1986). Este último concepto corrobora también el origen social y tecnológico de la AI.
Para definir qué se hace en una AI estos autores plantean: "El proceso se inicia desde una vista conceptual de alto nivel, luego es sucesivamente refinado hasta el nivel más bajo en el que la base de datos física puede ser implementada" (Brancheau, Wetherber; 1986). Aquí se evidencia el criterio de diseño de lo general a lo particular.
Estos autores ubican a la AI como un proceso dentro del diseño de sistemas de información, específicamente dentro de la etapa en la que se hace el análisis de requerimientos para hacer el diseño del sistema. En su artículo plantean ideas persistentes:
• Blueprint (plano)
• Requeriment (requerimientos)
• Information categories (categorías de información)
• Guidelines on bussines processes relates (una guía de las relaciones de los procesos de negocio)
• Global corporate needs (Necesidades generales corporativas)
Estas categorías conceptuales son muy usadas actualmente en la AI. Otro elemento que apoya el criterio de que estos autores sentaron las bases en los procesos que hoy conocemos como AI es un artículo escrito por Brancheau, Vogel y Wetherbe titulado "An investigation of the Information Center from the user's perspective", donde estos autores realizan un profundo estudio de usuarios, argumentándolo como un paso vital para un buen diseño de un sistema de información.
En otro artículo Brancheau, Schuster y March (1989) afirman que: "Una arquitectura de información proporciona un marco en el que la planificación del desarrollo de aplicaciones pueda realizarse en el grupo y niveles del proyecto. Una arquitectura de información puede guiar decisiones acerca de qué aplicaciones deberían ser construidas".
http://www.nosolousabilidad.com/articulos/historia_arquitectura_informacion.htm
Lunes 4 de octubre del 2010
GESTIÓN DE PROYECTOS
PROYECTO: IMPLEMENTACIÓN DE UN SISTEMA DE FACTURACIÓN “D” DAVID
1. IDENTIFICAR RIESGOS
| NUMERO | TIPO DE RIESGO | POSIBLE RIESGO |
| 1 | TECNOLOGÍA | LAS FACTURAS SE REALIZAN DE FORMA MANUAL CAUSANDO PÉRDIDA DE TIEMPO |
| 2 | PERSONAL | NO CUENTA CON EL PERSONAL APROPIADO PARA PODER EJECUTAR DICHO SISTEMA. |
2. ANALIZAR RIESGOS
| :: ANALISIS DE RIEGOS | ||||
| RIESGO | DESCRIPCION | TIPO DE RIESGO | CATEGORIA | PROBABILIDAD |
| RENDIMIENTO DE LA BASE DE DATOS A IMPLEMENTAR LA FACTURA | LA BASE DE DATOS QUE UTILIZAMOS EN ESTE PROYECTO ES FACIL DE USAR PERO DEBIDO A LA FALTA DE CONOCIMIENTOS EN LOS DISTINTOS PROGRAMAS QUE INTERVIENEN EN ESTE PROYECTO SE NOS COMPLICO PODER CULMINAR ESTE PROYECTO | TECNOLOGICO | NEGOCIO | MODERADA |
| PROBLEMAS CON EL PERSONAL | NO LAS HUBO YA QUE ESTE PROYECTO ESTABAN ASIGNADO SOLO DOS PERSONAS | PERSONAL | PROYECTO | MODERADA |
3. ESTRATEGIAS
| RENDIMIENTO DE LA BASE DE DATOS A IMPLEMENTAR LA FACTURA | ESTRATEGIA |
| RENDIMIENTO DE LA BASE DE DATOS A IMPLEMENTAR LA FACTURA | IMPLEMENTAR UN SISTEMA QUE PERMITA AUTOMATIZAR LA FACTURACIÓN |
| PROBLEMAS CON EL PERSONAL | SUGERIR AL CLIENTE LA CONTRATACIÓN DE PERSONAL CON LAS BASES NECESARIAS PARA UTILIZAR ESTE TIPO DE SISTEMA |
4. SUPERVISIÓN
| TIPO DE RIESGO | INDICADOR POTENCIAL |
| TECNOLOGÍA | DEMASIADOS INCONVENIENTES CON EN EL SISTEMA |
| PERSONAL | MALA INTEGRACIÓN DEL PERSONAL, NO SABER UTILIZAR EL SISTEMA |
Jueves 8 de octubre del 2010
EJERCICIO DE FACTIBILIDAD
A)
Una mala inversión, porque la empresa no recupera lo invertido dentro del transcurso de vida del sistema (5años).
B) Extraiga los requisitos de Usuario.
· Registro del Inventario de los productos.
· Registro de Usuarios.
· Registro de Clientes.
· Registro de ventas.
· Actualizar STOCK
· Registro de código de producto.
C)
Extraiga 4 requisitos funcionales del Sistema.
· Los beneficios de incrementa año tras año.
· Abastece las necesidades del Supermercado.
· Mejora el control sobre las ventas e inventario.
· Permite recuperar el 10% perdido.
D) Extraiga los requisitos no funcionales del Sistema.
· Ubicar precios a cada producto.
· Mayor seguridad al Sistema.
· Sistema debe ser factible.
· Reducción de respuestas redundantes.
· Reducción de errores al momento de procesar.
· Necesita adaptaciones.
ANALISIS DE AMORTIZACIÓN DEL SISTEMA DE INFORMACIÓN | ||||||
| Descripción de cash flow | Año 0 | Año 1 | Año 2 | Año 3 | Año 4 | Año 5 |
| Costo de desarrollo | -3276,00 | | | | | |
| Costo de operación y mantenimiento | | -270 | -324 | -378 | -432 | -486 |
| Fact.des 15% | 1 | 0,870 | 0,756 | 0,658 | 0,572 | 0,497 |
| Costos de tiempoajustado (ajustado al valor actual) | -3276,00 | -235 | -245 | -249 | -247 | -242 |
| Costos acumulados en tiempo ajustado a lo largo del tiempo de vida | -3276,00 | -3511 | -3756 | -4004 | -4251 | -4493 |
| | | | | | | |
| Beneficios obtenidos del funcionamiento del nuevo sistema | 0 | -54 | -64,8 | -75,6 | -86,4 | -97,2 |
| Factores de descuento 15% | 1 | 0,870 | 0,756 | 0,658 | 0,572 | 0,497 |
| Beneficios en tiempoajustado (Valorreal actual) | 0 | -47 | -49 | -50 | -49 | -48 |
| Beneficios acumulados en tiempo ajustado a lo largo del tiempo de vida | 0 | 53 | 104 | 154 | 205 | 257 |
| | | | | | | |
| Costos + Beneficios acumuladosen tiempo ajustado a lo largo del tiempo de vida | -3276,00 | -3458 | -3652 | -3850 | -4046 | -4236 |
| | | | | | | |
| Período de Amortización en tiempo ajustado | | | ||||
| Recursos Humanos | |||
| Nº | Cargo | Costo Individual | Total |
| 1 | Programador/Analista | $ 100 | $ 100 |
| 1 | Capacitacion Personal | $ 320 | $ 320 |
| | Total | | $ 420 |
| Recursos de Materiales y Varios | |||
| Cantidad | Descripcion | Costo | Total |
| 1 | Equipo de computo y lector de codigo de barras | $ 1.900 | $ 1.900 |
| | Total | | $ 1.900 |
| Recursos Tecnologicos | |||
| Hardware | |||
| Cantidad | Descripcion | Costo/Hora | Total |
| | | | |
| Software | |||
| Cantidad | Descripcion | Costo/Hora | Total |
| 1 | Licencia (Software Comercial) | | $ 800 |
| | Total | | $ 800 |
| FLUJOS DE PAGO | |||
| RECURSOS | COSTOS | ||
| Recursos Humanos | $ 420 | ||
| Recursos Tecnologicos | $ 1.900 | ||
| Recursos Materiales y Varios | $ 800 | ||
| Imprev. 5% (A+B+C) | $ 156 | ||
| TOTAL | $ 3.276 | ||
