I.- ANALISIS: (Cap. 11 Y 12, Ingeniera de Software, Pressman, ta. !d." 1.

Definicin, utilidad y consejos para aplicar correctamente las TFEA

Constituye una variacin de las entrevistas buscando identificar el problema, proponer elementos de solucin, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solucin. A pesar de ir un paso ms all de las entrevistas Convencionales, precisan an de una alta participacin del analista. Hoy en da, las !"A son empleadas de forma general por los sistemas de informacin, pero la t#cnica ofrece un potencial de mejora en aplicaciones de todo tipo. Consejos para aplicar correctamente las !"A $a reunin se celebra en un lugar neutral y acuden tanto los clientes como los desarrolladores. %e establecen normas de preparacin y de participacin. %e sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes, pero lo suficientemente informal como para animar el libre flujo de ideas. &n 'coordinador( )que puede ser un cliente, un desarrollador o un tercero* que controle la reunin. %e usa un 'mecanismo de definicin( )que puede ser +ojas de trabajo, grficos, carteles o pi,arras*. "l objetivo es identificar el problema, proponer elementos de solucin, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solucin en una atmsfera que permita alcan,ar el objetivo.
2. Resumen de principios del anlisis

Conjunto de principios operativos.. /ebe representarse y entenderse el dominio de informacin de un problema. 0. /eben definirse las funciones que debe reali,ar el soft1are 2. /ebe representarse el comportamiento del soft1are )como consecuencia de acontecimientos e3ternos*

4. /eben dividirse los modelos que representan informacin, funcin y comportamiento de manera que se descubran los detalles por capas. 5. "l proceso de anlisis debera ir desde la informacin esencial +asta el detalle de la implementacin.

3.

Resumen de creacin de prototipos de soft are

Creacin de prototipos del software "l anlisis +ay que +acerlo independientemente del paradigma de ingeniera del %oft1are que se aplique. %in embargo, la forma que toma este anlisis vara. Seleccin del enfoque de creacin de prototipos "l paradigma de creacin de prototipos puede ser cerrado o abierto. "l enfoque cerrado se denomina a menudo prototipo desec+able. "ste prototipo %irve nicamente como una vasta demostracin de los requisitos. /espu#s se /esec+a y se +ace una ingeniera del soft1are con un paradigma diferente. &n enfoque abierto, denominado prototipo evolutivo, emplea el prototipo como primera parte de una actividad de anlisis a la que seguir el dise6o y la construccin. %i una aplicacin candidata va a requerir el desarrollo de decenas de miles de lneas de cdigo 7antes8 de poder reali,ar cualquier funcin demostrable, es muy probable que sea demasiado compleja para crear un prototipo. Mtodos y herramientas para el desarrollo de prototipos #cnicas de cuarta generacin ) 49*- estas t#cnicas comprenden una amplia gama de lenguajes de consulta e informes de base de datos, generadores de programas y aplicaciones y de otros lenguajes no procedimentales de muy alto nivel. Componentes de soft1are reutili,ables "specificaciones formales y entornos para prototipos

!.

Resumen de los principios de la especificacin del anlisis

"l modo de especificacin tiene muc+o que ver con la calidad de la solucin. Principios de la especificacin :rincipios.. %eparar la funcionalidad de la implementacin. 0. /esarrollar un modelo del comportamiento deseado de un sistema que comprenda datos y las respuestas funcionales de un sistema a varios estmulos del entorno. 2. "stablecer el conte3to en que opera el soft1are especificando la manera en que otros componentes del sistema interactan con #l. 4. /efinir el entorno en que va a operar el sistema e indicar como 7una coleccin de agentes altamente entrela,ados reaccionan a estmulos del entorno producidos por esos agentes8. 5. Crear un modelo intuitivo en ve, de un dise6o o modelo de implementacin. ;. <econocer que 7la especificacin debe ser tolerante a un posible crecimiento si no es completa8 )puede especificarse a distintos niveles*. =. "stablecer el contenido y la estructura de una especificacin de manera que acepte cambios.
". T#cnicas para reali$ar una correcta re%isin de la especificacin

$a revisin de la "specificacin de requisitos del soft1are )y>o prototipo* es llevada a cabo tanto por el desarrollador del soft1are como por el cliente. Como la especificacin forma el fundamento para el dise6o y las subsiguientes actividades de la ingeniera del soft1are, se debera poner e3tremo cuidado al reali,ar la revisin. <equisitos %oft1are

<evisin de lo "specificacin ?nicialmente la revisin se lleva a cabo a nivel macroscpico. A este nivel, los revisores intentan asegurarse de que la especificacin sea completa, consistente y correcta cuando la informacin general, funcional y de los dominios del comportamiento son considerados. Asimismo, una e3ploracin completa de cada uno de estos dominios, la revisin profundi,a en el detalle, e3aminando no solo las descripciones superficiales, sino la va en la que los requisitos son e3presados. :or ejemplo, cuando una especificacin contiene un 't#rmino vago( )por ejemplo, algo, algunas veces, a veces, normalmente, corrientemente, muc+o, o principalmente*, el revisor se6alar la sentencia para su clarificacin. &na ve, que se +a completado la revisin, se firma la especificacin de requisitos del soft1are por el cliente y el desarrollador. $a especificacin se conviene en un 'contrato( para el desarrollo del soft1are. $as peticiones de cambios en los requisitos una ve, que se +a finali,ado la especificacin no se eliminarn, pero el cliente debe saber que cada cambio a posteriori significa una ampliacin del mbito del soft1are, y por tanto pueden aumentar los costes y prolongar los pla,os de la planificacin temporal del proyecto. ?ncluso con los mejores procedimientos de revisin, siempre persisten algunos problemas comunes de especificacin. $a especificacin es difcil de 'probar( de manera significativa, por lo que pueden pasar inadvertidas ciertas inconsistencias y omisiones. /urante la revisin, se pueden recomendar cambios a la especificacin. :uede ser e3tremadamente difcil valorar el impacto global de un cambio@ es decir, Acmo afecta el cambio en una funcin a los requisitos de las demsB $os modernos entornos de ingeniera del soft1are incorporan +erramientas CA%" desarrolladas para ayudar a resolver estos problemas .
". &ro'lemas y &untos a (onsiderar )a final del (ap*tulo+ )11.1 a 11.,+

11.1. El anlisis de re-uisitos del soft are es induda'lemente la fase de comunicacin ms intensa del proceso de in.enier*a del soft are. /&or -u# suele romperse frecuentemente este enlace de comunicacin0
:orque es llevada a cabo tanto por el desarrollador del soft1are como por el cliente. :ero a veces el cliente no sabe e3presar lo que quiere o el desarrollador no entiende lo que quiere el cliente y esto puede llevar a una confusin en el desarrollo del proyecto.

11.2. 1uele 2a'er serias repercusiones pol*ticas cuando comien$a el anlisis de re-uisitos del soft are )y3o anlisis de un sistema+. &or ejemplo, los tra'ajadores pueden creer -ue la se.uridad de su tra'ajo puede %erse amena$ada por un nue%o sistema automtico. /4u# ori.ina tales pro'lemas0 /1e pueden lle%ar a ca'o las tareas de anlisis de manera -ue se minimicen estas repercusiones pol*ticas0

$o origina la incertidumbre si el soft1are o sistema a anali,ar, va a reempla,ar al personal en donde se est reali,ando el anlisis. %i. %e pueden llevar las tareas de anlisis.

11.3. Estudie su percepcin ideal de la formacin y curr*culum de un analista de sistemas.

"l perfil tradicional del analista es anali,ar. $as cualidades que se esperan de un analista son esencialmente la capacidad de abstraccin y de anlisis. $os conocimientos que requiere son aquellos relacionados con las t#cnicas de anlisis de sistemas de informacin Conocimiento del paradigma tradicional de la ingeniera del soft1are y del tradicional ciclo de vida del soft1are en cascada. Codelado funcional- /iagrama de flujo de datos, diagrama de estado, etc. Codelado de datos y sus t#cnicas- /iagrama entidadDrelacin, modelo relacional, etc. Conocimiento de la tecnologa- arquitectura de soft1are, bases de datos, etc.

11.!. A lo lar.o de todo el cap*tulo nos referimos al 5cliente6. Descri'a el 5cliente6 desde el punto de %ista de los desarrolladores de sistemas de informacin, de los constructores de productos 'asados en computadora y de los constructores de sistemas. 7Ten.a cuidado, el pro'lema puede ser ms complejo de lo -ue parece8
Cliente- es aquel que e3presa una necesidad de su sistema de informacin )%.?.*

11.". Desarrolle un 59it6 de t#cnicas de especificacin de aplicacin )TFEA+. El 9it de'er*a incluir un conjunto de directrices para lle%ar a ca'o una reunin TFEA, materiales para facilitar la creacin de listas y otros elementos -ue pudieran ayudar en la definicin de re-uisitos. TFEA. &A1:1 A 1E;<=R &ARA >A E>A?:RA(=:@. Esta'lecer el pro'lema. Ele.ir un lu.ar para reali$ar la recoleccin de datos.

Esta'lecemos normas de preparacin y participacin. (reamos una a.enda de acti%idades. De'emos ele.ir al responsa'le. De'emos tomar decisiones y soluciones al pro'lema. (rear entre%istas para los clientes o personas implicadas para los procesos in%olucrados en la reali$acin del sistema.
EA/ )Eoint Application /evelopment*

utili$ar AAD es una t#cnica de definicin de re-uisitos y de diseBo de la interfa$ de usuario, 'asada en reuniones participati%as entre clientes, directi%a y desarrolladores.
/espliegue de la funcin de calidad )/!C*. ormenta de ideas )brainstorming*. Casos de uso o escenarios alleres ?ntrospeccin

11.C. 1u profesor di%idir la clase en .rupos de cuatro a seis estudiantes. >a mitad del .rupo 2ar el papel del departamento de mar9etin. y la otra mitad el de la in.enier*a del soft are. 1u tra'ajo consiste en definir los re-uisitos del sistema de se.uridad Do.ar se.uro descrito en este cap*tulo. (ele're una reunin TFEA usando las directrices estudiadas en el cap*tulo. 11.,. /1e puede decir -ue un Eanual preliminar de usuario es una forma de prototipo0 Ra$one su respuesta.
%i. :uede parecer innecesario reali,ar un manual de usuario en una etapa tan temprana del proceso de desarrollo, :ero de +ec+o, este borrador del manual de usuario fuer,a al analista a tomar el punto de vista del usuario del soft1are. "l manual permite al usuario > cliente revisar el soft1are desde una perspectiva de ingeniera +umana y frecuentemente produce el comentario- F$a idea es correcta pero esta no es la forma en que pens# que se podra +acer estoF. "s mejor descubrir tales comentarios lo ms tempranamente posible en el proceso, para la mejora del mismo.

,. &ro'lema 12.3 al final del cap*tulo )DFD ni%el 1 y 2 y ta'las+. )Repasar primero los conceptos de anlisis del cap*tulo+.

I.- #IS!$%: (Cap. 1&, 1' ( 1 , Ingeniera de Software, Pressman, ta. !d." 1. EFplicacin resumida de la fi.ura 13.1 )Relacin Anlisis 3 DiseBo+. =ncluir ejemplo.

/ise6o del soft1are e ingeniera del soft1are "l dise6o del soft1are se encuentre en el ncleo t#cnico de la ingeniera del soft1are y se aplica independientemente del modelo de dise6o de soft1are que se utilice. Cada uno de los elementos del modelo de anlisis proporciona la informacin necesaria para crear los cuatro modelos de dise6o que se requieren para una especificacin completa de dise6o. $a tarea de dise6o produce un dise6o de datos, un dise6o arquitectnico, un dise6o de interfa, y un dise6o de componente. "l dise6o de datos transforma el modelo del dominio de informacin que se crea durante el anlisis en las estructuras de datos que se necesitarn para implementar el soft1are. "jemplo.- las tablas de una base de datos. "l dise6o arquitectnico define la relacin entre los elementos estructurales principales del soft1are, los patrones de dise6o se pueden utili,ar para lograrlos requisitos que se +an definido para el sistema, y las restricciones que afectan a la manera en que se pueden aplicar los patrones de dise6o arquitectnico. "jemplo.- un programa cliente>servidor. "l dise6o de interfa, describe la manera de comunicarse el soft1are dentro de s mismo, con sistemas que interoperan dentro de #l y con las personas que lo utili,an. "jemplo.- una interfa, de usuario )9&?*

"l dise6o a nivel de componentes transforma los elementos estructurales de la arquitectura del soft1are en una descripcin procedimental de los componentes del soft1are. "jemplo.- un sistema modular. "l dise6o proporciona las representaciones del soft1are que se pueden evaluar en cuanto a la calidad.

2. Resumen de directrices de diseBo

"l dise6o deber implementar todos los requisitos e3plcitos del modelo de anlisis, y debern ajustarse a todos los requisitos implcitos que desea el cliente. "l dise6o deber ser una gua legible y comprobable para aquellos que generan cdigo y para aquellos que comprueban y consecuentemente, dan soporte al soft1are. "l dise6o deber proporcionar una imagen completa del soft1are, enfrentndose a los dominios de comportamiento, funcionales y de datos desde una perspectiva de implementacin. Criterios de calidad del dise6oG &n dise6o deber presentar una estructura arquitectnica queo %e +aya creado mediante patrones de dise6o reconocibles o Hue est# formada por componentes que e3+iban caractersticas de buen dise6o o G Hue se puedan implementar de manera evolutiva ,facilitando as la implementacin y la comprobacin &n dise6o deber ser modular, este es, el soft1are deber dividirse lgicamente en elementos que realicen funciones y subDfunciones especficas. &n dise6o deber contener distintas representaciones de datos, arquitectura, interfaces y componentes.

&n dise6o deber conducir estructuras de datos adecuadas para los objetos que se van a implementar y que procedan de patrones de datos reconocibles.

G &n dise6o deber conducir a componentes que presenten caractersticas funcionales independientes. G &n dise6o deber conducir a interfaces que redu,can la complejidad de las cone3iones entre los mdulos y con el entorno e3terno. G &n dise6o deber derivarse mediante un modelo repetitivo y controlado por la informacin obtenida durante el anlisis.

3. Resumen y ejemplo de los conceptosG 3.1. A'straccin procedimental

&na

abstraccin procedimental es una secuencia nombrada de instrucciones que tiene una funcin especfica y limitada. "jemplo.un procedimiento almacenado, en una base de datos o una funcin en un programa

3.2. A'straccin de datos

&na abstraccin de datos es una coleccin nombrada de datos que describe un objeto de datos. "jemplo la programacin orientada a objetos :II
3.3. A'straccin de control

$a abstraccin de control implica un mecanismo de control de programa sin especificar los datos internos. "jemplo las instrucciones de control de los lenguajes de programacin
3.!. Refinamiento

"l refinamiento paso a paso es una estrategia de dise6o descendente. "l desarrollo de un programa se reali,a refinando sucesivamente los niveles de detalle procedimentales. &na jerarquita se desarrolla descomponiendo una sentencia macroscpica de funcin paso a paso +asta alcan,arlas sentencias del lenguaje de programacin.

"l refinamiento verdaderamente es un proceso de elaboracin. %e comien,a con una sentencia de funcin que se define a un nivel alto de abstraccin.

"l refinamiento +ace que el dise6ador trabaje sobre la sentencia original, proporcionando cada ve, mas detalles a medida que va teniendo lugar sucesivamente todos y cada uno de los refinamientos. "jemplo refinamiento del cdigo en un programa.
3.". Eodularidad

$a arquitectura de computadora e3presa la modularidad@ es decir el soft1are se divide en componentes nombrados y abordados por separado, llamados frecuentemente mdulos, que se integran para satisfacer los requisitos del problema. $a modularidad es el nico atributo del soft1are que permite gestionar un problema ?ntelectualmente. %istema modular efectivoG Capacidad de descomposicin modular G Capacidad de empleo de componentes modulares G Capacidad de comprensin modular G Continuidad modular G :roteccin modular "jemplo. "s dividir tu sistema en "mdulos" o segmentos de cdigo, donde cada uno se encargue de cierta funcionalidad del programa en general, la finalidad de esto es hacer el programa ms entendible. Como por ejemplo un sistema bancario
3.C. :cultamiento de informacin

"l principio de ocultacin de informacin sugiere que los mdulos se caracteri,an por las decisiones de dise6o que )cada uno* oculta al otro.

EjemploG los mdulos de un sistema deben especificarse y disearse para

que la informacin contenida en ellos sea accesible solamente a los mdulos que necesiten dicha informacin. Implica que para conseguir una modularidad efectiva hay que definir un conjunto de mdulos independientes, que se comuniquen con los otros mediante la informacin que sea necesaria para reali ar la funcin del soft!are.
3.,. (o2esin

%iempre debemos buscar la co+esin ms alta, aunque la parte media del espectro suele ser aceptable.

"or ejemplo# bibliotecas de funciones matemticas, slo se agrupan porque reali an clculos matemticos, pero no tienen necesariamente relacin entre ellas.
3.H. Acoplamiento

?ntentamos conseguir el acoplamiento ms bajo posible. &na conectividad sencilla entre mdulos da como resultado un soft1are ms fcil de entender y menos propenso a tener 7efecto ola8 causado cuando ocurren errores en un lugar y se propagan por el sistema. "jemplo. $n ejemplo simple de acoplamiento es cuando un componente accede directamente a un dato que pertenece a otro componente.

!. EFplicacin resumida de la fi.ura 13." ):r.ani$acin en capas+. =ncluir ejemplo.

?ndependencia funcional "l concepto de independencia funcional es la suma de la modularidad y de los conceptos de abstraccin y ocultacin de informacin. /ise6ar el soft1are de manera que cada modulo trate una subDfuncin de requisitos y tenga una interna,a sencilla cuando se observa desde otras partes de la estructura del programa. $a interdependencia se mide mediante 0 criterios caritativos.. Co+esin- es una medida de la fuer,a relativa funcional de un mdulo. 0. Acoplamiento- es una medida de independencia relativa entre mdulos.

Cohesin %iempre debemos buscar la co+esin ms alta, aunque la parte media del espectro suele ser aceptable.

Acoplamiento ?ntentamos conseguir el acoplamiento ms bajo posible. &na conectividad sencilla entre mdulos da como resultado un soft1are ms fcil de entender y menos propenso a tener 7efecto ola8 causado cuando ocurren errores en un lugar y se propagan por el sistema.

". Resumen re.las de oro de una 'uena interfa$

<eglas de oro.. /ar el control al usuario. 0. <educir la carga de memoria del usuario 2. Construir una interfa, consecuente

Dar el control al usuario G G /efinir los modos de interaccin de manera que no obligue a que el usuario realice acciones innecesarias y no deseadas. ener en consideracin una interaccin fle3ible

G :ermitir que la interaccin del usuario se pueda interrumpir y des+acer G Aligerar la interaccin a medida que avan,a el nivel de conocimiento y permitir personali,ar la interaccin. G Icultar al usuario ocasional los entresijos t#cnicos. G /ise6ar la interaccin directa con los objetos que aparecen en la pantalla. Reducir la carga de memoria del usuario. G <educir la demanda de memoria a corto pla,o. G "stablecer valores por defecto tiles G /efinir las deficiencias que sean intuitivas G "l formato visual de la interfa, se deber basar en una metfora del mundo real

G /esglosar la informacin de forma progresiva Construccin de una interfa consistente oda la informacin visual esta organi,ada de acuerdo con el dise6o estndar que se mantiene en todas las presentaciones de pantalla.

odos los mecanismos de entrada limiten a un conjunto limitado y que se utilicen consecuentemente por toda la aplicacin $os mecanismos para ir de tarea a tarea se +ayan definido e implementado consecuentemente.

C. Resumen caracter*sticas detalladas de una 'uena interfa$

oda buena interfa, debe tener como mnimo estas J cualidadesClaridad. &na interfa, limpia no necesita manuales, no da lugar a confusiones. Con ello aseguramos que nuestros usuarios tengan menos fallos mientras la utili,an. 2. Concisin. "st relacionada con la cualidad anterior. Cientras ms sobrecargues tu interfa,, ms difcil le ser encontrar lo que busca al usuario. /ebemos ser concisos y especificar todo brevemente.
1. 3.

!amiliaridad. Hay que aprovec+ar y reutili,ar elementos ya preestablecidos en la sociedad ya que te ayudan bastante a comprender fcilmente tu interfa, en las primeras veces de uso. :or ejemplo, un icono con forma de carpeta para organi,ar carpetas, un icono con forma de calendario para ver un calendario. Sensi"ilidad. %e refiere a dos conceptoso o

4.

<apide, de la interfa,. Kuen feedbacL, el usuario debe saber en todo momento lo que est +aciendo, cuando lo consigue como cuando no.

5.

Consistencia. &na ve, que los usuarios aprendan ciertas partes del manejo de la interfa,, se puede e3trapolar este manejo a nuevas reas y funcionalidades de la interfa,. #sttica. &na interfa, visual atractiva +ace que el uso de la interfa, sea ms agradable y aumente la satisfaccin de los usuarios. #ficiencia. "l tiempo es oro y una buena interfa, de usuario debera a+orrarnos muc+o tiempo y esfuer,o. #rrores. odos cometemos errores y la forma como controla los errores ser una prueba de su calidad global. &na buena interfa, no

6. 7. 8.

debe castigar a los usuarios por sus errores sino que debe proporcionar la intencin de ponerles remedio.