ESPAM

jueves, 3 de julio de 2014

CARATULA



ESCUELA SUPERIOR POLITÉCNICA AGROPECUARIA DE MANABÍ MANUEL FÉLIX LÓPEZ

CARRERA INFORMÁTICA

SEMESTRE SÉPTIMO                 PERÍODO MAR./2014-AGO./2014

INGENIERA DE SOFTWARE

AUTORA:
PINARGOTE CARVAJAL RAQUEL KAROLINA


CATEDRÁTICO:
ING. HIRAIDA SANTANA.

MISIÓN
Formación de profesionales íntegros que conjuguen ciencia, tecnología y valores en su accionar, comprometidos con la sociedad en el manejo adecuado de programas y herramientas computacionales de última generación.

VISIÓN
Ser referente en la formación de profesionales de prestigio en el desarrollo de aplicaciones  informáticas y soluciones de hardware.

CALCETA, JULIO -2014.

SILABO






OBTENER SILABO EN DIGITAL:


INTRODUCCIÓN

INGENIERÍA DE SOFTWARE
La ingeniería de software es una disciplina formada por un conjunto de métodos, herramientas y técnicas que se utilizan en el desarrollo de los programas informáticos.
Esta disciplina trasciende la actividad de programación, que es el pilar fundamental a la hora de crear una aplicación. El ingeniero de software se encarga de toda la gestión del proyecto para que éste se pueda desarrollar en un plazo determinado y con el presupuesto previsto.
La ingeniería de software, por lo tanto, incluye el análisis previo de la situación, el diseño del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto funcionamiento y la implementación del sistema.
Cabe destacar que el proceso de desarrollo de software implica lo que se conoce como ciclo de vida del software, que está formado por cinco etapas: comunicación, planeación, modelado, construcción y despliegue.
La primera de todas las etapas del trabajo que realizan los ingenieros de software consiste en estudiar minuciosamente las características que se creen necesarias para el programa a desarrollar, y es éste el punto en el cual deben encontrar un equilibrio entre las demandas excesivas de los malos consumidores y las posibilidades de la compañía. El tiempo es dinero, y las empresas del mundo informático lo saben muy bien.
Cada función de un programa, cada rasgo que lo vuelva más cómodo, más inteligente, más accesible, se traduce en una cantidad determinada de tiempo, que a su vez acarrea los sueldos de todas las personas involucradas en su desarrollo. Pero además del costo de producción necesario para realizar cada una de las piezas de un programa, la ingeniería de software debe decidir cuáles de ellas tienen sentido, son coherentes con el resto y son necesarias para comunicar claramente la esencia y los objetivos de la aplicación.

TEMA 1. Metodologías de Desarrollo de Software

Lunes 30 de Julio de 2014.

INTRODUCCIÓN 

El desarrollo de software no es sin dudas una tarea fácil. Como resultado a este problema ha surgido una alternativa desde hace mucho: la Metodología. Las metodologías imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente. Lo hacen desarrollando un proceso detallado con un fuerte énfasis en planificar inspirado por otras disciplinas de la ingeniería.
Las metodologías ingenieriles han estado presentes durante mucho tiempo. No se han distinguido precisamente por ser muy exitosas. Aún menos por su popularidad. La crítica más frecuente a estas metodologías es que son burocráticas. Hay tanto que hacer para seguir la metodología que el ritmo entero del desarrollo se retarda.
Hoy en día existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Un ejemplo de ellas son las propuestas tradicionales centradas específicamente en el control del proceso. Estas han demostrado ser efectivas y necesarias en un gran número de proyectos, sobre todo aquellos proyectos de gran tamaño (respecto a tiempo y recursos).
Sin embargo la experiencia ha demostrado que las metodologías tradicionales no ofrecen una buena solución para proyectos donde el entorno es volátil y donde los requisitos no se conocen con exactitud, porque no están pensadas para trabajar con incertidumbre.
Aplicar metodologías tradicionales nos obliga a forzar a nuestro cliente a que tome la mayoría de las decisiones al principio. Luego el coste de cambio de una decisión tomada puede llegar a ser muy elevado si aplicamos metodologías tradicionales.
Es por ello que varios problemas como los que a continuación mencionamos han sido detectados:
  • Retrasos en la planificación: llegada la fecha de entregar el software éste no está disponible.
  • Sistemas deteriorados: el software se ha creado pero después de un par de años el coste de su mantenimiento es tan complicado que definitivamente se abandona su producción.
  • Tasa de defectos: el software se pone en producción pero los defectos son tantos que nadie lo usa.
  • Requisitos mal comprendidos: el software no resuelve los requisitos planificados inicialmente.
  • Cambios de negocio: el problema que resolvía nuestro software ha cambiado y nuestro software no se ha adaptado.
Falsa riqueza: el software hace muchas cosas técnicamente muy interesantes y divertidas, pero no resuelven el problema de nuestro cliente, ni hace que éste gane más dinero.
Cambios de personal: después de unos años de trabajo los programadores comienzan a odiar el proyecto y lo abandonan.
Como respuesta a los problemas aplicando metodologías tradicionales surgieron otras metodologías que tratan de adaptarse a la realidad del desarrollo de software.
El encanto de estas metodologías ágiles es su reacción ante la burocracia de las metodologías monumentales. Estos nuevos métodos buscan un justo medio entre ningún proceso y demasiado proceso, proporcionando simplemente suficiente proceso para que el esfuerzo valga la pena.
El resultado de todo esto es que los métodos ágiles cambian significativamente algunos de los énfasis de los métodos ingenieriles. La diferencia inmediata es que son menos orientados al documento, exigiendo una cantidad más pequeña de documentación para una tarea dada. De muchas maneras son más bien orientados al código: siguiendo un camino que dice que la parte importante de la documentación es el código fuente.

1.1 Ciclos de Vida del Software.

30 de junio del 2014.

Es el periodo de tiempo comprendido desde la definición de los requisitos hasta el fin del su uso, estos son procesos de actividades y tareas implicadas en el desarrollo operación y mantenimiento de un sistema de software. La aplicación de los procesos, tanto en el desarrollo como en el posterior mantenimiento y operación del software, se dibuja a través de unos “patrones fijos” que configuran el esquema de mapa de situación, relación y continuidad entre los diferentes procesos, actividades y tareas. En la etapa de desarrollo los patrones básicos son:
Desarrollo en cascada. (O variante secuencial)
Desarrollo en espiral. Una vez desarrollada la primera versión, el ciclo de vida del sistema discurre en cada momento según uno de los siguientes patrones.
Desarrollo incremental del sistema.
Desarrollo evolutivo del sistema. Sobre estos patrones básicos, en las diferentes etapas del ciclo de vida pueden intervenir como modificadores los siguientes factores:
Ø  Prototipo.
Ø  Concurrencia.

Componentes comerciales y reutilización. Generando la riqueza de modelos y sub-modelos de patrones que algunos textos clasifican de forma lineal y agrupada como “modelos de ciclos de vida”. 

FLUJO DEL PROCESO
MODELO CASCADA
MODELO EN V
MODELO INCREMENTAL
PROTOTIPO
ESPIRAL
MODELO DE PROCESO CONCURRENTE
PROCESO UNIFICADO

CONCLUSIÓN

La Ingeniería de software cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema. Esta disciplina establece el proceso de definición de requisitos como una sucesión de actividades mediante la cual se modela y analiza. En este proceso se deben conciliar diferentes puntos de vista y utilizar una combinación de métodos, personas y herramientas. El resultado final constituye la documentación de los requisitos. Éstos deben expresarse de forma clara y estructurada de manera que puedan ser entendidos tanto por expertos como por el usuario, quien deberá participar en la validación.




1.2 Metodologías Tradicionales.

Lunes 30 de Julio de 2014.

1.2 Metodologías Tradicionales.

Teniendo en cuenta la filosofía de desarrollo de las metodologías, aquellas con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales o Pesadas. 
Estas metodologías tradicionales 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.

Conclusiones

El desarrollo de las metodologías, es aquellas con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales o Pesadas.

Estas metodologías tradicionales 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.

1.3 Metodologías Agiles.

Lunes 30 de junio 2014

Un modelo de desarrollo ágil, generalmente es un proceso Incremental, (pequeños y frecuentes releases o entregas con ciclos rápidos), también Cooperativo (Clientes y desarrolladores trabajan constantemente con una comunicación muy fina y constante), sencillo (El método es fácil de aprender y modificar para el equipo, es bien documentado por medio de libros o la Web) y finalmente adaptativo (capaz de permitir cambios de último momento).
Cualquier proceso del software ágil se caracteriza por la forma en la que aborda cierto número de suposiciones acerca de la mayoría de proyectos de software:

  • Es difícil predecir qué requerimientos de software persistirán y cuáles cambiarán. También es difícil pronosticar cómo cambiarán las prioridades del cliente a medida que avanza el proyecto.
  • Para muchos tipos de software, el diseño y la construcción están imbricados. Es decir, ambas actividades deben ejecutarse en forma simultánea, de modo que los modelos de diseño se prueben a medida que se crean. Es difícil predecir cuánto diseño se necesita antes de que se use la construcción para probar el diseño.
  • El análisis, el diseño, la construcción y las pruebas no son tan predecibles como nos gustaría (desde un punto de vista de planeación).

Dadas estas tres suposiciones, surge una pregunta importante: ¿cómo crear un proceso que pueda manejar lo impredecible? La respuesta, como ya se dijo, está en la adaptabilidad del proceso (al cambio rápido del proyecto y a las condiciones técnicas). Por tanto, un proceso ágil debe ser adaptable.
Pero la adaptación continua logra muy poco si no hay avance. Entonces, un proceso de software ágil debe adaptarse incrementalmente. Para lograr la adaptación incremental, un equipo ágil requiere retroalimentación con el cliente (de modo que sea posible hacer las adaptaciones apropiadas). Un catalizador eficaz para la retroalimentación con el cliente es un prototipo operativo o una porción de un sistema operativo. Así, debe instituirse una estrategia de desarrollo incremental. Deben entregarse incrementos de software (prototipos ejecutables o porciones de un sistema operativo) en periodos cortos de tiempo, de modo que la adaptación vaya a ritmo con el cambio (impredecible). Este enfoque iterativo permite que el cliente evalúe en forma regular el incremento de software, dé la retroalimentación necesaria al equipo de software e influya en las adaptaciones del proceso que se realicen para aprovechar la retroalimentación.

COMPARACIÓN DE MÉTODOS ÁGILES Y TRADICIONALES


PROGRAMACIÓN EXTREMA (XP)
A fin de ilustrar un proceso ágil con más detalle, daremos un panorama de la programación extrema (XP), el enfoque más utilizado del desarrollo de software ágil. Aunque las primeras actividades con las ideas y los métodos asociados a XP ocurrieron al final de la década de 1980, el trabajo fundamental sobre la materia había sido escrito por Kent Beck. Una variante de XP llamada XP industrial [IXP] se propuso en una época más reciente. IXP mejora la XP y tiene como objetivo el proceso ágil para ser usado específicamente en organizaciones grandes.
VALORES XP
Se define un conjunto de cinco valores que establecen el fundamento para todo trabajo realizado como parte de XP: comunicación, simplicidad, retroalimentación, valentía y respeto. Cada uno de estos valores se usa como un motor para actividades, acciones y tareas específicas de XP.
PROCESO DE XP

CONCLUSIÓN
La programación extrema puede aportar nuevas formas de buscar y optimizar el modelo de desarrollo de software libre.
Pruebas, metáfora y refactorización son prácticas que serian interesantes plasmar mas formalmente en el desarrollo libre ceñido a la aplicación de Xp.
Los resultados en distintos proyectos del paradigma demuestran que es un complemento valioso a los múltiples métodos de desarrollo de software en los últimos años.
Los enfoques de métodos de agilidad tienen la distinción de que los últimos operan de modo geográficamente distribuido y por ende se toma al cliente en los procesos Oss como un codesarrollador.


TEMA 2. Lenguaje Unificado de Modelado UML

Fecha: 15 de julio del 2014

INTRODUCCIÓN

En todas las disciplinas de la Ingeniería se hace evidente la importancia de los modelos ya que describen el aspecto y la conducta de "algo". Ese "algo" puede existir, estar en un estado de desarrollo o estar, todavía, en un estado de planeación. Es en este momento cuando los diseñadores del modelo deben investigar los requerimientos del producto terminado y dichos requerimientos pueden incluir áreas tales como funcionalidad, performance y confiabilidad. Además, a menudo, el modelo es dividido en un número de vistas, cada una de las cuales describe un aspecto específico del producto o sistema en construcción.
El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de pequeño tamaño se obtienen beneficios de modelado, sin embargo es un hecho que entre más grande y más complejo es el sistema, más importante es el papel de que juega el modelado por una simple razón: "El hombre hace modelos de sistemas complejos porque no puede entenderlos en su totalidad".
UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 1.0 de UML fue liberada en Enero de 1997 y ha sido utilizado con éxito en sistemas construidos para toda clase de industrias alrededor del mundo: hospitales, bancos, comunicaciones, aeronáutica, finanzas, etc.
En esta clase se trato de los distintos tipos de lenguajes para hacer modelados. 

LENGUAJE UNIFICADO DE MODELADO

La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo. Recordemos que un modelo es una representación simplificada de la realidad; el modelo UML describe lo que hará un sistema, pero no dice cómo implementar dicho sistema.

DIAGRAMAS DE CASO DE USO.

El diagrama de casos de usos representa gráficamente los casos de uso que tiene un sistema. Se define un caso de uso como cada interacción supuesta con el sistema a desarrollar, donde se representan los requisitos funcionales. Es decir, se está diciendo lo que tiene que hacer un sistema y cómo. 

DIAGRAMAS DE CLASES.

Los diagramas de clases describen la estructura estática de un sistema. Las cosas que existen y que nos rodean se agrupan naturalmente en categorías. Una clase es una categoría o grupo de cosas que tienen atributos (propiedades) y acciones similares. Un ejemplo puede ser la clase “Aviones” que tiene atributos como el “modelo de avión”, “la cantidad de motores”, “la velocidad de crucero” y “la capacidad de carga útil”. Entre las acciones de las cosas de esta clase se encuentran: “acelerar”, “elevarse”, “girar”, “descender”, “desacelerar”. Un rectángulo es el símbolo que representa a la clase, y se divide en tres áreas. Un diagrama de clases está formado por varios rectángulos de este tipo conectados por líneas que representan las asociaciones o maneras en que las clases se relacionan entre sí.

DIAGRAMA DE FLUJO DE DATOS

Los diagrma de flujos son una manera de representar visualmente el flujo de datos a través de sistemas de tratamiento de información. Los diagramas de flujo describen que operaciones y en que secuencia se requieren para solucionar un problema dado.
Un diagrama de flujo u organigrama es una representación diagramática que ilustra la secuencia de las operaciones que se realizarán para conseguir la solución de un problema. Los diagramas de flujo se dibujan generalmente antes de comenzar a programar el código frente a la computadora. Los diagramas de flujo facilitan la comunicación entre los programadores y la gente del negocio. Estos diagramas de flujo desempeñan un papel vital en la programación de un problema y facilitan la comprensión de problemas complicados y sobre todo muy largos. Una vez que se dibuja el diagrma de flujo, llega a ser fácil escribir el programa en cualquier idioma de alto nivel. Vemos a menudo cómo los diagramas de flujo nos dan ventaja al momento de explicar el programa a otros. Por lo tanto, está correcto decir que un diagrama de flujo es una necesidad para la documentación mejor de un programa complejo.

Diagrama de Contexto: Nivel 0
En el diagrama de contexto se caracterizan todas las interacciones que 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"

Diagrama de Nivel Superior: Nivel 1
En el diagrama de nivel superior se plasman todos los procesos que describen 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 contemplar que 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 que en 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 de nivel superior.

CON RESPECTO AL PROYECTO DE AÑO HEMOS REALIZADO EL DFD:





TEMA
APLICACIÓN WEB DE COTIZACIÓN Y COMPRAS VÍA ONLINE EN EL ASERRÍO Y FERRETERÍA “LA KAROLINA” DE LA CIUDAD DE CALCETA DEL CANTÓN BOLIVAR.
De acuerdo con nuestro tema de proyecto, procedimos a realizar el diagrama de flujo en nivel 0 y en nivel 1.

CONCLUSIONES

Un UML sirve para que cualquier persona entienda el modelo en cuestión de forma rápida. Este resuelve de forma bastante satisfactoria un viejo problema del desarrollo de software como es su modelado gráfico.
El Nivel 0 o Diagrama de Contexto es aquel que muestra una sola burbuja y las entidades externas o terminadores con los que interactúa el sistema.
En el diagrama de nivel superior se plasman todos los procesos quedescriben al proceso principal.
Es una representación estructurada y gráfica que describe cómo circula la información a través de un sistema y los diferentes procesos de transformación a los que se ve sometida.

2.1 Diagramas de Comportamiento: casos de uso, actividad, interacción, estado, secuencia, comunicación, tiempo.

2.2 Diagramas de Estructura: clases, estructuras compuestas, componentes, despliegue, objeto, paquetes.

TEMA 3. Gestión de Proyectos de Software


3.1 Gestión de Requerimientos, Presupuesto y Tiempo.

3.2 Gestión de Riesgo.

3.3 Gestión de Calidad.

3.4 Gestión de Cambio.

CONCLUSIONES

La práctica de la ingeniería de software incluye principios, conceptos, métodos y herramientas que los ingenieros de software aplican en todo el proceso de desarrollo. Todo proyecto de ingeniería de software es diferente. No obstante, existe un conjunto de principios generales que se aplican al proceso como un todo y a cada actividad estructural, sin importar cuál sea el proyecto o el producto.
Existe un conjunto de principios fundamentales que ayudan en la aplicación de un proceso de software significativo y en la ejecución de métodos de ingeniería de software eficaz. En el nivel del proceso, los principios fundamentales establecen un fundamento filosófico que guía al equipo de software cuando avanza por el proceso del software. En el nivel de la práctica, los principios fundamentales establecen un conjunto de valores y reglas que sirven como guía al analizar el diseño de un problema y su solución, al implementar ésta y al someterla a prueba para, finalmente, desplegar el software en la comunidad del usuario.
Los principios de comunicación se centran en la necesidad de reducir el ruido y mejorar el ancho de banda durante la conversación entre el desarrollador y el cliente. Ambas partes deben colaborar a fin de lograr la mejor comunicación.
Los principios de planeación establecen lineamientos para elaborar el mejor mapa del proceso hacia un sistema o producto terminado. El plan puede diseñarse sólo para un incremento 8 Durante la actividad de comunicación, el equipo de software debe determinar los tipos de materiales de ayuda que quiere el usuario.
El modelado incluye tanto el análisis como el diseño, y describe representaciones cada vez más detalladas del software. El objetivo de los modelos es afirmar el entendimiento del trabajo que se va a hacer y dar una guía técnica a quienes implementarán el software. Los principios de modelado dan fundamento a los métodos y notación que se utilizan para crear representaciones del software.
La construcción incorpora un ciclo de codificación y pruebas en el que se genera código fuente para cierto componente y es sometido a pruebas. Los principios de codificación definen las acciones generales que deben tener lugar antes de que se escriba el código, mientras se escribe y una vez terminado. Aunque hay muchos principios para las pruebas, sólo uno predomina: la prueba es el proceso que lleva a ejecutar un programa con objeto de encontrar un error. El despliegue ocurre cuando se presenta al cliente un incremento de software, e incluye la entrega, apoyo y retroalimentación. Los principios clave para la entrega consideran la administración de las expectativas del cliente y darle información de apoyo adecuada sobre el software.
El apoyo demanda preparación anticipada. La retroalimentación permite al cliente sugerir cambios que tengan valor para el negocio y que brinden al desarrollador información para el ciclo iterativo siguiente de ingeniería de software.

BIBLIOGRAFIA