FACULTAD DE COMERCIO Y ADMINISTRACION VICTORIA

Lic. Informática

MATERIA:

Desarrollo de Sistemas

PROFESOR:

Castro Lopez Jose Refujio

ALUMNA:

Stephanie Elizabeth Barron Ceballos

INDICE

Metodología de desarrollo de software………………………………………………………….2

Modelos de Ciclo de Vida para el desarrollo de software……………………………………..2

Etapas dentro de un ciclo de vida ……………………………………………………………….3

Roles más comunes que puede cumplir una persona en el Desarrollo del software………5

Modelo/Diagrama de las características de un sistema de software ysus partes componentes………………………………………………………………………………………..6

¿Qué son los casos de uso?...............................................................................................7

Diagrama de Flujo de Datos DFD………………………………………………………………..8

¿Qué es un UML?..............................................................................................................11

Los modelos de ciclo de vida más comunes para el desarrollo de software………………11

1

Metodología de desarrollo de software

Una metodología de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de información.

Modelos de Ciclo de Vida de Software

Modelo Cascada

Este es el más básico de todos losmodelos. su visión  dice que eldesarrollo de software esa travésde una secuencia simple de fases.Cada fase tiene un conjunto demetas bien definidas. Utiliza puntode control para pasar a la

siguiente fase: Análisis, Diseño, Codificación, Pruebas, Implementación, Mantenimiento. Se tarda mucho tiempo en pasar todoel ciclo. El fracaso del software es la comunicación con el usuario final. Se utiliza en proyectos con requerimientos bien definidos. Las flechas muestran el flujo de información entre las fases. este modelo se enfrasca en los en: Planear un proyecto antes de embarcarse en él. Definir el comportamiento externo antes de diseñar su arquitectura interna. Documentar los resultados de cadaactividad. Diseñar un sistema antes de codificarlo. Testear el sistema después de construirlo.

Modelo De Desarrollo IncrementalExisten riesgos en el desarrollo de sistemas largos y complejos. La forma de reducir los riesgos es construir una parte del sistema. Un sistema pequeño es siempre menos riesgoso que construir un sistema grande.es más fácil determinar si los requerimientos para los niveles subsiguientes son correctos.Reduciendo el tiempo de desarrollo de un sistema decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo. Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.

Modelo De Desarrollo EvolutivoEl modelo de desarrollo evolutivo construye versiones sucesivas deun producto, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.

Basada en esta retroalimentación, la especificación de requerimientos es actualizada. El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software.

2

Modelo de Prototipado de RequerimientosEl prototipado de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rápida tal como sea posible.

Modelo EspiralBasada en la necesidad continúa de refinarlos requerimientos y estimaciones del proyecto.

Efectivo para proyectos pequeños donde conla retroalimentación dada por el cliente, se aprueba las diferentes etapas, puede ocurrir el riesgo que no se defina bien

los objetivos por el cual el desarrollo puede ser caótico.

Modelo ConcurrenteEl modelo concurrente provee una meta-descripción del proceso software, tiene la capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.Los requerimientos son denominadas "líneas de base", es decir que cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a losrequerimientos son comunes y frecuentes.  

CICLO DE VIDA

Es la forma mediante la cual se describen los diferentes pasos quese deben seguir para el desarrollo de un software, partiendo desdeuna necesidad hasta llegar a la puesta en marcha de una solución ysu apropiado mantenimiento. El ciclo de vida para un software comienza cuando se tiene la necesidad de resolver un problema, y termina cuando el programa que se desarrolló para cumplir con los requerimientos, deja de ser utilizado.

Existen varias versiones del ciclo de vida del software entre las cuales se destacan: el ciclo de vida clásico o en cascada, el

modelo en espiral, el desarrollo de prototipos, el modelo por incrementos y el modelo extremo.

ETAPAS DEL CICLO DE VIDA DEL SOFTWARE

El ciclo de vida clásico del software siendo uno de los más utilizados tal como lo plantean diferentes autores, está conformado en su versión ampliada por siete etapas que se pueden representar mediante un modelo en cascada así:

3

 

- INGENIERÍA DE SISTEMAS: En esta etapa el analista luego de un minucioso y detallado estudio de los sistemas de una organización,detecta un problema o una necesidad que para su solución y/o satisfacción es necesario realizar un desarrollo de software.

- ANÁLISIS: En esta etapa se debe entender y comprender de forma detallada cual es la problemática a resolver, verificando el entorno en el cual se encuentra dicho problema, de tal manera que se obtenga la información necesaria y suficiente para afrontar su respectiva solución. Esta etapa es conocida como la del QUÉ se va a solucionar.

- DISEÑO: Una vez que se tiene la suficiente información del problema a solucionar, es importante determinar la estrategia que se va a utilizar para resolver el problema. Esta etapa es conocidabajo el CÓMO se va a solucionar.

- IMPLEMENTACIÓN: partiendo del análisis y diseño de la solución, en esta etapa se procede a desarrollar el correspondiente programaque solucione el problema mediante el uso de una herramienta computacional determinada.

- PRUEBAS: Los errores humanos dentro de la programación de los computadores son muchos y aumentan considerablemente con la complejidad del problema. Cuando se termina de escribir un programa de computador, es necesario realizar las debidas pruebas que garanticen el correcto funcionamiento de dicho programa bajo el mayor número de situaciones posibles a las que se pueda enfrentar.

4

- DOCUMENTACIÓN: Es la guía o comunicación escrita en sus diferentes formas, ya sea en enunciados, procedimientos, dibujos odiagramas que se hace sobre el desarrollo de un programa. La importancia de la documentación radica en que a menudo un programaescrito por una persona, es modificado por otra. Por ello la documentación sirve para ayudar a comprender o usar un programa o para facilitar futuras modificaciones (mantenimiento).

La documentación se compone de tres partes:

a. Documentación Interna: Son los comentarios o mensajes que se añaden al código fuente para hacer más claro el entendimiento de

los procesos que lo conforman, incluyendo las precondiciones y lasposcondiciones de cada función.

b. Documentación Externa: Se define en un documento escrito con los siguientes puntos:

Descripción del Problema

Datos del Autor

Algoritmo (diagrama de flujo o Pseudocódigo)

Diccionario de Datos

Código Fuente (programa)

c. Manual de Usuario: Describe paso a paso la manera como funcionael programa, con el fin de que el usuario lo pueda manejar para que obtenga el resultado deseado.

- MANTENIMIENTO: una vez instalado un programa y puesto en marcha para realizar la solución del problema previamente planteado o satisfacer una determinada necesidad, es importante mantener una estructura de actualización, verificación y validación que permitan a dicho programa ser útil y mantenerse actualizado según las necesidades o requerimientos planteados durante su vida útil. Para realizar un adecuado mantenimiento, es necesario contar con una buena documentación del mismo.

Para terminar de entender la problemática en la cual se desarrollaeste libro es importante tener unos conceptos claros y precisos delo que es el Análisis y el Diseño de Algoritmos.

Roles más común que puede cumplir una persona en el Desarrollo del software

➢ Ingeniero de requerimientos (Documentador): trabaja con el cliente para realizar el análisis y la especificación del sistema a construir. Está capacitado para obtener claramente todos los requisitos necesarios para el desarrollo del software.

5

➢ Analista: Estudia el problema (de una complejidad determinada) ylo descompone en su problemas de menor complejidad. Transforma losrequisitos de usuario en requisitos de software.

➢ Diseñador: Es el encargado de generar el diseño arquitectónico ydiseño detallado del sistema, basándose en los requisitos.

➢ Programador: Los programadores deben convertir la especificacióndel sistema en código fuente ejecutable utilizando uno o más lenguajes de programación, así como herramientas de software de apoyo a la programación. No necesita conocer el funcionamiento delsistema, solo se encarga de codificar los módulos a partir de los distintos datos de entrada y salida que se le especifican.

➢ Tester: El tester realiza las tareas de detección y eliminación de los errores y defectos del sistema en construcción.

➢ Ingeniero de Manutención: adapta los sistemas existentes de acuerdo amcambios en su ambiente externo, realiza las mejoras pedidas por los usuarios, y la adaptación del sistema para usos futuros.

Modelo/Diagrama de las características de un sistema de software ysus partes componentes:

Modelo Esencial: Responde a la pregunta ¿qué tiene que satisfacer el sistema?

Modelo del Ambiente: Declaración de los Objetivos, captura de requerimientos.

Modelo de Comportamiento: Análisis.

6

Modelo de Implementación: Responde a la pregunta ¿Cómo realizar elsistema?

Se deben considerar, las imperfecciones de la tecnología y determinar: la cantidad de procesadores necesarios, las cualidadesde estos, el tamaño de disco necesario de acuerdo al volumen de lainformación a ser almacenada, etc. Luego se diseña la solución sobre la base de esas restricciones tecnológicas.

Modelo del Usuario: Interfaz.

Modelo de Distribución: Decide como distribuyo mi sistema.

Modelo de Tareas: Describe todas las decisiones relativas a la arquitectura de software.

Modelo de Procesadores: Describe todas las decisiones relativas a la arquitectura de hardware.

Modelo de Programa: Se realiza un diagrama estructurado del programa a partir de las técnicas y estrategias elegidas.

Enumere los modelos de ciclos de vida mas comunes para el desarrollo de software, junto con sus características principales.

➢ El ciclo de vida en Cascada, su principal característica es que para pasar a la siguiente etapa debe estar terminada la primera. Esto traía varios problemas a la hora de hacer modificaciones si eran requeridas.

➢ El ciclo de vida en Espiral, soluciona el problema del ciclo de vida en cascada ya que su desarrollo es incremental y permite realizar tareas de diferentes etapas.

Caso de uso

Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores. En el contexto de ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollaránentre un sistema y sus actores en respuesta a un evento que iniciaun actor principal sobre el propio sistema. Los diagramas de casosde uso sirven para especificar la comunicación y el comportamientode un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

7

Diagrama de Flujo de Datos

Un diagrama de flujo de datos (DFD sus siglas en español e inglés)es una representación gráfica del flujo de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado). Es una práctica común para un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción entre el sistema y las entidades externas. Este contexto a nivel de DFD se "explotó"

Los diagramas de flujo de datos fueron inventados por Larry Constantine, el desarrollador original del diseño estructurado,

basado en el modelo de computación de Martin y Estrin: "flujo gráfico de datos" . Los diagramas de flujo de datos (DFD) son una de las tres perspectivas esenciales de Análisis de Sistemas Estructurados y Diseño por Método SSADM. El patrocinador de un proyecto y los usuarios finales tendrán que ser informados y consultados en todas las etapas de una evolución del sistema. Con un diagrama de flujo de datos, los usuarios van a poder visualizarla forma en que el sistema funcione, lo que el sistema va a lograr, y cómo el sistema se pondrá en práctica. El antiguo sistema de diagramas de flujo de datos puede ser elaborado y se comparó con el nuevo sistema de diagramas de flujo para establecerdiferencias y mejoras a aplicar para desarrollar un sistema más eficiente. Los diagramas de flujo de datos pueden ser usados para proporcionar al usuario final una idea física de cómo resultarán los datos a última instancia, y cómo tienen un efecto sobre la estructura de todo el sistema. La manera en que cualquier sistema es desarrollado, puede determinarse a través de un diagrama de flujo de datos. modelo de datos.

niveles, los cuales son:

Diagrama de Contexto: Nivel 0

En el diagrama de contexto se caracterizan todas las interaccionesque realiza un sistema con su entorno (entidades externas), estas pueden ser otros sistemas, sectores internos a la organización, o factores externos a la misma. Se dibuja un sólo proceso que representa al sistema en cuestión y se escribe su nombre en dicha burbuja como un sustantivo común más adjetivos. De él solamente parten los flujos de datos que denotan las interrelaciones entre el sistema y sus agentes externos, no admitiéndose otros procesos ni almacenamientos en el dibujo.

Resulta de gran utilidad para los niveles posteriores de análisis como herramienta de balanceo. Y es conocido como el Diagrama de Flujo de Datos DFD de Nivel "0"

8

Diagrama de Nivel Superior: Nivel 1

En el diagrama de nivel superior se plasman todos los procesos quedescriben al proceso principal. En este nivel los procesos no suelen interrelacionarse directamente, sino que entre ellos debe existir algún almacenamiento o entidad externa que los una. Esta regla de construcción sirve como ayuda al analista para contemplarque en un nivel tan elevado de abstracción (DFD Nivel 1) es altamente probable que la información que se maneja requiera ser almacenada en el sistema aunque no esté especificado por un Requisito funcional, siendo en realidad un requisito no-funcional.

Diagrama de Detalle o Expansión: Nivel 2

En un diagrama de nivel 2 o mayor, comienzan a explotarse las excepciones a los caminos principales de la información dado que aumenta progresivamente el nivel de detalle. De aquí en adelante se permiten los flujos entre procesos.

El DFD (Diagrama De Flujo De Datos) nivel 2 puede considerarse el máximo para ser validado en forma conjunta con el usuario dado queen los niveles posteriores el alto grado de complejidad del diagrama puede resultar de muy difícil lectura para personas ajenas al equipo de sistemas. También se recomienda el diagrama denivel superior.

Componentes de un Diagrama de Flujo de Datos (DFD) según la notación de Yourdon y DeMarco.13 tipos de diagramas UML

9

¿Que son los UML?

UML, ¿Método o Lenguaje de Modelado?

UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de estructurarel pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método.

Los principales beneficios de UML son:

Mejores tiempos totales de desarrollo (de 50 % o más). Modelar sistemas (y no sólo de software) utilizando conceptos

orientados a objetos. Establecer conceptos y artefactos ejecutables.

Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.

Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.

Mejor soporte a la planeación y al control de proyectos. Alta reutilización y minimización de costos.

Diagrama de clases

Un diagrama de clases es un tipo de diagrama estático que describela estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.

Representación de: - Requerimientos en entidades y actuaciones. - La arquitectura conceptual de un dominio - Soluciones de diseño enuna arquitectura - Componentes de software orientados a objetos.

11

Diagrama de componentes

Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado.

Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras,bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitecturade software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.

Diagrama de objetos

Los diagramas de objetos son utilizados durante el proceso de Análisis y Diseño de los sistemas informáticos en la metodología UML.

Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias específicas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase.

Una diferencia con los diagramas de clase es que el compartimientode arriba va en la forma Nombre de objeto: Nombre de clase.

12

Por ejemplo, Miguel: Persona.

Diagrama de estructura compuesta

Un diagrama de estructura compuesta es un tipo de diagrama de estructura estática en el Lenguaje de Modelado Unificado (UML), que muestra la estructura interna de una clase y las colaboraciones que esta estructura hace posibles. Esto puede incluir partes internas, puertas mediante las cuales, las partes interactúan con cada una de las otras o mediante las cuales, instancias de la clase interactúan con las partes y con el mundo exterior, y conectores entre partes o puertas. Una estructura compuesta es un conjunto de elementos interconectados que colaboran en tiempo de ejecución para lograr algún propósito. Cadaelemento tiene algún rol definido en la colaboración.

13

Diagrama de despliegue

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.

Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo.

Diagrama de paquetes

En el Lenguaje Unificado de Modelado, un diagrama de paquetes muestra cómo un sistema está dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un paquete está pensado como un directorio, los diagramas de paquetes suministran una descomposición de la jerarquía lógica de un sistema.

14

Diagrama de actividades

En el Lenguaje de Modelado Unificado, un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general.

En SysML el diagrama de Actividades ha sido extendido para indicarflujos entre pasos que mueven elementos físicos (e.g., gasolina) o

energía (e.g., presión). Los cambios adicionales permiten al diagrama soportar mejor flujos de comportamiento y datos continuos.

15

Diagrama de casos de uso

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento.

El Lenguaje de Modelado Unificado define una notación gráfica pararepresentar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son amenudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.

Diagrama de estados

En UML, un diagrama de estados es un diagrama utilizado para identificar cada una de las rutas o caminos que puede tomar un flujo de información luego de ejecutarse cada proceso.Permite identificar bajo qué argumentos se ejecuta cada uno de losprocesos y en qué momento podrían tener una variación.

16

El diagrama de estados permite visualizar de una forma secuencial la ejecución de cada uno de los procesos.

Diagrama de secuencia

El diagrama de secuencia es un tipo de diagrama usado para modelarinteracción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"

Diagrama de comunicación

En el Lenguaje Unificado de Modelado (UML) 2.0, un diagrama de comunicación es una versión simplificada del diagrama de colaboración de la versión de UML 1.x.

Un diagrama de comunicación modela las interacciones entre objetoso partes en términos de mensajes en secuencia. Los diagramas de comunicación representan una combinación de información tomada desde el diagrama de clases, secuencia, y diagrama de casos de usodescribiendo tanto la estructura estática como el comportamiento dinámico de un sistema.

Diagrama de tiempos

Un diagrama de tiempos o cronograma es una gráfica de formas de

onda digitales que muestra la relación temporal entre varias señales, y cómo varía cada señal en relación a las demás.

Un cronograma puede contener cualquier número de señales relacionadas entre sí. Examinando un diagrama de tiempos, se puededeterminar los estados, nivel alto o nivel bajo, de cada una de las señales en cualquier instante de tiempo especificado, y el instante exacto en que cualquiera de las señales cambia de estado con respecto a las restantes.

17

Diagrama global de interacciones

Un diagrama global de las interacciones (en inglés: interaction overview diagram) es una de las trece clases de diagramas en el Lenguaje de Modelado Unificado (UML), un lenguaje de modelamiento para software y otros sistemas.

18

Bibliografia:

Metodología De Desarrollo De Software

Http://Es.Wikipedia.Org/Wiki/Metodolog%C3%Ada_De_Desarrollo_De_Software

Modelos De Ciclo De Vida De Software

Http://Www.Hanantek.Com/Modelos-Ciclo-Vida-Software

Ciclo De Vida Del Software

Http://Www.Monografias.Com/Trabajos75/Proyectos-Informaticos/Proyectos-Informaticos2.Shtml

Roles Más Comunes Que Puede Cumplir Una Persona En El Desarrollo Del Software

Modelo/Diagrama De Las Características De Un Sistema De Software YSus Partes Componentes

http://www.comoustedyasabe.com.ar/datos/Tercero/1er_cuatrimestre/Metodologias/Practica/Practico1.pdf

Diagrama de casos de uso

Diagrama de Flujo de Datos

http://mitareadeuml.blogspot.mx/