Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Paso 2 - Vélez Analisis de Sistemas
Paso 2 - Vélez Analisis de Sistemas
ANÁLISIS DE SISTEMAS
OBJETIVO ESPECÍFICO
Al finalizar la unidad, el alumno identificará los procesos necesarios para realizar el
análisis a detalle de un sistema de información empresarial.
INTRODUCCIÓN
Objetivos del análisis. Hacen referencia a lo que se desea realizar con el sistema;
deben estar acordes con los objetivos organizacionales.
Especificaciones funcionales del sistema. Proceso que parte del análisis de los
requisitos del sistema hasta el modelado del mismo, dando como resultado una
visión general de su estructura interna.
| 38
Unidad 2. Análisis de sistemas
LO QUE SÉ
| 39
Unidad 2. Análisis de sistemas
| 40
Unidad 2. Análisis de sistemas
Todo proyecto, sea de software o no, debe realizar un estudio de viabilidad (también
conocido como factibilidad) a fin de seleccionar la metodología más adecuada que
satisfaga los requisitos del sistema, tanto en su parte técnica, como en su rendimiento.
El objetivo principal es determinar si será económica y técnicamente factible, para ello se
debe analizar el problema y recopilar toda la información pertinente relacionada con el
producto, como los diferentes elementos de datos que se pueden introducir en el sistema,
el procesamiento necesario para llevar a cabo estos datos, los datos de salida necesarios
a ser producidos por el sistema, así como diversas restricciones sobre su
comportamiento.
| 41
Unidad 2. Análisis de sistemas
Factibilidad técnica
Viabilidad económica
El análisis económico es la técnica más utilizada para evaluar la eficacia de sistema a ser
desarrollado. Conocido también como análisis de costo/beneficio, el procedimiento
consiste en determinar los beneficios y ahorros que se esperan de un sistema adesplegar
y compararlos con sus costos. Si los beneficios superan a los costos, se tomauna decisión
de diseñar e implementar el sistema; de lo contrario, tendrá que ser realizada una
justificación adicional o alternativa en el sistema a generar para quepueda ser
aprobada.
14
Basado en el texto Feasibility study-software engineering. Disponible en http://goo.gl/JNFdj7.
Recuperado: 08/10/2013.
| 42
Unidad 2. Análisis de sistemas
Factibilidad operacional
Etapas
Estudio de la situación actual. Ofrece una descripción de la forma como las áreas
involucradas en el sistema se encuentran realizando sus actividades.
| 43
Unidad 2. Análisis de sistemas
Factibilidad técnica
15
Análisis de sistemas de computación. Disponible en http://goo.gl/auhq2F.
Recuperado: 08/07/2013.
16
Dos de los enfoques más populares de TFEA son Desarrollo Conjunto de Aplicaciones (JAD), creado
por IBM; y The METHOD, de Performance Resources, Inc., Falls Church, VA.
Fuente: Apuntes de Ingeniería de Software, Unidad 4. Desarrollados por alumnos del Instituto
Tecnológico de Ciudad Juárez, Chihuahua. Disponible en http://goo.gl/1RfpEB. Recuperado: 08/07/2013.
| 44
Unidad 2. Análisis de sistemas
Estudio económico
El estudio de viabilidad económica evalúa el costo del desarrollo de software contra los
ingresos o beneficios obtenidos una vez finalizado de forma exitosa el proyecto (véase
el punto 2.2). Al evaluar la viabilidad económica de una alternativa de aplicación, la
pregunta básica a responder es ¿el proyecto tiene viabilidad financiera? Esto se hace
mediante la realización de un análisis de costo/beneficio, donde se compara el costo total
real/de la aplicación a sus beneficios financieros completos/real. Las alternativas deben
ser evaluadas en función de su contribución al flujo neto de efectivo, la cantidad en que
los beneficios superan a los costos, ya que el principal objetivo de las inversiones es
mejorar el rendimiento general de la organización.
La siguiente tabla muestra algunos de los costos y beneficios potenciales que pueden ser
adquiridos en un proyecto de software. Aunque la lista no es exhaustiva, proporciona
una indicación de la variedad de factores que se deben tener en cuenta al evaluar la
viabilidad económica de una aplicación. La tabla incluye tanto los factores
| 45
Unidad 2. Análisis de sistemas
cualitativos, costos o beneficios que son de carácter subjetivo, como los factores
cuantitativos, costos o los beneficios monetarios.
Actualizaciones de
hardware/software.
Costo laborales (salarios +
prestaciones). Reducción de costos de
Costos de soporte de la operación.
aplicación. Reducción de costes de
Costos operativos esperados. personal al reducir personal.
Cuantitativo
Gastos de formación para que Aumento de los ingresos por
los usuarios aprendan la las ventas adicionales de sus
aplicación. productos o servicios de las
Gastos de formación para organizaciones.
capacitar a los desarrolladores
en nuevas o actualizadas
tecnologías.
| 46
Unidad 2. Análisis de sistemas
Ejemplo
| 47
Unidad 2. Análisis de sistemas
Mejores prácticas
| 48
Unidad 2. Análisis de sistemas
3. Trabaje con los salarios de desarrolladores al valor real. Hay dos realidades
fundamentales de desarrollo de software que hacen que la estimación del costo
de un proyecto de software sea único: 80% del costo de los salarios es del
desarrollador y los salarios de desarrolladores crece a un ritmo mayor que la
inflación. La implicación es que, aunque un programador junior gane hoy
$60,000, por la misma posición dentro de un año tal vez se tenga que pagar
$66,000, un aumento del 10%, aunque la tasa de inflación sólo sea del 2%. La
implicación es que el valor actual neto (VAN) de un desarrollador en el futuro es
mayor que el de hoy, algo que rara vez sucede en cualquier otra industria.
4. Busque los beneficios primero. Es probable que primero se deba analizar los
beneficios de un proyecto de software, y luego determinar si se puede permitir el
gasto en el área de TI.
La siguiente tabla muestra la evolución de los conceptos de calidad desde 1930 hasta
nuestros días.
| 49
Unidad 2. Análisis de sistemas
| 50
Unidad 2. Análisis de sistemas
17
Tuya, J., Ramos, R. I. y Dolado Cosin J. Técnicas cuantitativas para la gestión en la ingeniería del
software. Netbiblo. S. L. 2007.
18
Security by Design with CMMI for Development, Version 1.3. Disponible en http://goo.gl/hfRKe3.
Recuperado: 14/10/2013.
| 51
Unidad 2. Análisis de sistemas
El primer modelo CMMI (V1.02) fue diseñado para usarse por organizaciones de
desarrollo en su búsqueda de la mejora de procesos para toda la empresa. Fue publicado
en 2000. Actualmente, rige la versión 1.3 publicada en 2010.
INCOSE SECAM
(1996)
Software CMM
V2, draft C (1997)
Integrated Product
EIA 731 SECAM Development CMM
(1998) (1997)
Software Acquisition
CMM V1.03 (2002)
V1.02 (2000)
V1.1 (2002)
19
En Evolution of CMMI. Disponible en http://goo.gl/FjOdtN. Recuperado: 08/10/2013.
| 52
Unidad 2. Análisis de sistemas
| 53
Unidad 2. Análisis de sistemas
| 54
Unidad 2. Análisis de sistemas
La fase de análisis de requisitos del sistema tiene como objetivo proporcionar una
descripción completa de la cuestión sobre la base de los conceptos definidos en el ámbito
del problema. Comienza con el análisis de los requisitos y se detiene cuando el modelo
resultante se considera que está en conformidad con los requisitos señalados, o al llegar
a un acuerdo entre los diseñadores y las partes interesadas.
Trata con las descripciones ejecutables del sistema a desarrollar. La principal motivación
es mostrar que los lenguajes de programación funcionales son útiles en la práctica de
ingeniería de software.
Todo tipo de sistemas, ya sea con o sin un estado, se pueden modelar de manera simple.
Se hace un intento de idear modelos ejecutables susceptibles de pruebas matemáticas.
Además, es una técnica viable para el establecimiento de la corrección dealgoritmos.
| 55
Unidad 2. Análisis de sistemas
Dado que el software siempre es parte de un sistema, debemos iniciar por establecer
los requisitos para todos los elementos y posteriormente generar un subconjunto de estas
salvedades para el software. Esto es esencial cuando el software debe interactuarcon
otros elementos como el hardware, personas o bases de datos. De esta manera, sedeben
generar cuestionamientos que ayuden a comprender el dominio del flujo de información
hacia el software, las funciones a realizar, el comportamiento y rendimiento,la forma de
interfaz, etcétera.
Los requisitos tanto del sistema como del software deben ser documentados y revisados
con el cliente.
| 56
Unidad 2. Análisis de sistemas
Debemos pensar en un modelo lógico como un mapa que se desarrolla para aclarar y
comunicar las intenciones del proyecto de hacer y su posible impacto.
Los componentes de los modelos lógicos varían porque no existe un formato único de
modelo lógico. De acuerdo con la Guía de Desarrollo de la Fundación WK Kellogg20, los
componentes de un modelo lógico son explicados en la siguiente tabla.
20
W. K. Kellogg Foundation. Logic Model Development Guide. Disponible en http://goo.gl/yMPkLs.
Recuperado: 16/10/2013.
| 57
Unidad 2. Análisis de sistemas
A veces, un modelo lógico del programa se confunde con un plan de acción delproyecto.
Si bien existe cierta superposición, la diferencia es sutil pero muy importante. En todo
caso, después de haber definido los objetivos de los proyectos, productos y resultados,
será relativamente fácil desarrollar un modelo de lógico del programa.
| 58
Unidad 2. Análisis de sistemas
Debe ser considerado de izquierda a derecha. Los modelos lógicos muestran los
aspectos básicos del programa en el tiempo, desde la planificación hasta los resultados.
Comprender un modelo lógico significa seguir la cadena de razonamiento o enunciados
“si…, entonces…” que conectan las partes del programa.
| 59
Unidad 2. Análisis de sistemas
La falta de esta información dificulta apreciar de forma razonable y concisa datos tan
importantes como los costos, riesgo, designación de tareas y todas aquellas métricas que
indiquen el estatus actual del proyecto.
21
Pressman, R. Ingeniería del software. Un enfoque práctico, p. 19.
| 60
Unidad 2. Análisis de sistemas
22
Pressman, R. Ingeniería del software. Un enfoque práctico, p. 100.
| 61
Unidad 2. Análisis de sistemas
| 62
Unidad 2. Análisis de sistemas
Según el Instituto Americano de Estándares Nacionales (ANSI, por sus siglas en inglés),
los modelos de datos pueden ser los siguientes:
En el mundo de los negocios, el modelado de datos resulta ser muy importante, sobre
todo en la fase de diseño inicial. Además, durante el proceso, la comunicación yprecisión
son claves para que un modelo de datos sea crucial.
Modelado de datos
| 63
Unidad 2. Análisis de sistemas
Modelado funcional
El enfoque ágil de modelado de datos usa UML, que incluye diversas técnicas, tanto para
los datos, como en los modelos funcionales que pueden ser utilizados de varias maneras.
De hecho, utilizar diferentes metodologías de modelado de datos y técnicas de
modelado de proceso tiene ventajas y desventajas. Cabe aclarar que no hay ningún
método estándar o modelo que nos permite modelar todos los aspectos de un almacén
de datos (Mora y Trujillo, 2004).
El modelo de datos es una sección crucial del análisis de sistemas considerado el núcleo
del almacenamiento de datos. Un modelado de datos es un plan para la construcción de
una base de datos. Para ser eficaz, debe ser lo suficientemente simple para comunicarse
con el usuario final. Además, se recomienda que la estructura de datos sea
completamente detallada con la finalidad de generar la estructura física de la misma.
Como fuere, determinar cuál de los tipos de modelos de datos funcionará debe basarse
en el propósito del modelo y recursos disponibles.
| 64
Unidad 2. Análisis de sistemas
Se debe generar un documento que incluya todos los requisitos necesarios del nuevo
sistema a desarrollar:
Casos de uso. Son textos y diagramas que ilustran cómo están actuando todas las
funciones de la aplicación y sub-características, y cómo se da lacomunicación a
través de varias etapas de uso y flujo de trabajo.
| 65
Unidad 2. Análisis de sistemas
cliente para garantizar que el análisis de las necesidades actuales cubra todos
los requerimientos.
Estimación del tiempo. De acuerdo con los módulos, pasos de desarrollo, el nivel
de los expertos desarrolladores y los niveles lógicos y de ingeniería.
También puede ser una combinación de estas características, como un puerto serie o
un puerto paralelo, que forma un límite físico. Se utiliza para la transmisión de señales
entre los diferentes sistemas y se adhiere a estándares de la industria, tanto para
características físicas y eléctricas.
| 66
Unidad 2. Análisis de sistemas
El desarrollo y mejora de las interfaces puede ser una tarea difícil. Esto es particularmente
cierto en lo que respecta a las interfaces de usuario, ya que para desarrollar interfaces
de usuario verdaderamente de alta calidad, es indispensable tener en cuenta la
complejidad de los temas de ergonomía y variabilidad humana (o sea, las diferencias en
las características físicas y mentales entre los seres humanos).
Una interfaz de usuario es la forma en la que una persona controla una aplicación de
software o un dispositivo de hardware. Una buena interfaz de usuario proporciona una
experiencia “amigable" que permite al usuario interactuar con el software o el hardware
de una manera natural e intuitiva. Casi todos los programas de software tienen una
interfaz gráfica de usuario o GUI. Esto significa que el programa incluye controles gráficos
que el usuario puede seleccionar, como el empleo de un ratón o teclado.
Una GUI típica de un programa de software incluye una barra de menús, barra de
herramientas, ventanas, botones y otros controles. Los sistemas operativos Windows y
Macintosh tienen diferentes interfaces de usuario, pero coinciden en muchos elementos,
como una computadora de escritorio, ventanas, iconos, etcétera. Estos elementos
comunes permiten que las personas puedan usar cualquier sistema operativo sin tener
que volver a aprender por completo la interfaz. Del mismo modo, los programas como
procesadores de texto y navegadores web tienen interfaces bastante similares,
proporcionando una experiencia de usuario adecuada a través de múltiples programas.
| 67
Unidad 2. Análisis de sistemas
| 68
Unidad 2. Análisis de sistemas
Una vez traducidas las especificaciones, se genera un tutorial. Muchos de los subgrupos
de desarrollo hacen tutoriales sobre el diseño, código, etcétera. Con todo,los proyectos
de software pueden fallar debido a la falta de comunicación sobre el significado de lo que
dijo un cliente frente a lo que en realidad es; malentendidos que pueden llevar a
suposiciones erróneas.
| 69
Unidad 2. Análisis de sistemas
RESUMEN DE LA UNIDAD
Una vez que los estudios de viabilidad son realizados y el proyecto aprobado, se
recomienda que los involucrados en su desarrollo sigan modelos de calidad, lo que
significa emplear lo que se denomina "buenas prácticas de la ingeniería de software" para
la creación del sistema. Al establecer el modelo de calidad a seguir, se iniciará conla fase
de recopilación y análisis de requerimientos o requisitos, donde se recaba la información
necesaria para describir la forma como trabajará el sistema y la manera de interactuar
con su entorno. Por lo general, esta fase es una de las más complicadas, ya que en
muchas ocasiones la falta de comunicación entre clientes y desarrolladores llevaa un mal
entendimiento de los requisitos y, por ende, a un mal diseño del sistema.
| 70
Unidad 2. Análisis de sistemas
GLOSARIO DE LA UNIDAD
Análisis de requisitos
Proceso de estudio de las necesidades del usuario para conseguir una definición de los
requisitos del sistema o del software.
Desarrollador
Programador dedicado a una o más facetas del proceso de desarrollo de software;
realiza programas o aplicaciones en uno o varios lenguajes de programación informática.
Asimismo, realiza proyectos referidos a la ingeniería del software. Puede contribuir a la
visión general del proyecto más a nivel de aplicación que a nivel de componentes o en
las tareas de programación individuales.
Escenarios
Descripción de situaciones que se pueden presentar cuando los usuarios interactúan
con los sistemas de información.
Sistema
En sentido general, es un conjunto de cosas que se relacionan entre sí, ordenadamente,
que contribuyen a determinado objeto; elementos interrelacionados y regidos por normas
propias, de tal modo que pueden ser vistos y analizados como una totalidad. El sistema
se organiza para producir determinados efectos, o cumplir una o varias funciones. En el
contexto de la informática, designa un conjunto de hardware y software específicos.
| 71
Unidad 2. Análisis de sistemas
Sistema de información
Conjunto de procedimientos ordenados que, al ser ejecutados, proporcionan información
para apoyar la toma de decisiones y el control de la institución. No implica
necesariamente el uso de computadoras; se puede acceder a la información utilizando
un método mecánico o físico (por ejemplo, buscar un expediente en un archivador).
Sistema informático
Resulta de la interacción entre los componentes físicos, hardware, y lógicos, software.
A éstos hay que agregarles el recurso humano, parte fundamental de un sistema
informático. Una simple computadora es un sistema informático, dado que al menos
dos componentes deben trabajar en conjunto.
| 72
Unidad 2. Análisis de sistemas
ACTIVIDADES DE APRENDIZAJE
ACTIVIDAD 1
ACTIVIDAD 2
Investiga en tres fuentes distintas sobre los elementos que debe contener un
estudio de viabilidad de un sistema de información. Elabora una síntesis de tu
investigación en no más de dos páginas. Menciona tus fuentes de consulta.
ACTIVIDAD 3
| 73
Unidad 2. Análisis de sistemas
ACTIVIDAD 4
| 74
Unidad 2. Análisis de sistemas
CUESTIONARIO DE REFORZAMIENTO
| 75
Unidad 2. Análisis de sistemas
LO QUE APRENDÍ
Retoma el cuadro sinóptico que desarrollaste en la actividad “Lo que sé”, y escribe
una comparación sobre los conceptos que plasmaste en él y los conceptos
contenidos en la presente unidad. Escribe tus conclusiones al respecto.
| 76
Unidad 2. Análisis de sistemas
EXAMEN DE AUTOEVALUACIÓN
| 77
Unidad 2. Análisis de sistemas
MESOGRAFÍA
BIBLIOGRAFÍA RECOMENDADA
Pressman, Roger S. Ingeniería del software. Un enfoque práctico, 5.ª ed. España:
McGraw-Hill, 2002, 601 pp.
| 78
Unidad 2. Análisis de sistemas
| 79
Unidad 2. Análisis de sistemas
SITIOS ELECTRÓNICOS
| 80