Introduccin

UNIDAD I : INTRODUCCIN A LA INGENIERA DE SOFTWARE

a) Presentacin y contextualizacin

El anlisis, fundamentos conceptuales y el desarrollo en la ingeniera de

software. Son el primer paso, tan importante que hay que entender para la
creacin
de
proyectos
informticos
Por
ello,
conocer
y
entender coherentemente un tipo de metodologa implica la aplicacin de
diferentes tipos de conceptos. Los requerimientos dentro de un proyecto
de software y el tipo de paradigma a aplicar en un proyecto constituyen un
respaldo que se lleva a cabo a travs de una serie de etapas, las cuales
se deben seguir para lograr proyectos que puedan cumplir con una serie
de necesidades por parte del cliente.

b) Competencia

Conoce metodologas y enfoques para la creacin de un proyecto

y los aspectos fundamentales tericos de la ingeniera de software.

c) Capacidades

1. Identifica los conceptos, procesos y solucin en la construccin de un

proyecto a nivel de software partiendo de sus fases principales de
creacin.
2. Reconoce el enfoque de Objetos a travs de sus paradigmas y
conceptos.
3. Conoce las fases de solucin como metodologa de creacin de un
proyecto de software.
4. Identifica y emplea adecuadamente el uso de los requerimientos
vlidos en la obtencin de informacin.

d) Actitudes

Valora los conceptos y tipos de metodologa como un medio

privilegiado.
Asume una actitud positiva en la creacin de un proyecto.
Respeta los puntos de vista distintos a los suyos.

e) Presentacin de Ideas bsicas y contenidos esenciales de la Unidad:

La Unidad de Aprendizaje 01: Introduccin a la Ingeniera de

Software, comprende el desarrollo de los siguientes temas:

TEMA 01: Definicin, Objetivos y Procesos.

TEMA 02: Paradigma de la Programacin Orientada a Objetos.
TEMA 03: Metodologas.
TEMA 04: Requerimientos e Ingeniera.

UNIDAD I : INTRODUCCIN A LA INGENIERA DE SOFTWARE

Tema 01: Definicin, Objetivos y Procesos

La Ingeniera de Software es la
rama de la ingeniera
queaplica los principios de la
ciencia de la computacin y las
matemticas para lograr
soluciones costo-efectivas
(eficaces en costo o econmicas)
a los problemas de desarrollo de
software", es decir, "permite
elaborar consistentemente
productos correctos, utilizables y costo-efectivos.

OBJETIVOS Y PROCESOS

Alcances:

El
proces
o de
ingeni
era de

El proceso de desarrollo de software requiere por un lado un

conjunto de conceptos, una metodologa y un lenguaje propio. A este
proceso tambin se le llama el ciclo de vida del software que
comprende cuatro grandes fases: concepcin, elaboracin,
construccin y transicin.

Fases:

1. Concepcion
La concepcin define el alcance del proyecto y desarrolla un caso de
negocio.

2. Elaboracion
La elaboracin define
un plan del proyecto,
especifica las
caractersticas y
fundamenta la
arquitectura.

3. Construccion
La construccin crea el producto a travs de una herramienta de
desarrollo o tambin conocido como lenguaje de programacin.
Preferentemente deber ser el lenguaje que dominio tenga

4. Transicion
La transicin transfiere el producto a los usuarios. Esta fase
tambin se encarga de actualizar la solucin propuesta, ante
problemas o nuevos requerimientos que se presenten en el periodo
de uso, una vez instalada la solucin en las oficinas del cliente.

OBJETIVOS DE LA INGENIERA DE SOFTWARE

v Mejorar la calidad de los productos de

software
v Aumentar la productividad y trabajo
de los ingenieros del software.
v Facilitar el control del proceso de
desarrollo de software.
v Suministrar a los desarrolladores las
bases para construir software de alta
calidad en una forma eficiente.

Objetivos

Para que los proyectos se cumplan en las empresas se debern de

cumplir las 5 C:
1. Capacidad
2. Costo
3. Control
4. Comunicacin
5. Competitividad

Tema 02: Paradigmas de la Programacin Orientada a Objetos

Programacin Orientada a Objetos (OOP por sus siglas en ingls de

Object Oriented Programming) como paradigma, "es una forma de
pensar ETAPAS:

Se debe distinguir que la OOP como paradigma (enfoque o manera

de visualizar la realidad) y como metodologa (coleccin de
caractersticas para la ingeniera de software) no es la misma cosa.

La Programacin Orientada a Objetos desde el punto de vista

computacional "es un mtodo de implementacin en el cul los
programas son organizados como grupos cooperativos de objetos,
cada uno de los cuales representa una instancia de alguna clase, y
estas clases, todas son miembros de una jerarqua de clases unidas
va relaciones de herencia" Greiff 1994.

FUNDAMENTOS DEL TRMINO ORIENTADO A OBJETOS

El paradigma orientado a objeto se basa en el concepto de

objeto. Se debe distinguir que la OOP como paradigma (enfoque o
manera de visualizar la realidad) y como
metodologa (coleccin de caractersticas
para la ingeniera de software) no son la
misma cosa.

Qu es un objeto?

Es aquello que tiene estado (propiedades ms valores),

comportamiento (acciones y reacciones a mensajes) e identidad
(propiedad que lo distingue de los dems objetos). La estructura y
comportamiento de objetos similares estn definidos en su clase
comn; los trminos instancia y objeto son intercambiables. Una
clase es un conjunto de objetos que comparten una estructura y
comportamiento comn.

DIFERENCIA ENTRE OBJETO Y CLASE

Objeto
Un objeto es una entidad concreta
que existe en tiempo y espacio.
Clase
Representa una abstraccin, la
"esencia" de un objeto, tal como
son. De aqu que un objeto no es
una clase, sin embargo, una clase
puede ser un objeto.
Una clase tambin se define como
un conjunto de objetos y mtodos.

PRINCIPIOS DEL MODELO O.O

v
v
v
v
v
v
v

Abstraccin
Encapsulacin
Modularidad
Jerarqua,
Tipificacin
Concurrencia
Existencia

Nota
Booch 1986 dice que si un modelo que se dice OO no contiene
alguno de los primeros cuatro elementos, entonces no es OO.

PRINCIPIOS DEL MODELO ORIENTADO A OBJETOS

Abstraccin. Es una descripcin simplificada o especificacin de un
sistema que enfatiza algunos de los detalles o propiedades del
sistema, mientras suprime otros.
Encapsulacin
. En el proceso
de ocultar
todos los
detalles de un
objeto que no
contribuyen a
sus
caractersticas
esenciales.
Modularidad.
Es la propiedad
de un sistema
que ha sido
descompuesto
en un conjunto
de mdulos
coherentes e independientes.
Jerarqua o herencia. Es el orden de las abstracciones organizado
por niveles.

 Tipificacin. Es la definicin precisa de un objeto de tal forma que

objetos de diferentes
tipos no puedan ser
intercambiados o,
cuando mucho, puedan
intercambiarse de
manera muy
restringida.
Concurrencia. Es la
propiedad que
distingue un objeto que
est activo de uno que
no lo est.
Persistencia. Es la
propiedad de un objeto
a travs de la cual su
existencia trasciende el
tiempo (es decir, el objeto continua existiendo despus de que su
creador ha dejado de existir) y/o el espacio (es decir, la localizacin
del objeto se mueve del espacio de direccin en que fue creado).

BENEFICIOS DE LA POO
Primero, el uso del modelo OO nos ayuda a explotar el poder
expresivo de todos los lenguajes de programacin basados en
objetos y los orientados a objetos, como Smalltalk, Object Pascal, C+
+, CLOS, Ada, [ y recientemente Java] .
Segundo, el uso del modelo OO
alienta el uso no solo del software,
sino de diseos completos.
Tercero, produce sistemas que estn
construidos en formas intermedias
estables y por ello son ms
resistentes al cambio en
especificaciones y tecnologa.

ANLISIS ORIENTADO A OBJETOS

Segn Booch 1986, el Diseo Orientado a Objetos "es un mtodo de

diseo abarcando el proceso de descomposicin orientado a objetos

y una notacin para representar ambos modelos lgico y fsico tal

como los modelos estticos y dinmicos del sistema bajo diseo"

Tema 03: Metodologas

Un objetivo de dcadas ha sido el encontrar procesos y

metodologas, que sean sistemticas, predecibles y repetibles, a fin

de mejorar la productividad en el desarrollo y la calidad del producto
software.

ETAPAS DEL PROCESO

La ingeniera de software requiere llevar a cabo numerosas tareas,
dentro de etapas como son las
siguientes:
1. Anlisis de requerimientos
2. Especificacin
3. Arquitectura
4. Programacin
5. Prueba
6. Mantenimiento

ANLISIS DE REQUERIMIENTOS

Extraer los requisitos y requerimientos de un producto de software

es la primera etapa para crearlo. Mientras que los clientes piensan
que ellos saben lo que el software tiene que hacer, se requiere de
habilidad y experiencia en la ingeniera de software para reconocer
requerimientos incompletos, ambiguos o contradictorios. El
resultado del anlisis de requerimientos con el cliente se plasma en
el documento ERS, Especificacin de Requerimientos del Sistema,
cuya estructura puede venir definida por varios estndares, tales
como CMMI. Asimismo, se define un diagrama de Entidad/Relacin,
en el que se
plasman las
principales
entidades que
participarn en el
desarrollo del
software.
La captura,
anlisis y
especificacin de
requerimientos
(incluso pruebas
de ellos), es una
parte crucial; de
esta etapa
depende en gran
medida el logro
de los objetivos
finales. Se han
ideado modelos y
diversos
procesos de
trabajo para
estos fines.

Aunque an no est formalizada, ya se habla de la Ingeniera de

requerimientos, por ejemplo en dos captulos del libro de
Sommerville "Ingeniera del Software" titulados "Requerimientos del
software" y "Procesos de la Ingeniera de Requerimientos".
La IEEE Std. 830-1998 normaliza la creacin de las Especificaciones
de Requerimientos de Software (Software Requirements
Specification).

Especificacin
La Especificacin de Requisitos describe el comportamiento
esperado en el software una vez desarrollado. Gran parte del xito
de un proyecto de software radicar en la identificacin de las
necesidades del negocio (definidas por la alta direccin), as como la
interaccin con los usuarios funcionales para la recoleccin,

clasificacin, identificacin, priorizacin y especificacin de los

requisitos del software.
Entre las tcnicas utilizadas para la especificacin de requisitos se
encuentran:
Casos de Uso,
Historias de usuario,
Siendo los primeros ms rigurosos y formales, los segundas ms
giles e informales.

Arquitectura
La integracin de infraestructura, desarrollo de aplicaciones, bases
de datos y herramientas gerenciales, requieren de capacidad y
liderazgo para poder ser conceptualizados y proyectados a futuro,
solucionando los problemas de hoy. El rol en el cual se delegan todas
estas actividades es el del Arquitecto. El Arquitecto de Software es la
persona que aade valor a los procesos de negocios gracias a su
valioso aporte de soluciones tecnolgicas. La Arquitectura de
Sistemas en general, es una actividad de planeacin, ya sea a nivel
de infraestructura de red y hardware, o de Software. La Arquitectura
de Software consiste en el diseo de componentes de una aplicacin

(entidades del negocio), generalmente utilizando patrones de

arquitectura.

Para ello se documenta utilizando diagramas, por ejemplo:

Diagramas de clases
Diagramas de base de datos
Diagramas de despliegue plegados
Diagramas de secuencia multidireccional

Siendo los dos primeros los mnimos necesarios para describir la

arquitectura de un proyecto que iniciar a ser codificado. Depende
del alcance del proyecto, complejidad y necesidades, el arquitecto
elige qu diagramas elaborar. Entre las herramientas para disear
arquitecturas de software se encuentran:
Rational Rose, Enterprise Architect, Microsoft Visio for Enterprise
Architects

Programacin
Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo
de ingeniera de software, pero no necesariamente es la que
demanda mayor trabajo y ni la ms complicada. La complejidad y la
duracin de esta etapa est ntimamente relacionada al o a los
lenguajes de programacin utilizados, as como al diseo
previamente realizado.

Prueba

Consiste en comprobar que el software realice correctamente las

tareas indicadas en la especificacin del problema. Una tcnica de
prueba es probar por separado cada mdulo del software, y luego
probarlo de forma integral, para as llegar al objetivo. Se considera
una buena prctica el que las pruebas sean efectuadas por alguien
distinto al desarrollador que la program, idealmente un rea de
pruebas; sin
perjuicio de
lo anterior
el

programador debe hacer sus propias pruebas.

En general hay dos grandes formas de organizar un rea de pruebas,

la primera es que est compuesta por personal inexperto y que
desconozca el tema de pruebas, de esta forma se evala que la
documentacin entregada sea de calidad, que los procesos descritos
son tan claros que cualquiera puede entenderlos y el software hace
las cosas tal y como estn descritas. El segundo enfoque es tener un
rea de pruebas conformada por programadores con experiencia,
personas que saben sin mayores indicaciones en qu condiciones
puede fallar una aplicacin y que pueden poner atencin en detalles
que personal inexperto no considerara.

Documentacin
Todo lo concerniente a la documentacin del propio desarrollo del
software y de la gestin del proyecto, pasando por modelaciones
(UML),diagramas de casos de uso, pruebas, manuales de usuario,
manuales tcnicos, etc; todo con el propsito de eventuales
correcciones, usabilidad, mantenimiento futuro y ampliaciones al
sistema.

Mantenimiento
Mantener y mejorar el software para enfrentar errores descubiertos y
nuevos requisitos. Esto puede llevar ms tiempo incluso que el
desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniera
de software tiene que ver con dar mantenimiento. Una pequea
parte de este trabajo consiste en arreglar errores, o bugs. La mayor
parte consiste en extender el sistema para hacer nuevas cosas. De
manera similar, alrededor de 2/3 de toda la ingeniera civil,
arquitectura y trabajo de construccin es dar mantenimiento.

Tema 04: Requerimientos e

Ingeniera
REQUISITOS:

Descripcin de los servicios que debe brindar un sistema y sus

restricciones.

Ingeniera de Requisitos

Proceso de descubrir, analizar,

documentar y verificar esos servicios
y restricciones
Requisitos definen el Qu (el
problema) del sistema.
El Diseo define el Cmo (la
solucin).

Los Requisitos estn comprendidos en 2 Tipos:

 Funcionales:
Servicios o funciones que
proveer el sistema.
Describen la interaccin entre
el sistema y su entorno.
Ejemplos:
Se deben ingresar
cdula, nombre y telfono
de cada cliente.
Se quiere un listado de
los clientes por zona.

No-funcional:

Restricciones a los servicios o funciones ofrecidos por el sistema.

Describen restricciones que limitan las elecciones para construir una
solucin.
Ejemplos:
Las consultas deben resolverse en menos de 3 segundos.
El lenguaje de programacin debe ser Java.

Ingeniera de Requisitos

Proceso de Requisitos

Participantes en el proceso de requisitos

Cliente y Usuarios

Requisitos adecuados a sus necesidades

Diseadores
Comprenderlos
para
lograr
diseo que los satisfaga
Supervisores
del
Contrato,
sugieren:
Hitos de Control, cronogramas
Gerentes del Negocio, entienden:
Impacto en la Organizacin
Verificadores
Comprenderlos
para
poder
verificar si el sistema los
satisface

Procesos de Requisitos

Obtencin y Anlisis de Requisitos

Se trabaja en conjunto con los usuarios

y clientes
Problemas comunes:
No saben lo que quieren del sistema,
slo en trminos generales, no
conocen el costo de sus peticiones
Los requisitos estn en sus trminos y
con conocimiento implcito de su
propio trabajo
Distintos usuarios tienen distintos
requisitos, se deben encontrar todas
las fuentes

Especificacin

El resultado del trabajo realizado es una consecuencia de la

ingeniera de requisitos (especificacin el sistema e informacin
relacionada) y es evaluada su calidad en la fase de validacin

Validacin

Examina
las
especificaciones
para asegurar que
todos
los
requisitos
del
sistema han sido
establecidos
in
ambigedad, sin
inconsistencias,
sin omisiones, que
los
errores
detectados hayan
sido corregidos, y
que el resultado
del trabajo se
ajusta a los estndares establecidos para el proceso, el proyecto y
el producto.