Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Metodologia y prototipo

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
República Bolivariana de Venezuela
Ministerio del Poder Popular para la Educación
Instituto Universitario “Antonio José de...
Introducción
La metodología y desarrollo de software son conjuntos explicativos de cómo
desarrollar prototipos de invenció...
Metodología- Prototipos.
Método: Conjunto de herramientas precisas a nivel técnico que facilita y brindan
soporte para el ...
Anuncio
Anuncio
Anuncio
Cargando en…3
×

Eche un vistazo a continuación

1 de 16 Anuncio
Anuncio

Más Contenido Relacionado

Presentaciones para usted (20)

Similares a Metodologia y prototipo (20)

Anuncio

Más reciente (20)

Metodologia y prototipo

  1. 1. República Bolivariana de Venezuela Ministerio del Poder Popular para la Educación Instituto Universitario “Antonio José de Sucre” Informática III Alumno: Ángel Campos C.I: 20.883.194 Puerto Ordaz, 04/12/2014
  2. 2. Introducción La metodología y desarrollo de software son conjuntos explicativos de cómo desarrollar prototipos de invención de software, llevando para esto un conjunto de normas y/o procesos por el cual regidos por estructuras del mismo. El método está compuesto por lineamientos y estrategias que brindan soporte y ayudan a facilitar su construcción diseño y desarrollo. Seguidamente, esto conlleva, a la formación progresiva de un software pero para esto hay que tomar en cuenta muchas opciones de cómo será su funcionamiento y como estabilizar su ciclo de vida y mejoras que se tengan que hacer para el buen manejo y desarrollo del mismo y así satisfacer el producto final. Finalmente, Basadas en la evolución de los prototipos antes diseñados formar parte de presentaciones continuas de la misma creacion es decir tomar ejemplos anteriores y facilitar la creacion del mismo, no obstante realizar análisis y mejorar errores para un mejor rendimiento, y esto, conlleva a un final de desarrollo practico y útil para su creacion y finalidad .
  3. 3. Metodología- Prototipos. Método: Conjunto de herramientas precisas a nivel técnico que facilita y brindan soporte para el logro de una meta, es decir culminar el final de algo en específico. Metodología de desarrollo de software se describe como el conjunto de herramientas, técnicas, procedimientos y soporte documental para el diseño de Sistemas de información. 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. A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados diferenciándose por su fortaleza y debilidad. El framework para 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 Metodología Una metodología es un conjunto integrado de técnicas y métodos que permite abordar de forma homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo.
  4. 4. Una definición estándar de metodología puede ser el conjunto de métodos que se utilizan en una determinada actividad con el fin de formalizarla y optimizarla. Determina los pasos a seguir y cómo realizarlos para finalizar una tarea.15 Si esto se aplica a la Ingeniería de software, podemos destacar que una metodología:  Optimiza el proceso y el producto software.  Es una guía en la planificación y en el desarrollo del software.  Define qué hacer, cómo y cuándo durante todo el desarrollo y mantenimiento de un proyecto.  Una metodología define una estrategia global para enfrentarse con el proyecto. Entre los elementos que forman parte de una metodología se pueden destacar: Fases: tareas a realizar en cada fase. Productos: E/S de cada fase, documentos. Procedimientos y herramientas: apoyo a la realización de cada tarea. Criterios de evaluación: del proceso y del producto. Saber si se han logrado los objetivos.
  5. 5. El ciclo de vida es el conjunto de fases por las que pasa el sistema que se está desarrollando desde que nace la idea inicial hasta que el software es retirado o remplazado (muere).15 Entre las funciones que debe tener un ciclo de vida se pueden destacar: Determinar el orden de las fases del proceso de software. Establecer los criterios de transición para pasar de una fase a la siguiente. Definir las entradas y salidas de cada fase. Describir los estados por los que pasa el producto. Describir las actividades a realizar para transformar el producto. Definir un esquema que sirve como base para planificar, organizar, coordinar, desarrollar, entre otros. Las etapas de un ciclo de vida de un software son: Las etapas de un ciclo de vida de un software son: Inicio: éste es el nacimiento de la idea. Aquí definimos los objetivos del proyecto y los recursos necesarios para su ejecución. Hacia dónde queremos ir, y no cómo queremos ir. Las características implícitas o explícitas de cada proyecto hacen necesaria una etapa previa destinada a obtener el objetivo por el cual se escribirán miles o cientos de miles de líneas de código. Un alto porcentaje del éxito de nuestro proyecto se definirá en estas etapas que, al igual que la etapa de debugging, muchos líderes de proyecto subestiman. Planificación: idearemos un planeamiento detallado que guíe la gestión del proyecto, temporal y económicamente. Implementación: acordaremos el conjunto de actividades que componen la realización del producto.
  6. 6. Puesta en producción: nuestro proyecto entra en la etapa de definición, allí donde se lo presentamos al cliente o usuario final, sabiendo que funciona correctamente y responde a los requerimientos solicitados en su momento. Esta etapa es muy importante no sólo por representar la aceptación o no del proyecto por parte del cliente o usuario final sino por las múltiples dificultades que suele presentar en la práctica, alargándose excesivamente y provocando costos no previstos. Control en producción: control del producto, analizando cómo el proceso difiere o no de los requerimientos originales e iniciando las acciones correctivas si fuesen necesarias. Cuando decimos que hay que corregir el producto, hacemos referencia a pequeñas desviaciones de los requerimientos originales que puedan llegar a surgir en el ambiente productivo. Si nuestro programa no realiza la tarea para lo cual fue creada, esta etapa no es la adecuada para el rediseño. Incluimos también en esta etapa el liderazgo, documentación y capacitación, proporcionando directivas a los recursos humanos, para que hagan su trabajo en forma correcta y efectiva. Modelos de procesos en el desarrollo de software
  7. 7. Un modelo de proceso para el desarrollo de software es una representación simplificada de pasos, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real. Estos modelos tienen como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. La mayoría de los modelos de procesos de desarrollo del software son dirigidos por el tiempo; cuanto más tarde sea, más atrás se encontrará en el proceso de desarrollo. Como todo proceso, están constituidos de pasos o fases que contienen a su vez actividades, estos modelos de desarrollo de software se basan en un ciclo de vida para desarrollar el mismo, como lo son:  La necesidad de solucionar un problema (surgimiento de necesidades)  Inicio del proceso (desarrollo), dentro de esta fase se encuentra la definición del proyecto, el análisis del contexto, definición de requerimientos, diseño del sistema, construcción del sistema, pruebas e implantación.  Operación y mantenimiento, donde realiza ajustes y se buscan fallas.  Renovación o extinción. Clasificación de las Metodologías según el modelo de proceso Modelos Convencionales o Prescriptivos de Procesos Los modelos convencionales o modelos prescriptivos de procesos permiten llenar el marco de trabajo con un conjunto de tareas orientadas al desarrollo de un software.
  8. 8. Se les llama "prescriptivos" porque prescriben un conjunto de elementos del proceso, tales como:  Actividades del Marco de Trabajo.  Acciones de la Ingeniería del software.  Tareas.  Productos de trabajo.  Aseguramiento de la calidad.  Mecanismos de control del cambio para cada proyecto. Estos modelos son útiles si queremos describir un conjunto único de actividades dentro de un marco de trabajo para un proceso de software. Cada actividad debe contener un conjunto de acciones de ingeniería del software, y definir cada acción en cuanto a un conjunto de tareas que identifique el trabajo (y los productos del trabajo) que deben completarse para alcanzar las metas de desarrollo. Sin importar el modelo del proceso que se desee usar, los ingenieros de software eligen una manera tradicional para realizar el marco de trabajo genérico para el proceso, ya que estos modelos se caracterizan por ser en esencia rígida, estricta y los más utilizados. En las metodologías convencionales, el ciclo de vida de un proyecto, puede definirse como un ciclo de vida lineal, ya que imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software más eficiente. Para ello, se hace énfasis en la planificación total de todo el trabajo a realizar y una vez que está todo detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada. Además, las metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden predecirse o bien pueden variar.
  9. 9. Modelo en Cascada El modelo en cascada, algunas veces llamado el ciclo de vida clásico, sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimientos del cliente y que continúa con la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado. Este modelo es aplicable en donde existen ocasiones en que los requisitos de un problema se entienden de una manera razonable y deben estar bien definidos, también cuando el trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal, esta situación se encuentra a veces cuando es necesario hacer adaptaciones o mejorías bien definidas a un sistema existente. Modelo de Procesos Incrementables El modelo incremental combina elementos del modelo en cascada aplicado en forma iterativa.
  10. 10. El modelo incremental aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce "incrementos" del software. Por ejemplo, el software procesador de texto, desarrollado con el paradigma incremental en su primer incremento, podría realizar funciones básicas de administración de archivos, edición y producción de documentos; en el segundo incremento, ediciones más sofisticadas, y tendría funciones más complejas de producción de documentos; en el tercer incremento, funciones de corrección ortográfica y gramatical; y en el cuarto, capacidades avanzadas de configuración de página. Se debe tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construcción de prototipos que se expone más adelante. Modelo de desarrollo rápido de aplicaciones (DRA) El desarrollo rápido de aplicaciones (DRA) es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptación a "alta velocidad" del modelo en cascada en el que se logra el desarrollo rápido mediante un enfoque de construcción basado en componentes. Si se entienden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite que un equipo de desarrollo cree un "sistema completamente funcional" dentro de un periodo muy corto (por ejemplo, de 60 a 90 días).
  11. 11. Modelos Evolutivos Se reconoce que el software al igual que todos los sistemas complejos evoluciona con el tiempo, los requisitos de gestión y de producto a menudo cambian conforme a que el desarrollo procede haciendo que el camino que lleva al producto final no sea real. El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Los modelos evolutivos son iterativos, se caracteriza por la forma en que permiten a los ingenieros en software desarrollar versiones cada vez más completas del software. Modelo de Prototipos. También conocido como desarrollo con prototipo o modelo de desarrollo evolutivo, se inicia con la definición de los objetivos globales para el software, luego se identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Este modelo se utiliza para dar al usuario una vista preliminar de parte del software. Este modelo es básicamente prueba y error ya que si al usuario no le gusta una parte del prototipo significa que la prueba fallo por lo cual se debe corregir el error que se tenga hasta que el usuario quede satisfecho.
  12. 12. Etapas  Recolección y refinamiento de requisitos  Modelado, diseño rápido  Construcción del Prototipo  Desarrollo, evaluación del prototipo por el cliente  Refinamiento del prototipo  Producto de Ingeniería Cómo se lleva a cabo Se comienza elaborando un prototipo del producto final: qué aspecto tendrá, cómo funcionará. Para muchas interfaces de usuario, este modelo puede resultar tan simple como unos dibujos con lápiz y papel o tan complejo como el propio código operativo final. Para interfaces de hardware o estaciones de trabajo, el modelo puede consistir en maquetas de espuma, caucho, cartón o cartulina. Cuanto más próximo se encuentre el prototipo al producto real, mejor será la evaluación, si bien se pueden obtener magníficos resultados con prototipos de baja fidelidad. Ventajas  No modifica el flujo del ciclo de vida  Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios  Reduce costo y aumenta la probabilidad de éxito  Exige disponer de las herramientas adecuadas  Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.  También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.
  13. 13. Para que sea efectivo  Debe ser un sistema con el que se pueda experimentar  Debe ser comparativamente barato (menor que el 10%)  Debe desarrollarse rápidamente  Énfasis en la interfaz de usuario  Equipo de desarrollo reducido  Herramientas y lenguajes adecuadas Desventajas  Debido a que el usuario ve que el prototipo funciona piensa que este es el producto terminado y no entienden que recién se va a desarrollar el software.  El desarrollador puede caer en la tentación de ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y mantenimiento que tiene con el cliente. Tipos de Modelo de Prototipos  Modelo de Prototipos rápido: Metodología de diseño que desarrolla rápidamente nuevos diseños, los evalúa y prescinde del prototipo cuando el próximo diseño es desarrollado mediante un nuevo prototipo.  Modelo de Prototipos reutilizable: También conocido como "Evolutionary Prototyping"; no se pierde el esfuerzo efectuado en la construcción del prototipo pues sus partes o el conjunto pueden ser utilizados para construir el producto real.
  14. 14.  Modelo de Prototipos Modular: También conocido como Prototipado Incremental (Incremental prototyping); se añaden nuevos elementos sobre el prototipo a medida que el ciclo de diseño progresa.  Modelo de Prototipos Horizontal: El prototipo cubre un amplio número de aspectos y funciones pero la mayoría no son operativas. Resulta muy útil para evaluar el alcance del producto, pero no su uso real.  Modelo de Prototipos Vertical: El prototipo cubre sólo un pequeño número de funciones operativas. Resulta muy útil para evaluar el uso real sobre una pequeña parte del producto.  Modelo de Prototipos de Baja-fidelidad: El prototipo se implementa con papel y lápiz, emulando la función del producto real sin mostrar el aspecto real del mismo. Resulta muy útil para realizar test baratos.  Modelo de Prototipos de Alta-fidelidad: El prototipo se implementa de la forma más cercana posible al diseño real en términos de aspecto, impresiones, interacción y tiempo. Tipos de prototipos Hay dos clases de prototipos el desechable y el evolucionario El desechable: nos sirve para eliminar dudas sobre lo que realmente quiere el cliente además para desarrollar la interfaz que más le convenga al cliente. El evolucionario: es un modelo parcialmente construido que puede pasar de ser prototipo a ser software pero no tiene una buena documentación y calidad. Versión # 2 Versión # 1 ANALISIS DISEÑO CODIGO PRUEBAS PRODUCTO ANALISIS DISEÑO CODIGO PRUEBAS
  15. 15. Conclusiones Una metodología se basa en una combinación de los modelos de proceso genéricos para obtener como beneficio un software que soluciones un problema La trascendencia de las metodologías se ha hecho notoria, pasando de solo programar, establecer funciones en etapas o módulos, objetos, y por último agilizar el desarrollo del software y minimizar los costos. En el desarrollo convencional todo el programa está en un solo bloque, con ejecución secuencial de instrucciones En el desarrollo estructurado los programas están divididos en distintos bloques, estos bloques tienen funciones que se van confeccionado en forma de arriba- abajo, empezando desde las generales hasta las particulares, hasta llegar a detallar cada uno de los procedimientos y su interacción. El desarrollo orientado a objetos comprende dividir un programa en clases, donde estas clases estarán estructuradas por propiedades, atributos, variables, pretendiendo simular y describir de manera conceptual a un objeto. Los métodos ágiles fueron pensados especialmente para equipos de desarrollo pequeños, con plazos reducidos, requisitos volátiles y nuevas tecnologías. El modelado de negocio describe como desarrollar una visión de la nueva organización, basado en esta visión se definen procesos, roles y responsabilidades de la organización por medio de un Modelo de Casos de Uso del Negocio Los modelos de procesos permiten al analista de sistemas desarrollar un plan de requisitos del software, permiten establecer un trabajo en forma ordenada, además que existen muchos modelos que se adaptan a las exigencias del proyecto, solo debemos saber cual nos conviene.
  16. 16. Bibliografía  Alonso, F. y Martínez, L. (2005). Introducción a la ingeniería del software: modelos de desarrollo de programas (primera edición). España: Delta Publicaciones. Pág. 75-76  Sommerville, I. (2005). Ingeniería del software (Séptima Edición). España: Pearson Educación.  Hernán, M. (2004). Diseño de una Metodología Ágil de Desarrollo de Software. Tesis de Grado de Ingeniería en Informática. Universidad de Buenos Aires. Pág. 11-12  Sommerville, I. (2006). Ingeniería del software (Séptima Edición). Madrid. Pág. 62  Espinoza, A. Metodologías de desarrollo de software [documento en línea].Disponible en: « www.slideshare.net/juliopari/4-clase-metodologia-de- desarrolo-de-software » [consulta: 11 de junio de 2012]  Carballar, D. Ingeniería de software [documento en línea]. «  www.eduinnova.es/dic09/Ingenieria_Software.pdf » [consulta: 10 de junio de 2012]  7.Disponible en la web:  «www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html#paradigmaOO » [consulta: 10 de junio de 2012]  Kenneth, E. y Kendall, J. (2005). Análisis Y Diseño de Sistemas (Sexta edición). México.  Solís, M. (2003). Una explicación de la programación extrema (XP). Madrid. Pág. 103  Ordoñez (2011). Método de Desarrollo de sistemas dinámicos [documento en línea]. Disponible en:« www.slideshare.net/oscarfico/metodos-dinamicos » [consulta: 8 de junio de 2012]

×