Diseño

En esta etapa se debe proporcionar una estructura a todos los elementos reunidos durante el
análisis. En general se distinguen dos subetapas en el proceso de diseño.

Diseño Lógico: se debe obtener un modelo del sistema apoyado en alguna técnica
gráfica que sirva de comunicación entre los usuarios y desarrolladores del sistema. El modelo debe
ser una representación que todos puedan entender y compartir. El apelativo de lógico se refiere a
que en esta etapa el diseño debe llevarse a cabo en forma totalmente conceptual, independiente de
las restricciones físicas. Para cumplir con este objetivo se utiliza la técnica de Diagrama de
Flujo de Datos, que es una técnica de diseño Top-Down (de arriba hacia abajo), que permite partir
de un diseño muy general y proseguir secuencialmente aumentando el nivel de detalle.

Documentación de un Proceso

Proceso : 3
Descripción : Calcular impuestos
Objetivos : Calcular impuesto único correspondiente a cada trabajador.
Tareas : Tomar el sueldo bruto, restarle lo correspondiente a leyes
sociales y obtener la renta imponible. Luego, buscar en la tabla
de impuesto único el factor a aplicar, calcular las rebajas y
determinar el monto a deducir.
Entradas : Sueldo bruto, valor UTM, Tabla de impuesto único, monto
deducido por leyes sociales.
Salidas : Renta imponible, monto a pagar por concepto de impuesto
único
Observaciones : Proceso que cambia cada mes con las tablas de impuesto único,
actualmente efectuado en forma manual.

Documentación de un Archivo

Archivo # : D1
Nombre : Archivo de Trabajadores
Contenido : Información de cada trabajador en la empresa.

Atributos
Nombre Tipo Largo Observaciones
Nombres A 20 Primer y segundo nombre
Apellido Paterno A 12
Apellido Materno A 12
RUT AN 12 nn.nnn.nnn-d
Domicilio A 50 calle número, población y comuna
Número de cargas N 2 Cargas familiares
Fecha de Contrato F 8 Fecha de incorporación dd/mm/aa
Especialidad A 20 Profesión o especialidad .
 Diseño Físico: se definen los detalles requeridos para poder construir el S.I.,
en esta etapa se compromete el diseño con aspectos materiales, deja de ser algo
conceptual.

En general el diseño físico debe pasar en forma secuencial por las

siguientes partes:

a. Diseño de las salidas: se define la forma exacta de los informes, listados

pantallas, documentos que el sistema deba generar, su contenido
(atributos) y las características de los datos, extensivos o resumidos, se
especifica el medio en el cual se generará cada salida y se debe adjuntar
una muestra de cada una de ellas.
b. Diseño de entradas: Esta tarea requiere especificar los registros que se
utilizarán, los registros de donde serán extraídos, el medio de
almacenamiento donde se encuentren esos registros o el dispositivo a
través del cual se obtendrán las entradas en caso de que no estén
almacenadas (teclado, lector óptico, sensor, etc.)
c. Diseño de los procesos computacionales: define la transformación a que
se someten las distintas entradas para generar sus salidas particulares.
Comprende la especificación de los procesos de validación, de las
fórmulas o cálculos que se efectúen, la especificación de los archivos
temporales que se generan y la descomposición del proceso en todos sus
módulos.
d. Diseño de os archivos: incluye la identificación de los tipos de procesos:
entrada de datos, mantención, generación de informes, consultas, etc..
Describe también la identificación de los puntos de control para la
auditoría del sistema, el manejo de documentos, la periodicidad de cada
proceso, las actividades manuales que se realizan o requieren para el
funcionamiento del sistema, y un diagrama que indique la secuencia de los
pasos que deben seguirse.

Paralelamente a lo anterior en esta etapa se requiere desarrollar el proceso de selección de

tecnologías que no es un proceso trivial y debe ser realizada en forma cuidadosa teniendo
presente los siguientes criterios:

 Identificación del costo total de la tecnología a utilizar, se deben

identificar todos los costos (infraestructura, instalación, configuración,
capacitación, mantención, soporte posterior etc.).
 Identificar muy bien por qué y para qué se está adquiriendo determinada
tecnología, esto tiene la finalidad de intentar eliminar elementos subjetivos
o emocionales en la evaluación.
 Incorporar elementos relacionados con el proveedor y su calidad y tipo de
servicio.

La selección debe ser cuidadosa y con una perspectiva y orientación al negocio.

Construcción

Una vez que el sistema ha sido diseñado, está listo para ser construido y este proceso
comprende dos etapas:

Programación: que es la generación de instrucciones, mediante algún software

adecuado que puede ser un lenguaje de programación o un lenguaje de especificación, un generador
de programas, etc.
Prueba: esto consiste en la ejecución de las instrucciones codificadas durante la
programación, en base a entradas simuladas (con datos reales o ficticios) para chequear el correcto
funcionamiento del sistema. El resultado permite la inmediata corrección de los errores.

Conversión o Implementación del Sistema

En esta etapa se debe definir cuándo y en qué forma se va a introducir el nuevo sistema lo
que genera un clima de gran expectativa junto con una gran carga de trabajo ya que esto se debe
desarrollar en forma simultanea con las actividades propias del negocio

La conversión se refiere al momento en que el nuevo sistema reemplaza al que operaba

antes. Por su parte implantación significa la instalación y puesta en marcha de los nuevos equipos y
procedimientos que el sistema conlleva.

Existen varias formas alternativas para la conversión y son:

Paralelo: se requiere que tanto el sistema antiguo como el nuevo sean llevados en
forma simultanea durante cierto período de tiempo. El objetivo de esto es verificar
el funcionamiento del sistema nuevo con el antiguo, es ideal para sistemas de nivel
operacional. Su inconveniente es que requiere un alto esfuerzo en RRHH y
técnico, lo que aumenta los costos y la carga de trabajo con una posible extensión
del período de conversión.

Sistema Nuevo

Sistema Antiguo

Gradual: en este método el sistema nuevo va reemplazando paulatinamente las

actividades del antiguo, lo que minimiza el impacto organizacional derivado del
cambio y evitando algunos riesgos. El inconveniente es que no todas las
 aplicaciones son posibles de convertir en forma gradual ya que requiere
actividades divisibles y una comunicación entre ambos sistemas, lo que en algunos
casos es muy cara.

Sistema Antiguo Sistema Nuevo

Plan Piloto: se convierte al nuevo sistema sólo a una parte de la organización,

departamento, funciones, etc. quedando el resto bajo el sistema antiguo. La clave
es que el segmento donde se aplica el nuevo sistema sea representativo. El riesgo
es que el plan piloto se confunda con un testeo del nuevo sistema.

Sistema Antiguo Sistema Nuevo

Conversión Abrupta: esto requiere planificar muy bien la conversión para

reemplazar en un periodo corto de tiempo el sistema antiguo por el nuevo en toda
la organización. Su mayor ventaja son los costos bajos y el aspecto sociológico del
cambio, todos se involucran por sacar adelante el sistema, ya que no hay otro. El
problema son los errores y su tiempo de solución. Este tipo de conversión es ideal
para aplicaciones de bajo impacto organizacional.

Sistema Nuevo

Sistema Antiguo

Explotación Operación y Mantención

Todo sistema se desempeña en un entorno dinámico, debe ser sujeto a ciertos cambios para
adaptarlo a las situaciones del entorno que requieran modificar su proceso de transformación de
información, todas estas variaciones menores, permiten mantenerlo en operación permanente.
Evaluación

Con el objeto de medir el grado de satisfacción de sus usuarios y verificar si cumple sus
objetivos, todo sistema debe someterse a una evaluación que permita tomar medidas correctivas
oportunamente, esto especialmente si el sistema es nuevo.

Un sistema debe evaluarse cada 6 meses especialmente después de su conversión para así
detectar necesidades de mayor capacitación, entrenamiento o actitudes negativas.

Si la evaluación determina la necesidad de efectuar cambios significativos en un sistema, se

inicia este cambio con un estudio de factibilidad o con el desarrollo de un sistema distinto.

Problemas Ciclo de vida Clásico del Software. (o Desarrollo Tradicional)

1.- Los proyectos reales raramente siguen el flujo secuencial que propone el modelo

2.- Normalmente el cliente no puede establecer explícitamente todos los

requerimientos.

3.- El cliente sólo podrá ver el programa operativo al final del proyecto.
(eventualmente podría haber un error en este punto, lo que implicaría un desastre para
el software.)

Alternativas al Desarrollo Tradicional de Sistemas

Las alternativas al desarrollo tradicional de sistemas surgieron como una forma de paliar el
exceso de demanda en el desarrollo de sistemas (“backlog”: retraso en el desarrollo de nuevas
aplicaciones, carga de trabajo acumulada) y como una forma de sobrepasar las limitaciones del
desarrollo tradicional en términos de tiempo, costo e Ineficiencias en la especificación de
requerimientos y en la traducción de ellos a un diseño.

Los enfoques alternativos que se analizaran serán los siguientes:

 Compra de software envasado,

 Desarrollo mediante prototipos (esta es una forma de hacer SW,)
 Desarrollo por usuarios finales
 Externalización ( Outsourcing )

Compra de Software Envasado

Este enfoque también es conocido como compra de paquetes de software, se basa en que las
empresas poseen una variedad de aplicaciones computacionales en cierta forma parecidas. Por lo
tanto es posible beneficiarse de las economías de escala logradas al desarrollar S.I. que pueden
utilizarse en varias empresas al mismo tiempo. Cada vez que se instale en una empresa adicional se
reducirá en forma significativa el costo unitario del S.I., llegando a ser una fracción del costo
original.

Otro factor que hace esta alternativa recomendable es el grado de especialización que se puede
obtener dado que existen empresas que se especializan en determinado software, contando con
recurso humano de buena calidad y además como el paquete se ha instalado en varias oportunidades
generalmente se encuentra libre de errores.

Cabe considerar que cuando la empresa desarrolla software, lo hace pensando en la forma de darle
flexibilidad para que se adapte a diferentes compañías, este elemento es favorable para la compañía
que lo adquiere, pues la flexibilidad implica que se puede adaptar a condiciones particulares y a
cambios en el entorno en que opera.

Ventajas de esta alternativa:

 Los costos de desarrollo comparados con un proceso interno disminuyen

considerablemente. (el diseño consume app. 50% del esfuerzo de desarrollo)
 La prueba puede efectuarse en un periodo muy corto de tiempo.
 La implementación es apoyada por el proveedor con métodos y herramientas ya
probadas y seguras en tiempos cortos.
 La mantención es responsabilidad del proveedor. Esto implica asegurar que este
en el contrato de compra.
 La documentación esta disponible y ya ha pasado por diferentes controles de
calidad.

La decisión de comprar un paquete de software no es una decisión fácil ya que a menudo el sistema
no calza exactamente con los requerimientos y entonces se debe comparar el costo de modificar el
paquete, con el costo de adaptar la empresa al paquete y con el de desarrollar un sistema ad-hoc.

Desarrollo mediante prototipos

El concepto de prototipo se usa desde hace una o dos décadas en el área de la arquitectura,
diseño, decoración, en la industria automotriz, etc. En esencia, consiste en desarrollar en forma
rápida y burda un modelo, un primer sistema que funcione, para luego proceder a su
perfeccionamiento. Es como lograr un “borrador” de un sistema para luego pasarlo en “limpio” a
medida que va siendo utilizado. La versión definitiva se obtiene cuando alguna de las versiones
cumple con la especificación de requerimiento y/o cuando el usuario final de su aceptación.

El desarrollo mediante prototipos ataca de frente a una de las debilidades mayores del
enfoque tradicional: la definición de los requerimientos de información. Particularmente cuando se
trata de funciones poco estructuradas, donde el usuario rara vez tiene claro qué desea del sistema. En
general, sólo tiene una noción vaga de sus necesidades , sin poder describir en forma completa sus
requerimientos en un papel. Además, el prototipo, da lugar y se anticipa a las necesidades
cambiantes de los usuarios ya que las modificaciones pueden incorporarse rápidamente y sin
mayores costos durante las primeras etapas del desarrollo.
 Un desarrollo de prototipos es deseable cuando existe cierta incertidumbre a cerca de los
requerimientos de información o sobre los diseños que solucionarán el problema. Esta se presenta
generalmente en aplicaciones orientadas a la toma de decisiones, sin requerimientos específicos
claros o cuando estos pueden cambiar sustancialmente en tanto la implementación progrese.

Para desarrollar un prototipo se requieren dos personas: un usuario interesado en contar con
un sistema y dispuesto a trabajar duro y un analista con experiencia en un software de alto nivel,
quien habitualmente domina el uso de alguna herramienta CASE (Comp. Aided Software
Engineering), que permite automatizar el diseño de sistemas de información, facilitan el desarrollo
de aplicaciones y acortan el tiempo de construcción del sistema de información, a costa de un uso
intensivo del equipamiento computacional. Una vez con estos dos individuos y el hardware y el
software necesario, se procede con las etapas que se observan en la figura.
 Identificar
Requerimientos
Básicos
de Información

Desarrollar
Un Primer
Prototipo

Utilizar el
Prototipo para
Refinar la Definición
De Requerimientos

Revisar y
Ampliar
El Prototipo

La primera etapa, identificación de los requerimientos básicos de información, no debe

prolongarse por más de una o dos reuniones. Tiene por objetivo:

 Discutir el proceso para desarrollar el sistema a través de prototipos

 Escribir una breve declaración que sintetice las características esenciales de los
requerimientos de información del usuario
  Listar los datos que serán utilizados y sus interrelaciones

 Determinar la disponibilidad de los datos requeridos

 Estimar el plazo requerido y el costo para desarrollar un prototipo final (operacional)

 Considerar los posibles usos del prototipo final

El usuario debe asumir durante ésta y las siguientes etapas un rol activo de diseñador del sistema,
que debe expresar sus necesidades de información en base a salidas esperadas del sistema. Durante
toda esta etapa ambas partes, usuario y analista, deben procurar mantener tanto el sistema como las
estructuras de datos en un nivel simple.

El objetivo de la segunda etapa, construcción del primer prototipo, es armar una primera versión que
funcione en base a los requerimientos básicos expresados por el usuario. Por definición este primer
modelo debe actuar en forma interactiva y entregarle las salidas indicadas en la etapa anterior. Toda
la responsabilidad y el trabajo de esta etapa recaen sobre el analista. La interfaz entre el prototipo y
el usuario debe ser lo suficientemente simple y amigable para no inhibirlo durante su prueba y
utilización.

En la etapa tres se utiliza el prototipo con el objeto de refinar la definición de requerimientos de

información. Al final de la etapa precedente el analista entrega al usuario un prototipo funcionando.
Ahora es responsabilidad del usuario desarrollar una experiencia de tipo práctico con el modelo para
tratar de comprender mejor sus verdaderas necesidades de información. Durante este proceso el
usuario va identificando qué cosas son las que le gustan y cuáles son las que le desagradan . El
analista debe captar estas impresiones y hacer que el usuario redefina sus requerimientos de
información.

El propósito de la etapa cuatro, revisar y ampliar el prototipo, es corregir en el modelo inicial

aquellas características no deseables o faltantes, detectadas por el usuario en la etapa anterior. La
responsabilidad sobre esta etapa es del analista.

En general se debe producir una iteración entre las dos últimas etapas que permita refinar las
versiones hasta conseguir la aprobación del usuario. Esta última versión se denominará prototipo
operacional y permanecerá en estas condiciones hasta que cambios en el entorno exijan aplicar
nuevos cambios sobre él.

El desarrollo de prototipos se diferencia del desarrollo tradicional en tres aspectos fundamentales:

 Las especificaciones del sistema son producidas por el propio prototipo y los usuarios
pueden ver el resultado y realizarle repetidas modificaciones. En cambio con el
desarrollo tradicional la especificación es un proceso largo donde el usuario no está
seguro de qué está probando.

 La calificación y prueba del sistema son hechas en forma relativamente rápida y barata
con el desarrollo por prototipos respecto al tradicional.
  La documentación puede ser en parte automatizada con esta metodología alternativa, lo
que disminuye el tiempo y el esfuerzo requerido en el desarrollo no tradicional.

Hoy en día, el avance tecnológico y la disminución de los costos del Hardware permiten utilizar el
desarrollo mediante prototipos natural y masivamente.

Enfoque de desarrollo por usuarios finales

El desarrollo por usuarios finales implica que, mediante el uso de herramientas amistosas,
éstos consignan acceder a datos, crear reportes y ejecutar su propio procesamiento de información.
Un sistema completo puede ser construido por un solo usuario final, sin analistas de sistemas o
programadores . En forma alternativa, los usuarios finales pueden apoyarse en los especialistas de
informática para el soporte técnico, pero ejecutar solos la mayoría de las actividades de desarrollo.

Este enfoque es altamente atractivo para los usuarios, pues les permite comenzar un sistema
tan pronto como la necesidad se haga presente. El tiempo de desarrollo es generalmente breve, ya
que la etapa de análisis y diseño son una sola para el usuario-desarrollador, quien no requiere
comunicar a nadie sus necesidades. Generalmente se logra un alto grado de satisfacción y sensación
de logro al implementar el sistema de información.

Los mayores inconvenientes de este enfoque son: lleva a un excesivo uso de recursos
computacionales; los usuarios no siguen los mejores procedimientos de desarrollo, lo cual puede
llevar a sistemas poco eficientes, sin mecanismos de control ni auditoría y a menudo con fallas; los
sistemas generalmente son intransferibles, ya que rara vez se documentan y sólo se adaptan a la
idiosincrasia particular de quien los desarrolló.

Metodología para evaluar la factibilidad de los diversos enfoques

Cada una de las estrategias de desarrollo analizadas tienen sus pro y sus contra, y podrían
aplicarse para resolver un mismo problema. No obstante, cada problema a solucionar tiene ciertas
características que facilitan la elección de una estrategia o de otra, las cuales se describen a
continuación:

 Particularidad de la aplicación,

 Grado de impacto para la organización, y

 Estructuración implícita del proceso.

La particularidad de la aplicación se refiere al grado de originalidad o exclusividad que tiene un
determinado sistema y a la dificultad para encontrar requerimientos similares en otras empresas. De
ser esto así, es altamente probable que no se encuentren paquetes desarrollados con este fin en el
mercado.

El grado de impacto que el sistema tendrá en la organización define el rol que le cabe cumplir a los
profesionales de informática. En general, mientras más importante sea el sistema de información
para la empresa, mayor necesidad hay de que el personal de informática participe en el desarrollo
del sistema y asegure su calidad y mecanismo de control. Por el contrario, cuando se estima que el
sistema de información tendrá un efecto menor en la organización, resultará difícil justificar la
participación y el costo asociado a los especialistas de informática.

La tercera característica del sistema de información se refiere a su estructuración. Esta se define

como el grado de conocimiento y determinismo que se tiene sobre un problema y su solución. Esta
propiedad es particularmente importante para determinar la factibilidad de usar el enfoque de
prototipos, debido a lo iterativo de su proceso y al grado de participación requerida del usuario.

Estas tres propiedades de los sistemas de información pueden ilustrarse como aparecen en la
siguiente figura, donde cada una de ellas da origen a un eje y permiten visualizar el sector más
apropiado para cada una de ellas.

PARTICULARIDAD

Compra de Software
Baja Envasado

Desarrollo
Tradicional

Alta Alto
Desarrollo por
Usuarios Finales
Prototipo
Alta Baj
Baja o
IMPACTO
ESTRUCTURA

En consecuencia, cuando el problema y su solución son comunes a un gran número de

organizaciones, debería optarse por un paquete envasado, especialmente cuando la tarea implícita
puede considerarse suficientemente estructurada. En caso contrario, un desarrollo de carácter
tradicional puede ser recomendable. Por otra parte, la modalidad de desarrollo de usuarios finales es
susceptible siempre y cuando el impacto organizacional del sistema de información sea poco
importante. Finalmente, el uso de prototipos adquiere sus mayores ventajas en los casos en que el
problema es poco estructurado, independientemente de lo que ocurra con las otras características.