1. CICLO DE VIDA DE UN SISTEMA DE INFORMACION
El método de ciclo de vida para el desarrollo de sistemas es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información. El método del ciclo de vida para el desarrollo de sistemas consta de 6 fases:
1). Investigación Preliminar: La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona.
2). Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:
¿Qué es lo que hace?
¿Cómo se hace?
¿Con que frecuencia se presenta?
¿Qué tan grande es el volumen de transacciones o decisiones?
¿Cuál es el grado de eficiencia con el que se efectúan las tareas?
¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo origina?
3). Diseño del sistema: El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.
4). Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores. Los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.
5). Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.
6). Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses.
Es indudable que debe darse mantenimiento a las aplicaciones. La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:
*Evaluación operacional: Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización.
*Impacto organizacional: Identificación y medición de los beneficios para la organización en áreas tales como finanzas, eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información externo e interno.
*Opinión de los administradores: evaluación de las actividades de directivos y administradores dentro de la organización así como de los usuarios finales.
*Desempeño del desarrollo: La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo.
2. Secciones de Fijación de Objetivos
Cuando se realiza la planificación de un proyecto, indistintamente del tipo de proyecto, el primer paso es la fijación de objetivos. De allí pues que:
El primer paso en el establecimiento de los objetivos de un proyecto, es contemplar el mecanismo que se utilizaría para modificar los objetivos, en caso de necesidad. Este mecanismo debe ser ágil, y coherente con las formas y normas para manejo del cambio dentro de la organización. También es importante tener en cuenta que el cambio de los objetivos contempla muchos cambios dentro del proyecto y puede inclusive darlo por terminado.
La determinación de objetivos es los que hace que un proyecto perdure e inclusive sobreviva al cambio en las personas en la organización. Por lo general los proyectos deben aportarle algo al negocio, bien sea en aumento de rentabilidad, en disminución de costos, en acercamiento a los clientes, posición competitiva, entre otros. En algunos casos son múltiples los objetivos que se logran con un solo proyecto.
El establecimiento del objetivo también dispara consecuentemente el establecimiento de los cálculos (inversión) bajo las cuales se va a determinar el logro de estos objetivos. Estos indicadores deben incluir, además del indicador mismo, la forma en que se van a calcular y la periodicidad de los mismos. Uno de los indicadores importantes de un proyecto, e inclusive sobre el cual se basa la aprobación o no de la idea para desarrollar el mismo, es el retorno de la inversión. Se hace indispensable entonces tener también cálculos que permitan garantizar que el retorno original de la inversión estipulado al inicio del proyecto se va a cumplir con el transcurso del mismo. Se requiere tener bajo control entonces la utilización de los recursos asignados al proyecto, recursos de tiempo, dinero y equipo.
La claridad en los objetivos radica en dos factores indispensables, uno que sean alcanzables, y otro que se puedan medir. Objetivos a muy largo plazo requieren un replanteamiento de entregas parciales, de hitos en el transcurso del proyecto, de elementos que permitan generar informes de avance hacia el objetivo final. Es muy fácil que durante el transcurso del proyecto, los problemas dentro del mismo, que no han de faltar, hagan que se pierda el horizonte, si no hay pequeños hitos a los cuales se puede ir avanzando.
Los proyectos de hoy requieren de altísima velocidad en su desarrollo pero también de una excelente calidad en el logro de los objetivos del mismo. La gestión de los proyectos que es de por sí difícil con objetivos claros, es mucho más compleja. Es más complejo aún sostener un proyecto para el cual los objetivos no se ven en progreso, sino como algo tremendamente inalcanzable. Idealmente se debe fragmentar todo en pequeños proyectos, de uno o dos meses a lo sumo, sin embargo si solo se manejan así, se pierde ese "hilo conductor" que hace que todos los elementos apunten hacia el mismo objetivo corporativo.
En general los objetivos deben estar enmarcados bajo los siguientes preceptos:
• Claridad: Un objetivo debe estar claramente definido, de manera tal que no quede ninguna duda en aquellos que son responsables de participar en su logro. Su lenguaje debe ser estricto y conciso, de manera que pueda ser entendido fácilmente y comunicar exactamente lo que se quiere. Se deben utilizar palabras que no sean vagas, imprecisas. En los proyectos informáticos se debe ser muy claro en el lenguaje, y cualquier término técnico, debe aclararse para no crear confusiones.
• Flexibilidad: Los objetivos deben ser lo suficientemente flexibles para ser modificados cuando las circunstancias lo requieran. Dicho de otro modo, deben ser flexibles para aprovechar las condiciones del entorno.
• Medible o mesurable: Los objetivos deben ser medibles en un horizonte de tiempo para poder determinar con precisión y objetividad su cumplimiento.
• Realismo: Los objetivos deben ser factibles de lograrse dentro de las condiciones y plazos establecidos.
• Coherencia: Un objetivo debe definirse teniendo en cuenta su utilidad para la organización. Los objetivos por áreas funcionales deben ser coherentes entre sí, no deben contradecirse.
• Motivación: Los objetivos deben definirse de tal forma que se constituyan en un elemento motivador y en un reto para las personas responsables de su cumplimiento. En caso de ser necesario, relacionar los objetivos a acciones específicas. Fijar objetivos sólo en relación con otros objetivos de la organización. Fijar metas suficientemente altas para que los empleados tengan que luchar por cumplirlas, pero no tan altas que los empleados se den por vencidos.
Un aspecto importante que está relacionado con la formulación de los objetivos y que permite que se reafirme la necesidad de realizar un proyecto determinado es su justificación; ésta se hace sobre la base en la identificación de una problemática que se quiere resolver con el proyecto, por lo que no se debe preguntar sobre el porqué se requiere su realización. El análisis de este interrogante orientará sobre cómo justificarlo, sustentándolo con argumentos claros, cualitativos y cuantitativos, que deben soportarse con una buena información. La justificación no tiene otro propósito que indicar o describir el porqué del proyecto, qué importancia y qué utilidad tiene para el problema que se busca resolver. Se trata de argumentar por medio de conceptos técnicos y científicos que:
• Existe una necesidad que debe ser satisfecha.
• Existe un problema que debe ser solucionado.
• Hay una oportunidad que puede ser aprovechada.
• El proyecto va a satisfacer la necesidad o a resolver el problema.
• Estas necesidades y problemas tienen prioridad sobre otros.
• Existen argumentos políticos, sociales, económicos, técnicos y humanos que justifican que se conceda prioridad a la solución de estos problemas o a la satisfacción de ciertas necesidades.
3. Planificación de Sistemas de Información
La planificación de los Sistemas de Información (SI) se entiende como un procedimiento sistemático de toma de decisiones sobre que hacer con los sistemas de información en el futuro. Esto a evolucionado de tal manera a lo largo de los años que se pueden distinguir cuatro fases:
· La introducción de la informática en las organizaciones
· La expansión anárquica de las aplicaciones informáticas
· La coordinación de los SI con los objetivos de la empresa
· La interdependencia estratégica entre las compañías y los SI
Fase 1: La introducción de la informática en la organización
El objetivo primordial de los directivos al incorporar la Informática en las empresas era la reducción de los costos en el procesamiento de la información y elaborar los procesos con mayor eficiencia y precisión.
Con este objetivo, la elaboración formal de los planes informáticos no existía ni era necesario elaborarlos, ya que se limitaban al desarrollo de aplicaciones informáticas e implementación de peticiones de usuarios. La decisión de los proyectos que se realizan se tomaba a nivel del Departamento de Procesamiento de Datos con un criterio planteado en términos estrictamente económicos.
Esta fase se caracterizó por la dependencia organizacional y funcional del área de informática de las áreas de servicios administrativos, por la existencia de una barrera de comunicación entre los directivos de la empresa y la jefatura de Informática, así como la inexistencia de una conexión entre los objetivos de la empresa con los planes de los sistemas de información.
Fase 2: Expansión anárquica de las aplicaciones informáticas
Con la mecanización de los procesos administrativos, el departamento de informática tuvo la necesidad de enfrentarse a nuevas peticiones por parte de los usuarios que requerían de un mayor conocimiento del negocio. La falta de comprensión por parte de los responsables de Informática originó que las decisiones para desarrollar aplicaciones se tomarán basándose en criterios como:
· La facilidad de implementación.
· La novedad y el atractivo tecnológico del proyecto.
· El poder de la unidad funcional solicitante.
· El costo del desarrollo a realizar
Esta fase se caracteriza por el desarrollo de incipientes sistemas de información formados por una multitud de aplicaciones transaccionales disjuntas e interconectadas entre sí por otras aplicaciones que les sirven como canal de comunicación; esta disfuncionalidad era evidente tanto desde el punto de vista técnico como funcional.
Fase 3: Coordinación SI con los objetivos de la empresa
La inversión que representaba el área de Informática así como la insatisfacción de los usuarios por el servicio, originó que los directivos de las empresas decidieran afrontar el problema de los Sistemas de Información desde un punto de vista global. Así que a partir de ese momento se establecen planes sistemáticos de definición de necesidades de información coherentes con los objetivos estratégicos de las unidades funcionales de la compañía. El Plan de SI contemplaba además de los proyectos a desarrollar, las prioridades de la empresa en la asignación de recursos a las tecnologías de información.
Esta fase se caracterizó por la intervención de la alta Dirección en la decisión de los proyectos a implementar, el desarrollo de procedimientos formales de planificación de SI, el establecimiento de planes informáticos en concordancia con los objetivos de la empresa y el cambio en el rol del responsable de SI, que se convierte en un coordinador del equipo interdepartamental que elabora la propuesta de Plan de Sistemas.
Fase 4: Interdependencia estratégica de la compañía – TI/SI
Una vez superado el aislamiento de los planes de los Sistemas de Información respecto a la estrategia de la compañía, la dirección general se plantea como sacar el mayor provecho de las nuevas tecnologías de la información, por lo que se comienza a visualizar que el uso integrado de TI y SI permitirán a la empresa conseguir ventajas competitivas sostenibles. Para lo anterior es necesario integrar las posibilidades de los SI y de las TI con las estrategias de la empresa en el momento de formularla.
Para lograr una metodología de implementación exitosa de la TI /SI acorde con la estrategia de la empresa se requiere:
· Una cultura en la organización que sea sensible al potencial de las Tecnologías de Información.
· Un conocimiento en el Departamento de SI de los objetivos de la empresa.
Planificación del TI/SI a partir de la estrategia del negocio
A fin de delimitar el esfuerzo necesario para planificar los Sistemas de Información es conveniente empezar por definir que debe incluir un Plan de Sistemas y Tecnologías de Información (TI/SI):
· Una lista de proyectos a desarrollar en los próximos 3 a 5 años.
· Análisis de la TI /SI con un enfoque de negocio.
· Prioridad de cada proyecto.
· El detalle de los proyectos a desarrollar el primer año, con la finalidad de incluir en el presupuesto anual los recursos necesarios requeridos.
· Mecanismos de evaluación que permitan el seguimiento del plan, tales como un calendario y un presupuesto detallado.
· Un listado de las actividades de la empresa donde la TI puede utilizarse como herramienta de soporte para aumentar su eficacia y eficiencia.
La responsabilidad de desarrollar el plan de TI/SI recae fundamentalmente en la dirección de la empresa con la participación de un responsable de cada área funcional y del departamento técnico, con la finalidad de que este integrado por un equipo que represente a todas las áreas de la empresa.
Esquema general del procedimiento
El procedimiento de planificación requiere de varios grupos de trabajo para su implementación con una función específica, la cual se detalla a continuación:
Comité de TI/SI, formado por el máximo responsable de la compañía, los responsables de las distintas áreas funcionales y el director de SI. Sus responsabilidades son:
· Diseño del Sistema de Información.
· Supervisión del proyecto de planificación.
· Comunicación del compromiso de la empresa con el plan de desarrollo.
· Proporcionar los criterios estratégicos para la fijación de prioridades y asignación de recursos.
· Aprobar el Plan de TI/SI desarrollado
Equipo de trabajo, lleva a cabo el trabajo operativo encaminado a elaborar el plan de TI/SI, está dirigido por el director de SI e integrado por un director operativo del proyecto (DOP), personal de sistemas y usuarios de los departamentos especialmente dedicados al proyecto de planificación.
Grupo base, integrado por el subdirector general a cargo de SI, el director de SI, el DOP y, eventualmente, por consultores externos expertos en planificación de sistemas de información. Su responsabilidades son:
· Facilitar la negociación entre los usuarios.
· Asegurar la consistencia de los desarrollos.
· Supervisar el equipo de trabajo
Las fases principales que componen el procedimiento de planificación se describen a continuación:
Fase 1: Presentación y compromiso del equipo
Se dedicada a la construcción del equipo de trabajo que llevará a cabo la planificación y su presentación ante la organización. Una parte importante del proyecto de planificación es el tiempo dedicado de los responsables de los departamentos y áreas funcionales de la compañía a la tarea de entrevistas y sesiones de trabajo con el equipo de planificación, esto se logra gracias al compromiso de la alta dirección en comunicar que el Plan de TI/SI es un plan que pertenece a toda la organización.
Fase 2: Descripción de la situación actual
Una vez formado el equipo de trabajo y comprometida la organización con el esfuerzo de planificación, el primer paso consiste en describir la situación actual de la compañía en dos dimensiones: el negocio y los sistemas existentes. En esta fase se definen las funciones del negocio para poder identificar las necesidades de información. Aquí es donde se describe a la organización y al sistema de información existente.
Fase 3: Elaboración del Plan de TI/SI
Llevar a cabo la planificación propiamente dicha, donde se llevan a cabo las siguientes actividades:
· Documentar las necesidades de información de cada una de las funciones del negocio.
· Identificar las necesidades que no son cubiertas o parcialmente cubiertas por los sistemas actuales.
· Formular propuestas de actividades que influyan directamente en las líneas estratégicas de la empresa.
· Estimar el costo aproximado de la alternativa elegida
El resultado es una serie de acciones de TI/SI a realizar durante la vigencia del plan que deberá ser aprobado por el comité de Sistemas.
Fase 4: Programación de actividades
Detallar las acciones específicas en forma de proyectos que se llevarán a cabo durante el primer año de vigencia del Plan.
Características de los procedimientos de planificación de SI que parten de la estrategia del negocio
Durante la descripción de un procedimiento de planificación de SI enfocado a la alineación con la estrategia del negocio, se deben de destacar algunas características que constituyen la esencia de este tipo de procedimientos.
· El proceso de planificación debe de ser algo de la empresa, llevado a cabo y dirigido por personal propio
· La alta dirección de la empresa, así como de cada una de las áreas que la forman, deben participar activamente en el proceso
· Se deben de identificar en un matriz las funciones del negocio (filas), así como los criterios de carácter estratégico (columnas)
· Se debe de hacer el costeo de propuestas concretas en el plan en dos fases y personal distinto: uno técnico y el otro de negocio (estratégico)
· La comunicación entre técnicos y directivos durante el transcurso de un proyecto de planificación, debe de establecerse tanto durante las entrevistas de trabajo como durante las sesiones de elaboración de resultados y presentación de los mismos.
1. Arquitectura Tecnológica
La arquitectura tecnológica viene a ser el conjunto de las herramientas computacionales, tanto en sistemas de computo, de redes o sistemas comunicacionales, de programas y aplicaciones capaces de cubrir las necesidades de información de diferente índole, que se requieran para el desarrollo e implementación de un proyecto organizacional.
El objetivo del proceso de arquitectura tecnológica e innovación es por una parte establecer el diseño básico general de los sistemas de información y por otra asegurarse de que no sufren estancamiento ni obsolescencia.
El diseño de la arquitectura tecnológica busca establecer un marco conceptual que oriente los proyectos de transformación y evolución de los sistemas, de forma que se mantengan integrados de un modo coherente.
La demanda de una calidad y seguridad en los servicios obliga a definir una arquitectura coherente en que los sistemas, estén centralizados, distribuidos o subcontratado, sean capaces de intercambiar información y operar de modo armónico.
Los riesgos a la seguridad que se han introducido en las redes (virus, intrusos, pérdida de información, etc..) y la demanda de continuidad en los servicios derivada de la creciente implantación de sistemas en red que llegan a los usuarios (clientes o ciudadanos), requieren también una gestión profesional. Todos estos factores (calidad, integración, seguridad) llevan a necesitar una arquitectura de sistemas de información que permita una evolución armónica y acorde a lo que se busca lograr con el sistema.
2. Conducción de entrevistas
El analista para desarrollar los sistemas de información debe recurrir a una gran diversidad de técnicas y herramientas para recolectar los datos que requiera; para entre ellas puede utilizar las entrevistas, la encuesta, el cuestionario, la observación, el diagrama de flujo, el diccionario de datos. Todos estos instrumentos se aplicarán en un momento en particular, con la finalidad de buscar información que será útil a una investigación en común. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigación completa.
Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarán datos o serán afectados por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos algunos analistas prefieren este método a las otras técnicas que se estudiarán más adelante.
Dentro de una organización, las entrevistas es la técnica más significativa y productiva de que dispone el analista para recabar datos. Las entrevistas son un intercambio de información que se efectúa cara a cara. Viene a ser un canal de comunicación entre el analista y la organización; que sirve para obtener información acerca de las necesidades y la manera de satisfacerlas, así como consejo y comprensión por parte del usuario para toda idea o método nuevos. Por otra parte, la entrevista ofrece al analista una excelente oportunidad para establecer una corriente de simpatía con el personal usuario, lo cual es fundamental en el transcurso del desarrollo del proyecto. Cabe destacar que está técnica requiere de ciertos pasos de preparación y conducción.
Preparación de la Entrevista
1) Determinar la posición que ocupa de la organización el futuro entrevistado, sus responsabilidades básicas, actividades, etc. (Investigación).
2) Preparar las preguntas que van a plantearse, y los documentos necesarios (Organización).
3) Fijar un límite de tiempo y preparar la agenda para la entrevista (Psicología).
4) Elegir un lugar donde se puede conducir la entrevista con la mayor comodidad (Psicología).
5) Hacer la cita con la debida anticipación (Planeación).
Conducción de la Entrevista
1) Explicar con toda amplitud el propósito y alcance del estudio (Honestidad).
2) Explicar la función propietaria como analista y la función que se espera conferir al entrevistado. (Imparcialidad).
3) Hacer preguntas específicas para obtener respuestas cuantitativas (Hechos).
4) Evitar las preguntas que exijan opiniones interesadas, subjetividad y actitudes similares (habilidad).
5) Evitar el cuchicheo y las frases carentes de sentido (Claridad).
6) Ser cortés y comedio, absteniéndose de emitir juicios de valores. (Objetividad).
7) Conservar el control de la entrevista, evitando las divagaciones y los comentarios al margen de la cuestión.
8) Escuchar atentamente lo que se dice, guardándose de anticiparse a las respuestas (Comunicación).
Culminación de la Entrevista
1) Escribir los resultados.
2) Entregar una copia al entrevistado, solicitando su conformación, correcciones o adiciones. (Profesionalismo).
3) Archivar los resultados de la entrevista para referencia y análisis posteriores (Documentación).
3. Diagramas de Descomposición Funcional
De acuerdo a la visión de un sistema, desde el punto de vista de tiempo, información y función; existen diversas técnicas, una de las técnicas usuales en cuanto al modelado de la función viene a ser el Diagrama de Descomposición Funcional (DDF). El objetivo de esta técnica es representar la jerarquía de los procesos del sistema en diferentes niveles de abstracción. Para ello se descompone una función de alto nivel en funciones de más bajo nivel, y así sucesivamente. Los DDF se utilizan principalmente para representar las funciones, pero también pueden ayudar a representar otros tipos de información, como estructura de organizaciones, estructura de documentos, de menús, y otros.
Este diagrama se utiliza para representar o mostrar las estructuras de organizaciones, sistemas, programas, archivos e informes. El término "descomposición" significa "romper o separar algo en sus componentes o elementos básicos". Usualmente se utiliza como un adjetivo que dice cual es la naturaleza de la descomposición; por ejemplo: descomposición funcional, de procesos, procedimientos y datos.
La estructura de árbol es la que usualmente se utiliza para representar este modelo. También se utiliza el enfoque de arriba hacia abajo ("Top Down"). Por ejemplo, al crear un modelo de la organización el primer paso es determinar cuales son las áreas funcionales. El segundo paso es definir cuales son los procesos o actividades específicas que tienen que llevarse a cabo dentro de esa área funcional. El tercer paso es describir los procedimientos que se llevan a cabo para lograr esos procesos.
Para la representación gráfica de este tipo de diagrama se utiliza un bloque o rectángulo unido por líneas. Se deben diferenciar las áreas funcionales, procesos y los procedimientos sombreándolos de forma diferente. Según los estudiosos del tea, este tipo de diagrama es útil para crear una visión general de las funciones y procesos de la organización pero el mismo no es lo suficientemente bueno para representar el detalle de los procedimientos.
1. Análisis Estructurado
Los sistemas de información reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. El método de desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por medio de:
1). La división del sistema en componentes
2). La construcción de un modelo del sistema.
El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. Permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadora, terminales, sistemas de almacenamiento, etc.). Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado.
El análisis estructurado es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Éste análisis permite al analista conocer un sistema o proceso en una forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente.
Componentes
Símbolos gráficos: Iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes.
Diccionario de datos: descripción de todos los datos usados en el sistema. Puede ser manual o automatizado.
Descripciones de procesos y procedimientos: declaraciones formales que usan técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema.
Reglas: estándares para describir y documentar el sistema en forma correcta y completa.
2. Herramientas par Moldear Datos
HerramientasLas herramientas muestran todas las características esenciales del sistema y la forma en que se ajustan entre si, como es muy difícil entender todo un proceso de la empresa en forma verbal, las herramientas ayudan a ilustrar los componentes esenciales de un sistema, junto con sus acciones.
Diagrama de flujo de datos
Es el modelo del sistema. Es la herramienta más importante y la base sobre la cual se desarrollan otros componentes.
El modelo original se detalla en diagramas de bajo nivel que muestran características adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujos de datos cada vez más detallados. Repitiéndose esta secuencia hasta que se obtienen suficientes detalles para que el analista comprenda la parte del sistema que se encuentra bajo investigación.
El diagrama físico de datos da un panorama del sistema en uso, dependiente de la implantación, mostrando cuales tareas se hacen y como son hechas. Incluyen nombres de personas, nombres o números de formato y documento, nombres de departamentos, archivos maestro y de transacciones, equipo y dispositivos utilizados, ubicaciones, nombres de procedimientos.
El diagrama lógico de datos da un panorama del sistema, pero a diferencia del físico es independiente de la implantación, que se centra en el flujo de datos entre los procesos, sin considerar los dispositivos específicos y la localización de los almacenes de datos o personas en el sistema. Sin indicarse las características físicas.
Notaciones: son cuatro símbolos, que fueron desarrollados y promovidos la mismo tiempo por dos organizaciones: Yourdon y Gane y Sarson.
Flujo de datos: son movimientos de datos en una determinada dirección, desde un origen hasta un destino. Es un paquete de datos.
3 . Criterios de Diseño
El diseño del sistema es la estrategia de alto nivel para resolver problemas y construir una solución. Éste incluye decisiones acerca de la organización del sistema en subsistemas, la asignación de subsistemas a componentes hardware y software, y decisiones fundamentales conceptuales y de política que son las que constituyen un marco de trabajo para el diseño detallado
La organización global del sistema es lo que se denomina la arquitectura del sistema. Existe un cierto número de estilos frecuentes de arquitectura, cada uno de los cuales es adecuado para ciertas clases de aplicaciones. Una forma de caracterizar una aplicación es por la importancia relativa de sus modelos de objetos, dinámica y funcional. Las distintas arquitecturas ponen distintos grados de énfasis en los tres modelos.
El diseño de sistemas es la primera fase de diseño en la cual se selecciona la aproximación básica para resolver el problema. Durante el diseño del sistema, se decide la estructura y el estilo global. La arquitectura del sistema es la organización global del mismo en componentes llamados subsistemas. La arquitectura proporciona el contexto en el cual se toman decisiones más detalladas en una fase posterior del diseño. AL tomar decisiones de alto nivel que se apliquen a todo el sistema, el diseñador desglosa el problema en subsistemas, de tal manera que sea posible realizar más trabajo por parte de varios diseñadores que trabajarán independientemente en distintos subsistemas. El diseñador de sistemas debe tomar las siguientes decisiones:
- Organizar el sistema en subsistemas
- Identificar la concurrencia inherente al problema
- Asignar los subsistemas a los procesadores y tareas
- Seleccionar una aproximación para la administración de almacenes de datos
- Manejar el acceso a recursos globales
- Seleccionar la implementación de control en software
- Manejar las condiciones de contorno
- Establecer la compensación de prioridades
4. Diseño Estructurado.
El diseño Estructurado es otro elemento del Método de Desarrollo por Análisis Estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software.
El objetivo del Diseño Estructurado es programas formados por módulos independientes unos de otros desde el punto de vista funcional.
La herramienta fundamental del Diseño Estructurado es el diagrama estructurado que es de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas (que es la tarea de los diagramas de flujo).
Los Diagramas Estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él.
5. Evaluación y Adaptación de Paquetes
En esta fase, es donde el creador del sistema realiza diversas pruebas al software con el fin de establecer su idoneidad. Entre estas pruebas se pueden distinguir principalmente:
* Pruebas unitarias: Consisten en probar o testear piezas de software pequeñas; a nivel de secciones, procedimientos, funciones y módulos; aquellas que tengan funcionalidades específicas. Dichas pruebas se utilizan para asegurar el correcto funcionamiento de secciones de código, mucho más reducidas que el conjunto, y que tienen funciones concretas con cierto grado de independencia.
* Pruebas de integración: Se realizan una vez que las pruebas unitarias fueron concluidas exitosamente; con éstas se intenta asegurar que el sistema completo, incluso los subsistemas que componen las piezas individuales grandes del software funcionen correctamente al operar e ínter operar en conjunto.
Las pruebas normalmente se efectúan con los llamados datos de prueba, que es un conjunto seleccionado de datos típicos a los que puede verse sometido el sistema, los módulos o los bloques de código. También se escogen: Datos que llevan a condiciones límites al software a fin de probar su tolerancia y robustez; datos de utilidad para mediciones de rendimiento; datos que proporcionan condiciones eventuales o particulares poco comunes y a las que el software normalmente no estará sometido pero pueden ocurrir; entre otros. Los "datos de prueba" no necesariamente son ficticios o "creados", pero normalmente si lo son los de poca probabilidad de ocurrencia.
Generalmente, existe un fase probatoria final y completa del software, llamada Beta Test, durante la cual el sistema instalado en condiciones normales de operación y trabajo es probado exhaustivamente a fin de encontrar errores, inestabilidades, respuestas erróneas, etc. que hayan pasado los previos controles. Estas son normalmente realizadas por personal idóneo contratado o afectado específicamente a ello. Los posibles errores encontrados se transmiten a los desarrolladores para su depuración. En el caso de software de desarrollo "a pedido", el usuario final (cliente) es el que realiza el Beta Test, teniendo para ello un período de prueba pactado con el desarrollador.
Luego se llega a la fase de instalación y adaptación de paquetes o del software, que es el proceso por el cual los programas desarrollados son transferidos apropiadamente al computador destino, inicializados, y, eventualmente, configurados; todo ello con el propósito de ser ya utilizados por el usuario final. Constituye la etapa final en el desarrollo propiamente dicho del software. Luego de ésta el producto entrará en la fase de funcionamiento y producción, para el que fuera diseñado.
La instalación, dependiendo del sistema desarrollado, puede consistir en una simple copia al disco rígido destino (casos raros actualmente); o bien, más comúnmente, con una de complejidad intermedia en la que los distintos archivos componentes del software (ejecutables, bibliotecas, datos propios.) son descomprimidos y copiados a lugares específicos preestablecidos del disco; incluso se crean vínculos con otros productos, además del propio sistema operativo. Este último caso, comúnmente es un proceso bastante automático que es creado y guiado con herramientas de software específicas (empaquetado y distribución, instaladores). En productos de mayor complejidad, la segunda alternativa es la utilizada, pero es realizada o guiada por especialistas; puede incluso requerirse la instalación en varios y distintos computadores (instalación distribuida). También, en software de mediana y alta complejidad normalmente es requerido un proceso de configuración y chequeo, por el cual se asignan adecuados parámetros de funcionamiento y se testea la operatividad funcional del producto.
En productos de venta masiva las instalaciones completas, si son relativamente simples, suelen ser realizadas por los propios usuarios finales (tales como sistemas operativos, paquetes de oficina, utilitarios, etc.) con herramientas propias de instalación guiada; incluso la configuración suele ser automática. En productos de diseño específico o "a medida" la instalación queda restringida, normalmente, a personas especialistas involucradas en el desarrollo del software en cuestión.
Una vez realizada exitosamente la instalación del software, el mismo pasa a la fase de producción (operatividad), durante la cual cumple las funciones para las que fue desarrollado, es decir, es finalmente utilizado por el (o los) usuario final, produciendo los resultados esperados.
La fase final de este paso, comprende además de la instalación del sistema en sí, el entrenamiento del personal de la empresa y la conversión de datos del sistema antiguo al actual.
1. Conversión
En la etapa de conversión no solo se abarca el cambio del sistema anterior al actual, sino también la interconexión entre el sistema que estamos instalando y los demás sistema de información (SI) que posea la organización, por ejemplo: si se esta implantando un sistema de contabilidad en la empresa este debe ser plenamente compatible con el SI encargado de compras, ventas, inventario, y los demás sistemas organizacionales existentes; de lo contrario habría problemas en la transmisión de datos entre los departamentos, ocasionando graves pérdidas para la organización.
Por eso este paso es de vital importancia, ya que puede significar la muerte del sistema porque a nadie le interesa un sistema que a pesar de ser bueno este aislado de los sistemas de la empresa. Por eso se debe tomar en cuenta los otros sistemas con que cuenta la empresa y estarán en comunicación con el nuevo SI a la hora de establecer los requisitos del usuario.
Otro inconveniente es que durante la instalación del sistema se pueden descubrir nuevos errores no detectados durante la prueba del sistema generando sorpresas desagradables para los usuarios que se están empezando a familiarizar con este nuevo sistema. Para sobrellevar la transición existen 4 estrategias de conversión básicas, y el criterio de aplicación depende del tamaño de la empresa u organización, cuanto más rápido esta requiere ver los beneficios del nuevo sistema en acción y los costos de implantación.
La conversión en paralelo: plantea que tanto el sistema antiguo como el nuevo operen simultáneamente durante un periodo de tiempo determinado. Esta estrategia es de poco riesgo ya que en caso de existir una falla en el sistema recién implantado, se puede continuar trabajando con el sistema antiguo hasta que se corrijan los defectos. El problema es que los costos por mantener dos sistemas funcionando a la vez son elevados.
La conversión en fases: significa que el sistema será implantado por módulos. Por ejemplo en un sistema de pago a empleados primero se ejecutara el módulo de verificación de la cantidad de horas trabajadas, luego el calculo del sueldo de los empleados por hora, de los empleados asalariados y después el de calculo de impuesto. Esta estrategia es útil en grandes sistemas de información que deben ser modularizados para poder desarrollarlos. Las ventajas de esta estrategia son su poco riesgo, ya que en caso de haber una falla solo será en un modulo del sistema, mayor facilidad para los usuarios para aprender a usar el SI debido a que es más fácil aprender a usar el sistema módulo por módulo que todo el sistema a la vez. Su principal desventaja es que los beneficios de implantar el sistema tardaran más en aparecer y eso no es bueno para las empresas que han invertido mucho capital en el sistema.
La conversión directa: implica desechar el anterior sistema e implantar de una vez el sistema nuevo. En este caso la empresa debe estar totalmente segura que el nuevo sistema esta libre de fallas, ya que en casi de existir un error es muy probable que el sistema colapse. Su ventaja es que los beneficios se verán de inmediatos, los costes de instalación serán menores. También es fundamental que los empleados estén plenamente capacitados para usar el nuevo sistema, debido a que la inexperiencia de los usuarios puede reducir el rendimiento del SI.
La conversión piloto: esta es parecida a la conversión en fases ya que se usa en sistemas grandes o sistemas que van a usarse en más de una unidad de negocio o por varios departamentos. Así este se puede ir implementando área por área para evaluar el comportamiento del sistema, buscar fallos y ver como es la relación entre el sistema y los usuarios. También esta estrategia reduce los riesgos pero igual a la conversión en fases se necesita mas tiempo para ver los beneficios que aportara el sistemas funcional.
Después de superada esta fase de conversión, y con el SI ya implementado solo restan la aceptación definitiva del usuario del sistema, a partir de la cual la empresa se hace responsable de las posibles fallas del sistema en el futuro, la entrega de los manuales de usuarios y el código fuente del sistema.
2. Proyecto de Desarrollo – Estrategias
En la etapa de desarrollo del proyecto o sistema, que no es más que la ingeniería de software, se presentan o tiene varios modelos, paradigmas o estrategias 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): llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.
* Modelo de prototipos: se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.
* Modelo en espiral (modelo evolutivo): Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.
* Desarrollo por etapas: es similar al Modelo de prototipos ya que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultáneamente con las diferentes versiones del código.
* Desarrollo iterativo y creciente o Iterativo e Incremental: es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada. Para apoyar el desarrollo de proyectos por medio de este modelo se han creado frameworks (entornos de trabajo), de los cuales los dos más famosos son el Rational Unified Process y el Dynamic Systems Development Method. El desarrollo incremental e iterativo es también una parte esencial de un tipo de programación conocido como Extreme Programming y los demás frameworks de desarrollo rápido de software. La idea principal detrás de mejoramiento iterativo es desarrollar un sistema de programas de manera incremental, permitiéndole al desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo anterior, incrementando, versiones entregables del sistema. El aprendizaje viene de dos vertientes: el desarrollo del sistema, y su uso (mientras sea posible). Los pasos claves en el proceso son comenzar con una implementación simple de los requerimientos del sistema, e iterativamente mejorar la secuencia evolutiva de versiones hasta que el sistema completo esté implementado. En cada iteración, se realizan cambios en el diseño y se agregan nuevas funcionalidades y capacidades al sistema.
* RAD (Rapid Application Development): es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución. En la actualidad, suele utilizarse para referirse al desarrollo rápido de interfaces gráficas de usuario tales como Glade, o entornos de desarrollo integrado completos. Algunas de las plataformas más conocidas son Visual Studio, Delphi, Foxpro, Anjuta o Velneo.
* Proceso Unificado: es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.
* RUP (Proceso Unificado de Rational): (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.
3. Organización de Proyectos
De cierta manera un proyecto es también una organización. En un proyecto todos los actores (organizaciones) son diferentes entre sí, pero coinciden en que una parte de sus esfuerzos (y solo eso) son acciones dentro del proyecto, que van en una dirección común.
De allí que dentro de la organización del proyecto, surja un criterio similar a lo que es el control interno. Este ha sido diseñado, aplicado y considerado como la herramienta más importante para el logro de los objetivos, la utilización eficiente de los recursos y para obtener la productividad, además de proporcionar una seguridad razonable con miras a la consecución de objetivos en las siguientes áreas:
Efectividad y eficiencia en las operaciones.
Confiabilidad en la información financiera.
Cumplimiento de las leyes y regulaciones aplicables.
4. Técnicas de Estimación
Estas técnicas de estimación son una forma de resolución de problemas en donde, en la mayoría de los casos, el problema a resolver es demasiado complejo para considerarlo como una sola parte. Por esta razón, descomponemos el problema, recaracterizándolo como un conjunto de pequeños problemas.
Líneas de Código y Puntos de Función.
Los datos de líneas de código (LDC) y los puntos de función (PF) se emplean de dos formas durante la estimación del proyecto de software:
· Variables de estimación, utilizadas para calibrar cada elemento del software.
· Métricas de base, recogidas de anteriores proyectos utilizadas junto con las variables de estimación para desarrollar proyecciones de costo y esfuerzo.
Estas técnicas son diferentes pero tienen características comunes. El planificador del proyecto comienza con una declaración restringida del ámbito del software y, a partir de esa declaración, intenta descomponer el software en pequeñas subfunciones que pueden ser estimadas individualmente. Entonces, estima las LDC o PF (la variable de estimación) para cada subfunción. Luego, aplica las métricas básicas de productividad a la variable de estimación apropiada y deriva el costo y el esfuerzo para la subfunción. Combinando las estimaciones de las subfunciones se produce la estimación total para el proyecto entero.
Difieren en el nivel de detalle que requiere la descomposición. Cuando se utiliza LDC como variable de estimación, la descomposición funcional es absolutamente esencial y, a menudo, se lleva hasta considerables niveles de detalle. Debido a que los datos requeridos para estimar los Puntos de Función son más macroscópicos, en nivel de descomposición al que se llega cuando PF es la variable de estimación es considerablemente menos detallado. También, debe de tenerse en cuenta que mientras que LDC se estima directamente, PF se determina indirectamente mediante la estimación del número de entradas, salidas, archivos de datos, peticiones e interfaces externas, entre otras.
Independientemente de la variable de estimación que use, el planificador del proyecto, normalmente, proporciona un rango de valores para cada función descompuesta. A partir de los datos históricos o (cuando todo lo demás falla) usando su intuición, el planificador estima los valores optimista, más probable y pesimista de LDC o de PF para cada función. Cuando lo que se especifica es un rango de valores, implícitamente se proporciona una indicación del grado de incertidumbre.
Entonces, se calcula el valor esperado de LDC o de PF. El valor esperado para la variable de estimación, E, se obtiene como una medida ponderada de las estimaciones LDC o PF óptima (a), más probable (m) y pesimista (b).
Por ejemplo:
E = a + 4m + b
6
da una mayor credibilidad a la estimación más probable y sigue una distribución de probabilidad beta.
Técnicas Delfi.
Las técnicas delfi fueron desarrolladas en la corporación Rand en el año de 1948, con el fin de obtener el consenso de un grupo de expertos sin contar con los efectos negativos de las reuniones de grupos. La técnica puede adaptarse a la estimación de costos de la siguiente manera:
Un coordinador proporciona a cada experto la documentación con la definición del sistema y una papeleta para que escriba su estimación.
· Cada experto estudia la definición y determina su estimación en forma anónima; los expertos pueden consultar con el coordinador, pero no entre ellos.
· El coordinador prepara y distribuye un resumen de las estimaciones efectuadas, incluyendo cualquier razonamiento extraño efectuado por alguno de los expertos.
· Los expertos realizan una segunda ronda de estimaciones, otra vez anónimamente, utilizando los resultados de la estimación anterior. En los casos que una estimación difiera mucho de las demás, se podrá solicitar que también en forma anónima el experto justifique su estimación.
· El proceso se repite varias veces como se juzgue necesario, impidiendo una discusión grupal durante el proceso.
El siguiente enfoque es una variación de la técnica Delfi tradicional que aumenta la comunicación conservando el anonimato.
· El coordinador proporciona a cada experto la documentación con la definición del sistema y una papeleta para que escriba su estimación.
· Cada experto estudia su definición, y el coordinador llama a una reunión del grupo con el fin de que los expertos puedan analizar los aspectos de la estimación con él y entre ellos.
· Los expertos terminan su estimación en forma anónima.
· El coordinador prepara un resumen de las estimaciones efectuadas sin incluir los razonamientos realizados por algunos de los expertos.
· El coordinador solicita una reunión del grupo para discutir los puntos donde las estimaciones varíen más.
· Los expertos efectúan una segunda ronda de estimaciones, otra vez en forma anónima. El proceso se repite tantas veces como se juzgue necesario.
COCOMO.
El Modelo Constructivo de Costos (COnstructive COst Model) es una jerarquía de modelos de estimación para el software. Esta jerarquía está constituida por los siguientes modelos:
· El modelo COCOMO básico es un modelo univariable estático que calcula el esfuerzo (y el costo) del desarrollo de software en función del tamaño del programa expresando en líneas de código (LDC) estimadas.
· El modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en función del tamaño del programa y de un conjunto de “conductores de costo”, que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto.
· El modelo COCOMO avanzado incorpora todas las características de la versión intermedia y lleva a cabo una evaluación de impacto de los conductores de costo en cada fase (análisis, diseño, etc.) del proceso de ingeniería de software.
Los modelos COCOMO están definidos para tres tipos de proyecto de software.
Modelo Orgánico. Proyectos de software relativamente pequeños y sencillos en los que trabajan pequeños equipos, con buena experiencia en la aplicación, sobre el conjunto de requisitos poco rígidos (por ejemplo, un programa de análisis termal desarrollado para un grupo calórico).
Modelo Semiacoplado. Proyectos de software intermedios (en tamaño y complejidad) en los que los equipos, con variados niveles de experiencia, deben satisfacer requisitos poco o medio rígidos (por ejemplo, un sistema de procesamiento de transacciones con requisitos fijos para un hardware de terminal o un software de gestión de base de datos).
Modelo Empotrado. Proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringidas (por ejemplo, software de control de navegación para un avión).
Las ecuaciones del modelo COCOMO básico tienen la siguiente forma:
E = ab (KLDC) exp (bb)
D = c b (E) exp (db)
donde E es el esfuerzo aplicado en personas-mes, D es el tiempo de desarrollo en meses cronológicos y KLDC es el número estimado de Líneas de Código distribuídas (en miles) para el proyecto.
Las ecuaciones del modelo COCOMO intermedio toma la forma:
E = ai (KLDC) exp (bi) x FAE
donde E es el esfuerzo aplicado en personas-mes, KLDC es el número estimado de Líneas de Código distribuidas para el proyecto.
5. Justificación de Proyectos.
Un nuevo sistema requiere planificación, construcción y prueba. Los programas y módulos deben ser diseñados, codificados, probados y documentados; todo esto con el fin de demostrar que son totalmente funcionales; de allí que sean bien justificados su desarrollo, elaboración e implementación. Proporcionar una administración de datos.
Un síntoma característico de los sistemas atrasados es la falta de una administración de los datos. En esta condiciones, se desarrollan sobre una base ad hoc, y el proceso administrativo se lleva a cabo con los datos que se encuentran disponibles.
Para asegurar la conservación y realce del recurso de datos de una empresa, es necesario proporcionar una función de administración de datos de alto nivel, responsable del desarrollo y mantenimiento de todos los datos necesarios para apoyar efectivamente el proceso administrativo. Esta función debe incluir responsabilidad de proveer definiciones, relaciones, formatos y estándares de exactitud y precisión. Además, se debe responsabilizar de la seguridad de los datos de la organización
Automatizar el desarrollo de datos. Uno de los más grandes obstáculos para la implantación de nuevos sistemas es la necesidad de recoger y mantener datos adicionales. Esta tarea se facilita en gran medida mediante la introducción de medios automatizados de desarrollo y mantenimiento de datos. Esto se realiza a través de sistemas automatizados de codificación, recolección automática de datos, la que se realiza mejor cuando es parte del proceso de control, así como medios automatizados para extraer datos de archivos operacionales, consolidarlos, darles forma y validarlos.
6. Control de proyectos.
Los datos automatizados pueden ser suceptibles de destrucción, fraude, error y mal uso. Las empresas que soportan el procesamiento de todas sus operaciones criticas del negocio mediante el uso de computadoras y Sistemas de Información, pueden experimentar pérdidas totales de la funcionalidad del negocio, si pierden su capacidad de computo por más de unos cuantos días. Para minimizar los errores, desastres, delitos por computadoras y fallas de seguridad, es necesario incorporar políticas y procedimientos especiales en el diseño, implementación e implantación de los Sistemas de Información.
Los controles consisten en todos los métodos, políticas y procedimientos para asegurar la protección de los activos de la institución, la precisión y la confiabilidad de sus registros. El control debe ser parte integral del diseño. Los controles pueden ser de dos tipos:
Controles Generales: Son aplicables a todos los sistemas de la organización y consisten en una combinación de software y procedimientos. De hecho, abarcan las siguientes áreas:
1) De Implantación. Son puntos formales de revisión de las diferentes etapas del desarrollo del Software.
2) DelSoftware. Evitan el acceso al Software. Están diseñados para evitar cambios no autorizados de los programas y de los datos.
3) De Hardware. Deben asegurarse físicamente de forma tal que sólo tengan acceso a ellos las personas autorizadas. También contemplan aquellas aplicaciones que verifican posibles fallas de Hardware.
4) De Operaciones de Computo. También conocidas como auditorias. Aseguran que los procedimientos programados sean consistentes y estén siendo aplicados correctamente en su procesamiento y almacenamiento.
5) En los datos. Que los datos que están en cintas o discos no estén al alcance de personas no autorizadas.
6) Administrativos. Son normas, reglas, procedimientos y disciplinas formales para garantizar que los controles de la institucion se ejecuten.
Controles De Aplicaciones: Son específicos para cada aplicación de computador (nómina, cuentas por cobrar, y otros). Consisten en controles aplicados a los tipos de usuarios particulares de un sistema y a la programación de los procedimientos. Y pueden ser:
1) De Entradas. Procedimientos para chequear la exactitud y completitud de los datos cuando son introducidos en el sistema.
2) De Procesamiento. Rutinas para garantizar que los datos se mantienen completos y exactos durante una actualización.
3) de Salidas. Medidas que aseguren que los resultados de los procesamientos hechos por el computador sean exactos, completos y distribuidos apropiadamente.
9. Evaluación de Impacto y control de Cambio.
Evaluación operacional: Es el Momento en que sé evalúa la manera en que funciona el Sistema, esto incluye su facilidad de uso, Tiempo de respuesta ante una necesidad o proceso, como se adecuan los formatos en que se presenta la Información , contabilidad global y su nivel de Utilidad.
Impacto Organizacional: Identifica y mide los beneficios operacionales para la Empresa en áreas tales como, Finanzas (Costos, Ingresos y Ganancias), eficiencia en el desempeño laboral e impacto competitivo, Impacto, rapidez y organización en el flujo de Información interna y externa.
Desempeño del Desarrollo: Es la evaluación del Proceso de desarrollo adecuado tomando en cuentas ciertos criterios como, Tiempo y esfuerzo en el desarrollo concuerden con presupuesto y estándares y otros criterios de Administración de Proyectos. Además se incluyen la valoración de los métodos y herramientas utilizados durante el desarrollo del Sistema.
Prueba de Sistemas: Dependiendo del tamaño de la Empresa que usara el Sistema y el riesgo asociado a su uso, puede hacerse la elección de comenzar la operación del Sistema solo en un área de la Empresa (como una Prueba piloto), que puede llevarse a cabo en un Departamento o con una o dos personas. Cuando se implanta un nuevo sistema lo aconsejable es que el viejo y el nuevo funcionen de manera simultánea o paralela con la finalidad de comparar los resultados que ambos ofrecen en su operación, además dar tiempo al personal para su entrenamiento y adaptación al nuevo Sistema.
Durante el Proceso de Implantación y Prueba se deben implementar todas las estrategias posibles para garantizar que en el uso inicial del Sistema este se encuentre libre de problemas lo cual se puede descubrir durante este proceso y levar a cabo las correcciones de lugar para su buen funcionamiento. Cuando este proceso se lleva a cabo de manera adecuada proporciona muchas informaciones que pueden ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones futuras.
Ahora bien, en cuanto al mantenimiento del sistema informático o software no es más que el proceso de control, mejora y optimización del software ya desarrollado e instalado, que también incluye depuración de errores y defectos que puedan haberse filtrado de la fase de pruebas de control y beta test. Esta fase es la última (antes de iterar, según el modelo empleado) que se aplica al ciclo de vida del desarrollo de software. La fase de mantenimiento es la que viene después de que el software está operativo y en producción.
De un buen diseño y documentación del desarrollo dependerá cómo será la fase de mantenimiento, tanto en costo temporal como monetario. Modificaciones realizadas a un software que fue elaborado con una documentación indebida o pobre y mal diseño puede llegar a ser tanto o más costosa que desarrollar el software desde el inicio. Por ello, es de fundamental importancia respetar debidamente todas las tareas de las fases del desarrollo y mantener adecuada y completa la documentación.
Durante el período de mantenimiento, es común que surjan nuevas revisiones y versiones del producto; que lo liberan más depurado, con mayor y mejor funcionalidad, mejor rendimiento, etc. Varias son las facetas que pueden ser alteradas para provocar cambios deseables, evolutivos, adaptaciones o ampliaciones y mejoras. Básicamente se tienen los siguientes tipos de cambios:
* Perfectivos: Aquellos que llevan a una mejora de la calidad interna del software en cualquier aspecto: Reestructuración del código, definición más clara del sistema y su documentación; optimización del rendimiento y eficiencia.
* Evolutivos: Agregados, modificaciones, incluso eliminaciones, necesarias en el software para cubrir su expansión o cambio, según las necesidades del usuario.
* Adaptivos: Modificaciones que afectan a los entornos en los que el sistema opera, tales como: Cambios de configuración del hardware (por actualización o mejora de componentes electrónicos), cambios en el software de base, en gestores de base de datos, en comunicaciones, etc.
* Correctivos: Alteraciones necesarias para corregir errores de cualquier tipo en el producto software desarrollado.
