Instituto Universitario Politécnico “Santiago Mariño” Extensión Porlamar Escuela: Ingeniería de Sistemas Asignatura: Análisis y Diseño de Sistemas Profesor: Ing. Diógenes Rodríguez Brito Autor: José Marcano C.I.: 26.243.992 Porlamar, Julio 2017
Transcript
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. (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