Paso 2 - Vélez Analisis de Sistemas

UNIDAD 2.
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
Cualquier modelo de desarrollo de sistemas debe incluir una etapa de análisis, en la

cual los desarrolladores o ingenieros de software recopilarán la información necesaria
para poder comenzar con su construcción, y realizarán un bosquejo inicial de la forma
como estará estructurado. En esta línea, la unidad se concentra en los conceptos
principales que integran la fase de análisis del sistema de acuerdo con los siguientes
puntos:
 Objetivos del análisis. Hacen referencia a lo que se desea realizar con el sistema;
deben estar acordes con los objetivos organizacionales.
 Estudio de viabilidad. Determina si el sistema en cuestión es posible de realizar.
 Estudio económico técnico. Determina si se cuenta con los recursos financieros y

tecnológicos adecuados para desarrollar el sistema.
Unidad 2. Análisis de sistemas
 Conceptos de calidad. Hacen referencia a aquellos criterios que deben ser

considerados para obtener un sistema de información adecuado que cumpla con
todas sus especificaciones.
 Análisis de requisitos del sistema. En este proceso se establecen las

características funcionales y no funcionales que debe tener el sistema.
 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.
 Interfaces del sistema. Proceso donde se representan los módulos a través de

los cuales los usuarios podrán interactuar con el sistema.
| 38
LO QUE SÉ
Elabora un cuadro sinóptico de los procesos que, de acuerdo con tu

conocimiento, integran la fase de análisis de un sistema de información.
| 39
TEMARIO DETALLADO (12 horas)
2.1. Objetivos del análisis

2.2. Estudio de viabilidad
2.3. Estudio económico y técnico
2.4. Conceptos de calidad (CMM) en el análisis de sistemas
2.5. Análisis de requisitos del sistema
2.6. Especificación funcional del sistema
2.6.1. Identificación y definición de requisitos
2.6.2. Diseño del modelo lógico actual
2.6.3. Estudio de alternativas de construcción
2.7.1. Construcción del modelo de procesos del nuevo sistema
2.7.2. Construcción del modelo de datos del nuevo sistema
2.7.3. Elaboración de análisis detallado del nuevo sistema
2.8. Interfaz del sistema
2.8.1. Definición de interfaces con el usuario
2.8.2. Complementar las especificaciones del sistema
2.8.3. Complementar las especificaciones de entrega
| 40
2.1. Objetivos del análisis
El objetivo del análisis de sistemas es identificar con precisión las necesidades de

información de una organización y establecer la alternativa de solución másconveniente
para satisfacerla. Para ello se recomiendan los siguientes pasos:
1. Obtener los requisitos del cliente para el sistema.

2. Identificar escenarios o casos de uso.
3. Seleccionar clases y objetos usando los requisitos básicos de programación.
4. Identificar los atributos y operaciones para cada objeto del sistema.
5. Definir estructuras y jerarquías
2.2. Estudio de viabilidad
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
Factibilidad técnica
Se refiere a la especificación de equipos y software que van a satisfacer de forma exitosa

los requerimientos del usuario. Aunque las necesidades técnicas del sistema dependerán
de cada proyecto, en términos generales incluyen lo siguiente14:
 Facilidad para producir resultados en un tiempo determinado.

 Tiempo de respuesta en condiciones específicas.
 Capacidad para procesar un volumen de transacciones a una velocidad
determinada.
 Facilidad para comunicar datos a lugares distantes.
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
Factibilidad operacional
Esto se relaciona principalmente con los aspectos de la organización donde será

implantado el sistema y su interacción con los usuarios. En este caso, los puntos a
considerar son los siguientes:
 ¿Qué cambios serán traídos con el sistema?

 ¿Qué partes de la organización serán afectadas?
 ¿Qué nuevas habilidades serán requeridas?
 ¿Los miembros del personal cuentan con estas habilidades?
Este estudio de viabilidad se lleva a cabo por un pequeño grupo de personas

familiarizadas con la parte técnica del sistema.
Etapas
 Establecimiento del alcance del sistema. Se establecen las características

deseables del sistema a construir, así como las áreas involucradas en su
desarrollo.
 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.
 Definición de requisitos del sistema. Se describe a detalle el funcionamiento que

debe tener el sistema, así como la manera como interactuará con los diversos
usuarios del mismo y su entorno.
 Estudio de alternativas de solución. Se plantean diversas propuestas que pueden

responder a las necesidades a las cuales dará solución el sistema.
| 43
 Valoración de las alternativas. Establecidas las propuestas de solución, se debe

evaluar a detalle cada una de ellas para determinar cuál será la que se adapte
mejor a las necesidades planteadas.
 Selección de la solución. Evaluadas las alternativas, se elegirá una o varias que

darán vida al sistema de información.
2.3. Estudio económico y técnico
Factibilidad técnica
El estudio de viabilidad técnica compara el nivel de la tecnología disponible en la empresa

de desarrollo de software con el nivel de la tecnología necesaria para el desarrollo del
producto (en este caso, el nivel de la tecnología consiste en el lenguaje de
programación, recursos de hardware, software, otras herramientas, etcétera). Los
resultados obtenidos son la base para determinar sobre si continuar o abandonar el
proyecto, si hay riesgos de que no funcione, no tenga el rendimiento deseado, o si las
piezas no encajan perfectamente unas con otras.15
Se recomiendan técnicas para facilitar las especificaciones de la aplicación (TFEA16),

las cuales, con variaciones según cada proyecto, tienen las siguientes directrices:
 La reunión se celebra en un lugar neutral y acuden tanto clientes como

desarrolladores.
15
Análisis de sistemas de computación. Disponible en http://goo.gl/auhq2F.
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
 Se establecen normas de preparación y participación.

 Se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos
importantes; pero a la vez lo suficientemente informal como para animarel libre
flujo de ideas.
 Un coordinador (que puede ser un cliente, un desarrollador o un tercero) que
controle la reunión.
 Se usa un mecanismo de definición (hojas de trabajo, gráficos, carteles o pizarras).
 El objetivo es identificar el problema, proponer elementos de solución, negociar
diferentes enfoques y especificar un conjunto preliminar de requisitos de la
solución en una atmósfera que permita alcanzar el objetivo.
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
cualitativos, costos o beneficios que son de carácter subjetivo, como los factores
cuantitativos, costos o los beneficios monetarios.
Costos y beneficios potenciales de un proyecto de software
Tipo Costos potenciales Beneficios potenciales
 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.
 Decisiones mejoradas como

resultado del acceso a
 Aumento de insatisfacción de información precisa y
los empleados por el miedo al oportuna.
cambio.  Aumento o generación deuna
Cualitativo
 Percepción pública negativade nueva barrera dentro de la
despidos como el resultado de industria para mantener la
la automatización. competencia de su mercado.
 Percepción pública positiva
acerca de que la
| 46
organización es una empresa

innovadora.
Análisis cuantitativo de costo/beneficio
Para realizar un análisis de costo/beneficio cuantitativo es necesario identificar loscostos

iníciales del desarrollo, los costos esperados de la operación y el soporte a la aplicación,
así como los beneficios monetarios futuros esperados por la utilización de la aplicación.
Debido a que los costos y beneficios se acumulan en diferentes momentos, algunos de
inmediato y otros en el futuro, es necesario convertir los costos a los valoresactuales para
que se puedan comparar de forma adecuada.
Ejemplo
Concepto Año 1 Año 2 Año 3 Año 4 Año 5

Costos $ 18,055,858.00 $ 21,947,589.00 $ 26,435,582.00 $ 31,987,055.00 $ 38,704,338.00
Factor 0.83 0.68 0.56 0.47 0.39
Valor presente $ 14,986,362.14 $ 14,924,360.52 $ 14,803,925.92 $ 15,033,915.85 $ 15,094,691.82
Beneficios $ 5,250,899.00 $ 6,353,589.00 $ 7,687,842.00 $ 9,302,289.00 $ 11,255,770.00
Factor 0.83 0.68 0.56 0.47 0.39
Valor presente $ 4,358,246.17 $ 6,391,394.65 $ 9,774,045.13 $ 14,704,258.30 $ 21,570,278.00
Análisis de cualitativo de costo/beneficio
Hay dos líneas de pensamiento sobre el análisis costo/beneficio cualitativo. La primera

estrategia es mantener las cosas simples y aplicar el sentido común: si el proyecto parece
una buena idea, lo más probable es que lo sea. La segunda línea de pensamiento es que
se pueden cuantificar los aspectos cualitativos de un proyecto y, por tanto, realizar una
comparación justa.
| 47
Pasos para cuantificar los factores cualitativos.
1. Identificar los factores cualitativos. Lluvia de ideas con varias personas.

2. Cuantificar la importancia de cada factor a su organización. Por ejemplo, dar a
cada factor una calificación de uno a cinco, donde cinco es la más importante.
3. Tasar numéricamente cada alternativa respecto a cada factor cualitativo. Por
ejemplo, la tasa de cada alternativa en una escala de cero a diez, donde diez es
la calificación más alta posible.
4. Multiplicar la ponderación importancia de la clasificación de cada alternativa.
5. Calcular la puntuación global para cada alternativa sumando las puntuaciones
individuales.
Mejores prácticas
Al determinar la viabilidad económica de una alternativa, hay varias acciones

importantes a realizar:
1. Asignar todos los costos. Si su proyecto requiere actualizaciones de hardware /

software que otras aplicaciones también demandan, entonces no se deberáasumir
el costo total de la actualización. En este caso, es necesario negociar sóloparte de
la actualización con la alta dirección.
2. Asignar los beneficios de manera justa. Muchos beneficios se pueden lograr a

través de la mejora de procesos de negocio sin la necesidad de automatización
adicional. Los únicos beneficios que puede reclamarse son los que corresponden
al resultado directo de la automatización.
| 48
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.
2.4. Conceptos de calidad (CMM) en el análisis de sistemas
La siguiente tabla muestra la evolución de los conceptos de calidad desde 1930 hasta
nuestros días.
Año Nombre Modelo / Descripción

Método
1930 Walter Control Es considerado como el padre del
Shewhart estadístico de control estadístico de calidad. Fue
la calidad. el primero que realizó
Propuso el investigaciones sistemáticas en
conocido ciclo materia de calidad y desarrolló
de calidad métodos estadísticos, gráficos de
PDCA (plan- control de calidad, aplicables al
do-check-act) sector industrial. Sus
| 49
investigaciones ayudaron a las

empresas a disminuir el
porcentaje de defectos y cumplir
las especificaciones de los
diseños.
1980 Phil Crosby Cero defectos. Remarcó la importancia de la
“Parrilla de la implicación y de la motivación de
madurez de la cada uno de los empleados en la
gestión de la empresa. Destacó los factores
calidad”. que representan los costos de la
(Crosby 1980, calidad y de las no conformidades
1990). y propuso una tabla que
especifica cinco niveles de
madurez. Tiene cierto paralelismo
con los cinco niveles de madurez
del modelo CMM.
1982 Edwards Aplicó y Deming fue el impulsor de uno de
Deming extendió el uso los principios básicos de calidad,
del ciclo PDCA el famoso ciclo PDCA, también
(Deming. conocido como rueda de Deming.
1982). Propuso 14 puntos esenciales en
la gestión de una empresa para
conseguir la transformación y
mejora continua en la
organización.
1988 Joseph Juran La trilogía de Desarrolló y aplicó con éxito los
Juran. (Juran principios de Shewhart. Propuso
1990,1999). una aproximación sistemática
para controlar y mejorar la
| 50
calidad. Desplegó su famosa

trilogía: la planificación de la
calidad, el control de la calidad y
la mejora de la calidad, que
representan los instrumentos del
directivo para administrar la
gestión de calidad.
71989 Watts Creación de A partir de la parrilla de madurez
Humphrey Modelo CMM. de Crosby, aplicó los conceptos
(Humphrey, de calidad a los procesos de
1989a). desarrollo de software y propició
la creación del modelo CMM.
Tabla 2.4.1. Movimientos globales de calidad habidos a lo largo de la historia.17
El modelo de madurez y de capacidad (CMM, capability maturity model) comprende los

elementos básicos para la administración de procesos eficaces, y tiene su fundamento
en los principios creados por Crosby, Deming, Juran y Humphrey.
Desarrollo del CMMI18
CMM Integration surge como un proyecto con la finalidad de solucionar el problema de

usar múltiples modelos CMMs para ser implementados por las organizaciones que
pretendan mejorar los procesos dentro de su institución.
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.
| 51
El desarrollo de un conjunto de modelos integrados implicó más que una simple

combinación de los materiales de los modelos existentes. Al usar procesos que fomentan
el consenso, el equipo del producto CMMI creó un marco que da cabida a múltiples
constelaciones. El primer modelo a desarrollar fue el CMMI para Desarrollo (entonces
denominado simplemente CMMI). Inicialmente, CMMI era un modelo que combinaba tres
modelos fuente: Capability Maturity Model for Software (SW-CMM) v2.0 draft C, Systems
Engineering Capability Model (SECM) (EIA 2002ª) e Integrated Product Development
Capability Maturity Model (IPD-CMM) v0.98. Los tres modelos fueron seleccionados
debido al éxito en su adopción o por su prometedor enfoque para mejorar los procesos
en una organización.
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.
CMM for Software Systems Engineering

V1.1 (1993) CMM V1.1 (1995)
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)
CMMI for Development

V1.2 (2006)
CMM for Acquisition CMMI for Services
V1.2 (2007) V1.2 (2009)
CMMI for Acquisition CMMI for Development CMMI for Services

V1.3 (2010) V1.3 (2010) V1.3 (2010)
Figura 2.4.1. Historia de los CMMs.19
19
En Evolution of CMMI. Disponible en http://goo.gl/FjOdtN. Recuperado: 08/10/2013.
| 52
CMMI para desarrollo
CMMI para desarrollo es un modelo de referencia usado tanto en productos como en

servicios. Contiene prácticas que cubren la gestión de proyectos, la gestión de procesos,
la ingeniería de sistemas, la ingeniería de hardware, la ingeniería de software y otros
procesos de soporte utilizados en el desarrollo y mantenimiento.
| 53
Basado en CMMI-DEV 1.2. Disponible en: http://chrguibert.free.fr/cmmi12/cmmi-dev/text/7938cba-6019.php . Recuperado:

13/08/2014.
| 54
2.5. Análisis de requisitos del sistema
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.
Los requisitos funcionales y los requisitos no funcionales se identifican utilizando técnicas

clásicas, como los casos de uso. Cada requisito se asocia entonces a una organización.
Una organización se define por un conjunto de roles abstractos, sus interacciones y un
contexto común, determinados de acuerdo con una ontología. En el proceso, primero se
describe el contexto de la aplicación, a continuación se identifican las estructuras y
finalmente se descomponen para interactuar arreglos más simples.
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
Como todo proceso deben imponerse limitantes y restricciones, particularmente en lo

relacionado con la forma y tipo de lenguaje informáticos a usar. Esto trae como
consecuencia, un lenguaje de especificación ejecutable.
2.6.1. Identificación y definición de requisitos
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.
2.6.2. Diseño del modelo lógico actual
Un modelo lógico es una herramienta de planificación para aclarar y representar

gráficamente lo que el proyecto pretende hacer y lo que espera lograr, así como su
impacto. Se distingue por lo siguiente:
 Resume los elementos clave del programa.

 Explica la razón de ser de las actividades del programa.
 Aclara los resultados esperados.
 Proporciona una herramienta de comunicación.
| 56
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.
| 57
RECURSOS/ ACTIVIDADES PRODUCTOS RESULTADOS IMPACTO/ META

INSUMOS
Los recursos Lo que hace el Los productos Beneficios para Resultados
dedicados o programa con generados los participantes deseados del
consumidos por las entradas directamente durante y programa a largo
el programa. para cumplir su de las después de las plazo.
misión. actividades del actividades del
programa. programa.
Incluyen el Pueden incluir Son las Son las

capital humano, Involucra los tipos, niveles y consecuencias transformaciones
recursos procesos, metas de directas del intencionadas o
financieros, así herramientas, servicios que comportamiento, involuntarias
como todo lo eventos, serán conocimiento, fundamentales que
necesario para tecnología y prestados por aptitudes, ocurren en las
que pueda acciones que el programa. condición y nivel organizaciones,
realizarse de permiten de comunidades o
forma exitosa el originar los funcionamiento sistemas como
trabajo. cambios o de los resultado de las
resultados participantes del actividades del
intencionados programa. programa dentro
del programa. de 7-10 años.
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
Cómo interpretar un modelo lógico
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.
2.6.3. Estudio de alternativas de construcción
Figura 2.6.3. Paradigma de construcción de prototipos.
Al momento de planear las necesidades de un desarrollo de software, deben

considerarse caminos alternos a su construcción. Esto implica en muchas ocasiones
resolver el mismo problema, aunque desde perspectivas diferentes, sin dejar de lado el
objetivo real por el cual fue concebida la idea. Este procedimiento debe ser documentado
y señalado como “estudio de alternativas”, y requiere la gestación de nuevos modelos de
proceso según la naturaleza del proyecto, incluyendo métodos y herramientas a utilizarse,
así como controles y entregas requeridos.
| 59
Figura 2.6.4. (a) Fases de un bucle de resolución de problemas.

(b) Fases dentro de las fases del bucle de resolución de problemas.21
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
Figura 2.7. Evaluación del impacto.22
Es insuficiente contar con una implementación bien programada y estéticamente

atractiva. El desarrollo debe ser funcional y cubrir todas las especificaciones establecidas.
En esta línea, como ilustra la figura 2.7, el impacto de nuestro desarrollo de software
comenzará desde una perspectiva global (lo que ve el usuario), hasta llegara una vista
detallada de cada etapa o proceso.
22
Pressman, R. Ingeniería del software. Un enfoque práctico, p. 100.
| 61
2.7.1. Construcción del modelo de procesos del nuevo sistema
Los productos de software representan el resultado de un proceso de información

intensiva, se construyen gradualmente y son revisados de manera intensa a través de un
esfuerzo de desarrollo de software. Tales esfuerzos pueden ser organizados usando
modelos del ciclo de vida del producto de software. Estos modelos de desarrollo de
productos representan una evolución de los modelos de ciclo de vida del software
tradicional (MacCormack, 2001).
Las revisiones se presentaron debido a la disponibilidad de nuevas tecnologías de

desarrollo de software, como lenguajes de programación y entornos de creación de
prototipos, software reutilizable, generadores de aplicaciones y entornos de apoyo de
documentación. Cada una de estas tecnologías tiene como objeto permitir la creación
de implementaciones de software ejecutables, ya sea de forma temprana dentro del
esfuerzo de desarrollo de software o con mayor rapidez. En este sentido, los modelos
de desarrollo de software pueden estar implícitos en el uso de la tecnología, ya que tales
modelos se vuelven cada vez más intuitivos para los desarrolladores; y si a esto
agregamos la experiencia con estas tecnologías, se justifica su empleo. Luego, la
aplicación de un examen detallado de estos modelos es lo más apropiado cuando estas
tecnologías están disponibles para el uso o la experimentación.
2.7.2. Construcción del modelo de datos del nuevo sistema
El modelado de datos es una forma de estructurar y organizar datos, y se aplica

ampliamente en diversas industrias, no sólo en la generación de software, en razón de
que cada vez se depende más de la gestión de bancos de datos.
| 62
Según el Instituto Americano de Estándares Nacionales (ANSI, por sus siglas en inglés),
los modelos de datos pueden ser los siguientes:
 Conceptual. La idea a realizar (lo que pretendemos que sea).

 Lógico. Lo más razonable y viable de realizar.
 Físico. Lo que realmente será implementado o puesto en práctica.
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.
El proceso de análisis de software consiste en dos actividades principales: modelado de

datos y modelado funcional, descritos a continuación.
Modelado de datos
El modelo de datos se crea como representación de las necesidades de información para

generar un nuevo software. Funciona como herramienta de comunicación eficaz para
conversaciones con los usuarios, y también sirve como un modelo para el sistema de
base de datos. Así, actúa como un puente de información entre de los datos reales y el
banco de datos donde serán almacenados los datos relevantes. Con esa información, se
generan esquemas con los diferentes niveles de detalle a partir de los requisitos de más
alto nivel.
| 63
Modelado funcional
El modelado funcional es el más utilizado a través de diagramas de flujo de datos (DFD)

y metodologías orientadas a objetos (OO) que enfatizan el modelado de datos a través
de diagramas de clases.
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
2.7.3. Elaboración de análisis detallado del nuevo sistema
Se debe generar un documento que incluya todos los requisitos necesarios del nuevo
sistema a desarrollar:
 Aspectos técnicos (vista del desarrollador). Lista de los problemas técnicos

relevantes para el proyecto actual.
 Funciones básicas de la aplicación (vista del usuario). Se describen las

características básicas principales para el proyecto actual de forma que sea
entendible por el usuario final.
 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.
 Especificación de interfaz de usuario. Este documento es útil mientras se

construye la aplicación. A través de esta especificación, el cliente tiene un primer
contacto con el sistema y facilita la comprobación de lo que obtendrá al aplicarse
todas las características requeridas.
 Requisitos de usuario. Descripción detallada de las características básicas que

se han identificado.
 Arquitectura. Modelo de seguridad, configuración de aspectos, transferencia de

datos entre aplicaciones, identificación de los módulos y sus límites.
 Campos de datos. Se establecen los campos a usar y el esquema de la base de

datos, así como sus relaciones. Los datos son identificados y validados con el
| 65
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.
2.8. Interfaz del sistema
La interfaz es un límite compartido o conexión entre dos objetos diferentes, dispositivos

o sistemas a través del cual se transmite la información. La conexión puede ser física o
lógica. El término se utiliza en muchos campos. En la electrónica y equipo de ingeniería,
una interfaz puede ser el límite físico entre dos subsistemas o dispositivos; una parte o
circuito en algunos subsistema que envía o recibe señales hacia o desde otros sistemas
o subsistemas (por ejemplo, una interfaz de video o una tarjeta de interfaz de red); o un
estándar que especifica un conjunto de características funcionales, las características
comunes de interconexión físicas y características de la señal para el intercambio de
señales o datos (por ejemplo, SCSI o USB).
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.
Una interfaz de programación de aplicaciones (API) es un conjunto de especificaciones

que definen cómo una pieza de software interactúa con otras, en particular un programa
de aplicación en un sistema operativo. El objetivo principal es proporcionar un conjunto
de funciones de uso común, como dibujar ventanas o iconos en la pantalla, lo que ahorra
a los programadores la tediosa tarea de escribir código para todo desde cero.
| 66
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).
2.8.1. Definición de interfaces con el usuario
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
2.8.2. Complementar las especificaciones del sistema
Una de las mejores maneras de asegurar la calidad de cualquier producto o servicio es

conseguir los requisitos para hacerlo bien. Los desarrollos de software no son la
excepción, las especificaciones pueden ser utilizadas para desarrollar una solución
adecuada al problema, pero debemos ir más allá. Aparte de aplicar todo el proceso de
obtención, análisis, comunicación y completar los requisitos para generar la base esencial
en un desarrollo de software, es necesario tomar en cuenta cómo va a evolucionar a
través del tiempo. Esto significa que tal vez los requisitos deben ser reutilizados en
diferentes proyectos y a través de familias de productos para reducir el costo y esfuerzo
de generar nuevo software.
2.8.3. Complementar las especificaciones de entrega
El propósito de un análisis de las necesidades y especificaciones es separar las

necesidades de los deseos, y con ello evitar que el cliente pueda querer más de lo que
está disponible. A menudo, la especificación está escrita en el idioma del cliente, quien
firmará el documento. Aquí puede comenzar el problema: ¿cuántas personas de la
organización hablan el idioma del cliente? Por lo general, pocos. Luego, debe haber un
proceso que ayude a identificar las funciones de cada participante en el proyecto. Esto
se hace durante el análisis de necesidades, ya que los requisitos pueden cambiar como
resultado de los avances en el desarrollo del software.
Para cumplir y complementar las especificaciones de entrega, lo más recomendable es

incluir a todos los miembros que participan dentro del proyecto de gestión de software:
gestores de proyectos, analistas de negocio, programadores, evaluadores, gerentes de
control de calidad, clientes, etcétera.
| 68
Este encuentro se traducirá en un pliego de condiciones, por lo que no habrá de

generarse diseños o códigos hasta que estén concluidos el análisis de las necesidades
y sus soluciones. Dado que la especificación está escrita en el idioma del cliente, hay
necesidad de convertir el lenguaje del cliente en el idioma del grupo de desarrollo y el
grupo de prueba. Por ejemplo, los programadores deben saber cómo hacer que la
aplicación se ejecute en el sistema; o los probadores, entenderán cómo van a comprobar
que la solicitud cumple con las necesidades del usuario (a los probadores no les importa
el idioma en el que fue escrito el programa, sólo si cumple con las necesidades del
usuario; deben conocer las expectativas de los usuarios y cómo los usuarios utilizan la
aplicación). El objetivo general es, en todo caso, ofrecer un producto que satisfaga al
cliente.
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
RESUMEN DE LA UNIDAD
Uno de las fases más importantes en la creación de sistemas de información es el

análisis, en el cual será posible determinar si se cuenta con los recursos necesarios
para realizar el sistema. El análisis debe partir del establecimiento de objetivos precisos
acordes con los objetivos de la organización, luego, pasaremos a realizar los estudios
de viabilidad que abarcan los aspectos técnico-financieros en donde se determina si se
cuenta con los recursos materiales, financieros y humanos necesarios para la realización
del proyecto.
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.
Los requisitos recabados ayudarán a los ingenieros de software a detallar el modo

funcional del sistema, identificar riesgos en su construcción, establecer alternativas para
su elaboración y, finalmente, desarrollar interfaces visuales que ayuden a evaluar si lo
que se desea construir va bien encaminado. La fase de análisis es crítica en el desarrollo
de sistemas de información; si se realiza erróneamente, el sistema que resulte no cubrirá
las expectativas y, en consecuencia, llegará a ser muy costoso parala organización.
| 70
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.
Ingeniería del software

Aplicación de procesos sistemáticos y disciplinados para el desarrollo, operación y
mantenimiento de software.
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
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
ACTIVIDADES DE APRENDIZAJE
ACTIVIDAD 1
Elabora un mapa mental sobre los procesos a seguir en la fase de análisis de

sistemas.
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
Discute con tus compañeros sobre la calidad en los sistemas de información,

con base en las siguientes preguntas:
1. ¿Por qué es necesario un modelo de calidad de sistemas?

2. ¿Cuál es la importancia de seguir un modelo de calidad en el desarrollo de
sistemas?
| 73
ACTIVIDAD 4
Realiza una investigación sobre el modelado de procesos y datos en el desarrollo

de sistemas de información. Con base en lo anterior, desarrolla tres ejemplos de
modelado de procesos y de datos empleados en la ingeniería de sistemas.
Menciona tus fuentes de consulta.
| 74
CUESTIONARIO DE REFORZAMIENTO
Responde las siguientes preguntas:
1. ¿Cómo deben ser planteados los objetivos de un sistema de información en la etapa

de análisis?
2. ¿Qué es un estudio de viabilidad?
3. ¿Cuáles son los objetivos de un estudio técnico-financiero?
4. ¿Por qué es importante la realización del estudio técnico?
5. Menciona dos ejemplos de modelos de CMM.
6. Explica brevemente por qué es importante la definición de requisitos en la etapa de
análisis de sistemas.
7. ¿Qué es un modelo lógico del sistema de información y para qué es útil?
8. ¿Por qué es necesario establecer diversas alternativas de construcción de un
sistema en la etapa de análisis?
9. Menciona cinco ejemplos de riesgos que pueden presentarse en el desarrollo de
sistemas.
10. ¿Qué es el modelado de procesos y datos y cuál es su utilidad?
| 75
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
EXAMEN DE AUTOEVALUACIÓN
Responde verdadero (V) o falso (F).
1. El objetivo del estudio de viabilidad del sistema es el análisis de un conjunto

concreto de necesidades para proponer una solución a largo plazo, que tenga en
cuenta restricciones económicas, técnicas, legales y operativas. ( )
2. El análisis económico incluye el análisis costo-beneficio. ( )
3. Phil Crosby destacó “la importancia de la implicación y de la motivación de cada
uno de los empleados en la empresa”. ( )
4. El modelo CMMI para adquisición fue publicado en 2005. ( )
5. La versión 1.3 de CMMI para adquisición fue publicado en 2010. ( )
6. CMMI para desarrollo es un modelo de referencia que cubre las actividades para
desarrollar solamente productos. ( )
7. El análisis de los requisitos es una tarea de ingeniería del software que cubre el
hueco entre la definición del software a nivel sistema y las pruebas del software.
( )
8. Un modelo lógico es una forma sistemática y visual de presentar y compartir su
comprensión de las relaciones entre los recursos que dispone para operar su
programa, las actividades que planea realizar y los cambios o resultados que
espera obtener. ( )
9. El propósito de un modelo lógico es suministrar a los participantes un mapa guiado
que describa la secuencia de eventos relacionados que conectan lanecesidad de
un programa planificado con los resultados deseados. ( )
10. Joseph Juran fue el impulsor de uno de los principios básicos de calidad, el ciclo
PDCA. ( )
| 77
MESOGRAFÍA
BIBLIOGRAFÍA RECOMENDADA
Autor Capítulo Páginas

Peña Ayala 3 15-43
Roger S. Pressman. 10 165-180
Ingeniería del software. Un
enfoque práctico
BIBLIOGRAFÍA BÁSICA (REFERENCIAS)

Peña Ayala, Alejandro. Ingeniería de software: una guía para crear sistemas de
información. Instituto Politécnico Nacional.
Pressman, Roger S. Ingeniería del software. Un enfoque práctico, 5.ª ed. España:
McGraw-Hill, 2002, 601 pp.
BIBLIOGRAFÍA COMPLEMENTARIA (TEMARIO ANALÍTICO)

1. Bardou, Louis. Mantenimiento y soporte logístico de los sistemas informáticos.
México: Alfa Omega-Marcombo, 2004, 292 pp.
2. Bochinno, William A. Sistemas de información para la administración, técnicas e
instrumentos. México: Trillas, 2002.
3. Bonsón, Enrique. Tecnologías inteligentes para la gestión empresarial. México:
Alfa Omega-Rama, 2002, 258 pp.
4. Cornella, Alfons. Información digital para la empresa, una introducción a los
servicios de información electrónica. México: Alfa Omega-Marcombo,
2004, 196 pp.
| 78
5. Lardent, Alberto R. Sistemas de información para la gestión empresarial,

procedimientos, seguridad y auditoría. Buenos Aires: Pearson Education-
Prentice Hall, 2001.
6. Levine, Guillermo. Computación y programación moderna. México: Addison
Wesley, 2000.
7. Long, Nancy y Larry Long. Introducción a las computadoras y a los sistemas de
información, edición Internet. México: Prentice Hall, 1999, 416 pp.
8. McLeod, Raymond, Jr. Sistemas de información gerencial, 7.ª ed. México: Prentice
Hall, 1999, 688 pp.
9. Oz, Effy. Administración de sistemas de información, 2.ª ed. México: Thomson-
Learning, 2001, 578 pp.
10. Peña R., Baeza-Yates, R. y Rodríguez, J. Gestión digital de la información. de
bits a bibliotecas digitales y la web. México: Alfa Omega-Rama, 2004,
464 pp.
11. Piattini, Mario; J. Antonio Calvo-Manzano, Joaquín Cervera y Luis Fernández.
Análisis y diseño detallado de aplicaciones informáticas de gestión.
México: Alfa Omega-Rama, 2004, 728 pp.
12. Stair, Ralph M. Principios de sistemas de información, 4.ª ed. México: Thomson
Learning, 2002, 692 pp.
13. Walker, D. W. Sistemas e información para la administración. México: Alfa Omega-
Marcombo, 2001, 360 pp.
| 79
SITIOS ELECTRÓNICOS
Dirección electrónica Descripción

http://www.sei.cmu.edu/ Sitio oficial del Instituto de Ingeniería
de Software de la Universidad
Carnegie Mellon.
http://goo.gl/93ZAm4
Análisis de sistemas de información,
de Luis Antonio Domínguez, de Red
Tercer Milenio.
| 80

Paso 2 - Vélez Analisis de Sistemas

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Paso 2 - Vélez Analisis de Sistemas

Cargado por

Copyright:

Formatos disponibles

UNIDAD 2.

Cualquier modelo de desarrollo de sistemas debe incluir una etapa de análisis, en la

 Estudio de viabilidad. Determina si el sistema en cuestión es posible de realizar.

 Estudio económico técnico. Determina si se cuenta con los recursos financieros y

 Conceptos de calidad. Hacen referencia a aquellos criterios que deben ser

 Análisis de requisitos del sistema. En este proceso se establecen las

 Interfaces del sistema. Proceso donde se representan los módulos a través de

Elabora un cuadro sinóptico de los procesos que, de acuerdo con tu

TEMARIO DETALLADO (12 horas)

2.1. Objetivos del análisis

2.1. Objetivos del análisis

El objetivo del análisis de sistemas es identificar con precisión las necesidades de

1. Obtener los requisitos del cliente para el sistema.

2.2. Estudio de viabilidad

Se refiere a la especificación de equipos y software que van a satisfacer de forma exitosa

 Facilidad para producir resultados en un tiempo determinado.

Esto se relaciona principalmente con los aspectos de la organización donde será

 ¿Qué cambios serán traídos con el sistema?

Este estudio de viabilidad se lleva a cabo por un pequeño grupo de personas

 Establecimiento del alcance del sistema. Se establecen las características

 Definición de requisitos del sistema. Se describe a detalle el funcionamiento que

 Estudio de alternativas de solución. Se plantean diversas propuestas que pueden

 Valoración de las alternativas. Establecidas las propuestas de solución, se debe

 Selección de la solución. Evaluadas las alternativas, se elegirá una o varias que

2.3. Estudio económico y técnico

El estudio de viabilidad técnica compara el nivel de la tecnología disponible en la empresa

Se recomiendan técnicas para facilitar las especificaciones de la aplicación (TFEA16),

 La reunión se celebra en un lugar neutral y acuden tanto clientes como

 Se establecen normas de preparación y participación.

Costos y beneficios potenciales de un proyecto de software

Tipo Costos potenciales Beneficios potenciales

 Decisiones mejoradas como

organización es una empresa

Análisis cuantitativo de costo/beneficio

Para realizar un análisis de costo/beneficio cuantitativo es necesario identificar loscostos

Concepto Año 1 Año 2 Año 3 Año 4 Año 5

Análisis de cualitativo de costo/beneficio

Hay dos líneas de pensamiento sobre el análisis costo/beneficio cualitativo. La primera

Pasos para cuantificar los factores cualitativos.

1. Identificar los factores cualitativos. Lluvia de ideas con varias personas.

Al determinar la viabilidad económica de una alternativa, hay varias acciones

1. Asignar todos los costos. Si su proyecto requiere actualizaciones de hardware /

2. Asignar los beneficios de manera justa. Muchos beneficios se pueden lograr a

2.4. Conceptos de calidad (CMM) en el análisis de sistemas

Año Nombre Modelo / Descripción

investigaciones ayudaron a las

calidad. Desplegó su famosa

Tabla 2.4.1. Movimientos globales de calidad habidos a lo largo de la historia.17

El modelo de madurez y de capacidad (CMM, capability maturity model) comprende los

Desarrollo del CMMI18

CMM Integration surge como un proyecto con la finalidad de solucionar el problema de

El desarrollo de un conjunto de modelos integrados implicó más que una simple

CMM for Software Systems Engineering

CMMI for Development

CMMI for Acquisition CMMI for Development CMMI for Services

Figura 2.4.1. Historia de los CMMs.19

CMMI para desarrollo

CMMI para desarrollo es un modelo de referencia usado tanto en productos como en

Basado en CMMI-DEV 1.2. Disponible en: http://chrguibert.free.fr/cmmi12/cmmi-dev/text/7938cba-6019.php . Recuperado:

2.5. Análisis de requisitos del sistema

Los requisitos funcionales y los requisitos no funcionales se identifican utilizando técnicas

2.6. Especificación funcional del sistema