Repblica Bolivariana de Venezuela

Ministerio del Poder Popular para la Educacin Universitaria

Instituto Universitario Politcnico Santiago Mario
Extensin Puerto Ordaz
Escuela de Ingeniera de Sistemas
Profesor(a): Ing. Richard Rodrguez Alumno:
Noel Prez C.I: V-21.124.293
Ciudad Guayana, Enero del 2013
Introduccin
En la ingeniera de sistemas y la ingeniera de software, la Ingeniera
de requisitos o Ingeniera de requerimientos1 comprende todas las tareas
relacionadas con la determinacin de las necesidades o de las condiciones a
satisfacer para un software nuevo o modificado, tomando en cuenta los
diversos requisitos de los inversores, que pueden entrar en conflicto entre
ellos.
Muchas veces se habla de requerimientos en vez de requisitos; esto
se debe a una mala traduccin del ingls. La palabra requirement debe ser
traducida como requisito, mientras que requerimiento se traduce al ingls
como request.
El propsito de la ingeniera de requisitos es hacer que los mismos
alcancen un estado ptimo antes de alcanzar la fase de diseo en el
proyecto. Los buenos requisitos deben ser medibles, comprobables, sin
ambigedades o contradicciones, etc.
Anlisis y Diseo Orientado a Objetos
Es un mtodo de anlisis que examina los requisitos desde la
perspectiva de las clases y objetos que se encuentran en el vocabulario del
dominio del problema.
El Anlisis orientado a objetos ofrece un enfoque nuevo para el
anlisis de requisitos de sistemas software. En lugar de considerar el
software desde una perspectiva clsica de entrada/proceso/salida, como los
mtodos estructurados clsicos, se basa en modelar el sistema mediante los
objetos que forman parte de l y las relaciones estticas (herencia y
composicin) o dinmicas (uso) entre estos objetos.
El uso de Anlisis orientado a objetos puede facilitar mucho la
creacin de prototipos, y las tcnicas de desarrollo evolutivo de software. Los
objetos son inherentemente reutilizables, y se puede crear un catlogo de
objetos que podemos usar en sucesivas aplicaciones. De esta forma,
podemos obtener rpidamente un prototipo del sistema, que pueda ser
evaluado por el cliente, a partir de objetos analizados, diseados e
implementados en aplicaciones anteriores. Y lo que es ms importante, dada
la facilidad de reutilizacin de estos objetos, el prototipo puede ir
evolucionando hacia convertirse en el sistema final, segn vamos refinando
los objetos de acuerdo a un proceso de especificacin incremental.
Anlisis de requisitos del software
La ingeniera de requisitos del software es un proceso de
descubrimiento, refinamiento, modelado y especificacin. Se refinan en
detalle los requisitos del sistema y el papel asignado al software.
Tanto el desarrollador como el cliente tienen un papel activo en la
ingeniera de requisitos un conjunto de actividades que son denominadas
anlisis El cliente intenta replantear un sistema confuso, a nivel de
descripcin de datos, funciones y comportamiento, en detalles concretos. El
desarrollador acta como interrogador, como consultor, como persona que
resuelve problemas y como negociador.
El anlisis y la especificacin de requisitos pueden parecer una tarea
relativamente sencilla, pero las apariencias engaan. El contenido de
comunicacin es muy denso. Abundan las ocasiones para malas
interpretaciones o falta de informacin. Es muy probable que haya
ambigedad. El dilema al que se enfrenta el ingeniero de software puede
entenderse muy bien repitiendo la famosa frase de un cliente annimo: S
que cree que entendi lo que piensa que dije, pero no estoy seguro de que
se d cuenta de que lo que escuch no es lo que yo quise decir.
El anlisis de requisitos es una tarea de ingeniera del software que
cubre el hueco entre la definicin del software a nivel sistema y el diseo de
software. El anlisis de requerimientos permite al ingeniero de sistemas
especificar las caractersticas operacionales del software (funcin, datos y
rendimientos), indica la interfaz del software con otros elementos del sistema
y establece las restricciones que debe cumplir el software.
Tareas de Anlisis
El anlisis de requisitos del software se puede subdividir en cinco
reas de esfuerzo:
Reconocimiento del problema
Evaluacin y sntesis
Modelado
Especificacin
Revisin
Todos los mtodos de anlisis se relacionan por un conjunto de
principios operativos:
Debe representarse y entenderse el dominio de la informacin de 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.
Adems de los principios operativos mencionados anteriormente, se
sugiere un conjunto de principios directrices para la ingeniera de
requerimientos:
Entender el problema antes de empezar a crear el modelo de anlisis.
Desarrollar prototipos que permitan al usuario entender como ser la
interaccin hombre-mquina.
Registrar el orden y la razn de cada requerimiento,
Usar mltiples planteamientos de requerimientos.
Priorizar los requerimientos.
Trabajar para eliminar la ambigedad.
Un ingeniero de software que se apegue a estos principios es muy
probable que desarrolle una especificacin de software que represente un
excelente fundamento para el diseo.
Mtodos de Anlisis Orientados al Flujo de Datos
La informacin se transforma como un flujo a travs de un sistema
basado en computadora. El sistema acepta entrada de distintas formas;
aplica un hardware, software y elementos humanos para transformar la
entrada en salida; y produce una salida en distintas formas. La entrada
puede ser una seal de control transmitida por un transductor, una serie de
nmeros escritos por un operador humano, un paquete de informacin
transmitido por un enlace a red, o un voluminoso archivo de datos
almacenado en memoria secundaria. La transformacin puede comprender
una sencilla comparacin lgica, un complejo algoritmo numrico, o un
mtodo de inferencia basado en regla de un sistema experto. La salida
puede encender un sencillo led o producir un informe de 200 pginas. En
efecto, un modelo de flujo de datos puede aplicarse a cualquier sistema
basado en computadora independientemente del tamao o complejidad.
Diagramas de Flujos de Datos
Conforme con la informacin se mueve a travs del software, se
modifica mediante una serie de transformaciones. Un diagrama de flujos de
datos (DFD), es una tcnica grafica que describe el flujo de informacin y las
transformaciones que se aplican a los datos, conforme se mueven de la
entrada a la salida.
Diccionario de Datos
Un anlisis del dominio de la informacin puede ser incompleto si solo
se considera el flujo de datos.
Cada flecha de un diagrama de flujo de datos representa uno o ms
elementos de informacin. Por tanto, el analista debe disponer de algn otro
mtodo para representar el contenido de cada flecha de un DFD. Se ha
propuesto el diccionario de datos como una gramtica casi formal para
describir el contenido de los elementos de informacin y ha sido definido da
la siguiente forma:
El diccionario de datos contiene las definiciones de todos los datos
mencionados en el DFD, en una especificacin del proceso y en el propio
diccionario de datos. Los datos compuestos (datos que pueden ser adems
divididos) se definen en trminos de sus componentes; los datos elementales
(datos que no pueden ser divididos) se definen en trminos del significado de
cada uno de los valores que puede asumir. Por tanto, el diccionario de datos
esta compuesto de definiciones de flujo de datos, archivos [datos
almacenados] y datos usados en los procesos [transformaciones]
Desarrollo del Sistema Jackson
Desarrollo del sistema de Jackson ( JSD ) es un lineal metodologa de
desarrollo de software desarrollado por Michael A. Jackson y John Cameron
en la dcada de 1980.
Principios de funcionamiento
Tres principios bsicos del funcionamiento de JSD es que:
1. El desarrollo debe comenzar con la descripcin y el modelado del
mundo real, en lugar de especificar o la estructuracin de la funcin
realizada por el sistema. Un sistema realizado utilizando el mtodo de
JSD realiza la simulacin del mundo real antes de que se le prest
atencin directa a la funcin o propsito del sistema.
2. Un modelo adecuado de un mundo ordenado por tiempo en s mismo
debe ser ordenado por tiempo. El principal objetivo es mapear el
progreso en el mundo real sobre los avances en el sistema que
modela.
3. La manera de aplicar el sistema se basa en la transformacin de
especificacin en conjunto eficiente de los procesos. Estos procesos
deben ser diseados de tal manera que sera posible ejecutar en
software y hardware disponible.
Etapa de modelado
En la etapa de modelado el diseador crea una coleccin de
diagramas de estructura de la entidad y se identifican las entidades en el
sistema, las acciones que realizan, el tiempo-orden de las acciones en la
vida de las entidades y los atributos de las acciones y entidades. Estructura
de la entidad diagramas utilizan la notacin de diagramas de Jackson
Programacin Estructurada diagramas de estructura . Propsito de estos
diagramas es crear una descripcin completa de los aspectos del sistema y
de la organizacin. Los desarrolladores tienen que decidir qu cosas son
importantes y cules no lo son. La buena comunicacin entre los
desarrolladores y los usuarios del nuevo sistema es muy importante.
Esta etapa es la combinacin de la etapa anterior entidad / accin y el
paso de las estructuras de entidad.
Etapa Red
En la fase de red de un modelo del sistema como un todo se
desarrolla y se representa como un diagrama de especificacin del sistema
(SSD) (tambin conocido como un diagrama de la red ). Diagramas de red
muestran procesos (rectngulos) y la forma en que se comunican entre s, ya
sea a travs del vector de estado de conexiones (de diamantes) o por medio
de flujo de datos en las conexiones (crculos). En esta etapa es la
funcionalidad del sistema definido. Cada entidad se convierte en un proceso
o programa en el diagrama de red. Programas externos posteriormente, se
agregan a los diagramas de red. El propsito de estos programas es el de
procesar la entrada, calcular la produccin y mantener los procesos de la
entidad hasta a la fecha. Todo el sistema se describe con estos diagramas
de red y se completan con las descripciones acerca de los datos y las
conexiones entre los procesos y programas.
El paso inicial del modelo especifica una simulacin del mundo real. El
paso funcin aade a esta simulacin las operaciones y procesos
ejecutables adicionales necesarias para producir una salida del sistema.
Paso el tiempo del sistema proporciona la sincronizacin entre procesos,
presenta limitaciones. Esta etapa es la combinacin de la primera etapa
"modelo inicial", el paso de la "funcin" y el "sistema de temporizacin paso.
Etapa de implementacin
En la etapa de implementacin del modelo de red abstracto de la
solucin se convierte en un sistema fsico, representado como un diagrama
de implementacin del sistema (SID). El SID muestra el sistema como un
planificador de proceso que llama mdulos que implementan los procesos.
Datastreams se representan como llamadas a procesos invertidos. Smbolos
de bases de datos representan colecciones de entidades estatales-vectores,
y hay smbolos especiales para los archivos de memoria intermedia (que
deben aplicarse cuando los procesos estn programados para ejecutarse en
diferentes intervalos de tiempo).
La preocupacin central de paso es la aplicacin de optimizacin del
sistema. Es necesario reducir el nmero de procesos, ya que es imposible
proporcionar cada proceso que est contenida en la especificacin con su
propio procesador virtual. Por medio de la transformacin, los procesos se
combinan con el fin de los lmites de sus miembros para que el nmero de
procesadores.
Fundamentos de la Programacin Orientada a Objetos
Objeto
Entidad que contiene los atributos que describen el estado de un
objeto del mundo real y las acciones que se asocian con el objeto del mundo
real.
Un objeto es designado con un nombre o un identificador.
Abstraccin
Es el principio de ignorar aquellos aspectos de un fenmeno
observado que no son relevantes, con el objetivo de concentrarse en
aquellos que si lo son.
Encapsulamiento
Es la propiedad del POO que permite ocultar al mundo exterior la
representacin interna del objeto. Esto quiere decir que el objeto puede ser
utilizado, pero los datos esenciales del mismo no son conocidos fuera de l.
La idea central del encapsulamiento es esconder los detalles y mostrar
lo relevante. Permite el ocultamiento de la informacin separando el aspecto
correspondiente a la especificacin de la implementacin; de esta forma,
distingue el "qu hacer" del "cmo hacer". La especificacin es visible al
usuario, mientras que la implementacin se le oculta.
Modularidad
Es la propiedad que permite tener independencia entre las diferentes
partes de un sistema.
La modularidad consiste en dividir un programa en mdulos o partes,
que pueden ser compilados separadamente, pero que tienen conexiones
con otros mdulos. En un mismo mdulo se suele colocar clases y objetos
que guarden una estrecha relacin.
Jerarqua / Herencia
Es el proceso mediante el cual un objeto de una clase adquiere
propiedades definidas en otra clase que lo preceda en una jerarqua de
clasificaciones. Permite la definicin de un nuevo objeto a partir de otros,
agregando las diferencias entre ellos (Programacin Diferencial), evitando
repeticin de cdigo y permitiendo la reusabilidad.
Polimorfismo
Es una propiedad del POO que permite que un mtodo tenga mltiples
implementaciones, que se seleccionan en base al tipo objeto indicado al
solicitar la ejecucin del mtodo.
Concurrencia
La concurrencia es la propiedad que distingue un objeto activo de uno
que no est activo.
Se implementa mediante el proceso de creacin o instanciacin de
objetos a partir de su clase y las propiedades de identidad y estado de los
objetos.
Persistencia
La persistencia es la propiedad de un objeto mediante la cual su
existencia perdura en el tiempo y/o espacio.
Se implementa mediante los procesos de construccin y destruccin
de los objetos definidos como parte del comportamiento de la clase.
Garantas de calidad del software
Es una disciplina de la ingeniera de software se especializa en la
aplicacin de procesos de calidad a lo largo del proyecto de software.
Su misin no se limita a actividades de verificacin, sino que adems
asume un rol de liderazgo en la gestin de la calidad durante el proceso de
creacin y diseo del producto. La garanta de calidad no debe confundirse
con la tcnica especfica de control de calidad, cuyo objetivo es verificar el
producto.
Una concepcin errnea que an persiste en la industria, es limitar su
accin al aseguramiento de la calidad del producto y a constatar adherencia
a estndares.
La garanta de calidad toma responsabilidad por los siguientes procesos:
1. gestin de los procesos de ingeniera de software
2. iniciativas de mejoramiento de procesos a lo largo de la
organizacin,
3. integracin de los procesos de calidad de ingeniera y servicios a la
clientela
El liderazgo de la garanta de calidad puede ser asumida en
organizaciones pequeas o muy jvenes por el jefe del proyecto, siendo el
grupo de desarrollo el responsable de su ejecucin. Estos individuos pueden
provenir de organizaciones ms maduras donde hayan adquirido el "know-
how" en procesos de calidad, o pueden hacerse asesorar por consultores
externos que los ayuden a definir sus sistema de calidad.
La garanta de calidad se asegura de lo siguiente:
Se usa la metodologa de desarrollo apropiada
Las actividades de desarrollo han sido debidamente planeadas
Se han definido estndares y procedimientos para al proyecto
El personal ha sido debidamente entrenado en los procesos de
calidad aplicables
Se llevan a cabo regularmente revisiones y auditoras independientes
El desarrollo es documentado adecuadamente para facilitar la
mantencin y la reutilizacin
La documentacin se produce oportunamente y no despus que el
desarrollo ha sido completado
Los cambios introducidos han sido debidamente controlados
Las pruebas efectuadas son eficaces para detectar defectos,
especialmente en aquellas reas de mayor riesgo
Las actividades se llevan a cabo de acuerdo a los plazos y en los
trminos planeados
Las desviaciones a los estndares se identifican rpidamente
El proyecto est en condiciones para ser sometido a auditoras
externas, si corresponde
La calidad es verificada con respecto a criterios preestablecidos
La gerencia es oportunamente informada de problemas y riesgos
relativos a la calidad
Los problemas de calidad se analizan y las causas se comunican al
proyecto para tomar medidas preventivas que eviten su repeticin
Tcnicas de Pruebas del Software
Las pruebas de software (en ingls software testing) son las
investigaciones empricas y tcnicas cuyo objetivo es proporcionar
informacin objetiva e independiente sobre la calidad del producto a la parte
interesada o stakeholder. Es una actividad ms en el proceso de control de
calidad.
Las pruebas son bsicamente un conjunto de actividades dentro del
desarrollo de software. Dependiendo del tipo de pruebas, estas actividades
podrn ser implementadas en cualquier momento de dicho proceso de
desarrollo. Existen distintos modelos de desarrollo de software, as como
modelos de pruebas. A cada uno corresponde una nivel distinto de
involucramiento en las actividades de desarrollo.
Pruebas estticas
Son el tipo de pruebas que se realizan sin ejecutar el cdigo de la
aplicacin (Ceferino).
Puede referirse a la revisin de documentos, ya que no se hace una
ejecucin de cdigo. Esto se debe a que se pueden realizar pruebas de
escritorio con el objetivo de seguir los flujos de la aplicacin.
Pruebas Dinmicas
Todas aquellas pruebas que para su ejecucin requieren la ejecucin
de la aplicacin.
Las pruebas dinmicas permiten el uso de tcnicas de caja negra y
caja blanca con mayor amplitud. Debido a la naturaleza dinmica de la
ejecucin de pruebas es posible medir con mayor precisin el
comportamiento de la aplicacin desarrollada.
Mantenimiento de Software
El Servicio de mantenimiento de software es una de las actividades en
la Ingeniera de Software y es el proceso de mejorar y optimizar el software
desplegado (revisin del programa), as como tambin remediar los defectos.
El mantenimiento de software es tambin una de las fases en el Ciclo
de Vida de Desarrollo de Sistemas (SDLC System Development Life
Cycle), que se aplica al desarrollo de software. La fase de mantenimiento es
la fase que viene despus del despliegue (implementacin) del software en el
campo.
La fase de mantenimiento de software involucra cambios al software
en orden de corregir defectos y dependencias encontradas durante su uso
tanto como la adicin de nueva funcionalidad para mejorar la usabilidad y
aplicabilidad del software
Tipos de mantenimiento
A continuacin se sealan los tipos servicio de mantenimientos
existentes, y entre parntesis el porcentaje aproximado respecto al total de
operaciones de mantenimiento:
Perfectivo: Mejora del software ( rendimiento , flexibilidad , reusabilidad ..) o
implementacin de nuevos requisitos. Tambin se conoce como
mantenimiento evolutivo .
Adaptativo: Adaptacin del software a cambios en su entorno tecnolgico
(nuevo hardware, otro sistema de gestin de bases de datos , otro sistema
operativo ...)
Correctivo: Correccin de fallos detectados durante la explotacin.
Preventivo: Facilitar el mantenimiento futuro del sistema (verificar
precondiciones, mejorar legibilidad...).
Conclusin
A pesar de la importancia que tiene la Ingeniera de Requerimientos,
ha costado mucho que se le preste la atencin adecuada a esta actividad.
An quedan muchos desafos que deben ser mejorados, tales como la
integracin de requerimientos funcionales y no funcionales, la evaluacin de
especificaciones alternativas, la formalizacin de la SRS, entre otras.
Cada actividad y tcnica de la IR utilizada individualmente, dar
diferentes soluciones para diferentes proyectos, incluyendo aquellos casos
en los que el dominio y el rea del problema son el mismo. Por esta razn,
considero que no existe un modelo de proceso ideal para la IR; encontrar el
mtodo o la tcnica perfecta es una ilusin, pues cada mtodo y tcnica
ofrece diferentes soluciones ante un problema.
En esta investigacin se presentaron una serie de actividades y
tcnicas, que no pertenecen a un modelo de proceso en s, sino, que son
una alternativa al material publicado por diferentes autores y que, desde mi
punto de vista, son las ms importantes.
Debemos recordar que la Ingeniera de Requerimientos es una
actividad que involucra a clientes, usuarios, equipo de desarrollo,
administradores de proyectos, etc.; por lo tanto, el proceso de IR no depende
solamente de la forma en cmo se percibe el problema, sino tambin, del
nivel de experiencia que tengan los involucrados.