NOMBRE: AGUSTIN ZEPITA QUISPE
LIC: ALDO VALDEZ
MATERIA: INF-162
INFOGRAFIA
jueves, 31 de marzo de 2016
CUESTIONARIO
CUESTIONARIO
1. ¿QUE MODELOS SE PUEDEN INCLUIR EN EL PROCESO DE SOFTWARE?
Rpta.- Un modelo de flujo de trabajo, Un modelo de flujo de datos o de actividad, Un
modelo de rol/acción
2. ¿CUALES SON LOS MODELOS GENERALES O PARADIGMAS DE DESARROLLO
DE SOFTWARE?
Rpta.- El enfoque en cascada, Desarrollo iterativo, Ingeniería del software basada en
componentes (CBSE)
3.¿CUALES SON LAS ETAPAS QUE DEBEN CUMPLIRSE DE FORMA SUCESIVA?
Rpta.- especificación de requisitos, diseño del software,
construcción o implementan del software, integración , pruebas o validación,
despliegue o instalación, mantenimiento
4.¿QUE ES EL MODELO MOORE?
Rpta.- El modelo de Moore impone una limitación: La salida depende únicamente del estado y NO
de la entrada.
5. .¿QUE ES EL MODELO MEALY?
Rpta.- Las salidas están en función de dos, el estado presente y las entradas.
6.¿QUE ES E MODELO CASCADA?
Rpta.- considera las actividades fundamentales del proceso de especificación, desarrollo,
validación y evolución, y los representa como fases separadas del proceso
7.¿EN QUE CONSTA EL DESRROLLO EVOLUTIVO?
Rpta.- 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
8.¿ QUE SON LOS PROTOTIPOS DESECHABLES?
Rpta.- donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos
del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema.
9.¿ QUE SIGNIFICA EL CRYSTAL CLEAR?
Rpta.- Crystal es una metodología de desarrollo de Software ágil, más que una
metodología se la considera una familia de metodologías, debido a que se subdivide
en varios tipos de metodologías en función a la cantidad de persona que vayan a estar
en el proyecto.
10.¿CUALES SON SUS CARACTERÍSTICAS FUNDAMENTALES DEL MÉTODO
AGIL?
Rpta.- Desarrollo iterativo e incrementa, Pruebas unitarias continuas, Programación
en parejas, integración del equipo de programación con el cliente, Corrección de todos
los errores, Refactorización del código, Propiedad del código compartida
miércoles, 30 de marzo de 2016
INFORME
DEFINICIÓN DE MODELOS DE PROCESO DE SOFTWARE
Un modelo de procesos del software es una descripción simplificada de un proceso
del software que presenta una visión de ese proceso. Estos modelos pueden incluir
actividades que son parte de los procesos y productos de software y el papel de las
personas involucradas en la ingeniería del software. Algunos ejemplos de estos tipos de
modelos que se pueden producir son:
1. Un modelo de flujo de trabajo. Muestra la secuencia de actividades en el proceso
junto con sus entradas, salidas y dependencias. Las actividades en este modelo
representan acciones humanas.
2. Un modelo de flujo de datos o de actividad. Representa el proceso como un
conjunto de actividades, cada una de las cuales realiza alguna transformación en los
datos. Muestra cómo la entrada en el proceso, tal como una especificación, se transforma
en una salida, tal como un diseño. Pueden representar transformaciones llevadas a
cabo por las personas o por las computadoras.
3. Un modelo de rol/acción. Representa los roles de las personas involucrada en el
proceso del software y las actividades de las que son responsables.
La mayor parte de los modelos de procesos del software se basan en uno de los tres
modelos generales o paradigmas de desarrollo de software:
1. El enfoque en cascada. Considera las actividades anteriores y las representa como
fases de procesos separados, tales como la especificación de requerimientos, el
diseño del software, la implementación, las pruebas, etcétera. Después de que cada
etapa queda
definida «se firma» y el desarrollo continúa con la siguiente etapa.
define las siguientes etapas que deben cumplirse de forma sucesiva:
- especificación de requisitos
- diseño del software
- construcción o implementan del software
- integración
- pruebas o validación
- despliegue o instalación
- mantenimiento
Siguiendo el
modelo de cascada de forma estricta, sólo cuando se finaliza una fase, comienza
la otra. En ocasiones se realiza una revisión antes de iniciar la siguiente
fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso
de control formal de cambio). Las revisiones también se utilizan para asegurar
que la fase anterior ha sido totalmente finalizada; los criterios para
completar una fase se conocen frecuentemente con el término inglés
"gate" (puerta). Este modelo desaconseja revisitar y revisar fases
que ya se han completado. Esta falta de flexibilidad en un modelo de cascada
puro ha sido fuente de crítica de los defensores de modelos más flexibles.
2. Desarrollo iterativo. Este enfoque entrelaza las actividades de especificación, desarrollo
y validación. Un sistema inicial se desarrolla rápidamente a partir de especificaciones muy
abstractas. Este se refina basándose en las peticiones del cliente
para producir un sistema que satisfaga las necesidades de dicho cliente. El sistema puede
entonces ser entregado. De forma alternativa, se puede re implementar utilizando un
enfoque más estructurado para producir un sistema más sólido y mantenible.
3. Ingeniería del software basada en componentes (CBSE). Esta técnica supone que
las partes del sistema existen. El proceso de desarrollo del sistema se enfoca en la
integración de estas partes más que desarrollarlas desde el principio.
DESCRIPCIÓN DE AL MENOS 3 MODELOS DEL TIPO SECUENCIAL
Para construir sistemas lógicos secuenciales (SLS) de la forma más mecánica posible hace
Existen diversos métodos. Los más sencillos son el modelo de Moore y el modelo de
Mealy, que describen el comportamiento del sistema por medio de grafos basados en la
noción de estado
MODELO MOORE
El modelo de Moore impone una limitación: La salida depende únicamente del estado y NO
de la entrada.
Por tanto, la ecuación de salida Y se nos reduce y nos quedan las expresiones:
Yt = H(Et) ecuación de salida
Et+1 = G(Xt, Et) ecuación de transición de estados
Vamos a realizar el ejercicio contrario, es decir, partiendo del circuito obtener el grafo
asociado.
En este caso también hay que tener en cuenta la limitación de Moore: las salidas no
pueden depender de las entradas sino del estado en que nos encontremos.
En el caso de encontrar un circuito en el que las salidas dependan de las entradas através de alguna puerta, el modelo de Moore no servirá para su análisis.
MODELO MEALY
Las salidas están en función de dos, el estado presente y las entradas.
DESCRIPCIÓN DE AL MENOS 3 MODELOS DEL TIPO
EVOLUTIVO
Un modelo de desarrollo es una
representación abstracta de un proceso de software, cada modelo representa el
proceso de desarrollo de software de una manera en particular. A pesar de estar
definidos claramente, no representan necesariamente la realidad de cómo se debe
desarrollar el software, sino que establece un enfoque común. Un modelo puede
ser modificado y adaptado de acuerdo a las necesidades del software en
desarrollo.
En forma general podemos clasificar los
modelos de desarrollo en 3 grupos:
1. El modelo en
cascada.
Considera
las actividades fundamentales del proceso de especificación, desarrollo,
validación y evolución, y los representa como fases separadas del proceso,
tales como la especificación de requerimientos, el diseño del software, la
implementación, las pruebas, etcétera.
2. Desarrollo evolutivo
. Este
enfoque entrelaza las actividades de especificación, desarrollo y validación.
Un sistema inicial se desarrolla rápidamente a partir de especificaciones
abstractas. Éste se refina basándose en las peticiones del cliente para
producir un sistema que satisfaga sus necesidades.
3. Ingeniería
del software basada en componentes.
Este enfoque
se basa en la existencia de un número significativo de componentes
reutilizables. El proceso de desarrollo del sistema se enfoca en integrar estos
componentes en el sistema más que en desarrollarlos desde cero.
Aunque existen muchos tipos de modelos
de desarrollo, de forma genérica la mayoría está clasificada en una de estas 3
categorías, y estos a pesar de ser diferentes a veces son usados de manera
simultáneamente especialmente en sistemas grandes.
Desarrollo Evolutivo
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. Las fases de especificación, desarrollo y validación se
entrelazan en vez de separarse.
Existen dos tipos de desarrollo
evolutivo:
1.
Desarrollo
exploratorio,
donde el
objetivo del proceso es trabajar con el cliente para explorar sus
requerimientos y entregar un sistema final. El desarrollo empieza con las
partes del sistema que se comprenden mejor. El sistema evoluciona agregando
nuevos atributos propuestos por el cliente.
2. Prototipos
desechables
donde el
objetivo del proceso de desarrollo evolutivo es comprender los requerimientos
del cliente y entonces desarrollar una definición mejorada de los
requerimientos para el sistema. El prototipo se centra en experimentar con los
requerimientos del cliente que no se comprenden del todo.
Desde el punto de vista de desarrollo de
sistema el enfoque evolutivo suele traer más ventajas en comparación con un
enfoque en cascada ya que el sistema se va ajustando a las necesidades del
cliente, a la vez que él mismo entiende mejor sus propios requerimientos. Sin
embargo el enfoque evolutivo desde una perspectiva de ingeniería y gestión
suele tener dos grandes problemas:
1. El proceso no
es visible.
Los
administradores tienen que hacer entregas regulares para medir el progreso. Si
los sistemas se desarrollan rápidamente, no es rentable producir documentos que
reflejen cada versión del sistema.
2. A menudo los sistemas tienen una
estructura deficiente.
Los cambios
continuos tienden a corromper la estructura del software. Incorporar cambios en
él se convierte cada vez más en una tarea difícil y costosa.
Aunque supone grandes ventajas el
desarrollo evolutivo solo es recomendado para sistemas pequeños y medianos. En
los sistemas grandes, los constantes cambios en el desarrollo solo dificultan
la estabilidad y la integración de los avances de los distintos grupos de
trabajo que puedan existir. La mayoría de las empresas que desarrollan grandes
sistemas usan un modelo mixto que usa las mayores fortalezas de los enfoques
evolutivos y de cascada.
DESCRIPCIÓN DE AL MENOS 3 MODELOS DE TIPO ÁGIL
1. Crystal Clear
Crystal es una metodología de desarrollo de Software ágil, más que una metodología se la considera una familia de metodologías, debido a que se subdivide en varios tipos de metodologías en función a la cantidad de persona que vayan a estar en el proyecto. Es una metodología que ha sido creada por una persona en particular (Alistair Cockburn ) el cuál llegó la creó en base al análisis de distintos proyectos de desarrollo de SW y su propia experiencia, lo cual fusionando ambos aspectos dio lugar a una metodología bastante interesante, la cual se presenta a continuación.
Crystal Clear no es una metodología en sí misma sino una familia de metodologías con un “código genético” común.
El nombre Crystal deriva de la caracterización de los proyectos según 2 dimensiones, tamaño y complejidad (como en los minerales, color y dureza).
Por ejemplo.
- Clear es para equipos de hasta 8 personas o menos.
- Amarillo para equipos entre 10 a 20 personas.
- Naranja para equipos entre 20 a 50 persona.
- Roja para equipos entre 50 a 100 personas.
- Azul para equipos entre 100 a 200 personas.
CC puede ser usado en proyectos pequeños y como casi todos los otros métodos, CC consiste en valores, técnicas y procesos.
En primera instancia se especifican los antecedentes de la metodología, continuando con definiciones que ayudan a estructurar la fundamentación teórica y se termina con las características esenciales de los diferentes tipos de Crystal.
2. Metodología FDD
Metodología FDD (Feature Driven Development). Es una metodología ágil para el desarrollo de sistemas, basado en la calidad del software, que incluye un monitoreo constante del proyecto.
FDD fue desarrollado por Jeff De Luca y Peter Coad a mediados de los años 90. Esta metodología se enfoca en iteraciones cortas que permite entregas tangibles del producto en corto periodo de tiempo que como máximo son de dos semanas.
Contenido:
1 Características
2 Procesos
3 Roles y responabilidades
4 Comparación
5 Fuentes
Características
No hace énfasis en la obtención de los requerimientos sino en como se realizan las fases de diseño y construcción.
Se preocupa por la calidad, por lo que incluye un monitoreo constante del proyecto.
Ayuda a contrarrestar situaciones como el exceso en el presupuesto, fallas en el programa o el hecho de entregar menos de lo deseado.
Propone tener etapas de cierre cada dos semanas.
Se obtienen resultados periódicos y tangibles.
Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitoriar.
Define claramente entregas tangibles y formas de evaluación del progreso del proyecto.
Procesos
El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto.
Desarrollar un modelo global: Al inicio del desarrollo se construye un modelo teniendo en cuenta la visión, el contesto y los requisitos que debe tener el sistema a construir. Este modelo se divide en áreas que se analizan detalladamente. Se construye un diagrama de clases por cada área.
Construir una lista de los rasgos: Se elabora una lista que resuma las funcionalidades que debe tener el sistema, cuya lista es evaluada por el cliente. Cada funcionalidad de la lista se divide en funcionalidades más pequeñas para un mejor entendimiento del sistema.
Planear por rasgo: Se procede a ordenar los conjuntos de funcionalidades conforme a su prioridad y dependencia, y se asigna a los programadores jefes.
Diseñar por rasgo: Se selecciona un conjunto de funcionalidades de la lista. Se procede a diseñar y construir la funcionalidad mediante un proceso iterativo, decidiendo que funcionalidad se van a realizar en cada iteración. Este proceso iterativo incluye inspección de diseño, codificación, pruebas unitarias, integración e inspección de código.
3. METODOLOGÍA EXTREME PROGRAMMING (XP)
La programación extrema es una metodología de desarrollo ligero (o ágil) basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas.
Este modelo de programación se basa en una serie de metodologías de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay alrededor de la programación.
Una de las características principales de este método de programación, es que sus ingredientes son conocidos desde el principio de la informática. Los autores de XP han seleccionado aquellos que han considerado mejores y han profundizado en sus relaciones y en cómo se refuerzan los unos con los otros. El resultado de esta selección ha sido esta metodología única y compacta. Por esto, aunque no está basada en principios nuevos, sí que el resultado es una nueva manera de ver el desarrollo de software.
El objetivo que se perseguía en el momento de crear esta metodología era la búsqueda de un método que hiciera que los desarrollos fueran más sencillos. Aplicando el sentido común.
CARACTERÍSTICAS FUNDAMENTALES
Las características fundamentales del método son:
- Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
- Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres últimas inspiradas en JUnit, la cual, a su vez, se insipiró en SUnit, el primer framework orientado a realizar tests, realizado para el lenguaje de programación Smalltalk.
- Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
- Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
- Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
- Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
- Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
- Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.
ACTIVIDADES DE XP
- Codificar
Es necesario codificar y plasmar nuestras ideas a través del código. En programación, el código expresa la interpretación del problema, así podemos utilizar el código para comunicar, para hacer comunes las ideas, y por tanto para aprender y mejorar.
- Hacer pruebas
Las características del software que no pueden ser demostradas mediante pruebas simplemente no existen. Las pruebas dan la oportunidad de saber si lo implementado es lo que en realidad se tenía en mente. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema, entonces habremos acabado por completo.
- Escuchar
En una frase, "Los programadores no lo conocemos todo, y sobre todo muchas cosas que las personas de negocios piensan que son interesantes. Si ellos pudieran programarse su propio software ¿para qué nos querrían?".
Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita la información. Tenemos que escuchar a nuestros clientes cuáles son los problemas de su negocio, debemos de tener una escucha activa explicando lo que es fácil y difícil de obtener, y la realimentación entre ambos nos ayudan a todos a entender los problemas.
- Diseñar
El diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, lo apropiado es dividirla en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes.
Resumiendo las actividades de Xp: Tenemos que codificar porque sin código no hay programas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos que codificar ni probar, y tenemos que diseñar para poder codificar, probar y escuchar indefinidamente.
