Gui A 2

República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE I
Universidad Politécnica del Oeste Modulo: Fundamentos de Sistemas e Ingeniería de Software

“Mariscal Sucre” Apuntes Recopilados por: Profesor Bernardo González Rojas
UNIDAD Nº 2 FUNDAMENTOS DE LA INGENIERIA DE SOFTWARE.
TEMA N° 1.- EL SOFTWARE.

1.- Estándar de calidad de la IEEE 1061-1992
1.1.- Historia.
En febrero de 1984, un proyecto para desarrollar un estándar para una metodología del control de
calidad del software era aprobado, formaron a un grupo de funcionamiento porque no había un estándar
existente de IEEE que cubriera el campo del software de calidad.
En diciembre de 1992, el conjunto de los estándares de IEEE aprobó IEEE 1061-1992. Éste era el
primer estándar de IEEE que se ocupó del control de calidad.
Es importante que los usuarios de este estándar entiendan que esto es un estándar de proceso, y no un
estándar que asigna el control por orden específica para su uso. La filosofía de este estándar es que
una organización puede emplear siempre un control que juzgue el más apropiado para sus usos,
mientras se siga la metodología y se validan las métricas. Otra razón de este acercamiento es que no
había consenso de control para su uso (las provisiones de un estándar son obligatorias, no opcionales).
Constante con este acercamiento se realizo la carta de funcionamiento en la que de manera prevista se
veía la aprobación y autorización de este proyecto por el conjunto de los estándares de IEEE.
Debido a la regla de que un estándar se debe revisar o reafirmar en el plazo de cinco años de la emisión,
esta unidad del IEEE fue revisada, sometida y aprobada en 1998. La revisión era seleccionada, y los
comentarios fueron resueltos en 1998. El estándar obtuvo la tarifa necesaria de la aprobación durante la
votación y fue sometida al IEEE, los estándares del SA lo aprobaron en diciembre de 1998.
1.2. Propósito.
La calidad del software es el grado en la cual el software posee una combinación deseada de
cualidades. La combinación de cualidades será definida claramente; si no la calidad se deja a la
intuición.
Para el propósito de este estándar la calidad del software para un sistema es equivalente a definir una
lista de cualidades del software de calidad requeridas para ese sistema.
Para verificar las cualidades de la calidad del software, es necesario un apropiado sistema de control del
software.
El propósito del control del software, es hacer un análisis a través del ciclo de vida del software, si se
están resolviendo los requisitos de calidad del software.
También el uso de control del software reduce subjetividad en la determinación y el control de la
calidad del software, proporcionando una base cuantitativa para tomar decisiones sobre software de
calidad. Sin embargo, el uso del control del software no elimina la necesidad del juicio humano en
software evaluaciones.
Se espera que el uso del control del software dentro de una organización o de un proyecto tenga un
beneficioso efecto haciendo calidad del software más visible.
Más específicamente, el uso de la metodología de este estándar para el control de calidad permite a la
organización:
• Alcance las metas de la calidad;

• Establecer requisitos de calidad para un sistema en su principio;
• Establecer los criterios y los estándares de la aceptación;
• Evaluar el nivel de la calidad alcanzado contra los requisitos establecidos;
• Detectar las anomalías o señalar los problemas potenciales en el sistema;
• Predecir el nivel de la calidad que será alcanzado en el futuro;
Página 1
• Supervisar los cambios en la calidad cuando se modifique el software;

• Determinar la facilidad de cambio del sistema durante la evolución del producto;
• Validar el control de sistema.
Para lograr estos puntos, el proceso y la medición del producto se deben representar en el plan del
control del sistema.
1.3.- Un enfoque actual sobre la calidad del software.

Uno de los problemas que se afrontan actualmente en la esfera de la computación es la calidad del
software. Desde la década del 70, este tema ha sido motivo de preocupación para especialistas,
ingenieros, investigadores y comercializadores de software, los cuales han realizado gran cantidad de
investigaciones al respecto con dos objetivos fundamentales:
i.- ¿Cómo obtener un software con calidad?
ii.- ¿Cómo evaluar la calidad del software?
Ambas interrogantes conllevan amplias respuestas, pero están estrechamente ligadas con el concepto
de la calidad del software, que es el resultado de la primera y la fuente de la segunda.
1.4.- ¿Qué es la calidad del software?

La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y
existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad,
portabilidad, usabilidad, seguridad e integridad.
La calidad del software es medible y varía de un sistema a otro o de un programa a otro. Un software
elaborado para el control de naves espaciales debe ser confiable al nivel de "cero fallas"; un software
hecho para ejecutarse una sola vez no requiere el mismo nivel de calidad; mientras que un producto de
software para ser explotado durante un largo período (10 años o más), necesita ser confiable, mantenible
y flexible para disminuir los costos de mantenimiento y perfeccionamiento durante el tiempo de
explotación.
La calidad del software puede medirse después de elaborado el producto. Pero esto puede resultar muy
costoso si se detectan problemas deriva dos de imperfecciones en el diseño, por lo que es
imprescindible tener en cuenta tanto la obtención de la calidad como su control durante todas las etapas
del ciclo de vida del software.
1.5.- ¿Como obtener un software de calidad?

La obtención de un software con calidad implica la utilización de metodologías o procedimientos
estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la
filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la
vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del
software.
La política establecida debe estar sustentada sobre tres principios básicos: tecnológico, administrativo y
ergonómico.
El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del software.
El principio administrativo contempla las funciones de planificación y control del desarrollo del software,
así como la organización del ambiente o centro de ingeniería de software.
El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado.
La adopción de una buena política contribuye en gran medida a lograr la calidad del software, pero no la
asegura. Para el aseguramiento de la calidad es necesario su control o evaluación.
1.6.- ¿Cómo controlar la calidad del software?

Para controlar la calidad del software es necesario, ante todo, definir los parámetros, indicadores o
criterios de medición, ya que, como bien plantea Tom De Marco, "usted no puede controlar lo que no se
puede medir".
Página 2
Las cualidades para medir la calidad del software son definidas por innumerables autores, los cuales las
denominan y agrupan de formas diferentes. Por ejemplo, John Wiley define métricas de calidad y
criterios, donde cada métrica se obtiene a partir de combinaciones de los diferentes criterios. La
Metodología para la evaluación de la calidad de los medios de programas de la CIC, de Rusia, define
indicadores de calidad estructurados en cuatro niveles jerárquicos: factor, criterio, métrica, elemento de
evaluación, donde cada nivel inferior contiene los indicadores que conforman el nivel precedente. Otros
autores identifican la calidad con el nivel de complejidad del software y definen dos categorías de
métricas: de complejidad de programa o código, y de complejidad de sistema o estructura.
Todos los autores coinciden en que el software posee determinados índices medibles que son las bases
para la calidad, el control y el perfeccionamiento de la productividad.
Una vez seleccionados los índices de calidad, se debe establecer el proceso de control, que requiere los
siguientes pasos:
• Definir el software que va a ser controlado: clasificación por tipo, esfera de aplicación,
complejidad, etc., de acuerdo con los estándares establecidos para el desarrollo del software.
• Seleccionar una medida que pueda ser aplicada al objeto de control. Para cada clase de
software es necesario definir los indicadores y sus magnitudes.
• Crear o determinar los métodos de valoración de los indicadores: métodos manuales como
cuestionarios o encuestas estándares para la medición de criterios periciales y herramientas
automatizadas para medir los criterios de cálculo.
• Definir las regulaciones organizativas para realizar el control: quiénes participan en el control de
la calidad, cuándo se realiza, qué documentos deben ser revisados y elaborados, etc.
A partir del análisis de todo lo anterior, nuestro Centro se encuentra enfrascado en un proyecto para el
Aseguramiento de la Calidad del Software (ACS), válido para cualquier entidad que se dedique a la
investigación, producción y comercialización del software, el cual incluye la elaboración de un Sistema de
Indicadores de la Calidad del Software, la confección de una Metodología para el Aseguramiento de la
Calidad del Software y el desarrollo de herramientas manuales y automatizadas de apoyo para la
aplicación de las técnicas y procedimientos del ACS, de forma tal que se conforme un Sistema de
Aseguramiento de la Calidad del Software.
1.7.- Conclusiones.
Lograr el éxito en la producción de software es hacerlo con calidad y demostrar su buena calidad. Esto
sólo es posible con la implantación de un Sistema para el Aseguramiento de la Calidad del Software
directamente relacionado con la política establecida para su elaboración y que esté en correspondencia
con la definición internacional ISO de calidad, ampliamente aceptada, y por los estándares del grupo ISO
9000.
2.- Atributos de calidad.

Las cualidades de un sistema deben estar por encima y por delante de la función del sistema.
Lamentablemente, la funcionalidad no sólo ocupa el primer lugar en las prioridades de los
desarrolladores sino que muchas veces es el único.
La calidad debe ser considerada en todas las fases del ciclo de vida del software, aunque distintas
cualidades se manifiestan de formas diferentes durante el desarrollo.
2.1.- Cualidades del software.

2.1.1.- Clasificación de las cualidades.
Externas: son visibles a los usuarios.
Internas: son visibles a los desarrolladores del producto: son observables en los distintos productos y
subproductos del ciclo de vida.
Del proceso: describen a la forma en que el producto es producido.
Observables en tiempo de ejecución
Página 3
No observables en tiempo de ejecución

A continuación se describen las cualidades del software:
2.1.2.- Correctitud:
Un programa es funcionalmente correcto si se comporta de acuerdo a la especificación de las funciones
(especificación de requerimientos funcionales) que debería proveer. Esta definición de correctitud asume
que existe una especificación de requerimientos funcionales del sistema y que es posible determinar en
forma no ambigua si las cumple o no. Se presentan diversas dificultades cuando no existe dicha
especificación, o si existe pero está escrita informalmente utilizando, por ejemplo, lenguaje natural por lo
que es posible que contenga ambigüedades.
La correctitud es una propiedad matemática que establece la equivalencia entre el software y su
especificación, por lo que cuanto más riguroso se haya sido en la especificación, más precisa y
sistemática podrá ser su evaluación.
Posteriormente se verá que la correctitud puede ser evaluada mediante diversos métodos, algunos de
enfoque experimental como las pruebas, otros de enfoque analítico como verificación formal de la
correctitud.
Es de notar que esta definición de correctitud no toma en consideración el que la especificación en sí
misma puede ser incorrecta por contener inconsistencias internas, o no corresponder de forma adecuada
a las necesidades para las que fue concebido el programa.
2.1.3.- Confiabilidad.
Informalmente el software es confiable si el usuario puede tenerle confianza. Formalmente la
confiabilidad se define en términos del comportamiento estadístico: la probabilidad de que el software
opere como es esperado en un intervalo de tiempo especificado. Contrariamente a la correctitud que es
una cualidad absoluta, la confiabilidad es relativa. Cualquier desviación de los requerimientos hace que
el sistema sea incorrecto, por otro lado, si la consecuencia de un error en el software no es seria, el
software incorrecto aún puede ser confiable.
En el caso ideal en el que la especificación de requerimientos funcionales captura todas las propiedades
deseables de la aplicación y no hay propiedades indeseables erróneamente especificadas, el conjunto
de todos los programas confiables incluye el conjunto de programas correctos, pero no a la inversa. En la
práctica, como la especificación es un modelo de lo que quiere el usuario que puede ser o no adecuado
para sus necesidades y requerimientos reales, lo máximo que puede hacer el software es cumplir los
requerimientos especificados del modelo, sin asegurar la adecuación del mismo. Pueden tenerse
aplicaciones correctas diseñadas para requerimientos “incorrectos”, por lo que la correctitud del software
puede no ser suficiente para garantizar al usuario que el software se comporta como “es esperado”.
Los productos de la ingeniería son confiables, pero desafortunadamente los productos del software son
en general liberados conjuntamente con una lista de “bugs” conocidos. Este es uno de los síntomas de la
inmadurez de la Ingeniería de Software como disciplina ingenieril y sólo podrá alcanzar ese estatus
cuando se logre que la confiabilidad en el software sea comparable a la confiabilidad en otros productos
como por ejemplo los automóviles.
2.1.4.- Robustez.
Un programa es robusto si se comporta en forma razonable aún en circunstancias que no fueron
anticipadas en la especificación de requerimientos; por ejemplo cuando encuentra datos de entrada
incorrectos o algún malfuncionamiento del hardware como rotura de disco. Un programa que genere un
error no recuperable en tiempo de ejecución tan pronto como el usuario ingrese inadvertidamente un
comando incorrecto no será robusto, aunque podría ser correcto si en la especificación de
requerimientos no se establece la acción a tomar si se ingresa un comando incorrecto.
La robustez es una cualidad difícil de definir, ya que si se pudiera establecer en forma precisa lo que se
debiera hacer para obtener una aplicación robusta, se podría especificar completamente el
comportamiento “razonable”, con lo cual sería equivalente a la correctitud, o a la confiabilidad en el caso
ideal mencionado en la definición anterior.
Se puede observar que la robustez y la correctitud están fuertemente relacionadas: si se incluye un
requerimiento en la especificación será un tema de correctitud, si no se incluye podría ser un tema de
Página 4
robustez. La línea divisoria entre ambos es la especificación del sistema. La relación con la confiabilidad
surge del hecho de que no todos los comportamientos incorrectos significan problemas igualmente
serios, algunos comportamientos incorrectos pueden ser tolerados.
2.1.5.- Observación
La correctitud, confiabilidad y robustez también se aplican al proceso de producción del software, por
ejemplo un proceso es robusto si puede adaptarse a cambios no previstos en el entorno como ser una
nueva liberación del sistema operativo o una transferencia repentina de la mitad de los empleados a otra
sección, un proceso es confiable si lleva consistentemente a la producción de productos de alta calidad.
2.1.6.- Eficiencia.
En la Ingeniería de Software generalmente performance equivale a eficiencia. Un sistema de software es
eficiente si utiliza los recursos computacionales en forma económica. La performance de un sistema es
importante porque afecta su usabilidad, por ejemplo, si es muy lento reduce la productividad de los
usuarios, si usa demasiado espacio de disco puede ser muy caro de ejecutar, si utiliza demasiada
memoria puede afectar al resto de las aplicaciones que se están ejecutando o ejecutarse demasiado
lentamente mientras el sistema operativo intenta balancear el uso de la memoria por parte de las
distintas aplicaciones. Detrás de estos problemas están los límites cambiantes de la eficiencia según
cambia la tecnología, ya que la visión de “demasiado caro” cambia constantemente según los avances
tecnológicos, actualmente una computadora cuesta bastante menos que hace unos años y son bastante
más poderosas. La performance de un sistema también afecta su escalabilidad: un algoritmo de orden al
cuadrado puede funcionar bien con entradas pequeñas y no funcionar para nada con entradas muy
grandes.
2.1.7.- Amigabilidad.
Un sistema de software es amigable si un usuario humano lo encuentra fácil de utilizar. Esta definición
refleja la naturaleza subjetiva de la amigabilidad: una aplicación utilizada por usuarios no experimentados
califica como amigable por varias propiedades distintas a las de una aplicación utilizada por
programadores expertos, por ejemplo, los primeros apreciarían el uso de menú es mientras los segundos
se sentirían más cómodos ingresando comandos.
La interfaz de usuario es un componente importante de la amigabilidad al usuario, siguiendo el ejemplo,
un sistema con una interfaz de ventana y un mouse es más amigable para un usuario no experimentado,
mientras que un usuario más avanzado podría preferir utilizar un conjunto de comandos. La amigabilidad
es más que la interfaz de usuario, por ejemplo, un sistema embebido no tiene interfaz humana, ya que
sólo interactúa con hardware y quizás con otros sistemas. En este caso la amigabilidad está dada por la
facilidad con que el sistema puede configurarse y adaptarse al ambiente de hardware.
Las cualidades del software vistas previamente también afectan a la amigabilidad, por ejemplo un
sistema que produce respuestas erróneas no es amigable sin importar lo “linda” que sea la interfaz de
usuario, del mismo modo que un sistema que produce respuestas más lentas de lo que requiere el
usuario no es amigable aunque estas respuestas sean desplegadas en colores.
2.1.8.- Verificabilidad.
Un sistema de software es verificable si sus propiedades pueden ser verificadas fácilmente. Por ejemplo,
la correctitud o la performance de un sistema son propiedades que interesa verificar. El diseño modular,
prácticas de codificación disciplinadas, y la utilización de lenguajes de programación adecuados
contribuyen a la verificabilidad de un sistema.
La verificabilidad es en general una cualidad interna pero a veces también puede ser externa, por
ejemplo, en muchas aplicaciones de seguridad crítica, el cliente requiere la verificación de ciertas
propiedades.
2.1.9.- Mantenibilidad.
El término mantenimiento del software es utilizado generalmente para referirse a las modificaciones que
se realizan a un sistema de software luego de su liberación inicial, siendo visto simplemente como
“corrección de bugs”. Algunos estudios han mostrado sin embargo, que la mayor parte del tiempo
utilizado en mantenimiento es para agregarle al producto características que no estaban en las
especificaciones originales o estaban definidas incorrectamente.
Página 5
En realidad la palabra “mantenimiento” no es apropiada para el software ya que cubre un amplio rango
de actividades que tienen que ver con la modificación de un software existente para lograr una mejora,
un término que se aplica mejor a este proceso es “evolución del software”. Además en otros productos
de ingeniería como hardware de computadoras, automóviles o máquinas de lavar, el mantenimiento se
refiere al costo de reparación del producto en respuesta al deterioro gradual de sus partes debido a su
uso, sin embargo, se seguirá utilizando este término también para el software. Hay evidencia de que los
costos de mantenimiento exceden el 60% del total de los costos del software. Para analizar los factores
que afectan estos costos, es usual dividir el mantenimiento del software en tres categorías: correctivo,
adaptativo y perfectivo.
El mantenimiento correctivo tiene que ver con la eliminación de errores residuales presentes en el
producto al ser liberado así como errores introducidos al software durante su mantenimiento. Este tipo de
mantenimiento corresponde aproximadamente al 20% de los costos de mantenimiento.
El mantenimiento adaptativo involucra el ajuste de la aplicación a cambios en el entorno, por ejemplo una
nueva liberación de hardware o del sistema operativo, o un nuevo sistema de bases de datos. En este
caso la necesidad de cambios al software no puede ser atribuida a una característica del software en sí
mismo como la inhabilidad de proporcionar determinada funcionalidad requerida por el usuario o errores
residuales, sino que se originan debido a cambios en su entorno. Este tipo de mantenimiento
corresponde aproximadamente a otro 20% de los costos de mantenimiento.
El mantenimiento perfectivo involucra cambios en el software para mejorar algunas de sus cualidades,
los cuales se deben a la necesidad de modificar las funciones ofrecidas por la aplicación, agregar nuevas
funcionalidades, mejorar la performance, facilitar su utilización, entre otras. Estos cambios pueden ser
originados tanto por el ingeniero de software para mejorar el estatus del producto en el mercado, como
por el cliente debido a nuevos requerimientos. Este tipo de mantenimiento corresponde a más del 50%
de los costos de mantenimiento.
La mantenibilidad del software se verá a continuación como dos cualidades separadas: reparabilidad y
evolucionabilidad.
2.1.10.- Reparabilidad.
Un sistema de software es reparable si permite la corrección de sus defectos con una carga limitada de
trabajo. En otros campos de la ingeniería puede ser más barato cambiar un producto entero o una buena
parte del mismo que repararlo, por ejemplo televisores, y una técnica muy utilizada para lograr
reparabilidad es usar partes estándares que puedan ser cambiadas fácilmente. Sin embargo, en el
software las partes no se deterioran, y aunque el uso de partes estándares puede reducir el costo de
producción del software, el concepto de partes reemplazables pareciera no aplicar a la reparabilidad del
software. Otra diferencia es que el costo del software está determinado, no por partes tangibles sino por
actividades humanas de diseño.
Un producto de software consistente en módulos bien diseñados es más fácil de analizar y reparar que
uno monolítico, sin embargo, el solo aumento del número de módulos no hace que un producto sea más
reparable. Una modularización adecuada con definición adecuada de interfaces que reduzcan la
necesidad de conexiones entre los módulos promueve la reparabilidad ya que permite que los errores
estén ubicados en unos pocos módulos, facilitando la localización y eliminación de los mismos.
La reparabilidad de un producto afecta su confiabilidad, por otro lado la necesidad de reparabilidad
decrece a medida que aumenta la confiabilidad.
2.1.11.- Evolucionabilidad.
Un sistema es evolucionable si acepta cambios que le permitan satisfacer nuevos requerimientos. En
otros productos de ingeniería las modificaciones van precedidas de actividades como estudios de
factibilidad, diseño asociado, aprobaciones, evaluaciones y finalmente la introducción de la modificación.
En el caso del software, en general la implementación del cambio se comienza sin realizar ningún
estudio de factibilidad, dejando únicamente el diseño original y sin documentación a posteriori, esto es
sin actualizar las especificaciones para reflejarlo, lo que hace que cambios futuros sean cada vez más
difíciles de aplicar.
Por otro lado, los productos de software exitosos tienen larga duración, su primera liberación es el
comienzo de un tiempo extenso de vida y cada liberación sucesiva es el próximo paso en la evolución
del sistema. Si el software es diseñado cuidadosamente y cada modificación es realizada con cuidado
Página 6
puede evolucionar en buena forma. La mayoría de los sistemas de software comienzan siendo
evolucionables pero luego de años de evolución alcanzan un estado en el cual cualquier modificación
importante trae aparejado el riesgo de “dañar” características existentes. En general la aplicación de
cambios sucesivos tiende a reducir la modularidad del sistema original, que era lo que lo hacía
evolucionable.
La evolucionabilidad es una cualidad tanto del producto como del proceso, aplicado al segundo éste
debe ser capaz de adaptarse a nuevas técnicas de gestión y organización, cambios en la educación en
ingeniería, etc. Es una de las cualidades más importantes del software, e involucra otros conceptos como
familias de programas cuyo propósito es fomentar la evolucionabilidad.
2.1.12.- Reusabilidad.
La reusabilidad es similar a la evolucionabilidad: en la segunda se modifica un producto para construir
una nueva versión del mismo producto, en la primera se utiliza un producto, posiblemente con
modificaciones menores, para construir otro producto. Un ejemplo de un producto reusable es el shell de
UNIX que además de aceptar comandos de usuario y ejecutarlos, puede ser iniciado mediante un
archivo que contenga una lista de comandos del shell, lo que permite escribir programas (scripts) en el
lenguaje de comandos del shell, por lo que puede verse el programa como un nuevo producto que utiliza
el shell como componente. Puede parecer más apropiado aplicar este término a componentes del
software que a productos completos, pero es ciertamente posible construir productos que sean
reusables. Aunque es una herramienta importante para reducir los costos de producción del software, los
ejemplos de reusabilidad son raros.
Es difícil lograr reusabilidad a posteriori, por el contrario se debe contemplar al momento de desarrollar
los componentes del software; una técnica para lograr reusabilidad es la utilización de diseño orientado a
objetos. Otro nivel de reusabilidad está dado en los requerimientos: al analizar una nueva aplicación se
pueden identificar partes que son similares a otras utilizadas en una aplicación previa. También en el
nivel del código, se pueden reutilizar componentes desarrollados en una aplicación anterior.
La reusabilidad puede afectar tanto al producto como al proceso, por ejemplo la reusabilidad de
personas en el sentido de reutilizar sus conocimientos específicos en el dominio de una aplicación,
entorno de desarrollo, etc., aunque también tiene sus problemas debido a que este conocimiento se va
con las personas y nunca se vuelve un valor permanente independiente de éstas.
Es también una cualidad del proceso: varias metodologías de software pueden verse como intentos de
reutilizar el mismo proceso para la construcción de productos distintos, y los modelos de ciclo de vida
también son intentos de reutilizar procesos de alto nivel. En el enfoque “replay” de mantenimiento de
software, se reutiliza el proceso seguido al hacer un cambio: se comienza modificando los
requerimientos y se continúa con los mismos pasos utilizados en el desarrollo del producto original.
La reusabilidad es un factor clave que caracteriza la madurez de un área industrial: se pueden ver altos
niveles de reusabilidad en áreas maduras como la industria automotriz donde se construye un auto
ensamblando varios componentes que están altamente estandarizados y son utilizados en muchos
modelos que produce la misma industria, además el proceso de manufactura es en general reutilizado.
El bajo grado de reusabilidad que presenta el software es otra clara indicación de que se debe
evolucionar para alcanzar el estatus de disciplina ingenieril bien establecida.
2.1.13.- Portabilidad.
El software es portable si puede ser ejecutado en distintos ambientes, refiriéndose este último tanto a
plataformas de hardware como a ambientes de software como puede ser determinado sistema operativo.
Si bien se ha transformado en un tema importante debido a la proliferación de procesadores y sistemas
operativos distintos, puede ser importante incluso en una misma familia de procesadores debido a las
variaciones de capacidad de memoria e instrucciones adicionales, por lo que una forma de lograr
portabilidad es asumir una configuración mínima y utilizar un subconjunto de las facilidades provistas que
se garantiza estarán disponibles en todos los modelos de la arquitectura, como instrucciones de máquina
y facilidades del sistema operativo. También es necesario utilizar técnicas que permitan al software
determinar las capacidades del hardware y adaptarse a éstas.
En general la portabilidad se refiere a la habilidad de un sistema de ser ejecutado en plataformas de
hardware distintas, y a medida que la razón de dinero gastado en software versus hardware crece, la
portabilidad gana importancia. Algunos sistemas de software son de por sí específicos para una
Página 7
máquina: un sistema operativo es escrito para controlar una computadora especifica, y un compilador
produce código para una máquina específica, pero incluso en estos casos es posible alcanzar algún nivel
de portabilidad, por ejemplo UNIX fue portado a varios sistemas de hardware distintos y aunque requirió
meses de trabajo el esfuerzo fue mucho menor que escribirlo nuevamente desde cero. Para muchas
aplicaciones es importante ser portable entre sistemas operativos, o de otra forma, los sistemas
operativos proveen portabilidad entre plataformas de hardware.
2.1.14.- Comprensibilidad.
Algunos sistemas de software son más fáciles de comprender que otros, algunas tareas son
inherentemente más complejas que otras. Por ejemplo, un sistema que realiza predicción del clima, sin
importar lo bien que esté escrito, será más difícil de comprender que uno que imprime una lista de
correo. Dadas dos tareas con dificultad similar, se pueden seguir ciertas guías para producir diseños y
escribir programas más comprensibles.
La comprensibilidad es una cualidad interna del producto y ayuda a lograr muchas de las otras
cualidades como evolucionabilidad y verificabilidad. Desde un punto de vista externo, un usuario
considera que un sistema es comprensible si su comportamiento es predecible, en este caso la
comprensibilidad es un componente de la amigabilidad al usuario.
2.1.15.- Interoperabilidad.
La interoperabilidad se refiere a la habilidad de un sistema de coexistir y cooperar con otros sistemas,
por ejemplo, la habilidad de un procesador de texto de incluir gráficas producidas por un paquete de
gráficos. Aunque rara en los productos de software, la interoperabilidad abunda en otros productos de la
ingeniería, por ejemplo, estéreos de distinta marca pueden conectarse juntos y también a televisiones y
videograbadores, de hecho equipos producidos hace décadas se adaptan a nuevas tecnologías como
discos compactos, mientras que casi todos los sistemas operativos tuvieron que ser modificados – en
algunos casos significativamente – antes de que pudieran trabajar con los nuevos discos ópticos. Una
vez más, el ambiente UNIX con sus interfaces estándares ofrece un ejemplo de interoperabilidad limitada
en un único ambiente: promueve que las aplicaciones tengan una interfaz simple y estándar, lo que
permite que la salida de una aplicación sea utilizada como entrada de otra. Por otro lado, esta interfaz es
primitiva y orientada a caracteres, no es fácil para una aplicación utilizar datos estructurados como una
imagen producida por otra aplicación. UNIX tampoco puede el mismo operar conjuntamente con otro
sistema operativo
Un concepto relacionado con la interoperabilidad es el de sistema abierto, que es una colección
extensible de aplicaciones escritas en forma independiente que cooperan para funcionar como un
sistema integrado y permiten la adición de nuevas funcionalidades por parte de organizaciones
independientes, luego de ser liberado. Esto se logra, por ejemplo, liberando el sistema conjuntamente
con una especificación de sus interfaces “abiertas”, que podrán ser utilizadas por distintos
desarrolladores para comunicación entre distintas aplicaciones o sistemas. Los sistemas abiertos
permiten que distintas aplicaciones escritas por distintas organizaciones inter operen.
2.1.16.- Productividad.
La productividad es una cualidad del proceso de producción de software, mide la eficiencia del proceso y
como se vio antes, es la cualidad de performance aplicada al proceso. Un proceso eficiente resulta en
una entrega más rápida del producto.
Los ingenieros producen software individualmente a cierta tasa, la cual puede variar considerablemente
entre individuos con habilidad distinta. Cuando los individuos conforman un equipo, la productividad de
éste es alguna función de las productividades individuales, y en general esta productividad combinada es
menor que la suma de las partes.
Con respecto a la productividad se pueden adoptar distintas soluciones de compromiso al momento de
elegir un proceso, por ejemplo, si se requiere especialización de los individuos se logrará productividad
en la producción de cierto producto pero no de otros, si se quieren desarrollar componentes reusables se
reducirá la productividad del grupo a cargo del desarrollo debido a que éstos son más difíciles de
desarrollar, pero se logrará una mayor productividad a nivel de la organización involucrada, en el
desarrollo de varios productos.
Página 8
Medir la productividad es una tarea difícil, se necesita una métrica que permita comparar distintos
procesos en términos de su productividad. Algunas métricas como LOC (lines of code) producidas tienen
varias desventajas que serán vistas posteriormente.
Como en otras disciplinas de la ingeniería la eficiencia del proceso se ve fuertemente afectada por la
automatización: las herramientas de ingeniería de software y ambientes modernos, traen asociado un
aumento en la productividad.
2.1.17.- Oportunidad.
La oportunidad es una cualidad del proceso que se refiere a la habilidad de entregar un producto a
tiempo. Históricamente los procesos de producción de software no han tenido esta cualidad lo que llevó
a la llamada “crisis del software” que a su vez trajo aparejada la necesidad y el nacimiento de la
ingeniería de software. Incluso actualmente muchos procesos fracasan en lograr sus resultados a
tiempo.
La oportunidad en sí misma no es una cualidad útil, aunque llegar tarde puede llevar a perder
oportunidades en el mercado, entregar un producto a tiempo que carece de otras cualidades como
confiabilidad o performance, no tiene sentido.
Entregar un producto a tiempo requiere una agenda planeada cuidadosamente, con un trabajo de
estimación acertado y puntos de revisión especificados claramente y verificables. Todas las demás
disciplinas de la ingeniería utilizan técnicas estándares de gestión de proyectos, incluso hay varias
herramientas informáticas para hacerlo. Estas técnicas estándares de gestión de proyectos son difíciles
de aplicar en la ingeniería de software debido a la dificultad en medir la cantidad de trabajo requerido
para producir una pieza de software dada, la dificultad en medir la productividad de los ingenieros y el
uso de puntos de revisión imprecisos y no verificables. Otra razón de la dificultad en lograr la entrega en
tiempo en un proceso de software es el cambio continuo en los requerimientos del usuario.
Una técnica para alcanzar la entrega en tiempo de un producto es la liberación incremental del mismo,
esto es subconjuntos del producto completo cuyo uso ayuda a redefinir los requerimientos
incrementalmente. La aplicación de esta técnica depende de la habilidad para partir las funciones
requeridas del sistema, en subconjuntos que se puedan entregar en forma incremental, utilizando un
proceso de desarrollo incremental, ya que un proceso no incremental no permite este tipo de producción
aún si se pueden identificar los subconjuntos para la construcción incremental.
2.1.18.- Visibilidad.
Un proceso de desarrollo de software es visible si todos sus pasos y su estado actual son claramente
documentados. Otros términos utilizados son transparencia y apertura. La idea es que los pasos y el
estado del proyecto están disponibles y fácilmente accesibles para ser examinados externamente.
En muchos proyectos de software la mayoría de los ingenieros e incluso los gerentes no conocen el
estado exacto del proyecto, algunos están diseñando, otros codificando, otros testeando y todos al
mismo tiempo. Esto no está mal en sí mismo, pero si un ingeniero comienza a rediseñar una gran parte
del código justo antes de que el software sea liberado para una prueba de integración, los riesgos de
generar problemas y retrasos son altos.
La visibilidad permite a los ingenieros pesar el impacto de sus acciones y por lo tanto, los guía al tomar
decisiones, permite que los integrantes del equipo trabajen todos en la misma dirección. En el ejemplo
anterior se puede observar que en lugar de esto, mientras el grupo de testeo ha trabajado en testear una
versión y espera que la siguiente tenga corrección de errores y mínimas diferencias con ésta, un
ingeniero decide rediseñar gran parte del código para corregir un defecto menor. Esto producirá, además
de lo mencionado previamente, tensiones entre los grupos involucrados ya que por un lado se intenta
estabilizar el software y por el otro se está desestabilizando, por supuesto sin intención.
Esta cualidad del software es tanto interna como externa, ya que en el transcurso de un proyecto
muchas veces se requieren informes del estado del mismo, como presentaciones formales o informales,
generalmente por parte de los gerentes de la organización para futuras planificaciones o por parte del
mismo cliente. Si el proceso de desarrollo tiene poca visibilidad, los reportes de estado no serán
acertados o insumirá mucho esfuerzo realizarlos cada vez.
Una dificultad en la gestión de proyectos grandes es la gestión del conocimiento, muchas veces
información crítica sobre los requerimientos y diseño tiene forma de “folklore”: es conocida solo por
Página 9
personas que han estado en el proyecto desde el inicio o por un largo tiempo. En esos casos es bastante
difícil recuperarse de la pérdida de un ingeniero o agregar nuevos, de hecho, esto último en general
reduce la productividad de todo el proyecto debido al tiempo que demanda la transmisión de
conocimientos al nuevo integrante.
Para lograr visibilidad es importante no solo documentar los pasos sino también mantener en forma
adecuada el estado de los productos intermedios como la especificación de requerimientos y de diseño,
o sea tener también visibilidad del producto.
3.- Principios de la Ingeniería del Software.

3.1.- Introducción.
Ingeniería de software es la disciplina o área de la Ingeniería que ofrece métodos y técnicas para
desarrollar y mantener software. La creación del software es un proceso intrínsecamente creativo y la
Ingeniería del Software trata de sistematizar este proceso con el fin de acotar el riesgo del fracaso en la
consecución del objetivo creativo por medio de diversas técnicas que se han demostrado adecuadas en
base a la experiencia previa. Esta ingeniería trata con áreas muy diversas de la informática y de las
ciencias de la computación, tales como construcción de compiladores, sistemas operativos, o desarrollos
Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas
de información y aplicables a infinidad de áreas: negocios, investigación científica, medicina, producción,
logística, banca, control de tráfico, meteorología, derecho, Internet, Intranet, etc.
Una definición precisa aún no ha sido contemplada en los diccionarios, sin embargo se pueden citar las
enunciadas por algunos de los más prestigiosos autores:
• Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y
mantenimiento de sistemas software (Zelkovitz, 1978)
• Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y
construcción de programas de computadora y a la documentación asociada requerida para
desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción
de Software ( Bohem, 1976).
• Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin
de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer,
1972).
• Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y
mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).
Algunos autores consideran que Desarrollo de Software es un término más apropiado que Ingeniería de
Software (IS) para el proceso de crear software. Personas como Pete McBreen (autor de "Software
Craftmanship") cree que el término IS implica niveles de rigor y prueba de procesos que no son
apropiados para todo tipo de desarrollo de software
En esta sección se presentan algunos principios generales de importancia, que son centrales para
desarrollar software en forma exitosa, y que tratan tanto del proceso de ingeniería de software como del
producto final. El proceso adecuado ayudará a desarrollar el producto deseado, pero también el producto
deseado afectará la elección del proceso a utilizar. Un problema tradicional de la ingeniería de software
es poner el énfasis en el proceso o en el producto excluyendo al otro, sin embargo, ambos son
importantes.
Estos principios son suficientemente generales para ser aplicados a lo largo del proceso de construcción
y gestión del software, sin embargo no son suficientes para guiar el desarrollo ya que describen
propiedades deseables de los procesos y productos de software; para aplicarlos es necesario contar con
métodos apropiados y técnicas específicas. Los métodos son guías generales que gobiernan la
ejecución de alguna actividad, presentan enfoques rigurosos, sistemáticos y disciplinados, por otro lado,
las técnicas son más mecánicas y se refieren a aspectos más “técnicos” que los métodos y tienen
aplicación restringida. Una metodología es un conjunto de métodos y técnicas cuyo propósito es
promover cierto enfoque para la resolución de un problema mediante ese conjunto seleccionado. Las
herramientas son desarrolladas para apoyar la aplicación de técnicas, métodos y metodologías. Los
principios son la base de todos los métodos, técnicas, metodologías y herramientas.
Los principios del software se describen a continuación:
Página 10
3.2.- Rigor y formalidad.

En cualquier proceso creativo existe la tendencia a seguir la inspiración del momento de forma no
estructurada, sin ser precisos; el desarrollo de software es de por sí una actividad creativa. Por otro lado,
el rigor es un complemento necesario de la creatividad en todas las actividades de la ingeniería;
únicamente a través de un enfoque riguroso podrán producirse productos más confiables, controlando
sus costos e incrementando el grado de confianza en los mismos. El rigor no tiene por qué restringir la
creatividad, por el contrario, puede potenciar la creatividad aumentando la confianza del ingeniero en los
resultados de la misma, una vez que estos son analizados a la luz de evaluaciones rigurosas.
Paradójicamente el rigor es una cualidad intuitiva que no puede ser definida en forma rigurosa, pero sí
pueden alcanzarse varios niveles de rigurosidad siendo el más alto la formalidad.
La formalidad es un requerimiento más fuerte que el rigor: requiere que el proceso de software sea
guiado y evaluado por leyes matemáticas. Obviamente formalidad implica rigor pero no a la inversa: se
puede ser riguroso incluso informalmente. En todos los campos de la ingeniería el proceso de diseño
sigue una secuencia de pasos bien definidos, establecidos en forma precisa y posiblemente probados,
siguiendo en cada paso algún método o aplicando alguna técnica. Estos métodos y técnicas estarán
basados en alguna combinación de resultados teóricos derivados de un modelado formal de la realidad,
ajustes empíricos que tienen en cuenta fenómenos no presentes en el modelo, y métodos prácticos de
evaluación que dependen de la experiencia pasada (“rules of thumb”).
Un ingeniero debe saber cómo y cuándo ser formal si es requerido, entendiendo el nivel de rigor y
formalidad que debe ser alcanzado dependiendo de la dificultad conceptual de la tarea y su criticidad, lo
que puede variar para diferentes partes del mismo sistema. Por ejemplo, partes críticas pueden requerir
una descripción formal de las funciones esperadas y un enfoque formal para su evaluación mientras que
partes estándares o bien entendidas requerirán enfoques más simples. Esto aplica también en el caso de
la ingeniería de software, por ejemplo en el caso de la especificación del software la cual puede
establecerse de forma rigurosa utilizando lenguaje natural o también puede darse formalmente mediante
una descripción formal en un lenguaje de sentencias lógicas. La ventaja de la formalidad sobre el rigor es
que puede ser la base para la mecanización del proceso, por ejemplo si se quiere utilizar la descripción
formal para crear el programa si éste no existe, o para mostrar que el programa se corresponde con las
especificaciones establecidas si tanto el programa como las especificaciones existen.
Tradicionalmente es en la fase de codificación donde se utiliza un enfoque formal ya que los programas
son objetos formales: son escritos en un lenguaje cuya sintaxis y semántica están completamente
definidas. Los programas son descripciones formales que son manipuladas automáticamente por los
compiladores que chequean su correctitud y las transforman en una forma equivalente en otro lenguaje
(assembler o lenguaje de máquina), todo lo cual es posible gracias a la utilización de la formalidad en la
programación.
La aplicación del principio de rigor y formalidad tiene influencia beneficiosa en la obtención de cualidades
del software como la confiabilidad, verificabilidad, mantenibilidad, reusabilidad, portabilidad,
comprensibilidad e interoperabilidad. Por ejemplo, una documentación del software rigurosa o incluso
formal puede mejorar todas estas cualidades sobre una documentación informal que puede ser ambigua,
inconsistente e incompleta.
El principio de rigor y formalidad también se aplica al proceso de software; la documentación rigurosa del
proceso ayuda a que éste sea reutilizado en proyectos similares y también ayuda a mantener un
producto existente permitiendo que las modificaciones se realicen partiendo del nivel intermedio
apropiado, en lugar de hacerlo solamente sobre el código final. Si el proceso de software está
especificado en forma rigurosa, los gerentes podrán controlar su adecuación y evaluar su oportunidad
para mejorar la productividad.
3.3.- Separación de intereses.

Este principio permite enfrentarse a los distintos aspectos individuales de un problema de forma de
concentrarse en cada uno por separado. En el desarrollo de un producto de software deben tomarse
muchas decisiones como las funciones que serán ofrecidas, la confiabilidad esperada, eficiencia de
tiempo y espacio, relaciones con el ambiente como recursos de software o hardware especial, interfaces
de usuario, entre otras. Otras decisiones tienen que ver con el proceso de desarrollo como el ambiente
de desarrollo, la organización y estructura del equipo, la agenda, los procedimientos de control, las
estrategias de diseño, los mecanismos de recuperación frente a errores, entre otras. Y otras más que
tienen que ver con temas económicos y financieros. Muchas de estas decisiones pueden no estar
Página 11
relacionadas entre sí por lo que obviamente podrán ser tratadas en forma separada, pero muchas otras
estarán fuertemente relacionadas y será prácticamente imposible tener en cuenta todos los temas al
mismo tiempo o por parte de las mismas personas. La única forma de enfrentar la complejidad de un
proyecto es separar los distintos intereses.
La primera forma en la que se pueden separar los distintos intereses es según el tiempo, lo que permite
planificar las distintas actividades y eliminar el trabajo extra que implica cambiar de una a otra en forma
no restringida. Esta separación según el tiempo es la motivación que hay tras el ciclo de vida del
software; un modelo racional de la secuencia de actividades que deberían seguirse en la producción de
software.
Otra forma de separación de intereses es en términos de las cualidades que deberían tratarse por
separado, por ejemplo podrían enfrentarse separadamente la eficiencia y correctitud de un programa,
primero diseñándolo cuidadosa y estructuradamente para garantizar su correctitud a priori y luego
reestructurarlo para mejorar su eficiencia.
Otro tipo importante de separación de intereses permite que distintas visiones del software sean
analizadas en forma separada, por ejemplo al analizar los requerimientos de una aplicación podría ser de
ayuda concentrarse por un lado en los datos que fluyen de una actividad a otra y por otro lado en el flujo
de control que gobierna la sincronización de dichas actividades. Ambas ayudan a entender el sistema y
ninguna de las dos provee una visión completa del mismo.
Otra forma más de aplicación de este principio es enfrentar partes del mismo sistema en forma
separada, esto es en términos de tamaño. Este es un concepto fundamental que debe dominarse para
enfrentar la complejidad de la producción de software, y es tan importante que se trata como un punto
aparte bajo el principio de modularidad.
Si bien podrían perderse algunas optimizaciones potenciales al no tener en cuenta el problema en su
conjunto, la complejidad global puede resolverse mucho mejor concentrándose en los distintos aspectos
por separado, incluso si no fuera posible descomponer el problema en los distintos aspectos en forma
inmediata, es posible tomar inicialmente algunas decisiones de diseño generales y luego aplicar el
principio de separación de intereses en forma efectiva.
Como observación final, la separación de intereses podría resultar en la separación de responsabilidades
al enfrentarse a los distintos aspectos a tener en cuenta, por lo tanto es la base para dividir el trabajo en
un problema complejo en asignaciones de trabajo específicas posiblemente a personas distintas con
distintas habilidades.
3.4.- Modularidad.
Un sistema complejo puede dividirse en piezas más simples llamadas módulos, un sistema compuesto
de módulos es llamado modular. El principal beneficio de la modularidad es que permite la aplicación del
principio de separación de intereses en dos fases: al enfrentar los detalles de cada módulo por separado
ignorando detalles de los otros módulos, y al enfrentar las características globales de todos los módulos
y sus relaciones para integrarlos en un único sistema coherente. Si estas fases son ejecutadas en ese
orden se dice que el sistema es diseñado de abajo hacia arriba (bottom up), en el orden inverso se dice
que el sistema es diseñado de arriba hacia abajo (top down).
El principio de modularidad tiene tres (3) objetivos principales: capacidad de descomponer un sistema
complejo, capacidad de componerlo a partir de módulos existentes y comprensión del sistema en piezas
(o pedazos).
La posibilidad de descomponer un sistema se basa en dividir en subproblemas de forma top down el
problema original y luego aplicar el principio a cada subproblema en forma recursiva. Este procedimiento
refleja el bien conocido principio de Divide y Vencerás (Divide & Conquer).
La posibilidad de componer un sistema está basada en obtener el sistema final de forma bottom up a
partir de componentes elementales. Idealmente en la producción de software se quisiera poder
ensamblar nuevas aplicaciones tomando módulos de una biblioteca y combinándolos para formar el
producto requerido; estos módulos deberían ser diseñados con el objetivo expreso de ser reusables.
La capacidad de comprender cada parte de un sistema en forma separada ayuda a la modificabilidad del
sistema. Debido a la naturaleza evolutiva del software muchas veces se debe volver hacia atrás al
trabajo previo y modificarlo. Si el sistema solo puede ser comprendido como un todo las modificaciones
serán difíciles de aplicar y el resultado será poco confiable. Cuando se hace necesario reparar el
Página 12
sistema, la modularización apropiada ayuda a restringir la búsqueda de la fuente de error a componentes

separados.
Para alcanzar estos objetivos los módulos en los que se divida el sistema deben tener alta cohesión y
bajo acoplamiento. Un módulo tiene alta cohesión si todos sus elementos están fuertemente
relacionados y son agrupados por una razón lógica, esto es todos cooperan para alcanzar un objetivo
común que es la función del módulo. La cohesión es una propiedad interna de cada módulo, por el
contrario el acoplamiento caracteriza las relaciones de un módulo con otros. El acoplamiento mide la
interdependencia de dos módulos, por ejemplo si el módulo A hace una llamada a una rutina provista por
el módulo B o accede a una variable declarada por el módulo B. Si dos módulos dependen fuertemente
uno del otro tienen un alto acoplamiento lo que los vuelve difíciles de analizar, comprender, modificar,
testear o rehusar en forma separada. Idealmente se quiere que los módulos de un sistema tengan bajo
acoplamiento.
Una estructura modular con alta cohesión y bajo acoplamiento permite ver los módulos como cajas
negras cuando se describe la estructura global del sistema y luego encarar cada módulo por separado
cuando se analiza o describe la funcionalidad del módulo.
3.5.- Abstracción.
La abstracción es un proceso mediante el cual se identifican los aspectos relevantes de un problema
ignorando los detalles; es un caso especial del principio de separación de intereses en el cual se separan
los aspectos importantes de los detalles de menor importancia. Lo que se abstrae y lo que se considera
dependerá del propósito de la abstracción, por lo que podrán hacerse distintas abstracciones de la
misma realidad cada una de las cuales proveerá una visión de la realidad que sirve para un propósito
específico.
Por ejemplo, cuando los requerimientos de una nueva aplicación son analizados y especificados se
construye un modelo de la aplicación propuesta, el cual podrá ser expresado en varias formas
dependiendo del grado requerido de rigor y formalidad. Sin importar cual sea el lenguaje elegido para
expresar los requerimientos, lo que se provee es un modelo que abstrae los detalles que se decidió que
podían ser ignorados en forma segura. Los lenguajes de programación también son abstracciones
construidas sobre el hardware que proveen constructores útiles y poderosos para escribir programas
ignorando detalles como el número de bits que se utilizan para representar números o los mecanismos
de direccionamiento, lo que permite concentrarse en el problema a resolver en lugar de la forma de
instruir a la máquina para hacerlo.
El principio de abstracción es un principio importante que se aplica tanto a los productos de software
como a los procesos. En este último caso, por ejemplo, al realizar la estimación de costos para una
nueva aplicación una forma posible es identificar algunos factores claves del nuevo sistema y extrapolar
los valores a partir de perfiles de costo de sistemas previos similares. Los factores claves utilizados para
realizar el análisis son abstracciones del sistema.
3.6.- Anticipación al cambio.

El software sufre cambios constantemente, como se vio al tratar la mantenibilidad del software estos
cambios pueden surgir por la necesidad de eliminar errores que no fueron detectados antes de liberar la
aplicación, o por la necesidad de apoyar la evolución de la aplicación debido a nuevos requerimientos o
cambios en los requerimientos existentes.
La habilidad del software para evolucionar no viene sola sino que requiere esfuerzo especial para
anticipar cómo y cuándo pueden ocurrir estos cambios. Cuando se identifican posibles cambios futuros,
se debe tener cuidado de proceder de forma que estos sean fáciles de aplicar, es importante aislar los
posibles cambios en porciones específicas del software de tal forma que estén restringidos a esas
partes.
La anticipación al cambio es posiblemente el principio que más distingue al software de otros tipos de
producción industrial. Muchas veces una aplicación de software es desarrollada mientras sus
requerimientos aún no están completamente comprendidos, al ser liberado y obtener retroalimentación
del usuario debe evolucionar con nuevos requerimientos o cambios a los requerimientos ya existentes
los cuales pueden tener distintos orígenes, por ejemplo debido a cambios en el ambiente de la
organización. Por lo tanto este principio puede ser utilizado para lograr la evolucionabilidad del software y
Página 13
también la reusabilidad de componentes, viendo la reusabilidad como evolucionabilidad de granularidad

más fina, a nivel de componentes.
La aplicación de este principio requiere que se disponga de herramientas apropiadas para gestionar las
varias versiones y revisiones del software en forma controlada. Debe ser posible almacenar y recuperar
documentación, fuentes, ejecutables, etc. de una base de datos que actúe como repositorio central de
componentes reusables, y el acceso a la misma debe estar controlado. Un sistema de software debe
mantenerse consistente, incluso cuando se aplican cambios a algunos de sus componentes. La
disciplina que estudia esta clase de problemas es la Gestión de Configuración y se verá posteriormente.
La anticipación al cambio también aplica al proceso de desarrollo de software, por ejemplo, en la gestión
del proyecto los gerentes deberían anticipar los efectos de una reducción de personal, estimar los costos
y diseñar la estructura de la organización que apoyará la evolución del software, y decidir cuándo vale la
pena invertir tiempo y esfuerzo en la producción de componentes reusables tanto como parte de un
proyecto de desarrollo de software o como un esfuerzo de desarrollo paralelo.
3.7.- Generalidad.
El principio de generalidad establece que al tener que resolver un problema se debe buscar un problema
más general que posiblemente esté oculto tras el problema original, puesto que puede suceder que el
problema general no sea mucho más complejo (a veces puede ser incluso más simple) que el original y
posiblemente la solución al problema general tenga potencial de rehusó, o exista en el mercado como
producto off-the-shelf, o se diseñe un módulo que puede ser invocado por más de un punto en la
aplicación en lugar de tener varias soluciones especializadas.
Por otro lado, una solución general posiblemente sea más costosa en términos de rapidez de ejecución,
requerimientos de memoria o tiempo de desarrollo, que una solución especializada al problema original,
por lo que debe evaluarse la generalidad respecto al costo y la eficiencia al momento de decidir qué vale
más la pena, una solución general o una especializada.
La generalidad es un principio fundamental si se tiene como objetivo el desarrollo de herramientas
generales o paquetes para el mercado, ya que para ser exitosas deberán cubrir las necesidades de
distintas personas. Estos productos de propósito general, off-the-shelf como por ejemplo los
procesadores de texto, representan una tendencia general en el software; para cada área específica de
aplicación existen paquetes generales que proveen soluciones estándares a problemas comunes. Esta
tendencia es idéntica a lo que ocurrió en otras áreas de la industria como por ejemplo, los automóviles
que en los inicios de la tecnología automotriz era posible hacer autos de acuerdo a los requerimientos
específicos de un cliente, pero a medida que el área se fue industrializando solo podían encargarse a
partir de un catálogo y actualmente no es posible pedir un diseño de auto personal a menos que se esté
dispuesto a pagar una enorme cantidad de dinero.
3.8.- Incrementalidad.
La incrementalidad caracteriza un proceso que se desarrolla en forma de pasos, en incrementos,
alcanzando el objetivo deseado mediante aproximaciones sucesivas al mismo, donde cada aproximación
es alcanzada a través de un incremento de la previa.
Una forma de aplicar el principio de incrementalidad consiste en identificar subconjuntos tempranos de
una aplicación que sean útiles de forma de obtener retroalimentación (feedback) temprana del cliente.
Esto permite que la aplicación evolucione en forma controlada en los casos en que los requerimientos
iníciales no están estables o completamente entendidos. La motivación de este principio es que muchas
veces no es posible obtener todos los requerimientos antes de comenzar el desarrollo de una aplicación
sino que éstos van emergiendo a partir de la experimentación con la aplicación o partes de ésta. Por lo
tanto, lo antes que se pueda contar con feedback del usuario sobre la utilidad de la aplicación, más fácil
será incorporar los cambios requeridos la producto. Este principio está ligado al principio de anticipación
al cambio y es otro de los principios en los que se basa la evolucionabilidad.
La incrementalidad se aplica a muchas de las cualidades del software vistas previamente. Se puede por
ejemplo, comenzar con un núcleo de la aplicación que sea útil e ir agregando funcionalidades, también
se puede agregar performance en forma incremental si por ejemplo, la versión inicial enfatizaba las
interfaces de usuario y la confiabilidad, luego sucesivas liberaciones irán mejorando la eficiencia en
tiempo y espacio.
Página 14
Cuando se construye una aplicación en forma incremental, los pasos intermedios pueden ser prototipos
del producto final, esto es solamente una aproximación al mismo. Obviamente un ciclo de vida basado
en prototipos es bastante distinto al tradicional modelo en cascada, y está basado en un modelo de
desarrollo más flexible e iterativo. Estas diferencias tendrán efectos no solo en los aspectos técnicos sino
también en los organizativos y de gestión.
Como se mencionaba en el principio de anticipación al cambio, el desarrollo de software en forma
evolutiva requiere tener especial cuidado en la gestión de documentación, programas, datos de testeo,
etc. que son desarrollados para las varias versiones del software. Cada incremento significativo debe ser
registrado, la documentación debe poder ser fácilmente recuperada, los cambios deben aplicarse en
forma ordenada, etc.
Si lo anterior no se realiza con cuidado, un intento de desarrollo evolutivo podría rápidamente
transformarse en un desarrollo de software indisciplinado y perderse todas las ventajas potenciales de la
evolucionabilidad.
Página 15
TEMA N° 2.- VISION GENERAL DEL PROCESO DE DESARROLLO DEL SOFTWARE.

1.- El papel del usuario.
Todos sabemos que cuanto mayor sea la ayuda de los usuarios en un proyecto de desarrollo de
software, mayores serán las probabilidades de éxito que tenga el mismo.
No obstante es importante hacer algunas matizaciones:
i.- El proyecto no se hace sólo, porque incluso existiendo una gran ayuda por parte de los usuarios,
si no se consigue interpretar con precisión lo que quieren y no se dinamiza un feedback continuo
de los mismos durante todo el proceso de desarrollo, se incrementarán las posibilidades de que
algún requisito funcional no se haya recogido adecuadamente o de que se haya realizado un
software con una usabilidad incómoda para los usuarios.
ii.- Estas circunstancias son fuente de innumerables problemas en las fases finales del proyecto y
provocan retrasos, sobrecostes y grandes dificultades para cerrar el proyecto, además de crear
conflictos con el cliente que pueden perjudicar las relaciones futuras con el mismo. Esto hace
que sea fundamental el papel que desempeñan tanto el jefe de proyectos, como el equipo de
analistas funcionales y analistas programadores.
iii.- Es importante que entre el grupo usuarios asignados al proyecto haya usuarios que vayan a
estar implicados en el futuro uso del sistema de información, es decir, no es suficiente que el
equipo de usuarios esté formado por “ideólogos” o “teóricos” que se nutrirán del resultado del
trabajo de la herramienta, sino que es fundamental que participen usuarios que después se
tengan que poner el mono de trabajo y vayan a trabajar con el software. Es importante conseguir
la combinación de ambos tipos de usuarios (tampoco es positivo que en el grupo de usuarios no
participen usuarios directores, ya que pueden existir conflictos entre usuarios que éstos deben
solucionar y también es recomendable que el software no sólo se diseñe para el corto plazo, sino
que sirva para tareas de gestión, planificación, etc.… y esta visión la proporcionan
principalmente los usuarios directores), por lo que el jefe de proyectos debe poner en
conocimiento del cliente esta necesidad, como es lógico explicando los riesgos de que no se
aplique esta estrategia.
iv.- Los analistas están para ayudar y para colaborar con los usuarios en la especificación y diseño
de la solución, pero no están para “dar lecciones” a los usuarios y enseñarle cómo deben hacer
su trabajo. Si los usuarios hacen su trabajo de una determinada manera, aunque no sea la más
ortodoxa, siempre tendrá una justificación que sólo se entendería si realmente estuviéramos
haciendo su trabajo durante un tiempo y viéramos los problemas con los que se enfrentan
cotidianamente. La clave por tanto está en la colaboración y en el diálogo, es decir, se pueden
proponer cosas al usuario, se le pueden dar ideas, pero no se le puede dar una vuelta al calcetín
de cómo hacen sus tareas, salvo que ellos mismos lo soliciten y procurando en estos casos y en
consenso con los usuarios que los cambios sean tranquilos.
v.- Es fundamental documentar el proyecto, en primer lugar con la documentación que se
especifique en las normativas de desarrollo de la organización para la que se realiza el servicio,
con las matizaciones que indique el Director del Proyecto, en segundo lugar con la
documentación que establezcan las normativas internas de calidad de tu organización (no
requerirá un sobreesfuerzo, ya que en la mayor parte de los casos coincidirá) y a todo lo anterior
sumarle toda la documentación de trabajo que sea necesaria para trabajar con los usuarios, que
no tienen por qué entender de modelos de datos, de diagramas de casos de uso, etc.…, es más,
es un error trabajar con los usuarios utilizando dichas herramientas, ya que estas son de utilidad
técnica y no hablan el mismo lenguaje de los usuarios. Este tipo documentación, por tanto, no
tiene por qué tener los formalismos de la técnica y tiene como objetivo que el usuario capte lo
que el analista está interpretando y se pueda ir perfilando a partir de esto, tanto requisitos, como
casos de uso, interfaces, etc.… Es muy importante trabajar todo esto, ya que comenzar
demasiado pronto con la construcción, es algo muy arriesgado, ya que los costes de modificar
algo en las distintas fases de la construcción pueden ser muy importantes y provocar que se
tengan que reconstruir varias veces distintas funcionalidades de la aplicación.
Página 16
El desarrollo de un Sistema de Información es un una tarea muy compleja, que suele tomar varios meses
y a veces hasta años; actividad en la cual varias personas de diferentes disciplinas aportan sus
conocimientos para alcanzar un objetivo común, la sistematización de un determinado proceso. Sin
embargo, normalmente los usuarios no tienen claro cuál es su función dentro de este proceso de
sistematización; en ocasiones hasta llega a pensar que le está brindando una ayuda al informático con
una actividad netamente técnica, la cual él considera que será para beneficio del informático y no para
mejorar sus propios procesos.
El rol que el usuario desempeña dentro del desarrollo de un Sistema de Información es de suma
importancia, ya que los sistemas se construyen para satisfacer las necesidades particulares del usuario,
en función de los objetivos estratégicos de la organización y ninguna otra persona, incluyendo al analista
del sistema, conoce mejor que el usuario mismo, sus propios requerimientos; razón por la cual se dice
que el usuario es el “Dueño del Sistema”. Sin embargo, éste no es su único papel, ya que existen una
serie de funciones que el usuario debe asumir durante todo el desarrollo del proyecto, las cuales van
exigiendo una determinada categorización del usuario de acuerdo a la responsabilidad que tendrá dentro
del proyecto.
El primer papel del usuario será como Responsable del Sistema, esta será la persona encargada de
definir en forma clara los requerimientos del nuevo sistema. Para ello deberá enviarle al Jefe del
Departamento de Tecnología, una solicitud en la que al menos detalle lo siguiente:
• Nombre del Sistema.
• Objetivos Generales y Específicos.
• Descripción general del Sistema, especificando claramente su funcionamiento.

• Alcances y Delimitación del Sistema, aquí se mencionará lo que se espera que el sistema realice
y además aquellos procesos que están fuera de la frontera del sistema.
• Responsabilidades, dentro del equipo de trabajo, una persona del área usuario que cumplirá con
el papel de Encargado del Proyecto (puede ser el mismo Responsable del Sistema).
El papel que juega el Encargado de Proyecto del área usuario, será de coordinar junto con el Líder de
Proyectos del área técnica todo lo concerniente a la planificación, control y seguimiento del avance del
proyecto. Este será un “Facilitador” entre los usuarios y el equipo técnico que desarrollará el sistema,
velará por el buen cumplimiento de los requerimientos inicialmente planteados y será quien le reporte
directamente al Responsable del Sistema.
Después de elaborar el Plan de Trabajo del proyecto, necesario para iniciar el desarrollo del nuevo
sistema, debemos identificar un nuevo tipo de usuario, al cual llamaremos Usuario Operativo, quien es la
persona que conoce al detalle la operatividad de los diferentes procesos que se quieren sistematizar.
Este tipo de usuario le brindará al analista de sistemas la mayor parte de la información necesaria para
construir el sistema y posteriormente deberá formar parte del grupo de personas que realizarán las
pruebas para aceptar el sistema.
Otro rol que deben de asumir los usuarios, está relacionado con las pruebas del Sistema. Aunque el
Departamento de TI generalmente invierte una gran parte del tiempo de desarrollo, probando,
reprogramando y volviendo a probar las diversas funcionalidades de los sistemas; realmente es el
usuario quien indicará cuando un sistema está listo para su utilización, y esta labor la realizará probando
los sistemas, verificando que éste realmente satisfaga los requerimientos iníciales y los que fueron
aprobados posteriormente mediante una adecuada administración de cambios. En la mayoría de los
proyectos informáticos, el usuario operativo también asume el rol del usuario de pruebas, ya que el
objetivo principal de este rol consiste en minimizar o evitar que posibles fallas de programación incidan
en el normal funcionamiento de una organización, cuando el sistema se encuentre en producción. Cabe
señalar que el trabajo que cumple el usuario con el rol de pruebas, no debe darse únicamente al final del
proyecto, sino que se encuentra activo a lo largo de todo el desarrollo del sistema. Participa en las
pruebas de funcionalidad de componentes, en las de integración, en las de carga de datos, en las
pruebas de aseguramiento de la calidad del producto, en las pruebas finales, etc.
En algunas proyectos de alto impacto para la organización, se requiere de una persona que asuma el rol
de Usuario Patrocinador, la cual normalmente es una autoridad o una persona con un gran poder de
decisión dentro de la Institución, con características de visión, resistencia, persistencia y coraje;
promueven activa y vigorosamente el apoyo y empuje a los proyectos de TI, y a veces con riesgos para
Página 17
ellos (Beath, 1991). Su rol se centrará en la toma de aquellas decisiones del proyecto que afecten en
forma significativa el normal funcionamiento de la Institución. Además, será el encargado de velar por
que el proyecto cuente con los recursos financieros y humanos necesarios para el buen éxito del mismo.
Según Ann Light en la mayoría de los proyectos informáticos no existe un involucramiento real de los
usuarios, sino que éstos se limitan a ser informantes del equipo técnico y esto realmente no significa una
participación real, ni mucho menos de todas las personas necesarias, lo cual podría llevar al fracaso del
proyecto. El usuario debe participar a lo largo de todas las etapas del proyecto aportando sus ideas, sus
requerimientos y visión acerca del uso de las tecnologías de información. (Light 2005).
En el siguiente apartado se analizan las principales causas que impiden una participación real y activa de
los usuarios en los proyectos informáticos, ejecutando el papel protagónico que se espera de él para
garantizar el éxito de este tipo de proyectos.
1.2.- Involucramiento de los usuarios en el desarrollo de sistemas.
Uno de los principales factores críticos de éxito en el desarrollo de Sistemas de Información se refiere a
la motivación del usuario para participar en un proceso de Desarrollo de Sistemas.
El involucramiento del usuario se define como la participación en el desarrollo de un sistema por un
miembro o miembros del grupo objetivo de usuarios (Ives y Olson, 1984); se refiere a un estado
psicológico en el cual una persona cree que un sistema posee dos características: importancia y
relevancia personal (Hartwick y Barki, 1994) esta participación se ha reconocido como un componente
crítico de los eventos de éxito (Jiang, Chen y Klein, 2002).
Como se ha mencionado, el usuario representa la pieza fundamental dentro de este proceso, sin
embargo, en la mayoría de los proyectos informáticos su participación es muy pasiva. Seguidamente se
presentan algunos de los factores que inciden directamente en el poco involucramiento de los usuarios.
Resistencia al cambio: Los usuarios normalmente sienten temor al incorporar la tecnología en sus
procesos, ya que en ocasiones se sienten amenazados por el cambio, debido a que la incorporación de
las tecnologías de información en los procesos, suele replantear las estructuras administrativas, creando
o eliminando funciones, desplazando centros de poder, es decir, la incorporación eficaz de la tecnología
en las instituciones, implica una forma distinta de trabajar. Para minimizar este temor o la resistencia al
cambio, es necesario que el Responsable del Sistema y el Director del Proyecto por parte del área
usuario, junto con las autoridades de la Institución se den a la tarea de administrar los procesos de
cambio organizacional, garantizándoles a los usuarios que sufran modificaciones en sus funciones
actuales, una estabilidad y seguridad dentro de la Organización.
Los usuarios no son espectadores: Este concepto es fundamental y el que más radicalmente afecta los
sistemas, estos se construyen pensando en cómo se va a usar, en cómo van a contribuir en el
mejoramiento de los procesos de la organización. Por tanto, una vez desarrollados los sistemas, los
usuarios asumen nuevos roles asociados a las funcionalidades del sistema, los cuales son
preestablecidos propiamente durante la etapa de desarrollo. Dentro de cualquier Sistema de Información
existen al menos tres grandes roles que los usuarios deben adoptar, los cuales son:
• Rol de Administrador: Los usuarios a los que se les asigna el rol de administrador, tienen acceso
a todas las opciones que comprenden el sistema.
• Rol de Digitador: Este rol se le asigna a todos aquellos usuarios encargados de ingresar,
modificar, eliminar y consultar los datos de ciertas áreas del sistema.
• Rol de Consulta: Este rol le permite a los usuarios visualizar los datos de algunas de las áreas de
los sistemas. En algunas ocasiones, por razones de seguridad o de confidencialidad de la
información, se restringe la visualización de ciertos datos críticos dentro de los sistemas.
Además de los tres roles anteriores, existe otro rol que está tomando cierto nivel de importancia en
algunos sistemas que proveen algún tipo de información de interés para el público en general, este se
denomina Rol de Invitado. Se comporta similar al rol de consulta pero con mayores restricciones en
cuanto a la visualización de ciertos datos del sistema.
Los Usuarios no son diseñadores: El equipo técnico no debe esperar que los usuarios posean
conocimientos de diseño y aunque los tuvieran, el primer grupo debe ubicar al segundo en cuanto al
papel que debe desempeñar cada uno dentro del proyecto. El grupo de usuarios básicamente debe
contribuir con información acerca de su trabajo y de la organización, pensando en cómo la utilización de
Página 18
la tecnología podría ser aprovechada para mejorar sus procesos, mientras que el grupo técnico se
encargará principalmente de aspectos de diseño y construcción del sistema, enfocado principalmente en
satisfacer los requerimientos de los usuarios de forma eficiente
Comunicación efectiva entre la gerencia y los niveles operativos: Existen ocasiones en las cuales se
involucra a un grupo de usuarios dentro de un proyecto informático y estos se encuentran con una gran
motivación, sin embargo, los jefes de departamentos ni los responsables del sistema les indican a estos
usuarios que las actividades adicionales que van a realizar son parte de su carga de trabajo, por lo tanto
está bien tomarse el tiempo necesario para asistir a reuniones o para revisiones de documentos. En
lugar de esto, los usuarios piensan (a veces con justificación) que los jefes de departamento esperan que
ellos continúen con su carga de trabajo normal y busquen tiempo adicional para cumplir con las nuevas
exigencias de trabajo propiciando un entorno en donde las cosas se hacen simplemente por salir del
paso con el mínimo esfuerzo y sobre todo con poco involucramiento.
Capacitación de los usuarios: Los usuarios en general deberían de ser instruidos con respecto a todas
las actividades que comprenden el proceso del desarrollo de sistemas, así como sus funciones y
responsabilidades a lo largo de todo el proyecto. Es importante que participen en las decisiones
referentes a su ámbito de acción y que comprendan las repercusiones de sus decisiones.
Mala Selección de Usuarios: La experiencia y visión global de los usuarios sobre los procesos que se
desean automatizar son otro de los factores que inciden directamente en el éxito de estos proyectos. En
múltiples ocasiones algunos usuarios perciben solamente una parte del problema, enfocándolo como el
principal, siendo realmente éste solo una pequeña parte del problema general (Tsotra 2002). Es por ello
que la selección de los usuarios que formarán parte del equipo de trabajo para desarrollar un sistema, es
una tarea que no debe ser tomada a la ligera, no se trata de seleccionar a las personas con la menor
carga de trabajo, ni a los de menor experiencia, ni a los menos productivos, es decir, no se trata de
asignarle trabajo a las personas problemáticas, todo lo contrario, se trata de conformar un buen equipo
de trabajo con personas deseosas de trabajar, con amplia experiencia, con excelentes ideas,
emprendedoras e innovadoras.
1.3.- El equipo de trabajo ideal.
En muchos proyectos de TI, la participación del usuario es confusa. Esta situación se presenta debido a
que el personal de tecnología normalmente se enfoca en las especificaciones de los sistemas de TI,
mientras que los usuarios se concentran principalmente en los nuevos servicios y productos que el
sistema les brindará. Como resultado de esta situación ambos grupos se enfrascan en una eterna lucha
a lo largo de todo el proyecto, propiciando un ambiente de poca participación por parte de los usuarios.
Realmente son pocos los grupos de trabajo en donde no se presentan diferencias, y mucho menos
cuando estamos hablando de equipos interdisciplinarios, lo importante aquí es que los miembros del
equipo de trabajo tengan claro los objetivos del proyecto como un todo y puedan trabajar en conjunto, de
manera armoniosa, creando un ambiente de trabajo idóneo para que todos participen de una forma
placentera, respetando el área de cada cual, orientados hacia la consecución de los objetivos del
proyecto, aportando sus ideas individuales o grupales y sobretodo buscando una mejora continua para la
organización.
Chaparro y Melchor (2002) mencionan que existen estudios empíricos acerca de la incidencia que tienen
los usuarios en los Sistemas de Información y ésta puede analizarse desde diferentes variables, entre
ellas las más importantes son: la satisfacción del usuario, la toma de decisiones y el uso.
En cuanto a la satisfacción del usuario, tenemos que normalmente se encuentra relacionado con la
percepción del usuario final, sin embargo, debe ser evaluada y medida como un elemento de toda la
organización para el mejoramiento de la calidad.
En lo que respecta a la toma de decisiones, los autores argumentan que en la mayoría de los casos, los
usuarios no entienden sus necesidades en términos de metas de la organización, pero cuando se le
brindan las herramientas y aplicaciones apropiadas para realizar sus tareas, éstos pueden desempeñar
las funciones de toma de decisiones más rápido y con mejor calidad.
La tercera variable se refiere al Uso que se les den a los sistemas de información, los autores
manifiestan que la utilización debería ser medida como la proporción de veces que el usuario selecciona
utilizar los sistemas. Consecuentemente una empresa que paga por un sistema de información que no
usa, ha hecho una mala inversión. Además, reconocen que entre las múltiples variables que influyen en
el uso del sistema, las investigaciones previas determinan dentro de los más importantes: la gente tiende
Página 19
a usar o no usar una aplicación dependiendo si ésta le ayudará a realizar su trabajo de una mejor forma,
es decir, los colaboradores de una organización usarán los sistemas si creen que son fácil de usar y si
incrementarán su desempeño y productividad.
Ahora bien, después de este análisis surge la gran pregunta, qué se debe hacer para que el equipo
técnico desarrolle una aplicación o un sistema de información acorde con las necesidades del usuario,
para que les ayude a incrementar su desempeño y productividad; además que sea fácil de utilizar y
sobre todo, que le brinde apoyo en la toma de decisiones. La respuesta a esta pregunta pareciera muy
compleja, sin embargo es muy sencilla. La teoría del desarrollo de sistemas le brindan a los técnicos
diferentes metodologías enfocadas en el producto final, en el cumplimiento de requerimientos, también
visualizan al usuario como un cliente y consecuentemente el técnico se convierte en un proveedor de
bienes y/o servicios, mientras que lo óptimo sería que los técnicos asumieran un rol de aliados de la
empresa, que vivan los problemas de la misma, identificándose al máximo con ella como si se tratase de
su propio negocio, poniendo todos sus conocimientos técnicos a su servicio; y en conjunto con los
usuarios, quienes conocen el detalle de los procedimientos, juntos busquen soluciones en donde la
aplicación de la tecnología de una manera innovadora y creativa, sirva para contribuir en la maximización
del desempeño y la productividad. Además, el usuario debe participar activamente en todo el desarrollo
del sistema; también debe lograr desarrollar un sentimiento de pertenencia a un grupo, en donde el
producto final surge gracias a sus grandes aportes, es decir, debe contar con un entusiasmo para
participar en el proyecto y apasionarse por las actividades que realiza dentro del grupo de trabajo.
2.- Principios, modelos, métodos, metodologías técnicas, actividades y herramientas en el

proceso de desarrollo del software.
2.1.- Principios del desarrollo de software.
2.1.1..- Eliminar el desperdicio.
• Brindar un liderazgo técnico y de mercado - la organización puede ser exitosa si produce
productos innovadores y tecnológicamente avanzados, pero es importante comprender lo que
valoran nuestros clientes y conocer la tecnología que se está usando.
• Crear solamente cosas de valor - debemos ser cuidados con todos los procesos que sigamos.
Por ejemplo, debemos asegurarnos que todos estos procesos son útiles y están enfocados en
crear valor.
• Escribir menos código - mientras más código se tenga, más pruebas se van a necesitar, por lo
que se necesitará más trabajo. Si escribiremos pruebas para funcionalidad que no se necesita
estamos perdiendo el tiempo.
2.1.2.- Crear conocimiento.

• Crear equipos de diseño y construcción - el líder del equipo de desarrollo tiene que escuchar
a los miembros y hacerles preguntas inteligentes que los incite a buscar respuestas y volver lo
más pronto posible con los problemas que surgen, o con las soluciones inventadas.
• Mantener una cultura de mejora continua - crear un ambiente en donde las personas estén
mejorando continuamente en lo que trabajan - deben saber que no son y no deben ser perfectas
- y que siempre tienen algún área que pueden mejorar.
• Enseñar métodos de resolución de problemas - los equipos de desarrollo deberían

comportarse como pequeños centros de investigación, estableciendo hipótesis y realizando
varios experimentos rápidos para verificar su validez.
2.1.3.- Embeber a la calidad.

• Sincronizar - para lograr una alta calidad en el software nos debemos empezar a ocupar de él
antes de empezar a escribir una sola línea de código.
• Automatizar - automatizar las pruebas, la construcción, las instalaciones, y cualquier cosa que
sea rutinaria. Hay que automatizar de una manera inteligente, de forma que las personas puedan
mejorar el proceso y cambiar cualquier cosa que quieran sin preocuparse por si el cambio hace
que las cosas dejen de funcionar.
Página 20
• Refactor - eliminar la duplicación de código a CERO - cada vez que aparezca la oportunidad,
realizar el refactor del código, de las pruebas y de la documentación para minimizar la
complejidad.
2.1.4.- Postergar el compromiso.

• Agendar las decisiones irreversibles hasta el último momento responsable - debemos
saber hacia dónde queremos ir pero no conocemos el camino del todo, lo vamos descubriendo
día a día - lo más importante es mantener la dirección correcta.
• Romper con las dependencias - los componentes deben estar lo más desacoplados posible
para que puedan implementarse en cualquier orden.
• Mantener opciones - desarrollar múltiples soluciones para todas las decisiones críticas y ver
cuales funcionan mejor.
2.1.5.- Optimizar el total.

• Enfocarse en el flujo completo de valor - enfocarse en ganar la carrera completa (que es el
software). No hay que gastar esfuerzo en optimizar ineficiencias locales, sino en ver el todo y
optimizar a la organización en su totalidad.
• Entregar un producto completo - los equipos necesitan tener buenos líderes, y también
buenos ingenieros, vendedores, especialistas de marketing, secretarias, etc. Todos juntos
pueden entregar un gran producto final a los clientes.
2.1.6.- Entregar rápido.

• Trabajar en bloques pequeños - reducir el tamaño del proyecto, acortar los ciclos de entrega,
estabilizar el ambiente de trabajo (escucha lo que te dice la velocidad), repetir lo bueno y
erradicar las prácticas que crean obstáculos.
• Limitar el trabajo a la capacidad - limitar la cola de tareas al mínimo (una o dos iteraciones por
delante es suficiente), no hay que tener miedo al quitar elementos de la cola - rechazar cualquier
trabajo hasta que se haya vaciado un lugar en la cola.
• Enfocarse en el tiempo del ciclo, no en la utilización - agregar tareas pequeñas a la cola que
no puedan atascar al proceso por un tiempo largo - reducir el tiempo del ciclo y tener pocas
cosas para procesar en la cola
2.1.7.- Respetar a las personas.

• Capacitar a los líderes de equipo - darles a los líderes de equipo entrenamiento, guías y
espacio libre para implementar el pensamiento Lean en su ambiente.
• Mover la responsabilidad y la toma de decisiones al nivel más bajo posible - dejar que las
personas piensen y decidan por su cuenta - ellos saben mejor que nadie cómo implementar
algoritmos difíciles y aplicar tecnologías de última generación.
• Fomentar orgullo por el trabajo - fomentar la pasión y la participación del equipo hacia lo que
hacen y cómo lo hacen.
2.2.- Metodologías de desarrollo de software.

2.2.1.- Introducción.
Una metodología de desarrollo de software se refiere a un framework que es usado para estructurar,
planear y controlar el proceso de desarrollo en sistemas de información.
2.2.2.- Historia.
El desarrollo de los sistemas tradicionales de ciclo de vida se originó en la década de 1960 para
desarrollar a gran escala funcional de sistemas de negocio en una época de grandes conglomerados
empresariales. La idea principal era continuar el desarrollo de los sistemas de información en una muy
Página 21
deliberada, estructurada y metódica, reiterando cada una de las etapas del ciclo de vida. Los sistemas de
información en torno a las actividades resueltas pesadas para el procesamiento de datos y rutinas de
cálculo.
2.2.3.- Evolución de las Metodologías y/o métodos de desarrollo de software.

1970s
• Programación estructurada desde 1969
• Programación estructurada Jackson desde 1975
1980s
• Structured Systems Analysis and Design Methodology (SSADM) desde 1980
• Structured Analysis and Design Technique (SADT) desde 1980
• Ingeniería de la información (IE/IEM) desde 1981
1990s
• Rapid application development (RAD) desde 1991.
• Programación orientada a objetos (OOP) a lo largo de la década de los 90's
• Virtual finite state machine (VFSM) desde 1990s
• Dynamic Systems Development Method desarrollado en UK desde 1995.
• Scrum (desarrollo), en la última parte de los 90's
Nuevo milenio
• Programación extrema desde 1999
• Enterprise Unified Process (EUP) extensiones RUP desde 2002
• Rational Unified Process (RUP) desde 2003.
• Constructionist design methodology (CDM) desde 2004 por Kristinn R. Thórisson
• Agile Unified Process (AUP) desde 2005 por Scott Ambler.
2.2.4.- Clasificación de las metodologías de desarrollo de software.

Todos los métodos o metodologías anteriores, pueden clasificarse en dos (2) grandes grupos,
dependiendo del enfoque de programación y las técnicas y herramientas usadas, las cuales son:
• Desarrollo de sistemas estructurados (basado en la programación estructurada), diagramas de
flujo de datos, diccionario de datos, modelo entidad relación, diagrama de estructuras, modelo
relacional, herramientas CASE, entre otras.
• Desarrollo de sistemas orientado a objetos (basado en la programación orientada a objetos), uso
de los médelos pertenecientes al UML: (diagrama de caso de uso, diagrama de clases, diagrama
de objetos, etc.), modelo entidad relación, modelo relacional, herramientas CASE entre otros.
2.3.- Métodos o modelos de desarrollo de software usados actualmente.

A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados diferenciándose por su
fortaleza y debilidad. La ingeniería de software tiene varios métodos, modelos, paradigmas o filosofías de
desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos
destacar a éstos por ser los más utilizados y los más completos:
• Modelo en cascada o Clásico (modelo tradicional)
• Modelo de prototipos
• Modelo en espiral (modelo evolutivo)
• Desarrollo por etapas
Página 22
• Desarrollo iterativo y creciente o Iterativo e Incremental

• RAD (Rapid Application Development)
• Desarrollo concurrente
• Proceso Unificado
• RUP (Proceso Unificado de Rational).
• Programación extrema (XP- Extreming Programming).
2.4.- Técnicas y herramientas usadas en el desarrollo de software.

2.4.1.- Técnicas de recopilación de información:
Los analistas utilizan una variable de métodos a fin de recopilar los datos sobre una situación existente,
como entrevistas, cuestionario, inspección de registros y observación. Cada uno tiene ventajas y
desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a
asegurar una investigación completa. A continuación se verán cada una de ellas.
I.- Entrevistas.
Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone
el analista. Quienes responde pueden ser gerentes o empleados, los cuales son usuarios actuales del
sistema, existen usuarios potenciales del sistema propuesto o aquellos que proporcionaran datos o serán
afectadas por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en
grupos.
Recabar datos mediante la entrevista: La entrevista es una forma de conversación, ¡no interrogación! Al
analizar las características de los sistemas con personal seleccionado cuidadosamente por sus
conocimientos sobre ese sistema los analistas pueden conocerlos datos que no están disponibles en
ninguna otra forma.
En las investigaciones de sistemas, las formas cualitativas y cuantitativas de la información son
importantes. La información cualitativa está relacionada con opiniones, políticas y descripciones
cuantitativas tratan con números, frecuencia o cantidades. A menudo las entrevistas dan la mejor fuente
de información cualitativa; los otros métodos tienden a ser más útiles en la recabación de datos
cuantitativos.
Mucha gente incapaz de expresarse por escrito puede discutir sus ideas en forma verbal. Como
resultado de esto las entrevistas pueden descubrir rápidamente malos entendidos, falsas expectativas o
incluso resistencia potencial para las aplicaciones en desarrollo; mas aun a menudo es más fácil
calendarizar una entrevista con los gerentes del alto nivel, que pedirles que llenen cuestionarios.
Determinación del tipo de entrevista: La estructura de las entrevistas varía. Si el objetivo de la entrevista
radica en adquirir información general, es conveniente elaborar una serie de preguntas sin estructura,
con una sección de preguntas y respuestas libres. La atmósfera abierta y de fácil flujo de esta modalidad
proporciona una mayor oportunidad para conocer las actitudes, ideas y creencias de quien responde. Sin
embargo, cuando los analistas necesitan adquirir datos más específicos sobre la aplicación o desean
asegurar una alta confiabilidad en las respuestas a las preguntas que han propuesto a sus entrevistados,
las entrevistas estructuradas son mejores.
Las entrevistas estructuradas utilizan preguntas estandarizadas. El formato de respuestas para las
preguntas puede ser abierto o cerrado; las preguntas para respuesta abierta permiten a los entrevistados
dar cualquier respuesta que parezca apropiada. Con las preguntas para respuestas cerradas se
proporciona al usuario un conjunto de respuestas que se pueda seleccionar. Todas las personas que
responden se basan en un mismo conjunto de posibles respuestas.
La confiabilidad es solo una consideración en la selección del método de entrevista. Los analistas
también deben dividir su tiempo entre desarrollar preguntas para entrevistas y analizar las respuestas.
Las entrevistas no estructuradas requieren menos tiempo de preparación, porque no se necesita tener
por anticipado las palabras precisas de las preguntas. Sin embargo, analizar las respuestas después de
las entrevistas lleva más tiempo que con las entrevistas estructuradas. De cualquier manera, el mayor
costo radica en la preparación, administración y análisis de las entrevistas estructuradas para preguntas
cerradas.
Página 23
Dado que un número de personas se seleccionara para la entrevista, los analistas deben tener cuidado
de incluir aquellas personas que tienen información que no se podrá conseguir de otra forma. Durante
las primeras etapas de un estudio de sistemas, cuando los analistas determinan
La factibilidad del proyecto, con frecuencia las entrevistas solo se aplican a la gerencia o personal de
supervisión. Sin embargo, durante la investigación detallada en donde el objetivo es descubrir hechos
específicos, opiniones y conocer como se manejan las operaciones desempeñadas actualmente, las
entrevistas se aplican en todos los niveles gerenciales y de empleados y dependen de quien pueda
proporcionar la mayor parte de la información útil para el estudio. Así, los analistas que estudian a la
administración de inventarios pueden entrevistar a los trabajadores del embarque y de recepción, al
personal del almacén y a los supervisores de los diferentes turnos, es decir, aquellas personas que
realmente trabajan en el almacén; también entrevistaran a los agentes más importantes.
Realización de la entrevista: La habilidad del entrevistador es vital para el éxito en la búsqueda de
hechos por medio de la entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto
de la preparación del objetivo de una entrevista específica como de las preguntas por realizar a una
persona determinada.
El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa. La
falta de estos factores puede reducir cualquier oportunidad de éxito. Por ejemplo, un analista que trabaja
en la aplicación enfocada a la reducción de errores probablemente no tendría éxito si llegar a una oficina
de gerencia de nivel medio con la presentación equivocada, por ejemplo, si dijera, "hola, fui enviado para
encontrar una forma de mojar el rendimiento y de reducir los errores que presentan aquí. O la
introducción: "Estamos aquí para resolver su problema", es igualmente mala. Es imaginable la rapidez
con la que va a responder ser irrita y se molesta con un enfoque de este tipo.
A través de la entrevista, los analistas deben preguntarse así mismos las siguientes interrogantes:
¿Qué es lo que me está diciendo la persona?
¿Por qué me lo está diciendo a mí?
¿Qué se está olvidando?
¿Qué espera esta persona que haga yo?
Si se considera cada elemento de la información contra estas preguntas, los analistas tendrán más
conocimientos no solamente de la información adquirida sino también de su importancia.
II.- Cuestionario.
Los cuestionarios proporcionan una alternativa muy útil para las entrevistas; sin embargo, existen ciertas
características que pueden ser apropiadas en algunas situaciones e inapropiadas en otras.
Recabación de datos mediante cuestionarios: Para los analistas los cuestionarios pueden ser la única
forma posible de relacionarse con un gran número de personas para conocer varios aspectos del
sistema. Cuando se llevan a cabo largos estudios en varios departamentos, se puede distribuir los
cuestionarios a todas las personas apropiadas para recabar hechos con relación al sistema. Por
supuesto, no es posible observar las expresiones o relaciones de quienes responden a los cuestionarios.
También las preguntas estandarizadas pueden proporcionar datos más confiables. Por otra parte, las
características anteriores también son desventajas de los cuestionarios. Aunque su aplicación puede
realizarse con un mayor número de individuos, es muy rara una respuesta total. Puede necesitarse algún
seguimiento de los cuestionarios para motivar al personal que responda; todas las respuestas se
encontraran en una proporción entre el 25 o 35%, que es lo más común.
Selección de formas para cuestionarios: El desarrollo y distribución de los cuestionarios es caro; por lo
tanto, el tiempo invertido en esto debe utilizarse en una forma inteligente. También es importante el
formato y contenido de las preguntas en la recopilación de hechos significativos.
Existen dos formas de cuestionarios para recabar datos; cuestionario abierto y cerrados, y se aplican
dependiendo de si los analistas conocen de antemano todas las posibles respuestas de las preguntas y
pueden incluirlos. Con frecuencia se utilizan ambas formas en los estudios de sistemas.
Cuestionarios abiertos: Al igual, que las entrevistas, los cuestionarios pueden ser abiertos y se aplican
cuando se quieren conocer los sentimientos, opiniones y experiencias generales; también son útiles al
explorar el problema básico, por ejemplo, un analista que utiliza cuestionarios para estudiar los métodos
Página 24
de verificación de crédito, en un medio ambiente de ventas al menudeo, podría recabar mas información
provechosa de una pregunta abierta de este tipo: ¿Cómo podría simplificarse y mejorarse el proceso de
verificación de crédito para los clientes?
Cuestionarios cerrados: El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio
de un cuidadoso estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es
el mejor método para obtener información sobre los hechos. También fuerza a los individuos para que
tomen una posición y forma de opinión sobre los aspectos importantes.
Etapas en el desarrollo de un cuestionario: Los cuestionarios bien hechos no se desarrollan rápidamente,
llevan tiempo y mucho trabajo. La primera consideración se encuentra en determinar el objetivo del
cuestionario. ¿Qué datos quiere conocer el analista a través de su uso? El analista define como utilizar
los cuestionarios a fin de obtener los hechos al considerar la estructura más útil para el estudio y la más
sencilla de entender por parte de los interrogados.
Lleva tiempo desarrollar preguntas bien elaboradas y deben siempre probarse y modificarse, si es
necesario, antes de que imprima una forma final y se distribuya.
Selección de quienes recibirán el cuestionario: Aquellas personas que reciban el cuestionario deben
seleccionarse de a cuerdo con la información que puedan proporcionar. Escribir o imprimir un
cuestionario no significa que se pueda distribuir ampliamente sin un análisis previo. Lo pueden contestar
personas no calificadas y si el cuestionario no es anónimo, y no será posible retirar sus respuestas de la
muestra. La realización de esto también es desgastante y cara.
III.- Recopilación y análisis de documentos.
Recopilación de datos: Deberá dirigirse al registro de aquellos hechos que permitan conocer y analizar lo
que realmente sucede en la unidad o tema que se investiga. Esto consiste en la recolección, síntesis,
organización y comprensión de los datos que se requieren.
Se conocen dos tipos de fuentes:
• Primarias: que contienen información original no abreviada ni traducida.
• Secundarias: obras de referencia que auxilian al proceso de investigación.
Se conoce otra división que se conforma por las siguientes fuentes:
• -Documentales
• -De campo.
IV.- Fichas bibliográficas de trabajo y hemerograficas.
Las fuentes de recolección de datos son todos los registros de aquellos hechos que permitan conocer y
analizar lo que realmente sucede en el tema que se investiga.
Concluida la parte preparatoria de la investigación se inicia la fase de recopilación de datos.
Para recabar la información existente sobre el tema, el investigador se auxilia de instrumentos como las
fichas de trabajo; hay diversos tipos de fichas de trabajo como:
Fichas de trabajo para fuentes documentales, fichas de trabajo de una revista, fichas de trabajo de un
periódico, para investigación de campo, para observación, fichas bibliográficas y hemerográficas.
2.4.2.- Análisis e interpretación de información.

La interpretación de los resultados de la indagación lleva inmediatamente a la solución.
El análisis del instrumento de recolección de información de campo (encuesta), fue utilizando el análisis
individual de preguntas que se realiza con base en los porcentajes que alcanzan las distintas respuestas
de cada pregunta.
Para llevar a cabo este tipo de análisis se diseño una forma donde se tabulan las respuestas en base a
la cantidad de personas que contestaron cada respuesta y el porcentaje que representa del total de la
muestra.
I.- Redacción y presentación del informe.
Página 25
El objetivo del informe es presentar a los lectores el proceso que se realizó para presentar una solución
al problema planteado, para lo cual es necesario hacer la presentación del problema, los métodos
empleados para su estudio, los resultados obtenidos, las conclusiones a las que se llegaron y las
recomendaciones en base a estas.
Con respecto a la estructura del informe, ésta es sencilla y sigue fielmente los pasos fundamentales del
diseño de la investigación, ya que el informe debe ser la respuesta a lo planteado por el diseño de
investigación.
2.4.3..- Observación y técnica Strobe.

I.- Observación estructurada del ambiente (Strobe).
Confirma o niega la narración organizacional de entrevistas o cuestionarios.
La observación es sistemática: Sigue una metodología estándar y una clasificación estándar para el
análisis de los elementos organizacionales que influencian la toma de decisiones. 2. Permite que otros
analistas apliquen el mismo marco de trabajo analítico a la misma organización. 3. Limita el análisis a la
organización como existe durante la etapa de su ciclo actual de vida.
Elemento STROBE son 7:
i.- Ubicación de la oficina. La ubicación de la oficia de un tomador de decisiones particular con
respecto a las demás oficinas.
ii.- Ubicación del escritorio del tomador de decisiones. Proporciona pistas sobre el ejercicio de poder
por el tomador de decisiones.
iii.- Equipo de oficina fijo. Se conforma de archiveros, libreros, etc.
iv.-Propiedades. Todo el equipo pequeño que se usa para procesar información (calculadoras,
pantallas de video, lápices, etc.).
v.- Revistas y periódicos del negocio. Estas revelan si el tomador de decisiones busca información
externa o se apoya más en información interna.
vi.-Iluminación y color de la oficina. Nos indica la manera en que el tomador de decisiones recopila
información.
vii.- Vestimenta usada por los tomadores de decisiones. El analista de sistemas puede obtener una
comprensión de la credibilidad exhibida por los gerentes de la organización observando la
vestimenta que usan en el trabajo.
Mediante el uso de STROBE el analista de sistemas puede obtener una mejor comprensión sobre la
manera en que los gerentes recopilan, procesan, almacenan y usan información.
2.4.4.- Herramientas CASE.

I.- Introducción.
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por
Ordenador) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el
desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas
herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en
tareas como el proceso de realizar un diseño del proyecto, calculo de costes, implementación de parte
del código automáticamente con el diseño dado, compilación automática, documentación o detección de
errores entre otras.
II.- Objetivos
i.- Mejorar la productividad en el desarrollo y mantenimiento del software.
ii.- Aumentar la calidad del software.
iii.- Mejorar el tiempo y coste de desarrollo y mantenimiento de los sistemas informáticos.
iv.- Mejorar la planificación de un proyecto
v.- Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda
de soluciones para los requisitos.
Página 26
vi.- Automatizar, desarrollo del software, documentación, generación de código, pruebas de

errores y gestión del proyecto.
vii.- Ayuda a la reutilización del software, portabilidad y estandarización de la documentación
viii.- Gestión global en todas las fases de desarrollo de software con una misma herramienta.
ix.- Facilitar el uso de las distintas metodologías propias de la ingeniería del software.
III.- Clasificación
Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas CASE se pueden
clasificar teniendo en cuenta los siguientes parámetros:
i.- Las plataformas que soportan.
ii.- Las fases del ciclo de vida del desarrollo de sistemas que cubren.
iii.- La arquitectura de las aplicaciones que producen.
iv.- Su funcionalidad.
La siguiente clasificación es la más habitual basada en las fases del ciclo de desarrollo que cubren:
• Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación, análisis de
requisitos y estrategia del desarrollo, usando, entre otros diagramas UML.
• Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la
aplicación.
• Lower CASE (L-CASE), herramientas que semiautomatizan la generación de código, crean
programas de detección de errores, soportan la depuración de programas y pruebas. Además
automatizan la documentación completa de la aplicación. Aquí pueden incluirse las herramientas
de Desarrollo_rápido_de_aplicaciones.
Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificación
excluyente entre sí, ni con la anterior:
• Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software,
desde análisis hasta implementación.
• Meta CASE, herramientas que permiten la definición de nuestra propia técnica de modelado, los
elementos permitidos del meta modelo generado se guardan en un repositorio y pueden ser
usados por otros analistas, es decir, es como si definiéramos nuestro propio UML, con nuestros
elementos, restricciones y relaciones posibles.
• CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software.
• IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de
vida, incluyen componentes para la gestión de proyectos y gestión de la configuración.
Por funcionalidad podríamos diferenciar algunas como:
• Herramientas de generación semiautomática de código.
• Editores UML.
• Herramientas de Refactorización de código.
• Herramientas de mantenimiento como los sistemas de control de versiones
2.4.5.- Herramientas case estructuradas.
Aparecieron a fines de los 60’s con la Programación Estructurada, posteriormente a mediados de los
70’s extendidas con el Diseño Estructurado y a fines de los 70’s con el Análisis Estructurado. Versiones
más recientes incorporan Diagramas Entidad-Relación y Diagramas de Transición de Estados.
Ejemplos de metodologías estructuradas impulsadas por organismos gubernamentales lo constituyen:
MERISE (Francia), METRICA (España), SSADM (Reino Unido).
Página 27
Otras metodologías estructuradas en el ámbito académico y comercial son: Gane & Sarson, Ward
Mellor, Yourdon & DeMarco y Information Engineering. Esta última propuesta por James Martin pone un
énfasis adicional en el modelado de datos y la incorporación de los desarrollos informáticos dentro del
contexto organizacional (planificación, objetivos, etc.).
2.4.6.- Herramientas case orientada a objetos.
Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más
representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de C++
por Bjarne Stroustrup en 1981 y actualmente Java. Sólo a fines de los 80’s comenzaron a consolidarse
algunas metodologías Orientadas a Objetos.
Algunas de las más representativas en el ámbito comercial son: OMT de Rumbaugh,
OOAD de Grady Booch, OOSE de I.Jacobson, la propuesta por Peter Coad & Edward
Yourdon, la propuesta por S. Shaler & S.J. Mellor y la propuesta por J.Martin y J.J.Odell. En los últimos
años se ha realizado un esfuerzo de estandarización notacional materializado en UML (Unified Modeling
Language), el cual aglutina características de algunas de las propuestas OO más conocidas. En 1997
UML fue aprobado como notación estándar por el OMG.
2.5.- Desarrollo de prototipos.
2.5.1.- ¿Qué es un Prototipo?
Es un modelo a escala o facsímil de lo real, pero no tan funcional para que equivalga a un producto final,
ya que no lleva a cabo la totalidad de las funciones necesarias del sistema final. Proporcionando una
retroalimentación temprana por parte de los usuarios acerca del Sistema.
2.5.2.- Importancia de Definir su Objetivo.
Siempre se debe establecer cuál es su objetivo, ya que un prototipo puede ser útil en diferentes fases del
proyecto, por ello su objetivo debe ser claro. Durante la fase de análisis se usa para obtener los
requerimientos del usuario. En la fase de diseño se usa para ayudar a evaluar muchos aspectos de la
implementación seleccionada.
2.5.3.- Propósitos del Prototipo.
En la fase de Análisis de un proyecto, su principal propósito es obtener y validar los requerimientos
esenciales, manteniendo abiertas, las opciones de implementación. Esto implica que se debe tomar los
comentarios de los usuarios, pero debemos regresar a sus objetivos para no perder la atención.
En la fase de Diseño, su propósito, basándose en los requerimientos previamente obtenidos, es mostrar
las ventanas, su navegación, interacción, controles y botones al usuario y obtener una retroalimentación
que nos permite mejorar el Diseño de Interfaz.
2.5.4.- Características de los Prototipos:
• El proceso de desarrollo y empleo de prototipos tiene las siguientes características:
• El prototipo es una aplicación que funciona
• Los prototipos se crean con rapidez
• Los prototipos evolucionan a través de un proceso iterativo
• Los prototipos tienen un costo bajo de desarrollo
• Información Obtenida con el uso del Prototipo
2.5.5.- Reacciones Iníciales del Usuario.
El profesional de Sistema por medio de la observación, evaluación la retroalimentación, obtendrá cómo
reaccionan los usuarios al trabajar con el prototipo, y que tan conveniente es el acoplamiento entre las
necesidades y las características modeladas en el sistema. A través de la recopilación de tales
reacciones, el profesional, irá descubriendo nuevas perspectivas del prototipo, incluso si los usuarios se
encuentran satisfechos con él, o si habrá dificultades para vender o implantar el sistema.
2.5.6.- Desarrollo de Prototipo
Página 28
I.- Problemas Candidatos

Para decidir si el prototipo debe incluirse o no Ciclo de Desarrollo de Sistema de Información, el
profesional considera los siguientes factores:
Problemas no estructurado, novedosos y complejos, de información personalizada del usuario, ya que
sus salidas no son predecibles y definidas
Problemas de ambiente Inestable, el profesional también debe evaluar el contexto del sistema
II.- Experiencia en diseños similares
No se conocen los requerimientos, la naturaleza del sistema es tal que existe poca información con
respecto a las características que debe tener el nuevo sistema para satisfacer las necesidades del
usuario
Los requerimientos deben evaluarse, se conocen los requerimientos aparentes de información pero es
necesario verificarlos y evaluarlos
Costos altos, donde la inversión involucra gran cantidad de recursos financieros y humanos.
Altos riesgo, la evaluación inexacta de los requerimientos o el desarrollo incorrecto ponen en peligro a la
organización
El usuario, donde no está dispuesta examinar modelos en papel, o no sabe lo que quiere pero lo
reconocerá cuando lo vea.
Tecnologías Nuevas, la falta de experiencia en el uso de dichas tecnologías, junto con el deseo de
instalar nuevas tecnología hace que sea propicio el uso del prototipo.
3.- Selección de la metodología, método o modelo apropiado para desarrollo de software.

Las metodologías, métodos o modelos de desarrollo del sistema, se promueven como un medio para
mejorar la gestión y control del proceso de desarrollo de software, la estructuración y simplificación del
proceso, y estandarizar el desarrollo de procesos y productos mediante la especificación de las
actividades a realizar y las técnicas y herramientas a utilizar. A menudo se asume tácitamente que el uso
de una metodología de desarrollo del sistema mejorará el desarrollo de la productividad del sistema y la
calidad. Sin embargo, existe poca evidencia empírica para apoyar esta hipótesis.
Hay un creciente cuerpo de literatura que cuestiona la eficacia de los métodos formales de desarrollo del
sistema. En particular, las metodologías existentes efectivamente no puede soportar el cambio natural,
tanto del proceso y el producto del desarrollo del sistema.
La mayoría de la investigación hasta la fecha se ha centrado en el desarrollo de nuevos métodos y
marcos para la selección y comparación de metodologías, más que en su evaluación o el uso en la
práctica. Aunque el número de métodos ha proliferado, son en gran parte no probados. No se sabe si es
o cómo se utilizan, la eficacia con que se utilizan, o si son útiles. Mucha de la investigación para el
desarrollo de SI supone implícitamente que los métodos se utilizan y que son útiles y eficaces.
El propósito de esta investigación es descubrir cómo las metodologías o métodos de desarrollo se están
utilizando en las organizaciones. Temas específicos abordados son los tipos de metodologías que se
utilizan, qué nivel de adhesión es, los detalles de la metodología y el grado de satisfacción de las
organizaciones con sus metodologías.
3.2.- Antecedentes.
Quedan muchas preguntas sin respuesta acerca de metodologías o métodos de desarrollo del sistema
Este estudio se refiere específicamente a dos de estas preguntas: el grado de utilización de la
metodología y naturaleza de la adaptación de la metodología en las organizaciones.
Esto parece ser una simple pregunta. Sin embargo, la pregunta podría ser mejor que su enunciado: ¿En
qué medida son las metodologías utilizadas? No se debe suponer que porque una organización tiene
una metodología, la misma es usada en todos sus proyectos. La investigación limitada indica que las
condiciones que rodean los proyectos pueden prevenir el desarrollo de prácticas ideales a ser utilizadas.
Por lo tanto, este estudio examinará la adhesión de la organización a las normas de la metodología para
determinar si las organizaciones están utilizando la metodología adoptada en todos los proyectos de
Página 29
desarrollo o en un subconjunto seleccionado de proyectos. Una pregunta relacionada con la gerencia es

que si la metodología o método adoptado, se utiliza en su totalidad, o solo fragmentos de la metodología
seleccionada, para su uso en proyectos específicos de desarrollo.
Las metodologías o métodos pueden ser comprados y adaptados, ya que es más barato que el
desarrollo de una nueva metodología, y las metodologías deben ser continuamente refinadas para
satisfacer las cambiantes necesidades. La adaptación de las metodologías para usarlas en una situación
particular parece ser común. Un estudio británico indica que los usuarios han adaptado la metodología
mediante la adición u omisión de las técnicas y los pasos. Además de la adaptación de una metodología
única a una situación específica, metodologías diferentes se puede utilizar en diferentes proyectos o
metodologías se pueden adaptar en un proyecto. Sin embargo, no se sabe cómo esas decisiones se
hacen o cómo esa adaptación se hace, con qué frecuencia se hace, si hay algún control sobre los
cambios, y qué tan bien las metodologías de trabajo adaptadas funcionaron.
La investigación sobre el uso de metodología en su mayor parte se limita a los estudios que comparan
un pequeño número de metodologías. Sin embargo, a pesar los diferentes métodos o modelos
existentes, las diferencias entre ellos son leves y a menudo no más de semántica en la naturaleza. Por
esa razón, este estudio no se ocupará de la metodología o método específico, sino que examina el uso
en general.
3.3.- Método de investigación.
Para abordar el enfoque de esta investigación de la naturaleza del uso de la metodología se utilizaron
dos enfoques. Un cuestionario que fue utilizado para obtener una visión amplia del estado de utilizar la
metodología en las organizaciones en todos los EE.UU... Aunque las encuestas han sido el método
dominante de investigación para examinar el uso y adaptación de las metodologías, las encuestas en el
mejor de los casos también proporcionan una instantánea de cómo utilizar la metodología. Para entender
las motivaciones para el uso particular, o la adaptación de metodologías en contextos particulares, un
enfoque más profundo se necesita. Con este fin, se realizaron entrevistas en cuatro organizaciones.
El cuestionario fue distribuido a los responsables de SI de setecientas organizaciones de América del
Norte. El cuestionario incluyó preguntas sobre el tipo de metodología de desarrollo utilizada, las
características más útiles de la metodología y el grado de utilización de la metodología. De todas las
organizaciones contactadas se recibieron respuestas de 132 es decir (19%) El tamaño de las
organizaciones que van desde personal de desarrollo de aplicaciones de SI, de menos de 10 a más de
400 y presupuestos de operación que van desde varios cientos de miles a casi mil millones de dólares.
Mientras que el estudio proporciona una visión general del uso de metodologías de desarrollo en las
organizaciones de hoy, se necesita información adicional para comprender cómo las organizaciones
están utilizando y adaptando sus metodologías. Se realizaron entrevistas con los administradores y
desarrolladores de SI en cuatro organizaciones. Estos individuos se les pidió que describieran sus
metodologías de desarrollo y cómo fueron utilizados. Las personas en los distintos niveles de la gestión
fueron entrevistados para tratar de distinguir el desarrollo de procedimientos formales (es decir, cómo
deben hacerse las cosas) y el desarrollo de procedimientos reales (es decir, cómo las cosas realmente
se hacen). Esta investigación es un primer paso en la comprensión de la naturaleza de las metodologías
o métodos en uso y la medida en que se utilizan. Este ejemplo puede no ser representativo de las
organizaciones en general, ni sus experiencias. Pero es sólo a través de una base de datos de estas
experiencias que vamos a entender cómo son las metodologías en uso hoy en día y cuáles podrían ser
sus deficiencias.
3.4.- Metodología o método en uso.
3.4.1.- Resultados de la encuesta.
El cuestionario fue administrado a responsables de SI de 700 organizaciones de una amplia gama de
industrias en los Estados Unidos. Estas organizaciones fueron identificadas como los que utilizan una
metodología formal para el desarrollo de aplicaciones a partir de una muestra aleatoria de más de 1000
organizaciones. Debido a que el objetivo de este estudio es describir el uso de metodologías en las
organizaciones hoy en día, las organizaciones que no utilizan una metodología fueron retiradas de la
muestra. De los restantes 700 organizaciones, 132 cuestionarios fueron devueltos y utilizados, lo que
resulta en una tasa de respuesta del 19% de las organizaciones que respondieron que parecía ser
representativa de la muestra objetivo en términos del tamaño y ubicación de la industria.
Página 30
La primera parte de la encuesta dirigida a las características de las metodologías o métodos en uso.
Desde el enfoque del estudio no era determinar las metodologías individuales, las preguntas formuladas
el tipo general de la metodología y las características que las organizaciones identificadas como
importantes. En la Tabla 1, los porcentajes de de los tipos de metodologías más usadas. La gran
mayoría de las organizaciones están utilizando algún tipo de metodología estructurada.
Tabla N° 1 Tipos de las metodologías utilizadas
Tipo de Metodología o Método Porcentaje de las Organizaciones

Enfoque estructurado (SDLC) 76.5%
Prototipos / enfoque iterativo 7,6%
Desarrollo rápido de aplicaciones (RAD) 5,3 %
Orientado a objetos 0%
Otros 10,6 %
Las organizaciones se les preguntó cómo había adquirido su metodología. Aproximadamente el 35% de
las organizaciones informaron de que habían comprado su metodología. El 65% restante desarrollado su
metodología de las instalaciones.
En un intento por entender las fuerzas detrás de las decisiones que las organizaciones adopten
metodologías, una lista de las diez actividades relacionadas con el uso metodología fue desarrollada.
Esta lista fue compilada en base a un estudio de la literatura profesional y las discusiones con la práctica
de los desarrolladores de sistemas.
De esta lista, de directivos de SI que participaron en la encuesta se les pidió que identificaran las tres
características más importantes utilizados en la selección de sus metodologías de desarrollo y las tres
características más importantes que describen el uso de la metodología. Las tres características más
importantes tanto para la selección y el uso de la metodologías se estructuraron las técnicas de
desarrollo, bien definidas las políticas corporativas y procedimientos, y el intercambio de información
entre los desarrolladores. Las listas completas se presentan en la Tabla 2.
Es alentador ver la similitud entre las respuestas a las características de selección y las características
de uso. Parece que las metodologías son en realidad se utilizan para realizar las tareas para las que
fueron seleccionados. Sin embargo, más adelante en el estudio se pone de manifiesto que, si bien estas
organizaciones son capaces de utilizar las metodologías y las herramientas relacionadas para llevar a
cabo los tipos de actividades que consideran importantes (como el uso de técnicas estructuradas), que
no esté utilizando toda la metodología de hacer esto. La selección de las piezas en particular de la
metodología que se ajustan al proyecto de desarrollo particular, parece ser común. Las únicas
diferencias entre las dos clasificaciones fueron leves. Considerando que la utilización de herramientas
CASE para el diseño ha sido clasificado como el cuarto lugar en los criterios de selección, se trasladó a
la quinta posición en el ranking de uso, lo que parece indicar que, aunque las organizaciones de espera y
utilice las herramientas CASE para el diseño, en la práctica el uso de "documentos de diseño de
metodologías y herramientas de JAD se ha encontrado para ser particularmente útil
Tabla 2. Características más importantes de las metodologías.
Rango de Rango
Característica de la Metodología
Selección Usado
Utilizan técnicas de desarrollo estructurado 1 1
Cumplir bien con las políticas corporativas y procedimientos definidas 2 2
Compartir información entre los desarrolladores 3 3
El uso de herramientas CASE para el diseño de interfaz 4 5
Utilizan el desarrollo de aplicaciones en equipo (JAD) 5 4
Apoyo a la creación de un prototipo 6 6
Uso de herramientas CASE para la generación de código 7 7
Página 31
Uso de métodos orientados a objetos 8 8
5.- BIBLIOGRAFÍA.
5.1. http://www.google.co.ve/search?
as_q=cualidades+software&hl=es&num=10&btnG=Buscar+con+Google&as_epq=&as_oq=&as
_eq=&lr=&cr=&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=&as_rig
hts=&safe=images
5.2.- http://www.google.co.ve/search?
q=cualidades+software&hl=es&lr=&as_qdr=all&ei=ZL3JTOfpCYGClAeZ7YngCg&start=20
&sa=N
5.3.- http://bvs.sld.cu/revistas/aci/vol3_3_95/aci05395.htm
5.4.- http://www.uned.ac.cr/redti/tercera/documentos/articulo7.pdf
5.5.- http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software
5.6.- http://www.dosideas.com/noticias/metodologias/410-los-7-principios-del-desarrollo-
lean.html
5.7.- http://fundamentossistemas.blogspot.com/
5.8.- http://translate.google.co.ve/translate?hl=es&sl=en&tl=es&u=http%3A%2F
%2Fwww.andrews.edu%2F~vyhmeisr%2Fpapers%2Fsdm.html
5.9.-
Página 32

Gui A 2

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Gui A 2

Загружено:

Авторское право:

Доступные форматы

República Bolivariana de Venezuela Unidad Curricular:: INGENIERIA DE SOFTWARE I

Universidad Politécnica del Oeste Modulo: Fundamentos de Sistemas e Ingeniería de Software

UNIDAD Nº 2 FUNDAMENTOS DE LA INGENIERIA DE SOFTWARE.

TEMA N° 1.- EL SOFTWARE.

• Alcance las metas de la calidad;

• Supervisar los cambios en la calidad cuando se modifique el software;

1.3.- Un enfoque actual sobre la calidad del software.

1.4.- ¿Qué es la calidad del software?

1.5.- ¿Como obtener un software de calidad?

1.6.- ¿Cómo controlar la calidad del software?

2.- Atributos de calidad.

2.1.- Cualidades del software.

No observables en tiempo de ejecución

3.- Principios de la Ingeniería del Software.

3.2.- Rigor y formalidad.

3.3.- Separación de intereses.

sistema, la modularización apropiada ayuda a restringir la búsqueda de la fuente de error a componentes

3.6.- Anticipación al cambio.

también la reusabilidad de componentes, viendo la reusabilidad como evolucionabilidad de granularidad

TEMA N° 2.- VISION GENERAL DEL PROCESO DE DESARROLLO DEL SOFTWARE.

• Descripción general del Sistema, especificando claramente su funcionamiento.

2.- Principios, modelos, métodos, metodologías técnicas, actividades y herramientas en el

2.1.2.- Crear conocimiento.

• Enseñar métodos de resolución de problemas - los equipos de desarrollo deberían

2.1.3.- Embeber a la calidad.

2.1.4.- Postergar el compromiso.

2.1.5.- Optimizar el total.

2.1.6.- Entregar rápido.

2.1.7.- Respetar a las personas.

2.2.- Metodologías de desarrollo de software.

2.2.3.- Evolución de las Metodologías y/o métodos de desarrollo de software.

2.2.4.- Clasificación de las metodologías de desarrollo de software.

2.3.- Métodos o modelos de desarrollo de software usados actualmente.

• Desarrollo iterativo y creciente o Iterativo e Incremental

2.4.- Técnicas y herramientas usadas en el desarrollo de software.

2.4.2.- Análisis e interpretación de información.

2.4.3..- Observación y técnica Strobe.

2.4.4.- Herramientas CASE.

vi.- Automatizar, desarrollo del software, documentación, generación de código, pruebas de

I.- Problemas Candidatos

3.- Selección de la metodología, método o modelo apropiado para desarrollo de software.

desarrollo o en un subconjunto seleccionado de proyectos. Una pregunta relacionada con la gerencia es

Tipo de Metodología o Método Porcentaje de las Organizaciones

Uso de métodos orientados a objetos 8 8

Вам также может понравиться