El ciclo de vida de un Sistema de Informacin

Un sistema de informacin es un sistema, automatizado o manual, que engloba a personas, mquinas y/o mtodos organizados para recopilar, procesar, transmitir datos que representan informacin.

Un sistema de informacin engloba la infraestructura, la organizacin, el personal y todos los componentes necesarios para la recopilacin, procesamiento, almacenamiento, transmisin, visualizacin, diseminacin y organizacin de la informacin.

Etapas
Cualquier sistema de informacin pasa por una serie de fases a lo largo de su vida. Su ciclo de vida comprende una serie de etapas entre las que se encuentran las siguientes: Etapa Preliminar y Planificacin Anlisis Diseo Implementacin Pruebas Instalacin Uso y Mantenimiento

La Etapa Preliminar y Planificacin

Las tareas iniciales que se realizarn en esta fase inicial del proyecto incluyen actividades tales como:
la determinacin del mbito del proyecto la realizacin de un estudio de factibilidad el anlisis de los riesgos asociados al proyecto una estimacin del costo del proyecto su planificacin temporal la asignacin de recursos a las distintas etapas del proyecto

PUNTO CLAVE Definicin de Objetivos y Alcances

Los objetivos y alcance de un proyecto son los componentes principales de los documentos claves de definicin y planificacin de un proyecto. Pero, fundamentalmente, es la definicin conceptual del proyecto. La correcta gestin de proyectos procura el balance entre los aspectos de producto (ingeniera de producto) y de proceso (ingeniera de proceso).

Planificacin del Proyecto

La planificacin es un proceso iterativo, usualmente realizado repetidamente durante el curso de un proyecto a medida que las condiciones cambian y se adquieren nuevos conocimientos. An as, el conjunto de objetivos iniciales debe permanecer casi esttico.

Alcance del trabajo

El Alcance del Trabajo forma parte generalmente del Plan de Proyecto (Planificacin) an cuando en otras ocasiones se lo desarrolle como un documento separado (SOW Statement of work); dicha definicin inicial no debe confundirse con el listado completo y detallado de requerimientos que ser realizado en etapas posteriores del proyecto. El SOW contiene simplemente detalles que no van mas all de los paquetes a desarrollar.

Determinacin del mbito del proyecto En esta etapa es importante determinar los aspectos que abarca el proyecto y fijar aqullos aspectos que no se incluirn en el proyecto. Estos ltimos han de indicarse explcitamente. En esta etapa se obtiene un documento breve en el que se describe el problema que nuestro sistema pretende resolver. Este documento, denominado Project Charter, debe existir siempre en todo proyecto. Incluye la funcionalidad que tendr nuestro sistema, sus caractersticas principales y sus objetivos clave.
Debe formar parte del contrato que se firme con el cliente.

Un Project Charter incluye las necesidades de negocio, la descripcin del producto y las principales suposiciones, adems de una definicin a alto nivel de objetivos y alcance. Este documento es el principal elemento utilizado para realizar la eleccin de un proyecto en organizaciones con carteras de proyectos. Es la primera vez en la vida del proyecto que empieza a tomar coherencia de conjunto.

Project Charter Este documento puede recibir otros nombres tales como: Contrato de Proyecto, Documento de Iniciacin de Proyecto o Lnea Base de Alcance y puede ser producido empleando diferentes formatos y tcnicas pero su caracterstica fundamental es que debe ser breve, claro y completo respecto a: Objetivos Funciones Rendimiento Restricciones Alcance Costos y Beneficios

Adems de ser breve, debe estar escrito en un lenguaje que cualquiera pueda entender, evitando un vocabulario excesivamente tcnico. Adems, debe recoger todo lo que le contaramos a un conocido en unos segundos acerca del proyecto en el que estamos trabajando si nos lo cruzramos por la calle.

Plan de Administracin de Proyecto Es el documento mas importante del proyecto. Define la forma en la cual se ejecutar el proyecto y cul ser su producto. Debe incluir la siguiente informacin: Contenido del Project Charter. Organizacin del proyecto. Procesos tcnicos y administrativos a emplear. Calendario, dependencias y recursos. Estimaciones y presupuesto.

Estudio de Factibilidad o Viabilidad

Anlisis de riesgos Independientemente de la precisin con la que hayamos preparado nuestro proyecto, siempre se produce algn contratiempo que eche por tierra la mejor de las planificaciones. Es algo inevitable con lo que hemos de vivir y para lo cual disponemos de una herramienta extremadamente til: la gestin de riesgos, que tradicionalmente se descompone en evaluacin de riesgos y control de riesgos.

La evaluacin de riesgos se utiliza para identificar "riesgos" que pueden afectar negativamente al plan de nuestro proyecto, estimar la probabilidad de que el riesgo se materialice y analizar su posible impacto en nuestro proyecto. Qu sucedera si algn miembro clave del nuestro equipo abandona la empresa, se va de vacaciones, se pone enfermo o si nos encontramos con algn problema de compatibilidad del sistema que hemos desarrollamos con la configuracin de los equipos sobre los que ha de funcionar? O si, inadvertidamente, borramos o modificamos errneamente algn que otro archivo clave?

Una vez analizados los riesgos potencialmente ms peligrosos, podemos recurrir a distintas tcnicas de control de riesgos. Por ejemplo, podemos elaborar planes de contingencia para los riesgos que sean ms probables y de consecuencias ms desastrosas para el proyecto. O tal vez seamos capaces de eliminar el riesgo de raz (o mitigarlo) si buscamos alguna alternativa en la que el riesgo identificado no pueda presentarse (o se presente debilitado).

Independientemente de la solucin optemos, el anlisis de riesgos nos hemos de dejar un margen para previsibles y aadir cierta holgura a la de nuestro proyecto.

por la que ensea que imprevistos planificacin

Estimacin Sin duda, una de las tareas ms complejas de cualquier proyecto de desarrollo de software es la estimacin inicial del costo de algo que an no conocemos. Una mala estimacin han sido identificada como una de las dos causas ms comunes del fracaso de un proyecto de desarrollo de software. La otra es la existencia de requerimientos inestables sujetos a continuos cambios.

Estimacin
La prediccin es difcil, especialmente si se trata del futuro.

La estimacin del costo asociado se suele realizar en el peor momento: al comienzo. Cuando menos conocemos del proyecto y mayor es el margen del error de la estimacin. Existen algunas reglas heursticas que nos pueden ayudar a estimar el costo y duracin de un proyecto. El arte de una buena estimacin est basado, fundamentalmente, en la experiencia del estimador. Haber participado en proyectos de similares caractersticas puede ser esencial para que seamos capaces de realizar una buena estimacin. La incertidumbre en la estimacin es inevitable pero cuantos ms datos histricos recopilemos y ms precisa sea la informacin de la que dispongamos acerca de nuestro proyecto, mejor ser nuestra estimacin.

Planificacin temporal y asignacin de recursos

Una planificacin por semanas suele ser razonable para afrontar con comodidad las contingencias que surjan sin tener que estar continuamente reajustando el plan del proyecto. La planificacin del proyecto ha de reajustarse cada vez que cambien las circunstancias del mismo. Si no se ha podido terminar una tarea en el tiempo inicialmente establecido, no nos vale suponer alegremente que posteriormente se recuperar el tiempo perdido. Los proyectos se retrasan poco a poco. Debemos aprovechar las primeras seales de alarma y no esconderlas debajo de la alfombra fingiendo que todo marcha segn lo previsto.

Planificacin temporal y asignacin de recursos

La planificacin es fundamental en la gestin de un proyecto de desarrollo de software. Procure siempre mantener su plan al da. Un plan que no se ajusta a la realidad no sirve de mucho. Cuando algn retraso indique que posiblemente le ser imposible cumplir los plazos establecidos, hable con su cliente. A l le interesa saberlo y, aunque probablemente no se lo agradezca, a la larga resultar beneficioso y usted habr cumplido con su obligacin profesional.

Errores Comunes
- Abreviar las etapas iniciales del proceso de desarrollo de software (planificacin y anlisis, generalmente) para pasar directamente a la "construccin" del sistema. Los errores cometidos en las fases iniciales de un proyecto son mucho ms costosos de corregir a la larga. -No gestionar adecuadamente los cambios que inevitablemente ocurren durante el proyecto. Tan malo es permitir cualquier cambio de forma indiscriminada como ser excesivamente rgidos a la hora de no admitir cambios aunque stos sean razonables. - Reducir la interaccin con el cliente, ya que aparentemente slo se dedica a entorpecer nuestro trabajo con sus continuos cambios de opinin y sus expectativas poco realistas. Al fin y al cabo, el cliente es la persona cuyas necesidades hemos de descubrir y satisfacer.

Errores Comunes
-Olvidar que aadir personal a un proyecto retrasado, por lo general, slo lo retrasa ms (la ley de Brooks). La curva de aprendizaje que se necesita para comenzar a ser productivo ha de tenerse siempre en cuenta. Adems, quin le resuelve las dudas al recin incorporado? El tiempo que empleen los dems miembros del equipo ser tiempo que no podrn utilizar en otras cosas. -Someter a los miembros de nuestro equipo a continuas interrupciones durante su jornada de trabajo (llamadas telefnicas, reuniones, consultas...). Las calidad del trabajo intelectual depende de la capacidad del trabajador de mantener su "estado de flujo" (un estado relajado de inmersin total en un problema que facilita su comprensin y la generacin de soluciones). Se tarda unos 15 minutos en conseguir este estado, por lo que una simple interrupcin cada 10 minutos afecta drsticamente al rendimiento del trabajador.

Errores Comunes
-Hacer trabajar horas extra a los miembros del equipo de desarrollo slo sirve para disminuir su productividad (trabajo realizado por unidad de tiempo). Tras un larga jornada de trabajo, la mente pierde su frescura y comete errores que luego tendrn que corregirse. Adivina cmo? Con ms horas extra. - No informar de pequeos retrasos pensando que ms tarde se recuperar el tiempo perdido. La planificacin temporal del proyecto debe ir ajustndose conforme vamos aprendiendo ms cosas acerca del problema al que nos enfrentamos. En el peor de los casos, se deben negociar algunos recortes con el cliente si ste desea mantener los plazos estipulados al comienzo del proyecto. - Confiar excesivamente en la mejora de rendimiento que se producir gracias al uso de una nueva herramienta, tecnologa o metodologa (error conocido como el "sndrome de la bala de plata" en honor a un artculo muy recomendable escrito por Fred Brooks: No silver bullets - Essence and accidents of Software Engineering, Computer, 1987).

Anlisis
Lo primero que debemos hacer para construir un sistema de informacin es averiguar qu es exactamente lo que tiene que hacer el sistema. La etapa de anlisis en el ciclo de vida del software corresponde al proceso mediante el cual se intenta descubrir qu es lo que realmente se necesita y se llega a una comprensin adecuada de los requerimientos del sistema (las caractersticas que el sistema debe poseer). Por qu resulta esencial la etapa de anlisis? Simplemente, porque si no sabemos con precisin qu es lo que se necesita, ningn proceso de desarrollo nos permitir obtenerlo. El problema es que puede que ni nuestro cliente sepa de primera qu es exactamente lo que necesita. Por tanto, debemos ayudarlo a averiguarlo.

Anlisis
Por qu es tan importante averiguar exactamente cules son los requerimientos del sistema?. Porque el costo de construir correctamente un sistema de informacin desde el inicio es mucho menor que el costo de construir un sistema que habr que modificar ms adelante. Cuanto antes se detecte un error, mejor. Distintos estudios han demostrado que eliminar un error en las fases iniciales de un proyecto (en la etapa de anlisis) resulta de 10 a 100 veces ms econmico que subsanarlo al final del proyecto. Conforme avanza el proyecto, el software se va describiendo con un mayor nivel de detalle, se concreta cada vez ms y se convierte en algo cada vez ms rgido.

Anlisis
Es posible determinar de antemano todos los requerimientos de un sistema de informacin? NO. Una de las dos causas ms comunes de fracaso en proyectos de desarrollo de software es la inestabilidad de los requerimientos del sistema (la otra es una mala estimacin del esfuerzo requerido por el proyecto). En el caso de una mala estimacin, el problema se puede solucionar estableciendo objetivos ms realistas. Sin embargo, en las etapas iniciales de un proyecto, no disponemos de la informacin necesaria para determinar exactamente el problema que pretendemos resolver. Por mucho tiempo que le dediquemos al anlisis del problema (un fenmeno conocido como la parlisis del anlisis).

Anlisis
La inestabilidad de los requerimientos de un sistema es inevitable. Se estima que un 25% de los requerimientos iniciales de un sistema cambian antes de que el sistema comience a utilizarse. Muchas prcticas resultan efectivas para gestionar adecuadamente los requerimientos de un sistema y, en cierto modo, controlar su evolucin. Un buen analista debera tener una formacin adecuada en: -Tcnicas de elicitacin de requerimientos. -Herramientas de modelado de sistemas. - Metodologas de anlisis de requerimientos.

Tcnicas de elicitacin de requerimientos

En la fase de anlisis, los errores ms difciles de corregir son los causados por los "requerimientos ausentes", generalmente en la forma de suposiciones que se dan por sabidas pero nunca se llegan a plasmar explcitamente. Por este motivo, elicitar los requerimientos de un sistema de informacin (esto es, obtener de algn modo cules son realmente esos requerimientos) resulta una actividad esencial en cualquier proceso de desarrollo de software. La elicitacin de requerimientos requiere previamente la identificacin de las personas afectadas por el proyecto, sus stakeholders. En la elicitacin de requerimientos se recurre a distintas tcnicas que favorezcan la comunicacin entre el analista y el resto de personas involucradas, como son las tcnicas de relevamiento ya vistas en clase (entrevistas, cuestionarios, el desarrollo de prototipos, observacin, revisin de registros).

Herramientas de modelado de sistemas

Un modelo, es una simplificacin de la realidad. El uso de modelos en la construccin de sistemas de informacin resulta esencial por los siguientes motivos: -Los modelos ayudan a comunicar la estructura de un sistema complejo (y, por tanto, a comunicarnos con las dems personas involucradas en un proyecto). -Los modelos sirven para especificar el comportamiento deseado del sistema (como gua para las etapas posteriores del proyecto). -Los modelos nos ayudan a comprender mejor lo que estamos diseando (por ejemplo, para detectar inconsistencias y corregirlas). - Los modelos nos permiten descubrir oportunidades de simplificacin (ahorrarnos trabajo en el proyecto actual) y de reutilizacin (ahorrarnos trabajo en futuros proyectos).

Herramientas de modelado de sistemas

Los modelos, entre otras cosas, facilitan el anlisis de los requerimientos del sistema, as como su posterior diseo e implementacin. Un modelo, en definitiva, proporciona "los planos" de un sistema. El modelo ha de capturar "lo esencial desde determinado punto de vista. En funcin de para qu queramos el modelo, lo haremos ms o menos detallado, siempre de acuerdo a su relevancia y utilidad.

Metodologas de anlisis de requerimientos

Las tcnicas de elicitacin de requerimientos y las herramientas de modelado de sistemas deben utilizarse acompaadas de una metodologa adecuada. Las metodologas de anlisis particulares, estn ligadas, o bien al uso de determinadas herramientas (por lo que el vendedor de la herramienta se convierte, muchas veces, en el nico promotor de la metodologa), o bien a empresas de consultora concretas (que ofrecen cursos de aprendizaje de la metodologa que proponen). En general, no obstante, la eleccin adecuada de las tcnicas utilizadas depender de la situacin concreta en la que se encuentre nuestro proyecto. Lo ms adecuado es aprender la mayor cantidad de tcnicas y averiguar en qu situaciones resulta ms efectiva cada una de ellas.

Diseo
Mientras que los modelos utilizados en la etapa de anlisis representan los requisitos del usuario desde distintos puntos de vista (el qu), los modelos que se utilizan en la fase de diseo representan las caractersticas del sistema que nos permitirn implementarlo de forma efectiva (el cmo). Un software bien diseado debe exhibir determinadas caractersticas. Su diseo debera ser modular en vez de monoltico. Sus mdulos deberan ser cohesivos (encargarse de una tarea concreta y slo de una) y estar dbilmente acoplados entre s (para facilitar el mantenimiento del sistema). Cada mdulo debera ofrecer a los dems interfaces bien definidas y ocultar sus detalles de implementacin .

Diseo
Por ltimo, debe ser posible relacionar las decisiones de diseo tomadas con los requerimientos del sistema que las ocasionaron (algo que se suele denominar "trazabilidad de los requerimientos"). En la fase de diseo se han de estudiar posibles alternativas de implementacin para el sistema de informacin que hemos de construir y se ha de decidir la estructura general que tendr el sistema (su diseo arquitectnico). El diseo de un sistema es complejo y el proceso de diseo ha de realizarse de forma iterativa. La solucin inicial que propongamos probablemente no resulte la ms adecuada para nuestro sistema de informacin, por lo que deberemos refinarla. Existen autnticos catlogos de patrones de diseo que nos pueden servir para aprender de los errores que otros han cometido sin que nosotros tengamos que repetirlos.

Modelos en la etapa de diseo

Igual que en la etapa de anlisis crebamos distintos modelos en funcin del aspecto del sistema en que centrbamos nuestra atencin, el diseo de un sistema de informacin tambin presenta distintas facetas: - Por un lado, es necesario abordar el diseo de la base de datos. - Por otro lado, tambin hay que disear las aplicaciones que permitirn al usuario utilizar el sistema de informacin. Tendremos que disear la interfaz de usuario del sistema y los distintos componentes en que se descomponen las aplicaciones.

Implementacin
Una vez que sabemos qu funciones debe desempear nuestro sistema de informacin (anlisis) y hemos decidido cmo vamos a organizar sus distintos componentes (diseo), es el momento de pasar a la etapa de implementacin, pero nunca antes. Antes de escribir una sola lnea de cdigo es fundamental haber comprendido bien el problema que se pretende resolver y haber aplicado principios bsicos de diseo que nos permitan construir un sistema de informacin de calidad. Para la fase de implementacin hemos de seleccionar las herramientas adecuadas, un entorno de desarrollo que facilite nuestro trabajo y un lenguaje de programacin apropiado para el tipo de sistema que vayamos a construir. La eleccin de estas herramientas depender en gran parte de las decisiones de diseo que hayamos tomado hasta el momento y del entorno en el que nuestro sistema deber funcionar.

Implementacin
A la hora de programar, deberemos procurar que nuestro cdigo no resulte indescifrable. Adems de las tareas de programacin asociadas a los distintos componentes de nuestro sistema, en la fase de implementacin tambin hemos de encargarnos de la adquisicin de todos los recursos necesarios para que el sistema funcione (por ejemplo, las licencias de uso del sistema gestor de bases de datos que vayamos a utilizar). Usualmente, tambin desarrollaremos algunos casos de prueba que nos permitan ir comprobando el funcionamiento de nuestro sistema conforme vamos construyndolo.

Pruebas
Errar es humano y la etapa de pruebas tiene como objetivo detectar los errores que se hayan podido cometer en las etapas anteriores del proyecto (y, eventualmente, corregirlos). Su trabajo, es hacerlo antes de que el usuario final del sistema los tenga que sufrir. De hecho, una prueba es un xito cuando se detecta un error (y no al revs, como nos gustara pensar). La bsqueda de errores que se realiza en la etapa de pruebas puede adaptar distintas formas, en funcin del contexto y de la fase del proyecto en la que nos encontremos: En algunas empresas, como Microsoft, se hace una compilacin diaria utilizando los componentes del sistema tal como estn en ese momento y se somete al sistema a una serie de pruebas bsicas.

Pruebas
Una vez "finalizado" el sistema, se realizan pruebas alfa en el seno de la organizacin encargada del desarrollo del sistema. Estas pruebas, realizadas desde el punto de vista de un usuario final, pueden ayudar a pulir aspectos de la interfaz de usuario del sistema - Cuando el sistema no es un producto a medida, sino que se vender como un producto en el mercado, tambin se suelen realizar pruebas beta. Estas pruebas las hacen usuarios finales del sistema ajenos al equipo de desarrollo y pueden resultar vitales para que un producto tenga xito en el mercado. En sistemas a medida, se suele realizar un test de aceptacin que, si se supera con xito, marcar oficialmente el final del proceso de desarrollo y el comienzo de la etapa de mantenimiento. - Durante todo el ciclo de vida del software, se suelen hacer revisiones de todos los productos generados a lo largo del proyecto, desde el documento de especificacin de requerimientos hasta el cdigo de los distintos mdulos de una aplicacin.

Pruebas
Aunque es imposible garantizar la ausencia de errores en el software, una adecuada combinacin de distintas tcnicas de prueba puede ayudar a remover ms del 90% de los errores que se encontrarn a lo largo de toda la vida del sistema. Aunque podamos ser reacios a admitirlo, lo normal es que el 40% de nuestro tiempo lo "perdamos" eliminando errores, mientras que slo empleamos un 20% en la etapa de anlisis, otro 20% en el diseo y el 20% restante en la implementacin del sistema (Robert Glass, Building quality software, 1992). Al realizar cualquiera de los tipos de prueba descritos, es importante recordar que el desarrollo de software es una actividad que se realiza en equipo, por lo que pueden surgir roces personales y disputas polticas entre los miembros del equipo. Las pruebas resultan particularmente delicadas en este sentido, ya que su objetivo es, al fin y al cabo, encontrar defectos.

Instalacin
Una vez concluidas las etapas de desarrollo de un sistema de informacin (anlisis, diseo, implementacin y pruebas), llega el instante de que poner el sistema en funcionamiento, su instalacin o despliegue. De cara a su instalacin, hemos de planificar el entorno en el que el sistema debe funcionar, tanto hardware como software: equipos necesarios y su configuracin fsica, redes de interconexin entre los equipos y de acceso a sistemas externos, sistemas operativos (actualizados para evitar problemas de seguridad), bibliotecas y componentes suministrados por terceras partes.

Uso y mantenimiento
La etapa de mantenimiento consume tpicamente del 40 al 80 por ciento de los recursos de una empresa de desarrollo de software. De hecho, con un 60% de media, es probablemente la etapa ms importante del ciclo de vida del software. Dada la naturaleza del software, que ni se rompe ni se desgasta con el uso, su mantenimiento incluye tres facetas diferentes: - Eliminar los defectos que se detecten durante su vida til (mantenimiento correctivo), lo primero que a uno se le viene a la cabeza cuando piensa en el mantenimiento de cualquier cosa. - Adaptarlo a nuevas necesidades (mantenimiento adaptativo), cuando el sistema ha de funcionar sobre una nueva versin del sistema operativo o en un entorno hardware diferente, por ejemplo. - Aadirle nueva funcionalidad (mantenimiento perfectivo), cuando se proponen caractersticas deseables que supondran una mejora del sistema ya existente.

Uso y mantenimiento
De las distintas facetas del mantenimiento, la eliminacin de defectos slo supone el 17% del costo de mantenimiento de un sistema, mientras que el diseo e implementacin de mejoras es responsable del 60% del costo de mantenimiento. Si examinamos las tareas que se llevan a cabo durante la etapa de mantenimiento, nos encontramos que en el mantenimiento se repiten todas las etapas que ya hemos visto del ciclo de vida de un sistema de informacin. Al tratar principalmente de cmo aadirle nueva funcionalidad a un sistema ya existente, el mantenimiento repite "en miniatura" el ciclo de vida completo de un sistema de informacin.