UNIVERSIDAD TECNOLGICA DE LA REGIN NORTE DE

GURRERO
UNIDAD ACADMICA DE LA REGIN MONTAA

MATERIA:
OPTATIVA II
CARRERA:
INGENIERA EN TECNOLOGAS DE LA INFORMACIN

Cuatrimestre: 9 (Mayo - Agosto) Grupo: B

PROFESOR:
FIDENCIO MENESES GARCIA
ELABORADO POR:
CARLOS MANUEL BARRERA IXTLAHUAC

Chilapa de lvarez Gro, junio de 2016

Contenido
Unidad I. Introduccin a la ingeniera de software..........................................................3
Definicin de ingeniera de software y su importancia.................................................3
Ciclo de vida de un sistema software........................................................................4
Unidad II. Diagramas UML...................................................................................... 8
Introduccin a UML............................................................................................. 8
Diagramas.......................................................................................................... 8
Diagrama de objetos.......................................................................................... 8
Diagrama de casos de uso................................................................................... 9
Diagrama de estados......................................................................................... 9
Diagrama de secuencias................................................................................... 10
Diagrama de actividades.................................................................................. 10
Diagrama de colaboraciones............................................................................. 11
Diagrama de componentes................................................................................ 11
Unidad III. Ingeniera de requerimientos...................................................................12
Tcnicas para la obtencin de los requerimientos de un sistema..................................12
Entrevistas.................................................................................................... 12
Lluvia de ideas............................................................................................... 13
Especificacin de requisitos.................................................................................. 13

Introduccin

En el presente documento se describen los conceptos necesarios para poder realizar un

software, como algunos mtodos para obtener bien los requisitos, y despus realizar de la
mejor manera los diagramas UML, donde se describen cada uno de estos, y tener una
visualizacin ms cercana a lo que ser el sistema.

Unidad I. Introduccin a la ingeniera de software

Definicin de ingeniera de software y su importancia
La ingeniera de software es una disciplina formada por un conjunto de mtodos,
herramientas y tcnicas que se utilizan en el desarrollo de los programas informticos
(software).
Esta disciplina trasciende la actividad de programacin, que es el pilar fundamental a la
hora de crear una aplicacin. El ingeniero de software se encarga de toda la gestin del
proyecto para que ste se pueda desarrollar en un plazo determinado y con el presupuesto
previsto.
La ingeniera de software, por lo tanto, incluye el anlisis previo de la situacin, el diseo
del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto
funcionamiento y la implementacin del sistema.
Cabe destacar que el proceso de desarrollo de software implica lo que se conoce como ciclo
de vida del software, que est formado por cuatro etapas: concepcin, elaboracin,
construccin y transicin.
La concepcin fija el alcance del proyecto y desarrolla el modelo de negocio; la elaboracin
define el plan del proyecto, detalla las caractersticas y fundamenta la arquitectura; la
construccin es el desarrollo del producto; y la transicin es la transferencia del producto
terminado a los usuarios.
Una vez que se completa este ciclo, entra en juego el mantenimiento del software. Se trata
de una fase de esta ingeniera donde se solucionan los errores descubiertos (muchas veces
advertidos por los propios usuarios) y se incorporan actualizaciones para hacer frente a los
nuevos requisitos. El proceso de mantenimiento incorpora adems nuevos desarrollos, para
permitir que el software pueda cumplir con una mayor cantidad de tareas.
Un campo directamente relacionado con la ingeniera de software es la arquitectura de
sistemas, que consiste en determinar y esquematizar la estructura general del proyecto,
diagramando su esqueleto con un grado relativamente alto de especificidad y sealando los
distintos componentes que sern necesarios para llevar a cabo el desarrollo, tales como

aplicaciones complementarias y bases de datos. Se trata de un punto fundamental del

proceso, y es muchas veces la clave del xito de un producto informtico.
Ingeniera de software; Los avances tecnolgicos y su repercusin en la vida social han
afectado inevitablemente el proceso de desarrollo de software por diversos motivos, como
ser el acceso indiscriminado de los usuarios a cierta informacin que hasta hace un par de
dcadas desconoca por completo y que no pueden comprender, dado que no poseen el
grado de conocimiento tcnico necesario. Un consumidor bien informado es un consumidor
al que no se puede timar, ya que sabe lo que necesita y tiene la capacidad de analizar las
diferentes ofertas del mercado, comparando las propuestas y prestaciones de los productos;
sin embargo, un consumidor mal informado es como un nio caprichoso que llora, grita y
patalea sin parar.
La primera de todas las etapas del trabajo que realizan los ingenieros de software consiste
en estudiar minuciosamente las caractersticas que se creen necesarias para el programa a
desarrollar, y es ste el punto en el cual deben encontrar un equilibrio (cada vez ms difcil
de alcanzar) entre las demandas excesivas de los malos consumidores y las posibilidades de
la compaa. El tiempo es dinero, y las empresas del mundo informtico lo saben muy bien.
Cada funcin de un programa, cada rasgo que lo vuelva ms cmodo, ms inteligente, ms
accesible, se traduce en una cantidad determinada de tiempo, que a su vez acarrea los
sueldos de todas las personas involucradas en su desarrollo. Pero adems del costo de
produccin necesario para realizar cada una de las piezas de un programa, la ingeniera de
software debe decidir cules de ellas tienen sentido, son coherentes con el resto y son
necesarias para comunicar claramente la esencia y los objetivos de la aplicacin.
Ciclo de vida de un sistema software
El trmino ciclo de vida del software describe el desarrollo de software, desde la fase inicial
hasta la fase final. El propsito de este programa es definir las distintas fases intermedias
que se requieren para validar el desarrollo de la aplicacin, es decir, para garantizar que el
software cumpla los requisitos para la aplicacin y verificacin de los procedimientos de
desarrollo: se asegura de que los mtodos utilizados son apropiados.

Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se
detectan tarde dentro de la fase de implementacin. El ciclo de vida permite que los errores
se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la
calidad del software, en los plazos de implementacin y en los costos asociados.
El ciclo de vida bsico de un software consta de los siguientes procedimientos:
Definicin de objetivos: definir el resultado del proyecto y su papel en la estrategia global.
Anlisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del
cliente y examinar cualquier restriccin que se pueda aplicar.
Diseo general: requisitos generales de la arquitectura de la aplicacin.
Diseo en detalle: definicin precisa de cada subconjunto de la aplicacin.
Programacin (programacin e implementacin): es la implementacin de un lenguaje
de programacin para crear las funciones definidas durante la etapa de diseo.
Prueba de unidad: prueba individual de cada subconjunto de la aplicacin para garantizar
que se implementaron de acuerdo con las especificaciones.
Integracin: para garantizar que los diferentes mdulos se integren con la aplicacin. ste
es el propsito de la prueba de integracin que est cuidadosamente documentada.
Prueba beta (o validacin), para garantizar que el software cumple con las
especificaciones originales.
Documentacin: sirve para documentar informacin necesaria para los usuarios del
software y para desarrollos futuros.
Implementacin
Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y
las actualizaciones secundarias del software (mantenimiento continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una

aplicacin dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el
equipo de desarrolladores.
Modelos de ciclo de vida
Para facilitar una metodologa comn entre el cliente y la compaa de software, los
modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo
involucradas y la documentacin requerida, de manera que cada etapa se valide antes de
continuar con la siguiente etapa. Al final de cada etapa se arreglan las revisiones de manera
que (texto faltante).
Modelo en cascada
El modelo de ciclo de vida en cascada comenz a disearse en 1966 y se termin alrededor
de 1970. Se define como una secuencia de fases en la que al final de cada una de ellas se
rene la documentacin para garantizar que cumple las especificaciones y los requisitos
antes de pasar a la fase siguiente:

Ciclo de vida en cascada

Modelo V
El modelo de ciclo de vida V proviene del principio que establece que los procedimientos
utilizados para probar si la aplicacin cumple las especificaciones ya deben haberse creado
en la fase de diseo.

Unidad II. Diagramas UML

Introduccin a UML
Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML
ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos
conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos
como expresiones de lenguajes de programacin, esquemas de bases de datos y compuestos
reciclados.
Es importante remarcar que es un "lenguaje de modelado" para especificar o para describir
mtodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el
sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est
descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a
una metodologa de desarrollo de software (tal como el Proceso Unificado Racional
o RUP), pero no especifica en s mismo qu metodologa o proceso usar.
UML no puede compararse con la programacin estructurada, pues UML significa
Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad de una
utilizacin en un requerimiento. Mientras que, programacin estructurada, es una forma de
programar como lo es la orientacin a objetos, la programacin orientada a objetos viene
siendo un complemento perfecto de UML, pero no por eso se toma UML slo para
lenguajes orientados a objetos.
Est compuesto por diversos elementos grficos que se combinan para conformar
diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales
elementos.
La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales
se les conoce como modelo. Recordemos que un modelo es una representacin simplificada
de la realidad; el modelo UML describe lo que supuestamente har un sistema, pero no dice
cmo implementar dicho sistema.
Diagramas
Diagrama de objetos
Los Diagramas de Objetos estn vinculados con los Diagramas de Clases. Un objeto es una
instancia de una clase, por lo que un diagrama de objetos puede ser visto como una
instancia de un diagrama de clases. Los diagramas de objetos describen la estructura
esttica de un sistema en un momento particular y son usados para probar la precisin de
los diagramas de clases.

Diagrama de casos
de uso
Un caso de uso es una descripcin de las acciones de un sistema desde el punto de vista del
usuario. Es una herramienta valiosa dado que es una tcnica de aciertos y errores para
obtener los requerimientos del sistema, justamente desde el punto de vista del usuario. Los
diagramas de caso de uso modelan la funcionalidad del sistema usando actores y casos de
uso. Los casos de uso son servicios o funciones provistas por el sistema para sus usuarios.

Diagrama de estados
En cualquier momento, un objeto se encuentra en un estado particular, la luz est encendida
o apagada, el auto en movimiento o detenido, la persona leyendo o cantando, etc. El
diagrama de estados UML captura esa pequea realidad.

Diagrama de secuencias
Los diagramas de clases y los de objetos representan informacin esttica. No obstante, en
un sistema funcional, los objetos interactan entre s, y tales interacciones suceden con el
tiempo. El diagrama de secuencias UML muestra la mecnica de la interaccin con base en
tiempos.

Diagrama de actividades
Un diagrama de actividades ilustra la naturaleza dinmica de un sistema mediante el
modelado del flujo ocurrente de actividad en actividad. Una actividad representa una
operacin en alguna clase del sistema y que resulta en un cambio en el estado del sistema.
Tpicamente, los diagramas de actividad son utilizados para modelar el flujo de trabajo
interno de una operacin.

Diagrama de colaboraciones
El diagrama de colaboraciones describe las interacciones entre los objetos en trminos de
mensajes secuenciados. Los diagramas de colaboracin representan una combinacin de
informacin tomada de los diagramas de clases, de secuencias y de casos de uso,
describiendo el comportamiento, tanto de la estructura esttica, como de la estructura
dinmica de un sistema.
Diagrama de componentes
Un diagrama de componentes describe la organizacin de los componentes fsicos de un
sistema.

Unidad III. Ingeniera de requerimientos

Es el proceso para establecer los servicios que el sistema deber proveer y las restricciones
bajo las cuales deber operar y ser desarrollado.
La Ingeniera de Requerimientos es, por tanto, una actividad esencialmente de interaccin
con los interesados en el sistema.
Tcnicas para la obtencin de los requerimientos de un sistema.
Identificacin de un rea del problema.
Llegar un acuerdo con los clientes/usuarios sobre lo que el sistema debe hacer
Especificacin del sistema
Proporcionar los desarrolladores un mejor entendimiento de los requerimientos
Definirlas fronteras (delimitar) del sistema
Proporcionar bases para planificarlas iteraciones
Estimar los costos y el tiempo de desarrollo.
Desarrollar las aplicaciones en sesin JAD
Entrevistas
La entrevista es de gran utilidad para obtener informacin cualitativa como opiniones, o
descripciones subjetivas de actividades. Es una tcnica muy utilizada, y requiere una mayor
preparacin y experiencia por parte del analista. La entrevista se puede definir como un
intento sistemtico de recoger informacin de otra persona a travs de una comunicacin
interpersonal que se lleva a cabo por medio de una conversacin estructurada. Debe quedar
claro que no basta con hacer preguntas para obtener toda la informacin necesaria.
Aspectos ms importantes a tener en cuenta al realizar entrevistas:
Preparacin. Es necesario documentarse e investigar la situacin de la organizacin
analizando los documentos disponibles, de tal forma que la entrevista se enfoque en
aquellos aspectos que estn solamente en la mente del entrevistado y que no son
accesibles por otros medios como la observacin o el anlisis de documentos.
Entrevistar al personal adecuado. La mayora de los analistas adoptan un enfoque
comenzando a entrevistar a directivos para que brinden un panorama general de
hacia donde deberan ir las cosas, y terminando por hablar con los empleados que
aportan detalles importantes de la operacin.
Duracin. Una entrevista debera durar al menos un par de horas.

 Formato. Se recomienda utilizar preguntas abiertas, donde los entrevistados puedan

elaborar y dar detalles, ms all de simplemente responder si o no.
Lluvia de ideas
Es una tcnica de grupo para generar ideas originales en un ambiente relajado. Esta
herramienta creada en el ao 1941 por Alex Osborne, cuando su bsqueda de ideas
creativas result en un proceso interactivo de grupo no estructurado de lluvia de ideas
que generaba ms y mejores ideas que las que los individuos podan producir trabajando de
forma independiente.
Especificacin de requisitos
Requisitos Funcionales
Define las funciones que el sistema ser capaz de realizar.
Describe las transformaciones que el sistema realiza sobre las entradas para
producir salidas.
Requisitos no funcionales
Define las caractersticas que de una u otra forma pueden limitar el sistema.
Aspectos visibles por el usuario (Portabilidad, Confiabilidad, Eficiencia, Ingeniera
Humana, Verificabilidad, Entendimiento, Modificabilidad). Se recogen delos CU
con los que estn relacionados, o en las Especificaciones Complementarias.
Qu es un requerimiento?
Es una caracterstica que un sistema debe tener para cubrir alguna de las
necesidades que lo motivan
Rango de instrucciones abstractas de alto nivel de un servicio o de un
sistema
Base para la declaracin de un contrato y deber ser interpretado
Posteriormente debe ser definido en detalle
Ambas declaraciones sern llamadas Requerimientos.
Problemas:

 Roles del equipo de desarrollo indefinido y descoordinado.

Trabajo y rendimiento del proceso son daados por brechas de performance y

conflictos.
Visin limitada en el proceso y calidad del producto.
Control limitado de las configuraciones del producto.
Entrega tarda del cronograma inicialmente fijado.
Descontrol de costos, el trabajo cuesta mucho ms de estimado.
Las necesidades del cliente no son cubiertas por el software.

La IEEE Std 830-1998 es parte de los estndares que es necesario cubrir cuando se
pretende cumplir con las normas de calidad, por lo tanto, esta estructura se respeta en la
mayora de las especificaciones de requerimientos en cualquier parte del mundo cuando se
elaboran sistemas de software a nivel industrial. En cuanto a la seccin 3 requerimientos
especficos, la IEEE Std 830-1998 propone ocho plantillas diferentes a elegir, y son las
siguientes:
1.- Introduccin
2.- Descripcin General.
3.- Requerimientos Especficos.
Apndices.
ndice
3.- Requerimientos Especficos.
3.1 Requisitos Funcionales.
3.2 Requisitos de Interfaz Externa.
3.3 Requisitos de Ejecucin.
3.4 Restricciones de diseo.
3.5 Atributos de calidad Mantenimiento, reutilizacin
3.6 Otros Requisitos.