INGENIERIA DE SOFTWARE II

Clase 01/02 12/08/15 14/08/15:

Sistema: partes que interactan entre s, con un objetivo comn. Sistema de software:
La entrada al proceso se basa en una necesidad que tiene un cliente, un problema.
Mediante un proceso de software el profesional de sistemas buscar una solucin al
problema del cliente (salida del proceso), que derivar en un sistema de software.
La ingeniera de requisitos analizada como un proceso de software recibe las
necesidades del cliente y da como resultado los requisitos del sistema. Un requerimiento
hace referencia a una necesidad.
Partes de mi sistema:

Nombre: todo sistema debe tener un nombre. Debe tener uno comercial, pero
tambin puede tener un nombre interno, que utilice el equipo de desarrollo.
Objetivo: qu es lo que va a hacer (a grandes rasgos). Las funcionalidades que
debe tener el mismo y, por lo tanto, qu voy a construir. Esta informacin debera
encontrarse por escrito y ser comprendido por todos los stakeholders (los
interesados en el sistema, tanto clientes como desarrolladores y diseadores, etc).
El objetivo es el qu. El mismo debe ser un acuerdo de ambas partes. Aparejado
con el objetivo deben figurar los beneficios de la creacin e implementacin del
sistema, o la mejora de uno anterior mediante la adhesin de los nuevos
requisitos.
o Beneficios: Por ejemplo: Un sistema de stocks. El beneficio sera El
sistema permitir disminuir un 10% el tiempo invertido en el arque de la
mercadera. Hay que tener cuidado de cmo son planteados los
beneficios, ya que los mismos son un compromiso con el cliente, con lo
que el sistema deber hacer una vez terminado. Generalmente se plantan
con cierta ambigedad para poder cubrirse.
Limite vs. Alcance: El limite es aquello con lo que me compromet a realizar, son
las cosas que el cliente pretende que el sistema haga; a partir de ellos
establecemos las funcionalidades, el tiempo y los costos del sistema. Debemos
mantener un balance entre mantener al cliente contento pero tampoco excedernos
con las funcionalidades (ni exceso ni falta de las mismas, ya que pueden generar
prdidas, ya sea de dinero, tiempo o de confiabilidad de los clientes). Es por eso
que es importante que los lmites estn bien planteados. El alcance, por otro lado,
debe incluir todo aquello que interacta con el sistema, que dar un estmulo o
recibir una respuesta del sistema.
Limitaciones del sistema: cosas a tener en cuenta al construir el sistema (el
funcionamiento del 3G en Buenos Aires, por ejemplo); son aquellas cosas que
pueden afectar al sistema pero que no dependen de los desarrolladores. Las
limitaciones deberan estar especificadas en un apartado. En caso de depender

del desarrollador, cuando este puede hacer algo al respecto (por ejemplo, en que
plataformas no funcionar la aplicacin), se trata de un requisito no funcional.
Tanto las limitaciones como el alcance deben estar bien definidos para bajar las
expectativas de los clientes, as como tambin para definir el trabajo que realizar
el equipo de desarrollo.
Requisitos: Algn comportamiento del sistema o alguna restriccin a ese
comportamiento. Todo lo que digan mis requisitos ser lo que deber hacer mi
sistema. Los mismos deben tener un alto nivel de detalle y asegurarse de que los
mismos no sean ambiguos (de serlo, deben reescribirse). El cdigo de mi
programa debera respetar los requisitos, para tener bien ajustado el lmite y lo que
el cliente desea (evitando as faltas o prdidas). Responden a la pregunta Qu
voy a hacer? Pero a un nivel de detalle mucho mayor que el objetivo; ambos
deben estar alineados. Hay dos grandes grupos de requisitos:
o Requisitos Funcionales (RF n): funciones que debe tener el sistema.
Ejemplo: El profesor selecciona presente o ausente para cada alumno de
la lista de alumnos. El profesor est fuera del lmite del sistema, pero
dentro del alcance. Adems del ejecutor, puedo tener otros actores que
estimulen el sistema (el alumno, por ejemplo).
o Requisitos No Funcionales (RNF n): limitaciones sobre mi sistema.
Limitan los requisitos funcionales.
SRS: Especificacin de requisitos de Software. A donde los stakeholders debern
ir a buscar los detalles del sistema (clientes, desarrolladores, diseadores, etc).
Glosario: conjunto de trminos que pertenecen al universo de discurso del cliente,
y que sern utilizados en la SRS para especificar los requisitos. Deben
encontrarse en orden alfabtico para facilitar su bsqueda. Aparecen destacados
en la SRS (en otra letra, subrayado, etc) para que quin la lee sepa que debe leer
el detalle para terminar de comprender el requisito. Que la definicin del trmino
se encuentre en un solo lugar reduce errores en caso que sea necesario
modificarlo (no tengo que modificarlo en cada requisito).

Todo lo que pueda automatizarse en un sistema, siempre y cuando se mantenga dentro

del alcance, es conveniente hacerlo, ya que facilita el trabajo.
Los requisitos deben estar completos, no puede faltarles informacin.

Clase 03 18/08/15:
Los sistemas que hacemos apuntan a resolver problemas de una forma mejor, con menos
tiempo o con un mejor proceso (ya sea ahorro de tiempo o dinero). Objetivo primario:
solucionar problemas en un dominio que es claramente identificable. El software es
un negocio, por lo tanto el negocio manda (los objetivos del negocio deben tener prioridad
a la hora de la construccin de mi software).
Un evento genera un estmulo que pasa por mi sistema y luego del proceso, se elabora
una respuesta que genera una consecuencia. Las necesidades de un sistema surgen de
explorar un dominio determinado. En los Requisitos Funcionales establezco qu debe

tener mi sistema y en los Requisitos No Funcionales las limitaciones que habr sobre
estos, ya que hay infinitas formas de hacer las cosas. Si los Requisitos Funcionales no
estn cubiertos, la solucin no sirve. Sin embargo, que estos estn cubiertos no quiere
decir que la solucin sea la correcta (hay que tener en cuenta tambin los RNF y cmo
impactan sobre los RF). Cuanta ms funcionalidad tiene mi sistema (ms RF), ms
complejo es construirlo. Cuanto ms complejas estas funcionalidades, an ms complejo.
Primero que nada debemos conocer nuestras restricciones. Los RF estn claros, pero
debo establecer los RNF, las limitaciones. Los requerimientos deben apuntar a la funcin,
no a las restricciones fsicas.
Restricciones comunes sobre los RF: Quality Attributes:
Los QA engloban los RNF. Los costos no entran dentro de estas limitaciones; s que hay
algo mejor, pero no puedo pagarlo (no es propiamente una limitacin de requisitos
del sistema, sino que involucra otras cuestiones).
o

o
o
o
o

Performance: necesito hacer algo en determinado tiempo o menos (RNF de

performance o rendimiento). Puede ser velocidad de respuesta, cantidad de
consultas atendidas en simultneo, cantidad de clientes que debe soportar, etc.
Generalmente conviene tener cierto margen de error (si debo soportar 1000
clientes, sera conveniente hacerlo para que soporte un 10% ms, incluso si el
tiempo de respuesta es un poco mayor).
Seguridad: Por ejemplo, el sistema no puede ser usado por usuarios no
registrados. No estoy cambiando lo que el sistema hace, sino estableciendo una
restriccin sobre l. Otro ejemplo puede ser la encriptacin de datos.
Usabilidad.
Portabilidad: capacidad del sistema de funcionar correctamente en varias
plataformas.
Mantenibilidad: cambios o arreglos en el sistema. El tiempo de mantenibilidad
requerido me restringe el modo de construccin del sistema.
Disponibilidad: el tiempo que el sistema debe estar disponible. La tasa de
tiempo en la que debe estar disponible. (Ejemplo: tasa de disponibilidad .99
implica 3 das de no disponibilidad del sistema al ao).

Clase 04 20/08/15:
Alcance: mucho ms detallado que el objetivo (el objetivo es ms general). El objetivo es
la funcin principal de mi sistema, entender en forma global qu es lo que hace el mismo.
El alcance, en cambio, es el rango de funcionalidad, todo lo que est escrito en el alcance
deber ser construido.
Nivel de detalle (diseo piramidal): De ms general a ms detallado, arriba de todo se
encuentran los objetivos, luego est el alcance y por ltimo los requisitos.

Los requisitos son exactamente lo que voy a construir. EL alcance en cambio apunta a la
funcionalidad, qu se construir y qu no. El objetivo es la funcionalidad general. El
propsito puntual de cada parte es distinto, aunque el principal sea explicar la
funcionalidad del sistema.
Macro-requisitos o requisitos de alto nivel (sujeto+verbo+): No me alcanzan para
construir mi sistema (me falta detalle). Un (1) macro-requisito puede asociarse con n
requisitos. Tienen que ser dos requisitos o ms (si fuese una relacin de uno a uno, sera
el mismo requisito). Adems, un requisito no puede pertenecer a dos macro-requisitos, ya
que si no tendr a dos equipos trabajando en lo mismo.
Modelos: grafica + texto:
Un modelo es una vista del sistema en un contexto determinado que persigue un
propsito y que se genera mediante un proceso de abstraccin. Este proceso de
abstraccin consiste en ocultar detalles que no son relevantes para el propsito del
modelo; ajuntar el nivel de detalle adecuado al propsito.
Con los modelos tengo una sola vista del sistema. Le puedo dar un distinto nivel de
detalle, dependiendo de lo que quiera mostrar, de cul sea el propsito de este modelo y
hacia quin est dirigido. Hay que analizar siempre el contexto del sistema, ya que esto
determinar tambin el modelo y diferir el proceso de abstraccin.
UML: Lenguaje Unificado de Modelado:
Un lenguaje implica una sintaxis y una semntica (los dibujos tienen un significado). Los
diagramas son las representaciones grficas de un conjunto de elementos de modelado.
El modelo de software se compone de diagramas ms especificaciones.
Cada macro-requisito podra ser un paquete, ya que estos agrupan los requisitos (que es
la funcin que tienen los paquetes).
Diagramas de casos de uso: ACTORES, RELACIONES (asociacin, inclusin,
extensin y generalizacin), CASOS DE USO.