sábado, 9 de agosto 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


AUTORO:
Adolfo Antonio Marcillo Cedeño



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

martes, 29 de julio de 2014

DIAGRAMA DE FLUJO DE DATOS


INTRODUCCIÓN.

En esta clase se explicó el diagrama de fuljo de datos que se lo realiza para tener una comunicación entre el usuario y programador para que el usuario sepa de qué forma fluyen sus datos.


MARCO TEÓRICO

DIAGRAMA DE FLUJO DE DATOS

La metodología del flujo de datos para determinar los requerimientos humanos. “Los diagramas de flujo de datos (DFD) describen de forma general las entradas, los procesos y las salidas del sistema.”
Se lo puede definir como una técnica de análisis estructurado, donde el analista de sistemas puede ensamblar una representación gráfica de los procesos de datos a través de la organización. Al usar combinaciones de sólo cuatro símbolos, el analista puede crear una descripción ilustrada de los procesos con el fin de elaborar una documentación sólida para el sistema.


Ventajas de la metodología del flujo de datos

1. No hay que comprometerse demasiado pronto con la implementación técnica del sistema.
2. Permite comprender con más detalle la capacidad de interrelación de los sistemas y subsistemas.
3. Se puede comunicar el conocimiento del sistema actual a los usuarios por medio de diagramas de flujo de datos.
4. Se puede analizar un sistema propuesto para determinar si se han definido los datos y procesos necesarios.

CONVENCIONES USADAS EN LOS DFD

4 SÍMBOLOS BÁSICOS para graficar el movimiento de los datos en el diagrama:

Un cuadrado doble, una flecha, un rectángulo con esquinas redondas y un rectángulo con un extremo abierto (cerrado del lado izquierdo y abierto del lado derecho).


ENTIDAD.

 Describe una entidad externa (una empresa, una persona o una máquina) que pueda enviar/recibir datos hacia/desde el sistema.
 Cada entidad se identifica con un nombre apropiado. Aunque interactúa con el sistema, se considera fuera de los límites de éste.
 Se debe denominar a las entidades con un sustantivo. Se puede utilizar la misma entidad más de una vez en un diagrama de flujo de datos para evitar cruzar las líneas de flujo de datos.



FLUJO DE DATOS.

 La flecha muestra el movimiento de los datos de un punto a otro;
 La cabeza de la flecha apunta hacia el destino de los datos.
 Los flujos de datos que ocurren al mismo tiempo se pueden describir mediante el uso de flechas paralelas.
 Como una flecha representa datos sobre una persona, lugar o cosa, también se debe describir con un sustantivo.



PROCESO.

 Se utiliza un rectángulo con esquinas redondas para mostrar la ocurrencia de un proceso de transformación.
 Siempre expresan un cambio o transformación en los datos; por ende, el flujo de datos que sale de un proceso siempre se identifica de manera distinta al flujo que entra al proceso.

 Representan el trabajo que se realiza en el sistema y se deben denominar mediante el uso de uno de los siguientes formatos.
 Debe recibir un número de identificación único que indique su nivel en el diagrama.



ALMACEN DE DATO.

 El rectángulo se dibuja con dos líneas paralelas que se cierran mediante una línea corta del lado izquierdo y cuyo extremo derecho está abierto.
 En los DFD lógicos no se especifica el tipo de almacenamiento físico (permite examinar, agregar y recuperar los datos).
 Puede representar un almacén manual como un archivero o una base de datos computarizada.
 Como los almacenes de datos representan a una persona, lugar o cosa, se denominan con un sustantivo.
 Los almacenes de datos temporales, como el papel de borrador o un archivo temporal de computadora, no se incluyen en el diagrama de flujo de datos.
 Hay que dar a cada almacén de datos un número de referencia único, como D1, D2, D3, por ejemplo.




PROCEDIMIENTO QUE REALIZA EL ANALISTA

 Se utiliza una metodología arriba-abajo para dibujar primero un diagrama de flujo de datos a nivel de contexto del sistema con una vista más amplia.
o Se dibuja un diagrama de flujo de datos lógico de nivel 0.
o Se muestran los procesos y se agregan los almacenes de datos.

 Se crea un diagrama hijo para cada uno de los procesos en el Diagrama 0.

o Las entradas y salidas permanecen constantes, pero los almacenes de datos y los orígenes cambian. Al expandir el diagrama de flujo de datos original, el analista de sistemas se puede concentrar en descripciones más detalladas del movimiento de datos en el sistema.

 Se desarrolla un diagrama de flujo de datos físico a partir del diagrama de flujo de datos lógico y se particiona para facilitar la programación.
o Se analiza cada proceso para determinar si debe ser manual o automatizado.



DIAGRAMA DE CONTEXTO

• El diagrama de contexto es el nivel más alto en un diagrama de flujo de datos y contiene sólo un proceso, el cual representa a todo el sistema.
• El proceso recibe el número cero.
• El diagrama no contiene almacenes de datos y es bastante simple de crear una vez que los analistas conocen las entidades externas y el flujo de datos que entra y sale de ellas.

DIBUJO DEL DIAGRAMA 0

El Diagrama 0 es la expansión del diagrama de contexto; puede incluir hasta nueve procesos.
Los diagramas de contexto (superior) se pueden “expandir” en un Diagrama 0 (inferior).



CREACIÓN DE DIAGRAMAS HIJOS (Niveles más detallados).

La regla principal para crear diagramas hijos es el balanceo vertical; establece que no puede producir salida o recibir entrada que el proceso padre no produzca o reciba también.
Todos los datos entrantes o salientes del proceso padre deben mostrarse como entrantes o salientes en el diagrama hijo.
Se enumeran mediante el uso del número del proceso padre, un punto decimal y un número único para cada proceso hijo.
El flujo de datos que concuerda con el flujo padre se denomina flujo de datos de interfaz y se muestra como una flecha que entra o sale de un área en blanco del diagrama hijo.
Los procesos se pueden o no expandir, dependiendo de su nivel de complejidad. Cuando un proceso no se expande, se dice que es funcionalmente primitivo y se le denomina proceso primitivo.



COMPROBACIÓN DE ERRORES EN LOS DIAGRAMAS

1. Olvidar incluir un flujo de datos o apuntar una flecha en dirección equivocada.
2. Conectar almacenes de datos y entidades externas directamente entre sí. No se pueden conectar los almacenes de datos y las entidades entre sí; se deben conectar sólo mediante un proceso. Las entidades externas no trabajan directamente con archivos.
3. Etiquetar de manera incorrecta los procesos o el flujo de datos. Cada flujo de datos se debe describir con un sustantivo.
4. Incluir más de nueve procesos en un diagrama de flujo de datos. Al tener muchos procesos se produce un diagrama sobrecargado de información que crea confusión. Si hay más de nueve procesos, conviene agrupar algunos para formar un subsistema y colocarlos en un diagrama hijo.
5. Omitir el flujo de datos. Buscar un flujo de datos en el que cada proceso sólo tiene una entrada y una salida. El flujo de datos lineal ocurre raras veces. Por lo general su presencia indica que faltan flujos de datos en el diagrama.

6. Crear una expansión desbalanceada en los diagramas hijos. Cada diagrama hijo debe tener el mismo flujo de datos de entrada y salida que el proceso padre. La excepción a esta regla es la salida menor, como las líneas de error que se incluyen sólo en el diagrama hijo.

ERRORES COMUNES QUE PUEDEN OCURRIR EN UN DIAGRAMA DE FLUJO DE DATOS
(EJEMPLO DE NÓMINA).




EL DIAGRAMA DE FLUJO DE DATOS CORRECTO.
(EJEMPLO DE NÓMINA).







CONCLUSIÓN.


Es importante realizar este diagrama de flujo de dato ya q este diagrama dará entendimiento al usuaria de su software ya que en él se describen todo sus procesos y entidades que contendrás y sabrá como se van a estar movilizando los datos o ver como fluye la información. 



BIBLIOGRAFÍA


Kendall, K. & Kendall, J. 2011. Análisis y diseño de sistemas. Capítulo 7. Octava Ed. PEARSON EDUCACIÓN, México, 2011

jueves, 17 de julio de 2014

DIAGRAMAS DE COMPONENTES (CLASES - ACTIVIDADES - ESTADOS)


INTRODUCCIÓN.

En esta se dio a conocer el diagrama de clase la cual es una representación visual de cómo se representa los modelos de objetos especifica los detalles para la construcción de sistema así mismo en diagrama de secuencia la cual muestra la interacción de los componentes de una forma temporal, los diagramas de actividad permiten describir como un sistema implementa su funcionalidad en el momento de llevar a cabo un proceso, los diagrama de estados en si se utiliza para ver el comportamiento de las clases.


MARCO TEÓRICO
Diagrama de clases

En los diagramas de clases, se describen el objeto y las estructuras de información que se utilizan en la aplicación, tanto de forma interna como en la comunicación con los usuarios. Un diagrama de clases es una descripción visual de los posibles sistemas. Un diagrama de clases y un diagrama de objetos son las alternativas de representación de modelos de objetos, aunque los diagramas de clases prevalecen más que los de objetos. Normalmente se puede construir un diagrama de clases y ocasionalmente uno de objetos para ilustrar las estructuras de datos más complejas. Una clase es una ícono que se representa como una caja, la que se divide en tres partes, con el nombre de la clase en la parte superior, la lista de sus atributos en la segunda y la lista de sus operaciones o métodos en la última.





Diagrama de Actividades.

Son utilizados para modelar el comportamiento de los casos de uso, objetos u operaciones y se usan además para elaborar modelos de flujo de trabajo. Muestran el flujo entre objetos e información y capturan las acciones de una actividad y sus resultados.
Los diagramas de actividad permiten describir como un sistema implementa su funcionalidad las actividades modelan el comportamiento dinámico de un procedimiento, transacción o caso de uso haciendo énfasis en el proceso que se lleva a cabo.
Los diagramas de actividad es uno de los elementos de modelado que son mejor comprendidos por todos, ya que son herederos directos de los diagramas de flujo, pero los diagramas de actividad son más expresivos que los diagramas de flujo. 





Diagrama de estados


La secuencia de estados en  caso de uso, indicando qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que generan. Se utilizan para modelar el comportamiento de los objetos en el sistema. Los diagramas de estado son útiles para describir el comportamiento de clases y sistemas que han sido concebidos haciendo uso de un modelo de estados. En un modelo de estados se identifican las situaciones en la que el comportamiento o capacidad de respuesta con cualitativamente diferentes.


CONCLUSIÓN.

Los diagramas de clases describen el objeto es decir sus métodos y sus atributos lo que da una visión general del objeto además se visualiza las relaciones entre las clases del sistema, los diagrama de actividades son parecido a diagrama de flujo pero lo diagrama de actividad permiten describir su funcionalidad del proceso, Los diagramas de estado son útiles para describir el comportamiento de clases lo cual se utiliza para ver el comportamiento de los objetos.


BIBLIOGRAFÍA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición

Kendall, J; Kendall, K.2011. Análisis y diseño de sistemas. 8va edición.



miércoles, 9 de julio de 2014

DIAGRAMAS DE COMPONENTES (DESPLIEGUE Y SECUENCIA)


INTRODUCCIÓN.

En esta se dio a conocer el diagrama de despliegue que el cual se especifica los detalles para la construcción de sistema así mismo en diagrama de secuencia la cual muestra la interacción de los componentes de una forma temporal.

MARCO TEÓRICO

Diagrama de despliegue.
Los diagramas de despliegue se utilizan para visualizar los aspectos estáticos de estos nodos físicos y sus relaciones y para especificar sus detalles para la construcción.






DIAGRAMA DE SECUENCIA
Se utilizan para modelar el paso de mensajes entre objetos, se modela un diagrama de secuencia para cada caso de uso.

Representa una forma de indicar el período durante el que un objeto está desarrollando una acción directamente o a través de un procedimiento.

Muestra la interacción de los objetos que componen un sistema de forma temporal, es decir, ordenadas según el tiempo en que tienen lugar.





CONCLUSIÓN.

Los diagramas son importante de realizarlos ya que dan una visión general de los detalles del sistema así mismo el de clases pero este de forma temporal, es decir, ordenadas según el tiempo en que tienen lugar.

BIBLIOGRAFÍA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición


Kendall, J; Kendall, K.2011. Análisis y diseño de sistemas. 8va edición. 






jueves, 3 de julio de 2014

Casos de Uso


INTRODUCCIÓN.

En esta clase se planteó la función principal del caso de uso que es visualizar desde el punto de vista del usuario lo cual es la función primordial, todos los diagramas diagrama tiene su función y es necesario para cada uno de las resoluciones de los problemas.

MARCO TEÓRICO
Casos de Uso

Un caso de uso capta un contrato que describe el comportamiento del sistema en distintas condiciones en las que el sistema responde a una petición de alguno de sus participantes. En esencia, un caso de uso narra una historia estilizada sobre cómo interactúa un usuario final (que tiene cierto número de roles posibles) con el sistema en circunstancias específicas.
Un  lineamiento de tareas o interacciones, una descripción basada en un formato o una representación diagramática. Sin importar su forma, un caso de uso ilustra el software o sistema desde el punto de vista del usuario final.
El primer paso para escribir un caso de uso es definir un conjunto de “actores” que estarán involucrados en la historia. Los actores son las distintas personas (o dispositivos) que usan el sistema o producto en el contexto de la función y comportamiento que va a describirse. Los actores representan los papeles que desempeñan las personas (o dispositivos) cuando opera el sistema. Con una definición más formal, un actor es cualquier cosa que se comunique con el sistema o producto y que sea externo a éste. Todo actor tiene uno o más objetivos cuando utiliza el sistema.
Es importante notar que un actor y un usuario final no necesariamente son lo mismo. Un usuario normal puede tener varios papeles diferentes cuando usa el sistema, mientras que un actor representa una clase de entidades externas (gente, con frecuencia pero no siempre) que sólo tiene un papel en el contexto del caso de uso.
Una vez identificados los actores, es posible desarrollar casos de uso. Que debe responder un caso de uso:

• ¿Quién es el actor principal y quién(es) el(los) secundario(s)?
• ¿Cuáles son los objetivos de los actores?
• ¿Qué precondiciones deben existir antes de comenzar la historia?
• ¿Qué tareas o funciones principales son realizadas por el actor?
• ¿Qué excepciones deben considerarse al describir la historia?
• ¿Cuáles variaciones son posibles en la interacción del actor?
• ¿Qué información del sistema adquiere, produce o cambia el actor?
• ¿Tendrá que informar el actor al sistema acerca de cambios en el ambiente externo?
• ¿Qué información desea obtener el actor del sistema?
• ¿Quiere el actor ser informado sobre cambios inesperados?

Considerando la situación en la que el propietario de la casa usa el panel de control, a continuación se plantea el caso de uso básico para la activación del sistema

1. El propietario observa el panel de control de CasaSegura para determinar si el sistema está listo para recibir una entrada. Si el sistema no está listo, se muestra el mensaje no está listo en la pantalla de cristal líquido y el propietario debe cerrar físicamente ventanas o puertas de modo que desaparezca dicho mensaje [el mensaje no está listo implica que un sensor está abierto; por ejemplo, que una puerta o ventana está abierta].

2. El propietario usa el teclado para introducir una clave de cuatro dígitos. La clave se compara con la que guarda el sistema como válida. Si la clave es incorrecta, el panel de control emitirá un sonido una vez y se reiniciará para recibir una entrada adicional. Si la clave es correcta, el panel de control espera otras acciones.

3. El propietario selecciona y teclea permanecer o fuera para activar el sistema. La entrada permanecer activa sólo sensores perimetrales (se desactivan los sensores de detección de movimiento interior). La entrada fuera activa todos los sensores.

4. Cuando ocurre una activación, el propietario observa una luz roja de alarma.

Diagrama de caso de uso.


CONCLUSIÓN.

El caso de uso es la interacción entre el actor y el sistema para así dar a conocer de como el usuarios o actores van interactuar en el sistema.

BIBLIOGRAFÍA


Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición




martes, 24 de junio de 2014

PROCESO UNIFICADO


Es un intento por obtener los mejores rasgos y características de los modelos tradicionales del proceso del software, pero en forma que implemente muchos de los mejores principios del desarrollo ágil de software. Reconoce la importancia de la comunicación con el cliente y los métodos directos para describir su punto de vista respecto de un sistema.

La arquitectura del software “ayuda a que el arquitecto se centre en las metas correctas, tales como que sea comprensible, permita cambios futuros y la reutilización” se sugiere un flujo del proceso iterativo e incremental, lo que da la sensación evolutiva que resulta esencial en el desarrollo moderno del software.


- La fase de concepción del PU agrupa actividades tanto de comunicación con el cliente como de planeación.
  • Se desarrolla un plan para la naturaleza iterativa e incremental del proyecto en cuestión.
  • La arquitectura se mejorará después y se expandirá en un conjunto de modelos que representarán distintos puntos de vista del sistema.
- La fase de elaboración incluye las actividades de planeación y modelado del modelo general del proceso
  • La elaboración mejora y amplía los casos de uso preliminares desarrollados como parte de la fase de concepción y aumenta la representación de la arquitectura para incluir puntos de vista distintos del software.
  • En ciertos casos, crea una “línea de base de la arquitectura ejecutable” que representa un sistema ejecutable de “primer corte”. La línea de base de la arquitectura demuestra la viabilidad de ésta, pero no proporciona todas las características y funciones que se requieren para usar el sistema.
  • Al terminar la fase de elaboración se revisa con cuidado el plan a fin de asegurar que el alcance, riesgos y fechas de entrega siguen siendo razonables. Es frecuente que en este momento se hagan modificaciones al plan.
- La fase de construcción es idéntica a la actividad de construcción definida para el proceso general del software.

- La fase de transición del PU incluye las últimas etapas de la actividad general de construcción y la primera parte de la actividad de despliegue general (entrega y retroalimentación).
  • Se da el software a los usuarios finales para las pruebas beta, quienes reportan tanto los defectos como los cambios necesarios.
  • El equipo de software genera la información de apoyo necesaria (manuales de usuario, guías de solución de problemas, procedimientos de instalación, etc.) que se requiere para el lanzamiento.
  • Al finalizar la fase de transición, el software incrementado se convierte en un producto utilizable que se lanza.
 - La fase de producción coincide con la actividad de despliegue del proceso general.
  • Se vigila el uso que se da al software
  • Se brinda apoyo para el ambiente de operación
  • Se reportan defectos y solicitudes de cambio para su evaluación
Es probable que al mismo tiempo que se llevan a cabo las fases de construcción, transición y producción, comience el trabajo sobre el siguiente incremento del software. Esto significa que las cinco fases del PU no ocurren en secuencia sino que concurren en forma escalonada.

CONCLUSIÓN 


Un proceso es un conjunto de pasos ordenados para alcanzar un objetivo. En ingeniería de software, el objetivo es construir un producto de software nuevo o extender uno existente. Esto permite enfocar esfuerzo de los recursos humanos en términos de habilidades, competencias y capacidades a asumir roles específicos con responsabilidades bien definidas.





BIBLIOGRAFÍA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición



jueves, 19 de junio de 2014

METODOLOGÍAS ÁGILES


INTRODUCCIÓN.

Las metodología ágil es la forma más óptima de acoplarse a nuevos requerimientos en la creación de proyecto lo principal de esta clase es dar a conocer los principales sistemas agiles en la construcción de software.

MARCO TEÓRICO

METODOLOGÍAS ÁGILES
La historia de la ingeniería de software está salpicada de decenas de descripciones y metodologías de proceso, métodos de modelado y notaciones, herramientas y tecnología, todos ellos obsoletos. Cada uno tuvo notoriedad y luego fue eclipsado por algo nuevo y (supuestamente) mejor. Con la introducción de una amplia variedad de modelos ágiles del proceso —cada uno en lucha por la aceptación de la comunidad de desarrollo de software— el movimiento ágil está siguiendo la misma ruta histórica.

Principios de agilidad.

doce principios de agilidad para aquellos que la quieran alcanzar:

1. La prioridad más alta es satisfacer al cliente a través de la entrega pronta y continua de software valioso.

2. Son bienvenidos los requerimientos cambiantes, aun en una etapa avanzada del desarrollo. Los procesos ágiles dominan el cambio para provecho de la ventaja competitiva del cliente.

3. Entregar con frecuencia software que funcione, de dos semanas a un par de meses, de preferencia lo más pronto que se pueda.

4. Las personas de negocios y los desarrolladores deben trabajar juntos, a diario y durante todo el proyecto.

5. Hay que desarrollar los proyectos con individuos motivados. Debe darse a éstos el ambiente y el apoyo que necesiten, y confiar en que harán el trabajo.

6. El método más eficiente y eficaz para transmitir información a los integrantes de un equipo de desarrollo, y entre éstos, es la conversación cara a cara.

7. La medida principal de avance es el software que funciona.

8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deben poder mantener un ritmo constante en forma indefinida.

9. La atención continua a la excelencia técnica y el buen diseño mejora la agilidad.

10. Es esencial la simplicidad: el arte de maximizar la cantidad de trabajo no realizado.

11. Las mejores arquitecturas, requerimientos y diseños surgen de los equipos con organización propia.

12. El equipo reflexiona a intervalos regulares sobre cómo ser más eficaz, para después afinar y ajustar su comportamiento en consecuencia.


Un modelo de desarrollo ágil es un proceso incremental con pequeñas entregas de software ya que el software va evolucionando y necesita de nuevas características o nuevos requerimientos.

El más usado de todos los modelos ágiles de proceso es la programación extrema (XP). Pero se han propuesto muchos otros y están en uso en toda la industria. Entre ellos se encuentran los siguientes:

• Desarrollo adaptativo de software (DAS)
• Scrum
• Método de desarrollo de sistemas dinámicos (MDSD)
• Cristal
• Desarrollo impulsado por las características (DIC)
• Desarrollo esbelto de software (DES)
• Modelado ágil (MA)
• Proceso unificado ágil (PUA)



CONCLUSIÓN.

Las metodologías agiles son requeridas mucho en el desarrollo del proceso de software ya q estas metodologías permiten realizar pequeños incremento al equipo de desarrollo sin generar problemas ya que pasaría por lo mismo que todo el proceso de desarrollo es decir todas las actividades de desarrollo de software.


BIBLIOGRAFÍA


Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición





martes, 10 de junio de 2014

MODELOS DE PROCESOS ESPECIALIZADOS


Los modelos de proceso especializado tienen muchas de las características de uno o más de los modelos tradicionales, sin embargo, dichos modelos tienden a aplicarse cuando se elige un enfoque de ingeniería de software especializado o definido muy específicamente.


DESARROLLO BASADO EN COMPONENTES.

el modelo de desarollo basado en componentes incorpora muchas de las características del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creación del software. El modelo basado en componente configura aplicaciones desde componentes preparados software.El modelo de desarrollo basado en componentes conduce a la reutilización del software, y la reutilización proporciona beneficios a los ingenieros de software.Sin importar la tecnología usada para crear los componentes, el modelo de desarrollo basado en componentes incorpora las etapas siguientes.

  1. Se investigan y evalúan, para el tipo de aplicación de que se trate, productos disponibles basados en componentes.
  2. Se consideran los aspectos de integración de los componentes.
  3. Se diseña una arquitectura del software para que reciba los componentes.
  4. Se integran los componentes en la arquitectura.
  5. Se efectúan pruebas exhaustivas para asegurar la funcionalidad apropiada.
El modelo del desarrollo basado en componentes lleva a la reutilización del software, y eso da a los ingenieros de software varios beneficios en cuanto a la mensurabilidad. Si la reutilización de componentes se vuelve parte de la cultura, el equipo de ingeniería de software tiene la posibilidad tanto de reducir el ciclo de tiempo del desarrollo como el costo del proyecto. 


MODELOS DE MÉTODOS FORMALES.


El modelo de métodos formales acompaña a un conjunto de actividades que conducen a la especificación matemática del software de computadora. Los métodos formales permiten que un ingeniero del software especifique, desarrolle y verifique un sistema basado en computadora aplicando una notación rigurosa y matemática.

La ambigüedad, lo incompleto y la inconsistencia se descubren y se corrigen más fácilmente, no mediante una revisión a propósito para el caso, sino mediante la aplicación del análisis matemático. Cuando se utilizan métodos formales durante el diseño, sirven como base para la verificación de programas y por consiguiente permiten que el ingeniero del software descubra y corrija errores que no se pudieron detectar de otra manera.


Aunque el modelo de los métodos formales no es el más seguido, promete un software libre de defectos. Sin embargo, se han expresado preocupaciones acerca de su aplicabilidad en un ambiente de negocios:


  • El desarrollo de modelos formales consume mucho tiempo y es caro.
  • Debido a que pocos desarrolladores de software tienen la formación necesaria para aplicar métodos formales, se requiere mucha capacitación.
  • Es difícil utilizar los modelos como mecanismo de comunicación para clientes sin complejidad técnica.
A pesar de estas preocupaciones, el enfoque de los métodos formales ha ganado partidarios entre los desarrolladores que deben construir software de primera calidad en seguridad.


DESARROLLO DE SOFTWARE ORIENTADO A ASPECTO 

Sin importar el proceso del software que se elija, los constructores de software complejo implementan de manera invariable un conjunto de características, funciones y contenido de información localizados. Estas características localizadas del software se modelan como componentes (clases orientadas a objetos) y luego se construyen dentro del contexto de una arquitectura de sistemas. A medida que los sistemas modernos basados en computadora se hacen más sofisticados (y complejos), ciertas preocupaciones —propiedades que requiere el cliente o áreas de interés técnico— se extienden a toda la arquitectura. Algunas de ellas son las propiedades de alto nivel de un sistema (por ejemplo, seguridad y tolerancia a fallas). Otras afectan a funciones (aplicación de las reglas de negocios), mientras que otras más son sistémicas (sincronización de la tarea o administración de la memoria).

Cuando las preocupaciones afectan múltiples funciones, características e información del sistema, es frecuente que se les llame preocupaciones globales. Los requerimientos del aspecto definen aquellas preocupaciones globales que tienen algún efecto a través de la arquitectura del software. El desarrollo de software orientado a aspectos (DSOA), conocido también como programaciónorientada a aspectos (POA), es un paradigma de ingeniería de software relativamente nuevo que proporciona un proceso y enfoque metodológico para definir, especificar, diseñar y construir aspectos: “mecanismos más allá de subrutinas y herencia para localizar la expresión de una preocupación global”.

CONCLUSIÓN

Los métodos formales se centra fundamentalmente en las funciones y los datos. La especificación mediante métodos formales es más difícil de aprender que otros métodos de análisis. Las especificaciones formales se pueden estudiar matemáticamente, mientras que las informales no pueden estudiarse de esta manera.


BIBLIOGRAFÍA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición




jueves, 29 de mayo de 2014

MODELO DE PROCESO PRESCRIPTIVO


Los modelos son llamados prescriptivos ya que prescriven una serie de elementos de proceso así como su flujo de trabajo, cada uno de modelos se ajustan al marco de trabajo estándar pero cada uno aplica diferencias a cada una de las actividades y a su flujo de trabajo.



Los modelos prescriptivos de software nos definen un conjunto de tareas actividades, productos de trabajo que se requieren para desarrollar productos de calidad que son importantes para llevar control, estabilidad y organización a una actividad que tiende a ser caótica, el modelo prescriptivo llena el marco de trabajo con conjuntos de tareas explicitas para las acciones de la ingenieria de software. Se debe considerar que aun que un proceso sea prescriptivo esto no se debe asumir como estático, estos se deben adaptar al personal, al proyecto y al problema.



CUERPO. 
Modelo de Proceso Prescriptivo 
Modelo de Cascada.
El modelo de la cascada, a veces llamado ciclo de vida clásico, sugiere un enfoque sistemático y secuencial para el desarrollo del software, que comienza con la especificación de los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado.



Una variante de la representación del modelo de la cascada se denomina modelo en V, se ilustra el modelo en V, donde se aprecia la relación entre las acciones para el aseguramiento de la calidad y aquellas asociadas con la comunicación, modelado y construcción temprana. A medida que el equipo de software avanza hacia abajo desde el lado izquierdo de la V, los requerimientos básicos del problema mejoran hacia representaciones técnicas cada vez más detalladas del problema y de su solución.




  1. Es raro que los proyectos reales sigan el flujo secuencial propuesto por el modelo. Aunque el modelo lineal acepta repeticiones, lo hace en forma indirecta. Como resultado, los cambios generan confusión conforme el equipo del proyecto avanza. 
  2. A menudo, es difícil para el cliente enunciar en forma explícita todos los requerimientos. El modelo de la cascada necesita que se haga y tiene dificultades para aceptar la incertidumbre natural que existe al principio de muchos proyectos 
  3. El cliente debe tener paciencia. No se dispondrá de una versión funcional del(de los)programa(s) hasta que el proyecto esté muy avanzado. Un error grande sería desastroso si se detectara hasta revisar el programa en funcionamiento.


Hoy en día, el trabajo de software es acelerado y está sujeto a una corriente sin fin de cambios (en las características, funciones y contenido de información). El modelo de la cascada suele ser inapropiado para ese tipo de labor. No obstante, sirve como un modelo de proceso útil en situaciones en las que los requerimientos son fijos y el trabajo avanza en forma lineal hacia el final.


Modelos de Proceso Incremental


El modelo incremental combina elementos de los flujos de proceso lineal y paralelo, en tales casos, se elige un modelo de proceso diseñado para producir el software en incrementos. El modelo incremental aplica secuencias lineales en forma escalonada a medida que avanza el calendario de actividades. Cada secuencia lineal produce “incrementos” de software susceptibles de entregarse de manera parecida a los incrementos producidos en un flujo de proceso evolutivo.







Cuando se utiliza un modelo incremental, es frecuente que el primer incremento sea el producto fundamental. Es decir, se abordan los requerimientos básicos, pero no se proporcionan muchas características suplementarias (algunas conocidas y otras no). El cliente usa el producto fundamental (o lo somete a una evaluación detallada). Como resultado del uso y/o evaluación, se desarrolla un plan para el incremento que sigue. El plan incluye la modificación del producto fundamental para cumplir mejor las necesidades del cliente, así como la entrega de características adicionales y más funcionalidad. Este proceso se repite después de entregar cada incremento, hasta terminar el producto final. 


Modelos de Proceso Evolutivo

Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que permiten desarrollar versiones cada vez más completas del software.



Hacer Prototipos. El cliente describe un conjunto de de objetivos generales del software pero no identifica los requisitos detallados de entrada, salida o procesamiento y el desarrollador esta inseguro de la efectividad del software, si el cliente tiene un necesidad real del software pero no sepa definir los detalles o el mismo no sepa bien que es lo que quiere es importante como primer paso desarrollar un prototipo. y puede mezclarse con cualquier otro método.


El paradigma de construcción de prototipos se inicia con la comunicación el ingeniero de software y el cliente encuentran y definen los requisitos básicos y conocidos, entonces se plantea con rapidez una iteracion de construcción de prototipos y se presenta un diseño rápido y este se centra en aspectos visibles al cliente y al usuario final, se construye el prototipo y este se somete a una evaluación por parte del cliente/usuario para y con la retroalimentacion producida se reajustan los requisitos del software que se desarrollara. De tal forma que el prototipo sirve como un mecanismo para identificar los requisitos del software.

El Modelo Espiral. El modelo espiral es un proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos del modelo cascada, el modelo cascada se puede adaptar y aplicar a través del ciclo de vida completo de una aplicación desde el desarrollo del concepto hasta el mantenimiento. 

Cuando se aplica el modelo espiral se desarrolla una serie de entregas evolutivas iniciando desde posiblemente documentación y prototipos, hasta llegar versiones cada ves mejores del sistema.







Durante las primeras iteraciones, lo que se entrega puede ser un modelo o prototipo. En las iteraciones posteriores se producen versiones cada vez más completas del sistema cuya ingeniería se está haciendo. Un modelo en espiral es dividido por el equipo de software en un conjunto de actividades estructurales. Para fines ilustrativos, se utilizan las actividades estructurales generales ya analizadas.



Proceso Modelo Concurrente.

El modelo de desarrollo concurrente, en ocasiones llamado ingeniería concurrente, permite que un equipo de software represente elementos iterativos y concurrentes de cualquiera de los modelos de proceso. Es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo Por ejemplo, la actividad de modelado definida para el modelo espiral se logra por medio de invocar una o más de las siguientes acciones de software: Hacer prototipos, análisis y diseño.






El modelo de desarrollo concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componente funcional.


CONCLUSIONES

Todos los modelos del proceso del software ayudan al desarrolador seguir una secuencia gracias a estos modelos al desarrollar el software la calidad de este es que cumplen las especificaciones que desea el cliente con las diferentes tareas en un orden.


  • El modelo de cascada es uno de los modelos más utilizado en proyectos pequeños ya que tiene q tener bien en claro los requerimiento del software, si no se tienen en claro estos requerimientos generar problemas al desarrollarlo.
  • El modelos incremental aplica una secuencia lineal que produce incrementos lo cual modifica el software para cumplir las necesidades del cliente, este incremento se lo realiza hasta cumplir las especificaciones del cliente.
  • El modelo evolutivo es el que se caracteriza por  desarrollar versiones cada vez más completas del software, en este se encuentra el modelo prototipo el cual se hace ciertas especificaciones del software pero no se tiene en claro lo que se requiere por lo que se hace un diseño según  las especificaciones, de tal forma que sirva para identificar los requerimientos del software. EL modelo espiral el cual se entregan las primeras iteraciones de forma de prototipo lo cual se lleva documentación hasta llegar a versiones mas complejas.
  • Modelo concurrente este modelo es de tipo de red donde todas las personas actúan al mismo tiempo en el proceso del software, se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor


BIBLIOGRAFÍA


Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición