2012

Ingeniera de sistemas
Paradigmas de la ingeniera de software
En estos temas se abordan las diferentes estrategias para el desarrollo de sistemas de informacin y tener alternativas de solucin a problemas que se presentan en las entidades econmicas

2012

Estrategias para el desarrollo de sistemas

CO N TE NI DO
Estrategia para el desarrollo de sistemas ..................................................................................................................3 Modelo de ciclo de vida clasico ..............................................................................................................................3 Modelo de ciclo de vida clasico ...........................................................................................................................3 Modelo semiestructurado........................................................................................................................................7 Modelo semiestructurado ....................................................................................................................................7 Modelo estructurado ...............................................................................................................................................9 Modelo estructurado............................................................................................................................................9 Modelo basado en prototipos............................................................................................................................... 12 Modelo basado en prototipos ........................................................................................................................... 12 Modelo basado en prototipos............................................................................................................................... 13 Modelo basado en prototipos ........................................................................................................................... 13

FCAeI

Estrategias para el desarrollo de sistemas

ES TR ATEG I A P AR A EL D E S AR RO LLO D E SI S TEM AS MO DELO DE CI CLO DE V I D A CLA SI CO MO DELO DE CI CLO DE V I D A CLA SI CO

Ciclo de vida clsico del desarrollo de sistemas1 El desarrollo de sistemas, es un proceso formado por las etapas de anlisis y diseo, comienza cuando la administracin o algunos miembros del personal encargado de desarrollar sistemas, detectan un sistema de la empresa que necesita mejoras. El mtodo del ciclo de vida para desarrollo de sistemas (SDLC) es el conjunto de actividades que los analistas, diseadores y usuarios realizan para desarrollar e implantar un sistema de informacin. Esta seccin examina cada una de las seis actividades que constituyen el ciclo de vida de desarrollo de sistemas. En la mayor parte de las situaciones dentro de una empresa todas las actividades estn muy relacionadas, en general son inseparables, y quiz sea difcil determinar el orden de los pasos que se sigue para efectuarlas. Las diversas partes del proyecto pueden encontrarse al mismo tiempo en distintas fases de desarrollo; algunos componentes en la fase de anlisis mientras que otros en etapas avanzadas de diseo.

El mtodo del ciclo de vida para desarrollo de sistemas consta de las siguientes actividades: 1. 2. 3. 4. 5. 6. Investigacin preliminar. Determinacin de los requerimientos. Diseo del sistema. Desarrollo de software. Prueba de los sistemas. Implantacin y evaluacin.

Senn, A. James (2005) Anlisis y diseo de sistemas de informacin, Mxico. McGraw Hill. Pp 33-37

FCAeI

Estrategias para el desarrollo de sistemas

Investigacin preliminar La solicitud para recibir ayuda de un sistema de informacin puede originarse por varias razones; sin importar cuales sean estn, el ceso se inicia siempre con la peticin de una persona administrador, empleado o especialista en sistemas-. Cuando se formula la solicitud comienza la primera actividad de sistemas: la investigacin preliminar. Esta actividad tiene tres partes: aclaracin de la solicitud, estudio de factibilidad y aprobacin de la solicitud. Aclaracin de la solicitud muchas solicitudes que provienen de empleados y usuarios no estn formuladas de manera clara. Por siguiente, antes de considerar cualquier investigacin de sistemas, la solicitud de proyectos debe examinarse para determinar con precisin lo que el solicitante desea. Si este tiene una buena idea de lo que necesita pero no esta seguro como expresarlo, entonces bastar con hacer una llamada telefnica. Por otro lado, si el solicitante pide ayuda sin saber que es lo que esta mal o donde se encuentra el problema, la aclaracin del mismo se vuelve mas difcil. En cualquier caso, antes de seguir adelante, la solicitud de proyecto debe estar claramente planteada. Estudio de factibilidad un resultado importante de la investigacin preliminar es la determinacin de que el sistema solicitado sea factible. En la investigacin preliminar existen tres aspectos relacionados con el estudio de factibilidad. 1. Factibilidad tcnica. El trabajo para el proyecto, puede realizarse con el equipo actual, la tecnologa existente de software y el personal disponible? Si se necesita nueva tecnologa, Cul es la posibilidad de desarrollarla? 2. Factibilidad econmica. Al crear el sistema, los beneficios que se obtienen sern suficientes para aceptar los costos?, los costos asociados con la decisin de no crear el sistema son tan grandes que se debe aceptar el proyecto? 3. Factibilidad operacional. Si se desarrolla e implanta, ser utilizado el sistema?, existir cierta resistencia al cambio por parte de los usuarios que de cmo resultado una disminucin de los posibles beneficios de la aplicacin. El estudio de factibilidad lo lleva a cabo un pequeo equipo de personas (en ocasiones una o dos) que est familiarizado con tcnicas de sistemas de informacin; dicho equipo comprende la parte de la empresa u organizacin que participara o se ver afectada por el proyecto, y es gente experta en los procesos de anlisis y diseo de sistemas. En general, las
FCAeI

Estrategias para el desarrollo de sistemas

personas que son responsables de evaluar la factibilidad son analistas capacitados o directivos. Aprobacin de la solicitud no todos los proyectos solicitados son deseables o factibles. Algunas organizaciones reciben tantas solicitudes de sus empleados que solo es posible atender unas cuantas. Sin embargo, aquellos proyectos que son deseables y factibles deben incorporarse en los planes. En algunos casos el desarrollo puede comenzar inmediatamente, aunque lo comn es que los miembros del equipo de sistemas se encuentren ocupados con otros proyectos. Cuando esto ocurre, la administracin decide que proyectos son los ms importantes y decide el orden en que se llevara a cabo. Muchas organizaciones desarrollan sus planes para sistemas de informacin con el mismo cuidado con el que planifican nuevos productos y programas de fabricacin o la expansin de sus instalaciones. Despus de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario para terminarlo y las necesidades de personal; con esta informacin se determina donde ubicarlo dentro de la lista existente de proyectos. Determinacin de los requerimientos del sistema El aspecto fundamental del anlisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. (es por esta razn que el proceso de adquirir informacin se denomina, con frecuencia, investigacin detallada.) Conforme se renen los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar las caractersticas que debe tener el nuevo sistema, incluyendo la informacin que deben producir los sistemas junto con caractersticas operacionales tales como controles de procesamiento, tiempos de respuesta y mtodos de entrada y salida. Diseo del sistema El diseo de un sistema de informacin produce los detalles que establecen la forma en la que el sistema cumplir con los requerimientos identificados durante la fase de anlisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseo lgico en contraste con la de desarrollo del software, a la que denominan diseo fsico. Los analistas de sistemas comienzan el proceso de diseo identificndolos reportes y adems salidas que debe producir el sistema. Hecho lo anterior se determinan con toda precisin los datos especficos para cada reporte y salida. Es comn que los diseadores hagan un bosquejo del formato o pantalla que esperan que aparezca cuando el sistema este terminado.

FCAeI

Estrategias para el desarrollo de sistemas

Lo anterior se efecta en papel o en la pantalla de una terminal utilizando para ello algunas de las herramientas automatizadas disponibles para el desarrollo de sistemas. El diseo de un sistema tambin indica los datos de entrada, aquellos que sern calculados y los que deben ser almacenados. Asimismo, se escriben con todo detalle los procedimientos de clculo y los datos individuales. Los diseadores seleccionan las estructuras de archivos y los dispositivos de almacenamiento, tales como discos y cintas magnticos o incluso archivos en papel. Los procedimientos que se escriben indican como procesar los datos y producir las salidas. Los documentos que contienen las especificaciones de diseo representan a este de muchas maneras (diagramas, tablas y smbolos especiales.) la informacin detallada del diseo se proporciona al equipo de programacin para comenzar la fase de desarrollo de software. Desarrollo de software Los encargados de desarrollar software pueden instalar (o modificar y despus instalar) software comprado a terceros o escribir programas diseados a la medida del solicitante. La eleccin depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores. Por regla general, los programadores (o analistas programadores) que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales, tal como se indica en la narracin al inicio del captulo. En empresas pequeas, donde no hay programadores, se pueden contratar servicios externos de programacin. Los programadores tambin son responsables de la documentacin de los programas y de proporcionar una explicacin de cmo y por que ciertos procedimientos se codifican en determinada forma. La documentacin es esencial para probar el programa y llevar a cabo el mantenimiento una vez que la aplicacin se encuentra instalada. Prueba de sistemas Durante la fase de prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de q ue 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 alimenta como entradas conjuntos de datos de prueba para su procesamiento y despus se examinan los resultados. En ocasiones se permite que varios usuarios utilicen el sistema para que los analistas observen si tratan de emplearlo en formas no previstas. Es preferible descubrir cualquier sorpresa antes de que la organizacin implante el sistema y dependa de l.
FCAeI

Estrategias para el desarrollo de sistemas

En muchas organizaciones, las pruebas son producidas por personas ajenas al grupo que escribi los programas originales; con esto se persigue asegurar, por una parte, que las pruebas sean completas e imparciales y, por otra, que el software sea ms confiable. Implantacin y evaluacin La implantacin es el proceso de verificar e instalar nuevo equipo entrenar a los usuarios, instalar la aplicacin y construir todos los archivos de datos necesarios para utilizarla. Dependiendo del tamao de la organizacin que empleara la aplicacin y el riesgo asociado con su uso, puede elegirse comenzar la operacin del sistema solo en un rea de la empresa (prueba piloto), por ejemplo en un departamento o con 7una o dos personas. Algunas veces se deja que los dos sistemas, el viejo y el nuevo, trabajen en forma paralela con la finalidad de comparar los resultados. En otras circunstancias, el viejo sistema deja de utilizarse determinado da para comenzar a emplear el nuevo al da siguiente. Cada estrategia de implantacin tiene sus meritos de acuerdo con la situacin que se considere dentro de la empresa. Sin importar cual sea la estrategia utilizada, los encargados de desarrollar el sistema procuran que el uso inicial del sistema se encuentre libre de problemas. Con el transcurso del tiempo debe realizarse mantenimiento a las aplicaciones, realizar cambios y modificaciones en el software, archivos o procedimientos para satisfacer las nuevas necesidades de los usuarios.

MO DELO SE MI EST R UCT UR A DO MO DELO SE MI EST R UCT UR A DO

2

Dentro del modelo semi-estructurado encontramos detalles como, la implementacin descendente que significa que se pondrn en ejecucin paralelamente parte de la codificacin y de las pruebas. Dndose con lo anterior una retroalimentacin entre la codificacin, la prueba y la eliminacin de las fallas. Como ltimo punto acerca del modelo semi-estructurado, tenemos que una gran parte del trabajo que se realiza bajo el nombre de "diseo estructurado" es en realidad un esfuerzo
2

Instituto Tecnolgico de la Paz. Anlisis y Diseo de sistemas (agosto 2011). Recuperado de http://sistemas.itlp.edu.mx/tutoriales/analisis/23.htm

FCAeI

Estrategias para el desarrollo de sistemas

manual para enmendar especificaciones errneas. Otra funcin de los diseadores, es traducir un documento narrativo, ambiguo, monoltico y redundante a un modelo til, que sirva de base para derivar la jerarqua de mdulos que cumplan con los requisitos del usuario. En general con este enfoque de desarrollo de sistemas los diseadores tenan poco contacto con el analista que escriba la especificacin y definitivamente "no tena contacto con el usuario".

Modelo semiestructurado

FCAeI

Estrategias para el desarrollo de sistemas

MO DELO EST RU CT U RADO MO DELO EST RU CT U RADO 3

En el modelo estructurado se examinan brevemente las nueve actividades y los tres terminadores que lo componen. Los terminadores son los usuarios, los administradores, y el personal de operaciones. Los cuales se tratan de individuos o grupos que proporcionan la entrada al equipo del proyecto, y son los beneficiados finales del sistema.

Modelo estructurado

Instituto Tecnolgico de la Paz. Anlisis y Diseo de sistemas (agosto 2011). Recuperado de http://sistemas.itlp.edu.mx/tutoriales/analisis/23.htm

FCAeI

10

Estrategias para el desarrollo de sistemas

Actividad 1: La encuesta Esta actividad tambin se conoce como el estudio de factibilidad o como el estudio inicial de negocios. Empieza cuando el usuario solicita que una o ms partes de su sistema se automaticen. Los principales objetivos de la encuesta son: Identificar a los usuarios responsables y crear ""un campo de actividad" inicial del sistema. Identificar las deficiencias actuales en el ambiente del usuario. Establecer metas y objetivos para un sistema nuevo. Determinar si es factible automatizar el sistema y de ser as, sugerir escenarios aceptables. Preparar el esquema que se usar para guiar el resto del proyecto. En general, la encuesta ocupa slo del 5 al 10 por ciento del tiempo y los recursos de todo el proyecto, y para los proyectos pequeos y sencillos pudiera ni siquiera ser una actividad formal. A pesar de todo lo anterior, es una actividad importante debido a que la administracin pudiera decidir cancelar el proyecto si no parece atractivo desde el punto de vista de costobeneficio. Actividad 2: El anlisis de sistemas El propsito principal de la actividad de anlisis es transformar sus dos entradas - o insumos o factores - principales, las polticas del usuario y el esquema del proyecto, en una especificacin estructurada. Esto implica modelar el ambiente del usuario con diagramas de flujo de datos, diagramas de entidad-relacin, diagramas de transicin de estado, etc. El proceso paso a paso del anlisis de sistemas implica el desarrollo de un modelo ambiental y el desarrollo de un modelo de comportamiento, los cuales se combinan para formar el modelo esencial que representa una descripcin formal de lo que el nuevo sistema debe hacer, independientemente de la naturaleza de la tecnologa que se use para cubrir los requerimientos. Al final de la actividad de anlisis tambin se debe preparar un conjunto de presupuestos y clculos de costo y beneficio ms precisos y detallados.

FCAeI

Estrategias para el desarrollo de sistemas

Actividad 3: El diseo

11

La actividad de diseo se dedica a asignar porciones de la especificacin (modelo esencial) a procesadores adecuados (mquinas o humanos) y a labores apropiadas (o tareas, particiones, etc.) dentro de cada procesador. Dentro de cada labor, la actividad de diseo se dedica a la creacin de una jerarqua apropiada de mdulos de programas y de interfases entre ellos para implantar la especificacin creada en la actividad 2. Adems, se ocupa de la transformacin de modelos de datos de entidad-relacin en un diseo de base de datos. Actividad 4: Implantacin Esta actividad incluye la codificacin y la integracin de mdulos en un esqueleto progresivamente ms complejo del sistema final. Por eso, la actividad 4 incluye tanto programacin estructurada como implantacin descendente. Actividad 5: Generacin de pruebas de aceptacin La especificacin estructurada debe contener toda la informacin necesaria para definir un sistema que sea aceptable desde el punto de vista del usuario. Por eso, una vez generada la especificacin, puede comenzar la actividad de producir un conjunto de casos de prueba de aceptacin desde la especificacin estructurada. Actividad 6: Garanta de calidad La garanta de calidad tambin se conoce como la prueba final o la prueba de aceptacin. Esta actividad requiere como entradas los datos de la prueba de aceptacin generada en la actividad 5 y el sistema integrado producido en la actividad 4. Actividad 7: Descripcin del procedimiento Esta actividad implica la generacin de una descripcin formal de las partes del sistema que se harn en forma manual, lo mismo que la descripcin de como interactuarn los usuarios con la parte automatizada del nuevo sistema. El resultado de la actividad 7 es un manual para el usuario. Actividad 8: Conversin de bases de datos En algunos proyectos, la conversin de bases de datos involucraba ms trabajo que el desarrollo de programas de computadoras para el nuevo sistema. En otros casos, pudiera no haber existido una base de datos que convertir. En el caso general, esta actividad requiere como entrada la base de datos actual del usuario, al igual que la especificacin del diseo producida por medio de la actividad 3.
FCAeI

12

Estrategias para el desarrollo de sistemas

Actividad 9: Instalacin En esta actividad sus entradas son el manual del usuario producido en la actividad 7, la base de datos convertida que se cre con la actividad 8 y el sistema aceptado producido por la actividad 6. En algunos casos la instalacin pudiera significar simplemente un cambio de la noche a la maana al nuevo sistema; en otros casos, la instalacin pudiera ser un proceso gradual, en el que un grupo tras otro de usuario van recibiendo manuales y entrenamiento y comenzado a usar el nuevo sistema.

MO DELO EN ESPI R A L MO DELO EN ESPI R A L 4

En 1976 Barry Boehm propuso un nuevo modelo de ciclo de vida del desarrollo. El nuevo modelo es conocido como modelo de espiral y busca manejar los riesgos asociados al modelo de cascada. El modelo en espiral es, esencialmente, un desarrollo completo en cascada en cada iteracin. El modelo de Boehm es tambin conocido como modelo evolutivo o modelo del caracol.

Pressman, S. Roger (2005) Ingeniera del software. Espaa. Mc Graw Hill.pp. 30-32

FCAeI

Estrategias para el desarrollo de sistemas

Modelo en espiral

13

En cada una de las iteraciones, se deben cumplir cuatro actividades principales (una en cada cuadrante): Planeacin: determinacin de los objetivos, alternativas y restricciones Anlisis de riesgo: anlisis de alternativas e identificacin/resolucin de riesgos Ingeniera: desarrollo del producto hasta el siguiente nivel. Evaluacin: valoracin por parte del cliente de los resultados obtenidos. El movimiento de la espiral, ampliando con cada iteracin su amplitud radial, indica que cada vez se van construyendo versiones sucesivas del software, cada vez ms completas. Uno de los puntos ms interesantes del modelo, es la introduccin al proceso de desarrollo a las actividades de anlisis de los riesgos asociados al desarrollo y a la evaluacin por parte del cliente de los resultados del software. El modelo en espiral maneja el concepto de versiones del sistema de software. Cada que se completa una versin del sistema de software, se vuelven a estudiar los requerimientos y el impacto del sistema sobre los mismos para crear una nueva versin del sistema. Este modelo es similar al manejo de productos comerciales que liberan versiones, cada vez ms completas y complejas.

MO DELO BA SA DO EN PRO T O TI PO S MO DELO BA SA DO EN PRO T O TI PO S 5

Una variacin del modelo en espiral es utilizada por algunos nuevos mtodos. Los nuevos mtodos se basan nicamente en la construccin incremental de prototipos. En estos modelos no se genera un sistema completo en cada iteracin, sino que cada iteracin genera tan slo un nuevo prototipo, cada vez ms cercano al sistema final.

Menndez Rafael, Barzanallana Asensio. (Octubre 2007). Ejemplo de resolucin de trabajo propuesto en ingeniera del software.(Agosto 2011). Recuperado de: http://www.um.es/docencia/barzana/IAGP/IAGP2-Ingenieria-software-trabajo.html

FCAeI

14

Estrategias para el desarrollo de sistemas

Estos nuevos mtodos son conocidos actualmente como desarrollo rpido de aplicaciones o RAD (Rapid Applications Development). Este estilo fue promovido en 1985 por DuPont Co. (inventores del nylon y la lycra) mediante una metodologa propia conocida como produccin iterativa de prototipos o RIIP. James Martin realiz un libro posterior definiendo una metodologa similar e introduciendo el trmino RAD.

Un escenario para la construccin de prototipos. Todos los proyectos de ingeniera de software comienzan con una peticin del cliente. La peticin puede estar en la forma de una memoria que describe un problema, un informe que define un conjunto de objetivos comerciales o del producto, una peticin de propuesta formal de una agencia o compaa exterior, o una especificacin del sistema que ha asignado una funcin y comportamiento al software, como un elemento de un sistema mayor basado en computadora. Suponiendo que existe una peticin para un programa de una de las formas dichas anteriormente, para construir un prototipo del software se aplican los siguientes pasos: PASO 1. Evaluar la peticin del software y determinar si el programa a desarrollar es un buen candidato para construir un prototipo. Debido a que el cliente debe interaccionar con el prototipo en los ltimos pasos, es esencial que: 1) el cliente participe en la evaluacin y refinamiento del prototipo, y 2) el cliente sea capaz de tomar decisiones de requerimientos de una forma oportuna. Finalmente, la naturaleza del proyecto de desarrollo tendr una fuerte influencia en la eficacia del prototipo. PASO 2. Dado un proyecto candidato aceptable, el analista desarrolla una representacin abreviada de los requerimientos. Antes de que pueda comenzar la construccin de un prototipo, el analista debe representar los dominios funcionales y de informacin del programa y desarrollar un mtodo razonable de particin. La aplicacin de estos principios de anlisis fundamentales, pueden realizarse mediante los mtodos de anlisis de requerimientos. PASO 3. Despus de que se haya revisado la representacin de los requerimientos, se crea un conjunto de especificaciones de diseo abreviadas para el prototipo. El diseo debe ocurrir antes de que comience la construccin del prototipo. Sin embargo, el diseo de un prototipo se enfoca normalmente hacia la arquitectura a nivel superior y a los aspectos de diseo de datos, en vez de hacia el diseo procedimental detallado.
FCAeI

Estrategias para el desarrollo de sistemas

15

PASO 4. El software del prototipo se crea, prueba y refina idealmente, los bloques de construccin de software preexisten se utilizan para crear el prototipo de una forma rpida. Desafortunadamente, tales bloques construidos raramente existen. Incluso si la implementacin de un prototipo que funcione es impracticable, es escenario de construccin de prototipos puede aun aplicarse. Para las aplicaciones interactivas con el hombre, es posible frecuentemente crear un prototipo en papel que describa la interaccin hombre-maquina usando una serie de hojas de historia. PASO 5. Una vez que el prototipo ha sido probado, se presenta al cliente, el cual "conduce la prueba" de la aplicacin y sugiere modificaciones. Este paso es el ncleo del mtodo de construccin de prototipo. Es aqu donde el cliente puede examinar una representacin implementada de los requerimientos del programa, sugerir modificaciones que harn al programa cumplir mejor las necesidades reales. PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos estn formalizados o hasta que el prototipo haya evolucionado hacia un sistema de produccin.

Para que el Modelo basados en prototipos que sea efectivo Debe ser un sistema con el que se pueda experimentar Debe ser comparativamente barato Debe desarrollarse rpidamente nfasis en la interfaz de usuario Equipo de desarrollo reducido Herramientas y lenguajes adecuados

FCAeI

16

Estrategias para el desarrollo de sistemas

FCAeI

Estrategias para el desarrollo de sistemas

17

Referencias Bibliogrficas y electrnicas

Senn, A. James (2005) Anlisis y diseo de sistemas de informacin, Mxico. McGraw Hill. Pressman, S. Roger (2005) Ingeniera del software. Espaa. Mc Graw Hill. Instituto Tecnolgico de la Paz. Anlisis y Diseo de sistemas (agosto 2011). Recuperado de http://sistemas.itlp.edu.mx/tutoriales/analisis/23.htm Menndez Rafael, Barzanallana Asensio. (Octubre 2007). Ejemplo de resolucin de trabajo propuesto en ingeniera del software.(Agosto 2011). Recuperado de: http://www.um.es/docencia/barzana/IAGP/IAGP2-Ingenieria-software-trabajo.html

FCAeI