Desarrollo de Sistemas

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 9

Desarrollo de sistemas

Ciclo de vida del desarrollo de sistemas

El desarrollo de sistemas es un proceso que consiste en dos etapas


principales de análisis y diseño de sistemas; comienza cuando la
gerencia, o en algunas ocasiones el personal de desarrollo de
sistemas, se da cuenta de cierto sistema del negocio necesita
mejorarse.

El ciclo de vida del desarrollo de sistemas es el conjunto de


actividades de los analistas, diseñadores y usuarios, que necesitan
llevarse a cabo para desarrollar y poner en marcha un sistema de
información. Se debe tener presente que en la mayoría de las
situaciones del negocio, las actividades están íntimamente
relacionadas y son inseparables.

El ciclo de vida del desarrollo de sistemas consiste en las siguientes


actividades:

1. Investigación preliminar

2. Determinación de requerimientos

3. Desarrollo de sistema prototipo

4. Diseño de sistema

5. Desarrollo de software

6. Prueba de los sistemas

7. Puesta en marcha

Investigaciones preliminares

PUBLICIDAD
¿Cuantas veces se está en situaciones en donde se pregunta si no
existe una mejor manera de hacer algo? Por ejemplo, abrir una
tienda departamental adicional que creará una necesidad para
nuevos procedimientos de facturación, cuando un alto porcentaje de
clientes utiliza la cuenta de crédito de esta compañía de esta
compañía y compra en todas las tiendas. Duplicar el número de
clientas para agrandar las instalaciones y la introducción de muchos
nuevos productos, puede traer nuevos requerimientos de pago e
cuentas. Un cambio en las áreas de los gerentes departamentales
puede guiarlos hacia nuevas formas para registrar las ventas, con
implicaciones para el sistema de entrada de pedidos basado en
computadora. Una compañía en crecimiento, puede contemplara los
sistemas de información computarizados como una forma para
hacer posible el crecimiento continuo, sin tener dificultades en el
proceso de los pedidos de los clientes.

Se puede inicias una petición por muchas razones, pero la clave es


que alguien, ya sea gerente, un empleado o un especialista de
sistemas, inicie un requerimiento para recibir ayuda de un sistema
de información. Cuando ese requerimiento se realiza, la primera
actividad de sistemas, es decir, la investigación preliminar, se inicia.
Esta actividad tiene tres partes: clasificación de requerimiento,
estudio de la factibilidad y aprobación del requerimiento. El
resultado será aprobar el requerimiento para la atención posterior o
rechazarlo como no factible para un desarrollo futuro.

Clarificación del requerimiento

En las empresas muchos requerimientos de los empleados y


usuarios no están establecidos claramente; por lo tanto, antes de
que pueda considerarse la investigación del sistema, le proyecto
requerido debe examinarse para determinar para determinar
precisamente lo que desea la empresa. Una simple llamada
telefónica puede ser suficiente si la persona que requiere el servicio
tiene una idea clara, pero no sabe cómo establecerla. Por otro lado,
la persona que hace el requerimiento puede estar simplemente
pidiendo ayuda sin saber qué es lo que está mal o por qué existe un
problema. La clarificación del problema es este caso, antes de
poder llagar a otro paso, el requerimiento de proyecto debe estar
claramente establecido.

Estudio de Factibilidad

Un resultado importante de la investigación preliminar es la


determinación de que el sistema requerido es factible. Existen tres
aspectos en el estudio de factibilidad de la investigación preliminar:

1. Factibilidad técnica. ¿Puede realizarse el trabajo para el proyecto


con el equipo actual, tecnología de software y el personal
disponible? Si se requiere nueva tecnología, ¿qué probabilidades
hay de que pueda desarrollarse?

2. factibilidad económica. ¿Existen suficientes beneficios en la


creación del sistema para hacer que los costos sean aceptables? O,
en forma inversa, ¿son tan altos los costos como para que el
proyecto no deba llevarse a cabo?

3. Factibilidad operativa. ¿Se utilizará el sistema si se desarrolla y


pone en marcha? Habrá resistencia de los usuarios, que los
posibles beneficios reducirán del sistema.

El estudio de factibilidad se lleva a cabo con un pequeño grupo de


gente, familiarizada con las técnicas de los sistemas de información,
que entienden la parte de la empresa que será afectada por el
proyecto y tienen los conocimientos suficientes del proceso de
análisis y diseño de sistemas.

Aprobación del requerimiento

No todos los proyectos requeridos son deseables o factibles. Sin


embargo, aquellos que son tanto factibles como deseables deben
anotarse para tomarlos en cuenta. En algunos casos, el desarrollo
puede comenzar inmediatamente, pero en la mayor parte, los
miembros del departamento de sistemas están ocupados en otros
proyectos que se encuentran en marcha. Cuando esto sucede, la
gerencia decide que los proyectos son más importantes y entonces
los programas. Después de que se aprueba la requisición de un
proyecto, se estima su costo, la prioridad, el tiempo de terminación
y los requerimientos del personal que se utilizan, para determinar
qué lista existente los proyectos se incluirá.

Posteriormente, cuando se terminan algunos proyectos anteriores,


puede iniciarse el desarrollo de la aplicación propuesta. En este
momento, comienza la recabación de datos y la determinación de
los requerimientos.

Determinación de requerimientos

El punto clave de análisis de sistemas se consigue al adquirir un


conocimiento detallado de todas las facetas importantes dentro del
área de negocios que se investiga. (Por esta razón, a menudo esta
actividad se conoce como investigación detallada.) Los analistas, al
trabajar con los empleados y gerentes, deben estudiar el proceso
que actualmente se efectúa para contestar estas preguntas clave:

1. ¿Qué se está haciendo?

2. ¿Cómo se está haciendo?

3. ¿Qué tan frecuentemente ocurre?

4. ¿Qué tan grande es la cantidad de transacciones o decisiones?

5. ¿Qué tan bien se lleva acabo la tarea?

6. ¿Existe algún problema?

7. ¿Si el problema existe, qué tan serio es?

8. ¿Si el problema existe, cuál es la causa principal?

Para contestar estas preguntas, los analistas de sistemas hablarán


con diferentes personas para recabar los detalles en relación con el
proceso, así como sus opiniones sobre las causas por las cuales
suceden las cosas de esa manera y algunas ideas en relación a
modificarlas. Se utilizan cuestionarios para recopilar esta
información, aplicándolos a grandes que no pueden entrevistarse en
forma individual. Las investigaciones detalladas también requieren
el estudio de manuales y reportes, la observación real de las
actividades de las actividades de trabajo y algunas veces la
recabación de formas y documentos para entender completamente
el proceso.

Conforme se recopilan los elementos, los analistas estudian los


requerimientos de datos para identificar las características que
tendrá el nuevo sistema, incluyendo la información que el sistema
debe producir y las características operativas, como son controles
de procesamiento, tiempos de respuesta y métodos de entrada y
salida.

Desarrollo del sistema prototipo

La preparación de prototipos es el proceso de crear, desarrollar y


refinar un modelo funcional del sistema final. Se puede crear
un modelo prototipo preliminar durante la etapa de definición del
problema. Un miembro del equipo de reconocimiento -suponga que
se trata de un especialista en el procesamiento de datos- puede
construir un modelo de este tipo que muestre la composición de las
pantallas y los formatos de los informes. Durante una sesión de
requerimientos, otros miembros del equipo y usuarios del futuro
sistema examinan esta muestra en la forma con el constructor del
modelo entiende en principio el problema y los resultado que debe
producir el sistema. En este momento puede iniciarse un proceso
de refinación si los usuarios señalan omisiones y equivocas.

Durante este proceso de refinación, cuyo objetivo es definir la


necesidad que existe, uno o más miembros del equipo pueden
utilizar una computadora personal y un paquete de programas de
prototipos a fin de crear una serie de pantallas en la computadora
personal. Estas pantallas no son las salidas que producen los
programas ya terminados, pero pueden parecerse mucho a esos
resultados. Es posible exhibir en el monitor de la computadora,
como una secuencia de diapositivas, menús de captura de datos, la
interfaz con el usuario debe servir para buscar, consultar y
manipular datos y el formato de los informes de salida. Por ejemplo,
se pueden simular los resultados de una serie de selecciones
hechas en menús para que los usuarios tengan una idea más clara
de la forma como el constructor o los constructores del sistema
están interpretando el problema. Si los usuarios no están
convencidos de lo que se exhibe define con precisión sus
necesidades, pueden modificar fácilmente las plantillas prototipo
hasta que estén satisfechos. La creación de un modelo preliminar
de prototipo en este punto produce varios beneficios: los usuarios
pueden ver que se está avanzado, se les motiva para que participen
activamente en la definición del problema, se mejora la
comunicación 4entre todas las partes interesadas y se aclaran los
equívocos en una etapa temprana del estudio de sistemas, antes de
que se conviertan en costosos errores.

Como se acaba e ver, puede ser necesario un proceso repetitivo


(o interactivo) para terminar el paso de definición del problema. No
existe un procedimiento definido que se deba seguir antes de que
se pueda iniciarse el análisis detallado del sistema. Un alto ejecutivo
puede creer que existen diferencias de información. Puede preparar
una declaración general de los objetivos y nombrar a un gerente
para que realice un reconocimiento. Pueden realizarse varias
sesiones de requerimientos para traducir los deseos generales a
objetivos más específicos. Asimismo, pueden crearse y refinarse
modelos preliminares de prototipo; se puede ampliar o reducir el
alcance del estudio y es posible también que cambien los objetivos
conforme se reúnan los datos. Una vez que parezca haberse
logrado la aprobación en cuanto a la definición del problema, el
equipo de reconocimiento deberá poner la definición detallada por
escrito y enviarla a todas las personas interesadas, las cuáles
deberán aprobarla también por escrito. Si persisten diferencias,
deberán resolverse en sesiones adicionales de requerimientos. Hay
quienes se impacientan con los “retrasos” en el desarrollo del
sistema causados por estas sesiones adicionales. Sin embargo, las
personas más prudentes saben que los retrasos verdaderamente
largos y costosos se presentan cuando los usuarios descubren, ya
muy avanzados el proceso del desarrollo, que el sistema diseñado
no es satisfactorio por haberse pasado por alto algunos
requerimientos.

Diseño del sistema

El diseño de un sistema de información produce los elementos que


establecen cómo el sistema cumplirá los requerimientos indicados
durante el análisis de sistemas. A menudo los especialistas de
sistemas se refieren a esta etapa como en diseño lógico,
encontraste con desarrollo del software de programas, que se
conoce como diseño físico.

Los analistas de sistemas comienzan por identificar los informes y


otras salidas que el sistema producirá. A continuación los datos
específicos con éstos se señalan, incluyendo su localización exacta
sobre el papel, la pantalla de despliegue u otro medio. Usualmente,
los diseñadores dibujan la forma o la visualización como la esperan
cuando el sistema esta terminado.

El diseño del sistema también describe los datos calculados o


almacenados que se introducirán. Los grupos de datos individuales
y los procedimientos de calculo se describen con detalle. Los
diseñadores seleccionan las estructuras de los archivos y los
dispositivos de almacenamiento, como son discos magnéticos,
cintas magnéticas o incluso archivos en papel. Los procedimientos
que ellos escriben muestran cómo se van a procesar los datos y a
producir la salida.

Los documentos que contienen las especificaciones de diseño


utilizan muchas formas para representar los diseños, diagramas,
tablas y símbolos especiales, algunos de los cuales el lector puede
haber utilizado ya y otros que pudieran ser totalmente nuevos. La
información del diseño detallado se pasa al grupo de programación
para que pueda comenzar el desarrollo del software.

Los diseñadores son responsables de proporcionar a los


programadores las especificaciones completas y escritas con
claridad, que establezcan lo que debe hacer el software. Conforme
comienza la programación, los diseñadores están pendientes para
contestar preguntas, esclarecer ideas confusas y manejar los
problemas que confronten los programadores cuando utilicen las
especificaciones de diseño.

Desarrollo del Software

Los desarrollares del software pueden instalar o modificar; por


ejemplo, software comercial que se haya comprado, o pueden
escribir programas nuevos diseñados a la medida. La decisión de
qué se va a hacer depende del costo de cada una de las opciones,
el tiempo disponible para describir el software y la disponibilidad de
programadores. En forma usual, en las grandes empresas los
programadores de computadoras (o la combinación de analistas-
programadores) son parte del grupo profesional permanente. Las
compañías más pequeñas en donde los programadores
permanentes no se han contratado, pueden obtener servicios
externos de programación con base en un contrato.

Los programadores también son responsables de documentar el


programa e incluir los comentarios que expliquen tanto cómo y por
qué se utilizo cierto procedimiento conforma se codifico de cierta
forma. La documentación es esencial para probar el programa y
darle mantenimiento una vez que la aplicación se ha puesto en
marcha.

Prueba de los sistemas

Durante la prueba, el sistema se utiliza en forma experimental para


asegurar que el software no falle; es decir, Que corra de acuerdo a
sus especificaciones y a la manera que los usuarios esperan que lo
haga. Se examinan datos especiales de prueba en la entrada del
procesamiento y los resultados para localizar algunos problemas
inesperados. Puede permitirse también a un grupo limitado de
usuarios que utilice el sistema, de manera que los analistas puedan
captar si tratan de utilizarlo en forma no planeadas. Es preferible
detectar cualquier anomalía antes de que la empresa ponga en
marcha el sistema y dependa de él.
En muchas compañías la prueba se lleva a cabo por personas
diferentes a aquellos que los escriben en forma original; es decir si
se utilizan personas que no conocen como se diseñaron ciertas
partes de los programas, se asegura una mayor y más completa
prueba, además de ser imparcial, lo que da a un software más
confiable.

Puesta en marcha

Cuando el personal de sistemas verifica y pone en uso el nuevo


equipo, entrena al personal

usuario; instala la nueva aplicación y constituye los archivos de


datos que se necesiten, entonces el sistema está puesto en
marcha.

De acuerdo con el tamaño de la empresa que empleará la


aplicación y el riesgo asociado con su uso, los desarrolladores del
sistema pueden escoger una prueba piloto para la operación del
sistema solamente en un área de la compañía; por ejemplo, en un
departamento o sólo con una o dos personas. A veces correrán en
forma paralela tanto el sistema anterior como el nuevo para
comparar los resultados de ambos; en otras situaciones, los
desarrolladores pararán por completo el sistema anterior un día y al
siguiente empezarán a utilizar el nuevo. Como se puede apreciar,
cada estrategia para la puesta en marcha tiene sus méritos, que
dependen de la situación del negocio considerado. Sin importar la
estrategia para la puesta en marcha que se haya utilizado, los
desarrolladores tendrán que asegurarse que el uso inicial del
sistema esté libre de problemas.

Una vez instalada, con frecuencia la aplicación se utiliza por


muchos años; sin embargo, tanto la empresa como los usuarios
cambiarán, y el medio ambienta será diferente también a través del
tiempo. Por lo tanto, la aplicación indudable mente necesitará
mantenimiento; es decir, se harán cambios y modificaciones al
software, y a los archivos o procedimientos para cubrir los
requerimientos nuevos de los usuarios.

Los sistemas de la empresa y el medio ambiente de los negocios


están en continuo cambio. Los sistemas de información deben
mantenerse de la misma forma; es este sentido, la propuesta en
marcha es un proceso continuo.

También podría gustarte