REPÚBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN
UNIVERSITARIA
CIENCIA Y TECNOLOGÍA
INSTITUTO UNIVERSITARIO POLITÉCNICO SANTIAGO MARIÑO
“EXTENSIÓN MARACAY”
METODOLOGÍA PARA EL DESARROLLO DE SISTEMAS
Autor: Luis Fernando Sulbaran Ramirez
C.I: 27.146.150
Tutora: Lisseth Zurita
Maracay, junio 2024
ANÁLISIS ESTRUCTURADO
Permite al analista conocer un sistema o proceso (actividad) en una forma
lógica y manejable, el objetivo que persigue el análisis estructurado es
organizar las tareas asociadas con la determinación de requerimientos para
obtener la comprensión completa y exacta de una situación dada.
METODOLOGÍA DEL SOFTWARE
Una metodología de desarrollo de software se refiere a un framework
(entorno o marco de trabajo) que es usado para estructurar, planear y
controlar el proceso de desarrollo en sistemas de información. A lo largo del
tiempo, una gran cantidad de métodos han sido desarrollados
diferenciándose por su fortaleza y debilidad. El framework para la
metodología de desarrollo de software consiste en: una filosofía de desarrollo
de programas de computación con el enfoque del proceso de desarrollo de
software, herramientas, modelos y métodos para asistir al proceso de
desarrollo de software. Estos frameworks son a menudo vinculados a algún
tipo de organización, que además desarrolla, apoya el uso y promueve la
metodología.
METODOLOGÍA DEL SOFTWARE (Kendall & Kendall)
“El ciclo de vida del desarrollo de sistemas es un enfoque por fases para el
análisis y el diseño cuya premisa principal consiste en que los sistemas se
desarrollen mejor utilizando un ciclo especifico de actividades del analista y
el usuario.” (Kendall & Kendall).
Siguiendo la metodología de Kendall & Kendall el ciclo de vida de un
sistema consta de siete partes: siendo la primera la identificación del
problema, la segunda la identificación de requisitos de información, la tercera
es el análisis de las necesidades del sistema, la cuarta es el diseño del
sistema recomendado, la quinta es el desarrollo y documentación del
sistema, la sexta la prueba y mantenimiento y la última la implementación y
evaluación. Cada fase se explica por separado, pero nunca se realizan como
pasos aislados, más bien es posible que algunas actividades se realicen de
manera simultánea, y algunas de ellas podrían repetirse.
FASE I:
Identificación de problemas, oportunidades y objetivos: En esta etapa, se
busca entender qué es lo que la organización quiere lograr y cómo los
sistemas de información pueden ayudar a alcanzar esos objetivos.
FASE II:
Determinación de los requerimientos de información: Aquí se interactúa
con los usuarios para entender cuáles son sus necesidades de información.
FASE III:
Análisis de las necesidades del sistema: En esta fase, se analizan las
necesidades específicas del sistema, incluyendo las decisiones que se
deben tomar, las condiciones y las reglas.
FASE IV:
Diseño del sistema recomendado: Utilizando la información recopilada en
las etapas anteriores, se elabora el diseño lógico del sistema de información,
incluyendo los archivos o la base de datos que almacenará los datos
necesarios.
FASE V:
Desarrollo y documentación del software: En esta etapa se utilizan
técnicas estructuradas para transmitir al programador los requerimientos de
programación.
FASE VI:
Pruebas y mantenimiento del sistema: Antes de que el sistema sea
utilizado, debe ser probado para detectar y corregir problemas. También se
realiza el mantenimiento para asegurar su correcto funcionamiento a largo
plazo.
FASE VII:
Implementación y evaluación del sistema: Esta es la última etapa donde
se pone en marcha el sistema y se realiza el entrenamiento necesario para
los usuarios. También se evalúa si el sistema cumple con los requerimientos
y objetivos establecidos.
METODOLOGÍA DEL SOFTWARE (James Martin)
Creada por el gurú de computación James Martin en 1991. Esta
metodología de desarrollo de software está orientada a disminuir
radicalmente el tiempo necesario para diseñar e implementar Sistemas de
Información, el RAD (Rapid Application Development) cuenta con una
participación intensa del usuario, sesiones JAD, prototipaje, herramientas
CSE integradas y generadores de código. El RAD requiere cuatro
ingredientes esenciales: gerencia, gente, metodologías y herramientas.
FASE I:
Planificación de requerimientos: En esta etapa inicial, los diseñadores,
desarrolladores y usuarios llegan a un acuerdo sobre el alcance del proyecto
y los requisitos de la aplicación.
FASE II:
Diseño con el usuario: Durante esta fase, se recopilan los comentarios de
los usuarios con gran énfasis en la determinación de la arquitectura del
sistema. Esto permite crear modelos y prototipos iniciales.
FASE III:
Construcción: Una vez que ha comenzado el diseño básico del usuario y
del sistema, la fase de construcción es donde se lleva a cabo la mayor parte
de la codificación, las pruebas y la integración reales de la aplicación.
FASE IV:
Implementación: En esta fase, se realiza una transición del sistema
antiguo al nuevo. Se preparan los planes de prueba, se realizan las pruebas
del sistema, se convierten los datos, se entrena a los usuarios y se instala el
sistema.
METODOLOGÍA DEL SOFTWARE (James Senn)
FASE I:
Investigación preliminar: En esta etapa inicial, se definen los pasos a
seguir y se realiza un estudio de factibilidad. Se consideran factores
económicos, técnicos y operacionales.
FASE II:
Determinación de los requerimientos del sistema: Aquí, el analista estudia
el negocio y todos los elementos que formarán parte del desarrollo del
proyecto desde el punto de vista de los usuarios y del negocio.
FASE III:
Diseño del sistema: En esta fase, los analistas definen las entradas,
salidas, los cálculos y aspecto físico que tendrán las interfaces, así como
también las estructuras de datos y flujos de información.
FASE IV:
Desarrollo de software: Los responsables deciden cómo implementar el
sistema de información. Esta decisión dependerá de varios factores, como el
tamaño y la importancia del proyecto y los recursos disponibles.
FASE V:
Prueba de los sistemas: Antes de la implementación, se descubren y
corrigen errores. Es común que las pruebas las realicen personas no
vinculadas al desarrollo del sistema, para que los resultados de esta fase
sean lo más imparciales posible.
FASE VI:
Implantación y evaluación: Esta fase consiste en implantar el nuevo
sistema de información en la empresa y analizar las fortalezas y las
debilidades del nuevo sistema, una vez que esté funcionando.
METODOLOGÍA DEL SOFTWARE (Jeffrey Whitten)
Un aspecto importante en el desarrollo de un sistema de información es la
implementación de una metodología que describa paso a paso el método
necesario para crear dicho sistema de información. A continuación, se
detallan las fases de esta metodología para el desarrollo de los sistemas de
información:
FASE I:
Identificación del problema: En esta etapa inicial, se reconoce la
necesidad de un nuevo sistema o mejoras en uno existente.
FASE II:
Análisis del sistema actual: Durante esta fase, se examina el sistema
existente para entender sus fortalezas y debilidades.
FASE III:
Diseño o modelado: Aquí, se crea un modelo del nuevo sistema. Este
modelo sirve como un plan para el desarrollo del sistema.
FASE IV:
Diseño de la topología y servicios: En esta etapa, se definen los
componentes del sistema y cómo interactúan entre sí.
FASE V:
Desarrollo y documentación: Aquí, se desarrolla el software del sistema y
se documenta su funcionamiento.
FASE VI:
Implantación: En esta fase, se instala el nuevo sistema y se entrena a los
usuarios para su uso.
FASE VII:
Pruebas: Antes de que el sistema sea utilizado, se realizan pruebas para
detectar y corregir posibles errores.
FASE VIII:
Depuración: Finalmente, se corrigen los errores encontrados durante las
pruebas para asegurar que el sistema funcione correctamente.
TÉCNICAS DE RECOLECCIÓN DE DATOS
Se refiere al uso de una gran diversidad de técnicas y herramientas que
pueden ser utilizadas por el analista para desarrollar los sistemas de
información, los cuales pueden ser la entrevista, la encuesta, el cuestionario,
la observación, el diagrama de flujo y el diccionario de datos.
Todos estos instrumentos se aplicarán en un momento en particular, con
la finalidad de buscar información que será útil a una investigación en común.
En la presente investigación se trata con detalle los pasos que se deben
seguir en el proceso de recolección de datos, con las técnicas ya antes
nombradas.
ENTREVISTA
La entrevista es una conversación dirigida, con un propósito específico y
que usa un formato de preguntas y respuestas.
Se establece así un diálogo, pero un diálogo peculiar, asimétrico, donde
una de las partes busca recoger informaciones y la otra se nos presenta
como fuente de estas informaciones.
Una entrevista es un diálogo en el que la persona (entrevistador),
generalmente un periodista hace una serie de preguntas a otra persona
(entrevistado), con el fin de conocer mejor sus ideas, sus sentimientos su
forma de actuar.
LA ENCUESTA
Una encuesta es un conjunto de preguntas normalizadas dirigidas a una
muestra representativa de la población o instituciones, con el fin de conocer
estados de opinión o hechos específicos.
La intención de la encuesta no es describir los individuos particulares
quiénes, por azar, son parte de la muestra sino obtener un perfil compuesto
de la población.
Una “encuesta” recoge información de una “muestra.” Una “muestra” es
usualmente sólo una porción de la población bajo estudio.
CUESTIONARIO
Los cuestionarios proporcionan una alternativa muy útil para la entrevista;
sin embargo, existen ciertas características que pueden ser apropiadas en
algunas situaciones e inapropiadas en otra. Al igual que la entrevistas, deben
diseñarse cuidadosamente para una máxima efectividad.
Existen dos formas de cuestionarios para recabar datos: cuestionarios
abiertos y cerrados, y se aplican dependiendo de si los analistas conocen de
antemano todas las posibles respuestas de las preguntas y pueden incluirlas.
Con frecuencia se utilizan ambas formas en los estudios de sistemas.
Cuestionario Abierto
Al igual que las entrevistas, los cuestionarios pueden ser abiertos y se
aplican cuando se quieren conocer los sentimientos, opiniones y
experiencias generales; también son útiles al explorar el problema básico,
por ejemplo, un analista que utiliza cuestionarios para estudiar los métodos
de verificación de crédito, es un medio.
El formato abierto proporciona una amplia oportunidad para quienes
respondan escriba las razones de sus ideas. Algunas personas sin embargo,
encuentran más fácil escoger una de un conjunto de respuestas preparadas
que pensar por sí mismas.
Cuestionario Cerrado
El cuestionario cerrado limita las respuestas posibles del interrogado. Por
medio de un cuidadoso estilo en la pregunta, el analista puede controlar el
marco de referencia. Este formato es el método para obtener información
sobre los hechos. También fuerza a los individuos para que tomen una
posición y forma su opinión sobre los aspectos importantes.
OBSERVACIÓN
La observación es otra técnica útil para el analista en su proceso de
investigación, consiste en observar a las personas cuando efectúan su
trabajo.
El propósito de la observación es múltiple, permite al analista determinar
qué se está haciendo, cómo se está haciendo, quién lo hace, cuándo se lleva
a cabo, cuánto tiempo toma, dónde se hace y por qué se hace.
DIAGRAMA DE FLUJO
Es una representación pictórica de los pasos en proceso. Útil para
determinar cómo funciona realmente el proceso para producir un resultado.
Los diagramas de flujo se pueden aplicar a cualquier aspecto del proceso
desde el flujo de materiales hasta los pasos para hacer la venta u ofrecer un
producto.
Se debe saber que para utilizar un diagrama de flujo un equipo necesita
ver cómo funciona realmente un proceso completo. Este esfuerzo con
frecuencia revela problemas potenciales tales como cuellos de botella en el
sistema, pasos innecesarios y círculos de duplicación de trabajo.
DICCIONARIO DE DATOS
Un diccionario de datos es una lista de todos los elementos incluidos en el
conjunto de los diagramas de flujo de datos que describen un sistema. Los
elementos principales en un sistema, estudiados en las secciones anteriores,
son el flujo de datos, el almacenamiento de datos y los procesos. El
diccionario de datos almacena detalles y descripciones de estos elementos.
Los diccionarios de datos son el segundo componente del análisis del flujo
de datos. En sí mismos los diagramas de flujo de datos no describen por
completo el objeto de la investigación. El diccionario de datos proporciona
información adicional sobre el sistema.
El diccionario de datos se desarrolla durante el análisis de flujo de datos y
ayuda al analista involucrado en la determinación de los requerimientos de
sistemas. Sin embargo, como se verá más adelante, también el contenido del
diccionario de datos se utiliza durante el diseño del sistema.
ANÁLISIS ESTRUCTURADO Y ORIENTADO A OBJETOS
Se concentra en especificar lo que se requiere que haga el sistema o la
aplicación. No establece cómo se cumplirán los requerimientos o la forma en
que se implantará la aplicación. Más bien permite que las personas observen
los elementos lógicos (lo que hará el sistema) separado de los componentes
físicos (computadoras, terminales, sistemas de almacenamiento, etc.).
Se combina con bastante frecuencia con el método de ciclo de vida clásico
de desarrollo de sistemas. Por ejemplo, los analistas pueden optar por
desarrollar diagramas de flujo de datos como una forma para documentar las
relaciones entre componentes durante la investigación detallada de algún
sistema existente. Así mismo, se pueden definir los archivos y datos en un
diccionario centralizado de datos de acuerdo con las reglas del análisis
estructurado.
Los sistemas se construyen a partir de otros componentes probados con
un formato definido para las solicitudes de las operaciones del componente.
El analista orientado a objetos ve el mundo como objetos (con estructuras de
datos y métodos) y eventos que activan operaciones, las cuales modifican el
estado de los objetos. El analista crea diagramas de la estructura de los
objetos y de los eventos que los modifican.
ORIENTADO A OBJETOS
Los métodos orientados a objeto acortan la distancia existente entre el
espacio de conceptos (lo que los expertos o usuarios conocen) y el espacio
de diseño (lo que conocen los desarrolladores) e implementación, ya que los
objetos del mundo real tienen una correspondencia bastante clara con los
objetos del sistema informático, evitando así los grandes abismos existentes
entre el análisis y el diseño en el enfoque estructurado, esta es la falta de
continuidad en la representación de los conceptos en una y otra fase, por
ejemplo los DFDs y los diagramas de estructura.
Por su parte, en los desarrollos orientados al objeto se tiene una mayor
continuidad entre las diferentes fases, con unas fronteras entre fases muy
poco marcadas que dan lugar a desarrollos más iterativos e incrementales.
Todo esto es posible gracias a una característica de vital importancia, el
modelo subyacente a todas las fases es el mismo, el modelo objeto, que
tiene como elemento central al objeto, que es la entidad que encapsula
elementos estructurales y de comportamiento.
La transición entre las fases de análisis y diseño en la orientación al objeto
es mucho más suave que en las metodologías estructuradas, no habiendo
tanta diferencia entre las etapas. Esto implica que es difícil determinar donde
acaba el Análisis Orientado a Objeto (AOO) y donde comienza el Diseño
Orientado a Objeto (DOO), siendo la frontera entre ambas fases totalmente
inconsistente, de forma que lo que algunos autores incluyen en el AOO otros
lo hacen en el DOO. Esto conduce a que sea frecuente el uso de las siglas
ADOO para hacer referencia a ambas fases de forma conjunta.
El objetivo del AOO es modelar la semántica del problema en términos de
objetos distintos pero relacionados. Por su parte, el DOO conlleva
reexaminar las clases del dominio del problema, refinándolas, extendiéndolas
y reorganizándolas, para mejorar su reutilización y tomar ventaja de la
herencia. Por lo tanto, el AOO enfoca el problema en los objetos del dominio
del problema y el DOO en los objetos del dominio de la solución.
SISTEMAS EXPERTOS Y SUS APLICACIONES
Son el primer resultado operacional de la Inteligencia Artificial, pues logran
resolver problemas a través del conocimiento y raciocinio de igual forma que
lo hace el experto humano.
La tarea principal de un SE es tratar de aconsejar al usuario.
Las características principales de este tipo de problemas, según algunos
autores son:
- Utilizan normas o estructuras que contengan conocimientos y
experiencias de expertos especializados.
- Se obtienen conclusiones a través de deducciones lógicas.
- Contienen datos ambiguos.
- Contienen datos afectados por factores de probabilidades.
Con base a lo anterior, algunos investigadores de IA señalan que un SE
debe cumplir con las siguientes características:
Tener un amplio conocimiento específico en el área de
especialización.
Aplicar técnicas de búsqueda.
Tener soporte para Análisis Heurístico.
Poseer habilidad para inferir en nuevos conocimientos ya
existentes.
Tener la capacidad de procesar símbolos.
Tener la capacidad para explicar su propio razonamiento.
Sistema Fecha Autor Aplicación
Deduce
DENDRAL 1965 Stanford información
sobre
estructuras
químicas.
Análisis
Macsyma 1965 MIT matemático
complejo.
Interpreta en
HearSay 1965 Carnegie-Mellon lenguaje natural
un subconjunto
del idioma.
Diagnóstico de
Mycin 1972 Stanford enfermedades
de la sangre.
Herramienta
para la
Tieresias 1972 Stanford transformación
de
conocimientos.
Exploración
mineral y
Prospector 1972 Stanford herramientas de
identificación.
Herramienta
Age 1973 Stanford para generar
Sistemas
Expertos.
Herramientas
OPS5 1974 Carnegie-Mellon para el
desarrollo de
Sistemas
Expertos.
Herramienta de
Caduceus 1975 University of diagnóstico para
Pittsburg medicina interna.
Herramienta de
Rosie 1978 Rand desarrollo de
Sistemas
Expertos.
Configurador de
R1 1978 Carnegie-Mellon equipos de
computación
para DEC.
Continuación de la tabla de S.E y sus aplicaciones.
ESPECIFICACIÓN DE REQUERIMIENTOS
Una forma de clasificar los requerimientos se basa en separarlos en
funcionales y no funcionales. Los requerimientos funcionales son los
servicios que el sistema proveerá y la manera en la que este debe
comportarse. Los requerimientos no funcionales son las restricciones de los
servicios ofrecidos por el sistema.
El sistema debe proporcionar una herramienta que permita obtener una
solución del PAV por medio de diversos métodos, exactos y aproximados. El
sistema debe ofrecer la posibilidad de ser utilizado por usuarios no
necesariamente conocedores del tema, lo que permita que el software deba
resultar considerablemente accesible y fácil de usar.
Las restricciones del sistema se pueden resumir de la siguiente forma: el
sistema se topa con las limitaciones físicas de la tecnología poseída
actualmente. Esto significa que la capacidad de memoria que ofrece una
computadora tiene un tope, y esto nos lleva a establecer un máximo para las
instancias que sirvan de entrada al sistema. Un límite razonable para los
métodos aproximados, y el Híbrido MST-2Opt específicamente, es una PAV
de 200 nodos, mientras que los métodos exactos pueden trabajar con
instancias de 60 nodos generando un tiempo de ejecución de buenos
términos.
MODELADO UML
El lenguaje UML es un estándar OMG diseñado para visualizar,
especificar, construir y documentar software orientado a objetos.
Un modelo es una simplificación de la realidad.
El modelado es esencial en la construcción de software para:
Comunicar la estructura de un sistema complejo.
Especificar el comportamiento deseado del sistema.
Comprender mejor lo que estamos construyendo.
Descubrir oportunidades de simplificación y reutilización.
Un modelo proporciona “los planos” de un sistema y puede ser más o
menos detallado, en función de los elementos que sean relevantes en cada
momento.
El modelo ha de capturar “lo esencial”
Todo sistema puede describirse desde distintos puntos de vista:
- Modelos estructurales (organización del sistema)
- Modelos de comportamiento (dinámica del sistema)
UML estandariza 9 tipos de diagramas para representar gráficamente un
sistema desde distintos puntos de vista.
Ejercicios; procesos automatizados:
Diagrama UML de Clase.
Diagrama UML de Actividad.
Diagrama UML de Secuencia.
Diagrama UML de Casos de Uso.
Ejercicios manuales:
Diagrama UML de clase.
Diagrama UML de Actividad.
Diagrama UML de Secuencia.
Diagrama UML de Casos de Uso.
REFERENCIAS BIBLIOGRÁFICAS
Análisis Estructurado. (3 de septiembre de 2014). Casbeljon.
https://casbeljon.wordpress.com/2014/09/03/analisis-estructurado/
Metodología del software. (31 de enero de 2024). Wikipedia.
https://es.wikipedia.org/wiki/Metodolog
%C3%ADa_de_desarrollo_de_software
Rivas, A. (29 de noviembre de 2012). Mundoinformático321.
https://mundoinformatico321.blogspot.com/2012/11/metodologia-kendall-
kendall.html
Rivas, A. (1 de diciembre de 2012). Mundoinformático321.
https://mundoinformatico321.blogspot.com/2012/12/metodologia-de-james-
martin-y-uml.html
Narvaez, O. (7 de abril de 2014). Metodología de James Senn. Prezi.
https://prezi.com/vbf0gj7iom71/metodologia-de-james-senn/
Metodología para el desarrollo de sistemas de información y comunicación
según Jeffrey Whitten. (22 de abril de 2014). Slideshare.
https://es.slideshare.net/slideshow/metodologa-para-el-desarrollo-del-
sistemas-de-informacin-y-comunicacin-segn-jeffrey-whitten/33807394
Avilez, J. (s.f). Recolección de datos. Monografías.
https://www.monografias.com/trabajos12/recoldat/recoldat
Técnica de recolección de datos. (13 de mayo de 2009). Recodatos.
https://recodatos.blogspot.com/2009/05/tecnicas-de-recoleccion-de-
datos.html
Martínez, A. (19 de julio de 2016). Análisis de sistemas estructurados.
Slideshare. https://es.slideshare.net/slideshow/analisis-de-sistemas-
estructurados/64185691
Pardo Aguilar, C. (1998). Introducción al Análisis y Diseño Orientado a
Objetos. Repositorio Grial.
https://repositorio.grial.eu/bitstream/grial/265/1/ADOO.pdf
Quintanar León, T. (2007). Sistemas Expertos y sus Aplicaciones.
Universidad Autónoma del Estado de Hidalgo (UAEH).
https://www.uaeh.edu.mx/docencia/Tesis/icbi/licenciatura/documentos/
Sistemas%20expertos%20y%20sus%20aplicaciones.pdf
Análisis y diseño del sistema. (s.f). Catarina.
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/palacios_s_d/
capitulo3.pdf
Berzal, F. (s.f). UML. Universidad de Granada.
http://elvex.ugr.es/decsai/java/pdf/3e-uml.pdf
