unidad1-teorico2015

Universidad Tecnológica Nacional – Facultad Regional Córdoba Tecnicatura Superior en Programación Metodología de Sistemas - Año 2015

Unidad 1: Ciclo de Vida de los sistemas de información

Página 1 de 26

1-Introducción

Un sistema es un conjunto de partes o elementos organizadas y relacionadas que interactúan entre sí para lograr un objetivo. Los sistemas reciben (entrada) datos, energía o materia del ambiente y proveen (salida) información, energía o materia. - Un sistema puede ser físico o concreto (una computadora, un televisor, un humano,etc) o puede ser abstracto o conceptual (un software)

- Cada sistema existe dentro de otro más grande, por lo tanto un sistema puede estar formado por subsistemas y elementos, y a la vez puede ser parte de un supersistema (suprasistema). - Los sistemas tienen límites o fronteras, que los diferencian del ambiente. Ese límite puede ser físico (el gabinete de una computadora) o conceptual. Si hay algún intercambio entre el sistema y el ambiente a través de ese límite, el sistema es abierto, de lo contrario, el sistema es cerrado. Un grupo de elementos o partes ¿es un sistema? Un grupo de elementos no constituye un sistema si no hay una relación e interacción entre estos, que de la idea de un "todo" con un propósito.



Página 2 de 26

2-Conceptos básicos de sistema de información

Las tecnologías de la información y la comunicación (TIC o NTIC para Nuevas Tecnologías

de la Información y de la Comunicación o IT para «Information Technology») agrupan los elementos y las técnicas utilizadas en el tratamiento y la transmisión de las informaciones, principalmente de informática, Internet y telecomunicaciones. En este nuevo paradigma, la información debe ser administrada de forma correcta, teniendo en cuenta que en la producción, distribución, seguridad, almacenamiento y recuperación de la información existen costos y riesgos asociados como ocurre con cualquier otro recurso de una organización y/o cualquier otro medio necesario para propagar los conocimientos y facilitar la comprensión mutua.

La información no es un dato aislado, es más bien una colección de hechos significativos y pertinentes, para el organismo u organización que los percibe. La definición de información es la siguiente: Información es un conjunto de datos significativos y pertinentes que describan sucesos o entidades.

¿Cuál es la aplicación de los sistemas de información?

Los sistemas de información tratan con el desarrollo, uso y manejo de la organización como una infraestructura IT. En lo Post industrial, era de información, el objetivo de las compañías cambió de ser conocimiento orientado a productos, a un sentido en el que los operadores de mercado hoy en día compiten en proceso e innovación más que en producto. La mayor ventaja de las compañías en hoy en día, es su información, representada en personas, experiencia, conocimiento técnico, innovaciones(patentes, derechos de autor, secretos de intercambio), para el operador de mercado sea capaz de

competir, debe tener una fuerte infraestructura de información. Hasta ahora, el estudio de los sistemas de información, se enfoca en “PORQUE” y “COMO” la tecnología puede ser puesta en mejor uso para servir al flujo de información dentro de la organización. Los sistemas de información tienen diferentes áreas de trabajo:

Manejo de sistemas de información Desarrollo de sistemas de información

Concepto: Un sistema de información es un conjunto integrado de: datos, procedimientos, recursos, hardware y software que funcionan con un objetivo común ya sea para automatizar tareas, apoyar a la toma de decisiones de de una organización ó para brindar servicio de soporte que coloca a la organización en un nivel de mayor competitividad.

Los sistemas de información se desarrollan para permitir la gestión y administración de toda la información necesaria para el correcto desarrollo de las actividades de una organización. Para poder determinar a qué procesos de la organización brindará apoyo el sistema de información y cuál será la información de salida que debería producir, es necesario realizar un estudio de los requerimientos de información que se presentan en



Página 3 de 26

cada organización en particular.(La determinación de los requerimientos sugiere estudiar el sistema actual con la finalidad de entender cómo trabaja y dónde se debe mejorar).

Además del objetivo es importante definir de un sistema de información los propósitos o alcances, es decir todos aquellos procesos que tengan que ver con la captación, procesamiento y distribución de la información de la organización en el que se encuentra inserto. Para poder ejemplificar estos conceptos presentamos la figura 4 que ilustra lo explicado: Un sistema de información realiza tres actividades básicas: entrada, procesamiento y salida de información.

Posee

Sistema bajo Estudio

(Sist.Objeto)

Organización o parte de una organización

Requerimientos de Información

Sistema de Información (Producto)

Brinda información al

Captar Procesar Brindar Información

Tiene

debe

Figura 4. Definición de un sistema de información.

Entrada Proceso

Salida

Figura 2. Estructura básica de un sistema de información

Retroalimentación



Página 4 de 26

Evolución de los sistemas de información

Los primeros sistemas, en aparecer, fueron los TPS, en la década de los 60. Según la función a la que vayan destinados o el tipo de usuario final del mismo, los SI pueden clasificarse en:

Sistema de procesamiento de transacciones (TPS).- Gestiona la información referente a las transacciones producidas en una empresa u organización.

Sistemas de información gerencial (MIS).- Orientados a solucionar problemas empresariales en general.

Sistemas de soporte a decisiones (DSS).- Herramienta para realizar el análisis de las diferentes variables de negocio con la finalidad de apoyar el proceso de toma de decisiones.

Sistemas de información ejecutiva (EIS).- Herramienta orientada a usuarios de nivel gerencial, que permite monitorizar el estado de las variables de un área o unidad de la empresa a partir de información interna y externa a la misma.

Sistemas de automatización de oficinas (OAS).- Aplicaciones destinadas a ayudar al trabajo diario del administrativo de una empresa u organización.

Sistema experto (SE).- Emulan el comportamiento de un experto en un dominio concreto. Sistema Planificación de Recursos (ERP).- Integran la información y los procesos de una

organización en un solo sistema.

Otra clasificación, según el entorno y el objetivo de aplicación

Entorno transaccional: Una transacción es un suceso o evento que crea/modifica los datos. El procesamiento de transacciones consiste en captar, manipular y almacenar los datos, y también, en la preparación de documentos; en el entorno transaccional, por tanto, lo importante es qué datos se modifican y cómo, una vez ha terminado la transacción. Los TPS son los SI típicos que se pueden encontrar en este entorno.Ejemplo: un sistema de facturación.

Entorno decisional: Este es el entorno en el que tiene lugar la toma de decisiones; en una empresa, las decisiones se toman a todos los niveles y en todas las áreas (otra cosa es si esas decisiones son estructuradas o no), por lo que todos los SI de la organización deben estar



Página 5 de 26

preparados para asistir en esta tarea, aunque típicamente, son los DSS los que encargan de esta función. Si el único SI de una compañía preparado para ayudar a la toma de decisiones es el DSS, éste debe estar adaptado a todos los niveles jerárquicos de la empresa.Ejemplo:sistema de ventas de una organización.

Estratégicos: Los sistemas de información estratégicos consisten en manejar la información procesada de una organización de modo que se pueda utilizar para ser competitivos renunciando

a algunas cosas para alcanzar el objetivo propuesto. Ver ejemplo a continuación.

ERP (Enterprise Resource Planning)

Sistemas gerenciales que integran y manejan muchos de los negocios asociados con las operaciones de producción y de los aspectos de distribución de una compañía en la producción de bienes o servicios. Combina funciones de varios departamentos en una sola aplicación, con una sola base de datos para compartir información más fácilmente y comunicarse entre ellos. Los ERP funcionan ampliamente en las empresas. Entre sus módulos más comunes se encuentran el de manufactura o producción, almacenamiento, logística e información tecnológica, incluyen

además la contabilidad, y suelen incluir un sistema de administración de recursos humanos, y herramientas de mercadotecnia y administración estratégica.

Los sistemas ERP son llamados ocasionalmente back office (trastienda) ya que indican que el cliente y el público general no están directamente involucrados. Este sistema es, en contraste con el sistema de apertura de datos (front office), que crea una relación administrativa del consumidor o servicio al consumidor (CRM), un sistema que trata directamente con los clientes, o con los sistemas de negocios electrónicos tales como comercio electrónico, administración electrónica, telecomunicaciones electrónicas y finanzas electrónicas; asimismo, es un sistema que trata directamente con los proveedores, no estableciendo únicamente una relación administrativa con ellos (SRM-Supplier Relationship Management)

Tiene las siguientes características:

Flexibilidad Un sistema ERP es flexible de tal manera que responde a las constantes transformaciones de las empresas. La tecnología cliente/servidor permite al sistema ERP operar sobre diferentes bases de datos por las conexiones de bases de datos abiertas, pues es muy probable que el mismo producto migre de un área de producción para otra durante el ciclo total de producción.



Página 6 de 26

- Modularidad El sistema ERP es un sistema de arquitectura abierta, es decir, puede usar un módulo libremente sin que este afecte los restantes. Debe también facilitar la expansión y o/adaptabilidad de otros módulos posteriormente. - Conectividad El sistema no se debe confinar al espacio físico de la empresa y permitir la conexión con otras entidades pertenecientes al mismo grupo empresarial. - Selección de diferentes formas de negocio debe contener una selección de las mejores prácticas de negocios utilizadas en todo el mundo. - Simulación de la Realidad debe permitir la simulación de la realidad de la empresa, de forma alguna el control del sistema debe estar fuera del proceso de negocio y debe ser posible la elaboración de informes para los usuarios que controlan el sistema. Los ERP de última generación tienden a implementar en sus circuitos una abstracción de la administración denominada MECAF (Método de Expresión de Circuitos Administrativos Formalizado), lo cual los provee de una gran flexibilidad para describir diferentes circuitos usados en distintas empresas. Esto simplifica la regionalización y la adaptación de los ERP a diferentes mercados.



Página 7 de 26

3-Ciclo de Vida de un sistema

El ciclo de vida de desarrollo de sistemas informáticos puede dividirse en actividades o fases que, en general, se ajustan al esquema mostrado en el gráfico. Este esquema gráfico es el ciclo de vida típico, dado que existen gran cantidad de variantes que dependen de la organización y del tipo de sistema que se realizará, etc.

Esquema básico del ciclo de vida de un proyecto

Inicio: se define la “visión del sistema”, se establece el alcance del proyecto y se toma la decisión de

comenzar con el mismo, es decir, se decide realizar la inversión de dinero y esfuerzo para analizar en detalle el sistema a construír. En el caso de tratarse de la modificación o del agregado de funcionalidad a un sistema existente, esta fase puede ser corta y sencilla, basada en los pedidos de los usuarios, en reportes de problemas o en la necesidad de incorporar avances tecnológicos.

Elaboración: su propósito, en primer lugar, es analizar el sistema de negocio para el cual se busca una

solución. En segundo término, definir la estructura preliminar del sistema y en tercera instancia identificar los factores de riesgo del proyecto y por último, elaborar un plan detallado del mismo.

Construcción: consiste en la fabricación del sistema y de los productos de apoyo necesarios, tales como

documentación y los casos de prueba del sistema. En esta fase también se expanden y revisan los productos o resultados obtenidos en las fases anteriores.

Transición: es aquella en la cual el sistema se entrega a los usuarios. Esta fase incluye actividades de

instalación, configuración, soporte a los usuarios, correcciones, etc. Y finaliza cuando los usuarios están satisfechos con el sistema, lo cual suele implicar una aceptación formal por parte de los mismos.

El desarrollo de sistemas puede verse como una sucesión de iteraciones, a través de las cuales el sistema evoluciona en forma incremental, es decir, va creciendo en cada una de dichas iteraciones. Cada iteración termina con la generación del sistema en diferentes estados de avance, que puede ser un subconjunto de la visión total.

Las iteraciones de un ciclo pueden superponerse y, en algunos casos, pueden realizarse en paralelo. El número y la duración de las iteraciones no es una variable fija, sino que depende de algunas características del proyecto como: tipo de negocio, tamaño del proyecto, tipo de aplicación y restricciones (seguridad, performance, etc.).



Página 8 de 26

Esquema del ciclo de vida de las aplicaciones WEB

UWE UML (UML-Based Web Engineering) es una metodología de desarrollo de aplicaciones web, utilizada en la ingeniería web, prestando especial atención en sistematización y personalización (sistemas adaptativos).

Esta metodología para el desarrollo de Web, se basa en la “Ingeniería Web”:

1-Ingenieria de requisitos: implica el planeamiento, gerenciamiento y análisis de requisitos.Restricciones y recursos.

2-Especificacion del sitio: es un modelo conceptual de funcionalidad. 3-Diseño del sitio:proyecto de arquitectura, interfaz y navegación. Clases y colaboraciones. 4-Implementacion del sitio: 5-Utilización y prueba del sitio:implementación, uso y testing.Validación y verificación. 6-Mantenimiento del sitio:soporte, actualización y correcciones.

1-INGENIERIA DE REQUISITOS La Ingeniería de Requisitos

En el proceso de desarrollo de un sistema, sea o no para la web, el equipo de desarrollo se enfrenta al problema de la identificación de requisitos. La definición de las necesidades del sistema es un proceso complejo pues en él hay que identificar los requisitos que el sistema debe cumplir para satisfacer las necesidades de los usuarios finales y de los clientes. Para realizar este proceso, no existe una única técnica estandarizada y estructurada que ofrezca un marco de desarrollo que garantice la calidad del resultado.

Se debe tener en cuenta que la selección de las técnicas y el éxito de los resultados que se obtengan depende en gran medida tanto del equipo de análisis y desarrollo como de los propios clientes o usuarios que en ella participen. El proceso de especificación de requisitos se puede dividir en tres grandes actividades:



Página 9 de 26

1- captura de requisitos 2- definición de requisitos 3- validación de requisitos Tratamiento de requisitos en la WEB

El desarrollo de sistemas de aplicaciones web, agrupa una serie de características que lo hacen diferente del desarrollo de otros sistemas. Por un lado, hay que tener en cuenta que roles muy diferentes de desarrolladores participan en el proceso: analistas, clientes, usuarios, desarrolladores, diseñadores gráficos, expertos en multimedia y seguridad, etc. Por otro lado, la existencia en estos sistemas de un importante estructura de navegación obliga a un desarrollo preciso de este aspecto que garantice que el usuario no se “pierde en el espacio navegacional del sistema”. Estas ideas unidas al hecho que los sistemas web suelen tratar con múltiples medios y es esencial que ofrezcan una interfaz adecuada en cada momento, obligan a que estos aspectos propios de la web deban ser tratados de una forma especial en el proceso de desarrollo. Estas características especiales también hay que tenerlas en cuenta en la fase de especificación de requisitos. Por ello, la mayoría de las propuestas estudiadas ofrecen diferentes clasificaciones de los requisitos. Sin embargo, la terminología usada no es siempre la misma. Para facilitar la comprensión de las propuestas, antes de presentarlas, presentamos una clasificación de requisitos relevantes en sistemas web.

Requisitos de datos, también denominados requisitos de contenido, requisitos conceptuales o requisitos de almacenamiento de información. Éstos requisitos responden a la pregunta de qué información debe almacenar y administrar el sistema.

Requisitos de interfaz (al usuario), también llamados en algunas propuestas requisitos de interacción o de usuario. Responden a la pregunta de cómo va a interactuar el usuario con el sistema.

Requisitos navegacionales, recogen las necesidades de navegación del usuario.

Requisitos de personalización, describen cómo debe adaptarse el sistema en función de qué usuario interactúe con él y de la descripción actual de dicho usuario.

Requisitos transaccionales o funcionales internos, recogen qué debe hacer el sistema de forma interna, sin incluir aspectos de interfaz o interacción. También son conocidos en el ambiente web como requisitos de servicios.

Requisitos no funcionales, son por ejemplo los requisitos de portabilidad, de reutilización, de entorno de desarrollo, de usabilidad, de disponibilidad, etc.



Página 10 de 26

En la figura 1 se presenta el proceso de ingeniería de requisitos que incluye estas tres actividades. Para la representación se ha usado la notación de diagrama de actividades propuesta en UML [35].

3-Diseño del sitio: plantea algunas diferencias en el desarrollo de aplicaciones web

Actividades genéricas en todos los ciclos de vida

La combinación de paradigmas puede lograr mejores resultados que el uso del alguno en particular.

Simplificando aún más lo anterior podemos decir que existen básicamente tres actividades que se encuentran en todo ciclo de vida más allá del paradigma utilizado:

Análisis Diseño Construcción Gráficamente podemos ver cómo se presentan esas actividades en la figura 9.

El gráfico nos indica que las actividades no son separadas ni secuenciales sino que existe una superposición que va haciendo que las mismas se realicen paralela y simultáneamente.

Análisis Diseño

Construcción

Figura 9. Actividades Genéricas en todos los Ciclos de Vida



Página 11 de 26

4-Metodología de Sistemas ¿Qué es una metodología? Es un mecanismo o método que provee las herramientas y procedimientos confiables y repetibles que se adecuan particularmente bien a los problemas que se pretenden resolver. Vamos a analizar cada uno de los conceptos enunciados para comprender la totalidad de los aspectos que se abarcan cuando hablamos de metodología:

Métodos: indican cómo construir técnicamente el sistema. Abarcan un amplio espectro de tareas: planificación y estimación de proyectos, análisis de los requisitos del sistema y el software, diseño de estructuras de datos, arquitectura de programas y procedimientos algorítmicos, codificación, prueba y mantenimiento. Introducen frecuentemente una notación especial orientada al lenguaje y un conjunto de criterios para lograr calidad.

Herramientas: Suministran un soporte automático o semiautomático para los métodos. Combinación de

hardware, software y bases de datos.

Procedimientos: Relaciona métodos y herramientas. Definen la secuencia en la que se aplican los métodos, las entregas que se requieren, los controles que ayudan a asegurar la calidad y coordinar los cambios, y directrices que ayudan a los gestores del proyecto a evaluar el progreso.

Al realizar el desarrollo de un proyecto de sistemas ES NECESARIO contar con una metodología.

¿Qué debe cubrir una metodología?



Página 12 de 26

Las metodologías de desarrollo de software proveen una cantidad de herramientas, técnicas y modelos para representar el software en las diferentes etapas del ciclo de vida. Según el enfoque de estas metodologías, es decir, su OBJETIVO PRINCIPAL DE DESCOMPOSICION, se las puede clasificar en metodologías orientadas a la estructura de datos, metodologías estructuradas orientadas a los procesos, o metodologías orientadas a objetos.

Orientadas a la estructura de datos: se basan en la idea de que la modelización de la estructura de datos de entrada y salida asegura la calidad del software y por lo tanto define las actividades de desarrollo centrando la atención en la definición de la estructura de los datos, que a través de técnicas se transforman en programas. Orientadas a los procesos: enfatizan la descomposición del software en procesos o funciones, dando como resultado una estructura jerárquica de procesos compuestos por subproceso. La más popular es la metodología del “análisis y de diseño estructurado”. Esta

metodología provee un enfoque de descomposición funcional y ofrece herramientas tales como diagrama de flujo de datos, diagramas de estados y transpones, diagramas de entidades y relaciones y diagramad e estructuras. Orientadas a objetos: descomponen el software en conceptos u objetos. Estos objetos poseen una estructura de datos y un comportamiento que está dado por las funciones que ese objeto realiza. Es decir, los objetos o entidades agrupan datos y los procesos. Estas metodologías se basan en la identificación de objetos, las responsabilidades que ellos tienen asignadas y la forman en que colaboran entre sí para llevar a cabo los requerimientos del software. La metodología de este tipo más conocida es el Proceso Unificado de Desarrollo, que surgió de la unificación de las tres metodologías orientadas a objetos más conocidas. Su objetivo es asegurar

la producción de software de alta calidad que satisfaga las necesidades de los usuarios finales, dentro de una planificación y presupuesto predecibles.

Características principales de una buena metodología Motivar la actividad pretendida. Ser completa. Ser modificable en su corrección. Producir productos contra los que se pueda medir el avance. Ser fácilmente aprovechable en la fase subsiguiente.



Página 13 de 26

Clasificación: Tradicionales y Agiles

Heurística: un conjunto de métodos para ayudar a la habilidad de las personas para aprender

nuevas cosas.

METODOLOGIAS AGILES



Página 14 de 26

Actividad Práctica AULICA: Realice una lectura comprensiva de siguiente texto y construya con sus palabras una interpretación de cada punto. (Principles behind the Agile Manifesto)

1. Our highest priority is to satisfy the customer

through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for

the customer's competitive advantage. 3. Deliver working software frequently, from a

couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need,

and trust them to get the job done. 6. The most efficient and effective method of

conveying information to and within a development

team is face-to-face conversation. 7. Working software is the primary measure of

progress. 8. Agile processes promote sustainable development.

The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts

its behavior accordingly.

1. ..............

2. ………

3. ……

4. ……

5. …..

RESPUESTA



Página 15 de 26

“Nuestra prioridad más alta es la satisfacción del cliente mediante entregas tempranas y continuas de software “con valor”. ” “Bienvenidos sean los cambios de requerimientos, incluso tarde en el desarrollo. Los procesos ágiles soportan el cambio para la

ventaja competitiva del cliente.” “Entregar software funcional frecuentemente, en ciclos semanales o mensuales (menor tiempo del ciclo = mejor).” “El cliente (que conoce el negocio) y los desarrolladores deben trabajar conjunta y diariamente a lo largo del todo el proyecto.” “Construir el proyecto con personas motivadas. Dar el ambiente y el apoyo que necesiten, y confiar en que realizarán el trabajo.” “La forma más eficiente de transmitir información hacia y entre el grupo de desarrollo es la conversación cara a cara.” “Los procesos ágiles promueven una interacción entre partes. Los clientes, desarrolladores y usuarios deben mantener esta

interacción durante todo el proceso en paz.” “La dedicación a la excelencia técnica y a un buen diseño fomenta la agilidad.” “Simpleza –el arte de maximizar la cantidad de trabajo no implementado–es esencial.” “Las mejores arquitecturas, requerimientos y diseños provienen de grupos auto-organizados.” “En intervalos regulares, el equipo reflexiona como volverse más efectivos y ajusta su comportamiento para tal fin.”

Algunos modelos basados en las metodologías agiles son: SCRUM, Crystal Clear, XP, entre otras.

METODOLOGIAS ´TRADICIONALES Existen distintos ciclos de vida para el desarrollo de

sistemas de información, la elección del ciclo de vida para el desarrollo de un proyecto dependerá de la naturaleza del proyecto y de la aplicación, los métodos y herramientas a utilizar y los controles y salidas de información requeridos. Esos ciclos de vida son los que analizaremos a continuación:

Ciclo de vida Clásico o en Cascada

Modelado a partir del ciclo convencional de ingeniería. Este ciclo de vida (Figura 6) exige un enfoque sistemático y secuencial del desarrollo del software que comienza en el nivel del sistema y progresa a través del análisis, diseño, codificación, prueba y mantenimiento. A continuación se describen las actividades que comprende:

Ingeniería de sistemas: abarca la búsqueda de requisitos globales a nivel del sistema con una pequeña

cantidad de análisis y diseño a nivel superior. Análisis de requisitos de software: se centra e intensifica para el software, comprendiendo la naturaleza

del software que hay que construir.

Diseño: es un proceso multipaso que se enfoca sobre cuatro atributos del programa: Estructura de los datos, arquitectura de software, detalle de los procedimientos y diseño de la interfaz. Busca una representación de software que tenga buena calidad antes de codificar.

Codificación/Implementación: el diseño se traduce en esta etapa a un código legible por la máquina. El

diseño se hace detalladamente, la codificación de forma mecánica. Prueba: se asegura que todas las sentencias y funciones del sistema funcionen correctamente.



Página 16 de 26

Operación y Mantenimiento: una vez entregado al cliente quizás se detectan errores o se deban hacer modificaciones, las cuales se hacen en esta etapa.

El Ciclo de Vida en Cascada es el predecesor de todos los modelos de ciclo de vida. Aunque presenta

muchos problemas, sirve de base para otros modelos de ciclo de vida más efectivos. En un modelo en cascada, un proyecto progresa a través de una secuencia ordenada de pasos partiendo del concepto inicial de software hasta la prueba del sistema. El proyecto realiza una revisión al final de cada etapa para determinar si está preparado para pasar a la siguiente etapa, por ejemplo, desde el análisis hacia el diseño. Cuando la revisión determina que el proyecto no está listo para pasar a la siguiente etapa, permanece en la etapa actual hasta que esté preparado. El modelo en cascada está dirigido por documentos, es decir, los productos principales del trabajo que se pasan de etapa en etapa son documentos. En el modelo de cascada pura, las etapas son también discontinuas, es decir, no se solapan. Existe otra versión del modelo en Cascada Pura que es el de Cascada modificada, que permite que las etapas se solapen. El modelo en cascada pura se utiliza correctamente para ciclos de productos en los que se tiene una definición estable del producto, y también cuando se está trabajando con metodologías y técnicas conocidas. En estos casos, el modelo en cascada ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo. Si se está construyendo una versión de mantenimiento bien definida de un producto existente o migrando un producto existente a una nueva plataforma, un ciclo de vida en cascada puede ser una elección correcta para el desarrollo rápido. Por otra parte, el modelo en cascada funciona bien con proyectos complejos que se entienden correctamente, debido a que se pueden obtener beneficios al enfrentarse a la complejidad de forma ordenada. El ciclo de vida de cascada ayuda a minimizar los gastos de la planificación porque permite realizar la misma sin problemas. No proporciona resultados tangibles en forma de software familiarizados con el modelo, la documentación que genera proporciona indicaciones significativas del progreso a lo largo del ciclo de vida. El modelo en cascada funciona especialmente bien si se dispone de personal con poca experiencia, porque presenta el proyecto con una estructura que ayuda a minimizar el esfuerzo inútil. Las desventajas del modelo en cascada pura se centran en la dificultad para especificar claramente los requerimientos al comienzo del proyecto, antes de que se realice ningún trabajo de diseño y antes de escribir ningún código.

Una gran cantidad de productos software son complicados, y a menudo las personas que se encargan de especificar el software tampoco son expertos. Pueden olvidarse de cosas que parecen muy sencillas cuando se ve el producto funcionando. Cuando se utiliza un modelo en cascada, olvidar algo puede suponer un error costoso. No se percibe este hecho hasta que se realiza la prueba del sistema, y se comprueba que uno de los requerimientos no está o es incorrecto. Por tanto, el principal problema del modelo en cascada es no permitir flexibilidad en los cambios. Se tienen que especificar completamente todos los requerimientos al comienzo del proyecto, lo que puede suponer



Página 17 de 26

meses o incluso años antes de tener el software funcionando. Esto no resulta acorde con las necesidades del comercio moderno, donde el premio a menudo es para los desarrolladores que pueden implementar la máxima funcionalidad en las últimas etapas del proyecto.

Actividad Práctica AULICA: Realice una lectura comprensiva del marco teórico del ciclo de vida clásico y mencione sus ventajas y desventajas. Ventajas(aspectos positivos) Desventajas(aspectos negativos)

Ciclo de Vida de Construcción de Prototipos

Normalmente un cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el programador puede no estar seguro de la eficiencia de un algoritmo, la adaptabilidad de un sistema operativo o de la forma en que debe hacerse la interacción hombre-máquina. En estas y muchas otras situaciones puede ser el mejor método la construcción de un prototipo. Es un proceso que facilita al programador la creación de un modelo del software a construir. El prototipo es un modelo a escala del real que permite realizar un estudio sobre el mismo, pero no es tan funcional como el producto final. Tipos de modelo:

Prototipo en papel o un modelo basado en PC que describa la interacción hombre-máquina. Prototipo que implemente algunos subconjuntos de la función requerida del programa deseado. Programa existente que ejecute parte o toda la función deseada pero que tenga otras características que

deban ser mejoradas en el nuevo trabajo de desarrollo. Etapas en la construcción de prototipos: recolección y refinación de los requisitos / Diseño rápido / Construcción del prototipo / Evaluación del prototipo por el cliente / Refinación del prototipo / Producto de ingeniería. Estas actividades están representadas en la figura 7 que muestra la forma de construcción del sistema a través de prototipos.

La construcción de prototipos puede ser problemática: El cliente ve funcionando lo que parece ser una primera versión del software, ignorando que por las prisas en hacer que funcione, no hemos considerado los aspectos de calidad o de mantenimiento de software a largo plazo. Es necesario definir al comienzo las reglas de juego, el cliente y el técnico deben estar de acuerdo en que el prototipo se construyó para servir sólo como un mecanismo de definición de los requisitos. Posteriormente debe construirse un sistema real con calidad y mantenimiento.



Página 18 de 26

Una versión del Ciclo de vida de Prototipos es el Prototipado Evolutivo que es un modelo de ciclo de vida

en el que se desarrolla el concepto del sistema a medida que avanza el proyecto. Normalmente se comienza desarrollando los aspectos más visibles del sistema. Puede presentar la parte del sistema al cliente y entonces continuar el desarrollo del prototipo basándose en la realimentación que recibe. En algún punto, el analista y el cliente se ponen de acuerdo en que el prototipo es lo suficientemente bueno. En este punto, se completa cualquier trabajo pendiente en el sistema y se entrega el prototipo como el producto final. El prototipado evolutivo se utiliza especialmente cuando los requerimientos cambian con rapidez, cuando el cliente es reacio a especificar el conjunto de los requerimientos, o cuando ni el analista ni el cliente identifican de forma apropiada el área de aplicación. También es útil cuando los desarrolladores no están seguros de la arquitectura o los algoritmos adecuados a utilizar. Se generan signos visibles de progreso, que se pueden utilizar especialmente cuando existe una gran demanda en la velocidad del desarrollo. El principal inconveniente de este tipo de prototipado es la imposibilidad de conocer al comienzo del proyecto lo que se tardará en crear un producto aceptable. Incluso no se sabe cuántas iteraciones se tendrán que realizar. Este inconveniente aparece de algún modo por el hecho de que los clientes pueden ver signos firmes de progreso y entonces tienden a ponerse menos nerviosos con la adquisición eventual de un producto que con otras aproximaciones.

Actividad Práctica: Realice una lectura comprensiva del marco teórico del ciclo de vida de construcción de Prototipos y mencione sus ventajas y desventajas. Ventajas(aspectos positivos) Desventajas(aspectos negativos)

Diseño Rápido

Constr. Protot.

Eval. Protot. Cliente

Refin Prototipo

Producto Ingen.

Recolec. Requisit.

Parada

Comienzo

Figura 7. Construcción de Prototipos



Página 19 de 26

Ciclo de Vida Estructurado

Cuando se desarrolla un sistema mediante el ciclo de vida estructurado se tienen en cuenta nueve actividades y tres terminadores: los usuarios, los administradores y el personal de operaciones. Se trata de individuos o grupos que proporcionan las entradas al equipo del proyecto y son los beneficiarios finales del sistema. Ellos interactúan con las nueve actividades para que se cumpla el desarrollo del sistema. A continuación se presentan las actividades y una breve descripción de las mismas.

La Encuesta: conocida también como estudio de factibilidad o como Estudio Preliminar. Los objetivos principales de la encuesta son:

- Identificar a los usuarios responsables y crear un campo de actividad inicial del sistema. - Identificar las deficiencias actuales del 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.

Por lo general la encuesta solo ocupa entre el 5 y 10 por ciento del tiempo y recursos de todo el proyecto.

Análisis de Sistemas: el propósito principal es de modelar el ambiente del usuario con distintas herramientas desarrollando un modelo lógico del sistema que pretende cubrir las necesidades de información de los usuarios.

El Diseño: se realiza un modelo físico del sistema, es decir se asignan tareas a procesadores, se define la interfaz del

sistema y se realiza una jerarquía de módulos de programas, a partir del modelo lógico creado en el análisis.

Implementación: incluye la codificación y la integración de módulos en un esqueleto progresivamente más completo del sistema final. Incluye programación estructurada e implementación descendente.(TOP DOWN)

Generación de pruebas de aceptación: se realizan distintos casos de pruebas de aceptación del sistema, para realizar

el control del mismo. Garantía de calidad: es la prueba final o prueba de aceptación. Descripción del procedimiento: descripción formal de las partes del sistema que se realizarán en forma manual. Conversión de la Base de datos: significa trasladar los datos de la base de datos actual a la del nuevo sistema. Instalación: es la instalación y puesta en marcha del nuevo sistema, puede ser un proceso gradual del paso de un

sistema al otro, o ser inmediato.

Las actividades del ciclo de vida estructurado no se realizan en forma secuencial como vimos en el ciclo de vida en Cascada, sino que pueden realizarse varias actividades paralelamente. Además se produce durante el



Página 20 de 26

desarrollo de las actividades del ciclo de vida Estructurado la posibilidad de retroalimentar información hacia otras actividades y volver a definir elementos anteriormente no tenidos en cuenta. Tiene como objetivo emplear herramientas CASE, incrementando la productividad en el desarrollo e implantación de sistemas de información y entre ellas podemos encontrar a Kendall & Kendall entre otras. Crea los modelos de forma descendente. Son las orientadas a procesos, a datos y las mixtas. Intentan aplicar formas ingenieriles para solucionar problemas técnicos al obtener un sistema de información, proponen la creación de modelos, flujos y estructuras mediante un top-down. Es la primera aproximación al problema. Está orientada a procesos, es decir, se centra en especificar y descomponer la funcionalidad del sistema. Se utilizan 5 herramientas: 1-Diagramas de flujo de datos (DFD): Representan la forma en la que los datos se mueven y se transforman. Incluye: Procesos,Flujos de datos y Almacenes de datos, tal que los procesos individuales se pueden a su vez descomponer en otros DFD de nivel superior. 2-Especificaciones de procesos: Es lo que se escribe para uno de los procesos definidos en el DFD cuando no se puede descomponer más. Puede hacerse en pseudocódigo, con tablas de decisión o en un lenguaje de programación. 3-Diccionario de datos: Son los nombres de todos los tipos de datos y almacenes de datos junto con sus definiciones. 4-Diagramas de transición de estados: Modelan procesos que dependen del tiempo 5-Diagramas entidad-relación: Los elementos del modelo E/R se corresponden con almacenes de datos en el DFD. En este diagrama se muestran las relaciones entre dichos elementos Los lenguajes de programación también reflejan la metodología empleada, así existen lenguajes para la programación estructurada. Los más famosos son: Cobol, Fortran, C, Pascal entre otros. Ejemplo de un DFD .



Página 21 de 26

Actividad Práctica AULICA: Realice una lectura comprensiva del marco teórico del ciclo de vida de construcción de Estructurado y mencione sus ventajas y desventajas. Ventajas(aspectos positivos) Desventajas(aspectos negativos)

Ciclo de Vida en Espiral

Cubre las mejores características tanto del ciclo de vida Clásico como la construcción de prototipos agregando el análisis de riesgo, que falta en esos ciclos de vida. Etapas:

Planificación: determinación de objetivos, alternativas y restricciones. Análisis de riesgo: análisis de las alternativas e identificación/resolución de riesgos. Ingeniería: se desarrolla el producto de “siguiente nivel”. Evaluación por el cliente: valoración de los resultados de la ingeniería por parte del cliente.

Con cada iteración alrededor del espiral se construyen sucesivas versiones del software cada vez más

completas. El objetivo final del modelo espiral es que en cada vuelta se construirá una versión más nueva y completa del programa. (Figura 8). El modelo en espiral es actualmente el enfoque más realista para el desarrollo de software y sistemas a gran escala. El modelo en sí es relativamente nuevo y no se ha usado tanto como el ciclo de vida clásico o la creación de prototipos. El modelo espiral es un modelo de ciclo de vida orientado a riesgos que divide un proyecto software en miniproyectos. Cada miniproyecto se centra en uno o más riesgos importantes hasta que todos éstos estén controlados. El concepto “riesgo” se define ampliamente en este contexto, y puede referirse a requerimientos poco comprensibles, arquitecturas poco comprensibles, problemas de ejecución importantes, problemas con la tecnología subyacente, y demás. Después de controlar todos los riesgos más importantes, el modelo en espiral finaliza del mismo modo que el modelo de ciclo de vida en cascada.

Análisis de Riesgo basado en los requisitos iniciales. Análisis de riesgo basado en la reacción del cliente Decisión de seguir o no. Hacia el sistema Final. Prototipo inicial del Soft. Prototipo del siguiente nivel

Recolecc. de Requisitos y Planif. del Proy. Planific. basada en los comentarios del cliente Evaluación del Cliente

Planificación Análisis de Riesgo

Ingeniería Eval. del cliente

Figura 8 El Modelo en Espiral



Página 22 de 26

La idea básica que subyace en el diagrama que representa a este ciclo de vida es que se parte de una

escala pequeña en medio de la espiral, se localizan los riesgos, se genera un plan para manejar los riesgos, y a continuación se establece una aproximación a la siguiente iteración. Cada iteración supone que el proyecto pasa a una escala superior, se comprueba que se tiene lo que se desea, y después se comienza a trabajar en el siguiente nivel. En el modelo en espiral, las primeras iteraciones son las menos costosas. Supone menos gasto desarrollar el concepto de operación que realizar el desarrollo de los requerimientos, y también es menos costosos desarrollar los requerimientos que llevar a cabo el desarrollo del diseño, la implementación del producto y la prueba del mismo. El significado del diagrama no tiene por qué seguirse de forma literal. No es importante que la espiral tenga exactamente cuatro ciclos, y no es importante tampoco que se realicen exactamente los seis pasos como se indica, aunque se trata de un orden apropiado a utilizar. Puede adaptar cada iteración de la espiral a las necesidades que demanda el proyecto. El modelo se puede combinar con otros modelos de ciclo de vida de dos formas distintas. Se puede comenzar un proyecto con una serie de iteraciones para reducir los riesgos, después de que se haya reducido los riesgos a un nivel aceptable, se puede finalizar el esfuerzo de desarrollo con un ciclo de vida en cascada u otro modelo de ciclo de vida no basado en riesgos. Usted puede incorporar otros modelos de ciclo de vida como iteraciones dentro del modelo en espiral. Por ejemplo, si uno de los riesgos consiste en que no se tiene seguridad de alcanzar los objetivos de rendimiento, puede incluir una iteración de prototipado para investigar si es posible la consecución de estos objetivos. Una de las ventajas más importantes del modelo en espiral es que mientras los costos suben, los riesgos disminuyen. Cuando más tiempo y dinero emplee, menores serán los riesgos, que es exactamente lo que se quiere en un proyecto de desarrollo rápido. El modelo en espiral proporciona al menos tanto control de gestión como el modelo en cascada tradicional. Se tienen los puntos de verificación al final de cada iteración. Como el modelo está orientado a riesgo insuperable, descubrirá si el proyecto no se puede realizar por razones técnicas u otras razones, y esto no supondrá un costo excesivo. La única desventaja del modelo en espiral es que se trata de un modelo complicado. Requiere de una gestión atenta y que exige conocimientos profundos. Puede ser difícil definir hitos/objetivos de comprobación que indiquen si está preparado para pasar al siguiente nivel del espiral. En algunos casos, el desarrollo del producto es suficientemente lineal, y los riesgos del proyecto son tan pocos que no se necesita flexibilidad y la gestión de riesgos que ofrece el modelo en espiral.

Actividad Práctica AULICA: Realice una lectura comprensiva del marco teórico del ciclo de vida en Espiral y mencione sus ventajas y desventajas. Ventajas(aspectos positivos) Desventajas(aspectos negativos)



Página 23 de 26

Ciclo de Vida de “Objetos” Los tipos de ciclos de vida que se han visto hasta ahora son relativos al análisis y diseño estructurados, pero los objetos tienen una particularidad, y es que están basados en componentes que se relacionan entre ellos a través de interfaces(clases de interfaz), o lo que es lo mismo, son mas modulares y por lo tanto el trabajo se puede dividir en un conjunto de miniproyectos. Además, hoy en día la tendencia es a reducir los riesgos, y en este sentido, el ciclo de vida en cascada no proporciona muchas facilidades. Debido a todo esto, el ciclo de vida típico en una metodología de diseño orientado a objetos es iterativo e incremental. Al igual que la filosofía del paradigma de la programación orientada a objetos, en esta metodología cada funcionalidad, o requerimiento solicitado por el usuario, es considerado un objeto. Los objetos están representados por un conjunto de propiedades a los cuales denominamos ATRIBUTOS, por otra parte, al comportamiento que tendrán estos objetos lo denominamos METODOS. A los fines de aplicación de esta metodología, la idea es obtener un concepto de objeto sobre casos de la vida real. La característica principal de este modelo es la ABSTRACCION de los requerimientos del usuario, por lo que este modelo es mucho más flexible que los restantes, soportando mejor la incertidumbre, aunque sin garantizar la ausencia e riesgos. ¿Qué es la abstracción?. Es lo que nos permite analizar y desarrollar características esenciales de un objeto(requerimiento) despreocupándonos de las menos relevantes. Esto favorece la reducción de la complejidad del problema que deseamos abordar y permite el perfeccionamiento del producto. El modelo de ciclo de vida de objetos es utilizado para describir como un objeto cambia de estados en el tiempo y que eventos producen dichos cambios de estado. Además, se puede utilizar independientemente del lenguaje con orientación a objetos.(aunque no es lo más aconsejable) Entre los variados modelos que existen podemos mencionar: el P.U.D.



Página 24 de 26

Luego de ver las características de los diferentes modelos basados en las metodologías tradicionales sabemos que ninguno predomina sobre los otros. Por ello, debemos elegir el modelo que mejor se adapte al proyecto a desarrollar, sin embargo, podemos analizar para guiarnos en nuestra lección las siguientes características.

COMPLEJIDAD

TIEMPO

ENTREGAS PARCIALES

COMUNICACION

REQUERIMIENTOS

5-Participantes del ciclo de vida de un sistema La fábula de la granja

Un día cualquiera, los animales de una granja decidieron hacer una fiesta, con el propósito de pasar un momento agradable. Para organizar la fiesta, se reunieron el mismo día en la mañana. Cada animal debía llevar algo a la fiesta. Como es lógico, a la vaca le pidieron la leche. A la gallina, le tocó llevar los huevos. Y al chancho, el tocino. En este caso, la vaca y la gallina participan de la fiesta. Sin embargo, el chancho se encuentra involucrado. Su participación le obliga a entregar parte de si mismo como aporte para la fiesta. Al chancho le toca aportar una cuota de sacrificio mayor. Lo anterior muestra la diferencia entre participar en un evento y estar involucrado. Tomemos esta fábula para caracterizar a los miembros del grupo de un desarrollo del software. ¿Cómo se comportan, en general? ¿Participan

o están comprometidos en el proceso de desarrollo de software?



Página 25 de 26

Parece claro que lo deseable, desde el punto de vista del problema completo, es tener integrantes comprometidos. Pero, ¿cómo se obtienen estos miembros comprometidos? ¿Es posible “crear” miembros del grupo comprometidos? ¿Administrador de proyecto comprometido, analista comprometido, diseñador comprometido, programador comprometido, téster comprometido, asegurador de calidad comprometido, documentador comprometido, ingeniero de manutención comprometido, ingeniero de validación y verificación comprometido, administrador de la configuración comprometido y cliente comprometido? La fábula anterior nos enseña la diferencia entre participar y estar comprometidos en una actividad. Es claro que para tener miembros del equipo de desarrollo comprometidos, es necesario capacitarlos en su en sus deberes y derechos en el ciclo de vida del desarrollo de software. Es muy poco probable que un miembro no capacitado pueda estar comprometido con los objetivos del proyecto. Este presentará claras deficiencias en el momento de participar en el proceso. Como ejemplo, se mencionan algunas: 1. Un miembro no capacitado no entenderá el lenguaje técnico utilizado por el resto de los miembros. Muchas veces, entenderá una cosa diferente a la expresada por sus pares. Esto es común debido a diferencias en el lenguaje. 2. Un miembro no capacitado, no conoce el ciclo de vida del desarrollo, ni los problemas que se presentan durante el desarrollo. Sería muy bueno que el miembro pudiera aportar sus conocimientos en su dominio del problema durante todo el ciclo de desarrollo del proyecto. Saber cuándo exigir y cuando ceder. Conocer los estándares de desarrollo, de documentación, de aseguramiento de la calidad. 3. Un miembro no capacitado no presupuesta su involucración en el proyecto, sólo su participación. Este solo hecho reduce las posibilidades de éxito del proyecto. También aumenta los tiempos de desarrollo, disminuye la calidad del sistema, aumentan los riesgos de rechazo del sistema por parte de la comunidad de clientes, etc.

Lo anterior sugiere que es necesario contar con “miembros comprometidos” para desarrollar correctamente el proyecto. Aspectos a considerar son los de crear un lenguaje común entre el equipo de desarrollo, así como hacer que entiendan claramente sus deberes y obligaciones.

Por otro lado, los clientes también deben estar comprometidos con el desarrollo. Eso significa que deben conocer el ciclo de vida escogido, cual es su participación en cada una de las fases del ciclo, y la cantidad de esfuerzo y recursos que se espera que pongan en cada momento del proyecto. Es de vital importancia que participen activamente en la etapa de análisis, así como en todas aquellas actividades de revisión y aceptación.

En caso que el cliente no tenga dicha experiencia, se hace necesario que antes de un desarrollo, se los capacite para convertirlos en clientes comprometidos. Lo anterior requiere de trabajo, pero va en la senda correcta del éxito de un proyecto de software. Es claro entonces que todos los integrantes del equipo de desarrollo debiesen estar comprometidos con el proyecto, incluyendo los clientes. Lo anterior implica trabajar con el equipo completo en torno a las metas a lograr, así como las cualidades y características deseables de cada uno de ellos. Para ello, se requiere entender correctamente las características de liderazgo dentro de un grupo humano. Cuando se trabaja en proyectos de desarrollo de sistemas de información se interactúa constantemente con una variedad de personajes que a pesar de variar su cantidad y personalidad de un proyecto a otro, en general se destacan una serie de características que se mantiene constantes en los distintos papeles que van asumiendo. A continuación observaremos a cada uno de los participantes en el desarrollo de un sistema de información y definiremos sus características más importantes:

1. Usuarios: es el participante más importante en el desarrollo de los sistemas, Es aquél o aquellos para quienes se construye el sistema. Es la persona a la que tendrá que entrevistar el analista de sistemas a fin de conocer las características que deberá tener el nuevo sistema para tener éxito. Por su nivel de experiencia ,se clasifican en :

Amateur: es aquella persona que jamás ha visto una computadora así se pueden encontrar ciertas

dificultades al entender el lenguaje del analista y posiblemente no comprendan fácilmente el funcionamiento del sistema.



Página 26 de 26

Novato Presuntuoso: es una persona que ha tenido que ver con algún proyectos de desarrollo de

sistemas o que posee una computadora en su casa , por lo cuál dice saber exactamente lo que quiere que el sistema haga y suele señalar todos los errores que el analista cometió en el último proyecto. Muchas veces realiza discusiones sobre la tecnología a utilizar o forma de implementar el sistema.

Experto: son los que realmente entienden del análisis de sistemas y también de la tecnología de

computadoras. Estas personas ayudan mucho al desarrollo del proyecto ya que tienen un vocabulario común con el especialista a cargo del proyecto.

2. Administradores: proveen los recursos necesarios para el desarrollo del proyecto de sistemas. Pueden ser:

-Administradores Usuarios: son administradores que tienen a cargo varias personas del área operacional donde se va a implantar el nuevo sistema.

-Administrador de Informática: son las persona responsables del centro de cómputos, la red de telecomunicaciones, la seguridad del hardware y software, además de la ejecución de los programas, el montaje de los discos , el manejo de las salidas de las impresoras y administración global y distribución de los recursos que hará uso el personal de desarrollo de sistemas.

- Administrador General: Son los administradores de nivel superior que no están directamente involucrados con la organización informática ni son de la organización usuaria. Están a cargo de la presidencia de la organización o de la administración financiera. Se interesan en general por la planeación estratégica y la toma de decisiones.

3. Auditores: Según sea la naturaleza de la organización y el tamaño del proyecto pudiera haber

auditores participando en el proyecto. El objetivo de este equipo es asegurar que el sistema se desarrolle de acuerdo con diversos estándares o normas externos al proyecto ( de contabilidad, producción, etc.). Pueden ser internos o externos a la organización.

4. Analistas: son los encargados de detectar los problemas y requerimientos de los usuarios y crean un

modelo lógico para la construcción del sistema.

5. Diseñadores: toman el modelo libre de consideraciones tecnológicas creado por el analista y lo

traduce en un modelo físico del sistema, con todas las consideraciones necesarias de tecnología, que será entregado a los programadores para su construcción. Las habilidades de un diseñador están mucho más cercanas a las de un programador. Un diseñador debe tener un buen entendimiento de las capacidades del ambiente de destino, para diseñar sistemas que aprovechen sus fortalezas. El diseñador traza los planos a partir de los cuales se construirá el sistema.

6. Developers-Programadores: son los que realizan la construcción del sistema a partir de la

codificación del mismo en el lenguaje de programación definido para el proyecto a partir del diseño.

7. Tester: son los que se encargan de aprobar el software solo luego de que todos los defectos de calidad son identificados y resueltos. Se encarga de hacer: Plan de Testing ,Ingeniería de Testing y Reportes de Testing

8. Leader Project: es el encargado de entregar la solución dentro de las restricciones del proyecto. Tiene como responsabilidad: la Administración del proyecto, Arquitectura de la solución, Aseguramiento del proceso, y Servicios administrativos.

unidad1-teorico2015

Documents