1. 1. Instituto Universitario Politcnico Santiago Mario Extensin Porlamar Escuela: Ingeniera de Sistemas Asignatura: Anlisis y Diseo de Sistemas Profesor: Ing. Digenes Rodrguez Brito Autor: Jos Marcano C.I.: 26.243.992 Porlamar, Julio 2017
2. 2. En la actualidad para muchas organizaciones, los sistemas de informacin basados en computadoras son el corazn de las actividades cotidianas y objeto de gran consideracin en la toma de decisiones, las empresas consideran con mucho cuidado las capacidades de sus sistemas de informacin cuando deciden ingresar o no en nuevos mercados o cuando planean la respuesta que darn a la competencia. El anlisis y diseo de sistemas se refiere al proceso de examinar la situacin de una empresa con el propsito de mejorar con mtodos y procedimientos ms adecuados, por eso se presenta un breve informe sobre los mtodos para el anlisis y diseos de sistemas, esta informacin se obtuvo mediante el anlisis de informacin electrnica y bibliogrfica.
3. 3. Es un modo, manera o forma de realizar algo de forma sistemtica, organizada y/o estructurada. Hace referencia a una tcnica o conjunto de Mtodo tareas para desarrollar una tarea. En algunos casos se entiende tambin como la forma habitual de realizar algo por una persona basada en la experiencia, costumbre y preferencias personales. Procede del latn methdus, que a su vez deriva del griego . Disponible en: https://www.significados.com/metodo/
4. 4. Entonces, lo que preeminentemente hace la metodologa es estudiar los mtodos para luego determinar cul es el ms adecuado a aplicar o sistematizar en una investigacin o trabajo. Disponible en: https://nosotos.wordpress.com/metodologia/ Es el conjunto de mtodos por los cuales se regir una investigacin cientfica por ejemplo, en tanto, para aclarar mejor el concepto, vale aclarar que un mtodo es el procedimiento que se llevar a cabo en orden a la consecucin de determinados objetivos.
5. 5. Con UML podemos modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y tambin se puede modelar sistemas que no son informticos, como flujos de trabajo (workflow) en una empresa, diseo de la estructura de una organizacin y por supuesto, en el diseo de hardware. UML entrega una forma de modelar cosas conceptuales como lo son procesos de negocio y funciones de sistema, adems de cosas concretas como lo son escribir clases en un lenguaje determinado, esquemas de base de datos y componentes de software reusables.
6. 6. En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es til categorizarlos jerrquicamente, como se muestra en la figura de la derecha. Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado: * Diagrama de clases * Diagrama de componentes * Diagrama de objetos * Diagrama de estructura compuesta (UML 2.0) * Diagrama de despliegue * Diagrama de paquetes
7. 7. Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado: * * Diagrama de actividades * Diagrama de casos de uso * Diagrama de estados Los Diagramas de Interaccin son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado: Diagrama de secuencia * Diagrama de comunicacin, que es una versin simplificada del Diagrama de colaboracin (UML 1.x) * Diagrama de tiempos (UML 2.0) * Diagrama global de interacciones o Diagrama de vista de interaccin (UML 2.0)
8. 8. Las fases del desarrollo de sistemas que soporta uml son: anlisis de requerimientos, anlisis, diseo, programacin y pruebas. UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A travs del modelado de casos de uso, los actores externos que tienen inters en el sistema son modelados con la funcionalidad que ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son modelados con relaciones y tienen asociaciones entre ellos o stas son divididas en jerarquas. Los actores y casos de uso son descritos en un diagrama use-case. Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo que l (o ella) espera del sistema sin considerar la funcionalidad que se implementar. Un anlisis de requerimientos puede ser realizado tambin para procesos de negocios, no solamente para sistemas de software.
9. 9. La fase de anlisis abarca las abstracciones primarias (clases y objetos) y mecanismos que estn presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso tambin se consideran en esta fase a travs de los modelos dinmicos en uml. Es importante notar que slo se consideran clases que estn en el dominio del problema (conceptos del mundo real) y todava no se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc. En la fase de diseo, el resultado del anlisis es expandido a una solucin tcnica. Se agregan nuevas clases que proveen de la infraestructura tcnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. las clases de dominio del problema del anlisis son agregadas en esta fase. El diseo resulta en especificaciones detalladas para la fase de programacin.
10. 10. En esta fase las clases del diseo son convertidas a cdigo en un lenguaje de programacin orientado a objetos. Cuando se crean los modelos de anlisis y diseo en UML, lo ms aconsejable es trasladar mentalmente esos modelos a cdigo. Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integracin, pruebas de sistema, pruebas de aceptacin, etc. las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son tpicamente ejecutadas por el programador. Las pruebas de integracin integran componentes y clases en orden para verificar que se ejecutan como se especific. Las pruebas de sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de aceptacin conducidas por el cliente verifican que el sistema satisface los requerimientos y son similares a las pruebas de sistema.
11. 11. Esta metodologa de desarrollo de Software es mejor conocida como Metodologa RAD (Rapid Application Development) o Desarrollo rpido de Aplicaciones, y fue creada por el gur de computacin James Martin en 1991. Est orientada a disminuir radicalmente el tiempo necesario para disear e implementar Sistemas de Informacin, el RAD cuenta con una participacin intensa del usuario, sesiones JAD, prototipaje, herramientas CSE integradas y generadores de cdigo. Esta metodologa de desarrollo de Software es mejor conocida como Metodologa RAD (Rapid Application Development) o Desarrollo rpido de Aplicaciones, y fue creada por el gur de computacin James Martin en 1991.
12. 12. 1) Etapa de Planificacin de Requisitos: Esta etapa requiere que los usuarios con un vasto conocimiento de los procesos de la compaa determinen cules sern las funciones del sistema. Debe darse una discusin estructurada sobre los problemas de la compaa que necesitan solucin. 2) Etapa de Diseo: Esta consiste de un anlisis detallado de las actividades de la compaa en relacin al sistema propuesto. Los usuarios participan activamente en talleres bajo la tutela de los profesionales de la informtica. En ellos descomponen funciones y definen entidades asociadas con el sistema. Una vez se completa el anlisis se crean los diagramas que definen las alteraciones entre los procesos y la data. 3) Construccin: En la etapa de construccin el equipo de desarrolladores trabajando de cerca con los usuarios finalizan el diseo y la construccin del sistema. La construccin de la aplicacin consiste de una serie de pasos donde los usuarios tienen la oportunidad de afirmar los requisitos y repasar los resultados. 4) Implementacin: Esta etapa envuelve la implementacin del nuevo producto y el manejo de cambio del viejo al nuevo sistema. Se hacen pruebas comprensivas y se adiestran los usuarios.
13. 13. Segn el Diccionario de la Real Academia de la Lengua Espaola en su edicin vigsimo segunda la palabra sistema significa Conjunto de cosas que relacionadas entre s ordenadamente contribuyen a determinado objeto. Tomando como base este simple pero general concepto de lo que es un sistema podemos centrarnos en dialogar sobre que es un sistema de informacin, y aunque su definicin quizs no diste mucho de la anterior es ms acorde con los objetivos de este trabajo y nos ofrece una idea ms especfica de lo que en realidad estamos buscando. Los Sistemas de Informacin han sido conceptualizados por distintos investigadores y expertos del rea, Laudon y Laudon (2004) los definen como un conjunto de componentes interrelacionados que recolectan (o recuperan), procesan, almacenan y distribuyen informacin para apoyar la toma de decisiones y el control de una organizacin.
14. 14. Elementos fundamentales de un sistema de informacin: Informacin: La informacin es la base, la materia prima sobre la cual se mueve todo el engranaje de un sistema de informacin, es todo lo almacenado, procesado y distribuido en la organizacin por el sistema. Las personas: Son los encargados de interactuar con la informacin, quienes la introducen, utilizan y valoran su importancia en las distintas tareas relacionadas con esta. Medios para la interaccin con la informacin: Activos tangibles e intangibles de interaccin con los usuarios para el tratamiento de la informacin, pueden ser archivos, documentos, hardware, software, redes de comunicacin, intranets, etctera. Normas y/o tcnicas de trabajo: Mtodos utilizados por las personas y las tecnologas para desarrollar sus actividades.
15. 15. Hardware: Todas las piezas fsicas de la computadora y sus perifricos, dgase teclado, monitor, tarjeta madre, y los dems elementos que conforman el equipo. Este equipamiento es utilizado para llevar a cabo las tareas de entrada, procesamiento y salida. Software: Son los programas de computacin mediante los cuales se dirige las operaciones de una computadora. Bases de Datos: Una Base de Datos es una coleccin de datos organizados en celdas. Este elemento se encuentra entre los ms importantes de un sistema de informacin informtico. Redes: Se denomina as a la interconexin entre computadoras u otros equipos informticos para hacer posible la comunicacin electrnica, este elemento es muy importante ya que puede ser determinante en la efectividad del sistema de informacin informtico.
16. 16. Un proceso de software detallado y completo suele denominarse Metodologa. Las metodologas se basan en una combinacin de los modelos de proceso genricos (cascada, evolutivo, incremental,). El Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. El Proceso Unificado de desarrollo puede ser dividido en cuatro fases: Fase de Inicio. Fase de Elaboracin. Fase de Construccin. Fase de Transicin.
17. 17. En la ingeniera del software el trmino fases de desarrollo expresa cmo ha progresado el desarrollo de un software y cunto desarrollo puede requerir. Cada versin importante de un producto pasa generalmente a travs de una etapa en la que se agregan las nuevas caractersticas (etapa alfa), despus una etapa donde se eliminan errores activamente (etapa beta), y finalmente una etapa en donde se han quitado todos los bugs importantes (etapa estable). Las etapas intermedias pueden tambin ser reconocidas. Las etapas se pueden anunciar y regular formalmente por los desarrolladores del producto, pero los trminos se utilizan a veces de manera informal para describir el estado de un producto. Normalmente muchas compaas usan nombres en clave para las versiones antes del lanzamiento de un producto, aunque el producto y las caractersticas reales son raramente secretas
18. 18. El ciclo de vida de vida del desarrollo de sistemas es un enfoque por fases para el anlisis y el diseo cuya premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo especifico de actividades del analista y el usuario. (Kendall & Kendall) Segn la metodologa de Kendall & Kendall el ciclo de vida de un sistema consta de siete partes: siendo la primera la identificacin del problema, la segunda identificacin de requisitos de informacin, la tercera es el anlisis de las necesidades del sistema, la cuarta es el diseo del sistema recomendado, la quinta desarrollo y documentacin del sistema, la sexta prueba y mantenimiento y la ltima implementacin y evaluacin. Cada fase se explica por separado pero nunca se realizan como pasos aislados, ms bien es posible que algunas actividades se realicen de manera simultnea, y algunas de ellas podran repetirse.
19. 19. FASE I: Identificacin de problemas, oportunidades y objetivos. Observacin directa del entorno. Aplicacin de entrevista para recolectar informacin. Sintetizar la informacin recolectada para construir objetivos. Estimar el alcance del proyecto. Identificar si existe una necesidad, problema u oportunidad argumentada. Documentar resultados. Estudiar los riesgos del proyecto. Presentar un informe de vialidad. FASE II: Determinacin de los requerimientos de informacin. Revisin de los objetivos. Identificar el dominio. Investigar la razn por la cual se implementa el sistema actual. Recolectar informacin sobre los procedimientos y operaciones que se desempean actualmente.
20. 20. FASE IV: Diseo del sistema recomendado. Evaluar las tres fases anteriores. Realizar el diseo lgico de todo el sistema. Elaborar procedimientos precisos para la captura de los datos que van a ingresar al sistema de informacin. Elaborar el diseo de la base de datos. Disear las diferentes interfaces de usuarios de cada operacin, procedimiento y/o funcin. Disear controles y procedimientos de respaldos que protejan al sistema y a los datos. Producir los paquetes especficos de programas para los programadores. Elaborar una lista de las funciones genricas y de las que ser obligatorio crear. FASE III: Anlisis de las necesidades. Evaluar las dos fases anteriores. Modelar las entradas, los procesos y las salidas de las funciones ya identificadas. Elaborar diccionario de datos y sus especificaciones. Elaborar diagramas de procesos de cada funcin. Elaborar propuesta del sistema con todos los diagramas de operaciones y de procesos. Realizar el anlisis del riesgo sobre el realizado en las fases anteriores, tomando en cuenta el aspecto econmico, tcnico y operacional (estudio de factibilidad) Estimar en un diagrama de Gantt el tiempo que tomar desarrollar el sistema.
21. 21. FASE VI: Prueba y mantenimiento del sistema. Realizar la programacin de las pruebas del sistema. Realizar un instrumento para evaluar el sistema de informacin. El programador deber elaborar un resumen de las pruebas del sistema. El analista deber realizar un informe de sus pruebas y discutirlo con el programador. Elaborar la planificacin de las horas del mantenimiento del sistema. Elaborar la lista de las operaciones que pudieran sufrir modificaciones de cdigos. FASE V: Desarrollo y documentacin del software. Evaluar los procedimientos que va a ser desarrollados por el programador. Mostrar y explicar cada procedimiento, funcin y operacin al programador. Elaborar manuales de procedimientos internos del sistema. Elaborar manuales externos de ayuda a los usuarios del sistema. Elaborar demostraciones para los usuarios y la interaccin con distintas interfaces. Elaborar actualizaciones para los diferentes procedimientos. Elaborar un informe con el tiempo que se llev construir cada procedimiento.
22. 22. FASE VII: Implementacin y evaluacin del sistema. Planificar gradualmente la conversin del sistema anterior. Instalar los equipos de hardware necesarios para el funcionamiento del software creado. Capacitar por medio de talleres a los usuarios en el manejo de equipos y software creados. Evaluar la adaptabilidad de los usuarios al sistema. Esta es la ltima fase del desarrollo de sistemas, y aqu el analista participa en la implementacin del sistema de informacin. En esta fase se capacita a los usuarios en el manejo del sistema. Parte de la capacitacin la imparten los fabricantes, pero la supervisin de sta es responsabilidad del analista de sistemas.
23. 23. La RMM o Relationship Management Methodology se define como un proceso de anlisis, diseo y desarrollo de aplicaciones hipermedia. Los elementos principales de este mtodo son el modelo E-R (Entidad-Relacin) y el modelo RMDM (Relationship Management Data Model) basado en el modelo HDM. La metodologa fue creada por Isakowitz, Stohr y Balasubramanian. Esta metodologa es apropiada para dominios con estructuras regulares (es decir, con clases de objetos bien definidas, y con claras relaciones entre esas clases). Por ejemplo, catlogos o "frentes" de bases de datos tradicionales. Segn sus autores, est orientada a problemas con datos dinmicos que cambian con mucha frecuencia, ms que a entornos estticos. El modelo propone un lenguaje que permite describir los objetos del dominio, sus interrelaciones y los mecanismos de navegacin hipermedia de la aplicacin. Los objetos del dominio se definen con la ayuda de entidades, atributos y relaciones asociativas. El modelo introduce el concepto de slice (trozo) con el fin de modelizar los aspectos unidos a la presentacin de las entidades. Un slice corresponde a un subconjunto de atributos de una misma entidad destinados a ser presentados de forma agrupada.
24. 24. Las etapas son: Primera etapa: representar los objetos del dominio con la ayuda del modelo Entidad-Relacin ampliado con relaciones asociativas (aqullas que permiten representar caminos navegacionales entre entidades puestos en evidencia en la fase de anlisis). Segunda etapa: determinar la presentacin del contenido de las entidades de la aplicacin as como su modo de acceso. El esquema obtenido como resultado de esta etapa se denomina esquema E.R+. Se trata de un esquema Entidad-Relacin en el que cada entidad ha sido reemplazada por su esquema de entidad. Un esquema de entidad est constituido por nodos (los trozos o slides) unidos por relaciones estructurales. Tercera etapa: definir los caminos de navegacin inducidos por las relaciones asociativas del esquema E-R+. A continuacin, es posible definir estructuras de acceso de alto nivel (agrupaciones), lo que permite dotar a la aplicacin de accesos jerrquicos a niveles diferentes de los trozos de informacin.
25. 25. El esquema RMDM resultante se obtiene aadiendo al esquema E-R+ las agrupaciones y caminos navegacionales definidos en esta etapa. Las cuatro etapas restantes consisten en: definicin del protocolo de conversin de elementos del diagrama RMDM en objetos de la plataforma de desarrollo concepcin del interfaz usuario concepcin del comportamiento en ejecucin construccin del sistema y test.
26. 26. La metodologa OMT (Object Modeling Technique) fue creada por James Rumbaugh y Michael Blaha en 1991, mientras James diriga un equipo de investigacin de los laboratorios General Electric. OMT es una de las metodologas de anlisis y diseo orientada a objetos, ms madura y eficiente que existe en la actualidad. La gran virtud que aporta esta metodologa es su carcter de abierta (no propietaria), que le permite ser de dominio pblico y , en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolucin para acoplarse a todas las necesidades actuales y futuras de la ingeniera de software.
27. 27. Las fases que conforman a la metodologa OMT son: 1. Anlisis. El analista construye un modelo del dominio del problema, mostrando sus propiedades ms importantes. El modelo de anlisis es una abstraccin resumida y precisa de lo que debe de hacer el sistema deseado y no de la forma en que se har. Los elementos del modelo deben ser conceptos del dominio de aplicacin y no conceptos informticos tales como estructuras de datos. Un buen modelo debe poder ser entendido y criticado por expertos en el dominio del problema que no tengan conocimientos informticos. 2. Diseo del sistema. El diseador del sistema toma decisiones de alto nivel sobre la arquitectura del mismo. Durante esta fase el sistema se organiza en subsistemas basndose tanto en la estructura del anlisis como en la arquitectura propuesta. Se selecciona una estrategia para afrontar el problema.
28. 28. 3. Diseo de objetos. El diseador de objetos construye un modelo de diseo basndose en el modelo de anlisis, pero incorporando detalles de implementacin. El diseo de objetos se centra en las estructuras de datos y algoritmos que son necesarios para implementar cada clase. OMT describe la forma en que el diseo puede ser implementado en distintos lenguajes (orientados y no orientados a objetos, bases de datos, etc.). 4. Implementacin. Las clases de objetos y relaciones desarrolladas durante el anlisis de objetos se traducen finalmente a una implementacin concreta. Durante la fase de implementacin es importante tener en cuenta los principios de la ingeniera del software de forma que la correspondencia con el diseo sea directa y el sistema implementado sea flexible y extensible. No tiene sentido que utilicemos AOO y DOO de forma que potenciemos la reutilizacin de cdigo y la correspondencia entre el dominio del problema y el sistema informtico, si luego perdemos todas estas ventajas con una implementacin de mala calidad.
29. 29. Los Sistemas Expertos se han definido como aquellos programas que se basan en el conocimiento y tratan de imitar el razonamiento de un experto para resolver un problema de un tpico definido. Su comportamiento se basa generalmente en reglas, es decir, se basa en conocimientos previamente definidos, y mediante estos conocimientos, los SE son capaces de tomar decisiones. Se puede decir que los Sistemas Expertos son el primer resultado operacional de la Inteligencia artificial, pues logran resolver problemas a travs del conocimiento y raciocinio de igual forma que lo hace el experto humano.
30. 30. Para que un sistema experto sea herramienta efectiva, los usuarios deben interactuar de una forma fcil, reuniendo dos capacidades para poder cumplirlo: 1. Explicar sus razonamientos o base del conocimiento: los sistemas expertos se deben realizar siguiendo ciertas reglas o pasos comprensibles de manera que se pueda generar la explicacin para cada una de estas reglas, que a la vez se basan en hechos. 2. Adquisicin de nuevos conocimientos o integrador del sistema: son mecanismos de razonamiento que sirven para modificar los conocimientos anteriores. Sobre la base de lo anterior se puede decir que los sistemas expertos son el producto de investigaciones en el campo de la inteligencia artificial ya que sta no intenta sustituir a los expertos humanos, sino que se desea ayudarlos a realizar con ms rapidez y eficacia todas las tareas que realiza. Debido a esto en la actualidad se estn mezclando diferentes tcnicas o aplicaciones aprovechando las ventajas que cada una de estas ofrece para poder tener empresas ms seguras. Un ejemplo de estas tcnicas sera los agentes que tienen la capacidad de negociar y navegar a travs de recursos en lnea; y es por eso que en la actualidad juega un papel preponderante en los sistemas expertos.
31. 31. Es una metodologa de desarrollo de software que contempla una serie de fases o etapas de un proceso sistemtico atendiendo a: anlisis, diseo, desarrollo, prueba y ajuste, y por ltimo implementacin. Etapa 1: Anlisis. Caractersticas de la poblacin objetivo: edad (fsica y mental), sexo, caractersticas fsicas y mentales (si son relevantes), experiencias previas, expectativas, actitudes, aptitudes, intereses o motivadores por aprender. Conducta de entrada y campo vital: nivel escolar, desarrollo mental, fsico o psicolgico, entorno familiar y escolar, etc. Etapa 2: Diseo: Educativo (este debe resolver las interrogantes que se refieren al alcance, contenido y tratamiento que debe ser capaz de apoyar el Sistema Educativo). Comunicacional (es donde se maneja la interaccin entre usuario y mquina, se denomina interfaz). Computacional (con base a las necesidades se establece qu funciones es deseable que cumpla el Sistemas Educativo en apoyo de sus usuarios, el docente y los estudiantes).
32. 32. Etapa 3: Desarrollo: En esta fase se implementa la aplicacin usando la informacin obtenida anteriormente. Tomando en cuenta las restricciones que se tengan. Etapa 4: Prueba Piloto: En esta etapa se pretende ayudar a la depuracin del Sistema Educativo a partir de su utilizacin por una muestra representativa de los tipos de destinatarios para los que se hizo y la consiguiente evaluacin formativa. Es imprescindible realizar ciertas validaciones (efectuadas por expertos) de los prototipos durante las etapas de diseo y prueba en uno a uno de los mdulos desarrollados, a medida que estos estn funcionales. Etapa 5: Prueba de Campo : La prueba de campo de un Sistema Educativo es mucho ms que usarlo con toda la poblacin objeto. Si se exige, pero no se limita a esto. Es importante que dentro del ciclo de desarrollo hay que buscar la oportunidad de comprobar, en la vida real, que aquello que a nivel experimental pareca tener sentido, lo sigue teniendo, es decir, si efectivamente la aplicacin satisface las necesidades y cumple la funcionalidad requerida.
33. 33. SSM de Peter Checkland es una metodologa sistmica fundamentada en el concepto de perspectiva o en el lenguaje de la metodologa Weltanschauung. Un weltanschauung representa la visin propia de un observador, o grupo de ellos, sobre un objeto de estudio, visin sta que afecta las decisiones que el(los) observador(es) pueda(n) tomar en un momento dado sobre su accionar con el objeto. La SSM toma como punto de partida la idealizacin de estos weltanschauung para proponer cambios sobre el sistema que en teora deberan tender a mejorar su funcionamiento.
34. 34. MeRinde es un proyecto que propone un estndar abierto para el proceso de desarrollo de software orientado a planes que se estructura en dos dimensiones o ejes. La metodologa propuesta MeRinde se organiza en disciplinas. Las disciplinas poseen flujos de trabajos en donde cada uno conlleva a actividades (ver primera figura) que a su vez estn compuestos por un conjunto de tareas (ver segunda figura) realizadas en un rea determinada, las cuales tienen como objetivo producir artefactos. A su vez, en MeRinde existen actividades que se dividen en subactividades (ver tercera figura) con el fin de facilitar la agrupacin de tareas relacionadas. Las disciplinas que conforman esta metodologa se fundamentan en las propuestas por RUP, las cuales se dividirn en dos grupos. El primero comprende las disciplinas fundamentales asociadas con las reas de ingeniera:
35. 35. Modelado del Negocio Requerimientos Anlisis y Diseo Implementacin Pruebas Implantacin El segundo grupo lo integran aquellas disciplinas llamadas de soporte o gestin: Gestin de Configuracin y Cambios Gestin del Proyecto Gestin del Ambiente Fases: Fase de Inicio Fase de Elaboracin Fase de Construccin Fase de Transicin
36. 36. Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prcticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prcticas se apoyan unas a otras y su seleccin tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.
37. 37. Un proyecto de desarrollo de un Sistema de Informacin comprende varios componentes o pasos llevados a cabo durante la etapa del anlisis, el cual ayuda a traducir las necesidades del cliente en un modelo de Sistema que utiliza uno ms de los componentes: Software, hardware, personas, base de datos, documentacin y procedimientos. La funcin del Anlisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios.
38. 38. (s/f). Mtodo. Recuperado el 04/07/2017. Disponible en: http://www.significados.com/metodo/ (s/f). Metodologa. Recuperado el 04/07/2017. Disponible en: https://nosotos.wordpress.com/metodologia/ (s/f). Mtodos de Sistemas. Recuperado el 04/07/2017. Disponible en: http://articulacion.simonrodriguez.org.ve/lval/index.php/Metodologia (s/f). Programacin Extrema XP. Recuperado el 04/07/2017. Disponible en: http://ingenieriadesoftware.mex.tl/52753_xp---extreme-programing.html