El documento describe las diferentes fases del ciclo de vida del desarrollo de sistemas, haciendo énfasis en la importancia de la primera fase de definición de requerimientos. En esta fase, el analista construye prototipos iterativos con la participación de los usuarios para definir claramente los requerimientos del sistema a través de sucesivas rondas de evaluación y modificación del prototipo.

1. Hugo González

2. Hugo González

3.  En la primera fase del ciclo de vida del desarrollo de sistemas el analista tiene
que ver con la identificación de problemas, oportunidades y objetivos. Esta
etapa es crítica para el éxito del resto de proyecto, debido a que nadie quiere
desperdiciar el tiempo subsecuente resolviendo el problema equivocado.
 La primera fase requiere que el analista observe honestamente lo que está
sucediendo en un negocio. Luego, junto con los demás miembros de la
organización, el analista hace resaltar los problemas. Frecuentemente estos ya
han sido vistos por los demás, y son la razón por la cual el analista fue llamado
inicialmente.
 Las personas involucradas en la primera fase son los usuarios, analistas y
administradores de sistemas que coordinan el proyecto. Las actividades de
esta fase consisten en entrevistas a los administradores de los usuarios,
sumarización del conocimiento obtenido, estimación del alcance del proyecto y
documentación de los resultados. La salida de esta fase es un estudio de
factibilidad que contiene una definición del problema y la sumarización de los
objetivos. Luego los administradores deben tomar una decisión para ver si
continúan con el proyecto propuesto.

4.  Entre las herramientas utilizadas para definir los
requerimientos de información en el negocio se
encuentran: muestreo e investigación de los datos
relevantes, entrevistas, cuestionarios, el
comportamiento de los tomadores de decisiones y su
ambiente de oficina y hasta la elaboración de
prototipos. En esta fase el analista está esforzándose
por comprender qué información necesitan los
usuarios para realizar su trabajo. Las personas
involucradas en esta fase son los analistas y los
usuarios, típica mente los administradores de las
operaciones y los trabajadores de las operaciones.

5.  La siguiente fase que realiza el analista de sistemas involucro el
análisis de las necesidades del sistema. Nuevamente,
herramientas y técnicas especiales ayudan para que el analista
haga las determinaciones de los requerimientos. Una herramienta
de éstas es el uso de diagramas de flujo de datos para diagramar
la entrada, proceso y salida de las funciones del negocio en
forma gráfica estructurado.
 A partir de los diagramas de flujo de datos se desarrolla un
diccionario de datos, que lista todos los conceptos de datos
usados en el sistema, así como sus especificaciones, si son
alfanuméricos y qué tanto espacio ocupan cuando se imprimen.
Hay tres métodos principales para el análisis de decisiones
estructurales: lenguaje estructurado, tablas de decisión y árboles
de decisión.

6.  En esta fase del ciclo de vida del desarrollo de sistemas, el analista
usa la información recolectada anteriormente para realizar el diseño
lógico del sistema de información. El analista diseña procedimientos
precisos para la captura de datos, a fin de que los datos que van a
entrar al sistema de información sean correctos. Además, el analista
también proporciona entrada efectiva para el sistema de información
mediante el uso de técnicas para el buen diseño de formas y pantallas.

7.  En la quinta fase del ciclo de vida del desarrollo
de sistemas el analista trabaja con los
programadores para desarrollar cualquier
software original que se necesite. Durante esta
fase, el analista también trabaja con los usuarios
para desarrollar documentación efectiva para el
software, incluyendo manuales de
procedimientos. La documentación le dice al
usuario la manera de usar el software y también
qué hacer si se suceden problemas con el
software.

8.  Antes de que pueda ser usado, el sistema de información
debe ser probado. Es mucho menos costoso encontrar
problemas antes de que el sistema sea entregado a los
usuarios. Algunas de las pruebas son realizadas por los
programadores solos, y otras por los analistas de sistemas
junto con los programadores. Primero se ejecuta una serie
de pruebas para que destaquen los problemas con datos
de ejemplo y eventualmente con datos reales del sistema
actual. El mantenimiento del sistema y de su
documentación comienza en esta fase y es efectuado
rutinariamente a lo largo de la vida del sistema de
información.

9.  Definición de un prototipo en software: “…es un
modelo del comportamiento del sistema que
puede ser usado para entenderlo completamente
o ciertos aspectos de él y así clarificar los
requerimientos… Un prototipo es una
representación de un sistema, aunque no es un
sistema completo, posee las características del
sistema final o parte de ellas”

10.  Modelo o maqueta del sistema que se construye
para comprender mejor el problema y sus
posibles soluciones:
 Evaluar mejor los requisitos.
 Probar opciones de diseño.

11. Hugo González

12.  Funcionalidad limitada.
 Poca fiabilidad.
 Características de funcionalidad pobres.
 Alto grado de participación del usuario el cual evalúa los
prototipos, propone mejoras y detalla requisitos.
 Alto grado de participación del analista de sistemas, ya
que en muchos casos los usuarios no pueden indicar los
requisitos sin tener experiencia con el sistema.
 El prototipo da mayor conocimiento al usuario y analistas
ayudando a que el usuario aprenda a utilizar el sistema.

13.  Se presenta al cliente un prototipo para su
experimentación.
 Ayuda al cliente a establecer claramente los
requisitos.
 Ayuda a los desarrolladores a:
 Validar corrección de la especificación.
 Aprender sobre problemas que se presentarán
durante el diseño e implementación del sistema.
 Mejorar el producto.
 Examinar viabilidad y utilidad de la aplicación.

14.  Prototipito de interfaz de usuario: modelos de
pantallas.
 Prototipito funcional (operacional): implementa
algunas funciones, y a medida que se comprueba que
son las apropiadas, se corrigen, refinan, y se añaden
otras.
 Modelos de rendimiento: evalúan el rendimiento de
una aplicación crítica (no sirven al análisis de
requisitos).

15. Hugo González

16.  Sirve al análisis y validación de los requisitos.
 Después se redacta la especificación del sistema
y se desecha el prototipo.
 La aplicación se desarrolla siguiendo un
paradigma diferente.
 Problema: cuando el prototipo no se desecha, y
termina convirtiéndose en el sistema final.

17.  Comienza con un sistema relativamente simple que
implementa los requisitos más importantes o mejor
conocidos.
 El prototipo se aumenta o cambia en cuanto se
descubren nuevos requisitos.
 Finalmente, se convierte en el sistema requerido.
 Actualmente se usa en el desarrollo de sitios Webs y
en aplicaciones de comercio electrónico.

18. Vertical
 Desarrolla completamente alguna de las
funciones.

Horizontal
 Desarrolla parcialmente todas las funciones.
 Herramientas de prototipado.
 Lenguajes dinámicos de alto nivel.
 Lenguajes de cuarta generación (4GLs)
(programación de BBDD).
 Ensamblaje de componentes y aplicaciones.

19.  Muy usados:
 Smalltalk (basado en objetos, sistemas interactivos)
 Java (basado en objetos, sistemas interactivos)
 Prolog (lógico, procesamiento simbólico)
 LISP (basado en listas, procesamiento simbólico)
 Elección del lenguaje:
 ¿Cuál es el dominio de aplicación?
 ¿Cuál es la interacción de usuario requerida?
 (Java, Smalltalk se integran bien con las interfaces Web.)
 ¿Cuál es el entorno proporcionado para el lenguaje?

20.  La mayoría de aplicaciones de gestión son interactivas e implican la
manipulación de una BD y la producción de salidas que involucran
organizar y dar formato a esos datos.
 4GL: lenguaje de programación de BBDD (y su entorno de desarrollo),
que contiene conocimiento de la BD y operaciones para manipulación
de la misma.
 4GL: lenguaje no Procedimental.
 Reducen claramente los costos del desarrollo.
 Muy usados en prototipito evolutivo.
 Muchos 4GLs permiten el desarrollo de interfaces de
 BBDD basadas en navegadores Web.
 Generan SQL.
 Menos eficientes que los lenguajes de programación convencionales.
 Reducen claramente los costos del desarrollo.

21. Hugo González

22. 
El nivel de aplicación, en el que una aplicación completa se integra con el prototipo
 P.ej., si el prototipo requiere procesamiento de textos, se puede integrar un sistema
estándar de procesamiento de textos (MS Office).
 B. El nivel de componente, en el que los componentes se integran en un marco de
trabajo estándar.
 Visual Basic, TCL/TK, Python, Perl…
 - Lenguajes de alto nivel sin tipos, con kits de herramientas gráficas.
 - Desarrollo rápido de aplicaciones pequeñas y relativamente sencillas,
construidas por una persona o conjunto de personas.
 - No existe una arquitectura explícita del sistema.

 CORBA, DCOM, JavaBeans
 - Junto con un marco arquitectónico, es más apropiado para sistemas grandes.

23.  Las descripciones textuales y los diagramas no son
suficientemente buenos para expresar los requisitos
de la interfaz.
 La construcción de prototipos evolutivos con la
participación del usuario final es la forma más
sensata de desarrollar una interfaz.
 Los usuarios deben estar implicados en la
evaluación y evolución del prototipo.

24.  Generadores de interfaz (4GLs, Visual Basic,
etc.).
 Editores de páginas Web.
 Herramientas CASE.
 -Formularios, pantallas, generación de código…
 Bocetos en papel.
 Aplicaciones de dibujo
 -Harward Graphics, etc.
 MS PowerPoint.

25.  Investigación preliminar. Las metas principales de esta fase son: determinar el problema
y su ámbito, la importancia y sus efectos potenciales sobre la organización por una parte
y, por otro lado, identificar una idea general de la solución para realizar un estudio de
factibilidad que determine la factibilidad de una solución software.

 Definición de los requerimientos del sistema. El objetivo de esta etapa es registrar
todos los requerimientos y deseos que los usuarios tienen en relación al proyecto bajo
desarrollo. Esta etapa es la más importante de todo el ciclo de vida, es aquí donde el
desarrollador determina los requisitos mediante la construcción, demostración y
retroalimentaciones del prototipo. Por lo mismo esta etapa será revisada con más detalle
luego de esta descripción.

 Diseño técnico. Durante la construcción del prototipo, el desarrollador ha obviado el
diseño detallado. El sistema debe ser entonces rediseñado y documentado según los
estándares de la organización y para ayudar a las mantenciones futuras. Esta fase de
diseño técnico tiene dos etapas: por un lado, la producción de una documentación de
diseño que especifica y describe la estructura del software, el control de flujo, las
interfaces de usuario y las funciones y, como segunda etapa, la producción de todo lo
requerido para promover cualquier mantención futura del software.

26. 
Programación y prueba. Es donde los cambios identificados en el diseño
técnico son implementados y probados para asegurar la corrección y
completitud de los mismos con respecto a los requerimientos.
 Operación y mantención. La instalación del sistema en ambiente de
explotación, en este caso, resulta de menor complejidad, ya que se supone
que los usuarios han trabajado con el sistema al hacer las pruebas de
prototipos. Además, la mantención también debería ser una fase menos
importante, ya que se supone que el refinamiento del prototipo permitiría
una mejor claridad en los requerimientos, por lo cual las mantenciones
perfectivas se reducirían. Si eventualmente se requiriese una mantención
entonces el proceso de prototipado es repetido y se definirá un nuevo
conjunto de requerimientos.
 La fase más importante corresponde a la definición de requerimientos, la
cual correspondería a un proceso que busca aproximar las visiones del
usuario y del desarrollador mediante sucesivas iteraciones. La definición de
requerimientos consiste de cinco etapas entre dos de las cuales se
establece un ciclo iterativo:

27.  La fase más importante corresponde a la definición de requerimientos,
la cual correspondería a un proceso que busca aproximar las visiones
del usuario y del desarrollador mediante sucesivas iteraciones. La
definición de requerimientos consiste de cinco etapas entre dos de las
cuales se establece un ciclo iterativo:

 Análisis grueso y especificación. El propósito de esta súbase es
desarrollar un diseño básico para el prototipo inicial.

 Diseño y construcción. El objetivo de esta súbase es obtener un
prototipo inicial. El desarrollador debe concentrarse en construir un
sistema con la máxima funcionalidad, poniendo énfasis en la interface
del usuario.


28. 
Evaluación. Esta etapa tiene dos propósitos: extraer a los usuarios la
especificación de los requerimientos adicionales del sistema y verificar que el
prototipo desarrollado lo haya sido en concordancia con la definición de
requerimientos del sistema. Si los usuarios identifican fallas en el prototipo,
entonces el desarrollador simplemente corrige el prototipo antes de la siguiente
evaluación. El prototipo es repetidamente modificado y evaluado hasta que
todos los requerimientos del sistema han sido satisfechos. El proceso de
evaluación puede ser dividido en cuatro pasos separados: preparación,
demostración, uso del prototipo y discusión de comentarios. En esta fase se
decide si el prototipo es aceptado o modificado.
 Modificación. Esto ocurre cuando la definición de requerimientos del sistema
es alterada en la sub−fase de evaluación. El desarrollador entonces debe
modificar el prototipo de acuerdo a los comentarios hechos por los usuarios.
 Término. Una vez que se ha desarrollado un prototipo estable y completo, es
necesario ponerse de acuerdo en relación a aspectos de calidad y de
representación del sistema.
 En la siguiente figura se puede ver un esquema en que estas etapas se
realizan, note que la especificación de requerimientos está claramente
diferenciada de las demás. Es en ella donde se utiliza el prototipado, ya que
permite entregar al usuario lo que sería una visión la solución final en etapas
tempranas del desarrollo, reduciendo tempranamente los costos de
especificaciones erróneas.

29.  Reducción de la incertidumbre y del riesgo
 Reducción de tiempo y de costos, incrementos en la
aceptación del nuevo sistema,
 Mejoras en la administración de proyectos
 Mejoras en la comunicación entre desarrolladores y
clientes, etc.

30. 
La dependencia de las herramientas de software para el éxito ya que la
necesidad de disminución de incertidumbre depende de las iteraciones
del prototipo, entre más iteraciones exista mejor y esto último se logra
mediante el uso de mejores herramientas lo que hace a este proceso
dependiente de las mismas.
 También, no es posible aplicar la metodología a todos los proyectos de
software y, finalmente, la mala interpretación que pueden hacer los
usuarios del prototipo, al cual pueden confundir con el sistema
terminado.
 No se puede desconocer que la fase de definición de requerimientos
se ha perfeccionado en dos aspectos importantes: primero se ha
aproximado las visiones del usuario y el desarrollador, lo cual
representa el beneficio de establecer una base común de
comunicación; también, el hacer explícita la posibilidad de iterar sobre
estos dominios permitiría que la convergencia de los mismos sea una
posibilidad cierta.

31.  Todos los proyectos de ingeniería de software comienzan con una
petición del cliente. La petición puede estar en la forma de una memoria
que describe un problema, un informe que define un conjunto de objetivos
comerciales o del producto, una petición de propuesta formal de una
agencia o compañía exterior, o una especificación del sistema que ha
asignado una función y comportamiento al software, como un elemento
de un sistema mayor basado en computadora. Suponiendo que existe
una petición para un programa de una de las formas dichas
anteriormente, para construir un prototipo del software se aplican los
siguientes pasos:
 PASO 1. Evaluar la petición del software y determinar si el programa a
desarrollar es un buen candidato para construir un prototipo. Debido a
que el cliente debe interaccionar con el prototipo en los últimos pasos, es
esencial que:
 1)el cliente participe en la evaluación y refinamiento del prototipo, y
 2)el cliente sea capaz de tomar decisiones de requerimientos de una
forma oportuna. Finalmente, la naturaleza del proyecto de desarrollo
tendrá una fuerte influencia en la eficacia del prototipo.

32.  PASO 2. Dado un proyecto candidato aceptable, el analista desarrolla
una representación abreviada de los requerimientos. Antes de que
pueda comenzar la construcción de un prototipo, el analista debe
representar los dominios funcionales y de información del programa y
desarrollar un método razonable de partición. La aplicación de estos
principios de análisis fundamentales, pueden realizarse mediante los
métodos de análisis de requerimientos.

PASO 3. Después de que se haya revisado la representación de los
requerimientos, se crea un conjunto de especificaciones de diseño
abreviadas para el prototipo. El diseño debe ocurrir antes de que
comience la construcción del prototipo. Sin embargo, el diseño de un
prototipo se enfoca normalmente hacia la arquitectura a nivel superior
y a los aspectos de diseño de datos, en vez de hacia el diseño
procedimental detallado.

33.  PASO 4. El software del prototipo se crea, prueba y refina Idealmente, los bloques de
construcción de software preexisten se utilizan para crear el prototipo de una forma rápida.
Desafortunadamente, tales bloques construidos raramente existen. Incluso si la
implementación de un prototipo que funcione es impracticable, es escenario de
construcción de prototipos puede aun aplicarse. Para las aplicaciones interactivas con el
hombre, es posible frecuentemente crear un prototipo en papel que describa la interacción
hombre-maquina usando una serie de hojas de historia.
 PASO 5. Una vez que el prototipo ha sido probado, se presenta al cliente, el cual “conduce
la prueba” de la aplicación y sugiere modificaciones. Este paso es el núcleo del método de
construcción de prototipo. Es aquí donde el cliente puede examinar una representación
implementada de los requerimientos del programa, sugerir modificaciones que harán al
programa cumplir mejor las necesidades reales.

 PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos
estén formalizados o hasta que el prototipo haya evolucionado hacia un sistema de
producción. El paradigma de construcción del prototipo puede ser conducido con uno o
dos objetivos en mente:

34.  Las universidades necesitan desarrollar procesos de evaluación institucional de
desempeño, que conllevan a la revisión de sus estructuras funcionales y al conocimiento
diagnóstico de la situación actual con el fin de incrementar los niveles de eficacia,
eficiencia y efectividad de la gestión universitaria.
 Es necesario fomentar procesos de evaluación en función de optimizar el uso de los
recursos humanos, tecnológicos y financieros disponibles en la institución a objeto de
lograr un desarrollo más armónico y planificado, en atención a una estricta observación de
su misión. Bajo esta perspectiva se ofrece una propuesta de Prototipo Informático para la
Evaluación de la Calidad de la Educación Superior, cuyos objetivos, entre otros, son:
fomentar e incentivar la cultura de evaluación de la calidad universitaria; diseñar
indicadores de gestión universitaria para dicho sistema de información, para cada uno de
los ámbitos: académico, investigación, extensión y administrativo. Para el desarrollo, se
aplicarán las herramientas y técnicas para levantar los requerimientos de usuario, y
producir las salidas que satisfagan las necesidades de información y el acceso en forma
integrada a la misma; respecto a los diferentes niveles de la pirámide organizacional,
accesibilidad a indicadores de gestión de calidad universitaria a través de módulos
interdependientes; esto es, cada nivel con su vista de usuario en la base de datos. Se
aplica la metodología modular de sistemas, el enfoque de arriba hacia abajo y el diseño
de base de datos relacional.
 El prototipo está diseñado bajo una interfaz gráfica para interactuar con el usuario a través
de botones programables y la navegación del sistema se realizará a través de pantallas
tipo ventanas

35.  El modelo sistémico, se basa en las fórmulas más
convencionales de la teoría de sistemas,
considerando entradas, transferencias y salidas.
 Será el utilizado para el prototipo informático
propuesto, ya que ofrece todas las bondades de la
metodología de sistemas.
 En el modelo de evaluación propuesto para el
prototipo de evaluación de la calidad universitaria, se
perfilan tres bloques, como lo muestra la gráfica
siguiente:

36. Comunicación
Plan
rápido
Modelado
Construcción
del prototipo
Hugo González

37.  Entrada: estaría constituida por las inversiones, tanto en
recursos materiales como humanos. En otras palabras:
salas, talleres, bibliotecas, laboratorios con todos sus
implementos; además de estudiantes, profesores y
personal administrativo.
 Procesos: estarían compuestos justamente por todas
las interacciones que tienen lugar en la institución y que
permiten que ésta pueda cumplir los compromisos
adquiridos con la sociedad, en cuanto a conocimiento
creados, profesionales formados y servicios entregados
a la comunidad.
 Esto incluye todos los procedimientos de administración
universitaria y gestión financiera de la organización.
 Salida o productos: corresponde a los logros
organizacionales en docencia, investigación y extensión.
Serían aspectos del resultado, la cantidad de graduados
por cohorte, los proyectos de investigación realizados,
las publicaciones de los mismos y el número de
académicos perfeccionados en un periodo determinado.

38.  Función Docente
 Aspectos Generales Académicos
 Función Investigación
 Función Extensión
 Gestión Administrativo-académica

39.  Para el desarrollo del prototipo informático para la evaluación de la calidad de la
educación superior, se aplicarán los instrumentos y técnicas para levantar los
requerimientos de usuario, y producir las salidas que satisfagan las necesidades de
información y el acceso en forma integrada a la misma, respecto a los diferentes
niveles de la pirámide organizacional; esto es, nivel estratégico, nivel táctico y nivel
operativo, accesibilidad a indicadores de gestión de calidad universitaria a través de
módulos interdependientes, es decir, cada nivel con su vista de usuario en la base
de datos.
 Se aplica la metodología modular de sistemas, el enfoque de arriba hacia abajo y el
diseño de base de datos Diseño de arriba hacia abajo (top-down)
 Se selecciona el diseño de arriba hacia abajo, “por la facilidad de visualizar una gran
imagen del sistema y luego explotarla en partes o subsistemas más pequeños. El
diseño de arriba hacia abajo permite que el analista de sistemas piense acerca de
las interrelaciones e interdependencias de los subsistemas. Este enfoque también
proporciona el énfasis deseado sobre la sinergia o las interfaces que requieren los
sistemas y subsistemas. Las ventajas de usar este enfoque para el diseño de
sistemas incluyen el evitar el caos de diseñar un sistema todo a la vez. El tratar de
tener todos los subsistemas en su lugar y funcionando a la vez es aceptar que se va
a fallar”.

40.  Una vez que ha sido tomado el enfoque de diseño de
arriba hacia abajo, el enfoque modular es útil en la
programación. Este enfoque involucra la división de la
programación en partes o módulos lógicos y
manejables. Este enfoque de programación se ajusta
bien con el diseño de arriba hacia abajo, debido a que
enfatiza las interfaces entre módulos. En el prototipo
se aplica la metodología modular de sistemas para
desarrollar los módulos: Función Docente, Función
Investigación, Aspectos Generales Académicos,
Función Extensión, Gestión Administrativo-académica.

41.  Se selecciona el modelo relacional de base de datos, por ser el
óptimo en comparación con los modelos de base de datos
jerárquicos y el de redes. Otra ventaja de este modelo es la
portabilidad, ya que la mayoría de los paquetes de manejo de base
de datos para computadores personales usan el enfoque
“relacional”. En este modelo los datos se organizan en “tablas” en
las cuales una fila equivale a un registro. Conceptualmente la tabla
de la base de datos es lo mismo que un archivo. Una o más tablas
constituyen una base de datos relacional. La base de datos
relacional se refiere a una serie de tablas y a las relaciones entre
ellas.

42. 
Crear y mantener la base de datos: esto es agregar,
eliminar y modificar tablas.Extraer y presentar
información que cumpla ciertas condiciones.Hacer
consultas (por ejemplo: “¿Cuál es el promedio de
notas de los alumnos por carrera y por universidad?
¿Cuál es la matricula por área de conocimiento?
¿Cuál es la rotación matricular?”, etc.).Ordenar los
registros (tablas), según el campo clave.Generar
informes adecuados para el usuario. (Por ejemplo:
una universidad generará el reporte de gestión
periódicamente, según sea el caso o el “Reporte
financiero” puede ser semestral o anual, etc.).

43.  Se generarán una serie de entidades y relaciones “uno a muchos”,
a las cuales se le aplicará la técnica de normalización de tablas,
incluso la tercera forma normal 3FN y 4FN, de ser necesario. Entre
las entidades tenemos: Universidad, Alumnos, Profesor,
Organismos reguladores, Proveedores, Productos, Oferta
académica laboral, Egresados, etc.
Hugo González

44.  Para el desarrollo del prototipo informático para la evaluación de
la calidad de la educación superior, se deben aplicar
instrumentos y técnicas para levantar los requerimientos de
usuario, y producir las salidas que satisfagan las necesidades de
información y el acceso en forma integrada a la misma, respecto
a los diferentes niveles de la pirámide organizacional; esto es
nivel estratégico, nivel táctico y nivel operativo, accesibilidad a
indicadores de gestión de calidad universitaria a través de
módulos interdependientes; esto es, cada nivel con su vista de
usuario en la base de datos.
 El prototipo está diseñado bajo una interfaz gráfica para
interactuar con el usuario a través de botones programables y la
navegación del sistema se realizará a través de pantallas tipo
ventanas.

45.  El origen del estándar MoProSoft es la necesidad de cumplir con la estrategia número 6
del Programa de Software (ProSoft) de la Secretaría de Economía (establecida desde el
sexenio 2000-2006), relativa a "alcanzar niveles internacionales de capacidad de
procesos" por parte de las pequeñas y medianas empresas mexicanas desarrolladoras de
software. El esquema MoProSoft permite a las PyMES que desarrollan software,
demostrar la capacidad de sus procesos y con esto hacerlas más competitivas, a fin de
que tengan mayores probabilidades de permanecer en el mercado.
 En el ámbito de TI, NYCE contribuyó a la elaboración y posterior evaluación del estándar
o norma NMX-I-059/02-NYCE-2011 "Tecnología de la información - Ingeniería de
Software - Calidad de producto"(MoProSoft). La creación de este estándar no fue
casual, ya que con esto se logró dar legitimidad y certeza jurídica al modelo de evaluación
de madurez de la capacidad de procesos, para así elevarlo a la categoría de norma, hoy
estándar MoProSoft.
 Como Unidad de Verificación de Tecnologías de Información (UVTI) acreditada desde
noviembre de 2005 por la Entidad Mexicana de Acreditación en los términos de la Ley
Federal sobre Metrología y Normalización (LFMN), NYCE evalúa el cumplimiento de la
norma NMX-I-059/02-NYCE-2011 (MoProSoft), determinando el nivel de madurez de la
capacidad del proceso de las empresas, a las cuales se les otorga el correspondiente
Dictamen.

46.  La verificación conforme a la norma mexicana NMX-I-
059/02-NYCE-2011 consiste en determinar el nivel de
madurez de los 9 procesos en las organizaciones que
tienen como referencia el modelo MoProSoft.
 Estos 9 procesos están contenidos en tres
categorías: Alta Dirección (DIR), Gerencia (GER) y
Operación (OPE), lo que asegura una cobertura total
en la organización. Se determina el nivel de madurez
de capacidades para cada proceso verificado, y con
base en ello, el nivel de madurez de capacidades de
la organización que es el máximo nivel de capacidad
alcanzado por todos los procesos de MoProSoft.

47. Hugo González

48. GRACIAS POR SU
ATENCION
Por: Hugo González