jueves, 9 de octubre de 2008

Unidad 3

Unidad 3 Paradigmas de la ingenieria de software

Ingeniería de software es la disciplina o área de la informática que ofrece métodos y técnicas para desarrollar y mantener software de calidad.
Esta ingeniería trata con áreas muy diversas de la informática y de las Ciencias de la Computación, tales como construcción de compiladores, Sistemas Operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de Sistema de Información y aplicables a infinidad de áreas (negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología, derecho, Internet Intranet, etc.).

Una definición precisa aun no ha sido contemplada en los diccionarios, sin embargo se pueden citar las enunciadas por algunos de los más prestigiosos autores:

1 – ES el estudio de todos los sistemas de software (Zelkovitz, 1978)
2 – Es el desarrollo del conocimiento científico para aplicarlo en la producción de cualquier sistema. ( Bohem, 1976).
3 - Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería aplicables a autómatas y máquinas (Bauer, 1972).
4 - Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).

La ingeniería de software tiene varios modelos o paradigmas de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más utilizados y los más completos:
Modelo en cascada o Clásico (modelo tradicional)
Modelo en espiral (modelo evolutivo)
Modelo de prototipos
Desarrollo por etapas
Desarrollo iterativo y creciente o Interativo Incremental
RAD (Redundant Application Development)

En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.
Un ejemplo de una metodología de desarrollo en cascada es:
Diseño del Sistema
Análisis de requisitos
Mantenimiento
Implantación Diseño del Programa
Codificación
Pruebas
Diseño del Programa

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al la fase de pruebas, logrando así una mejor calidad en el software.
Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.
Fases del modelo.

Análisis de requisitos
Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras..

Diseño del Sistema
Se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.

Es importante señalar que en esta etapa se deben consensuar todo lo que se requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software.

Diseño del Programa
Es la fase de programación o implementación propiamente dicha. Aquí se implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores.
Dependiendo del lenguaje de programación y su versión se crean las librerías y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

Codificación
Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.

Pruebas
El software obtenido se pone en producción. Se implantan los niveles software y hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto. Es una de las fases finales del proyecto
Durante la explotación del sistema software pueden surgir cambios, bien para corregir errores o bien para introducir mejoras. Todo ello se recoge en los Documentos de Cambios.
Implantación

Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotación.
Variantes

Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final este libre de fallos.
Desventajas

En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso.
Difícilmente un cliente va a establecer al principio todos los requerimientos necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases.

Los resultados y/o mejoras no son visibles, el producto se ve recién cuando este esté finalizado, lo cual provoca una gran inseguridad por parte del cliente que anda ansioso de ver avances en el producto. Esto también implica toparse con requerimientos que no se habian tomado en cuenta, y que surgieron al momento de la implementación, lo cual provocara que se regrese nuevamente a la fase de requerimientos.

Ventajas
Se tiene todo bien organizado y no se mezclan las fases.
Es perfecto para proyectos que son rígidos, y además donde se especifiquen muy bien los requerimientos y se conozca muy bien la herramienta a utilizar

Desarrollo en espiral

El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, cada bucle epresenta un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior
Determinar o fijar objetivos
Fijar también los productos definidos a obtener: requerimientos, especificación, manual de usuario.
Fijar las restricciones.
Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
Hay una cosa que solo se hace una vez: planificación inicial o previa.
Análisis del riesgo
Tareas de la actividad propia y de prueba.
Análisis de alternativas e identificación resolución de riesgos.

Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado.

Desarrollar, verificar y validar (probar)
Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos.


Planificar
Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.

Modelo de prototipos
En Ingeniería de software el desarrollo con prototipación, también llamado modelo de prototipos que pertenece a los modelos de desarrollo evolutivo, se inicia haciendo un prototipo muy avanzado del sistema y este se va refinando en iteraciones con el cliente.
El diseño rápido se centra en una representación de los requerimientos y especificaciones más completos y detallados, aquellos representan la funcionalidad más compleja y específica del software.

Ventajas
Es útil cuando se nesecita terminar el desarrollo de manera efectiva y con un alto nivel de calidad.
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.

La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto.

Inconvenientes
El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.

En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.
Desarrollo por etapas

El modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultáneamente con las diferentes versiones del código.
Pueden distinguirse las siguientes fases:
Especificación conceptual
Análisis de requerimientos
Diseño inicial
Diseño detallado, codificación, depuración y liberación
Estas diferentes fases se van repitiendo en cada etapa del diseño

Desarrollo iterativo y creciente
Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada.
Para apoyar el desarrollo de proyectos por medio de este modelo se han creado frameworks (entornos de trabajo), de los cuales los dos más famosos son el Rational Unified Process y el Dynamic Systems Development Method. El desarrollo incremental e iterativo es también una parte esencial de un tipo de programación conocido como Extreme Programming y los demás frameworks de desarrollo rápido de software.
Ciclo de vida

La idea principal detrás de mejoramiento iterativo es desarrollar un sistema de programas de manera incremental, permitiéndole al desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo anterior, incrementando, versiones entregables del sistema. El aprendizaje viene de dos vertientes: el desarrollo del sistema, y su uso (mientras sea posible). Los pasos claves en el proceso eran comenzar con una implementación simple de los requerimientos del sistema, e iterativamente mejorar la secuencia evolutiva de versiones hasta que el sistema completo esté implementado. En cada iteración, se realizan cambios en el diseño y se agregan nuevas funcionalidades y capacidades al sistema.
El proceso en sí mismo consiste de:
Etapa de inicialización
Etapa de iteración
Lista de control de proyecto
Etapa de inicialización

Se crea una versión del sistema. La meta de esta etapa es crear un producto con el que el usuario pueda interactuar, y por ende retroalimentar el proceso. Debe ofrecer una muestra de los aspectos claves del problema y proveer una solución lo suficientemente simple para ser comprendida e implementada fácilmente. Para guiar el proceso de iteración, una lista de control de proyecto se crea, y esta lista contiene un historial de todas las tareas que necesitan ser realizadas. Incluye cosas como nuevas funcionalidades para ser implementadas, y areas de rediseño de la solución ya existente. Esta lista de control se revisa periódica y constantemente como resultado de la fase de análisis.
Etapa de iteración

Esta etapa involucra el rediseño e implementación de una tarea de la lista de control de proyecto, y el análisis de la versión más reciente del sistema. La meta del diseño e implementación de cualquier iteración es ser simple, directa y modular, para poder soportar el rediseño de la etapa o como una tarea añadida a la lista de control de proyecto. El código puede, en ciertos casos, representar la mayor fuente de documentación del sistema. El análisis de una iteración se basa en la retroalimentación del usuario y en el análisis de las funcionalidades disponibles del programa. Involucra el análisis de la estructura, modularidad, usabilidad, confiabilidad, eficiencia y eficacia (alcanzar las metas). La lista de control del proyecto se modifica bajo la luz de los resultados del análisis.

Las guías primarias que guían la implementación y el análisis incluyen:
Cualquier dificultad en el diseño, codificación y prueba de una modificación debería apuntar a la necesidad de rediseñar o recodificar.

Las modificaciones deben ajustarse fácilmente a los módulos fáciles de encontrar y a los aislados. Si no es así, entonces se requiere algún grado de rediseño.

Las modificaciones a las tablas deben ser especialmente fáciles de realizar. Si dicha modificación no ocurre rápidamente, se debe aplicar algo de rediseño.

Las modificaciones deben ser más fáciles de hacer conforme avanzan las iteraciones. Si no es así, hay un problema primordial usualmente encontrado en un diseño débil o en la proliferación excesiva de parches al sistema.

Los parches normalmente deben permanecer solo por una o dos iteraciones. Se hacen necesarios para evitar el rediseño durante una fase de implementación.
La implementación existente debe ser analizada frecuentemente para determinar que tan bien se ajusta a las metas del proyecto.

Las facilidades para analizar el programa deben ser utilizadas cada vez para ayudar en el análisis de implementaciones parciales.
La opinión del usuario debe ser solicitada y analizada para indicar deficiencias en la implementación referida por él.
Caso práctico

La mejora iterativa fue exitosamente aplicada al desarrollo de una familia extensa de compiladores para una familia de lenguajes de programación en una gama de arquitecturas de hardware. Un conjunto de 17 versiones del sistema se desarrollaron en un lugar, generando 17 mil líneas de código fuente de lenguaje de alto nivel (6500 de código ejecutable). El sistema posteriormente fue desarrollado en dos sitios diferentes, llegando a dos versiones diferentes del lenguaje base: una versión esencialmente se enfocaba en aplicaciones matemáticas, añadiendo números reales y varias funciones matemáticas, y la otra se centró en añadir capacidades para escribir del compilador.
Cada iteración fue analizada del punto de vista de los usuarios (las capacidades del lenguaje fueron determinadas en parte por las necesidades del usuario) y el punto de vista del desarrollador (el diseño del compilador evolucionó para ser más fácilmente modificable, por ejemplo, para añadir nuevos tipos de datos). Mediciones tales como acoplamiento y modularización fueron seguidas sobre múltiples versiones.
Características

Usando análisis y mediciones como guías para el proceso de mejora es una diferencia mayor entre las mejoras iterativas y el desarrollo rápido de aplicaciones, principalmente por dos razones:
Proveé de soporte para determinar la efectividad de los procesos y de la calidad del producto.
Permite estudiar y después mejorar y ajustar el proceso para el ambiente en particular.
Estas mediciones y actividades de análisis pueden ser añadidas a los métodos de desarrollo rápido existentes.

De hecho, el contexto de iteraciones múltiples conlleva ventajas en el uso de mediciones. Las medidas a veces son difíciles de comprender en lo absoluto, aunque en los cambios relativos en las medidas a través de la evolución del sistema puede ser muy informativo porque proveén una base de comparación. Por ejemplo, un vector de medidas m1, m2,..., mn puede ser definido para caracterizar varios aspectos del producto en cierto punto, como pueden ser el esfuerzo total realizado, los cambios, los defectos, los atributos lógico, físico y dinámico, consideraciones del entorno, etcétera. Así el observador puede decir como las carácterísticas del producto como el tamaño, la complejidad, el acoplamiento y la cohesión incrementan o disminuyen en el tiempo.
También pude monitorearse el cambio relativo de varios aspectos de un producto o pueden proveer los límites de las medidas para apuntar a problemas potenciales y anomalías.
Debilidades de este modelo de desarrollo
Debido a la interacción con los usuarios finales, cuando sea necesaria la retroalimentación hacia el grupo de desarrollo, utilizar este modelo de desarrollo puede llevar a avances ser extremadamente lento.

Por la misma razón no es una aplicación ideal para desarrollos en los que de antemano se sabe que serán grandes en el consumo de recursos y largos en el tiempo.
Al requerir constantemente la ayuda de los usuario finales, se agrega un costo extra a la compañía, pues mientras estos usuarios evalúan el software dejan de ser directamente productivos para la compañía.

Desarrollo rápido de aplicaciones
Redundant application development (RAD), es un proceso de desarrollo de software, en inglés: software development process, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo y redundante, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.
Ventajas y desventajas
El desarrollo rápido tiene dos ventajas primarias:
Debido a la alta redundancia en este modelo, la velocidad y la prototipación del proyecto se ven incrementados.

Calidad: la calidad del proyecto se ve incrementada debido al alto desempeño que conlleva el incluir al cliente en el desarrollo.
El RAD tiene dos desventajas primarias:
Características reducidas.
Escalabilidad reducida: debido a que el RAD se desarrolló como prototipo.
Herramientas RAD Multiplataforma
NetBeans Herramienta Open Source
Eclipse Herramienta Open Source
WaveMaker WaveMaker Herramienta Open Source para aplicaciones Web2.0
Revolution Studio Es una avanzada herramienta cross-platform RAD que deriva ejecutables sobre Windows, Linux, Solaris, MacOS X Universal Binary and MacOS Classic.
Lazarus Es un IDE cross-platform similar a Borland Delphi.
Real Basic Es un IDE cross-platform similar a Visual Basic.
Leonardi Es una herramienta avanzada cross-platform RAD que deriva ejecutables sobre Windows, Linux, MacOs.
Microsoft Visual Studio 2005 / 2008
ycube RAD Plus Herramienta Open Source para aplicaciones comerciales multiplataforma (Windows, Linux, Unix, MAC OSX).

12 comentarios:

Anónimo dijo...

El errror que encontre fue en la parte donde hablan del desarrollo en cascada la informacion correcta es esta:

Fases del modelo.
Análisis de requisitos Se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.
Es importante señalar que en esta etapa se deben consensuar todo lo que se requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software.

Diseño del Sistema Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras..

Diseño del Programa Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.

Codificación Es la fase de programación o implementación propiamente dicha. Aquí se implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores.
Dependiendo del lenguaje de programación y su versión se crean las librerías y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

Pruebas Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotación.

Implantación El software obtenido se pone en producción. Se implantan los niveles software y hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto. Es una de las fases finales del proyecto
Durante la explotación del sistema software pueden surgir cambios, bien para corregir errores o bien para introducir mejoras. Todo ello se recoge en los Documentos de Cambios.

Anónimo dijo...

El errror que encontre fue en la parte donde hablan del desarrollo en cascada la informacion correcta es esta:

Fases del modelo.
Análisis de requisitos Se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.
Es importante señalar que en esta etapa se deben consensuar todo lo que se requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software.

Diseño del Sistema Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras..

Diseño del Programa Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.

Codificación Es la fase de programación o implementación propiamente dicha. Aquí se implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores.
Dependiendo del lenguaje de programación y su versión se crean las librerías y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

Pruebas Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente antes de ser puesto en explotación.

Implantación El software obtenido se pone en producción. Se implantan los niveles software y hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto. Es una de las fases finales del proyecto
Durante la explotación del sistema software pueden surgir cambios, bien para corregir errores o bien para introducir mejoras. Todo ello se recoge en los Documentos de Cambios.

Rafael Vargas Balderas 06480231

Anónimo dijo...

Bueno yo queria implementar a la informacion algo importante que no mencionaron en el teme y a mi pubnto de vista yo lo veria como un grave error no ponerlo: como lo es decir que:

El ciclo de Vida. El ciclo de vida es el paradigma mas antiguo y mas ampliamente usado en la ingenieria de software

Y aqui podemos ver otros puntos importantes como lo son:
*Construccion de prototipos. La construccion de prototipos es un proceso que facilita al programador la creacion de un modelo del software a construir.

* El modelo tomara una de las tre formas siguientes:

*Un prototipo en papel o un modelo basado en PC que describa la interaccion hombre-maquina
Un prototipo que implemente algunos subconjuntosde la funcion requerida del programa deseado.

*Un programa existente que ejecute parte o toda la funcion deseada.


*El modelo en espiral. Ha sido desarrollado para cubrir las mejores caracteristicas tanto del ciclo de vida como de la creacion de prototipos, añadiendo al mismo tiempo un nuevo elemento: el analisis de riesgo.

*Tecnicas de cuarta generacion. Abarca un amplio espectro de herramientas de software que tienen algo en comun: todas facilitan al que desarrolla el software.


*Combinacion de paradigmas. En muchos casos, los paradigmas pueden y deben combinarse de forma que puedan utilizarse las ventajas de cada uno en un unico proyecto.



nombre: Juan Antonio Moreno Gonzalez

numero de Control: 06050233

JOAQUIN HERNANDEZ SANTOS dijo...

ALUMNO: JOAQUIN HERNANDEZ SANTOS
NUM. CONTROL: 06480430

Bueno desde mi punto de vista este blog no esta muy bien centrado que digamos en los temas que deberia de hablar, porque hay algunas partes de ste que hablan de otras cosas que no son nada interesantes para la unidad, como es el caso donde nos dice lo siguiente:

Revolution Studio Es una avanzada herramienta cross-platform RAD que deriva ejecutables sobre Windows, Linux, Solaris, MacOS X Universal Binary and MacOS Classic.
Lazarus Es un IDE cross-platform similar a Borland Delphi.
Real Basic Es un IDE cross-platform similar a Visual Basic.
Leonardi Es una herramienta avanzada cross-platform RAD que deriva ejecutables sobre Windows, Linux, MacOs.
Microsoft Visual Studio 2005 / 2008
ycube RAD Plus Herramienta Open Source para aplicaciones comerciales multiplataforma (Windows, Linux, Unix, MAC OSX).

Una definición precisa aun no ha sido contemplada en los diccionarios, sin embargo se pueden citar las enunciadas por algunos de los más prestigiosos autores:

1 – ES el estudio de todos los sistemas de software (Zelkovitz, 1978)
2 – Es el desarrollo del conocimiento científico para aplicarlo en la producción de cualquier sistema. ( Bohem, 1976).
3 - Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería aplicables a autómatas y máquinas (Bauer, 1972).
4 - Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).

Desarrollo rápido de aplicaciones
Redundant application development (RAD), es un proceso de desarrollo de software, en inglés: software development process, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo y redundante, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.

Anónimo dijo...

al principio donde mencionas que el termino aun no tiene una definicion precisa en los diccionarios se pueden citar las enunciadas por algunos de los mas prestigiados autores te falto poner los puntos completos

* 1 - Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)

* 2 - Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software ( Bohem, 1976).

* 3 - Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).

* 4 - Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).

Francisco Ricardo Reyna Cortez
N° de control 06480039

Jorge A. Garcia dijo...

Tiene error en el texto donde dice
Una definición precisa aun no ha sido contemplada en los diccionarios, sin embargo se pueden citar las enunciadas por algunos de los más prestigiosos autores:

* 1 - Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)
* 2 - Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software ( Bohem, 1976).
* 3 - Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).
* 4 - Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).
Jorge A. Garcia Mtz. 05480010

fundamentos de desarrillo de sistemas dijo...

jose juan
06480206


encontre informacion sobre diagramas de flujos
que les puede servir

El diagrama de flujo de datos es un modelo que describe los flujos de datos o tuberías, los procesos que cambian o transforman los datos en un sistema, las entidades externas que son fuente o destino de los datos (y en consecuencia los límites del sistema) y los almacenamientos o depósitos de datos a los cuales tiene acceso el sistema, permitiendo así describir el movimiento de los datos a través del sistema.

este es el link de donde baje la informacion

http://html.rincondelvago.com/dfd.html

Anónimo dijo...

Pues aqui esta un complemento del desarrollo practico de aplicaciones en las plataformas donde se utiliza

Herramientas RAD Multiplataforma NetBeans Herramienta Open Source
Eclipse Herramienta Open Source
WaveMaker WaveMaker Herramienta Open Source para aplicaciones Web2.0
Revolution Studio Es una avanzada herramienta cross-platform RAD que deriva ejecutables sobre Windows, Linux, Solaris, MacOS X Universal Binary and MacOS Classic.
Lazarus Es un IDE cross-platform similar a Borland Delphi.
Real Basic Es un IDE cross-platform similar a Visual Basic.
Leonardi Es una herramienta avanzada cross-platform RAD que deriva ejecutables sobre Windows, Linux, MacOs.
Microsoft Visual Studio 2005 / 2008
ycube RAD Plus Herramienta Open Source para aplicaciones comerciales multiplataforma (Windows, Linux, Unix, MAC OSX).

Herramientas RAD para Escritorio AppBuilder 1 2 3
Automated Architecure's Blue Ink
Borland C++Builder
Borland Delphi
Gambas
WinDev
Visual Basic
Ultimate++
NConstruct - .NET RAD herramienta para Winforms & Web

Herramientas RAD para Bases de Datos Clarion Es una herramienta (ARAD) Advanced Rapid Application
FileMaker Pro Advanced
Omnis Studio
Oracle Forms
Oracle Application Express o APEX
Sybase PowerBuilder
WinDev
Servoy
NConstruct - .NET RAD herramienta para Winforms & Web
Microsoft Access
c++ builder
oracle 2000
power builder

Herramientas RAD Orientadas a la WEB WaveMaker WaveMaker Herramienta Open Source para aplicaciones Web2.0
Django WebFramework para el desarrollo de aplicaciones web sobre Python.
37 Signals Ruby on Rails
Adobe ColdFusion
Symfony (PHP)
iRise 1
WebDev
Velneo
Leonardi
Microsoft Visual Studio 2005
ycube RAD Plus Herramienta Open Source para aplicaciones comerciales.
NConstruct - .NET RAD herramienta para Winforms & Web



Nombre: Juan Antonio Moreno Gonzalez
numero de control :06050233

Anónimo dijo...

PEDRO BALLEZA ARRIETA
NUM CTRL:05480382

PARA MI FALTO ESTA INFORMACION QUE VIENE DENTRO DEL TEMARIO Y QUE ES DE IMPORTANCIA PUES OCUPA 3 PUNTOS LA PROGRAMACION ORIENTADA A OBJETOS

La Programación Orientada a Objetos

como paradigma, "es una forma de pensar, una filosofía, de la cual surge una cultura nueva que incorpora técnicas y metodologías diferentes. Pero estas técnicas y metodologías, y la cultura misma, provienen del paradigma, no lo hacen. La OOP como paradigma es una postura ontológica: el universo computacional está poblado por objetos, cada uno responsabilizándose por sí mismo, y comunicándose con los demás por medio de mensajes"

La Programación Orientada a Objetos desde el punto de vista computacional "es un método de implementación en el cuál los programas son organizados como grupos cooperativos de objetos, cada uno de los cuales representa una instancia de alguna clase, y estas clases, todas son miembros de una jerarquía de clases unidas vía relaciones de herencia"

En el enfoque OO las propiedades del objeto son claves. Los principios del modelo OO son: abstracción, encapsulación, modularidad y jerarquía, fundamentalmente, y en menor grado tipificación (typing), concurrencia, persistencia. [Booch 1986] dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO.
• Abstracción. Es una descripción simplificada o especificación de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros.
• Encapsulación. En el proceso de ocultar todos los detalles de un objetoque no contribuyen a sus características esenciales.
• Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes.
• Jerarquía o herencia. Es el orden de las abstracciones organizado por niveles.
• Tipificación. Es la definición precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida.
• Concurrencia . Es la propiedad que distingue un objeto que está activo de uno que no lo está.
• Persistencia. Es la propiedad de un objeto a través de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado).

Anónimo dijo...

EDUARDO MARQUEZ ESPINOSA
<05480547>
AL PARECER NO HABLAN DEL DIAGRAMA DE FLUJO DE DATOS;ESPERO QUE ESTO IMPLEMENTE MAS LA INFORMACION DE LA UNIDAD.

Definición:

El diagrama de flujo de datos es un modelo que describe los flujos de datos o tuberías, los procesos que cambian o transforman los datos en un sistema, las entidades externas que son fuente o destino de los datos (y en consecuencia los límites del sistema) y los almacenamientos o depósitos de datos a los cuales tiene acceso el sistema, permitiendo así describir el movimiento de los datos a través del sistema.

En síntesis, el Diagrama de Flujo de Datos describe:

ð los lugares de origen y destino de los datos (los límites del sistema),

ð las transformaciones a las que son sometidos los datos (los procesos internos),

ð los lugares en los que se almacenan los datos dentro del sistema, y

ð los canales por donde circulan los datos.

Características:

ð Relevante: Ya que posibilitar comunicar diferentes modelos para así facilitar el entendimiento entre el usuario y el analista de sistemas.

ð Lógico: Ya que no identifica soporte físico.

ð Descendente: Se construye en forma descendente, de lo general a lo particular.



El DFD posee niveles de desagregación o explosión o apertura de burbujas. 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.

Simbología:

Entidad Externa:

Son generalmente clases lógicas de cosas o de personas, las cuales representan una fuente o destino de transacciones, como por ejemplo clientes, empleados, proveedores, etc., con las que el sistema se comunica. También pueden ser una fuente o destino específico, como por ejemplo Departamento Contable.

Como el sistema que esta bajo análisis acepta datos de otro sistema o bien se los provee, este otro sistema es una Entidad Externa.

Mediante la designación de alguna cosa o de algún sistema como Entidad Externa estamos estableciendo implícitamente que se encuentra fuera de los límites del sistema que estamos considerando por lo cual no nos interesa la transformación o proceso que se realiza dentro de ellos, es decir que están fuera del control del sistema que se está modelando. Son sólo proveedores o requeridores de datos del sistema bajo consideración.

Por todo ello, ni el analista ni el diseñador pueden cambiar ni los contenidos ni la forma de trabajo de un terminador.

Proceso:

Indican aquellos lugares dentro del sistema en donde la información (flujos de datos) que ingresan se procesan o transforman. Es decir, son las funciones o procesos que transforman entradas de datos en salidas de información.

Su nombre deberá ponerse mediante una frase imperativa, que consistirá idealmente de un verbo activo seguido por una claúsula objeto, cuanto mas simple mejor. Al analista le servirá pensar que la descripción de la función es "una orden a un empleado sin conocimiento del tema". Estas frases imperativas no tienen sujeto; tan pronto como se introduce un sujeto se habrá indicado como deberá realizarse físicamente la función ("El operador ingresará los datos del alumno").

Un proceso puede ser físicamente una oficina repleta de empleados, un procedimiento, o una combinación de actividades manuales y automatizadas.

Flujo de datos:

Representa un transporte de paquetes de datos desde su origen hasta su destino, es decir que representa una estructura de datos en movimiento de una parte del sistema a otro.

Un flujo muestra las interfaces entre los elementos del DFD.

Puede imaginarse como una tubería por donde se envían paquetes de datos, pero deberá tener una descripción de su contenido la cual deberá elegirse de forma que sea lo más útil posible a los usuarios que revisen el DFD.

La flecha indica la dirección del flujo.

Puede estar contenido físicamente en una nota, una factura, una llamada telefónica, de programa a programa, etc. Es decir, en cualquier medio por el cual los datos pasan de una entidad o proceso a otra.

Almacén o archivo:

Representa un archivo lógico en donde se agregan o de donde se extraen datos. Es una estructura de datos, pero estática.

Puede ser físicamente un archivo de tarjetas, una microficha, un archivo, o un archivo en cinta o diskette.

Deberá elegirse el nombre que sea más descriptivo para el usuario, que identifique los paquetes de datos que contiene.

Implica escritura, actualización o borrado de datos.

Implica lectura o recuperación de información almacenada.

Anónimo dijo...

Rosa Maria Cazares Espinosa 06480443

Agrego esta información que considero importante que encontre sobre los diferentes tipos de paradigmas de la ingeníeria de software para complementar la unidad.

PARADIGMAS
La ingeniería de software esta compuesta por una serie de pasos que abarcan los métodos, herramientas y los procedimientos. Estos pasos se denominan frecuentemente paradigmas de la ingeniería de software. La elección de un paradigma para la ingeniería de software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicación, los métodos, herramientas a usar, los controles y entregas requeridos.

Gama de paradigmas de la ingeniería de software:

PARADIGMA CICLO DE VIDA DEL SOFTWARE Este fue el modelo inicial planteado para organizar el proceso de desarrollo, aunque antiguo tiene vigencia en algunos proyectos o como parte de otros modelos, da la medida de los pasos tradicionales de cualquier modelo: análisis, diseño, codificación, prueba y mantenimiento.

PARADIGMA DE CONSTRUCCIÓN DE PROTOTIPOS Normalmente un cliente definirá un conjunto de objetivos generales para el software pero no identificara los requerimientos detallados de entrada, procesamiento de salida.
En otros casos el programador puede no estar seguro de la eficiencia de un algoritmo, la adaptabilidad de un sistema operativo o la forma en que debe realizarse la interacción hombre-maquina. En estas y muchas otras situaciones puede ser mejor método de ingeniería de software realizar un prototipo. La construcción de prototipo es un proceso que facilita al programador la creación de un método de software a conseguir.
Los sucesos para el paradigma de construcción de prototipos es la siguiente:
-Recolección de los requerimientos
-Diseño rápido
-Construir prototipo
-Evaluar, refinar los requerimientos
-Producto construido
-Mantenimiento

PARADIGMA DEL MODELO ESPIRAL Es un modelo de proceso de software evolutivo. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones. La versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez mas completas de ingeniería del sistema.
El modelo en espiral se divide en un número de actividades estructurales, también llamadas regiones de tareas. Generalmente existen seis regiones de tareas.
-Comunicación con el cliente
-Planificación
-Análisis de Riesgos
-Ingeniería
-Construcción y Adaptación
-Evaluación del cliente

EL MODELO DRA El Desarrollo Rápido de Aplicaciones (DRA) (rapid application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:
-Modelado de gestión
-Modelado de datos
-Modelado de proceso
-Generación de aplicaciones
-Pruebas de entrega

PARADIGMA DE TÉCNICAS DE CUARTA GENERACION El termino de técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de software ha especificar algunas características de alto nivel. Luego la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Existe cierto debate sobre cuanto ha de elevarse el nivel en el que se especifique el software para una maquina. El paradigma de T4G para la ingeniería de software se orienta hacia la habilidad de especificar software a un nivel que sea más próximo al lenguaje natural o a una notación que proporcione funciones significativas.
El paradigma T4G para la ingeniería de software se describe de la siguiente forma:
-Recolección de los requerimientos
-Estrategia de diseño
-Implementación
-Producto
-Mantenimiento

EL MODELO DE DESARROLLO CONCURRENTE Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.
Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo.
El modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.
En realidad, el modelo de desarrollo concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto. En vez de confinar actividades de ingeniería de software a una secuencia de sucesos, define una red de actividades, todas las actividades de la red existen simultáneamente con otras. Los sucesos generados dentro de una actividad dada o algún otro lado de la red de actividad inicia las transiciones entre los estados de una actividad.

COMBINACIÓN DE PARADIGMAS En muchos casos los paradigmas pueden y deben combinarse en forma que puedan utilizarse las ventajas de cada uno en un único proyecto.
La naturaleza de aplicación dictara la aplicabilidad del método de construcción de prototipos. Si los requerimientos para la función y rendimiento del software están razonablemente bien comprendidos pueden ser aplicables los métodos de especificación recomendados para el ciclo de vida clásico. Por otra parte si la aplicación del software exige una fuerte interacción hombre-maquina o requiere algoritmos no probados o técnicas de control de salidas pueden regresarse a un prototipo. En tales casos puede usarse un lenguaje de cuarta generación para el desarrollo de un prototipo. Una vez que se haya evaluado y reafinado el prototipo pueden aplicarse los pasos de diseño e implementación del ciclo de vida clásico para desarrollar el software formalmente.

Anónimo dijo...

LES FALTO HABLAR ALGO SOBRE LOS DIAGRAMAS DE FLUJO
El diagrama de flujo de datos (DFD), es una herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre sí por "conductos" y "tanques de almacenamiento" de datos. Siendo éste, una de las herramientas más comúnmente usadas, sobre todo por sistemas operacionales en los cuales las funciones del sistema son de gran importancia y son más complejos que los datos que éste maneja.
Es importante tener en mente: los DFD no sólo se pueden utilizar para modelar sistemas de sistemas de proceso de información, sino también como manera de modelar organizaciones enteras, es decir, como una herramienta para la planeación estratégica y de negocios.
Los componentes de un diagrama típico de flujo de datos:
• Proceso.
• Flujo.
• Almacén.
• Terminador.
Proceso.
El primer componente del DFD se conoce como proceso. Los sinónimos comunes son burbuja, función, transformación. El proceso muestra una parte del sistema que transforma entradas en salidas.


FLUJO
Un flujo se representa gráficamente por medio de una flecha que entra o sale de un proceso; un ejemplo se muestra en la figura 4.1.2. El flujo se usa para describir el movimiento de bloques o paquetes de información de una parte del sistema a otra
Almacén.
El almacén se utiliza para modelar una colección de paquetes de datos en reposo. Se denota por dos líneas paralelas, como lo muestra la figura 4.1.5. De modo característico el nombre que se utiliza para identificar al almacén es el plural del que se utiliza para los paquetes que entran y salen del almacén por medio de flujos.
TERMINDADOR
Los terminadores representan entidades externas con las cuales el sistema se comunica. Comúnmente, puede ser una persona, o un grupo, por ejemplo, una organización externa o una agencia gubernamental, o un grupo o departamento que esté dentro de la misma compañía u organización, pero fuera del control del sistema que se está modelando.

MIGUEL JAZAHEL PUENTE CASTILLO
06480376