Ingenieria de Software

INTRODUCCIN A LA INGENIERA DE SOFTWARE
Definicin Ingeniera de software. Es una disciplina que comprende todos los aspectos de la produccin de software desde las etapas iniciales de la especificacin del sistema, hasta el mantenimiento de ste despus de que se utiliza.
Ingeniera de software.
Es el estudio de los principios y metodologas para desarrollo y mantenimiento de sistemas de software.
Es la aplicacin prctica del conocimiento cientfico en el diseo y construccin de programas de computadora y la documentacin asociada requerida para desarrollar. Operar (funcionar) y mantenerlos. Se conoce tambin como desarrollo de software o produccin de software.
Se trata del establecimiento de los principios y mtodos de la ingeniera a fin de obtener software de modo rentable que sea fiable y trabaje en mquinas reales.
La aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin (funcionamiento) y mantenimiento del software; es decir, la aplicacin de ingeniera al software.
Motivacin y necesidades
El impacto del software en nuestra sociedad y en la cultura contina siendo profundo. Al mismo tiempo que crece su importancia. Actualmente, el software tiene un doble papel. Es un producto y, al mismo tiempo, el vehculo para entregarlo.
Como producto, hace entrega de la potencia informtica que incorpora el hardware informtico o, ms ampliamente, una red de computadoras que es accesible por hardware local.
Si reside dentro de un telfono celular u opera dentro de una computadora central, el software es un transformador de informacin,
produciendo, gestionando, adquiriendo, modificando, mostrando o trasmitiendo informacin que puede ser tan simple como un solo bit, o tan complejo como un laboratorio en lnea.
Como vehculo utilizado para hacer entrega del producto, el software acta como la base de control de la computadora (sistemas operativos), la comunicacin de informacin (redes) y la creacin y control de otros programas (herramientas de software y entornos).
Atributos de un buen sistema de software

El objetivo primordial de la ingeniera de software es producir un sistema, aplicacin o producto de alta calidad. Para lograr este objetivo, se deben aplicar mtodos efectivos junto con herramientas modernas dentro del contexto de un proceso maduro de desarrollo de software

Adems, un buen ingeniero del software debe medir si la alta calidad se va a llevar a cabo.

La calidad de un sistema, aplicacin o producto es tan bueno como los requisitos que describen el problema, el diseo que modela la solucin,

el cdigo que conduce a un programa ejecutable y las pruebas que ejercitan el software para detectar errores.

Un buen ingeniero de software utiliza mediciones que evalan la calidad del anlisis y los modelos de diseo, el cdigo fuente, y los casos de prueba que se han creado al aplicar la ingeniera de software
FACTORES QUE AFECTAN A LA CALIDAD

Los factores que afectan a la calidad del software lo evalan desde tres puntos de vista:
FACTORES QUE AFECTAN A LA CALIDAD

Operacin del producto (utilizndolo) Revisin del producto (cambindolo) Transicin del producto (modificndolo para que funcione en un entorno diferente,portndolo)
MEDIDA DE LA CALIDAD
Aunque existen muchas medidas de la calidad del software, la correccin, facilidad de mantenimiento, integridad, y facilidad de uso proporcionan indicadores tiles para el equipo del proyecto
CORRECCION
Correccin. Un programa debe operar correctamente o proporcionar poco valor a sus usuarios. La correccin es el grado en el que el software lleva a cabo su funcin requerida.
FACILIDAD DE MANTENIMIENTO
Facilidad de mantenimiento. El mantenimiento del software cuenta con ms esfuerzo que cualquier otra actividad de ingeniera de software. La facilidad con la que se puede corregir un programa si se encuentra un error, se puede adaptar si su entorno cambia, o mejorar si el cliente desea un cambio de requisitos.
No hay forma de medir directamente la facilidad de mantenimiento; por consiguiente, se deben analizar medidas indirectas.
Una mtrica orientad al tiempo es el tiempo medio del cambio (TMC), es decir el tiempo que se tarda en analizar la peticin de cambio, en disear la modificacin adecuada, en implementar el cambio, en probarlo y distribuirlo a todos los usuarios
los programas mas fciles de mantener tendrn un TMC menor que los programas que no son fciles de mantener.
INTEGRIDAD
Integridad. En la poca actual en donde existe tanta intromisin al software, la integridad de ste ha llegado a tener mucha importancia.
INTEGRIDAD
Este atributo mide la capacidad de un sistema de un sistema para resistir ataques (tanto accidentales como intencionados) contra su seguridad.
INTEGRIDAD
El ataque se puede realizar en cualquiera de los componentes del software: programas, datos y documentos
FACILIDAD DE USO
Facilidad de uso. El calificativo amigable con el usuario se ha convertido en omnipresente en las discusiones sobre productos de software. Si un programa no es amigable con el usuario, frecuentemente est conducido al fracaso, incluso aunque las funciones que realice sean valiosas
FACILIDAD DE USO
La facilidad de uso es un intento de cuantificar lo amigable que puede ser con el usuario y se puede medir en funcin de cuatro caractersticas:
FACILIDAD DE USO
Habilidad intelectual y/o fsica requerida para aprender el sistema. El tiempo requerido para llegar a ser moderadamente eficiente en el uso del sistema.
FACILIDAD DE USO
Aumento neto en la productividad(sobre el enfoque del sistema que reemplaza) medida cuando alguien utiliza el sistema moderadamente y eficientemente Valoracin subjetiva (a veces obtenida mediante un cuestionario) de la disposicin de los usuarios hacia el sistema.
El PROCESO DE DESARROLLO
Modelos Son muchos los modelos de proceso que se han descrito sobre la ingeniera del software. Algunos son prescripciones para al manera en que debe avanzar el desarrollo del software, y otras son descripciones de la manera en que el desarrollo del software se hace en la realidad
En teora, las dos clases de modelo deberan ser iguales o similares, pero en la prctica no lo son.
La construccin de un modelo de proceso y la discusin de los subprocesos ayuda al equipo a comprender la brecha que existe entre lo que debe ser y lo que es.
Existen otras varias razones para el modelado de un proceso:
Cuando un grupo pone por escrito una descripcin de su proceso de desarrollo, da forma a una comprensin comn de las actividades, recursos y restricciones comprometidos en el desarrollo del software.
La creacin de un modelo de proceso ayuda al equipo de desarrollo a encontrar las inconsistencias, las redundancias y las omisiones en el proceso y en las partes que lo constituyen.
A medida que estos problemas se descubren y se corrigen, el proceso se vuelve mas efectivo y concentrado en la construccin del producto final.
El modelo debe reflejar las metas del desarrollo, como la construccin del software de alta calidad, la localizacin temprana de los defectos en el desarrollo y el cumplimiento de las restricciones del cronograma y el presupuesto.
A medida que se construye el modelo, el equipo de desarrollo evala las actividades candidatas por su grado de adecuacin para alcanzar estas metas.
Por ejemplo, el equipo puede llevar a cabo revisiones de requerimientos, de modo que los problemas relativos a los requerimientos puedan encontrarse y subsanarse antes de dar comienzo al diseo.
Todo proceso debe ser adaptado para la situacin especial en que ser utilizado. La construccin de un modelo de proceso ayuda al equipo de desarrollo a comprender dnde debe hacerse la adaptacin.
Todo modelo de proceso de desarrollo de software incluye los requerimientos del sistema como entrada y un producto entregado como salida. A lo largo de los aos se han propuesto muchos modelos de este tipo.
MODELOS
Cascada Uno de los primeros modelos que han sido propuestos es el modelo en cascada, como puede verse en la figura 1 donde las etapas se representan cayendo en cascada, desde una etapa hacia la siguiente.
Anlisis de requerimientos Diseo Del Sistema Diseo Del Programa Codificacin

Pruebas Unitaria Y De Integracin
Prueba Del Sistema Prueba De Aceptacin
Operacin y Mantenimiento
CASCADA
Como se desprende de esta figura, una etapa de desarrollo debe completarse antes de dar comienzo a la siguiente.
CASCADA
De esta forma, cuando todos los requerimientos del cliente han sido identificados, analizados para comprobar su integridad y consistencia, y documentados en un informe de requerimientos, recin entonces el equipo de desarrollo puede seguir con las actividades de desarrollo del sistema.
CASCADA
El modelo en cascada presenta una visin muy clara de cmo se suceden las etapas durante el desarrollo, y sugiere a los desarrolladores cul es la secuencia de eventos que podrn encontrar.
REQUERIMIENTOS DEL SOFTWARE

Identificacin de los requerimientos del software Antes de que puedan ser analizados, modelados o especificados los requisitos, deben ser recopilados a travs de un proceso de obtencin.
IDENTIFICACIN DE LOS REQUERIMIENTOS DEL SOFTWARE
Un cliente tiene un problema que pretende sea resuelto con una solucin basada en computadora. Un desarrollador responde a la solicitud de ayuda del cliente.
IDENTIFICACIN DE LOS REQUERIMIENTOS DEL SOFTWARE

Ha empezado la comunicacin. Sin embargo debe darse el proceso de la comunicacin al entendimiento.
Proceso de obtencin de los requerimientos del software

La tcnica de obtencin de requisitos ms usada es llevar a cabo una reunin o entrevista preliminar. Se sugiere que el analista empiece la comunicacin con preguntas de contexto libre .

Es decir, un conjunto de preguntas que llevarn a un entendimiento bsico del problema, qu solucin busca, la naturaleza de la solucin que desea.

El primer conjunto de cuestiones de contexto libre se enfoca sobre el cliente, los objetivos generales y los beneficios esperados. Por ejemplo:
PREGUNTAS DE CONTEXTO LIBRE

Quin utilizar la solucin? Cul ser el beneficio econmico del xito de una solucin? Existe otra alternativa para la solucin que necesita?

Estas preguntas ayudan a identificar a todos los participantes que tienen inters en el software a construir. Adems las preguntas identifican los beneficios medibles en una implementacin correcta de posibles alternativas para un desarrollo normal del software.

Las preguntas siguientes permiten al analista obtener un mejor entendimiento del problema y al cliente comentar sus opiniones sus opiniones sobre la solucin:

Cmo definira una buena salida generada por una buena solucin? A que tipo de problema(s) va dirigida esta solucin?

Puede mostrarme (o describirme) el entorno en el que se utilizar esta solucin? Hay aspectos o restricciones especiales del rendimiento que afectan a la manera de enfocar la solucin?

El ltimo conjunto de preguntas se enfoca en la eficacia de la reunin las siguientes pueden ser algunas de ellas:

Es usted la persona adecuada para responder a estas preguntas? Sus respuestas son oficiales? Estoy preguntando demasiado?

Hay alguien ms que pueda proporcionarme informacin adicional? Hay algo mas que deba preguntarle?

Estas y otras preguntas ayudarn a tomar confianza e iniciar la comunicacin tan esencial para el xito del anlisis. Pero este formato de reunin tipo pregunta y respuesta no es en s suficiente para obtener el xito

De hecho, esta sesin de preguntas y respuestas debera utilizarse solamente en el primer encuentro y despus sustituirse por una modalidad que combine elementos de resolucin de problema, negociacin y especificacin.
Tcnicas para la obtencin de las especificaciones de una aplicacin

Los clientes y los ingenieros de software a menudo trabajan por separado en lugar de trabajar como un equipo para identificar y determinar los requisitos.

Esto ocasiona que se den malentendidos, se omita informacin importante y que no exista una adecuada relacin de trabajo.

Debido a que se presentan estos problemas, es que se ha desarrollado un enfoque orientado al equipo para la reunin de requisitos que se aplica durante las primeras fases del anlisis y especificacin.

Se denominan Tcnicas para facilitar las especificaciones de la aplicacin (TFEA), este enfoque es partidario de la creacin de un equipo conjunto de clientes y desarrolladores que trabajan juntos

para identificar el problema, proponer soluciones, negociar diferentes enfoques y especificar un conjunto de preliminar de requisitos de la solucin.

Se han propuesto muchos enfoques diferentes de TFEA cada uno utiliza un escenario ligeramente diferente, pero todos aplican alguna variacin de las siguientes directrices bsicas:
TECNICAS PARA FACILITAR LAS ESPECIFICACIONES DE LA APLICACIN

La reunin se celebra en un lugar neutral y acuden tanto clientes como los desarrolladores. Se establecen normas de preparacin y de participacin

Se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes, pero lo suficientemente informal como para propiciar el libre flujo de ideas. Se establece la participacin de un coordinador (que puede ser un cliente, un desarrollador o un tercero) que controle la reunin

Se utiliza un mecanismo de definicin (hojas de trabajo, grficos, carteles, pizarrn) El objetivo es identificar el problema, proponer elementos de solucin, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solucin en un ambiente que permita alcanzar el objetivo.
REQUERIMIENTOS
Cuando una compaa desea se le desarrolle un proyecto de software, debe definir sus necesidades de forma tal que pueda establecerse a partir de ella, una solucin,
REQUERIMIENTOS
los requerimientos deben redactarse de tal forma que, el desarrollador pueda ofrecer la forma de cumplir las necesidades del cliente.
REQUERIMIENTOS
Una vez que el contrato se asigna, el desarrollador debe redactar una definicin del sistema parta el cliente de forma que ste comprenda y pueda validar lo que har el software.
REQUERIMIENTOS
. A ambos documentos se les llama: documento de requerimientos para el sistema.
REQUERIMIENTOS
Algunos de los problemas que surgen durante el proceso de obtencin de requerimientos son el resultado de no hacer una clara separacin entre los diferentes niveles de descripcin.
REQUERIMIENTOS
Esto se hace utilizando el trmino requerimientos del usuario, para designar los requerimientos abstractos de alto nivel, y requerimientos del sistema, para designar la descripcin detallada de lo que el sistema debe hacer.
REQUERIMIENTOS
De igual forma que en estos dos niveles de detalle, se puede producir una descripcin mas detallada (una especificacin del diseo del software) para establecer un puente entre la obtencin de los requerimientos y las actividades de diseo.
REQUERIMIENTOS
Los requerimientos del usuario, los del sistema y la especificacin del diseo del software se definen de la siguiente manera:
REQUERIMIENTOS
1. Los requerimientos del usuario son declaraciones, en lenguaje natural y en diagramas, de los servicios que se espera que el sistema provea y de las restricciones bajo las cuales debe operar. 2. Los requerimientos del sistema establecen con detalle los servicios y restricciones del sistema, este documento debe ser preciso.
REQUERIMIENTOS
3. Una especificacin del diseo del software es una descripcin abstracta del diseo del software que es una base para un diseo e implementacin detallados. Esta especificacin agrega detalle a la especificacin de requerimientos del sistema.
Definicin de requerimientos del usuario

1. El software debe permitir la elaboracin y edicin de documentos de texto va web con mecanismos de conciencia de grupo por un nmero n de participantes
Especificacin de los requerimientos del sistema a) A los participantes de la conferencia se les permite seleccionar el archivo a abrir.
b) Los participantes de la conferencia saben mediante un widget quien mas se encuentra utilizando la aplicacin. c) Los participantes de la conferencia conocen la posicin dentro del texto en que se encuentran las dems personas que estn utilizando la aplicacin gracias a las barras de desplazamiento mltiples. d) Los participantes de la conferencia saben la posicin del puntero del ratn de los dems participantes de la conferencia.
Figura 3.1 Requerimientos del usuario y del sistema
REQUERIMIENTOS
Los diferentes niveles de especificacin del sistema son de utilidad debido a que comunican la informacin del sistema a los diferentas tipos de lectores.
REQUERIMIENTOS
La figura 3.1 ilustra la diferencia entre los requerimientos del usuario y del sistema. Muestra la manera en que un requerimiento del usuario se divide en varios requerimientos del sistema.
REQUERIMIENTOS
Los requerimientos del usuario se redactan para el cliente y los contratistas administradores quienes no tienen un conocimiento tcnico detallado del sistema.
REQUERIMIENTOS
La especificacin de requerimientos del sistema se orienta al personal tcnico y a los administradores del proyecto. Tambin lo utilizar tanto el equipo del cliente como el del contratista.
REQUERIMIENTOS
Los usuarios finales del sistema pueden leer ambos documentos.
REQUERIMIENTOS
La especificacin del diseo del software es un documento orientado a la implementacin. Debe redactarse para los ingenieros de software que desarrollarn el sistema.
REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

Frecuentemente, los requerimientos de sistemas de software se clasifican en funcionales y no funcionales o como requerimientos del dominio:
Requerimientos funcionales
Son declaraciones de los servicios que proveer el sistema, de la manera en que ste reaccionar a entradas particulares y de cmo se comportar en situaciones particulares.
Requerimientos funcionales
En algunos casos, los requerimientos funcionales de los sistemas tambin declaran explcitamente lo que el sistema no debe hacer.
Requerimientos no funcionales
Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo estndares, etc.
Requerimientos del dominio

Son requerimientos que provienen del dominio de aplicacin del sistema y que reflejan las caractersticas de ese dominio. Estos pueden ser funcionales o no funcionales.
REQURIMIENTOS FUNCIONALES Y NO FUNCIONALES

Realmente, la distincin entre estos dos tipos diferentes de requerimientos no es tan clara como las definiciones anteriores. Por ejemplo, un requerimiento del usuario sobre seguridad podra parecer uno no funcional

Sin embargo, cuando se desarrolla en detalle, conduce a otros que son claramente funcionales, como la necesidad de incluir en el sistema los recursos para la autorizacin del usuario.

Por lo tanto, aunque en la discusin sea de utilidad clasificar de esta forma los requerimientos, debe recordar que en la realidad es una distincin artificial.
REQUERIMIENTOS FUNCIONALES
Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera que este proveer. Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software.
REQUERIMIENTOS FUNCIONALES
Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma general mientras que los requerimientos funcionales del sistema describen con detalle la funcin de ste, sus entradas y salidas, excepciones, etc.
REQUERIMIENTOS NO FUNCIONALES
stos como su nombre sugiere, son aquellos requerimientos que no se refieren directamente a las funciones especficas que entrega el sistema, sino a las propiedades emergentes de ste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento
REQUERIMIENTOS NO FUNCIONALES
De esta forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la representacin de datos que se utiliza en las interfaces del sistema.
REQUERIMIENTOS DEL USUARIO

Los requerimientos del usuario para un sistema describen los requerimientos funcionales y no funcionales de tal forma que sean comprensibles por los usuarios del sistema que no posean un conocimiento tcnico detallado

nicamente especifican el comportamiento externo del sistema y evitan, tanto como sea posible, las caractersticas de diseo del sistema.

Por consiguiente, los requerimientos del usuario se deben definir utilizando el lenguaje natural, representaciones y diagramas intuitivos sencillos.

No obstante, pueden surgir algunos problemas cuando se redactan en lenguaje natural:

Falta de claridad Algunas veces es difcil utilizar el lenguaje en forma precisa y no ambigua sin detallar el documento y hacerlo difcil de leer.

Confusin de requerimientos No se distinguen claramente los requerimientos funcionales y no funcionales, las metas del sistema y la informacin para el diseo.

Conjunto de requerimientos Diversos requerimientos diferentes se expresan de forma conjunta como un nico requerimiento.

Para ilustrar alguno de estos problemas, considere uno de los requerimientos para un entorno de programacin Ada como se ve a continuacin:
Un requerimiento de una base de datos para un entorno de programacin:
La base de datos deber ayudar a la generacin y control de la configuracin de objetos; es decir, objetos que a su vez son agrupaciones de otros de la base de datos. Los recursos para este control permitirn el acceso a los objetos en una versin de grupo utilizando un nombre incompleto
REQUERIMIENTOS
Este requerimiento incluye tanto informacin conceptual como detallada. Expresa la existencia de recursos de control de la configuracin como una parte inherente del APSE.
REQUERIMIENTOS
Sin embargo, esta tambin incluye el detalle de que los recursos de control de la configuracin que permiten el acceso a los objetos en una versin de grupo sin especificar y su nombre completo
REQUERIMIENTOS
. Este detalle podra ubicarse mejor en la especificacin de requerimientos del sistema.
REQUERIMIENTOS
En el documento de requerimientos es una buena prctica separar los requerimientos del usuario de los detallados del sistema. Por otra parte, los lectores no tcnicos de los requerimientos del usuario se confundirn con los detalles que slo son relevantes a los lectores tcnicos.
REQUERIMIENTOS
La siguiente figura ilustra esta confusin.
Un requerimiento de usuario para un editor de cuadrcula
Recursos de la cuadrcula para ayudar a la ubicacin de entidades en un diagrama, el usuario activar una cuadrcula en centmetros o en pulgadas, mediante una opcin en el panel de control. De forma inicial, dicha cuadrcula estar desactivada. Esta cuadrcula se podr activar o desactivar en cualquier momento durante una sesin de edicin y puesta en pulgadas y centmetros. La opcin de cuadrcula se proveer en la vista de reduccin de ajuste, pero el nmero de lneas de la cuadrcula a mostrar se reducir para evitar saturar el diagrama ms pequeo con lneas de cuadrcula
4 MODELADO DE ANLISIS
Principios del anlisis.
Existen diferentes mtodos de anlisis sin embargo, todos se relacionan por un conjunto de principios operativos:
PRINCIPIOS OPERATIVOS
Debe representarse y entender el dominio de informacin un problema. Deben definirse las funciones que debe realizar el software. Debe representarse el comportamiento del software (como consecuencia de acontecimientos externos).
Deben dividirse los modelos que representan informacin, funcin y comportamiento de manera que se descubran los detalles por capas (o jerrquicamente). El proceso de anlisis debera ir desde la informacin esencial hasta el detalle de la implementacin.
Aplicando estos principios, el analista se aproxima al problema sistemticamente. Se examina el dominio de informacin de manera que pueda entenderse completamente la funcin. Se emplean modelos para poder comunicar de forma compacta las caractersticas de la funcin y su comportamiento
Se aplica la particin para reducir la complejidad. Son necesarias las visiones esenciales y de implementacin del software para acomodar las restricciones lgicas impuestas por los requisitos del procesamiento y las restricciones fsicas impuestas por otros elementos del sistema.
Adems de los principios operativos de anlisis anteriores, se sugiere un conjunto de principios directrices para la ingeniera de requisitos
PRINCIPIOS DIRECTRICES
Entender el problema antes de empezar a crear el modelo de anlisis. Hay tendencia a precipitarse en busca de una solucin, incluso ates de entender el problema. Esto lleva a menudo a un elegante software para el problema equivocado.
Desarrollar prototipos que permitan al usuario entender cmo ser la interaccin hombre-mquina. Como el concepto de calidad del software se basa a menudo en la opinin sobre la ambigedad de la interfaz, el desarrollo de prototipos (y la iteracin que se produce es altamente recomendable.
Registrar el origen y la razn de cada requisito. Este es el primer paso para establecer un seguimiento hasta el cliente.
Usar mltiples planteamientos de requisitos. La construccin de modelos de datos, funcionales y de comportamiento, le proporcionan al ingeniero de software tres puntos de vista diferentes.
Esto reduce la probabilidad de que se olvide algo y aumenta la probabilidad de reconocer la falta de consistencia.
Dar prioridad a los requisitos. Las fechas ajustadas de entrega pueden impedir la implementacin de todos los requisitos del software.
Trabajar para eliminar la ambigedad. Como la mayora de los requisitos estn descritos en un lenguaje natural, abunda la oportunidad de ambigedades. El empleo de revisiones tcnicas formales es una manera de descubrir y eliminar la ambigedad.
MODELADO
Los modelos se crean para entender mejor la entidad que se va a construir. Cuando la entidad es algo fsico (un auto, una casa, una mquina), podemos construir un modelo idntico en forma, pero ms pequeo
MODELADO
Sin embargo, cuando la entidad que se va a construir es software, nuestro modelo debe tomar una forma diferente. Debe ser capaz de modelar la informacin que transforma el software,
MODELADO
las funciones y (subfunciones) que permiten que ocurran las transformaciones y el comportamiento del sistema cuando ocurren estas transformaciones.
MODELADO
El segundo y tercer principios operativos del anlisis requieren la construccin de modelos de funcin y comportamiento.
Modelos funcionales
El software transforma la informacin y, para hacerlo, debe realizar al menos tres funciones genricas: entrada, procesamiento y salida.
Modelos funcionales
Cuando se crean modelos funcionales de una aplicacin, el ingeniero de software se concentra en funciones especficas del problema.
Modelos funcionales
El modelo funcional empieza con un sencillo modelo a nivel de contexto (por ejemplo, el nombre del software que se va a construir).
Modelos funcionales
Despus de una serie de iteraciones, se consiguen ms y ms detalles funcionales, hasta que se consigue representar una minuciosa definicin de toda la funcionalidad del sistema.
Modelos de comportamiento
La mayora del software responde a los acontecimientos del mundo exterior. Esta caracterstica estmulo-respuesta forma la base del modelo del comportamiento.
Un programa de computadora siempre se encuentra en un estado, un modo de comportamiento observable exteriormente (por ejemplo, esperando, calculando, imprimiendo, haciendo cola) que cambia slo cuando ocurre algn suceso.
Por ejemplo, el software permanecer en el estado de espera hasta que (1) un reloj interno le indique que ha pasado cierto intervalo de tiempo,
(2) un suceso externo (por ejemplo un movimiento del ratn) provoca una interrupcin, o (3) un sistema externo seala al software que acte de alguna manera.
Un modelo de comportamiento crea una representacin de los estados de software y los sucesos que causan que cambie de estado.
Los modelos creados durante el anlisis de requisitos desempean papeles muy importantes:
o El modelo ayuda al analista a entender la informacin, la funcin y el comportamiento del sistema, haciendo por tanto ms fcil y sistemtica la tarea de anlisis de requisitos.
o EL modelo se convierte en el punto de mira para la revisin y por tanto la clave para determinar si se ha completado, su consistencia y la precisin de la especificacin.
o El modelo se convierte en el fundamento para el diseo, proporcionando al diseador una representacin esencial del software que pueda trasladarse al contexto de la implementacin.
Enfoque utilizado de la creacin de prototipos

El paradigma de creacin de prototipos puede ser cerrado o abierto. El enfoque cerrado se denomina a menudo prototipo desechable.

Este prototipo sirve nicamente como una basta demostracin de los requisitos. Despus se desecha y se hace una ingeniera de software con un paradigma diferente

Un enfoque abierto, denominado prototipo evolutivo, emplea el prototipo como primera parte de una actividad de anlisis a la que seguir el diseo y la construccin.

El prototipo del software es la primera evolucin del sistema terminado.

Antes de poder elegir un enfoque abierto o cerrado, es necesario determinar si se puede crear un prototipo del sistema a construir. Se pueden definir varios factores candidatos a la creacin de prototipos:

rea de aplicacin, complejidad, caractersticas del cliente y del proyecto.

En general, cualquier aplicacin que cree pantallas visuales dinmicas, interacte intensamente con el ser humano, o demande algoritmos o procesamiento de combinaciones que deban crearse de manera progresiva, es un buen candidato para la creacin de un prototipo.

Sin embargo, estas reas de aplicacin deben ponderarse con la complejidad de la aplicacin.

Si una aplicacin candidata (con las caractersticas mencionadas anteriormente) va a requerir el desarrollo de decenas de miles de lneas de cdigo antes de poder realizar cualquier funcin demostrable, es muy probable que sea demasiado compleja para crear un prototipo.

Si se puede hacer una particin a su complejidad, puede ser posible crear prototipos de porciones del software

Como el cliente debe interactuar con el prototipo en fases posteriores, es esencial que:

(1) se destinen recursos del cliente a la evaluacin y refinamiento del prototipo, y (2) el cliente sea capaz de tomar decisiones inmediatas sobre los requisitos.

Finalmente, la naturaleza del proyecto de desarrollo tendr una gran influencia en la capacidad de crear un prototipo

Desea y es capaz la gestin del proyecto de trabajar con el mtodo del prototipo? Tenemos disponibles herramientas para la creacin de prototipos?

Tienen experiencia los desarrolladores con los mtodos de creacin de prototipos?

Se sugieren un conjunto de preguntas e indica unos conjuntos bsicos de respuestas con su correspondiente tipo de prototipo sugerido.

Pregunta Prototipo Desechable Prototipo evolutivo Trabajo preliminar Adicional requerido Se entiende el dominio de la aplicacin? Se puede modelar el problema? Est el cliente Suficientemente seguro de los requisitos bsicos del sistema?
Si
Si
No
Si
Si
No
Si/No
Si/No
No
Estn establecidos Los requisitos y Son estables?

Hay requisitos ambiguos? Hay contradicciones en los requisitos?
No
Si
Si
Si Si
No No
Si Si
MODELADO DE ANLISIS
En un nivel tcnico, la ingeniera de software empieza con una serie de tareas de modelado que llevan a una especificacin completa de los requisitos y a una representacin del diseo general del software a construir.
MODELADO DE ANLISIS
El modelo de anlisis, realmente un conjunto de modelos, es la primera representacin tcnica de un sistema. Se han propuesto muchos mtodos para el modelado del anlisis
MODELADO DE ANLISIS
. Sin embargo dos tendencias dominan el panorama del modelado del anlisis. El primero, anlisis estructurado, es un mtodo de modelado clsico. El otro enfoque, anlisis orientado a objetos.
ELEMENTOS DE DEL MODELO DE ANLISIS

El modelo de anlisis debe lograr tres objetivos primarios: (1) describir lo que requiere el cliente, (2) establecer una base para la creacin de un diseo de software, y

(3) definir un conjunto de requisitos que se pueda validar una vez que se construye el software. Para lograr estos objetivos, el modelo de anlisis extrado durante el anlisis estructurado toma la forma estructurado toma la forma ilustrada en la figura.

En el centro del modelo se encuentra el diccionario de datos- un almacn que contiene definiciones de todos los objetos de datos consumidos y producidos por el software.

Tres diagramas diferentes rodean el ncleo. El diagrama de entidad relacin (DER) representa las relaciones entre los objetos del dato

Ingenieria de Software

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Ingenieria de Software

Diunggah oleh

Hak Cipta:

Format Tersedia

INTRODUCCIN A LA INGENIERA DE SOFTWARE

Atributos de un buen sistema de software

Atributos de un buen sistema de software

Atributos de un buen sistema de software

Atributos de un buen sistema de software

Atributos de un buen sistema de software

FACTORES QUE AFECTAN A LA CALIDAD

FACTORES QUE AFECTAN A LA CALIDAD

Anlisis de requerimientos Diseo Del Sistema Diseo Del Programa Codificacin

Prueba Del Sistema Prueba De Aceptacin

REQUERIMIENTOS DEL SOFTWARE

IDENTIFICACIN DE LOS REQUERIMIENTOS DEL SOFTWARE

IDENTIFICACIN DE LOS REQUERIMIENTOS DEL SOFTWARE

Proceso de obtencin de los requerimientos del software

Proceso de obtencin de los requerimientos del software

Proceso de obtencin de los requerimientos del software

PREGUNTAS DE CONTEXTO LIBRE

PREGUNTAS DE CONTEXTO LIBRE

PREGUNTAS DE CONTEXTO LIBRE

PREGUNTAS DE CONTEXTO LIBRE

PREGUNTAS DE CONTEXTO LIBRE

PREGUNTAS DE CONTEXTO LIBRE

PREGUNTAS DE CONTEXTO LIBRE

PREGUNTAS DE CONTEXTO LIBRE

PREGUNTAS DE CONTEXTO LIBRE

PREGUNTAS DE CONTEXTO LIBRE

Tcnicas para la obtencin de las especificaciones de una aplicacin

Tcnicas para la obtencin de las especificaciones de una aplicacin

Tcnicas para la obtencin de las especificaciones de una aplicacin

Tcnicas para la obtencin de las especificaciones de una aplicacin

Tcnicas para la obtencin de las especificaciones de una aplicacin

Tcnicas para la obtencin de las especificaciones de una aplicacin

TECNICAS PARA FACILITAR LAS ESPECIFICACIONES DE LA APLICACIN

TECNICAS PARA FACILITAR LAS ESPECIFICACIONES DE LA APLICACIN

TECNICAS PARA FACILITAR LAS ESPECIFICACIONES DE LA APLICACIN

Definicin de requerimientos del usuario

Figura 3.1 Requerimientos del usuario y del sistema

REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

Requerimientos del dominio

REQURIMIENTOS FUNCIONALES Y NO FUNCIONALES

REQURIMIENTOS FUNCIONALES Y NO FUNCIONALES

REQURIMIENTOS FUNCIONALES Y NO FUNCIONALES

REQUERIMIENTOS DEL USUARIO

REQUERIMIENTOS DEL USUARIO

REQUERIMIENTOS DEL USUARIO

REQUERIMIENTOS DEL USUARIO

REQUERIMIENTOS DEL USUARIO

REQUERIMIENTOS DEL USUARIO

REQUERIMIENTOS DEL USUARIO

REQUERIMIENTOS DEL USUARIO

Un requerimiento de una base de datos para un entorno de programacin:

Un requerimiento de usuario para un editor de cuadrcula

Enfoque utilizado de la creacin de prototipos

Enfoque utilizado de la creacin de prototipos

Enfoque utilizado de la creacin de prototipos

Enfoque utilizado de la creacin de prototipos

Enfoque utilizado de la creacin de prototipos

Enfoque utilizado de la creacin de prototipos

Enfoque utilizado de la creacin de prototipos

Enfoque utilizado de la creacin de prototipos

Enfoque utilizado de la creacin de prototipos

Enfoque utilizado de la creacin de prototipos

Enfoque utilizado de la creacin de prototipos

Enfoque utilizado de la creacin de prototipos