86
 Instituto Tecnológico de Pachuca Autopista México - Pachuca: Km 87.5, Código Postal 42080, Apartado Postal 276 Teléfonos: (771) 71-1 31 40, 71–130 73, 71–1 35 96 Fax: 71–1 33 9910/04/2008  José Fructuoso Gutiérrez Díaz Planificación y modelado, trata de la planificaci ón, análisis y diseño de proyectos de software o sistemas de información, conforme a los requerimien tos establecidos al inicio del mismo y aplicando técnicas modernas y de acorde a las características intrínsecas del mismo. Planificación y Modelado

Planificación y Modelado

Embed Size (px)

Citation preview

Page 1: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 1/86

 

I n s t i t u t oT e c n o l ó g i c o d e

P a c h u c a

A u t o p i s t a M é x i c o -

P a c h u c a : K m 8 7 . 5 ,C ó d i g o P o s t a l4 2 0 8 0 , A p a r t a d o

P o s t a l 2 7 6

T e l é f o n o s : ( 7 7 1 )7 1 - 1 3 1 4 0 , 7 1 – 1 3 0

7 3 , 7 1 – 1 3 5 9 6

F a x : 7 1 – 1 3 3

9 9 1 0 / 0 4 / 2 0 0 8

 José Fructuoso GutiérrezDíaz

Planificación y modelado, trata de laplanificación, análisis y diseño de proyectos

de software o sistemas de información,conforme a los requerimientos establecidosal inicio del mismo y aplicando técnicasmodernas y de acorde a las característicasintrínsecas del mismo.

Planificación y

Modelado

Page 2: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 2/86

 

     0     0     8

Planificación y Modelado

ContenidoContenido ............................................................................................................ 2

Procesos de la ingeniería de requerimientos. ..................................................... 41.1 Requerimientos de proceso. ...................................................................... 7

1.1.1 Inicio.................................................................................................... 8

1.1.2 Obtención............................................................................................ 8

1.1.3 Elaboración.......................................................................................... 9

1.1.4 Negociación......................................................................................... 9

1.1.5 Especificación.................................................................................... 10

1.1.6 Validación.......................................................................................... 11

1.1.7 Gestión de requerimientos................................................................. 12

1.2 Requerimientos de los usuarios (actores involucrados). ..........................14

1.2.1 Requerimientos de los usuarios......................................................... 16

1.2.2 Actores involucrados.......................................................................... 19

1.3 Requerimientos para el análisis y la negociación. ....................................26

1.3.1 Requerimientos para el análisis......................................................... 26

1.3.2 Requerimientos para la negociación. ................................................. 31

1.4 Requerimientos para la gestión. .............................................................. 32

1.4.1 Requerimientos duraderos y volátiles ................................................ 34

1.4.2Planificación de la gestión de requerimientos.....................................35

1.4.3 Gestión de cambio de los requerimientos ..........................................36

Planificación del sistema ................................................................................... 37

2.1 Planificación del tiempo........................................................................... 39

2.1.1 Gráficos de barras y redes de actividades......................................... 41

2.2 Evaluación del costo beneficio................................................................. 44

2.2.1 Productividad..................................................................................... 452.2.2 Técnicas de estimación...................................................................... 46

2.2.3 Modelo algorítmico de costos. .......................................................... 48

2.3 Estudio de viabilidad. ............................................................................... 49

2.4 Planificación de la documentación. .......................................................... 50

2.4.1 El documento de requerimientos del software...................................51

Page 3: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 3/86

 

     0     0     8

Planificación y Modelado

2.5 Gestión de la configuración del software................................................. 53

2.5.1. Líneas base....................................................................................... 54

2.5.2 Elemento de configuración del software............................................ 56

2.5.3 El proceso de la configuración del software. ......................................58

2.5.4 Identificación de objetos en GCS....................................................... 58

2.5.5 Control de versiones.......................................................................... 59

2.5.6 Control de cambios............................................................................ 61

2.5.7 Auditoria de la configuración............................................................. 64

2.5.8 Informes de estado............................................................................ 65

Análisis del proyecto......................................................................................... 66

3.1 Análisis de riesgos................................................................................... 66

3.2 Control de calidad.................................................................................... 68

Análisis de los requerimientos.......................................................................... 70

4.1 Requerimientos funcionales y no funcionales.......................................... 72

4.1.1 Requerimientos funcionales............................................................... 72

4.1.2 Requerimientos no funcionales. ......................................................... 74

4.2 Casos de uso............................................................................................ 76

4.2.1 Los Casos de uso y el valor del sistema............................................. 76

4.3 Diseño de interfaz de usuario.................................................................. 80

4.3.1 Reglas en el diseño de interfaz de usuario. ....................................... 83

Page 4: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 4/86

 

     0     0     8

Planificación y Modelado

Unidad 1

Procesos de la ingeniería de requerimientos.

¿Qué son requerimientos? normalmente, un tema de ingeniería de softwaretiene diferentes significados. De las muchas definiciones que existen pararequerimiento, a continuación se presenta la definición que aparece en elglosario de la IEEE:

1. Una condición o necesidad de un usuario para resolver un problema o

alcanzar un objetivo.

2. Una condición o capacidad que debe estar presente en un sistema ocomponentes de sistema para satisfacer un contrato, estándar,especificación u otro documento formal.

3. Una representación documentada de una condición o capacidad como en1 y 2.

Los requerimientos pueden dividirse en funcionales y 

requerimientos no funcionales.

Los requerimientos funcionales definen las funciones que el sistema será capazde realizar. Describen las transformaciones que el sistema realiza sobre lasentradas para producir salidas.

Los requerimientos no funcionales tienen que ver con las característicasque de una u otra forma puedan limitar el sistema, como por ejemplo, elrendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustezdel sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad,estándares, etcétera.

Características de los requerimientos. Las características de unrequerimiento son sus propiedades principales. Un conjunto de requerimientosen estado de madurez, deben presentar una serie de características tantoindividualmente como en grupo. A continuación se presentan las másimportantes.

• Necesario: Un requerimiento es necesario si su omisión provoca unadeficiencia en el sistema a construir, y además su capacidad,

Page 5: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 5/86

 

     0     0     8

Planificación y Modelado

características físicas o factor de calidad no pueden serreemplazados por otras capacidades del producto o del proceso.

• Conciso: Un requerimiento es conciso si es fácil de leer y entender.Su redacción debe ser simple y clara para aquellos que vayan a

consultarlo en el futuro.• Completo: Un requerimiento está completo si no necesita ampliar

detalles en su redacción, es decir, si se proporciona la informaciónsuficiente para su comprensión.

• Consistente: un requerimiento es consistente si no es contradictoriocon otro requerimiento.

• No  ambiguo: Un  requerimiento no es ambiguo cuando tiene unasola interpretación. El lenguaje usado en su definición, no debecausar confusiones en el lector.

• Verificable: un requerimiento es verificable cuando puede sercuantificado de manera que permita hacer uso de los siguientesmétodos de verificación: inspección, análisis, demostración opruebas.

Dificultades para definir los requerimientos.

• Los requerimientos no son obvios y vienen de muchas fuentes.

• Son difíciles de expresar con palabras (el lenguaje es ambiguo).

• Existen muchos tipos de requerimientos y diferentes niveles de detalle.

• La cantidad de requerimientos en un proyecto puede ser difícil demanejar.

• Nunca son iguales. Algunos son más difíciles, más riesgosos, másimportantes o más estables que otros.

• Los requerimientos están relacionados unos con otros, y a su vez serelacionan con otras partes del proceso.

• Cada requerimiento tienen propiedades únicas y abarcan áreasfuncionales específicas.

• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

Page 6: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 6/86

 

     0     0     8

Planificación y Modelado

• Son difíciles de cuantificar, ya que el conjunto de requerimientos esparticular para cada proyecto. Ingeniería de requerimientos vs.Administración de requerimientos.

Nota: el proceso de recopilar, analizar y verificar las necesidades del cliente

 para un sistema es llamado ingeniería de requerimientos.

La meta de la ingeniería de requerimientos (IR) es entregar unaespecificación de requisitos de software correcta y completa. A continuación sedarán algunas definiciones para ingeniería de requerimientos.

“Ingeniería de requerimientos es la disciplina para desarrollar unaespecificación completa, consistente y no ambigua, la cual servirá como basepara acuerdos comunes entre todas las partes involucradas y en dónde sedescriben las funciones que realizará el sistema” Boehm 1979.

“Ingeniería de requerimientos es el proceso por el cual se transforman

los requerimientos declarados por los clientes, ya sean hablados o escritos, aespecificaciones precisas, no ambiguas, consistentes y completas delcomportamiento del sistema, incluyendo funciones, interfaces, rendimiento ylimitaciones” STARTS Guide 1987.

“Es el proceso mediante el cual se intercambian diferentes puntos devista para recopilar y modelar lo que el sistema va a realizar. Este procesoutiliza una combinación de métodos herramientas y actores, cuyo producto esun modelo del cual se genera un documento de requerimientos” Leite 1987.

“Ingeniería de requerimientos es un enfoque sistemático para recolectar,

organizar y documentar los requerimientos del sistema; es también el procesoque establece y mantiene acuerdos sobre los cambios de requerimientos, entrelos clientes y el equipo del proyecto” Rational Software.

Importancia de la ingeniería de requerimientos.

Los principales beneficios que se obtienen de la ingeniería derequerimientos son:

• Permite gestionar las necesidades del proyecto en formaestructurada: cada actividad de la IR consiste de una serie de

pasos organizados y bien definidos.

• Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: la IR proporciona un punto de partida paracontroles subsecuentes y actividades de mantenimiento, talescomo estimación de costos, tiempo y recursos necesarios.

Page 7: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 7/86

 

     0     0     8

Planificación y Modelado

• Disminuye los costos y retrasos del proyecto: muchos estudioshan demostrado que reparar errores por un mal desarrollo nodescubierto a tiempo, es sumamente caro; especialmenteaquellas decisiones tomadas durante el análisis.

Mejora la calidad del software: la calidad del software tiene quever con cumplir un conjunto de requerimientos (funcionalidad,facilidad de uso, confiabilidad, desempeño, etcétera.).

• Mejora la comunicación entre equipos: la especificación derequerimientos representa una forma de consenso entre clientes ydesarrolladores. Si este consenso no ocurre, el proyecto no seráexitoso.

• Evita rechazos de usuarios finales: la ingeniería de requerimientosobliga al cliente a considerar sus requerimientos cuidadosamente

y revisarlos dentro del marco del problema, por lo que se leinvolucra durante todo el desarrollo del proyecto.

1.1 Requerimientos de proceso.

La ingeniería de requerimientos, proporciona un mecanismo apropiado paraentender lo que el cliente quiere, analizar las necesidades, evaluar lafactibilidad, negociar una solución razonable, especificar la solución sinambigüedades, validar la especificación, y administrar los requisitos conformeéstos se transformen en un sistema operacional. Los requerimientos deproceso se llevan a cabo a través de siente distintas funciones: inicio,

obtención, elaboración, negociación, especificación, validación y gestión.

Page 8: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 8/86

 

     0     0     8

Planificación y Modelado

Resulta importante destacar que algunas de estas funciones de laingeniería de requerimientos ocurren en paralelo y que todas deben adaptarsea las necesidades del proyecto. Todas están dirigidas a definir lo que el clientequiere, y todas sirven para establecer una base sólida respecto al diseño y laconstrucción de lo que obtendrá el cliente.

Nota: Se debe esperar la realización de una parte del diseño durante el trabajo

de los requisitos y una parte del trabajo de los requisitos durante el diseño.

1.1.1 Inicio.¿Cómo se inicia un proyecto de software? ¿Es un evento aislado que seconvierte en el catalizador para un nuevo sistema o producto basado encomputadora? ¿O la necesidad evoluciona con el tiempo? No existenrespuestas definitivas para estas preguntas.

Nota: “Por lo general, las semillas de los desastres más importantes en

software se siembran en los primeros tres meses desde el comienzo del

 proyecto” Capers Jones.

En algunos casos, una conversación informal es todo lo que se necesitapara precipitar un esfuerzo importante de ingeniería de software. Pero engeneral, la mayoría de los proyectos se inician cuando se identifica unanecesidad de negocios o se descubre un nuevo mercado o servicio potencial.Los participantes de la comunidad de negocios (es decir, los gerentes, gente demercadotecnia, gerentes de producto) definen un caso de negocios para laidea, tratan de identificar la amplitud y profundidad del mercado, hacen unanálisis preliminar de factibilidad, e identifican una descripción funcional del

ámbito del proyecto. Toda esa información está sujeta a cambios (unasituación probable), pero suficiente para suscitar conversaciones con laorganización de ingeniería de software.

Al inicio del proyecto los ingenieros de software hacen una serie depreguntas libres de contexto. El objetivo es establecer una comprensión básicadel problema, las personas que quieren una solución, la naturaleza de lasolución que se desea, y la efectividad de la comunicación preliminar entre elcliente y el desarrollador.

1.1.2 Obtención.

En verdad parece muy simple preguntarle al cliente, a los usuarios, y otrosinteresados cuáles son los objetivos para el sistema o el producto, qué es loque se debe lograr, de qué forma el producto satisface las necesidades delnegocio y por último cómo se utilizará el sistema o producto día a día. Pero noes simple, es muy difícil.

Christel y Kang identifican una serie de problemas que ayudan aentender por qué es difícil la obtención de requisitos:

Page 9: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 9/86

 

     0     0     8

Planificación y Modelado

• Problemas de ámbito. El límite del sistema está mal definido o losclientes/usuarios especifican detalles técnicos innecesarios que puedenconfundir, en lugar de clarificar, los objetivos generales del sistema.

• Problemas de comprensión. Los clientes/usuarios no están seguros

por completo de qué es lo que se necesita, comprenden poco acerca delas capacidades y limitaciones de su ambiente de cómputo, nocomprenden del todo el dominio del problema, tienen dificultades alcomunicar necesidades al ingeniero de sistemas, omiten informaciónque consideran “obvia”, especifican requisitos que chocan con lasnecesidades de otros clientes/usuarios, especifican requisitos ambiguoso inestables.

• Problemas de volatilidad. Los problemas cambian conformetranscurre el tiempo.

Para ayudar a superar estos problemas, los ingenieros de requerimientosdeben realizar en forma organizada la actividad de recopilación de requisitos.

1.1.3 Elaboración.La información conseguida con el cliente durante el inicio y obtención seexpande y se refina durante la elaboración. Esta actividad de la ingeniería derequerimientos se enfoca en el desarrollo de un modelo técnico refinado de lasfunciones, características y restricciones del software.

La elaboración es una acción del modelado del análisis y se componende una serie de tareas del modelado y refinamiento. La elaboración se conduce

mediante la creación y el refinamiento de escenarios del usuario que describenla forma en que el usuario final (y otros actores interactúan con el sistema)interactuarán con el sistema. Cada escenario del usuario se analiza paraobtener clases de análisis: entidades del dominio del negocio visibles para elusuario final. Se definen los atributos de cada clase de análisis y se identificanlos servicios que requiere cada clase. Se identifican las relaciones y lacolaboración entre las clases y se produce una variedad de diagramas de UMLcomplementarios.

Nota: la elaboración es buena, pero se debe saber cuándo detenerla. La clave

es describir el problema de una forma que establezca una base firme para el

diseño. Si se trabaja más allá de ese punto, se estará haciendo diseño.

El resultado final de la elaboración es un modelo de análisis que define eldominio de la información, las funciones y el comportamiento del problema.

1.1.4 Negociación.Dados los recursos limitados del negocio, no resulta inusual que los clientes yusuarios pidan más de lo que se puede lograr. También es relativamente

Page 10: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 10/86

 

     0     0     8

Planificación y Modelado

común que diferentes cliente o usuarios propongan requisitos que entran enconflicto entre sí al argumentar que su versión es “esencial para nuestrasnecesidades especiales”.

El ingeniero de requerimientos debe conciliar estos conflictos por medio

de un proceso denegociación

. Se pide a los clientes, usuarios y a otrosinteresados que ordenen sus requisitos y después discutan los conflictosrelacionados con la prioridad. Se identifican y analizan los riesgos asociadoscon cada requisito. Se hacen “estimaciones” preliminares del esfuerzorequerido para su desarrollo y después se utilizan para evaluar el impacto decada requisito en el costo del proyecto y sobre el tiempo de entrega. Medianteun enfoque iterativo, los requisitos se eliminan, combinan o modifican de formaque cada parte alcance cierto grado de satisfacción.

Nota: en una negociación eficaz no debe haber ni ganador ni perdedor. Ambas

 partes ganan porque se solidifica un “trato” con el que las dos pueden vivir.

1.1.5 Especificación.En el contexto de los sistemas basados en computadora (y en software), eltérmino especificación tiene significados diferentes para personas distintas.Una especificación puede ser un documento escrito, un conjunto de modelosgráficos, un modelo matemático formal, una colección de escenarios de uso, unprototipo o cualquier combinación de estos.

Algunos sugieren que para una especificación se debe desarrollar yutilizar una “plantilla estándar”, argumentan que esto conduce a que losrequisitos sean presentados de manera más consistente y por ende más

entendible. Sin embargo, algunas veces es necesario ser flexible mientras sedesarrolla una especificación. Respecto de sistemas grandes el mejor enfoquepodría ser un documento escrito que combinara descripciones en lenguajenatural y modelos gráficos. Por otro lado, en cuanto a productos o sistemasmás pequeños, podría ser que no se necesite más que escenarios de uso,cuando dichos sistemas residan en ambientes técnicos que se comprendanbien.

Nota: la formalidad y el formato de una especificación varían con el tamaño y 

la complejidad del software que se va a construir.

La especificación es el producto de trabajo final que genera la ingenieríade requerimientos. Sirve como base para las actividades de ingeniería desoftware subsecuentes.

Describe la función y el desempeño de un sistema basado encomputadora y las restricciones que regirá su desarrollo.

Page 11: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 11/86

 

     0     0     8

Planificación y Modelado

1.1.6 Validación.La calidad de los productos de trabajo procedentes de la Ingeniería derequerimientos se evalúa durante un paso de validación. La validación derequerimientos examina la especificación para asegurar que todos losrequerimientos de software se han establecido de manera precisa; que se han

detectado inconsistencias, omisiones y errores y que éstos han sido corregidos,y que los productos de trabajo cumplen con los estándares establecidos para elproceso, proyecto y producto.

Nota: un interés clave durante la validación de requisitos es la consistencia. Se

recomienda utilizar el modelo de análisis para asegurar que los requisitos se

han establecido de madera consistente.

El mecanismo primario para la validación de requerimientos es larevisión técnica formal. El equipo de revisión que valida los requisitos incluyeingenieros de software, clientes, usuarios y otros interesados que examinan la

especificación y buscan errores en el contenido o en la interpretación, áreasque tal vez requieren una clasificación, información faltante, inconsistencias(que es un problema importante cuando se desarrollan productos o sistemasgrandes), conflictos entre los requisitos, o requisitos irreales (inalcanzables).

A continuación se muestra una lista de verificación para la validación derequisitos.

Con frecuencia resulta útil examinarcada requisito frente a una serie depreguntas en forma de lista de

verificación. Enseguida se presentaun pequeño subconjunto de laspreguntas que deben realizarse:

• ¿El requisito se puede probar?Sí es así, ¿Se puedenespecificar las pruebas

(algunas veces llamadascriterios de validación) paraejecutar el requisito?

• ¿Los requisitos estánestablecidos de manera clara?¿Éstos puedenmalinterpretarse?

• ¿El requisito es rastreable paracualquier modelo de sistema quehaya sido creado?

• ¿La fuente del requisito (porejemplo, una persona, unaregulación o un reglamento)

está identificada? ¿Elenunciado final del requisitoha sido examinado por lafuente original o comparándolocon ella?

• ¿El requisito es rastreable para losobjetivos generales del sistema oproducto?

• ¿El requisito está restringidoen términos cuantitativos?

• ¿La especificación estáestructurada de una forma queconduzca a su comprensión,

Page 12: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 12/86

 

     0     0     8

Planificación y Modelado

referencia y traducción fácil enproductos de trabajo mástécnicos?

• ¿Cuáles otros requisitos estánrelacionados con este? ¿Están

registrados de manera clarapor medio de una matriz dereferencias cruzadas u otromecanismo?

• ¿Se ha creado un índice para laespecificación?

• ¿El requisito viola algunarestricción del dominio delsistema?

• ¿Los requerimientos asociados conel rendimiento, el desempeño y lascaracterísticas operacionales sehan establecido de manera clara?¿Cuáles requerimientos parecenser implícitos?

 

1.1.7 Gestión de requerimientos.Se sabe que los requerimientos para los sistemas basados en computadorascambian y que el deseo de cambiarlos persiste durante la vida del sistema.

La gestión de requerimientos es un conjunto de actividades que ayudanal equipo de proyecto a identificar, controlar y rastrear los equipos y loscambios a éstos en cualquier momento mientras se desarrolla el proyecto.Muchas de estas actividades son idénticas a las actividades de la gestión de laconfiguración del software (CGS).

Nota: cuando un sistema es grande y complejo, la determinación de las

conexiones entre los requisitos puede ser una tarea redituable. Se recomienda

el uso de las tablas de rastreabilidad para facilitar un poco el trabajo.

A01 A02 A03 A04 A05 Aii

R01

R02

R03

Aspecto especifico del sistema o suambiente

Requisito

Page 13: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 13/86

 

     0     0     8

Planificación y Modelado

R04

R05

Rnn

Figura 1.1 tabla de rastreabilidad

La gestión de requisitos comienza con la identificación. Cada requerimiento se

asigna a un solo identificador. Una vez identificados los requisitos sedesarrollan las tablas de rastreabilidad. En la figura 1.1 se muestra de maneraesquemática una tabla de rastreabilidad, cada una de ellas relaciona losrequisitos con uno o más aspectos del sistema o de su ambiente. Entre lasmuchas tablas de rastreabilidad tenemos las siguientes:

• Tabla de rastreabilidad de las características. Muestra la maneraen que los requerimientos se relacionan con las características delsistema/producto observables para el cliente.

• Tabla de rastreabilidad de la fuente. Identifica la fuente de cada

requerimiento.

• Tabla de rastreabilidad de dependencia. Indica la forma en que losrequisitos están relacionados entre sí.

• Tabla de rastreabilidad del subsistema. Establece categorías entrelos requerimientos de acuerdo con los subsistemas que gobiernan.

• Tabla de rastreabilidad de la interfaz. Muestra la forma en que losrequerimientos se relacionan con las interfaces internas y externas delsistema.

En muchos casos, estas tablas de rastreabilidad se mantienen comoparte de la base de datos de los requerimientos de forma que puedebuscárseles con rapidez para entender cómo el cambio en un requisito afectarádiferentes aspectos del sistema que se construirá.

Herramientas de software para la ingeniería de requerimientos.

Page 14: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 14/86

 

     0     0     8

Planificación y Modelado

Las herramientas de la ingeniería de requerimientos ayudan en la recopilación,modelado, gestión y validación de los requerimientos.

Mecánica. La mecánica de las herramientas varia. Por lo general, lasherramientas de la ingeniería de requerimientos construyen una variedad de

modelos gráficos (por ejemplo, UML) que muestran los aspectos deinformación, funcionamiento y comportamiento de un sistema. Estos modelosforman la base para todas las otras actividades en el proceso del software.

1.2 Requerimientos de los usuarios (actores involucrados).

Ian Sommerville, establece en su Libro (Ingeniería de Software 6º edición,Pearson Educación), que algunos de los problemas que surgen durante elproceso de ingeniería de requerimientos son resultado de no hacer una claraseparación entre los diferentes niveles de descripción. Esto se hace utilizandoel término requerimientos del usuario, para designar los requerimientosabstractos de alto nivel, y requerimientos del sistema, para designar ladescripción detallada de lo que es sistema debe de hacer. De igual forma que

Page 15: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 15/86

 

     0     0     8

Planificación y Modelado

en estos dos niveles de detalle, se puede producir una descripción másdetallada (una especificación del diseño del software) para establecer unpuente entre la ingeniería de requerimientos y las actividades de diseño. Losrequerimientos del usuario, los del sistema y la especificación del diseño delsoftware se definen como se muestra a continuación:

1. Los requerimientos del usuario son declaraciones en lenguaje natural yen diagramas, de los servicios que se espera que el diagrama provea yde las restricciones bajo las cuales debe operar.

2. Los requerimientos del sistema establecen con detalle los servicios yrestricciones del sistema. El documento de requerimientos del sistema,algunas veces denominado especificación funcional, debe ser preciso.Éste sirve como un contrato entre el comprador del sistema y eldesarrollador del software.

3. Una especificación del diseño del software es una descripción abstractadel diseño del software que es una base para un diseño eimplementación detallados. Esta especificación agrega detalle a laespecificación de requerimientos del sistema.

Figura 1.2 Requerimientos del usuario y del sistema.

Diferentes niveles de especificación del sistema son de utilidad debido a

que comunican la información del sistema a los diferentes tipos de lectores. Lafigura 1.2 ilustra la diferencia entre los requerimientos del usuario y delsistema. Muestra la manera en que un requerimiento del usuario se expandeen varios requerimientos del sistema.

 

Definición de requerimientos del usuario.

1. El software debe proveer un medio para representar y acceder a archivosexternos creados por otras herramientas.

Especificación de los requerimientos del sistema.

1.1 Al usuario se le proveerá con los recursos para definir el tipo de archivosexternos.

1.2 Cada tipo de archivo externo tendrá una herramienta asociada que seráaplicada al archivo.

1.3 Cada tipo de archivo externo se representara como un icono especifico sobrela pantalla del usuario.

1.4 Se proveerán recursos para que el usuario defina el icono que representa untipo de archivo externo.

1.5 Cuando un usuario selecciona un icono que representa un archivo externo, elefecto de esta selección es aplicar la herramienta asociada con este tipo dearchivo al archivo representado por el icono seleccionado.

Requerimientosdel usuario.

Administradores clientes.Usuarios finales delsistema.Ingenieros clientes.Administradores

Page 16: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 16/86

 

     0     0     8

Planificación y Modelado

Figura 1.3 Lectores de los diferentes tipos de especificaciones.

Los requerimientos del usuario se redactan para el cliente y loscontratistas administradores quienes no tienen un conocimiento técnico

detallado del sistema (vea la figura 1.3). La especificación de requerimientosdel sistema se orienta al personal técnico y a los administradores del proyecto. También lo utilizaran tanto el equipo de cliente como el del contratista. Losusuarios finales del sistema pueden leer ambos documentos. Finalmente, laespecificación del diseño del software es un documento orientado a laimplementación. Debe redactarse por los ingenieros de software quedesarrollaran el sistema.

1.2.1 Requerimientos de los usuarios.Los requerimientos de los usuarios para un sistema describen losrequerimientos funcionales y no funcionales de tal forma que sean

comprensibles por los usuarios del sistema que no posean un conocimientotécnico detallado. Únicamente especifican el comportamiento externo delsistema y evitan, en tanto sea posible, las características del diseño delsistema. Por consiguiente, los requerimientos del usuario no se deben definirutilizando un modelo de implementación. Deben redactarse utilizando ellenguaje natural, representaciones y diagramas intuitivos sencillos.

Sin embargo, pueden surgir diversos problemas cuando se redactan enlenguaje natural:

1.Falta de claridad. Algunas veces es difícil utilizar el lenguaje en forma

precisa y no ambigua sin detallar el documento y hacerlos fácil de leer.

2.Confusión de requerimientos.  No se distinguen claramente losrequerimientos funcionales y no funcionales, las metas del sistema y lainformación para el diseño.

3.Conjunción de requerimientos. Diversos requerimientos diferentes seexpresan de forma conjunta como un único requerimiento.

Requerimientosdel sistema.

Usuarios finales delsistema.Ingenieros clientes.

Arquitectos del sistema.Desarrolladores delsoftware.

Especificación deldiseño del

 

Ingenieros clientes(quizás).Arquitectos del sistema.Desarrolladores delsoftware

Page 17: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 17/86

 

     0     0     8

La base de datos deberá ayudar a la generación y control de la configuración deobjetos; es decir, objetos que a su vez son agrupaciones de otros de la base de datos.Los recursos para este control permitirán el acceso a los objetos en una versión de

Planificación y Modelado

Figura 1.4 un requerimiento de una base de datos para un entorno de programación.

Para ilustrar algunos de estos problemas, considere uno de losrequerimientos para un entorno de programación Ada que se muestra en lafigura 1.4.

Este requerimiento incluye tanto información conceptual como detallada.Expresa la existencia de recursos de control de la configuración como unaparte inherente del APSE. Sin embargo, ésta también incluye el detalle de quelos recursos de control de la configuración que permiten el acceso a los objetosen una versión de grupo sin especificar su nombre completo. Este detallepodría ubicarse mejor en la especificación de requerimientos del sistema.

Nota: APSE significa, Entorno de Ayuda a la programación en Ada.

En el documento de requerimientos es una buena práctica separar losrequerimientos del usuario de los detallados del sistema. Por otra parte, loslectores no técnicos de los requerimientos del usuario se confundirán con losdetalles que sólo son relevantes a los lectores técnicos. La figura 1.5 ilustraesta confusión.

Figura1.5 Un requerimiento de usuario para un editor de cuadrícula.

Este ejemplo se tomó del documento de requerimientos para unaherramienta CASE para editar modelos de diseño de software. El usuarioespecifica que se desplegará una cuadrícula para que las entidades secoloquen de forma precisa en un diagrama.

La primera oración mezcla tres diferentes clases de requerimientos.

1. Un requerimiento funcional conceptual que establece que el sistema deedición proveerá una cuadrícula. Se presenta la justificación de esto.

2. Un requerimiento no funcional que provee información detallada de lasunidades de la cuadrícula (centímetros o pulgadas).

3. Un requerimiento de interfaz de usuario no funcional que define lamanera en que esa cuadrícula es activada o desactivada por el usuario.

Recursos de la cuadrícula. Para ayudar a la ubicación de entidades en un diagrama, elusuario activará una cuadricula en centímetros o en pulgadas, mediante una opción en elpanel de control. De forma inicial, dicha cuadrícula estará desactivada. Ésta cuadrícula se

podrá activar o desactivar en cualquier momento durante una sesión de edición y puesta enpulgadas y en centímetros. La opción de cuadrícula se proveerá en la vista de reducción deajuste, pero el número de líneas de la cuadrícula a mostrar se reducirá para evitar saturar el

Page 18: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 18/86

 

     0     0     8

Planificación y Modelado

El requerimiento de la figura 1.5 también muestra un parte de lainformación de inicialización. Define que la cuadrícula está inicialmentedesactivada. Sin embargo, no define sus unidades cuando se activa. Proveealguna información detallada, como la de intercambiar unidades, pero no elespacio entre las líneas de la cuadrícula.

Cuando los requerimientos del usuario incluyen demasiada información,restringen la libertad del desarrollador del sistema para proveer solucionesinnovadoras a los problemas del usuario y hace que los requerimientos seandifíciles de comprender. Los requerimientos del usuario simplemente debenenfocarse a los recursos principales a proveer. Esto se ilustra en la figura 1.6,donde se redactan nuevamente los requerimientos para el editor de lacuadrícula, con énfasis en las características esenciales del sistema.

Figura 1.6 Una definición de un recurso para el editor de cuadrícula.

La base asociada a los requerimientos es importante. Ayuda a losdesarrolladores y mantenedores del sistema a entender por qué elrequerimiento se incluye y a valorar el impacto de los cambios en éstos. Por

ejemplo, en la figura 1.6 la base declara que es de utilidad que una cuadrículaactiva situé automáticamente objetos a una línea de la cuadrícula. Sinembargo, de forma deliberada se rechaza esta opción cuando se hace unaubicación manual. Sí en alguna etapa posterior se propone un cambio a esto,entonces es claro que la utilización de una cuadrícula pasiva es mucho mejorque una decisión de implementación.

 

Recursos de la cuadrícula.

El editor deberá proporcionar un recurso para la cuadrícula donde una matriz delíneas horizontales y verticales proporciona un fondo para la ventana del editor. Esta

cuadrícula deberá ser pasiva, donde la alineación de entidades es responsabilidad delusuario.

Fundamento: Una cuadrícula ayuda al usuario a crear un diagrama ordenado conentidades bien espaciadas. Aunque en una cuadrícula activa pueda ser de utilidadque las entidades se ajusten a las líneas de la cuadrícula, la ubicación es imprecisa.

Adición de nodos a un diseño.

El editor deberá proporcionar un recurso a los usuarios para agregar a sudiseño nodos de un tipo especifico.

La secuencia de acciones para agregar un nodo debería ser como se muestra acontinuación:

1. El usuario selecciona el tipo de nodo a agregar.

2. El usuario mueve el cursor a la proximidad de la posición del nodo en eldiagrama e indica que el símbolo de dicho nodo debe agregarse en estepunto.

3. Después el usuario arrastra el símbolo del nodo a su posición final.

Fundamento: El usuario es la mejor persona para decidir dónde ubicar unnodo en un diagrama. Este enfoque da al usuario control directo sobre la

selección del tipo de nodo y sobre la ubicación.

Page 19: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 19/86

 

     0     0     8

Planificación y Modelado

Figura 1.7 Requerimientos del usuario para la creación de nodos.

En la figura 1.7 se muestra un ejemplo adicional de un requerimiento delusuario más específico, que también define parte del sistema de edición. Esta

es una especificación más detallada de la función. En este caso, la definiciónincluye una lista de las acciones del usuario. Algunas veces, esto es necesariopara que todas las funciones se proporcionen de forma consistente. Losdetalles de la implementación no deben incluirse en esta información adicional.Por lo tanto, la definición no establece como se mueven el cursor y el símbolo,o cómo se selecciona el tipo.

Para minimizar las malas interpretaciones al redactar los requerimientos delusuario, se recomienda seguir unas pautas sencillas para redactarrequerimientos:

1. Inventar un formato estándar y asegurar que todos los requerimientos seadhieren al formato. Estandarizar el formato significa reducir laprobabilidad de las omisiones y hacer que los requerimientos seanfáciles de verificar. El formato incluye poner en negritas el requerimientoinicial, que incluye una declaración base para cada requerimiento delusuario, y una referencia a la especificación detallada de losrequerimientos para el sistema.

2. Utilizar el lenguaje de forma consistente. en particular, distinguir entrelos requerimientos deseables y los obligatorios. Es común definir estosúltimos en futuro simple y los deseables en futuro condicional como se

muestra en la figura 1.7. por lo tanto es obligatorio que el sistemaincluya un recurso para agregar nodos a un diseño. Es necesario que lasucesión de acciones se especifique. Pero no es absolutamente esencialsi existe buenas razones para hacerlo.

3. Resalta el texto (con negritas o itálicas) para ver las partes claves delrequerimiento.

4. Evitar, hasta donde sea posible, utilizar el lenguaje “técnico” decomputación. Sin embargo, en los requerimientos de usuario seráinevitable utilizar términos técnicos detallados provenientes del dominio

de aplicación del sistema.

1.2.2 Actores involucrados.Los actores en los sistemas de información se dividen en cinco grupos:

1. Dueños del sistema.

2. Usuarios del sistema.

Page 20: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 20/86

 

     0     0     8

Planificación y Modelado

3. Diseñadores de sistemas.

4. Constructores de sistemas.

5. Analistas de sistemas.

A continuación se exponen cada uno de estos grupos.

1.2.2.1 Dueños del sistema.

Para cualquier sistema de información grande o pequeño habrá uno o másdueños del sistema, los dueños del sistema tienden a estar interesados en:

• ¿Cuánto costara el sistema?

• ¿Cuál será el costo/beneficio?

• ¿Cuándo recuperaran la inversión y como la recuperaran?

 Y otras, las cuales son de interés económico primordialmente. Este grupo esque paga por el sistema.

1.2.2.2 Usuario del sistema.

Los usuarios del sistema son los que definen los requerimientos del negocio ylas expectativas del sistema. Ellos ven a un sistema de información entérminos de la funcionalidad que provee a sus trabajos, en que sea fácil deaprender y de utilizar.

Hay muchas clases de usuarios, pero para estudiarlos los separaremosen dos grandes clases: usuarios internos y usuarios externos dentro de los

cuales se cuenta con más subdivisiones las cuales se explican a continuación:

Usuarios internos.

Son aquellos empleados del negocio para el cual se está construyendo elsistema y son el mayor porcentaje de usuarios de un sistema. Dentro de estegrupo tenemos.

• Empleados administrativos y de servicios: realizan los procesos deldía a día, procesan órdenes, facturas, pagos etcétera. Ellos capturan losdatos en el sistema.

• Staff técnico y profesional: son empleados que realizan tareasespecializadas ejemplo. Abogados, ingenieros, científicos etcétera.

• Supervisores mandos medios y ejecutivos: son los empleados quetoman decisiones, ya sea decisiones del día a día (supervisores), decorto plazo (mandos medios) o largo plazo (ejecutivos).

Page 21: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 21/86

 

     0     0     8

Planificación y Modelado

Usuarios Externos.

El uso de Internet ha permitido extender los límites de las organizaciones, deforma que se ha generado un aumento de usuarios externos, dentro de loscuales podemos mencionar:

• Clientes: son cualquier organización o persona(s) que compren nuestrosproductos o servicios. Hoy día nuestros clientes se pueden convertir enusuarios directos, ya que pueden ejecutar órdenes y comprasdirectamente al sistema, como por ejemplo las compras online.

• Surtidor o Proveedor: son cualquier organización en la cual nuestracompañía compre insumos. Hoy día nuestros proveedores puedeninteractuar directamente con nuestros sistemas y determinar nuestranecesidad de insumos y crear de forma automática ordenes con dichasnecesidades.

• Socios: son cualquier organización a la cual nuestra compañía compreservicios o de la que sea socio. Ejemplo: mantenimiento, manejo de lared, outsourcing, etc.

• Empleados: son empleados que trabajan en el camino o en casa.Ejemplo: representantes de venta, empleados que puedan trabajarremotamente en el sistema.

La cantidad de usuarios externos ha ido en aumento en los últimos tiempos,ellos se conectan a la información de la compañía a través de laptos,

handhelds y smartphones (ya se con conexión en bases o vía inalámbrica) porlo que debemos tener presente el uso de estos dispositivos al momento derealizar el diseño del sistema.

1.2.2.3 Diseñadores del sistema.

Son técnicos especializados que traducen los requerimientos de los usuariosdel negocio en soluciones técnicas. Ellos diseñan: bases de datos, entradas ysalidas del sistema, pantallas, redes y software que se puede adaptar a losrequerimientos del usuario.

Un diseñador del sistema puede pertenecer a algunas de las siguientes

especialidades:• Administrador de la base de datos. Son especialistas en bases de

datos, se encargan de realizar el diseño de la base de datos, y lacoordinación de cambios en bases de datos corporativas.

• Arquitectos de redes. Se especializan en redes y telecomunicaciones.

Page 22: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 22/86

 

     0     0     8

Planificación y Modelado

• Arquitectos web. se encargan de diseñar sitios web para lasorganizaciones, generalmente de un alto grado de complejidad.

• Artistas gráficos. Son especialistas en la tecnología grafica y enmétodos de diseño de interfaces fáciles de utilizar. (en pc, web,

handheld, smartphones, etc).• Expertos en seguridad. Son en especialistas en tecnología y

metodologías utilizadas para asegurar la integridad y la privacidad de losdatos y la red.

• Especialistas en tecnología. Son expertos en la aplicación detecnologías específicas que podrían ser utilizadas en un sistema. Tantoen paquetes de software como en hardware con característicasespecificas.

1.2.2.4 Constructores del sistema.

Su rol es la construcción del sistema de acuerdo a las especificaciones dadaspor el diseñador de sistemas.

Un constructor del sistema puede pertenecer a algunas de las siguientesespecialidades:

• Programador de aplicaciones. son especialistas que convierten losrequerimientos de la compañía en lenguajes de programación. Ellosdesarrollan y prueban programas de computación que capturan yalmacenan datos.

• Programadores de sistemas. son especialistas que desarrollan,prueban e implementan software a nivel de sistema operativo.

• Programadores de bases de datos. Son especialistas en tecnologíasy lenguajes de bases de datos, que construyen, modifican y prueban lasestructuras de las bases de datos así como los programas que se utilizanpara darles mantenimiento a las mismas.

• Administradores de redes. Son especialistas que diseñan, instalan yoptimizan las redes de computadoras.

• Administradores de seguridad. Son especialistas que diseñan,implementan y manejan la seguridad y controles de privacidad de unared.

• Webmaster. Son especialistas que codifican y dan mantenimiento a losservidores Web.

Page 23: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 23/86

 

     0     0     8

Planificación y Modelado

• Integradores de software. Son especialistas que integran paquetesde software con hardware, redes y otros paquetes de software.

1.2.2.5 Analista de sistemas.

Es un especialista que estudia los problemas y necesidades de una

organización para determinar cómo las personas, datos, procesos y latecnología de la información pueden en conjunto mejorar un negocio.

Roles del analista de sistemas.

El analista de sistemas evalúa de manera sistemática el funcionamiento de unnegocio mediante el examen de la entrada, el procesamiento de datos y suconsiguiente producción de información, con el propósito de mejorara losprocesos de una organización. Muchas mejoras incluyen un mayor apoyo a lasfunciones de negocio a través del uso de sistemas de informacióncomputarizados.

Un analista debe tener la capacidad de trabajar con todo tipo de gente ycontar con suficiente experiencia en computadoras. El analista desempeñadiversos roles, en ocasiones varios de ellos al mismo tiempo. Los tresprincipales roles del analista de sistemas son el de consultor, experto ensoporte técnico y agente de cambio.

El rol de consultor del analista de sistemas. Con frecuencia, elAnalista de Sistemas desempeña el rol de consultor para un negocio y, portanto podría ser contratado de manera específica para enfrentar los problemasde sistemas de información de una empresa. Esta contratación se puede

traducir en una ventaja porque los consultores externos tienen una perspectivafresca de la cual carecen los demás miembros de una organización. Tambiénse puede traducir en una desventaja porque alguien externo nunca conocerá laverdadera cultura organizacional. En su función de consultor externo, usteddependerá en gran medida de los métodos sistemáticos que se deberáaprender de los libros sobre el análisis y diseño de sistemas de información.Además tendrá que apoyarse en los usuarios de los sistemas de informaciónpara entender la cultura organizacional desde el punto de vista que ellostienen.

El rol de experto en soporte técnico del analista de sistemas.

Otro rol que tendrá que desempeñar es el de experto en soporte técnico dentrode la empresa en la cual labora de manera regular. En este rol el analistarecurre a su experiencia profesional con el hardware y software de cómputo yal uso que se le da en el negocio. Con frecuencia, este trabajo no implica unproyecto completo de sistemas, sino más bien la realización de pequeñasmodificaciones o la toma de decisiones que se circunscriben a un solodepartamento.

Page 24: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 24/86

 

     0     0     8

Planificación y Modelado

Como experto en soporte técnico, usted no está a cargo del proyecto,tan solo actúa como recurso para aquellos que si lo están. Si usted es unanalista de sistemas contratado por una empresa manufacturera o servicios,gran parte de sus actividades podrían ajustarse a este rol.

El rol de agente de cambio del analista de sistemas. El rol máscompleto y de mayor responsabilidad que asume el analista de sistemas es elde agente de cambio, ya sea interno o externo para la empresa. Como analista,usted es un agente de cambio si desempeña cualquiera de las actividadesrelacionadas con el ciclo de vida del desarrollo de sistemas y está presente enla empresa durante un largo periodo (de dos semanas a más de un año). Unagente de cambio se puede definir como alguien que sirve de catalizador parael cambio, desarrolla un plan para el cambio y coopera con los demás parafacilitar el cambio.

Su presencia en el negocio inicia el cambio. Como analista de datos,

usted debe estar consciente de este hecho y utilizarlo como punto de partidapara su análisis. De ahí que tenga que interactuar con los usuarios laadministración desde el principio del proyecto. Sin su colaboración usted nopodría entender lo que ocurre en una organización y el cambio real nunca sedaría.

Si el cambio (es decir, las mejoras al negocio que se pueden concretarmediante los sistemas de información) parece factible después de efectuar elanálisis, el siguiente paso es desarrollar un plan para el cambio de maneraconjunta con quienes tienen la facultad de autorizarlo. Una vez que se hayaalcanzado el consenso acerca de los cambios por realizar, usted tendrá que

interactuar constantemente con quienes vaya a cambiar.

En su calidad de analista de sistemas desempeñando la función deagente de cambio debe promover un cambio que involucre el uso de lossistemas de información. También es parte de su tarea enseñar a los usuariosel proceso del cambio, ya que las modificaciones a un sistema de informaciónno solo afecta a este sino que provocan cambios en el resto de la organización.

Cualidades del analista de sistemas.

De las descripciones anteriores sobre los roles que desempeña el analista de

sistemas, se deduce fácilmente que el analista exitoso debe contar con unaamplia gama de cualidades. Hay una gran diversidad de personas trabajandocomo analistas de sistemas, por lo que cualquier descripción que intente sergeneral está destinada a quedarse corta en algún sentido. No obstante, lamayoría de los analistas de sistemas tienen algunas cualidades comunes.

En primer lugar, el analista es un solucionador de problemas. Es unapersona que aborda como un reto el análisis de problemas y que disfruta al

Page 25: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 25/86

 

     0     0     8

Planificación y Modelado

diseñar soluciones factibles. Cuando es necesario, el analista debe contar conla capacidad de afrontar sistemáticamente cualquier situación mediante lacorrecta aplicación de herramientas, técnicas y su experiencia.

El analista también debe ser un comunicador con capacidad para

relacionarse con los demás durante extensos periodos. Necesita suficienteexperiencia en computación para programar, entender las capacidades de lascomputadoras, recabar los requisitos de información de los usuarios ycomunicarlos a los programadores. Asimismo, debe tener una ética personal yprofesional firme que le ayude a moldear las relaciones con sus clientes.

El analista de sistemas debe ser una persona autodisciplinada yautomotivada, con la capacidad de administrar y coordinar los innumerablesrecursos de un proyecto, incluyendo a otras personas. La profesión de analistade sistemas es muy exigente; pero es una profesión en constante evoluciónque siempre trae nuevos retos.

Page 26: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 26/86

 

     0     0     8

Planificación y Modelado

1.3 Requerimientos para el análisis y la negociación.

Una vez recopilados los requerimientos, el producto obtenido configura la base

de los requerimientos para el análisis. Los requerimientos se agrupan porcategorías y se organizan en sub conjuntos, se estudia cada requerimiento enrelación con el resto, se examinan los requerimientos en su consistencia,completitud y ambigüedad, y se clasifican en base a las necesidades de losclientes/usuarios. Es corriente en clientes y usuarios solicitar más de lo quepuede realizarse, consumiendo recursos de negocios limitados. También esrelativamente común en clientes y usuarios el proponer requisitoscontradictorios, argumentando que esa versión es esencial por necesidadesespeciales.

Nota: el ingeniero de requerimientos debe resolver estos conflictos a través deun proceso de negociación.

Los clientes, usuarios y el resto de intervinientes deberán clasificar susrequerimientos y discutir los posibles conflictos según su prioridad. Los riesgosasociados con cada requerimiento serán identificados y analizados. Seefectúan estimaciones del esfuerzo de desarrollo que se utilizan para valorar elimpacto de cada requerimiento en el costo del proyecto y en el plazo deentrega.

1.3.1 Requerimientos para el análisis.

En esta sección se presenta el análisis global de los requerimientos de unaaplicación, que es un proceso de conceptualización y expresión de losconceptos en forma concreta. La mayor parte de los defectos encontrados enel software entregado se originan durante la obtención de los requerimientospara el análisis. En general, estos defectos también son los más caros dereparar.

1.3.1.1 Significado de requerimientos para el análisis.

Para construir algo primero debe entenderse lo que debe ser “algo”. El procesode entender y documentar este algo se llama “requerimientos para el análisis”.En general, los requerimientos expresan qué se supone debe hacer una

aplicación: por lo común, no intentan expresar cómo lograr estas funciones. Porejemplo, la siguiente afirmación es un requerimiento para una aplicación decontabilidad.

El sistema debe permitir a los usuarios acceso a sus saldos.

En términos generales, la siguiente afirmación no es un requerimiento parauna aplicación.

Page 27: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 27/86

 

     0     0     8

Planificación y Modelado

Los estados de cuenta del cliente se almacenarán en una tabla llamada

“saldos” en una base de datos de Access™.

Esta última afirmación se refiera a cómo debe de construirse la aplicación, y noa qué debe hacer la aplicación.

Un requerimiento en un nivel con frecuencia se traduce en más de unrequerimiento específico en el siguiente nivel más detallado.

Además existen excepciones a la regla de que en los requerimientos seevite especificar cómo debe hacerse algo. Por ejemplo, el cliente del ejemplodel anterior podría, por alguna razón, querer que los estados de cuentas sealmacenen en la base de datos de Access™ con el nombre indicado. En estecaso, la segunda afirmación sería un requerimiento.

La salida de los requerimientos para el análisis es un documento que seconoce como especificación de requerimientos o especificación de

requerimientos de software (ERS).

1.3.1.2 Requerimientos C y requerimientos D.Durante algún tiempo se ha discutido quien es el “dueño” de losrequerimientos: el cliente o el desarrollador. Para manejar este aspecto, elanálisis de requerimientos se divide en dos niveles. El primer nivel documentalos deseos y necesidades del cliente y se expresa en un lenguaje claro para él.Los resultados suelen llamarse “requerimientos del cliente” o “requerimientosc”. La audiencia primaria para los requerimientos C es la comunidad del clientey la secundaria es la comunidad del desarrollador. El segundo nivel documentalos requerimientos de manera específica y estructurada. Éstos se llaman“requerimientos del desarrollador” o “requerimientos D”. La audienciaprimordial de éstos es la comunidad del desarrollador y la secundaria la delcliente.

Aquí se menciona el estándar de IEEE para documentar losrequerimientos. La distinción entre los tipos de requerimientos C y D en lostítulos principales de la plantilla del documento estándar del IEEE se ilustra enla figura 1.8. 

ERS (IEEE)

1. Introducción.2. Descripción

global.3. Requerimient

osespecíficos.

4. InformaciónRequerimientos C

 

Requerimientos D

Page 28: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 28/86

 

     0     0     8

Planificación y Modelado

Figura 1.8 Requerimientos del cliente comparados con los requerimientos detallados.

Aunque las audiencias principales para los requerimientos C y D son diferentes,los clientes y desarrolladores trabajan juntos para crear productos exitosos.Una manera de asegurar una buena comunicación es hacer que representantesde los clientes trabajen junto con los desarrolladores. Algunas organizacionesde desarrollo se rehúsan a aceptar trabajos si no se hace esto.

1.3.1.3 Por qué deben escribirse los requerimientos.Aun para las personas sin experiencia puede ser evidente la necesidad deescribir lo que se supone debe hacer un programa cuando esté terminado. Decualquier forma, este proceso de escribir suele ignorarse o dejarse morir. Enesas situaciones, se cree que el código fuente expresa todos los

requerimientos: como el código fuente es imprescindible, ¿por qué no reducirel proceso completo a este documento esencial? La respuesta es que esto nofunciona. La disciplina de ingeniería de software, los mejores ingenieros desoftware y este libro, insisten en escribir documentos con todo cuidado. Sinellos, el equipo no sabe en realidad cuáles son las metas que intenta lograr, nopuede inspeccionar y probar su trabajo de manera adecuada, no puedecontrolar su productividad, no obtiene datos adecuados de sus prácticas, nopuede predecir el tamaño y esfuerzo de su siguiente trabajo y no puedesatisfacer a sus clientes. En resumen, no existe la ingeniería profesional sin losrequerimientos escritos.

Para ilustrar estos puntos, considere el siguiente requerimiento para unaaplicación científica.

La aplicación debe desplegar la longitud del gene x12345 en la ventana del

sistema (requerimiento 7824).

La figura 1.9 muestra una lista de lo que debe hacerse con éste y los otrosrequerimientos. Además, debe registrarse el tiempo para realizar cada paso,de manera que en futuro se pueda estimar el tiempo para implementarrequerimientos similares en contextos similares. Considere el caos queresultaría si el requerimiento 7824 no estuviera escrito. Muy pocos de los pasos

de los figura 1.9 se podrían llevar a cabo de modo apropiado. No sería desorprender que la aplicación en cuestión no fuera confiable.

 

Cada requerimiento debe.

• Expresarse de modo adecuado.

• Ser de acceso sencillo.

• Numerarse.

• Acompañarse con pruebas que lo verifiquen.

•  Tomarse en cuenta en el diseño.

•  Tomarse en cuenta en el código.

• Probarse aislado.

• Probarse junto con otros requerimientos.

• Validarse con las pruebas después de construir laaplicación.

Page 29: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 29/86

 

     0     0     8

Planificación y Modelado

Figura 1.9 lo que debe hacerse con cada requerimiento.

Cuando se contemplan los pasos de la figura 1.9 para todos y cada uno de losrequerimientos, se obtiene una idea de por qué los ingenieros de softwaremanejan de forma extensa los requerimientos individuales: son el acervobásico más importante de la profesión.

1.3.1.4 mapa conceptual típico del proceso de requerimientos para elanálisis.

La figura 1.10 es un mapa conceptual típico del proceso de requerimientospara el análisis descrito en este capítulo. Este mapa conceptual se consultará

durante cada iteración. El último paso de mapa reúne los requerimientos Ddetallados. El equipo recolecta las mediciones de las etapas de este procesopara facilitar la estimación de iteraciones y aplicaciones futuras.

Figura 1.10 Mapa conceptual típico para los requerimientos C.

Existen varias formas para organizar la especificación de requerimientosde software. Se usará y modificará el estándar IEEE830-1993 que muestra lafigura 1.11. También este es un estándar ANSI.

 

1. Identificar “el cliente”.

2. Entrevistar representantes del cliente.

• Identificar deseos y necesidades.• Aprovechar herramientas de

expresión.• Bosquejar las GUI.• Identificar el hardware.

3. Escribir requerimientos C en forma de documento estándar.

4. inspeccionar los requerimientos C.

5. Construir los requerimientos D.

 

Para todas las etapas, supervisarmétricaspor ejemplo:

•  Tiempo indicado.• Cantidad lograda.

Páginas derequerimientos C.Minutos de interaccióncon el cliente por página.

• Calidad autoevaluada(escala 1 a 10).

•  Tasas de defectos eninspecciones.

Revisión con el cliente

Con la aprobación delcliente

Page 30: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 30/86

 

     0     0     8

1. Introducción.1.1 Propósito.1.2 Alcance1.3 Definiciones, acrónimos y

abreviaturas.1.4 Referencias.1.5 Panorama.

2. Descripción general.2.1 Perspectiva del producto.

2.1.1Interfaces del sistema.2.1.2Interfaces de usuario.2.1.3Interfaces de hardware.2.1.4Interfaces de software.2.1.5Interfaces de comunicación.2.1.6Restricciones de memoria.2.1.7Operaciones.2.1.8Requerimientos de adaptación

del sitio.

2.2 Funciones de producto.2.3 Características del usuario.2.4 Restricciones.2.5 Suposiciones y dependencias.2.6 Distribución de requerimientos.

3. Requerimientos específicos.4. Información de apoyo.

Planificación y Modelado

Los ingenieros de software discuten los méritos de las distintas formasde documentación de los requerimientos. La desventaja del estándar IEEE esque es bastante antiguo y necesita modificarse y ampliarse (para reflejar losavances en el análisis y diseño orientados a objetos y el surgimiento de losaspectos de Internet). La ventaja del estándar IEEE es que abarca la mayor

parte de los aspectos que debenexpresarse de una u otra forma.

Figura 1.11 Contenido del estándar IEEE 830-1993:

especificación de requerimientos de software. Copyright © 1994 IEEE.

1.3.1.5 Retos y beneficios delanálisis de requerimientos.

Un requerimiento defectuoso (es decir, elque no se repara antes de terminar el documento de requerimientos) es muycostoso. Se estima que repararlo es entre 20 y 50 veces más costo si sepermite que pase durante todo el proceso de desarrollo. En términosfinancieros, si el costo de encontrar y reparar un defecto en la etapa derequerimientos es $100, entonces el costo de encontrar y reparar ese mismo

defecto al final del proceso de desarrollo es entre $2000 y $5000. ¿Quiénrechazaría una inversión de $100 que garantiza un pago de $2000 a $5000 enun año o en dos? Piense que cada búsqueda de los defectos en losrequerimientos desde el inicio es una inversión de este tipo.

El daño que resulta de una mala experiencia del cliente con la aplicaciónes un factor por completo adicional al gasto involucrado.

Dado el gran beneficio de detectar y reparar defectos en la etapa derequerimientos, ¿Por qué tantos proyectos sufren daños por un análisis derequerimientos malo o falta del mismo? Una razón es que, por lo general, al

principio de un proyecto los clientes no saben qué quieren o necesitan conexactitud. Los ingenieros que usan un proceso iterativo bien organizado reúnenrequerimientos, diseñan según éstos y los implementan mediante iteracionescoordinadas.

El análisis de requerimientos es una necesidad, no un lujo. Considere susdefectos sobre las pruebas. La mayor parte de las organizaciones de desarrolloconsidera las pruebas una necesidad absoluta. Pero si alguien le proporcionara

Page 31: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 31/86

 

     0     0     8

Planificación y Modelado

una caja negra con un cable morado, uno rosa y uno naranja que salen de ella,y le pidiera que lo probara, lo más seguro es que se negara. Probarla seráimposible ¡sin saber qué se supone que debe lograr! En otras palabras, sinrequerimientos no es posible realizar pruebas adecuadas.

Muchas organizaciones no describen los requerimientos. Esto no significaque no los usen –sólo quiere decir que los requerimientos existen en la mentede ciertos ingenieros de software—. Cuando se considera la falta de efectividadgeneral de los requerimientos no escritos, y el gran número de requerimientosen cada aplicación real, junto con la realidad de la rotación de personal,¿realmente sorprende el porcentaje tan grande de proyectos de software quenunca terminan? Un problema más sutil se crea en las organizaciones queescriben los requerimientos para la iteración inicial, construyen con ellos enmente, pero no actualizan el documento de requerimientos en lasinteracciones que siguen. La razón es que con frecuencia es más difícilactualizar un documento de requerimientos que escribir la primera versión.

(Esto subraya la importancia de la buena organización del documento.) Sinembargo, la situación de que sea más difícil actualizar no altera el hecho deque no escribir los requerimientos ocasionará un alto grado de dificultad.

Un beneficio importante del análisis de requerimientos es lacomprensión y acuerdo de la aplicación que se construirá. Esta es la base detodo tipo de contratos.

1.3.2 Requerimientos para la negociación.En un contexto ideal de la ingeniería de requerimientos, las tareas de inicio,obtención y elaboración determinan los requisitos con el suficiente detalle

como para emprender los pasos subsecuentes de la ingeniería de software.Desgraciadamente, esto sucede muy rara vez. En realidad, el cliente y eldesarrollador entran en un proceso de negociación, en el cual se le debe pediral cliente un balance de la funcionalidad, el rendimiento y otras característicasdel sistema o producto frente al costo y el tiempo de colocación en el mercado.El objetivo de esta negociación es desarrollar un plan de proyecto quesatisfaga las necesidades del cliente al mismo tiempo que refleja lasrestricciones del mundo real (por ejemplo, tiempo, gente, presupuesto) a lasque está sometido el equipo de software.

“un acuerdo es el arte de dividir el pastel de tal forma que cada uno piense

que se quedó con la rebanada más grande”.

Las mejores negociaciones son aquellas que buscan un resultado del tipo“ganar-ganar” esto es, el cliente gana al obtener el sistema o producto quesatisface la mayoría de sus necesidades, y el equipo de software gana altrabajar con presupuestos y límites de tiempo realistas y alcanzables.

Page 32: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 32/86

 

     0     0     8

Planificación y Modelado

Bohem define un conjunto de actividades de negociación en el inicio decada iteración del proceso del software. En lugar de la actividad sencilla decomunicación con el cliente, se definen las siguientes actividades:

1. Identificación de los interesados calve en el sistema o subsistema.

2. Determinación de las “Condiciones ganadoras” de los interesados.

3. Negociación de las condiciones ganadoras de los interesados parareconciliarlas en conjunto de condiciones del tipo ganar-ganar paratodos los involucrados (incluido el equipo de software).

La conclusión exitosa de estos pasos iníciales asegura un resultado del tipoganar-ganar, el cual se convierte en el criterio clave para continuar con lasactividades subsecuentes de la ingeniería de software.

1.4 Requerimientos para la gestión.

En temas anteriores se estableció que los requerimientos para los sistemas decomputadora cambian y que el deseo de cambiarlos persiste durante la vidadel sistema. Los requerimientos para la gestión es un conjunto de actividadesque ayudan al equipo de proyecto a identificar, controlar y rastrear losrequerimientos y los cambios a éstos en cualquier momento mientras sedesarrolla el proyecto.

Nota: formalmente la recopilación de los requerimientos para la gestión

se inicia sólo para proyectos grandes, los cuales tienen cientos de

requerimientos identificables. En los proyectos pequeños esta función de la

ingeniería de requerimientos es bastante menos formal.

Muchas de estas actividades son idénticas a las actividades de la gestiónde la configuración del software (GCS).

 

El arte de la negociación.El aprendizaje del arte de la negociación efectiva es una actividad que sirve a travésde la vida técnica y personal. La consideración de las siguientes directrices puederesultar muy valiosa:1. Reconocer que no es una competencia. Para ser exitoso, ambos lados deben

de tener el sentimiento de haber ganado o logrado algo. Las dos partes tendránque haber llegado a un acuerdo.

2. Diseñar una estrategia. Decidir qué es lo que se desearía lograr; que es loque la otra parte quiere alcanzar, y qué es lo que se va a hacer para que ambascosas sucedan.

3. Escuchar de manera activa. no se debe pensar en formular una respuestamientras la otra parte está hablando. Es necesario escuchar es posible que seobtenga un conocimiento que ayudará a negociar de mejor manera la posiciónpropia.

4. Enfocarse en los intereses de otra parte. Si se quieren evitar los conflictos nose debe de tomar una posición inflexible.

5. No dejar que se vuelva personal. Enfocarse en el problema que debe serresuelto.

6. Ser creativo. Cuando existen situaciones de estancamiento no se debe tenermiedo de pensar fuera de los cánones.

7. Estar listo para pactar. Una vez que se ha llegado a un acuerdo, no esnecesario esperar: se debe pactar dicho convenio y seguir adelante.

Page 33: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 33/86

 

     0     0     8

Planificación y Modelado

Durante el proceso del software, la comprensión del problema por partede los stakeholders está cambiando constantemente. Estos requerimientosdeben entonces evolucionar para reflejar esta perspectiva cambiante delproblema.

Además, una vez que un sistema se ha instalado, inevitablementesurgen nuevos requerimientos. Es difícil para los usuarios y clientes del sistemaanticipar qué efecto tendrá el sistema nuevo en la organización. Cuando losusuarios finales tienen experiencia con un sistema, descubren nuevasnecesidades y prioridades:

1. Normalmente, los sistemas grandes tienen una comunidad deusuarios diversa donde los usuarios tienen diversosrequerimientos y prioridades. Los requerimientos finales delsistema son inevitablemente un compromiso entre ellos.

2. Las personas que pagan por el sistema y los usuarios de ésteraramente son la misma persona. Los clientes del sistemaimponen requerimientos debido a las restriccionesorganizacionales y de presupuesto. Esto puede estar en conflictocon los requerimientos de los usuarios finales y, después de laentrega, pueden tener que añadirse nuevas características deapoyo al usuario si el sistema tiene que cumplir su objetivo.

3. El entorno de negocios y técnico del sistema cambia después dela instalación, y estos cambios se deben reflejar en el sistema. Sepuede introducir nuevo hardware, puede ser necesario que el

sistema interactúe con otros sistemas, las prioridades de negociopueden cambiar con modificaciones consecuentes en la ayuda delsistema, y puede haber una nueva legislación y regulaciones quedeben ser implementadas en el sistema.

La gestión de requerimientos es el proceso de comprender y controlarlos cambios en los requerimientos del sistema. Es necesario mantenerse altanto de los requerimientos particulares y mantener vínculos entre losrequerimientos dependientes de forma que pueda evaluar el impacto de loscambios en los requerimientos. Hay que establecer un proceso formal paraimplementar las propuestas de cambios y vincular éstos a los requerimientos

del sistema. El proceso de gestión de requerimientos debería empezar encuanto esté disponible una versión preliminar del documento derequerimientos, pero se debería empezar a planificar cómo gestionar losrequerimientos que cambian durante el proceso de obtención derequerimientos.

Page 34: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 34/86

 

     0     0     8

Planificación y Modelado

1.4.1 Requerimientos duraderos y volátilesLa evolución durante el proceso de ingeniería de requerimientos y después deque un sistema esté en uso es inevitable. El desarrollo de requerimientossoftware centra su atención en las capacidades de este, los objetivos delnegocio y otros sistemas de la organización. Conforme se van desarrollando la

definición de los requerimientos, normalmente tiene una mejor comprensión delas necesidades de los usuarios. Esto retroalimenta la información del usuario,quien puede entonces posponer un cambio en los requerimientos (figura 1.12).Además, especificar y desarrollar un sistema grande puede llevar varios años.Durante ese tiempo, el entorno del sistema y los objetivos del negociocambian, y los requerimientos evolucionan para reflejar esto.

Figura 1.12 evolución de los requerimientos

Desde una perspectiva evolutiva, los requerimientos se dividen en dosclases:

1. Requerimientos duraderos, Son requerimientos relativamente establesque se derivan de la actividad principal de la organización y que están

relacionados directamente con el dominio del sistema. Por ejemplo, en elhospital siempre habrá requerimientos que se refieren a los pacientes,médicos, enfermeras y tratamientos. Estos requerimientos se puedenderivar de los modelos del dominio que muestran las entidades yrelaciones que caracterizan un dominio de aplicación.

2. Requerimientos volátiles, Son requerimientos que probablementecambian durante el proceso de desarrollo del sistema o después de queeste se haya puesto en funcionamiento. Un ejemplo serían los

requerimientos resultantes de las políticas gubernamentales sobre lasanidad.

Harker y otros han indicado que los requerimientos volátiles se dividen en 5clases. Utilizando estas como base, se ha desarrollado la clasificación mostradaen la figura 1.13.

Page 35: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 35/86

 

     0     0     8

Planificación y Modelado

Requerimientos cambiarios Requerimientos que cambiandebido a los cambios en elentorno en el que opera laorganización. Por ejemplo, en lossistemas hospitalarios, el pago

del cuidado del paciente puedecambiar y así requerir untratamiento diferente lainformación a recopilar.

Requerimientos emergentes Requerimientos que emergen alincrementarse la comprensión delcliente en el desarrollo del sistema. Elproceso de diseño puede revelarrequerimientos emergentes nuevos.

Requerimientos consecuentes Requerimientos que son resultado dela introducción del sistemainformático. Esta introducción puedecambiar los procesos de laorganización y desarrollar nuevasformas de trabajar que generannuevos requerimientos del sistema.

Requerimientos de compatibilidad Requerimientos que dependen desistemas particulares o procesos denegocios dentro de la organización.

Cuando estos últimos cambian, losrequerimientos de compatibilidad delsistema encargado o entregadotambién pueden cambiar.

Figura 1.13 clasificación de los requerimientos volátiles.

1.4.2Planificación de la gestión de requerimientos.La planificación es una primera etapa esencial del proceso de gestión derequerimientos. La cual tiene un coste elevado. Para cada proyecto la etapade planificación establece el nivel de detalle necesario en la gestión de

requerimientos. Durante la etapa de gestión de requerimientos, habrá quedecidir sobre:

1. La identificación de requerimientos. Cada requerimiento se debeidentificar de forma única de tal forma que puedan ser remitidos porotros requerimientos de manera que pueda utilizarse en lasevaluaciones de rastreo.

Page 36: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 36/86

 

     0     0     8

Planificación y Modelado

2. Un proceso de gestión del cambio. Este es conjunto de actividades queevalúan el impacto y coste de los cambios.

3. Políticas de rastreo. Esta política define las relaciones entre losrequerimientos, y entre éstos y el diseño del sistema que se debe

registrar y la manera en que estos registros se deben mantener.4.  Ayuda de herramientas CASE. La gestión de requerimientos comprende

el procesamiento de grandes cantidades de información sobre losrequerimientos. Las herramientas que se pueden utilizar van desdesistemas de gestión de requerimientos especializados hasta hojas decálculo y sistemas sencillos de bases de datos.

1.4.3 Gestión de cambio de los requerimientosSe debe aplicar a todos los cambios propuestos en los requerimientos. Laventaja de utilizar un proceso formal para gestionar el cambio es que todos loscambios propuestos son tratados de forma consistente y que los cambios en eldocumento de requerimientos se hacen de forma controlada. Existen 3 etapasprincipales en un proceso de gestión de cambio:

1.  Análisis del problema y especificación del cambio. El proceso empiezacon la identificación de un problema en los requerimientos o, algunasveces, con una propuesta de cambio específica. Durante esta etapa, elproblema o la propuesta de cambio se analizan para verificar que estaes válida.

2.   Análisis del cambio y cálculo de costes. El efecto de un cambiopropuesto se valora utilizando la información de rastreo y elconocimiento general de los requerimientos del sistema. Coste de hacerun cambio se estima en términos de modificaciones al documento derequerimientos y, si es apropiado, al diseño e implementación delsistema.

3. Implementación del cambio. Se modifica el documento derequerimientos y, en su caso el diseño e implementación del sistema.

Debe organizar el documento de requerimientos de modo que puedahacer cambios en el sin tener que hacer grandes reorganizaciones oredactar nuevamente gran cantidad del mismo.

Si se requiere de forma urgente un cambio en los requerimientos delsistema, existe siempre la tentación de hacer ese cambio al sistema yentonces modificar de forma retrospectiva el documento de requerimientos.

Page 37: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 37/86

 

     0     0     8

Planificación y Modelado

Esto conduce casi inevitablemente a que la especificación de requerimientos yla implementación del sistema se desfasen.

Unidad 2

Planificación del sistema

La planeación de proyectos de software es una parte esencial de la ingeniería

del software. La buena gestión no puede garantizar el éxito del proyecto, perola mala llevara al fracaso del proyecto.

La administración efectiva de un proyecto de software depende deplanear completamente el progreso del proyecto. El administrador del proyectodebe anticiparse a los problemas que podrían surgir, así como prepararsoluciones tentativas a esos problemas. Un plan, preparado al inicio de unproyecto, debe utilizarse como un conductor para el proyecto. Este plan inicialdebe ser el mejor posible de acuerdo con la información disponible. Esteevolucionara conforme el proyecto progrese y la información disponible serámejor.

Los administradores tienen que preparar planes de trabajo, para llevar acabo mejor el sistema y tener un control sobre el trabajo algunos de estosplanes se muestran en la figura 2.1:

Plan Descripción

Plan de calidad Describe los procedimientos y estándares de calidad

Page 38: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 38/86

 

     0     0     8

Planificación y Modelado

que se utilizaran en un proyecto.

Plan de validación Describe el enfoque, los recursos y la programaciónutilizados para la validación del sistema.

Plan de la

administración dela configuración

Describe los procedimientos de administración de la

configuración y las estructuras a utilizarse.

Plan demantenimiento

Predice los requerimientos de mantenimiento delsistema, los costos de mantenimiento y el esfuerzorequerido.

Plan de desarrollopersonal

Describe cómo se desarrollan las habilidades yexperiencia de los miembros del equipo del proyecto.

Figura 2.1 planes de trabajo.

Los gestores de software son responsables de la planificación ytemporalización del desarrollo de los proyectos. Supervisan el trabajo paraasegurar que se lleva a cabo conforme a los estándares requeridos ysupervisan el progreso para comprobar que el desarrollo se ajusta al tiempoprevisto y al presupuesto. La administración de proyectos de software esnecesaria debido a que la ingeniería de software profesional siempre estásujeta a restricciones organizacionales de tiempo y presupuesto. El trabajo delgestor de proyectos de software es asegurar que estos cumplan dichasrestricciones y entregar software que contribuya a las metas de la compañía dedesarrollo de software.

Los gestores de software hacen el mismo trabajo que otros gestores. Sinembargo, la ingeniería del software es diferente en varios aspectos a otrostipos, lo que hace la gestión de software particularmente difícil.

La gestión de proyectos de software es un tema amplio y no puedetratarse en un solo tema; es necesario abordar temas como la planificación deltiempo, la evaluación de costos, la planificación de la documentación, elestudio de la viabilidad, entre otros temas.

Plan de proyecto

Este plan fija los recursos disponibles, divide el trabajo y crea un calendario detrabajo. En algunas organizaciones, el plan del proyecto es un únicodocumento que incluye todos los diferentes tipos de planes mencionadosanteriormente en la tabla; en otros casos solo se refiere al proceso dedesarrollo y en otros puede estar referenciado, pero son proporcionados porseparado.

Page 39: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 39/86

 

     0     0     8

Planificación y Modelado

La estructura general de cualquier plan lleva los siguientes puntos,aunque pueden variar un poco según el tipo de proyecto o el lugar en que sequiera aplicar:

• Introducción: describe brevemente los objetivos del proyecto y expone

las restricciones que afectan la administración del proyecto.• Organización del proyecto: describe la forma en que el equipo de

desarrollo de desarrollo está organizado, la gente involucrada y sustareas en el equipo.

•   Análisis de riesgo: describe los posibles riesgos del proyecto, laprobabilidad de que surjan estos riesgos y las estrategias de reducciónde riesgos propuestas.

• Requerimientos de recursos de hardware y software: describe elhardware y la ayuda de software requerida para llevar a cabo eldesarrollo. Si es necesario comprar hardware, se deben incluir losestimados de los precios y las fechas de entrega.

• División del trabajo: describe la división del proyecto en actividades eidentifica los hitos y productos a entregar asociados con cada actividad

• Programa del proyecto: describe las dependencias entre actividades,el tiempo estimado requerido para alcanzar cada hito y la asignación dela gente a las actividades.

• Mecanismos de supervisión e informe: describe la administración deinformes y cuando deben producirse, así como los mecanismos desupervisión del proyecto a utilizar.

El plan de proyecto debe revisarse regularmente durante el proyecto.Algunas partes, como el calendario del proyecto, cambiaran frecuentemente;otras serán más estables. Debe utilizarse una organización documental quepermita reemplazar fácilmente las secciones.

2.1 Planificación del tiempo.

La planificación es una parte muy demandante para los administradores desoftware, ya que deben estimar el tiempo y los recursos para completar yprogramar las actividades en forma coherente; en caso de existir un proyectoprevio parecido, se puede tomar como base su planificación adaptándola al

Page 40: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 40/86

 

     0     0     8

Planificación y Modelado

nuevo proyecto, aunque esto se complica cuando el nuevo proyecto utilizamétodos de diseño y lenguajes de implementación diferentes.

Si el proyecto es técnicamente complejo, las estimaciones iníciales detiempo pueden variar con las estimaciones finales, ya que durante el proceso

pueden salir imprevistos que pueden ir retrasando el proyecto, por lo que esrecomendable ir actualizando la calendarización mediante se vaya progresandoen dicho proyecto.

Para calendarizar el proyecto, se debe separar en actividadescomplementarias y considerar el tiempo para llevar acabo dichas actividades(figura 2.2); se debe asignar personal para cada actividad a fin de que lapersona que calendarizo pueda coordinarlas y evitar el atraso del proyecto.Cabe destacar que algunas de dichas actividades complementarias puedenllevarse simultáneamente o paralelamente.

Figura 2.2 actividades complementarias de un proyecto.

Normalmente, cada actividad debe durar por lo menos una semana, ycomo máximo de 8 a 10 semanas, si se estima más tiempo, se deben hacermas subdivisiones.

En la elaboración de la calendarización, los administradores debencontemplar que cada etapa puede tener problemas, ya que pueden pasardistintas fallas o pudieran ser más complicadas, por lo que se llevara mástiempo del estimado inicialmente.

Un método es estimar como si no saliera nada mal, entonces se debeincrementar esta estimación para problemas no previstos; este aumento será apartir del tipo de proyecto, de los parámetros y de la calidad y experiencia delos ingenieros de software que trabajen en el proyecto.

Por lo general, el calendario del proyecto se representa como unconjunto de gráficos que muestran la división del trabajo, las dependencias delas actividades y la asignación del personal; las herramientas de administración

Identificaractividades

Identificardependencias

deactividades

Estimarrecursos para

lasactividades

Asignarpersonas a

lasactividades

Creargráficos deproyecto

Requerimientos de

Redes deactividades y

Page 41: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 41/86

 

     0     0     8

Planificación y Modelado

de software, como Microsoft Project, se utilizan para automatizar la producciónde diagramas.

2.1.1 Gráficos de barras y redes de actividades.Los gráficos de barra y las redes de actividades son notaciones graficas que se

utilizan para ilustrar la calendarización del proyecto. Los gráficos de barrasmuestran quien es responsable de cada actividad y cuando se debe comenzary finalizar ésta; las redes de actividades muestran las dependencias entre lasdiferentes actividades que conforman un proyecto; ambos se generanautomáticamente a partir de una base de datos de la información del proyectoutilizando una herramienta de administración de proyectos.

Tarea Duración (días) Dependencias

T1 8

T2 15

T3 15 T1 (M1)

T4 10

T5 10 T2, T4 (M2)

T6 5 T1, T2 (M3)

T7 20 T1 (M1)

T8 25 T4 (M5)

T9 15 T3, T6 (M4)

T10 15 T5, T7 (M7)

T11 7 T9 (M6)

T12 10 T11 (M8)

Figura 2.3 tabla de actividades.

Se considera un conjunto de actividades, las cuales son representadaspor la tabla de la figura 2.3 anterior; esta tabla nos enseña que actividades sondependientes de otras, así como las que no tienen dependencia: por ejemplo,

para llevar a cabo la actividad T3, es necesario llevar a cabo la actividad T1, así como T2 se puede realizar de manera paralela a T1. Dadas las dependencias yla duración estimada de las actividades, se puede realizar una red deactividades, la cual muestra la sucesión de actividades que deben generarse,ya sea dependientes o paralelas unas de otras; la figura 2.4 ilustra esto:

25

días

10días

 

20 días

25/7/99

15días

10 días

5/9/99

7 días

4/8/99

14/7/99días

25/7/99

8días

4/7/9

9

15días

 T1

M1

M3INICIO

M7

M4M6

M8

M2

FINAL

M5

 T2 T7

 T3

 T9

 T11

 T12 T1

0

 T5

 T8

 T4

 T6

 

18/7/99

11/8/99

5 días

25/8/99

15 días

10 días

 

15 días

Page 42: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 42/86

 

     0     0     8

Planificación y Modelado

Figura 2.4 red de actividades.

Las actividades se representan con rectángulos, los hitos y los productosa entregar por el proyecto se muestran con esquinas redondeadas; la red sedebe lee de izquierda a derecha y de arriba hacia abajo.

 Todas las actividades deben terminar en hitos; una actividad comienzacuando su hito precedente ha sido alcanzado; también otra característica, esque antes de que pueda pasar de un hito a otro, todas las trayectorias debencompletarse.

El tiempo total se calcula en base a la trayectoria más larga de la red, eneste caso esta remarcada la trayectoria más larga, que es de 11 semanas o 55días laborales. Cualquier aplazamiento en la trayectoria crítica provoca elretraso en el proyecto.

Los gráficos de proyecto (figura 2.5) es otra manera de representar lainformación del calendario; es un grafico de barras que muestra el calendario ylas fechas iníciales y finales de las actividades. Algunas de las actividades quese muestran son seguidas por una barra sombreada cuya longitud es calculadapor una herramienta de calendarización. Esto muestra que existe alguna

flexibilidad en las fechas de terminación de estas actividades.

19/9/9

Page 43: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 43/86

 

     0     0     8

Planificación y Modelado

Figura 2.5 ejemplo gráfica de proyecto.

Page 44: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 44/86

 

     0     0     8

Planificación y Modelado

2.2 Evaluación del costo beneficio.

La estimación y la calendarización del proyecto se llevan a cabo de formaconjunta. Sin embargo, en las primeras etapas del proyecto se requierenalgunas estimaciones de costos, antes de que se tenga la calendarizacióndetallada. Estas estimaciones son necesarias para establecer un presupuestopara el proyecto o para asignar un precio para el software de un cliente.

Una vez que el proyecto se encamina, las estimaciones se actualizan deforma regular; esto ayuda al proceso de planeación y permite la utilizaciónefectiva de los recursos. Si el gasto real es significativamente más grande quelas estimaciones, entonces el administrador del proyecto debe tomar algunasacciones. Estas pueden ser solicitar recursos adicionales para el proyecto omodificar el trabajo a realizar.

Existen tres parámetros involucrados en el cálculo del costo total de unproyecto de desarrollo de software:

• los costos de hardware y software, incluyendo el mantenimiento

• los costos de viajes y capacitación

• los costos de esfuerzo (los costos de pago a los ingenieros de software

En muchos proyectos, el costo dominante es el costo de esfuerzo. Lascomputadoras que son suficientemente poderosas como para desarrollar elsoftware son relativamente baratas. Aunque los costos de viajes pueden serimportantes si un proyecto se desarrolla en sitios distintos, son relativamentebajos para muchos proyectos; el uso de fax, correos electrónicos yteleconferencias reduce los viajes requeridos.

Los costos de esfuerzo no son simplemente los relacionados a los salariosde los ingenieros de software involucrados en el proyecto. Las organizacionescalculan los costos de esfuerzos en términos de los costos de sobrecarga

donde se toma en cuenta el costo total de hacer funcionar la organización ydividen este entre el número de personas productivas. Por lo tanto, lossiguientes costos son parte de los costos de esfuerzo totales:

• los costos de proveer, calentar e iluminar las oficinas

• los costos de personal de apoyo como los contadores, secretarias,limpiadores y técnicos

Page 45: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 45/86

 

     0     0     8

Planificación y Modelado

• los costos de las redes y las comunicaciones

• los costos de los recursos centralizados como las bibliotecas, losrecursos recreativos, etc.

Los costos de seguridad social y de beneficio de empleados como laspensiones y los seguros de salud.

El costo de un proyecto es de interés continuo y vital para los coparticipes.Con el precio de producción equivocado, incluso el sistema más fantásticopuede ser un desastre. La estimación de costo más sencilla es la queproporciona un costo fijo desde el principio, sin permitir desviaciones enninguna circunstancia. Aunque las organizaciones muy competentes tienensuficientes aptitudes para cambiar las variables restantes para cumplir con uncosto predeterminado, la rigidez absoluta en el costo no siempre se adopta.

El proceso de estimar costos con frecuencia comienza desde la concepcióndel proyecto y continúa aun después de iniciada la codificación. Cuando seinicia un proyecto, tal vez el equipo tenga solo una idea vaga de su costo. Si laestimación del costo se puede posponer hasta que el proyecto tome forma, sinduda deben esperar, pero siempre existe la necesidad de estimar por lo menosun intervalo burdo a partir de un resumen de requerimientos para el producto ymas diseño se realice, más preciso será el costo.

Una buena manera de enfocar la estimación de costos del proyecto durantelas primeras etapas es desarrollar estimaciones de varias manerasindependientes y después combinar los resultados. Incluso se pueden ponderar

las estimaciones obtenidas de acuerdo con el nivel de confianza personal encada una de ellas.

2.2.1 Productividad.La productividad en un sistema de manufactura se mide contando el númerode unidades que se producen y dividiendo éste entre el número de personas-hora requeridas para producirlas. Sin embargo, para cualquier problema desoftware, existen muchas soluciones diferentes con distintos atributos. Unasolución podía ejecutarse de forma más eficiente mientras que otra podría sermás legible y fácil de mantener. Cuando se producen soluciones con diferentesatributos, no tiene sentido comparar estas tasas de producción.

Sin embargo, los administradores tienen que estimar la productividad delos ingenieros en el proceso de desarrollo de software. Estas estimaciones sonnecesarias para la estimación del proyecto y para valorar si los procesos o lasmejoras tecnológicas son efectivos. Por lo general, estas estimaciones deproductividad se basan en medir algunos atributos del software y dividir elresultado entre el esfuerzo total requerido para el desarrollo. Existen dos tiposde medidas utilizadas:

Page 46: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 46/86

 

     0     0     8

Planificación y Modelado

Medidas relacionadas con el tamaño: estas se relacionan con el tamañode alguna salida de una actividad. La mediad más común relacionada con eltamaño son las líneas de código fuente entregadas. Otras medidas que seutilizan son el numero de instrucciones de código objeto entregado o el númerode páginas de la documentación del sistema.

Medidas relacionadas con la función: estas se relacionan con lafuncionalidad total del software entregado. La productividad se expresa entérminos de la cantidad de funcionalidad útil producida en un tiempo dado. Lospuntos de función y los puntos de objeto son las medidas más conocidas deeste tipo.

Las líneas de código fuente por programador-mes son una métricaampliamente utilizada en la medida de la productividad. Esta se calculacontando el número total de líneas del código fuente que se entrega. La cuentase divide entre el tiempo total de programadores-mes requeridos para

completar el proyecto. Por lo tanto, este tiempo incluye el tiempo requeridopara el análisis y diseño, codificación, pruebas y documentación.

2.2.2 Técnicas de estimación.No existe una forma simple de hacer una estimación precisa del esfuerzorequerido para desarrollar un sistema de software. Las estimaciones inícialesse hacen bajo la base de la definición de requerimientos de usuario de altonivel. El software tiene que ejecutarse en computadoras poco familiares outilizar nuevas tecnologías de desarrollo. Probablemente no se conozcan laspersonas involucradas en el proyecto y sus habilidades. Todos estos factoressignifican que en una primera etapa del proyecto es difícil producir una

estimación precisa de los costos de desarrollo del sistema.

Existe una dificultad para valorar la precisión de los diferentes enfoquesde las técnicas de estimación de costos. Por lo general, las estimaciones de loscostos del proyecto se cumplen por su propia naturaleza. La estimación seutiliza para definir el presupuesto del proyecto y el producto se ajusta para quelas cifras del presupuesto se cumplan. No se conocen informes deexperimentos controlados sobre los costos de los proyectos donde los costosestimados no se utilicen para ajustar el experimento. Un experimentocontrolado no revelaría la estimación del costo al administrador del proyecto.Los costos reales tendrían que compararse con los estimados del proyecto.

A pesar de esto, las organizaciones necesitan hacer esfuerzos desoftware y estimaciones de los costos. Para hacerlo, se utilizan una o más delas técnicas descritas en el cuadro de la figura 2.6:

Técnica Descripción

Modelado Se desarrolla un modelo utilizando información histórica de

Page 47: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 47/86

 

     0     0     8

Planificación y Modelado

delalgoritmo decostos

costos que relaciona alguna métrica de software con el costodel proyecto. Se hace una estimación de esa métrica y elmodelo predice el esfuerzo requerido.

Opinión deexpertos

Se consultan varios expertos en las técnicas de desarrollo desoftware propuestas y en el dominio de la aplicación. Cadauno de ellos estima el costo del proyecto. Estas estimacionesse comparan y discuten. El proceso de estimación se iterahasta que se acuerda una estimación.

Estimaciónpor analogía

Esta técnica es aplicable cuando otros proyectos en el mismodominio de la aplicación se han completado. Se estima elcosto de un nuevo proyecto por analogía con estos proyectos

completados. Myers (1989) da una descripción muy clara deeste enfoque.

Ley deParkinson

La ley de Parkinson establece que el trabajo se extiende parallenar el tiempo disponible. El costo se determina por losrecursos disponibles más que por los objetivos logrados. Si elsoftware se tiene que entregar en 12 meses y se dispone de 5personas, el esfuerzo requerido se estima en 60 personas-mes.

Asignarprecios paraganar

El costo del software se estima independientemente de lo queel cliente está dispuesto a pagar por el proyecto. El esfuerzoestimado depende del presupuesto del cliente y no de lafuncionalidad del software.

Figura 2.6 técnicas de esfuerzos de software y estimaciones de costos.

Cada técnica de estimación tiene sus propias fortalezas y debilidades.Para proyectos grandes, se deben utilizar varias técnicas de estimación decostos y comparar sus resultados. Si estos predicen costos radicalmentediferentes, esto indica que no se tiene suficiente información para generar loscostos. Se debe buscar más información y repetir el proceso hasta que laestimación converja.

Page 48: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 48/86

 

     0     0     8

Planificación y Modelado

Estas técnicas de estimación son aplicables cuando existe un documentode requerimientos para el sistema. Este define a todos los usuarios y losrequerimientos del sistema. Por lo tanto, se puede generar una estimaciónrazonable de la amplitud de la funcionalidad del sistema a desarrollar. Engeneral, los proyectos grandes de ingeniería de sistemas normalmente tendrán

tal documento de requerimientos.

2.2.3 Modelo algorítmico de costos.El enfoque más sistemático, aunque no necesariamente el más preciso, para laestimación del software es la estimación algorítmica de costos. Un modeloalgorítmico de costos se construye analizando los costos y atributos de losproyectos realizados. Se utiliza una fórmula matemática para predecir loscostos basados en estimaciones del tamaño del proyecto, numero deprogramadores y otros factores de los procesos y productos. Kitchenham(1990) describe 13 modelos algorítmicos de costos desarrollados a partir deobservaciones empíricas.

Muchos de los modelos de estimación algorítmica tienen un componenteexponencial. Esto refleja el hecho de que los costos normalmente no seincrementen linealmente con el tamaño del proyecto. Puesto que el tamaño delsoftware crece, se incurre en costos extra como sobrecarga de comunicacionesde equipos grandes, administración más compleja de la configuración,integración más difícil del sistema, etc. También se incluye multiplicadores quereflejan los atributos de los productos a desarrollar, la plataforma de desarrollo,el proceso y los desarrolladores del software.

En su forma más general, una estimación algorítmica de costos para el

software se expresa como:

Esfuerzo= A x TamañoB x M

En la formula, A es un factor constante que depende de las practicasorganizacionales locales y del tipo de software que se desarrolla. Tamaño esuna valoración del tamaño del código del software o una estimación de lafuncionalidad expresada en puntos de funciones o de objetos. El valor delexponente B por lo general se encuentra entre 1 y 1.5. Refleja el esfuerzorequerido para proyectos grandes. M es un multiplicador generado al combinardiferentes procesos, atributos del producto y del desarrollo.

 Todos los modelos algorítmicos padecen las mismas dificultades básicas:

A menudo es difícil estimar el Tamaño en una primera etapa de unproyecto donde solamente está disponible la especificación. Las estimacionesde los puntos de función y los puntos de objeto son más fáciles de producir quelas del tamaño del código pero pueden ser imprecisas.

Page 49: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 49/86

 

     0     0     8

Planificación y Modelado

Las estimaciones de los factores B y M son subjetivas. Las estimacionesvarían de una persona a otra, dependiendo de su conocimiento y experiencia.

El número de líneas de código fuente en un sistema terminado es lamétrica básica utilizada en muchos de los modelos algorítmicos de costos. La

estimación del tamaño puede comprender la estimación por analogía con otrosproyectos, la de convertir los puntos de función al tamaño del código, la de losvalores del tamaño de los componentes del sistema y la utilización de uncomponente de referencia conocido para estimar el tamaño de loscomponentes, o simplemente puede ser una cuestión de juicio de ingeniería.

2.3 Estudio de viabilidad.

Este estudio es con el que debe empezar el proceso de ingeniería derequerimientos; la entrada de este es un conjunto de requerimientos denegocio preliminares, una descripción resumida del sistema y de cómo éstepretende contribuir a los procesos del negocio. Los resultados del estudio deviabilidad deberían ser un informe que recomiende si merece o no la peaseguir con la ingeniería de requerimientos y el proceso de desarrollo del

sistema.

Este estudio está orientado a resolver varias cuestiones:

• ¿Contribuye el sistema a los objetivos generales de la organización?

• ¿Se puede implementar el sistema utilizando la tecnología actual ydentro de las restricciones de coste y tiempo?

Page 50: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 50/86

 

     0     0     8

Planificación y Modelado

• ¿Puede integrarse el sistema con otros sistemas existentes en laorganización?

Llevar a cabo un estudio de viabilidad comprende la evaluación yrecopilación de la información y la redacción de informes. La fase de

evaluación de la información identifica la información requerida para contestarlas preguntas anteriores. Una vez que dicha información se ha identificado, sedebería hablar con las fuentes de información para descubrir las respuestas aestas preguntas.

En este tipo de estudio, se puede consultar las fuentes de información,como los jefes de los departamentos donde se utilizara el sistema, losingenieros de software que están familiarizados con el tipo de sistemapropuesto, los expertos en tecnología y los usuarios finales del sistema.Normalmente, se debería intentar completar un estudio de viabilidad en2 o 3semanas. Una vez que se tiene la información, se redacta el informe del

estudio de viabilidad. Debería hacerse una recomendación sobre si debecontinuar o no con el desarrollo del sistema. En el informe, se pueden proponercambios en el alcance, el presupuesto y la confección de agendas del sistemay sugerir requerimientos adicionales de alto nivel para éste.

2.4 Planificación de la documentación.

La documentación es la sangre que alimenta la ingeniería de software. Estoincluye la documentación separada del código, al igual que la documentaciónasociada con él. Para entender la importancia de la documentación integral,imagine que le piden participar en un proyecto de software que ya está enmarcha. Dada la complejidad potencial involucrada, sería lo mismo que lepidieran aprender, por ejemplo, un aspecto de la patología sanguínea. Parahacerlo, querría un panorama global del tema, la motivación para conocerlo, un

Page 51: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 51/86

 

     0     0     8

Planificación y Modelado

flujo ordenado desde el panorama general hasta los detalles, diagramas conlas interrelaciones, numerosas notas acerca de implementaciones específicas,entre otros. Las omisiones o contradicciones harían difícil o imposible entenderque sucede.

2.4.1 El documento de requerimientos del software.El documento de requerimientos del software (algunas veces denominadoespecificación de requerimientos del software o SRS) es la declaración oficialde qué deben implementar los desarrolladores del sistema. Debe incluir tantolos requerimientos del usuario para el sistema como una especificacióndetallada de los requerimientos del sistema. En algunos casos, los dos tipos derequerimientos se pueden integrar en una única descripción. En otros, losrequerimientos del usuario se definen en una introducción a la especificaciónde los requerimientos del sistema. Si existe un gran número de requerimientos,los detalles de los requerimientos del sistema se pueden presentar en undocumento separado.

El documento de requerimientos tiene un conjunto diverso de usuariosque va desde los altos cargos de la organización que pagan por el sistema,hasta los ingenieros responsables de desarrollar el software. La figura 2.7tomada del libro sobre ingeniería de requerimientos de Gerald Kotonya e IanSommerville, ilustra los posibles usuarios del documento y como lo utilizan.

La diversidad de posibles usuarios significa que el documento derequerimientos tiene que presentar un equilibrio entre la comunicación de losrequerimientos a los clientes, la definición de los requerimientos en el detalleexacto para los desarrolladores y probadores, y la inclusión de la información

sobre la posible evolución del sistema. La información sobre cambios previstospuede ayudar a los diseñadores del sistema a evitar decisiones de diseñorestrictivas y a los ingenieros encargados del mantenimiento del sistema,quienes tienen que adaptar el sistema a los nuevos requerimientos.

El nivel de detalle se debe incluir en un documento de requerimientosdepende del tipo de sistema que se desarrolle y del proceso de desarrolloutilizado. Cuando del sistema se desarrolle por un contratista externo, lasespecificaciones de los sistemas críticos necesitan ser claras y muy detalladas.Cuando haya más flexibilidad en los requerimientos y cuando se utilice unproceso de desarrollo iterativo dentro de la empresa, el documento derequerimientos puede ser mucho menos detallado y cualquier ambigüedadresuelta durante el desarrollo del sistema.

Page 52: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 52/86

 

     0     0     8

Planificación y Modelado

Figura 2.7 usuarios del documento de requerimientos.

Varias organizaciones grandes, como el Departamentos de Defensa delos Estados Unidos y el IEEE, ha definido estándares para los documentosrequeridos. Davis analiza algunos de estos estándares y compara suscontenidos. El estándar más ampliamente conocido es el IEEE/ANSI 830-1998.Este estándar IEEE sugiere la siguiente estructura para los documentos derequerimientos:

Page 53: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 53/86

 

     0     0     8

Planificación y Modelado

2.5 Gestión de la configuración del software.

La gestión de la configuración del software es uno de los procesos clave paratoda organización dedicada a la Ingeniería del Software, ya que posibilita unamejor organización del desarrollo y mantenimiento, producto, facilitando elresto de procesos de producción.

Durante el proceso de construcción de un software, los cambios soninevitables. Los cambios provocan confusión e incertidumbre, sobre todocuando no se han analizado o pronosticado correctamente. Es importanteconsiderar ciertas modificaciones que pueden ocurrirle al software dentro detodo el proceso de ingeniería.

El arte de coordinar el desarrollo de software para minimizarla confusión,se denomina gestión de la configuración. La gestión es el arte de identificar,organizar y controlar las modificaciones que sufre el software la meta esmaximizar la productividad minimizando errores.

Los cambios dentro del desarrollo del software pueden ocurrir encualquier momento por lo tanto debemos estar preparados, las actividades deCGS sirven para:

• Identificar el cambio de nuestro software.

Page 54: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 54/86

 

     0     0     8

Planificación y Modelado

• Controlar ese cambio.

• Garantizar que el cambio quede bien implantado.

• Informar el cambio.

La gestión de configuración del software no es un mantenimiento delsoftware, el mantenimiento es la etapa final de la ingeniería hasta que se retireel producto del equipo, la CGS es un conjunto de actividades de seguimiento ycontrol que comienzan cuando se inicia el proyecto de desarrollo del software ytermina sólo una vez que el software queda fuera de circulación.

Desgraciadamente, en el proceso de ingeniería del software existe unavariable importantísima que entra en juego, el cambio.

La primera Ley de la ingeniería de sistemas establece: Sin importar enqué momento del ciclo de vida del sistema nos encontremos, el sistema

cambiará y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida.

Entonces nos hacemos diferentes preguntas: ¿Por qué cambiar elsistema? ¿Que produce los en el sistema cambios? La respuesta a estasinterrogantes se puede encontrar en cuatro aspectos fundamentales y amenudo muy tradicionales dentro del desarrollo del software:

Nuevos requisitos del negocio o condiciones que dictan los cambios enlas condiciones del producto o en las normas comerciales.

• Nuevas necesidades del los clientes que demandan la modificación de los

datos producidos por un sistema basado en computadora.

• Reorganización y/o reducción del volumen comercial que provoca cambios enlas prioridades del proyecto o en la estructura del equipo de ingeniería delsoftware.

• Restricciones presupuestarias o de planificaciones que provocan unaredefinición del sistema o del producto.

La gestión de configuración del software realiza un conjunto deactividades desarrolladas para gestionar y registrar los cambios a lo largo del

ciclo de vida del software de computadora.La GCS es una actividad de garantía de calidad del software que se

aplica en todas las fases del proceso de ingeniería del software.

2.5.1. Líneas base.Una línea base es un concepto de gestión de configuración del software quenos ayuda a controlar los cambios sin impedir seriamente los cambios justificados. La IEEE define una línea base como:

Page 55: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 55/86

 

     0     0     8

Planificación y Modelado

Una especificación o producto que se ha revisado formalmente y sobrelos que se ha llegado a un acuerdo, y que de ahí en adelante sirve como basepara un desarrollo posterior y que puede cambiarse solamente a través deprocedimientos formales de control de cambios.

Una forma de describir la línea base es mediante una analogía.Considere las puertas de la cocina de un gran restaurante. Para evitarcolisiones una puerta está marcada como SALIDA y la otra como ENTRADA laspuertas tienen topes que hacen que solo se puedan abrir en la direcciónapropiada. Si un camarero recoge un pedido en la cocina lo coloca en unabandeja y luego se da cuenta de que ha cogido un plato equivocado, puedecambiar el plato correcto rápidamente informalmente antes de salir de lacocina.

Sin embargo, si abandona la cocina le da el plato al cliente y luego se leinforma de su error, debe seguir el siguiente proceso:

1) Mirar en la orden de pedido si ha cometido algún error.

2) Disculparse insistentemente.

3) Volver a la cocina por la puerta de entrada.

4) Explicar el problema etc.

Una línea base es análoga a un plato mientras pasa por las puertas de lacocina de un restaurante antes de que un elemento de configuración delsoftware se convierta en línea base, el cambio se puede llevar a cabo rápida e

informalmente. Sin embargo, una vez que se establece una línea base,pasamos, de forma figurada, por una puerta de un solo sentido. Sé puedenllevar a cabo los cambios, pero se debe aplicar un procedimiento formal paraevaluar y verificar cada cambio.

En el contexto de la ingeniería del software definimos una línea basecomo un punto de referencia en el desarrollo del software y que quedamarcado por el envío de uno o más elementos de configuración del software(ECS) y la aprobación de ECS obtenido mediante una revisión técnica formal.Por ejemplo, los elementos de una especificación de diseño se documentan yse revisan. Se encuentran errores y se corrigen cuando todas las partes de las

especificaciones se han revisado corregido y aprobado, la especificación dediseño se convierte en línea base. Solo se pueden realizar cambios futuros enla arquitectura del software (contenidos en la especificación del diseño) trashaber sido evaluados y aprobados. Aunque se puedan definir las líneas basecon cualquier nivel de detalle las líneas base más comunes son las que semuestran en la figura 2.8

Page 56: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 56/86

 

     0     0     8

Planificación y Modelado

Figura 2.8 líneas base.

2.5.2 Elemento de configuración del software.Un elemento de la configuración del software es la información creada comoparte del proceso de ingeniería, un ECS (elemento de configuración desoftware) es un documento, un conjunto completo de casos de prueba o uncomponente de un programa 40 dado. Los siguientes ECS son el objetivo de lastécnicas de gestión de configuración y forman un conjunto de líneas base:

1) Especificación del sistema

2) Plan de proyecto

3) a. Especificación de requisitosb. Prototipo ejecutable o en papel

4) Manual de usuario preliminar

5) Especificación de diseños

a. Descripción del diseño de datos

b. Descripción del diseño arquitectónico

c. Descripciones del diseño de los módulos

d. Descripciones del diseño de interfaces

e. Descripciones de los objetos (si se utilizan técnicas de P.O.O)

6) Listados del código fuente

7) a. Plan y procedimiento de pruebas

Page 57: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 57/86

 

     0     0     8

Planificación y Modelado

b. Casos de prueba y resultados registrados

8) Manuales de operación de y de instalación

9) Programas ejecutables

a. Módulos, código ejecutable

b. Módulos enlazados

10) Descripción de la base de datos

a. Esquema y estructura de archivos

b. contenido inicial

11) Manual del usuario final

12) Documentos de mantenimientoa. Informes de problemas del software

b. Peticiones de mantenimiento

c. Ordenes de cambios e ingeniería

13) Estándares y procedimientos de ingeniería del software

Es importante considerar poner las herramientas de desarrollo desoftware bajo control de configuración. Es decir congelar la versiones de

editores, compiladores y otras herramientas CASE utilizadas durante eldesarrollo, un cambio en las versiones utilizadas puede que produzcaresultados diferentes que la versión original

Los ECS se organizan como objetos de configuración que deben sercatalogados por la base de datos del proyecto con un nombre único. Un ECStiene un nombre y atributos, y está conectado a otros objetos medianterelaciones.

Page 58: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 58/86

 

     0     0     8

Planificación y Modelado

Fig.2.9 Objetos configuración

La figura 2.9 se muestra el modelo de datos de los elementos de laconfiguración, cada objeto está relacionado con otro, si se lleva a cabo uncambio sobre un objeto la interrelaciones señalan a que otros objetos afectará.

2.5.3 El proceso de la configuración del software.La GCS es un elemento importante de garantía de calidad es responsable decontrolar los cambios. Sin embargo también se debe identificar los ECS

individuales. El proceso se puede definir en cinco tareas de CGS:

• Identificación

• Control de versiones

• Control de cambios

• Auditorias de configuración

• Generación de informes

2.5.4 Identificación de objetos en GCS.Se pueden identificar dos tipos de objetos los objetos básicos y los objetoscompuestos.

Un objeto básico es una unidad de texto creada durante el análisis,diseño, codificación o prueba. Un objeto compuesto es una colección deobjetos básicos u objetos compuestos. Cada objeto tiene un conjunto decaracterísticas que los identifican como únicos. El nombre del objeto es una

Page 59: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 59/86

 

     0     0     8

Planificación y Modelado

cadena de caracteres que identifica al objeto sin ambigüedad. La descripcióndel objeto es una lista de elementos de datos que identifican:

• El tipo de ECS (documento, programa, datos) que está representado por elobjeto.

• Un identificador del proyecto; y la información de la versión y/o el cambio.

Figura 2.10 Grafo de evolución.

En el grafo de la figura 2.10 de evolución se describe la historia delobjeto y sus cambios, las grandes modificaciones hacen que un objeto cambie,por lo que cambia el número de versión principal.

2.5.5 Control de versiones.

El control de versiones combina procedimientos y herramientas para gestionarlas versiones de los objetos de configuración creadas durante el proceso deingeniería del software.

"La gestión de configuración permite a un usuario especificar configuracionesalternativas del sistema de software mediante la selección de las versionesadecuadas. Esto se puede gestionar asociando atributos a cada versión del

Page 60: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 60/86

 

     0     0     8

Planificación y Modelado

software y permitiendo luego especificar y construir una configuracióndescribiendo el conjunto de atributos deseado."

Los atributos pueden ser tan sencillos como un número específico deversión asociado a cada objeto o tan complejos como una cadena de variables

lógicas que especifiquen tipos de cambios funcionales aplicados al sistema.

Figura 2.11 Versiones y variantes

Para construir la variante adecuada de una determinada versión de unprograma, a cada componente se le asigna una tupla de atributos. A cadavariante se le asigna uno o más atributos. Otra forma de establecer losconceptos de la relación entre componentes, variantes y versiones esrepresentarlas como un fondo de objetos.

Page 61: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 61/86

 

     0     0     8

Planificación y Modelado

Figura 2.12 Representación de objetos, componentes, variantes y versiones

La principal diferencia entre los distintos está en la sofisticación de losatributos que se usan para construir versiones y variantes específicas de un

sistema y en la mecánica del proceso de construcción.

2.5.6 Control de cambios.En un gran proyecto de desarrollo de software, el cambio incontrolado llevarápidamente al caos. El control de cambios combina los procedimientoshumanos y las herramientas automáticas para proporcionar un mecanismopara el control de cambio.

Page 62: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 62/86

 

     0     0     8

Planificación y Modelado

Figura 2.13 Proceso de control de cambios.

Los resultados de la evaluación se presentan como un informe decambios a la autoridad de control de cambios (ACC). Para cada cambioaprobado se genera una orden de cambio de ingeniería (OCI). La OCI describeel cambio a realizar, las restricciones que se deben respetar y los criterios de

revisión y de auditoría.El objeto a cambiar es "dado de baja" de la base de datos del proyecto;

se realiza el cambio y se aplican las adecuadas actividades de SQA. Luego, elobjeto es "dado de alta" en la base de datos y se usan los mecanismos de decontrol de versiones apropiadas (sección 4) para crear la siguiente versión delsoftware.

Page 63: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 63/86

 

     0     0     8

Planificación y Modelado

Los procedimientos de "alta" y "baja" implementan dos elementosimportantes del control de cambios: control de acceso y control desincronización. El control de acceso gobierna los derechos de los ingenieros desoftware a acceder y modificar objetos de configuración concretos. El controlde sincronización asegura que los cambios en paralelo, realizados por personas

diferentes, no se sobrescriben mutuamente.

Figura 2.14 Control de acceso y de sincronización.

Antes de que un ECS se convierta en una línea base, sólo es necesarioaplicar un control de cambios informal.

El que haya desarrollado el ECS en cuestión podrá hacer cualquiercambio justificado por el proyecto y por los requisitos técnicos. Una vez que elobjeto ha pasado la revisión técnica formal y ha sido aprobada, se crea la línea

base.

Una vez que el ECS se convierte en una línea base, aparece el control decambios a nivel de proyecto. Para hacer un cambio, el encargado del desarrollodebe recibir la aprobación del gestor del proyecto (si el cambio es local), o dela ACC si el cambio impacta en otros ECS. En algunos casos, se dispensa degenerar formalmente las peticiones de cambio, los informes de cambio y las

Page 64: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 64/86

 

     0     0     8

Planificación y Modelado

OCI. Sin embargo, hay que hacer una evaluación de cada cambio así como unseguimiento y revisión de los mismos.

Cuando se distribuye el producto de software a los clientes, se instituyeel control de cambios formal.

La autoridad de control de cambios (ACC) desempeña un papel activo enel segundo y tercer nivel de control.

El papel de la ACC es el de tener una visión general, o sea, evaluar elimpacto del cambio fuera del ECS en cuestión. ¿Cómo impactará el cambio enel hardware? ¿Cómo impactará en el rendimiento? ¿Cómo alterará el cambio lapercepción del cliente sobre el producto?

2.5.7 Auditoria de la configuración.¿Cómo podemos asegurar que el cambio se ha implementado correctamente?La respuesta es doble:

1) revisiones técnicas formales

2) auditorias de configuración del software.

Las revisiones técnicas formales se centran en la corrección técnica delelemento de configuración que ha sido modificado. Los revisores evalúan elECS para determinar la consistencia con otros ECS, las omisiones o los posiblesefectos secundarios.

Una auditoria de configuración del software complementa la revisión

técnica formal al comprobar características que generalmente no tiene encuenta la revisión. La auditoria se plantea y responde con las siguientespreguntas:

¿Se ha hecho el cambio especificado en la OCI? ¿Se han incorporadomodificaciones adicionales?

¿Se ha llevado a cabo una revisión técnica formal para evaluar la correccióntécnica?

¿Se han seguido adecuadamente los estándares de ingeniería de software?

¿Se han "recalcado" los cambios en el ECS?

¿Se han especificado la fecha del cambio y el autor?

¿Reflejan los cambios los atributos del objeto de configuración?

¿Se han seguido procedimientos del GCS para señalar el cambio, registrarlo ydivulgarlo?

Page 65: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 65/86

 

     0     0     8

Planificación y Modelado

¿Se han actualizado adecuadamente todos los ECS relacionados?

2.5.8 Informes de estado.La generación de informes de estado de la configuración es una tarea de GCSque responde a las siguientes preguntas:

1) ¿Qué pasó?

2) ¿Quién lo hizo?

3) ¿Cuándo pasó?

4) ¿Que más se vio afectado?

La generación de informes de estado de la configuración desempeña unpapel vital en el éxito del proyecto de desarrollo de software. Cuando apareceinvolucrada mucha gente es muy fácil que no exista una buena comunicación.

Pueden darse errores entre las personas desarrolladoras del software. El IECayuda a eliminar esos problemas, mejorando la comunicación entre todas laspersonas involucradas.

Page 66: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 66/86

 

     0     0     8

Planificación y Modelado

Unidad 3

Análisis del proyecto.

3.1 Análisis de riesgos.

Durante este proceso, se considera por separado cada riesgo identificado y sedecide acerca de la probabilidad y la seriedad del mismo. No existe una formafácil de hacer esto. No se hace una valoración con números precisos sino enintervalos:

La probabilidad del riesgo se puede valorar como muy bajo (<10%), bajo(10-25%), moderado (25-50%), alto (50-75%) o muy alto (>75%).

Los efectos del riesgo pueden ser valorados como catastróficos, serios,tolerables o insignificantes.

En un entorno informático existen una serie de recursos (humanos,técnicos, de infraestructura…) que están expuestos a diferentes tipos deriesgos: los `normales’, aquellos comunes a cualquier entorno, y losexcepcionales, originados por situaciones concretas que afectan o puedenafectar a parte de una organización o a toda la misma, como la inestabilidadpolítica en un país o una región sensible a terremotos. Para tratar de minimizarlos efectos de un problema de seguridad se realiza lo que denominamos unanálisis de riesgos, término que hace referencia al proceso necesario pararesponder a tres cuestiones básicas sobre nuestra seguridad:

• ¿Qué queremos proteger?

• ¿Contra quién o qué lo queremos proteger?

• ¿Cómo lo queremos proteger?

Page 67: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 67/86

 

     0     0     8

Planificación y Modelado

En la práctica existen dos aproximaciones para responder a estascuestiones, una cuantitativa y otra cualitativa. La primera de ellas es condiferencia la menos usada, ya que en muchos casos implica cálculos complejoso datos difíciles de estimar. Se basa en dos parámetros fundamentales: laprobabilidad de que un suceso ocurra y una estimación del coste o las pérdidas

en caso de que así sea; el producto de ambos términos es lo que se denominacoste anual estimado (EAC, Estimated Annual Cost), y aunque teóricamente esposible conocer el riesgo de cualquier evento (el EAC) y tomar decisiones enfunción de estos datos, en la práctica la inexactitud en la estimación o en elcálculo de parámetros hace difícil y poco realista esta aproximación.

El segundo método de análisis de riesgos es el cualitativo, de uso muydifundido en la actualidad especialmente entre las nuevas `consultoras’ deseguridad (aquellas más especializadas en seguridad lógica, cortafuegos, testsde penetración y similares). Es mucho más sencillo e intuitivo que el anterior,ya que ahora no entran en juego probabilidades exactas sino simplemente una

estimación de pérdidas potenciales. Para ello se interrelacionan cuatroelementos principales: las amenazas, por definición siempre presentes encualquier sistema, las vulnerabilidades, que potencian el efecto de lasamenazas, el impacto asociado a una amenaza, que indica los daños sobre unactivo por la materialización de dicha amenaza, y los controles o salvaguardas,contramedidas para minimizar las vulnerabilidades (controles preventivos) o elimpacto (controles curativos). Por ejemplo, una amenaza sería un pirata quequeramos o no (no depende de nosotros) va a tratar de modificar nuestrapágina web principal, el impacto sería una medida del daño que causaría si lolograra, una vulnerabilidad sería una configuración incorrecta del servidor que

ofrece las páginas, y un control la reconfiguración de dicho servidor o elincremento de su nivel de parcheado. Con estos cuatro elementos podemosobtener un indicador cualitativo del nivel de riesgo asociado a un activodeterminado dentro de la organización, visto como la probabilidad de que unaamenaza se materialice sobre un activo y produzca un determinado impacto.

 Tras obtener mediante cualquier mecanismo los indicadores de riesgo ennuestra organización llega la hora de evaluarlos para tomar decisionesorganizativas acerca de la gestión de nuestra seguridad y sus prioridades. Tenemos por una parte el riesgo calculado, resultante de nuestro análisis, yeste riesgo calculado se ha de comparar con un cierto umbral (umbral de

riesgo) determinado por la política de seguridad de nuestra organización; elumbral de riesgo puede ser o bien un número o bien una etiqueta de riesgo(por ejemplo, nivel de amenaza alto, impacto alto, vulnerabilidad grave, etc.), ycualquier riesgo calculado superior al umbral ha de implicar una decisión dereducción de riesgo. Si por el contrario el calculado es menor que el umbral, sehabla de riesgo residual, y el mismo se considera asumible (no hay porquétomar medidas para reducirlo). El concepto de asumible es diferente al deriesgo asumido, que denota aquellos riesgos calculados superiores al umbral

Page 68: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 68/86

 

     0     0     8

Planificación y Modelado

pero sobre los que por cualquier razón (política, económica…) se decide notomar medidas de reducción; evidentemente, siempre hemos de huir de estasituación.

De forma simple, se puede concebir un riesgo como una probabilidad de

que una circunstancia adversa ocurra. Los riesgos son una amenaza para elproyecto, para el software que se está desarrollando y para la organización.Estas categorías de riesgos se definen como se muestra:

• Riesgos del proyecto: estos afectan la calendarización o los recursos delproyecto.

• Riesgos del producto: estos afectan a la calidad o al rendimiento delsoftware que se está desarrollando.

• Riesgos del negocio: estos afectan a la organización que desarrolla osuministra el software.

3.2 Control de calidad.

El control de la variación es el corazón del control de calidad. El control de lavariación es la clave para un producto de alta calidad. En el contexto desoftware se lucha para controlar la variación en el proceso genérico que seaplica y el énfasis de calidad que permea el trabajo de ingeniería del software.

La calidad “es una característica o atributo de algo”. Como un atributode un elemento, la calidad se refiere a características mensurables, es decir,

cosas que se pueden comparar para conocer estándares, como longitud, color,maleabilidad, etc. Sin embargo, el software, principalmente una entidadintelectual, es más difícil de caracterizar que los objetos físicos.

La calidad de diseño, se refiere a las características que los diseñadoresespecifican para un elemento. La calidad de concordancia es el grado en elquelas especificaciones de diseño se aplican durante la fabricación.

En el desarrollo de software, la calidad de diseño incluye requisitos,especificaciones y el diseño del sistema. La calidad de concordancia es untema enfocado principalmente en la implementación.

El control de la variación puede equipararse con el control de calidad; elcontrol de calidad involucra una serie de inspecciones, revisiones y pruebasempleadas a lo largo del proceso del software para garantizar que cadaproducto de trabajo satisfaga los requisitos que se le han asignado. El controlde calidad incluye un bucle de retroalimentación con el proceso que creó elproducto de trabajo. La combinación de medición y retroalimentación permite

Page 69: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 69/86

 

     0     0     8

Planificación y Modelado

afinar el proceso cuando los productos de trabajo creados fracasan en cuanto asatisfacer sus especificaciones.

Un concepto clave del control de calidad es que todos los productos detrabajo tienen especificaciones definidas mesurables con las cuales se puede

comparar la salida de cada proceso. El bucle de retroalimentación es esencialpara minimizar los defectos producidos.

El control de la calidad implica el proceso de desarrollo de software paraasegurar que se sigan los procedimientos de aseguramientos y estándares decalidad; los productos resultantes de un proceso de software se compruebancontra los estándares definidos del proyecto en el proceso de control decalidad.

El proceso de control de calidad tiene su propio conjunto deprocedimientos e informes a utilizar durante el desarrollo de software. Estosprocedimientos son directos y fácilmente comprensibles por los ingenieros quedesarrollan el software.

Existen dos enfoques complementarios para el control de la calidad:

Revisiones de la calidad en las que el software, su documentación y losprocesos utilizados para producir ese software son revisados por un grupo depersonas. Son responsables de comprobar que se han seguido los estándaresdel proyecto y que el software y los documentos están acordes a estosestándares. Toman las desviaciones de los estándares y las ponen aconsideración de la administración del proyecto.

Valoración automática del software en la que el software y losdocumentos producidos se procesan por algún programa y se comparan conlos estándares que aplica a ese proyecto de desarrollo en particular. Estavaloración automática comprende una medida cuantitativa de algunosatributos del software.

Las revisiones son el método más utilizado para validar la calidad de unproceso o producto. Involucran a un grupo de personas que examinan parte otodo el proceso del software, los sistemas o su documentación asociada paradescubrir problemas potenciales. Las conclusiones de la revisión se registranformalmente y se pasan al autor o a quien sea responsable de corregir losproblemas descubiertos.

El cometido del equipo de revisión es detectar los errores einconsistencias y señalarlas al diseñador o autor del documento. Las revisionesse basan en documentos pero no se limitan a las especificaciones, diseños ocódigo. Se revisan todos los documentos tales como los modelos de proceso,

Page 70: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 70/86

 

     0     0     8

Planificación y Modelado

los planes de prueba, los procedimientos de administración de la configuración,los estándares del proceso y los manuales de usuario.

Unidad 4

Análisis de los requerimientos.

En la ingeniería de sistemas, un requerimiento es una necesidaddocumentada sobre el contenido, forma o funcionalidad de un producto oservicio. Se usa en un sentido formal en la ingeniería de sistemas o la

ingeniería de software.En la ingeniería clásica, los requerimientos se utilizan como datos de

entrada en la etapa de diseño del producto. Establecen QUÉ debe hacer elsistema, pero NO CÓMO hacerlo.

La fase del desarrollo de requerimientos puede estar precedida por unafase de análisis conceptual del proyecto. Esta fase puede dividirse enrecolección de requerimientos de los inversores, análisis de consistencia e

Page 71: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 71/86

 

     0     0     8

Planificación y Modelado

integridad, definición en términos descriptivos para los desarrolladores y unesbozo de especificación, previo al diseño completo

Los requerimientos de información de un nuevo sistema implican laidentificación de quién necesita que información, dónde, cómo y cuándo. El

análisis de requerimientos define los objetivos del sistema nuevo o modificadoy desarrolla una descripción detallada de las funciones que debe llevar a caboel nuevo sistema. Los requerimientos deben considerar las restricciones decarácter económico, técnico y de tiempo así como las metas, procedimientos ylos procesos de decisiones en la institución.

Un mal análisis de requerimientos es una de las causas principales de lafalla de los sistemas y de los costos elevados del desarrollo.

Para obtener los requerimientos de los sistemas de información, losanalistas deben trabajar una y otra vez en enunciados de requerimientos encolaboración con los usuarios.

El análisis de sistemas a menudo hace una contribución no intencional ala institución al aclarar los procedimientos y llegar a un consenso sobre cómodeben hacerse las cosas.

Una vez culminada la etapa de requerimientos los revisoresindependientes revisarán lo efectuado, no sólo las funciones sino también laauditabilidad del sistema.

En ingeniería de sistemas existen tres tipos de requerimientos.

Un requerimiento funcional puede ser una descripción de lo que unsistema debe hacer. Este tipo de requerimiento específica algo que el sistemaentregado debe ser capaz de realizar.

Un requerimiento no funcional: de rendimiento, de calidad, etc;especifica algo sobre el propio sistema, y cómo debe realizar sus funciones.Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, elmantenimiento, la facilidad de uso, etc.

Otros tipos de limitaciones externas, que afectan en una forma indirectaal producto. Estas pueden ir desde la compatibilidad con cierto sistema 

operativo hasta la adecuación a leyes o regulaciones aplicables al producto

Una colección de requerimientos describe las características o atributosdel sistema deseado. Se omite el cómo debe lograrse su implementación, yaque esto debe ser decidido en la etapa de diseño por los diseñadores.

En la ingeniería de software se aplica el mismo significado, sólo que elénfasis está puesto en el propio software.

Page 72: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 72/86

 

     0     0     8

Planificación y Modelado

4.1 Requerimientos funcionales y no funcionales.

4.1.1 Requerimientos funcionales.Los requerimientos funcionales son declaraciones de los servicios que proveeráel sistema, de la manera en que éste reaccionara a entradas particulares y decómo se comportara en situaciones particulares. En algunos casos, losrequerimientos funcionales de los sistemas también declaran explícitamente loque el sistema no debe de hacer.

Los requerimientos funcionales especifican los servicios que debeproporcionar la aplicación (por ejemplo, “la aplicación debe calcular el valor del

Page 73: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 73/86

 

     0     0     8

Planificación y Modelado

portafolio de inversión del usuario”). Por otro lado, un requerimiento como “laaplicación debe terminar el cálculo del valor de cada portafolio en menos de 1segundo” no es un requerimiento funcional, porque no especifica un serviciodado. En su lugar, califica un servicio o servicios (especifica algo sobre ellos).

Los requerimientos funcionales de un sistema describen la funcionalidado los servicios que se espera que éste proveerá, esto depende del tipo desoftware y del sistema que se desarrolle y de los posibles usuarios delsoftware. Cuando se expresan como requerimientos del usuario, habitualmentese describen de forma general mientras que los requerimientos funcionales delsistema describen con detalle la función de éste, sus entradas y salidas,excepciones, etc.

Los requerimientos funcionales para un sistema de software se expresande diferentes formas. Algunos de estos requerimientos para un sistema debiblioteca universitario para estudiantes y académicos que solicitan libros y

documentos de otras bibliotecas son:

El usuario deberá tener la posibilidad de buscar en el conjunto inicial dela base de datos o seleccionar un subconjunto de ella.

El sistema deberá proveer visores adecuados para que el usuario leadocumentos en el almacén de documentos.

A cada pedido se le deberá asignar un identificador único que el usuariopodrá copiar al área de almacenamiento permanente de la cuenta.

Estos son requerimientos funcionales del usuario que definen los

recursos específicos que el sistema debe proveer. Dichos requerimientos setoman del documento de requerimientos del usuario para el sistema e ilustranlos diferentes niveles de detalle en que se pueden relacionar losrequerimientos funcionales (contrastar los requerimientos 1 y 3).

Muchos de los problemas de la ingeniería de software provienen de laimprecisión en la especificación de requerimientos. Para un desarrollador desistemas es natural dar interpretaciones de un requerimiento ambiguo con elfin de simplificar su implementación. Sin embargo, a menudo no es lo que elcliente desea. Se tienen que estipular nuevos requerimientos y se deben hacercambios al sistema. Por supuesto, eso retrasa la entrega de éste e incrementalos costos.

En principio, la especificación de requerimientos funcionales de unsistema debe estar completa y ser consistente. La compleción significa quetodos los servicios solicitados por el usuario están definidos. La consistenciasignifica que los requerimientos no tienen definiciones contradictorias. En lapráctica, para sistemas grandes y complejos, es posible cumplir los

Page 74: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 74/86

 

     0     0     8

Planificación y Modelado

requerimientos de consistencia y compleción. La razón de esto se debeparcialmente a la complejidad inherente del sistema y parcialmente a que losdiferentes puntos de vista tienen necesidades inconsistentes. Estasinconsistencias no son obvias cuando los requerimientos se especifican porprimera vez. Los problemas emergen después de un análisis profundo. Una vez

que estos se hayan descubierto en las diferentes revisiones o en las fasesposteriores del ciclo de la vida, se deben corregir en el documento derequerimientos.

4.1.2 Requerimientos no funcionales.Los requerimientos no funcionales son restricciones de los servicios o funcionesofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso dedesarrollo, estándares, etc. Muchos requerimientos no funcionales se refierenal sistema como un todo más que a rasgos particulares del mismo, lo quesignifica que a menudo son más críticos que los requerimientos funcionales. Elincumplimiento en un funcional degrada el sistema, mientras que el fallo en un

no funcional, inutilizara el sistema.

Sin embargo, los requerimientos no funcionales no siempre se refieren alsistema de software a desarrollar. Algunos de estos requerimientos restringenel proceso a utilizar en el desarrollo del sistema. Algunos de estosrequerimientos de procesos son la especificación de los estándares de calidadque se deben utilizar en el proceso, una especificación que el diseño debeproducir una herramienta CASE particular y una descripción del proceso aseguir.

Los requerimientos no funcionales surgen de la necesidad del usuario,

debido a las restricciones del presupuesto, a las políticas de la organización, ala necesidad de interoperabilidad con otros sistemas de software o hardware oa factores externos. El diagrama muestra una clasificación de los diferentestipos de requerimientos no funcionales que puede haber.

Page 75: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 75/86

 

     0     0     8

Planificación y Modelado

Figura 4.1 requerimientos funcionales.

Estos diferentes tipos de requerimientos que se muestran en la figura4.1 anterior se clasifican de acuerdo con sus implicaciones:

Requerimientos del producto: estos especifican el comportamiento delproducto. Algunos ejemplos son los requerimientos de desempeño en larapidez de ejecución del sistema y cuanta memoria se requiere; los defiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los deportabilidad y los de usabilidad.

Requerimientos organizacionales: se derivan de las políticas yprocedimientos existentes en la organización del cliente y en la deldesarrollador. Algunos ejemplos son los estándares en los procesos que debenutilizarse; los requerimientos de implementación como los lenguajes deprogramación o el método de diseño a utilizar, y los requerimientos de entregaque especifican cuando se entregara el producto y su documentación.

Requerimientos externos: este gran apartado cubre todos losrequerimientos que se derivan de los factores externos al sistema y de suproceso de desarrollo. Estos incluyen los requerimientos de interoperabilidadque definen la manera en que el sistema interactúa con los otros sistemas de

la organización; los requerimientos legales que deben seguirse para asegurarque el sistema opere dentro de la ley, y los requerimientos éticos. Estosúltimos son impuestos al sistema para asegurar que será aceptado por elusuario y por el público en general.

Un problema común con los requerimientos no funcionales es quealgunas veces no se pueden verificar. Se redactan para reflejar las metasgenerales del usuario, como la facilidad de uso, la capacidad del sistema para

Page 76: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 76/86

 

     0     0     8

Planificación y Modelado

recuperarse de las fallas o la respuesta rápida del usuario. Estosrequerimientos causan problemas a los desarrolladores del sistema puesto quedejan abierta la posibilidad a interpretación, lo que provoca discusionessubsecuentes una vez que el sistema se entregue.

4.2 Casos de uso.

El proceso unificado de desarrollo de software (USDP) explota la observaciónde que muchos requerimientos ocurren de manera natural en secuenciasoperativas. Por ejemplo, el requerimiento individual de que una aplicación parauna tienda de videos permita introducir el titulo de un nuevo video suele serparte de una secuencia de transacciones. Estas son los casos de uso, algunasveces llamados “escenarios” (en UML, un “escenario” es en realidad unainstancia de un caso de uso). El USDP favorece la organización de losrequerimientos por casos de uso. Organizarlos de esta manera es útil para

producir casos de uso más grandes a partir de los pequeños.

Cuando se usa como parte del análisis de tareas, el caso de uso sedesarrolla para que muestre la manera en que el usuario final realiza algunatarea relacionada con el trabajo; Casi siempre, el caso de uso se escribe demanera informal (un solo párrafo) en primera persona.

4.2.1 Los Casos de uso y el valor del sistema.A quién no le ha pasado que siente la necesidad de comprar algo sólo paraterminar con ese producto en un rincón sin jamás ser utilizado. Nos pudo haberpasado porque no alcanzó nuestras expectativas, o porque resultó demasiado

complicado de utilizar, o porque en realidad no era una verdadera necesidadsino simplemente un capricho. Sea cual fuera la razón, la realidad es quehicimos un gasto inútil e innecesario.

Con el software, y en particular con el desarrollo de software a la medidaocurre con bastante frecuencia algo similar. Pues, no es raro encontrarse conempresas que contratan un desarrollo de software sólo para darse cuenta deque desperdiciaron su dinero y su tiempo, pues no obtuvieron lo que ellosesperaban o necesitaban. En otras palabras, no obtuvieron el valor queesperaban recibir para su negocio con el software adquirido.

4.2.1.1 La Administración de requerimientos.Una de las razones principales por las cuales se da esta situación, y de hecho,una de las causas principales por las cuales los proyectos de desarrollofracasan o por lo menos no tienen el éxito que deberían, se debe a una malaadministración de requerimientos. Esto generalmente se da por falta ya sea dehabilidades en el personal responsable o de técnicas apropiadas utilizadas parallevar a cabo esta labor.

Page 77: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 77/86

 

     0     0     8

Planificación y Modelado

La administración de requerimientos, de acuerdo a CMM, abarcaactividades como la recopilación, documentación, validación y control de losrequerimientos y sus cambios. UML, como estándar integrador de las buenasprácticas de desarrollo nos ofrece en este sentido los casos de uso como unatécnica excelente para administrar los requerimientos de nuestros proyectos.

4.2.1.2 ¿Consultoría o manufactura?

Si queremos realizar una verdadera consultoría de software entonces noscorresponde algo más que escuchar la lista de funciones que el cliente creeque debería de tener su sistema (a menos que nuestro cliente tenga un áreacon la capacidad de realizar una buena recopilación y análisis derequerimientos).

Si nos limitáramos a lo primero entonces en lugar de llamarle consultoríaa nuestro trabajo, deberíamos llamarle manufactura de software, donde unoimplementa las funciones exactamente cómo se las solicita el cliente,cuestionando nada o muy poco, tal como se haría en una planta manufactureradonde se reciben las especificaciones del producto a construir.

4.2.1.3 El sistema y su misión.

Si queremos desarrollar el mejor sistema posible debemos realizar un trabajoserio para identificar, en primer lugar, cuál es el valor que el sistema debeproporcionar al negocio. Para lo cual habrá que preguntárselo a las personasque obtendrán alguna clase de beneficio cuando se ponga en operación. Unabuena parte de estas personas probablemente vayan a ser usuarios del

sistema; en UML los conocemos como Actores (más adelante veremos otrostipos de Actores que también tendremos que identificar).

4.2.1.4 Buscando los beneficios del sistema.

Una vez identificados los usuarios del sistema (actores primarios) habrá quepreguntarles en qué situaciones valdrá la pena para ellos utilizarlo. La listaidentificada de dichas situaciones no debería de tener pequeñas funciones,sino flujos completos que le proporcionen suficiente valor tanto a ellos como alnegocio, de manera que “valga la pena usar el sistema” en dichas situaciones.

Ejemplo: un vendedor en cierto sistema de ventas querrá “Registrar

venta”, “Registrar pedido”, “Consultar comisiones”, “Administrar prospectos”,“Generar factura” y “Administrar clientes”. Todas ellas son ejemplos desituaciones u objetivos importante que podría necesitar un vendedor parallevar a cabo su trabajo, conocidas y modeladas como casos de uso en UML, talcomo se muestra en el diagrama de la figura 4.2.

Page 78: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 78/86

 

     0     0     8

Planificación y Modelado

Figura 4.2 caso de uso

4.2.1.5 Los requerimientos funcionales.

Normalmente los casos de uso son iniciados por algún actor, conocido comoactor primario. Lo inicia con algún evento, que podría ser tan simple comoelegir una opción en el sistema, y continúa como una serie de eventos ointeracciones entre actores y sistema, hasta que el objetivo del caso de uso se

cumple (el objetivo principal del caso de uso es lo que le da el nombre almismo). Por lo tanto los casos de uso describen la funcionalidad del sistemapara alcanzar objetivos importantes.

Lo que estamos obteniendo así es una especificación de requerimientosfuncionales mediante un análisis top-down (de lo general a lo particular), esdecir, primero obtenemos los objetivos que hay que cumplir en el sistemadescritos con el nombre del caso de uso (p. ej: Realizar una venta) y despuésbuscamos cuáles son las funciones o requerimientos funcionales precisos yordenados para que el actor cumpla dicho objetivo al utilizar sistema. Esto noslleva a identificar requerimientos realmente relevantes para alcanzar la misión

del sistema.

Resumen para recopilar los requerimientos funcionales adecuados delsistema mediante casos de uso:

1. Especificar la misión del sistema

2. Identificar quiénes utilizarán el sistema (actores primarios)

Page 79: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 79/86

 

     0     0     8

Planificación y Modelado

3. Averiguar cuáles objetivos desean cumplir los actores al usar el sistema(casos de uso)

4. Identificar los pasos o eventos de cada caso de uso (especificación del casode uso)

4.2.1.5 Las interfaces del sistema.Hay otro tipo de actores que también hay que modelar; los actoressecundarios. Suelen ser otros sistemas, componentes externos o dispositivoscon los cuales interactúa nuestro sistema. A diferencia de los actoressecundarios, éstos no son los que inician o requieren del caso de uso, sino quenuestro sistema, al llevar a cabo un caso de uso requiere tener algún tipo deinteracción con él.

En el diagrama de casos de uso también suele ser apropiado mostrar aeste tipo de actores, en cuyo caso aparecerán asociados a los casos de usodurante los cuales tienen que intervenir con algún tipo de interacción con elsistema a modelar.

Por experiencia sabemos que, en los modelos de UML, el buen uso de

pocos elementos da mejores resultados que el uso de muchos elementos malaplicados. La esencia de los modelos radica en la simplicidad, ya que facilita elanálisis, entendimiento y comunicación entre quienes solicitan el sistema y losque participan en su desarrollo.

En otras oportunidades veremos elementos adicionales para modelar loscasos de uso, pero podemos asegurar que la sencillez es parte importante delmodelado, y esto implica que en ocasiones, y sobre todo cuando el analista notiene tanta experiencia en UML, es mejor limitarnos a los elementos másbásicos.

 

Ejemplo de Actor Secundario.

Nuestro sistema de ventas podría requerir enviarle información al sistema decontabilidad cuando se ejecuta la funcionalidad del caso de uso “Generar factura”. Endicha situación el sistema de contabilidad aparecerá como un actor secundarioasociado a dicho caso de uso. De esta forma estamos mostrando las interfacesrequeridas con otro sistema en cada momento.

Page 80: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 80/86

 

     0     0     8

Planificación y Modelado

4.3 Diseño de interfaz de usuario.

El diseño de sistemas de computo comprende varias actividades que vandesde el diseño de hardware hasta el de la interfaz de usuario. Son muy pocoslos especialistas que trabajan en el diseño de la interfaz de usuario, es por esoque muchas veces los ingenieros del software tienen que encargarse dediseñar este aspecto, así como de diseñar el software que implemente estainterfaz.

El diseño de la interfaz se concentra en tres áreas:

• El diseño de interfaces entre componentes de software

• El diseño de interfaces entre el software y otros productores yconsumidores de la información que no son humanos (entidadesexternas)

• El diseño de la interfaz entre un ser humano y la computadora.

Solo hablaremos del número 3, la interfaz de usuario.El diseño de la interfaz de usuario crea un medio de comunicación efectiva

entre un ser humano y una computadora. Siguiendo un conjunto de principiosde diseño de interfaces, el diseñador identifica los objetos y las acciones de lainterfaz y luego crea un formato en la pantalla que forma la base de unprototipo de interfaz de usuario.

Un ingeniero de software diseña la interfaz de usuario al aplicar un procesoiterativo basado en principios de diseño ampliamente aceptados.

Si el uso del software es difícil, si lleva al usuario a cometer errores o si

frustra sus esfuerzos por alcanzar sus objetivos, no le gustara, sin importar sucapacidad ni las funciones que ofrezca. La interfaz tiene que ser correctaporque moldea la percepción del usuario acerca del software.

Aunque las interfaces basadas en texto aun se utilizan, especialmente enlos sistemas heredados, actualmente los usuarios de las computadorasesperan que los sistemas de aplicaciones tengan algún tipo de interfaz graficade usuario.

Page 81: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 81/86

 

     0     0     8

Planificación y Modelado

Las computadoras contienen GUIs (interfaz grafica de usuario) lo que lepermite el despliegue en color de alta resolución e interacción utilizando tantoel teclado como el mouse.

Las ventajas de las GUIs son:

• Son relativamente fáciles de aprender y utilizar.

• Para interactuar con el sistema, los usuarios cuentan con pantallasmúltiples.

• Es posible interactuar rápidamente y tener acceso inmediato a cualquierpunto de la pantalla.

Características de las interfaces graficas de usuario:

Características

Descripción

Ventanas Las ventanas múltiples permiten que se desplieguensimultáneamente información diversa en la pantalla delusuario

Iconos Los iconos representan diferentes tipos de información. Enalgunos sistemas, los iconos representan archivos; en otros,procesos

Menús Los comandos se seleccionan de un menú en lugar deteclearse en un lenguaje de ordenes

Apuntador Para seleccionar opciones de un menú o para indicarelementos de interés en una ventana, se utiliza un dispositivoapuntador, como el ratón

Gráficos Los elementos gráficos se pueden mezclar con texto en elmismo despliegue

Page 82: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 82/86

 

     0     0     8

Planificación y Modelado

El proceso de diseño de la interfaz de usuario.

Diseñar el

prototipo

Prototipoejecutable

Analizar ycomprenderlasactividadesdel usuario

Producir unprototipo dediseño en

papel

Producir elprototipo del

diseñodinamice

Evaluar el

diseño conlos usuariosfinales

Implementar

la interfaz delusuario final

Evaluar el diseñocon los usuarios

finales

Page 83: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 83/86

 

     0     0     8

Planificación y Modelado

4.3.1 Reglas en el diseño de interfaz de usuario.El diseño de la interfaz de usuario requiere el estudio de las personas y elconocimiento tecnológico adecuado

En su libro sobre diseño de interfaces, Theo Mantel [MAN97] acuño tresreglas de oro para el diseño de la interfaz:

• Dar el control al usuario

• Reducir la carga en la memoria del usuario

• Lograr que la interfaz sea consistente

• Dar el control al usuario

Se necesitan sistemas que reaccionen a las necesidades de los usuarios yque le ayuden a hacer las cosas; que el usuario controle la computadora, noque la computadora controle al usuario.

Se debe definir los modos de interacción de forma que el usuario no realiceacciones innecesarias o indeseables, esto es, que el usuario pueda decidir si

entrar o salir de diferentes tipos de interacción

Proporcionar una interacción flexible, esto es, que le permita al usuariointeractuar con la interfaz mediante movimientos del ratón, del lápizdigitalizador o comandos seleccionados con el teclado o mediantereconocimiento de voz

Incluir las opciones de interrumpir y deshacer la interacción del usuario,esto quiere decir que el usuario es libre de dejar de hacer lo que estabahaciendo para iniciar un proceso nuevo pero sin perder lo que ya había hecho opoder deshacer acciones que ya haya hecho.

Depurar la interacción a medida de que aumentan los grados de destreza ypermitir que se personalice la interacción, o sea, que se pueda personalizar lainterfaz con el fin de los usuarios que repitan secuencias de interacciones.

Oculte al usuario ocasional los elementos técnicos internos; la interfaz debellevar al usuario al mundo virtual de la aplicación; no es necesario que conozca

Page 84: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 84/86

 

     0     0     8

Planificación y Modelado

el sistema operativo, las funciones de administración de archivos u otrossecretos de la tecnología de computo.

Diseñar interacción directa con los objetos que aparecen en pantalla; elusuario siente que tiene el control cuando manipula los objetos necesarios para

realizar una tarea de manera parecida a como lo haría con un objeto material.Reducir la carga en la memoria del usuario; entre más cosas tenga que

recordar el usuario, mas fácil será que cometa errores; es por eso que unainterfaz debe “recordar” la información pertinente y ayudar al usuario con unescenario de interacción que le facilite el uso de la memoria.

Se debe reducir la demanda de memoria a corto plazo, esto es, que lainterfaz se debe diseñar para que se reduzca la necesidad de recordar accionesy resultados anteriores. Esto se logra al proporcionar pistas visuales quepermitan al usuario reconocer acciones anteriores sin tener que recordarlas.

Se deben definir valores por defecto que tengan significado; el conjuntoinicial de valores por defecto debe tener un sentido para el usuario promedio,pero también contar con la posibilidad de especificar sus preferencias.

  También se debe definir accesos directos intuitivos, esto es, cuando seemplea la mnemotécnica para aplicar una función del sistema, debe estarunida a una acción de manera tal que resulte fácil de recordar.

El formato visual de la interfaz debe basarse en una metáfora tomada de larealidad, osea, se debe encontrar acciones de la vida real y conectarlasmediante la interfaz a algo semejante para poder llevar a cabo la acción

deseada.

Desglosar la información de manera progresiva; la interfaz debe organizarse  jerárquicamente, la información sobre una tarea, un objeto o algúncomportamiento debe presentarse primero en un alto grado de abstracción.Después de que el usuario se interese en seleccionar algo con el ratón, debenpresentarse más detalles.

Lograr que la interfaz sea consistente

La interfaz debe adquirir y presentar la información de manera consistente.

Esto implica que:

•  Toda la información visual esté organizada de acuerdo con un estándarde diseño que se mantenga en todas las presentaciones de pantalla.

• Los mecanismos de entrada se restrinjan a un conjunto limitado que seutilice de manera consistente en toda la aplicación.

Page 85: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 85/86

 

     0     0     8

Planificación y Modelado

• Los mecanismos para ir de una tarea a otra se hayan definido eimplementado de manera consistente.

Se debe permitir que el usuario incluya la tarea actual en un contexto quetenga algún significado; muchas interfaces implementan capas complejas de

interacciones con docenas de imágenes en pantalla. Es importanteproporcionar indicadores que permitan al usuario conocer el contexto deltrabajo que realiza.

Mantener la consistencia en toda una familia de aplicaciones, se debe deimplementar las mismas reglas de diseño para mantener la consistencia entodas las interacciones

Si modelos interactivos anteriores han generado expectativas en el usuario,no hacer cambios a menos que haya razones inexcusables. Una vez que unasecuencia interactiva se ha convertido en un estándar de facto, el usuario

espera esto en todas las aplicaciones que encuentre.

Bibliografia:

1. Pressman Roger S (2001).Ingeniería del Software, 5/E.Ed. Mc Graw Hill.

2. Sommerville, Ian (2001).Ingeniería de Software.Ed. Prentice Hall.

3. Kotonya, Gerald, Sommerville, Ian (2003).

Requirements Engineering : Processes and Techniques.Ed. Wiley.

4. Jacobson,Ivar. (2000).El Proceso unificado de desarrollo de Software.Ed. Addison Wesley.

5. Fowler, Martin, (1999).UML Gota a Gota.

Page 86: Planificación y Modelado

5/10/2018 Planificación y Modelado - slidepdf.com

http://slidepdf.com/reader/full/planificacion-y-modelado-559dfc4821fed 86/86

 

     0     0     8

Planificación y Modelado

Ed. Addison Wesley.

6. Larman, Craig (1999).UML y patrones.Ed. Pearson.

7. Humphrey, Watts S. (2000)..Introducción al Proceso Software Personal.Ed. Addison Wesley.

8. Pfleeger, Shari Lawrence (2002).Ingeniería de Software Teoría y práctica.Ed. Prentice Hall.

9. Bruegge Bernd (2001).Ingeniería de Software Orientada a Objetos.Ed. Prentice Hall.

10. Braude, Eric (2003).Ingeniería de Software Una perspective Orientada a Objetos.Ed. Alfaomega.

11. Meyer, Bertrand (1999).I Construcción de Software Orientada a Objetos.Ed. Prentice Hall.

12. Laudon & Laudon 8/E (2003).Management Information Systems.Ed. Prentice Hall.