CARRERA: INGENIERÍA DE SISTEMAS

PROYECTO INGENIERÍA DE SOFTWARE

INTEGRANTES:

NICOLE SERRATE

HUGO MARCELO AJHUACHO

ERICK RODRIGO MAMANI

DOCENTE: Ing. Zuleica Mariaca

AGOSTO 2018
Santa Cruz – Bolivia

II
 INDICE

INDICE............................................................................................................................ii

1. ENUNCIADO DEL CASO DE ESTUDIO................................................................1

2. ASPECTOS GENERALES.....................................................................................5

2.1. Título del proyecto............................................................................................5

2.2. Introducción......................................................................................................5

2.3. Definición del problema....................................................................................5

2.4. Delimitaciones...................................................................................................5

2.4.1. Geográfica.....................................................................................................5

2.4.2. Temporal.......................................................................................................5

2.4.3. Temática........................................................................................................6

2.4.4. Alcance..........................................................................................................6

2.5. Objetivo General...............................................................................................6

2.6. Objetivos Específicos.......................................................................................6

3. MARCO TEORICO INGENIERIA DE SOFTWARE...............................................7

3.1. Qué es y qué no es Ingeniería de Software.....................................................7

3.2. Principios fundamentales..................................................................................7

3.2.1. Principios que guían el proceso....................................................................7

3.2.2. Principios que guían la práctica....................................................................8

3.3. Principios que guían toda la actividad estructural..........................................10

3.3.1. Principios de comunicación.........................................................................10

3.3.2. Principios de planeación.............................................................................12

3.3.3. Principios de modelado...............................................................................14

3.3.4. Requerimientos de los principios de modelado..........................................17

II
3.3.5. Principios del modelo de diseño.................................................................18

3.4. Principios de construcción..............................................................................21

3.4.1. Principios de codificación............................................................................21

3.4.1.1. Principios de preparación........................................................................21

3.4.1.2. Principios de programación.....................................................................21

3.4.1.3. Principios de validación............................................................................22

3.4.1.4. Principios de la prueba.............................................................................22

3.4.1.5. Principios de despliegue..........................................................................23

3.5. Qué es calidad................................................................................................24

3.5.1. Calidad del software....................................................................................24

3.5.2. El dilema de la calidad del software............................................................24

3.5.2.1. Software “suficientemente bueno”...........................................................25

3.5.2.2. El costo de la calidad...............................................................................25

3.5.2.3. Riegos......................................................................................................25

3.5.3. Lograr la calidad del software.....................................................................25

3.5.3.1. Métodos de la Ingeniería de Software.....................................................26

3.5.3.2. Técnicas de administración de proyectos................................................26

3.5.3.3. Control de calidad....................................................................................26

3.5.3.4. Aseguramiento de la calidad....................................................................26

3.6. Elementos de aseguramiento de la calidad de software................................27

3.6.1. Seguridad del Software...............................................................................27

3.7. Administración del Proyecto...........................................................................27

3.7.1. El espectro Administrativo...........................................................................28

3.7.1.1. Definición de: El Personal........................................................................28

3.7.1.1.1. Participantes.........................................................................................28

II
3.7.1.1.2. Líderes de Equipo.................................................................................29

3.7.1.1.3. Equipo de Software..............................................................................29

3.7.1.2. Definición de: El producto........................................................................29

3.7.1.2.1. Ámbito del software..............................................................................30

3.7.1.2.2. Descomposición del problema.............................................................30

3.7.1.3. Definición de El proceso..........................................................................30

3.7.1.3.1. Fusión de producto y proceso..............................................................30

3.7.1.3.2. Descomposición del proceso................................................................30

3.7.1.4. Definición de: El proyecto........................................................................31

3.8. Calendarización del Proyecto.........................................................................31

3.9. Métricas del Producto.....................................................................................31

3.9.1. Medidas, métricas e indicadores.................................................................31

3.9.2. Principios de medición................................................................................32

3.9.3. Métricas para el Modelo de Requerimientos..............................................32

3.9.3.1. Métricas basadas en funciones...............................................................32

3.9.3.2. Métricas para calidad de la especificación..............................................32

3.9.4. Métricas para el Modelo de Diseño.............................................................33

3.9.5. Métricas para diseño orientado a objetos...................................................33

3.9.6. Métricas para Pruebas................................................................................35

3.9.6.1. Métricas para pruebas Orientados a Objetos..........................................35

3.9.6.2. Métricas para Mantenimiento...................................................................36

3.9.7. Definición de: Métricas para Calidad del Software.....................................36

3.9.7.1. Medición de la calidad..............................................................................36

3.9.7.2. Eficiencia en la remoción del defecto......................................................37

3.9.7.3. Establecimiento de un programa de métricas de software......................37

II
 3.9.8. Administración del Riesgo...........................................................................38

3.9.8.1. Identificación de Riesgos.........................................................................38

3.9.8.2. Proyección del Riesgo.............................................................................38

3.9.8.3. Valoración de impacto de riesgo..............................................................39

3.9.8.4. El plan MMMR..........................................................................................39

4. MARCO TEORICO DE LA METODOLOGIA........................................................39

4.1. PUDS..............................................................................................................39

4.1.1. Características.............................................................................................40

4.1.1.1. Iterativo e Incremental..............................................................................40

4.1.1.2. Dirigido por los casos de uso...................................................................40

4.1.1.3. Centrado en la arquitectura.....................................................................41

4.1.1.4. Enfocado en los riesgos...........................................................................41

4.2. UML................................................................................................................41

4.2.1. Definición de Unificado................................................................................41

4.2.2. Tipos de Dominio.........................................................................................41

4.2.3. Objetivos UML.............................................................................................42

4.2.4. Modelo.........................................................................................................42

5. INGENIERIA DE SOFTWARE DEL PROYECTO................................................43

5.1. Planificación temporal.....................................................................................43

5.2. Organización del personal (Estructura del equipo de desarrollo del software)
44

5.3. Estimación del proyecto (Asumir Productividad = 29,5).................................45

5.3.1. Métricas basadas en Punto de función.......................................................45

5.3.2. Valores de ajuste de complejidad...............................................................47

5.3.3. Cálculo de punto de función........................................................................48

II
 5.3.4. Cálculo del Esfuerzo...................................................................................49

5.3.5. Cálculo de número de personas que conformarán el equipo de desarrollo

del software..............................................................................................................49

5.3.6. Costo del personal.......................................................................................49

5.3.7. Costo del Software......................................................................................49

5.4. Análisis y Gestión de Riesgos........................................................................50

5.4.1. Escala basada en el aspecto del personal..................................................50

5.4.2. Escala basada en el aspecto tecnológico...................................................50

5.4.3. Escala basada en el aspecto del negocio...................................................50

5.5. Gestión de la Calidad.....................................................................................51

5.5.1. Calidad en función a 5 métricas (Corrección, Confiabilidad, Eficiencia,

Integridad, Facilidad de Mantenimiento)..................................................................51

5.5.2. Normas........................................................................................................51

5.5.2.1. Norma ISO 25000....................................................................................51

5.6. Presupuesto....................................................................................................53

5.6.1. Costo parcial de las tareas de desarrollo de software................................53

5.6.2. Costo parcial de la gestión de proyecto......................................................53

5.6.3. Costo parcial de recursos............................................................................53

5.6.4. Costo parcial de servicios básicos..............................................................54

5.6.5. Costo parcial de material extra....................................................................54

5.6.6. COSTO TOTAL DEL PROYECTO..............................................................54

5.7. Plan de comunicación.....................................................................................54

6. INGENIERIA DEL PROYECTO............................................................................55

6.1. Modelo de Requisitos.....................................................................................55

6.1.1. Requerimientos funcionales........................................................................55

II
 6.1.2. Requisitos no funcionales...........................................................................57

6.1.3. Descripción de los actores..........................................................................58

6.2. Modelo de Análisis..........................................................................................59

6.2.1. Diagrama general de los casos de uso.......................................................59

6.2.2. Especificación del caso de uso “Registrar venta”.......................................61

Gestionar Ventas.........................................................................................................61

Vendedor......................................................................................................................61

Descripción...................................................................................................................61

Normal..........................................................................................................................61

Alternativa....................................................................................................................61

6.2.3. Modelo de dominio......................................................................................62

6.2.3.1. Diagrama de clases conceptuales...........................................................62

6.2.3.2. Modelo de datos relacional......................................................................63

6.3. Modelo de Diseño...........................................................................................64

6.3.1. Diagrama de secuencia...............................................................................64

6.4. Modelo de Implementación.............................................................................65

6.4.1. Modelo de Componentes............................................................................65

6.4.2. Modelo de Despliegue.................................................................................66

7. CONCLUSIONES.................................................................................................67

8. RECOMENDACIONES.........................................................................................67

9. BIBLIOGRAFIA.....................................................................................................68

II
 1. ENUNCIADO DEL CASO DE ESTUDIO

SISTEMA DE INFORMACION DE RECURSOS HUMANOS PARA LA EMPRESA

“REPSOL YPFB.SA”

I. SITUACION PROBLEMÁTICA

La empresa REPSOL YPFB S.A está teniendo dificultades con la gestión de

información del área de RRHH. En este sentido se precisa un sistema que pueda
gestionar los Kardex, Planillas de sueldo, Planillas de AFP, Vacaciones, Aguinaldos,
Liquidaciones, Control de lactancias y partes de alta y bajas del seguro médico.

II. LOGICA DE NEGOCIO

Los empleados son contratados por proyectos, los cuales pueden durar de uno a dos
años. Los contratos del personal administrativo son de carácter indefinido pero los
contratos del personal de campo son por proyecto. Un proyecto puede abarcar dos
zonas geográficas contiguas.

Tanto obreros como administrativos necesitan entregar la siguiente información: CI,

Nombre completo, Fecha de nacimiento, Estado civil, Dirección de domicilio y
Teléfono.

Para cada proyecto se contratan los obreros que harán el trabajo de desmonte,
perforación, detonación y rastreo sísmico de las líneas predeterminadas en las que
probablemente hay petróleo para que posteriormente otra empresa haga la
extracción del “oro negro”

Cada contrato especifica un haber básico acorde a la función (cocinero, enfermero,

capataz, mecánico) que le toca desempeñar al obrero en el campo.

Cada final de mes los administradores de los diferentes proyectos de campo deben
hacer llegar las planillas de asistencia de los obreros para procesar las respectivas
planillas de sueldo. Adjunto a las planillas de sueldo se deben imprimir las boletas de
pago.

Adicionalmente a la planilla general de sueldos se debe imprimir la planilla de AFP’s.

Al inicio de cada proyecto se debe imprimir una planilla de todos los trabajadores que
serán afiliados al seguro médico.

Cada fin de mes también se precisa una planilla de los obreros que deben ser
retirados del seguro de salud por fenecimiento de contrato.

1
La planilla mensual que se envía al seguro médico debe especificar los mismos
datos que la planilla de sueldo para reducir el monto mensual que la empresa debe
pagar al seguro.

Durante el mes laboral el sistema debe registrar las solicitudes de anticipo de

sueldos.

La empresa reconoce las duodécimas de vacaciones, aguinaldos para todo tipo de

contrato (obrero y administrativo)

Al finalizar un proyecto es necesario procesar los cálculos para liquidar a todos los
obreros excepto a los administrativos que continúan con sus contratos activos.

Es necesario controlar la acumulación de vacaciones para los administrativos según

la ley (1 a 5 años: 15 días; 6 a 9 años:20 días; >=10 años:30 días). También este tipo
de trabajadores tiene derecho a un bono de antigüedad según ley (2 a 4 años 5%; 5
a 7 años 11%; 8 a 10 años 18%, etc)

Los obreros deben hacer llegar a la oficina central sus formularios RCIVA para el
descargo del descuento (13%) por transacciones comerciales. Estos montos deben
ser tomados en cuenta a la hora de procesar la planilla de sueldo.

III. DESARROLLO APLICANDO INGENIERIA DE SOFTWARE

 Planificación temporal.

 Organización del personal (Estructura del equipo de desarrollo del

software)

 Estimación del proyecto (Asumir Productividad = 29,5)

 Métricas basadas en Punto de función

 Valores de ajuste de complejidad

 Cálculo de punto de función

 Cálculo del Esfuerzo

2
  Cálculo de número de personas que conformarán el equipo de
desarrollo del software.

 Costo del personal

 Costo del Software

 Análisis y Gestión de Riesgos

 Escala basada en el aspecto del personal

 Escala basada en el aspecto metodológico

 Escala basada en el aspecto del negocio

 Gestión de la Calidad

 Calidad en función a 5 métricas (Corrección, Confiabilidad,

Eficiencia, Integridad, Facilidad de Mantenimiento)

 Normas

 Presupuesto

 Costo parcial de las tareas de desarrollo de software.

 Costo parcial de la gestión de proyecto.

 Costo parcial de recursos

 Costo parcial de servicios básicos.

 Costo parcial de material extra

 COSTO TOTAL DEL PROYECTO

IV. DESARROLLO APLICANDO METODOLOGIA

El desarrollo debe ser realizado utilizando PUDS y UML.

3
V. CASOS DE USO BASICOS

VI. ARTEFACTOS SOLICITADOS

a) Modelo de Requisitos

 Requerimientos funcionales

 Requisitos no funcionales

 Descripción de los actores

b) Modelo de Análisis

 Diagrama general de los casos de uso (todos)

 Especificación del caso de uso seleccionado.

 Modelo de dominio

 Diagrama de clases conceptuales

 Modelo de datos relacional

c) Modelo de Diseño

 Diagrama de secuencia

 Diseño de reportes,

 Diseño de la base de datos: Lógico y físico

d) Modelo de Implementación

 Modelo de Componentes

 Modelo de Despliegue

4
2. ASPECTOS GENERALES

2.1. Título del proyecto

SISTEMA DE INFORMACION DE RECURSOS HUMANOS PARA LA EMPRESA

“REPSOL YPFB.SA”

2.2. Introducción

El presente documento tiene como objetivo el desarrollo de un SISTEMA DE

INFORMACION DE RECURSOS HUMANOS PARA LA EMPRESA “REPSOL
YPFB.SA”.

2.3. Definición del problema

La empresa REPSOL YPFB.SA, está teniendo dificultades con la gestión de

información del área de RRHH. En este sentido se precisa un sistema que pueda
gestionar los Kardex, Planillas de sueldo, Planillas de AFP, Vacaciones, Aguinaldos,
Liquidaciones, Control de lactancias y partes de alta y bajas del segundo médico.

2.4. Delimitaciones

La investigación tomará como espacio geográfico de recolección de información el

departamento de Santa Cruz específicamente en la zona metropolita

El presente proyecto será realizado tomando en cuenta datos comprendidos entre el

año 2012 – 2017, ya que en este periodo de tiempo la empresa VUITON SRL tuvo
mayores inconvenientes con su sistema desarrollado.

2.5. Objetivo General

Desarrollar un Sistema de Información de Recursos Humanos que permita cubrir las

necesidades de la automatización de las tareas de la empresa REPSOL YPFB.SA.

2.6. Objetivos Específicos

5
  Determinar los requerimientos del sistema a desarrollar con la finalidad de
sentar las bases para la elaboración de un diseño de acuerdo a las
necesidades y dificultades identificadas.
 Realizar la construcción del sistema de gestión que resuelva los problemas
analizados y que cumpla con los requerimientos obtenidos en la fase de
análisis y diseño.
 Efectuar la implementación del sistema desarrollado tomando en cuenta que
software resultante que cumple con todos los requisitos planteados y
aprobados por los encargados de la empresa VUITON SRL.

3. MARCO TEORICO INGENIERIA DE SOFTWARE

3.1. Qué es y qué no es Ingeniería de Software

La ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y

cuantificable al desarrollo, operación y mantenimiento de software, y el estudio de
estos enfoques, es decir, el estudio de las aplicaciones de la ingeniería al software.
Integra matemáticas, ciencias de la computación y prácticas cuyos orígenes se
encuentran en la ingeniería.[ CITATION Ian \l 3082 ]

3.2. Principios fundamentales

3.2.1. Principios que guían el proceso

Principio 1. Ser ágil. Ya sea que el modelo de proceso que se elija sea prescriptivo o
ágil, son los principios básicos del desarrollo ágil los que deben gobernar el enfoque.
Todo aspecto del trabajo que se haga debe poner el énfasis en la economía de
acción: en mantener el enfoque técnico tan sencillo como sea posible, hacer los
productos del trabajo que se generan tan concisos como se pueda y tomar las
decisiones localmente, siempre que sea posible.

Principio 2. En cada etapa, centrarse en la calidad. La condición de salida para toda

actividad, acción y tarea del proceso debe centrarse en la calidad del producto del
trabajo que se ha generado.

6
Principio 3. Estar listo para adaptar. El proceso no es una experiencia religiosa, en él
no hay lugar para el dogma. Cuando sea necesario, adapte su enfoque a las
restricciones impuestas por el problema, la gente y el proyecto en sí.

Principio 4. Formar un equipo eficaz. El proceso y práctica de la ingeniería de

software son importantes, pero el objetivo son las personas. Forme un equipo con
organización propia en el que haya confianza y respeto mutuos.

Principio 5. Establecer mecanismos para la comunicación y coordinación. Los

proyectos fallan porque la información importante cae en las grietas o porque los
participantes no coordinan sus esfuerzos para crear un producto final exitoso. Éstos
son aspectos de la administración que deben enfrentarse.

Principio 6. Administrar el cambio. El enfoque puede ser formal o informal, pero

deben establecerse mecanismos para administrar la forma en la que los cambios se
solicitan, evalúan, aprueban e implementan.

Principio 7. Evaluar el riesgo. Son muchas las cosas que pueden salir mal cuando se
desarrolla software. Es esencial establecer planes de contingencia.

Principio 8. Crear productos del trabajo que agreguen valor para otros. Sólo genere
aquellos productos del trabajo que agreguen valor para otras actividades, acciones o
tareas del proceso. Todo producto del trabajo que se genere como parte de la
práctica de ingeniería de software pasará a alguien más. La lista de las funciones y
características requeridas se dará a la persona (o personas) que desarrollará(n) un
diseño, el diseño pasará a quienes generan código y así sucesivamente. Asegúrese
de que el producto del trabajo imparte la información necesaria sin ambigüedades u
omisiones.[ CITATION Rog \l 3082 ]

3.2.2. Principios que guían la práctica

La práctica de la ingeniería de software tiene un solo objetivo general: entregar a

tiempo software operativo de alta calidad que contenga funciones y características

7
que satisfagan las necesidades de todos los participantes. Para lograrlo, debe
adoptarse un conjunto de principios fundamentales que guíen el trabajo técnico.
Estos principios tienen mérito sin que importen los métodos de análisis y diseño que
se apliquen, ni las técnicas de construcción (por ejemplo, el lenguaje de
programación o las herramientas automatizadas) que se usen o el enfoque de
verificación y validación que se elija. Los siguientes principios fundamentales son
vitales para la práctica de la ingeniería de software:

Principio 1. Divide y vencerás. Dicho en forma más técnica, el análisis y el diseño

siempre deben enfatizar la separación de entidades (SdE). Un problema grande es
más fácil de resolver si se divide en un conjunto de elementos (o entidades). Lo ideal
es que cada entidad entregue funcionalidad distinta que pueda desarrollarse, y en
ciertos casos validarse, independientemente de otras entidades.

Principio 2. Entender el uso de la abstracción. En su parte medular, una abstracción

es una simplificación de algún elemento complejo de un sistema usado para
comunicar significado en una sola frase. Cuando se usa la abstracción hoja de
cálculo, se supone que se comprende lo que es una hoja de cálculo, la estructura
general de contenido que presenta y las funciones comunes que se aplican a ella.

Principio 3. Buscar la coherencia. Ya sea que se esté creando un modelo de los

requerimientos, se desarrolle un diseño de software, se genere código fuente o se
elaboren casos de prueba, el principio de coherencia sugiere que un contexto familiar
hace que el software sea más fácil de usar.

Principio 4. Centrarse en la transferencia de información. El software tiene que ver

con la transferencia de información: de una base de datos a un usuario final, de un
sistema heredado a una webapp, de un usuario final a una interfaz gráfica de usuario
(GUI, por sus siglas en inglés), de un sistema operativo a una aplicación, de un
componente de software a otro… la lista es casi interminable. En todos los casos, la
información fluye a través de una interfaz, y como consecuencia hay posibilidades de
cometer errores, omisiones o ambigüedades. Este principio implica que debe
ponerse atención especial al análisis, diseño, construcción y prueba de las interfaces.

8
Principio 5. Construir software que tenga modularidad eficaz. La separación de
entidades (principio 1) establece una filosofía para el software. La modularidad
proporciona un mecanismo para llevar a cabo dicha filosofía. Cualquier sistema
complejo puede dividirse en módulos (componentes), pero la buena práctica de la
ingeniería de software demanda más. El modularidad debe ser eficaz.

Principio 6. Buscar patrones. Brad Appleton [App00] sugiere que: El objetivo de los
patrones dentro de la comunidad de software es crear un cúmulo de bibliografía que
ayude a los desarrolladores de software a resolver problemas recurrentes que surgen
a lo largo del desarrollo. Los patrones ayudan a crear un lenguaje compartido para
comunicar perspectiva y experiencia acerca de dichos patrones y sus soluciones. La
codificación formal de estas soluciones y sus relaciones permite acumular con éxito
el cuerpo de conocimientos que define nuestra comprensión de las buenas
arquitecturas que satisfacen las necesidades de sus usuarios.

Principio 7. Cuando sea posible, representar el problema y su solución desde varias

perspectivas diferentes. Cuando un problema y su solución se estudian desde varias
perspectivas distintas, es más probable que se tenga mayor visión y que se detecten
los errores y omisiones.

Principio 8. Tener en mente que alguien dará mantenimiento al software. El software

será corregido en el largo plazo, cuando se descubran sus defectos, se adapte a los
cambios de su ambiente y se mejore en el momento en el que los participantes pidan
más capacidades. Estas actividades de mantenimiento resultan más fáciles si se
aplica una práctica sólida de ingeniería de software a lo largo del proceso de
software[ CITATION Rog \l 3082 ]

3.3. Principios que guían toda la actividad estructural

3.3.1. Principios de comunicación

La comunicación efectiva (entre colegas técnicos, con el cliente y otros participantes,

y con los gerentes de proyecto) se encuentra entre las actividades más difíciles que

9
deben enfrentarse. En este contexto, aquí se estudian principios de comunicación
aplicados a la comunicación con el cliente. Sin embargo, muchos de ellos se aplican
por igual en todas las formas de comunicación que ocurren dentro de un proyecto de
software

Principio 1. Escuchar. Trate de centrarse en las palabras del hablante en lugar de

formular su respuesta a dichas palabras. Si algo no está claro, pregunte para
aclararlo, pero evite las interrupciones constantes. Si una persona habla, nunca
parezca usted beligerante en sus palabras o actos (por ejemplo, con giros de los ojos
o movimientos de la cabeza).

Principio 2. Antes de comunicarse, prepararse. Dedique algún tiempo a entender el

problema antes de reunirse con otras personas. Si es necesario, haga algunas
investigaciones para entender el vocabulario propio del negocio. Si tiene la
responsabilidad de conducir la reunión, prepare una agenda antes de que ésta tenga
lugar.

Principio 3. Alguien debe facilitar la actividad. Toda reunión de comunicación debe

tener un líder (facilitador) que: 1) mantenga la conversación en movimiento hacia una
dirección positiva, 2) sea un mediador en cualquier conflicto que ocurra y 3) garantice
que se sigan otros principios.

Principio 4. Es mejor la comunicación cara a cara. Pero por lo general funciona mejor
cuando está presente alguna otra representación de la información relevante. Por
ejemplo, un participante quizá genere un dibujo o documento en “borrador” que sirva
como centro de la discusión

Principio 5. Tomar notas y documentar las decisiones. Las cosas encuentran el modo
de caer en las grietas. Alguien que participe en la comunicación debe servir como
“secretario” y escribir todos los temas y decisiones importantes

Principio 6. Perseguir la colaboración. La colaboración y el consenso ocurren cuando

el conocimiento colectivo de los miembros del equipo se utiliza para describir
funciones o características del producto o sistema. Cada pequeña colaboración sirve

10
para generar confianza entre los miembros del equipo y crea un objetivo común para
el grupo

Principio 7. Permanecer centrado; hacer módulos con la discusión. Entre más

personas participen en cualquier comunicación, más probable es que la conversación
salte de un tema a otro. El facilitador debe formar módulos de conversación para
abandonar un tema sólo después de que se haya resuelto.

Principio 8. Si algo no está claro, hacer un dibujo. La comunicación verbal tiene sus
límites. Con frecuencia, un esquema o dibujo arroja claridad cuando las palabras no
bastan para hacer el trabajo.

Principio 9. a) Una vez que se acuerde algo, avanzar. b) Si no es posible ponerse de

acuerdo en algo, avanzar. c) Si una característica o función no está clara o no puede
aclararse en el momento, avanzar. La comunicación, como cualquier actividad de
ingeniería de software, requiere tiempo. En vez de hacer iteraciones sin fin, las
personas que participan deben reconocer que hay muchos temas que requieren
análisis (véase el principio 2) y que “avanzar” es a veces la mejor forma de tener
agilidad en la comunicación.

Principio 10. La negociación no es un concurso o un juego. Funciona mejor cuando

las dos partes ganan. Hay muchas circunstancias en las que usted y otros
participantes deben negociar funciones y características, prioridades y fechas de
entrega.[ CITATION Rog \l 3082 ]

3.3.2. Principios de planeación

La actividad de comunicación ayuda a definir las metas y objetivos generales (por

supuesto, sujetos al cambio conforme pasa el tiempo). Sin embargo, la comprensión
de estas metas y objetivos no es lo mismo que definir un plan para lograrlo. La
actividad de planeación incluye un conjunto de prácticas administrativas y técnicas
que permiten que el equipo de software defina un mapa mientras avanza hacia su
meta estratégica y sus objetivos tácticos

11
Principio 1. Entender el alcance del proyecto. Es imposible usar el mapa si no se
sabe a dónde se va. El alcance da un destino al equipo de software

Principio 2. Involucrar en la actividad de planeación a los participantes del software.

Los participantes definen las prioridades y establecen las restricciones del proyecto.
Para incluir estas realidades, es frecuente que los ingenieros de software deban
negociar la orden de entrega, los plazos y otros asuntos relacionados con el
proyecto.

Principio 3. Reconocer que la planeación es iterativa. Un plan para el proyecto nunca

está grabado en piedra. Para cuando el trabajo comience, es muy probable que las
cosas hayan cambiado. En consecuencia, el plan deberá ajustarse para incluir dichos
cambios. Además, los modelos de proceso iterativo incrementales dictan que debe
repetirse la planeación después de la entrega de cada incremento de software, con
base en la retroalimentación recibida de los usuarios.

Principio 4. Estimar con base en lo que se sabe. El objetivo de la estimación es

obtener un índice del esfuerzo, costo y duración de las tareas, con base en la
comprensión que tenga el equipo sobre el trabajo que va a realizar. Si la información
es vaga o poco confiable, entonces las estimaciones tampoco serán confiables

Principio 5. Al definir el plan, tomar en cuenta los riesgos. Si ha identificado riesgos

que tendrían un efecto grande y es muy probable que ocurran, entonces es
necesario elaborar planes de contingencia. Además, el plan del proyecto (incluso la
programación de actividades) deberá ajustarse para que incluya la posibilidad de que
ocurran uno o más de dichos riesgos.

Principio 6. Ser realista. Las personas no trabajan 100% todos los días. En cualquier
comunicación humana hay ruido. Las omisiones y ambigüedad son fenómenos de la
vida. Los cambios ocurren. Aun los mejores ingenieros de software cometen errores.
Éstas y otras realidades deben considerarse al establecer un proyecto.

Principio 7. Ajustar la granularidad cuando se defina el plan. La granularidad se

refiere al nivel de detalle que se adopta cuando se desarrolla un plan. Un plan con

12
“mucha granularidad” proporciona detalles significativos en las tareas para el trabajo
que se planea, en incrementos durante un periodo relativamente corto (por lo que el
seguimiento y control suceden con frecuencia).

Principio 8. Definir cómo se trata de asegurar la calidad. El plan debe identificar la

forma en la que el equipo de software busca asegurar la calidad. Si se realizan
revisiones técnicas, deben programarse. Si durante la construcción va a utilizarse
programación por parejas

Principio 9. Describir cómo se busca manejar el cambio. Aun la mejor planeación

puede ser anulada por el cambio sin control. Debe identificarse la forma en la que
van a recibirse los cambios a medida que avanza el trabajo de la ingeniería de
software. Por ejemplo, ¿el cliente tiene la posibilidad de solicitar un cambio en
cualquier momento? Si se solicita uno, ¿está obligado el equipo a implementarlo de
inmediato? ¿Cómo se evalúan el efecto y el costo del cambio?

Principio 10. Dar seguimiento al plan con frecuencia y hacer los ajustes que se
requieran. Los proyectos de software se atrasan respecto de su programación. Por
tanto, tiene sentido evaluar diariamente el avance, en busca de áreas y situaciones
problemáticas en las que las actividades programadas no se apeguen al avance real.
Cuando se detecten desviaciones, hay que ajustar el plan en
consecuencia[ CITATION Rog \l 3082 ]

3.3.3. Principios de modelado

Se crean modelos para entender mejor la entidad real que se va a construir. Cuando
ésta es física (por ejemplo, un edificio, un avión, una máquina, etc.), se construye un
modelo de forma idéntica pero a escala. Sin embargo, cuando la entidad que se va a
construir es software, el modelo debe adoptar una forma distinta. Debe ser capaz de
representar la información que el software transforma, la arquitectura y las funciones
que permiten que esto ocurra, las características que desean los usuarios y el
comportamiento del sistema mientras la transformación tiene lugar. Los modelos
deben cumplir estos objetivos en diferentes niveles de abstracción, en primer lugar

13
con la ilustración del software desde el punto de vista del cliente y después con su
representación en un nivel más técnico.

Principio 1. El equipo de software tiene como objetivo principal elaborar software, no

crear modelos. Agilidad significa entregar software al cliente de la manera más rápida
posible. Los modelos que contribuyan a esto son benéficos, pero deben evitarse
aquellos que hagan lento el proceso o que den poca perspectiva.

Principio 2. Viajar ligero, no crear más modelos de los necesarios. Todo modelo que
se cree debe actualizarse si ocurren cambios. Más importante aún es que todo
modelo nuevo exige tiempo, que de otra manera se destinaría a la construcción
(codificación y pruebas). Entonces, cree sólo aquellos modelos que hagan más fácil y
rápido construir el software.

Principio 3. Tratar de producir el modelo más sencillo que describa al problema o al

software. No construya software en demasía [Amb02b]. Al mantener sencillos los
modelos, el software resultante también lo será. El resultado es que se tendrá un
software fácil de integrar, de probar y de mantener (para que cambie). Además, los
modelos sencillos son más fáciles de entender y criticar por parte de los miembros
del equipo, lo que da como resultado un formato funcional de retroalimentación que
optimiza el resultado final.

Principio 4. Construir modelos susceptibles al cambio. Suponga que sus modelos

cambiarán, pero vigile que esta suposición no lo haga descuidado. Por ejemplo,
como los requerimientos se modificarán, hay una tendencia a ignorar los modelos.
¿Por qué? Porque se sabe que de todos modos cambiarán. El problema con esta
actitud es que sin un modelo razonablemente completo de los requerimientos, se
creará un diseño (modelo de diseño) que de manera invariable carecerá de funciones
y características importantes.

Principio 5. Ser capaz de enunciar un propósito explícito para cada modelo que se
cree. Cada vez que cree un modelo, pregúntese por qué lo hace. Si no encuentra
una razón sólida para la existencia del modelo, no pierda tiempo en él.

14
Principio 6. Adaptar los modelos que se desarrollan al sistema en cuestión. Tal vez
sea necesario adaptar a la aplicación la notación del modelo o las reglas; por
ejemplo, una aplicación de juego de video quizá requiera una técnica de modelado
distinta que el software incrustado que controla el motor de un automóvil en tiempo
real.

Principio 7. Tratar de construir modelos útiles, pero olvidarse de elaborar modelos

perfectos. Cuando un ingeniero de software construye modelos de requerimientos y
diseño, alcanza un punto de rendimientos decrecientes. Es decir, el esfuerzo
requerido para terminar por completo el modelo y hacerlo internamente consistente
deja de beneficiarse por tener dichas propiedades. ¿Se sugiere que el modelado
debe ser pobre o de baja calidad? La respuesta es “no”. Pero el modelado debe
hacerse con la mirada puesta en las siguientes etapas de la ingeniería de software.
Las iteraciones sin fin para obtener un modelo “perfecto” no cumplen la necesidad de
agilidad.

Principio 8. No ser dogmático respecto de la sintaxis del modelo. Si se tiene éxito

para comunicar contenido, la representación es secundaria. Aunque cada miembro
del equipo de software debe tratar de usar una notación consistente durante el
modelado, la característica más importante del modelo es comunicar información que
permita la realización de la siguiente tarea de ingeniería. Si un modelo tiene éxito en
hacer esto, es perdonable la sintaxis incorrecta.

Principio 9. Si su instinto dice que un modelo no es el correcto a pesar de que se vea

bien en el papel, hay razones para estar preocupado. Si usted es un ingeniero de
software experimentado, confíe en su instinto. El trabajo de software enseña muchas
lecciones, algunas en el nivel del inconsciente. Si algo le dice que un modelo de
diseño está destinado a fracasar (aun cuando esto no pueda demostrarse en forma
explícita), hay razones para dedicar más tiempo a su estudio o a desarrollar otro
distinto

Principio 10. Obtener retroalimentación tan pronto como sea posible. Todo modelo
debe ser revisado por los miembros del equipo. El objetivo de estas revisiones es

15
obtener retroalimentación para utilizarla a fin de corregir los errores de modelado,
cambiar las interpretaciones equivocadas y agregar las características o funciones
omitidas inadvertidamente.

3.3.4. Requerimientos de los principios de modelado

En las últimas tres décadas se han desarrollado numerosos métodos de modelado

de requerimientos. Los investigadores han identificado los problemas del análisis de
requerimientos y sus causas, y han desarrollado varias notaciones de modelado y los
conjuntos heurísticos correspondientes para resolver aquéllos. Cada método de
análisis tiene un punto de vista único. Sin embargo, todos están relacionados por
ciertos principios operacionales:

Principio 1. Debe representarse y entenderse el dominio de información de un

problema. El dominio de información incluye los datos que fluyen hacia el sistema
(usuarios finales, otros sistemas o dispositivos externos), los datos que fluyen fuera
del sistema (por la interfaz de usuario, interfaces de red, reportes, gráficas y otros
medios) y los almacenamientos de datos que recaban y organizan objetos
persistentes de datos (por ejemplo, aquellos que se conservan en forma
permanente).

Principio 2. Deben definirse las funciones que realizará el software. Las funciones del
software dan un beneficio directo a los usuarios finales y también brindan apoyo
interno para las características que son visibles para aquéllos. Algunas funciones
transforman los datos que fluyen hacia el sistema. En otros casos, las funciones
activan algún nivel de control sobre el procesamiento interno del software o sobre los
elementos externos del sistema. Las funciones se describen en muchos y distintos
niveles de abstracción, que van de un enunciado de propósito general a la
descripción detallada de los elementos del procesamiento que deben invocarse.

Principio 3. Debe representarse el comportamiento del software (como consecuencia

de eventos externos). El comportamiento del software de computadora está

16
determinado por su interacción con el ambiente externo. Las entradas que dan los
usuarios finales, el control de los datos efectuado por un sistema externo o la
vigilancia de datos reunidos en una red son el motivo por el que el software se
comporta en una forma específica.

Principio 4. Los modelos que representen información, función y comportamiento

deben dividirse de manera que revelen los detalles en forma estratificada (o
jerárquica). El modelado de los requerimientos es el primer paso para resolver un
problema de ingeniería de software. Eso permite entender mejor el problema y
proporciona una base para la solución (diseño). Los problemas complejos son
difíciles de resolver por completo. Por esta razón, debe usarse la estrategia de divide
y vencerás. Un problema grande y complejo se divide en subproblemas hasta que
cada uno de éstos sea relativamente fácil de entender. Este concepto se llama
partición o separación de entidades, y es una estrategia clave en el modelado de
requerimientos.

Principio 5. El trabajo de análisis debe avanzar de la información esencial hacia la

implementación en detalle. El modelado de requerimientos comienza con la
descripción del problema desde la perspectiva del usuario final. Se describe la
“esencia” del problema sin considerar la forma en la que se implementará la solución.
Por ejemplo, un juego de video requiere que la jugadora “enseñe” a su protagonista
en qué dirección avanzar cuando se mueve hacia un laberinto peligroso. Ésa es la
esencia del problema. La implementación detallada (normalmente descrita como
parte del modelo del diseño) indica cómo se desarrollará la esencia. Para el juego de
video, quizá se use una entrada de voz, o se escriba un comando en un teclado, o tal
vez un joystick (o mouse) apunte en una dirección específica, o quizá se mueva en el
aire un dispositivo sensible al movimiento.

3.3.5. Principios del modelo de diseño

El modelo del diseño del software es análogo a los planos arquitectónicos de una
casa. Se comienza por representar la totalidad de lo que se va a construir (por
ejemplo, un croquis tridimensional de la casa) que se refina poco a poco para que

17
guíe la construcción de cada detalle (por ejemplo, la distribución de la plomería). De
manera similar, el modelo del diseño que se crea para el software da varios puntos
de vista distintos del sistema

Principio 1. El diseño debe poderse rastrear hasta el modelo de requerimientos. El

modelo de requerimientos describe el dominio de información del problema, las
funciones visibles para el usuario, el comportamiento del sistema y un conjunto de
clases de requerimientos que agrupa los objetos del negocio con los métodos que les
dan servicio. El modelo de diseño traduce esta información en una arquitectura, un
conjunto de subsistemas que implementan las funciones principales y un conjunto de
componentes que son la realización de las clases de requerimientos. Los elementos
del modelo de diseño deben poder rastrearse en el modelo de requerimientos.

Principio 2. Siempre tomar en cuenta la arquitectura del sistema que se va a

construir. La arquitectura del software (véase el capítulo 9) es el esqueleto del
sistema que se va a construir. Afecta interfaces, estructuras de datos, flujo de control
y comportamiento del programa, así como la manera en la que se realizarán las
pruebas, la susceptibilidad del sistema resultante a recibir mantenimiento y mucho
más. Por todas estas razones, el diseño debe comenzar con consideraciones de la
arquitectura. Sólo después de establecida ésta debe considerarse los aspectos en el
nivel de los componentes.

Principio 3. El diseño de los datos es tan importante como el de las funciones de

procesamiento. El diseño de los datos es un elemento esencial del diseño de la
arquitectura. La forma en la que los objetos de datos se elaboran dentro del diseño
no puede dejarse al azar. Un diseño de datos bien estructurado ayuda a simplificar el
flujo del programa, hace más fácil el diseño e implementación de componentes de
software y más eficiente el procesamiento conjunto.

Principio 4. Las interfaces (tanto internas como externas) deben diseñarse con
cuidado. La manera en la que los datos fluyen entre los componentes de un sistema
tiene mucho que ver con la eficiencia del procesamiento, la propagación del error y la

18
simplicidad del diseño. Una interfaz bien diseñada hace que la integración sea más
fácil y ayuda a quien la somete a prueba a validar las funciones componentes.

Principio 5. El diseño de la interfaz de usuario debe ajustarse a las necesidades del

usuario final. Sin embargo, en todo caso debe resaltar la facilidad de uso. La interfaz
de usuario es la manifestación visible del software. No importa cuán sofisticadas
sean sus funciones internas, ni lo incluyentes que sean sus estructuras de datos, ni
lo bien diseñada que esté su arquitectura, un mal diseño de la interfaz con frecuencia
conduce a la percepción de que el software es “malo”.

Principio 6. El diseño en el nivel de componentes debe tener independencia

funcional. La independencia funcional es una medida de la “mentalidad única” de un
componente de software. La funcionalidad que entrega un componente debe ser
cohesiva, es decir, debe centrarse en una y sólo una función o subfunción.

Principio 7. Los componentes deben estar acoplados con holgura entre sí y con el
ambiente externo. El acoplamiento se logra de muchos modos: con una interfaz de
componente, con mensajería, por medio de datos globales, etc. A medida que se
incrementa el nivel de acoplamiento, también aumenta la probabilidad de
propagación del error y disminuye la facilidad general de dar mantenimiento al
software. Entonces, el acoplamiento de componentes debe mantenerse tan bajo
como sea razonable.

Principio 8. Las representaciones del diseño (modelos) deben entenderse con

facilidad. El propósito del diseño es comunicar información a los profesionales que
generarán el código, a los que probarán el software y a otros que le darán
mantenimiento en el futuro. Si el diseño es difícil de entender, no servirá como medio
de comunicación eficaz.

Principio 9. El diseño debe desarrollarse en forma iterativa. El diseñador debe buscar

más sencillez en cada iteración. Igual que ocurre con casi todas las actividades
creativas, el diseño ocurre de manera iterativa. Las primeras iteraciones sirven para

19
mejorar el diseño y corregir errores, pero las posteriores deben buscar un diseño tan
sencillo como sea posible.

3.4. Principios de construcción

La actividad de construcción incluye un conjunto de tareas de codificación y pruebas

que lleva a un software operativo listo para entregarse al cliente o usuario final. En el
trabajo de ingeniería de software moderna, la codificación puede ser 1) la creación
directa de lenguaje de programación en código fuente (por ejemplo, Java), 2) la
generación automática de código fuente que usa una representación intermedia
parecida al diseño del componente que se va a construir o 3) la generación
automática de código ejecutable que utiliza un “lenguaje de programación de cuarta
generación” (por ejemplo, Visual C++).[ CITATION Rog \l 3082 ]

3.4.1. Principios de codificación

Los principios que guían el trabajo de codificación se relacionan de cerca con el

estilo, lenguajes y métodos de programación. Sin embargo, puede enunciarse cierto
número de principios fundamentales:

3.4.1.1. Principios de preparación.

• Entender el problema que se trata de resolver.

• Comprender los principios y conceptos básicos del diseño.

• Elegir un lenguaje de programación que satisfaga las necesidades del software que
se va a elaborar y el ambiente en el que operará.

• Seleccionar un ambiente de programación que disponga de herramientas que

hagan más fácil su trabajo.

• Crear un conjunto de pruebas unitarias que se aplicarán una vez que se haya
terminado el componente a codificar.

20
3.4.1.2. Principios de programación

• Restringir sus algoritmos por medio del uso de programación estructurada [Boh00].

• Tomar en consideración el uso de programación por parejas.

• Seleccionar estructuras de datos que satisfagan las necesidades del diseño.

• Entender la arquitectura del software y crear interfaces que son congruentes con
ella.

• Mantener la lógica condicional tan sencilla como sea posible.

• Crear lazos anidados en forma tal que se puedan probar con facilidad.

• Seleccionar nombres significativos para las variables y seguir otros estándares

locales de codificación.

• Escribir código que se documente a sí mismo.

• Crear una imagen visual (por ejemplo, líneas con sangría y en blanco) que ayude a
entender.

3.4.1.3. Principios de validación

• Realizar el recorrido del código cuando sea apropiado.

• Llevar a cabo pruebas unitarias y corregir los errores que se detecten.

• Rediseñar el código

3.4.1.4. Principios de la prueba

• La prueba es el proceso que ejecuta un programa con objeto de encontrar un error.

• Un buen caso de prueba es el que tiene alta probabilidad de encontrar un error que
no se ha detectado hasta el momento.

• Una prueba exitosa es la que descubre un error no detectado hasta el momento.

21
3.4.1.5. Principios de despliegue

Principio 1. Deben manejarse las expectativas de los clientes. Con demasiada

frecuencia, el cliente espera más de lo que el equipo ha prometido entregar, y la
desilusión llega de inmediato.

Principio 2. Debe ensamblarse y probarse el paquete completo que se entregará.

Debe ensamblarse en un CD-ROM u otro medio (incluso descargas desde web) todo
el software ejecutable, archivos de datos de apoyo, documentos de ayuda y otra
información relevante, para después hacer una prueba beta exhaustiva con usuarios
reales. Todos los scripts de instalación y otras características de operación deben
ejecutarse por completo en tantas configuraciones diferentes de cómputo como sea
posible (por ejemplo, hardware, sistemas operativos, equipos periféricos,
configuraciones de red, etcétera).

Principio 3. Antes de entregar el software, debe establecerse un régimen de apoyo.

Un usuario final espera respuesta e información exacta cuando surja una pregunta o
problema. Si el apoyo es ad hoc, o, peor aún, no existe, el cliente quedará
insatisfecho de inmediato. El apoyo debe planearse, los materiales respectivos
deben prepararse y los mecanismos apropiados de registro deben establecerse a fin
de que el equipo de software realice una evaluación categórica de las clases de
apoyo solicitado.

Principio 4. Se deben proporcionar a los usuarios finales materiales de aprendizaje

apropiados. El equipo de software entrega algo más que el software en sí. Deben
desarrollarse materiales de capacitación apropiados (si se requirieran); es necesario
proveer lineamientos para solución de problemas y, cuando sea necesario, debe
publicarse “lo que es diferente en este incremento de software”

22
Principio 5. El software defectuoso debe corregirse primero y después entregarse.
Cuando el tiempo apremia, algunas organizaciones de software entregan
incrementos de baja calidad con la advertencia de que los errores “se corregirán en
la siguiente entrega”. Esto es un error. Hay un adagio en el negocio del software que
dice así: “Los clientes olvidarán pronto que entregaste un producto de alta calidad,
pero nunca olvidarán los problemas que les causó un producto de mala calidad. El
software se los recuerda cada día.”[ CITATION Rog \l 3082 ]

3.5. Qué es calidad

En un nivel algo pragmático, David Garvin [Gar84], de Harvard Business School,

sugiere que “la calidad es un concepto complejo y de facetas múltiples” que puede
describirse desde cinco diferentes puntos de vista. El punto de vista trascendental
dice (como Persig) que la calidad es algo que se reconoce de inmediato, pero que no
es posible definir explícitamente. El punto de vista del usuario concibe la calidad en
términos de las metas específicas del usuario final. Si un producto las satisface, tiene
calidad. El punto de vista del fabricante la define en términos de las especificaciones
originales del producto. Si éste las cumple, tiene calidad. El punto de vista del
producto sugiere que la calidad tiene que ver con las características inherentes
(funciones y características) de un producto. Por último, el punto de vista basado en
el valor la mide de acuerdo con lo que un cliente está dispuesto a pagar por un
producto. En realidad, la calidad incluye todo esto y más.[ CITATION Rog \l 3082 ]

3.5.1. Calidad del software

Proceso eficaz de software que se aplica de manera que crea un producto útil que
proporciona valor medible a quienes lo producen y a quienes lo utilizan[ CITATION
Rog \l 3082 ]

3.5.2. El dilema de la calidad del software

Si produce un sistema de software de mala calidad, usted pierde porque nadie lo

querrá comprar. Por otro lado, si dedica un tiempo infinito, demasiado esfuerzo y
enormes sumas de dinero para obtener un elemento perfecto de software, entonces

23
tomará tanto tiempo terminarlo y será tan caro de producir que de todos modos
quedará fuera del negocio. En cualquier caso, habrá perdido la ventana de mercado,
o simplemente habrá agotado sus recursos. De modo que las personas de la
industria tratan de situarse en ese punto medio mágico donde el producto es
suficientemente bueno para no ser rechazado de inmediato, no en la evaluación,
pero tampoco es un objeto perfeccionista ni con demasiado trabajo que lo convierta
en algo que requiera demasiado tiempo o dinero para ser terminado[ CITATION
Mey \l 3082 ]

3.5.2.1. Software “suficientemente bueno”

El software suficientemente bueno contiene las funciones y características de alta

calidad que desean los usuarios, pero al mismo tiempo tiene otras más oscuras y
especializadas que contienen errores conocidos. El vendedor de software espera que
la gran mayoría de usuarios finales perdone los errores gracias a que estén muy
contentos con la funcionalidad de la aplicación[ CITATION Rog \l 3082 ]

3.5.2.2. El costo de la calidad

El costo de la calidad incluye todos los costos en los que se incurre al buscar la
calidad o al realizar actividades relacionadas con ella y los costos posteriores de la
falta de calidad. Para entender estos costos, una organización debe contar con
unidades de medición que provean el fundamento del costo actual de la calidad, que
identifiquen las oportunidades para reducir dichos costos y que den una base
normalizada de comparación. El costo de la calidad puede dividirse en los costos que
están asociados con la prevención, la evaluación y la falla.[ CITATION Rog \l 3082 ]

3.5.2.3. Riegos

La implicación es que el software de mala calidad aumenta los riesgos tanto para el
desarrollador como para el usuario final. En la subsección anterior se analizó uno de
dichos riesgos (el costo). Pero lo perjudicial de las aplicaciones mal diseñadas e
implementadas no siempre se mide en dólares y tiempo[ CITATION Rog \l 3082 ]

3.5.3. Lograr la calidad del software

24
La calidad del software no sólo se ve. Es el resultado de la buena administración del
proyecto y de una correcta práctica de la ingeniería de software. La administración y
práctica se aplican en el contexto de cuatro actividades principales que ayudan al
equipo de software a lograr una alta calidad en éste: métodos de la ingeniería de
software, técnicas de administración de proyectos, acciones de control de calidad y
aseguramiento de la calidad del software.[ CITATION Rog \l 3082 ]

3.5.3.1. Métodos de la Ingeniería de Software

Si espera construir software de alta calidad, debe entender el problema que se quiere
resolver. También debe ser capaz de crear un diseño que esté de acuerdo con el
problema y que al mismo tiempo tenga características que lleven al software a las
dimensiones y factores de calidad[ CITATION Rog \l 3082 ]

3.5.3.2. Técnicas de administración de proyectos

Las implicaciones son claras: si 1) un gerente de proyecto usa estimaciones para

verificar que las fechas pueden cumplirse, 2) se comprenden las dependencias de
las actividades programadas y el equipo resiste la tentación de usar atajos, 3) la
planeación del riesgo se lleva a cabo de manera que los problemas no alienten el
caos, entonces la calidad del software se verá influida de manera positiva[ CITATION
Rog \l 3082 ]

3.5.3.3. Control de calidad

El control de calidad incluye un conjunto de acciones de ingeniería de software que

ayudan a asegurar que todo producto del trabajo cumpla sus metas de calidad. Los
modelos se revisan para garantizar que están completos y que son
consistentes[ CITATION Rog \l 3082 ]

3.5.3.4. Aseguramiento de la calidad

El aseguramiento de la calidad establece la infraestructura de apoyo a los métodos

sólidos de la ingeniería de software, la administración racional de proyectos y las
acciones de control de calidad, todo de importancia crucial si se trata de elaborar

25
software de alta calidad. Además, el aseguramiento de la calidad consiste en un
conjunto de funciones de auditoría y reportes para evaluar la eficacia y completitud
de las acciones de control de calidad.[ CITATION Rog \l 3082 ]

3.6. Elementos de aseguramiento de la calidad de software

 Estándares
 Revisión y auditoría
 Pruebas
 Colección y análisis de errores
 Administración del cambio
 Educación
 Administración de la seguridad
 Seguridad
 Administración de riesgos

3.6.1. Seguridad del Software

La seguridad del software se relaciona por completo con la calidad. Debe pensarse
en seguridad, confiabilidad, disponibilidad y dependencia, en la fase inicial, en la de
diseño, en la de arquitectura, pruebas y codificación, durante todo el ciclo de vida del
software [proceso]. Incluso las personas conscientes del problema de la seguridad
del software se centran en las etapas finales del ciclo de vida. Entre más pronto se
detecte un problema en el software, mejor. Y hay dos clases de problemas. Uno son
los errores, que son problemas de implementación. El otro son las fallas del software:
problemas de arquitectura en el diseño. La gente presta demasiada atención a los
errores pero no la suficiente a las fallas.[ CITATION Gar \l 3082 ]

3.7. Administración del Proyecto

La administración del proyecto involucra planificación, monitoreo y control del

personal, procesos y acciones que ocurren conforme el software evoluciona desde

26
un concepto preliminar hasta su despliegue operativo completo.[ CITATION Rog \l
3082 ]

3.7.1. El espectro Administrativo

La administración efectiva de un proyecto de software se enfoca en las cuatro P:

personal, producto, proceso y proyecto. El orden no es arbitrario. El gerente que
olvida que el trabajo de la ingeniería del software es una empresa intensamente
humana nunca triunfará en la administración del proyecto. Un gerente que fracase en
alentar una comunicación comprensiva con los participantes durante las primeras
etapas de la evolución de un producto se arriesga a construir una solución elegante
para el problema equivocado.[ CITATION Rog \l 3082 ]

3.7.1.1. Definición de: El Personal

El People-CMM define las siguientes áreas prácticas clave para el personal de

software: plantilla, comunicación y coordinación, ambiente de trabajo, desempeño
administrativo, capacitación, compensación, análisis y desarrollo de competencias,
desarrollo profesional, desarrollo de grupo de trabajo y desarrollo de equipo/cultura,
entre otros. Las organizaciones que conforme a este modelo logran altos niveles de
madurez de capacidades de personal tienen una probabilidad muy elevada de
alcanzar la implementación de prácticas administrativas efectivas en los proyectos de
software.[ CITATION Mod \l 3082 ]

3.7.1.1.1. Participantes

El proceso de software (y todo proyecto de software) está poblado de participantes,

quienes pueden organizarse en alguna de las siguientes áreas:

1. Gerentes ejecutivos, quienes definen los temas empresariales que con frecuencia
tienen una influencia significativa sobre el proyecto.

27
2. Gerentes de proyecto (técnicos), quienes deben planificar, motivar, organizar y
controlar a los profesionales que hacen el trabajo de software.

3. Profesionales que aportan las habilidades técnicas que se necesitan para someter
a ingeniería un producto o aplicación.

4. Clientes que especifican los requerimientos para el software que se va a fabricar,

así como otros participantes que tienen un interés periférico en el resultado.

5. Usuarios finales, quienes interactúan con el software una vez que se libera para su
uso productivo.

3.7.1.1.2. Líderes de Equipo

La administración del proyecto es una actividad que implica mucho trato con la gente;
por esta razón, los profesionales competentes tienen con frecuencia pobre
desempeño como líderes de equipo. Simplemente, no tienen la mezcla justa de
habilidades personales. Y aun así, como Edgemon afirma: “Por desgracia, y por muy
frecuente que parezca, los individuos simplemente se topan con el papel de gerente
de proyecto y se convierten en gerentes accidentales de proyecto”[ CITATION Rog \l
3082 ]

3.7.1.1.3. Equipo de Software

Existen casi tantas estructuras organizativas humanas para el desarrollo del software
como organizaciones que lo desarrollan. Para bien o para mal, la estructura
organizativa no puede modificarse fácilmente. La preocupación por las
consecuencias prácticas y por las políticas del cambio organizativo no está dentro del
ámbito de responsabilidad del gerente del proyecto de software. Sin embargo, la
organización de las personas directamente involucradas en un nuevo proyecto de
software está dentro del campo de acción del gerente del proyecto

3.7.1.2. Definición de: El producto

Resultado producido natural o artificialmente, o resultado de un trabajo u operación.

[ CITATION Rev97 \l 3082 ]

28
3.7.1.2.1. Ámbito del software

El ámbito del software describe las funciones y características que se entregan a los
usuarios finales; los datos que son entrada y salida; el “contenido” que se presenta a
los usuarios como consecuencia de usar el software y el desempeño, las
restricciones, las interfaces y la confiabilidad que se ligan al sistema.[ CITATION Rog
\l 3082 ]

3.7.1.2.2. Descomposición del problema

La descomposición del problema, en ocasiones llamada división o elaboración del

problema, es una actividad que se asienta en el centro del análisis de requerimientos
del software. Durante la actividad de determinación del ámbito, no se hacen intentos
por descomponer completamente el problema. En vez de ello, la descomposición se
aplica en dos áreas principales: 1) la funcionalidad y el contenido (información) que
deben entregarse y 2) el proceso que se usará para entregarlo[ CITATION Rog \l
3082 ]

3.7.1.3. Definición de El proceso

Un proceso de software proporciona el marco conceptual desde el cual puede

establecerse un plan completo para el desarrollo de software. Un pequeño número
de actividades de marco conceptual se aplica a todos los proyectos de software, sin
importar su tamaño o complejidad. [ CITATION Rog \l 3082 ]

3.7.1.3.1. Fusión de producto y proceso

La planificación del proyecto comienza con la fusión de producto y proceso. Cada

función que se va a someter a ingeniería por parte del equipo debe pasar a través del
conjunto de actividades de marco conceptual que defina la organización de software.

3.7.1.3.2. Descomposición del proceso

Un equipo de software debe tener un grado significativo de flexibilidad al elegir el

modelo de proceso de software que es mejor para el proyecto y las tareas de la
ingeniería de software que pueblen el modelo de proceso una vez elegido. Un

29
proyecto relativamente pequeño que sea similar a esfuerzos anteriores puede
lograrse mejor al usar el enfoque secuencial lineal.

3.7.1.4. Definición de: El proyecto

Conjunto de actividades necesarias para obtener un producto. [CITATION Pro \l 3082

]

3.8. Calendarización del Proyecto

Es una actividad que distribuye estimaciones de esfuerzo a través de la duración

planificada del proyecto, al asignar el esfuerzo a tareas específicas de ingeniería del
software. Es la culminación de una actividad de planificación que es un componente
principal de la gestión del proyecto de software[ CITATION Jos \l 3082 ]

3.9. Métricas del Producto

Las métricas de producto ayudan a los ingenieros de software a obtener

comprensión acerca del diseño y la construcción del software que elaboran, al
enfocarse en atributos mensurables específicos de los productos de trabajo de la
ingeniería del software.[ CITATION Rog \l 3082 ]

3.9.1. Medidas, métricas e indicadores

Aunque los términos medida, medición y métrica con frecuencia se usan de modo
intercambiable, es importante observar las sutiles diferencias entre ellos. En el
contexto de la ingeniería del software, una medida proporciona un indicio cuantitativo
de la extensión, cantidad, dimensión, capacidad o tamaño de algún atributo de un
producto o proceso. La medición es el acto de determinar una medida. Una medida
cuantitativa del grado en el que un sistema, componente o proceso posee un atributo
determinado. [ CITATION IEE \l 3082 ]

3.9.2. Principios de medición

30
Formulación. La derivación de medidas y métricas de software apropiadas para la
representación del software que se está construyendo.

Recolección. Mecanismo que se usa para acumular datos requeridos para derivar las
métricas formuladas.

Análisis. El cálculo de métricas y la aplicación de herramientas matemáticas.

Interpretación. Evaluación de las métricas resultantes para comprender la calidad de

la representación.

Retroalimentación. Recomendaciones derivadas de la interpretación de las métricas

del producto, transmitidas al equipo de software.

3.9.3. Métricas para el Modelo de Requerimientos

El trabajo técnico en la ingeniería del software comienza con la creación del modelo
de requerimientos. En esta etapa se derivan los requerimientos y se establece un
cimiento para el diseño. Por tanto, son deseables métricas de producto que
proporcionen comprensión acerca de la calidad del modelo de análisis.[ CITATION
Rog \l 3082 ]

3.9.3.1. Métricas basadas en funciones

La métrica de punto de función (PF) puede usarse de manera efectiva como medio
para medir la funcionalidad que entra a un sistema.4 Al usar datos históricos, la
métrica PF puede entonces usarse para: 1) estimar el costo o esfuerzo requerido
para diseñar, codificar y probar el software;

3.9.3.2. Métricas para calidad de la especificación

Davis et al. [Dav93] proponen una lista de características que pueden usarse para
valorar la calidad del modelo de requerimientos y la correspondiente especificación
de requerimientos: especificidad (falta de ambigüedad), completitud, corrección,
comprensibilidad, verificabilidad, consistencia interna y externa, factibilidad,
concisión, rastreabilidad, modificabilidad, precisión y reusabilidad. Además, los

31
autores observan que las especificaciones de alta calidad se almacenan
electrónicamente, son ejecutables o al menos interpretables, se anotan mediante
importancia relativa, son estables, tienen versión, se organizan, cuentan con
referencia cruzada y se especifican en el nivel correcto de detalle.

3.9.4. Métricas para el Modelo de Diseño

Las métricas de diseño para software de computadora, al igual que todas las demás
métricas de software, no son perfectas. El debate continúa acerca de su eficacia y
sobre la forma en la que deben aplicarse. Muchos expertos argumentan que se
requiere más experimentación antes de poder usar las medidas de diseño, aunque el
diseño sin medición es una alternativa inaceptable. En las siguientes secciones se
examinan algunas de las métricas de diseño más comunes para software de
computadora. Cada una puede proporcionarle comprensión mejorada y todas
pueden ayudar a que el diseño evolucione hacia un mayor nivel de calidad.
[ CITATION Rog \l 3082 ]

3.9.5. Métricas para diseño orientado a objetos

Hay mucho de subjetivo en el diseño orientado a objetos: un diseñador

experimentado “sabe” cómo caracterizar un sistema OO de modo que implemente de
manera efectiva los requerimientos del cliente. Pero, conforme un modelo de diseño
OO crece en tamaño y complejidad, una visión más objetiva de las características del
diseño puede beneficiar tanto al diseñador experimentado (quien adquiere
comprensión adicional) como al novato (quien obtiene un indicio de la calidad que de
otro modo no tendría disponible).[ CITATION Rog \l 3082 ]

Tamaño. El tamaño se define en función de cuatro visiones: población, volumen,

longitud y funcionalidad.

Complejidad. Como el tamaño, existen muchas visiones diferentes de la complejidad

del software [Zus97]. Whitmire ve la complejidad en términos de características
estructurales al examinar cómo se relacionan mutuamente las clases de un diseño
OO

32
Acoplamiento. Las conexiones físicas entre elementos del diseño OO (por ejemplo, el
número de colaboraciones entre clases o el de mensajes que pasan entre los
objetos) representan el acoplamiento dentro de un sistema OO.

Suficiencia. Whitmire define suficiencia como “el grado en el que una abstracción
posee las características requeridas de él o en el que un componente de diseño
posee características en su abstracción, desde el punto de vista de la aplicación
actual”.

Completitud. La única diferencia entre completitud y suficiencia es “el conjunto de

características contra las cuales se compara la abstracción o el componente de
diseño” [Whi97]. La suficiencia compara la abstracción desde el punto de vista de la
aplicación actual.

Cohesión. Como su contraparte en software convencional, un componente OO debe

diseñarse de manera que tenga todas las operaciones funcionando en conjunto para
lograr un solo propósito bien definido.

Primitivismo. Una característica que es similar a la simplicidad, el primitivismo

(aplicado tanto a operaciones como a clases), es el grado en el que una operación es
atómica, es decir, la operación no puede construirse a partir de una secuencia de
otras operaciones contenidas dentro de una clase.

Similitud. El grado en el que dos o más clases son similares en términos de su

estructura, función, comportamiento o propósito se indica mediante esta medida

Volatilidad. Como se menciona muchas veces en este libro, los cambios en el diseño
pueden ocurrir cuando se modifican los requerimientos o cuando ocurren
modificaciones en otras partes de una aplicación, lo que da como resultado la
adaptación obligatoria del componente de diseño en cuestión. La volatilidad de un
componente de diseño OO mide la probabilidad de que ocurrirá un cambio.

3.9.6. Métricas para Pruebas

33
Las métricas de prueba se ubican en dos amplias categorías: 1) métricas que
intentan predecir el número probable de pruebas requeridas en varios niveles de
prueba y 2) métricas que se enfocan en la cobertura de pruebas para un componente
determinad

3.9.6.1. Métricas para pruebas Orientados a Objetos

Las métricas del diseño OO anotadas en la sección 23.3 proporcionan un indicio de

la calidad del diseño. También ofrecen un indicio general de la cantidad de esfuerzo
de prueba requerido para ejercitar un sistema OO. Binder [Bin94b] sugiere un amplio
arreglo de métricas de diseño que tienen influencia directa sobre la
“comprobabilidad” de un sistema OO. Las métricas consideran aspectos de
encapsulación y herencia

Falta de cohesión en métodos (FCOM).15 Mientras más alto sea el valor de la

FCOM, más estados deben ponerse a prueba para garantizar que los métodos no
generan efectos colaterales.

Porcentaje público y protegido (PPP). Los atributos públicos se heredan de otras

clases y, por tanto, son visibles para dichas clases. Los atributos protegidos son
accesibles a los métodos en las subclases. Esta métrica indica el porcentaje de los
atributos de clase que son públicos o protegidos. Valores altos de PPP aumentan la
probabilidad de efectos colaterales entre las clases porque los atributos públicos y
protegidos conducen a alto potencial para acoplamiento.16 Las pruebas deben
diseñarse para garantizar el descubrimiento de tales efectos colaterales

Acceso público a miembros de datos (APD). Esta métrica indica el número de clases
(o métodos) que pueden acceder a otros atributos de clase, una violación de la
encapsulación. Valores altos de APD conducen al potencial de efectos colaterales
entre clases. Las pruebas deben diseñarse para garantizar el descubrimiento de
tales efectos colaterales

34
Número de clases raíz (NCR). Esta métrica es un conteo de las distintas jerarquías
de clase que se describen en el modelo de diseño. Deben desarrollarse las suites de
prueba para cada clase raíz y la correspondiente jerarquía de clase. Conforme el
NCR aumenta, también aumenta el esfuerzo de prueba.

Fan-in (FIN). Cuando se usa en el contexto OO, el fan-in (abanico de entrada) en la

jerarquía de herencia es un indicio de herencia múltiple. FIN > 1 indica que una clase
hereda sus atributos y operaciones de más de una clase raíz. FIN > 1 debe evitarse
cuando sea posible.

3.9.6.2. Métricas para Mantenimiento

IEEE Std. 982.1-1988 [IEE93] sugiere un índice de madurez de software (IMS) que
proporcione un indicio de la estabilidad de un producto de software (con base en
cambios que ocurran para cada liberación del producto).

3.9.7. Definición de: Métricas para Calidad del Software

Las métricas para calidad de software tienen la intención de obtener una medida
cuantificable para la demostrar la calidad de un producto software.

3.9.7.1. Medición de la calidad

Aunque existen muchas medidas de calidad del software, la exactitud, capacidad de

mantenimiento, integridad y usabilidad proporcionan útiles indicadores para el equipo
del proyecto. Gilb [Gil88] sugiere definiciones y medidas para cada una.

Exactitud. Un programa debe operar correctamente o proporcionará poco valor a sus

usuarios. La exactitud es el grado en el cual el software realiza la función requerida.
La medida más común de la exactitud son los defectos por KLOC, donde un defecto
se define como una falta verificada de acuerdo con los requerimientos.

Capacidad de mantenimiento. El mantenimiento y soporte del software representan

más esfuerzo que cualquiera otra actividad de ingeniería del software. La capacidad
de mantenimiento es la facilidad con la que un programa puede corregirse si se

35
encuentra un error, la facilidad con que se adapta si su entorno cambia o de mejorar
si el cliente quiere un cambio en requerimientos.

Integridad. La integridad del software se ha vuelto cada vez más importante en la era
de los ciberterroristas y hackers. Este atributo mide la habilidad de un sistema para
resistir ataques (tanto accidentales como intencionales) a su seguridad. Los ataques
pueden hacerse en los tres componentes de software: programas, datos y
documentación.

Usabilidad. Si un programa no es fácil de usar, con frecuencia está condenado al

fracaso, incluso si las funciones que realiza son valiosas. La usabilidad es un intento
por cuantificar la facilidad de uso y puede medirse en términos de las características

3.9.7.2. Eficiencia en la remoción del defecto

Una métrica de calidad que proporciona beneficio tanto en el nivel del proyecto como
en el del proceso es la eficiencia de remoción del defecto (ERD). En esencia, la ERD
es una medida de la habilidad de filtrado de las acciones de aseguramiento y control
de la calidad según se aplican a lo largo de todas las actividades del marco
conceptual del proceso.

3.9.7.3. Establecimiento de un programa de métricas de software

El Software Engineering Institute (SEI) desarrolló un manual muy completo [Par96b]

para establecer un programa de métrica de software “dirigido hacia la meta”. El
manual sugiere los siguientes pasos:

1. Identificar las metas empresariales.

2. Identificar lo que se quiere conocer o aprender.

3. Identificar la submetas.

4. Identificar las entidades y atributos relacionados con la submetas.

5. Formalizar las metas de medición.

36
6. Identificar preguntas cuantificables y los indicadores relacionados que se usarán
para ayudar a lograr las metas de medición.

7. Identificar los elementos de datos que se recopilarán para construir los indicadores
que ayuden a responder las preguntas.

8. Definir las medidas que se van a usar y hacer operativas estas definiciones.

9. Identificar las acciones que se tomarán para implementar las medidas.

10. Preparar un plan para la implantación de las medidas.

3.9.8. Administración del Riesgo

El análisis y la administración del riesgo son acciones que ayudan al equipo de

software a entender y manejar la incertidumbre. Muchos problemas pueden destruir
un proyecto de software. Un riesgo es un problema potencial: puede ocurrir, puede
no ocurrir. Pero, sin importar el resultado, realmente es una buena idea identificarlo,
valorar su probabilidad de ocurrencia, estimar su impacto y establecer un plan de
contingencia para el caso de que el problema realmente ocurra.

3.9.8.1. Identificación de Riesgos

La identificación de riesgos es un intento sistemático por especificar amenazas al

plan del proyecto (estimaciones, calendario, carga de recursos, etc.). Al identificar los
riesgos conocidos y predecibles, el gerente de proyecto da un primer paso para
evitarlos cuando es posible y para controlarlos cuando es necesario.

3.9.8.2. Proyección del Riesgo

La proyección del riesgo, también llamada estimación del riesgo, intenta calificar
cada riesgo en dos formas: 1) la posibilidad o probabilidad de que el riesgo sea real y
2) las consecuencias de los problemas asociados con el riesgo, en caso de que
ocurra. Usted trabaja junto con otros gerentes y personal técnico para realizar cuatro
pasos de proyección de riesgo:

1. Establecer una escala que refleje la probabilidad percibida de un riesgo.

37
2. Delinear las consecuencias del riesgo.

3. Estimar el impacto del riesgo sobre el proyecto y el producto.

4. Valorar la precisión global de la proyección del riesgo de modo que no habrá

malos entendidos.

3.9.8.3. Valoración de impacto de riesgo

Tres factores afectan las probables consecuencias si ocurre un riesgo: su naturaleza,

su ámbito y su temporización. La naturaleza del riesgo indica los problemas
probables si ocurre. Por ejemplo, una interfaz externa pobremente definida en el
hardware cliente (un riesgo técnico) impedirá el diseño y las pruebas tempranas, y
probablemente conducirá más tarde a problemas de integración de sistema en un
proyecto. El ámbito de un riesgo combina la severidad (¿cuán serio es?) con su
distribución global (¿cuánto del proyecto se afectará o cuántos participantes se
dañarán?). Finalmente, la temporización de un riesgo considera cuándo y por cuánto
tiempo se sentirá el impacto. En la mayoría de los casos se quiere que las “malas
noticias” ocurran tan pronto como sea posible, pero en algunos, mientras más se
demoren, mejor.

3.9.8.4. El plan MMMR

En el plan de proyecto del software puede incluirse una estrategia de administración

del riesgo, o los pasos de administración del riesgo pueden organizarse en un plan
de mitigación, monitoreo y manejo de riesgo (MMMR) por separado. El plan MMMR
documenta todo el trabajo realizado como parte del análisis de riesgos y el gerente
del proyecto lo usa como parte del plan de proyecto global

4. MARCO TEORICO DE LA METODOLOGIA

4.1. PUDS

El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un

marco de desarrollo de software que se caracteriza por estar dirigido por casos de
uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más

38
conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational
o simplemente RUP.

4.1.1. Características

4.1.1.1. Iterativo e Incremental

El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de

cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una
de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede
incluir varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como
resultado un incremento del producto desarrollado que añade o mejora las
funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que
recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de
requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen
incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una
de ellas varía a lo largo del proyecto.

Diagrama ilustrando como el énfasis relativo en las distintas disciplinas cambia a lo

largo del proyecto.

4.1.1.2. Dirigido por los casos de uso

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos
funcionales y para definir los contenidos de las iteraciones. La idea es que cada
iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino
a través de las distintas disciplinas: diseño, implementación, prueba, etc. El proceso
dirigido por casos de uso es el rup. Nota: en UP se está Dirigido por requisitos y
riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema.

4.1.1.3. Centrado en la arquitectura

El Proceso Unificado asume que no existe un modelo único que cubra todos los
aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que

39
definen la arquitectura de software de un sistema. La analogía con la construcción es
clara, cuando construyes un edificio existen diversos planos que incluyen los distintos
servicios del mismo: electricidad, fontanería, etc.

4.1.1.4. Enfocado en los riesgos

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los
riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada
iteración, en especial los de la fase de Elaboración deben ser seleccionados en un
orden que asegure que los riesgos principales son considerados primero.

4.2. UML

El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual que

se usa para especificar, visualizar, construir y documentar artefactos de un
sistema de software.

4.2.1. Definición de Unificado

Se puede utilizar un conjunto de conceptos en un mismo modelo

Combina los conceptos comúnmente aceptados por muchos métodos orientados

a objetos. Puede representar la mayoría de los modelos existentes. Está pensado
para modelar la mayoría de los dominios de aplicación, incluyendo aquellos
sistemas grandes, complejos, de tiempo real. Puede ser usado en sistemas
desarrollados en diferentes lenguajes de programación, bases de datos,
documentos de organización, firmware y otros. Es unificado porque se
estandarizo varios modelos en uno

4.2.2. Tipos de Dominio

La mayoría de los dominios de aplicación, incluyendo aquellos que implican

sistemas grandes, complejos, de tiempo real, distribuidos, con tratamiento
intensivo de datos o cálculo intensivo, entre otras propiedades

4.2.3. Objetivos UML

40
Pueden usar todos los modeladores

Incorpora buenas prácticas de diseño como encapsulación, separación de temas,

y la captura de la intención del modelo construido

Pretende trabajar correctamente con todos, o al menos con la mayoría de los

proceso de desarrollo existentes.

4.2.4. Modelo

Es una representación, en cierto medio, de algo en el mismo u otro medio. El

modelo capta los aspectos importantes de lo que estamos modelando, desde
cierto punto de vista, y simplificación omite el resto.

Pueden capturas requisitos sobre su dominio de aplicación, la forma en que los

usuarios lo utilizaran, su división en módulos, los patrones comunes usados en su
construcción y otras cosas.

Un modelo de un sistema de software ayuda a los desarrolladores a explorar

varias arquitecturas y soluciones de un diseño fácilmente antes de escribir el
código.

Semántica y presentación: los elementos semánticos del modelo llevan el

significado del modelo, es decir transportan la semántica. Se utilizan para la
generalización del código, la comprobación de la validez, las métricas de
complejidad. La presentación visual muestra la información semántica de modo
que se pueda ser considerada, hojeada y corregida por los seres humanos.

Contexto: Los modelos son artefactos en un sistema informático, y se utilizan

dentro de un contexto más grande que les dé significado completo. Este contexto
incluye la organización interna del modelo, anotaciones sobre el uso de cada
modelo en el proceso total del desarrollo, un sistema de valores por defecto y de
suposiciones para la creación y la manipulación del elemento, y una relación al
entorno en el cual se utilizan.

41
5. INGENIERIA DE SOFTWARE DEL PROYECTO

5.1. Planificación temporal.

42
5.2. Organización del personal (Estructura del equipo de desarrollo del software)

43
Para este proyecto se determinó que se utilizara la estructura de Equipo Centralizado
Controlado (CC) por los siguientes motivos:

 Hay un único jefe de equipo.

 Este jefe resuelve los problemas a alto nivel, y la coordinación del equipo.
 Comunicación vertical entre el jefe y los miembros del equipo.
 Fue el primer organigrama que se empezó a aplicar.
 Menos tiempo en la solución de problemas por menores líneas de
comunicación.
 Proyecto medianos o pequeños

5.3. Estimación del proyecto (Asumir Productividad = 29,5)

5.3.1. Métricas basadas en Punto de función

ENTRADAS DE USUARIO
# Detalle
1 Interfaz de registro de productos
2 Interfaz de registro de ventas
3 Interfaz de registro de clientes
4 Interfaz de registro de pedidos
5 Interfaz de registro de recepción
6 Interfaz de registro de empleados
7 Interfaz de registro de proveedores

SALIDAS DE USUARIO
# Detalle
1 Interfaz de visualización de productos
2 Interfaz de visualización de ventas
3 Interfaz de visualización de clientes
4 Interfaz de visualización de pedidos
5 Interfaz de visualización de recepción
6 Interfaz de visualización de empleados
7 Interfaz de visualización de proveedores

PETICIONES DE USUARIO
# Detalle
1 Reporte de vendedores

44
2 Reporte de productos
3 Reporte de productos con marcas (Para
marketing)

ARCHIVOS
# Detalle
1 Archivo de texto de Facturación para
impuestos

INTERFACES EXTERNAS
# Detalle
1 Impresión de adhesivas con código de
barras

Factor de ponderación
Parámetro Cuenta Subtotal
Simple Medio Complejo

Número de entradas
 7 2 2 3  21
de usuario

Número de salidas
 7 0 1 8  56
de usuario

Número de
peticiones de   3 0 3 0 9 
usuario

Número de archivos   1 0 0 11

Número de
 1 0 0 1 1 
interfaces externas

Cuenta Total  88

∑ Ct

45
0: No influencia, 1: Incidental, 2: Moderado, 3: Es Medio, 4: Significativo, 5: Esencial

5.3.2. Valores de ajuste de complejidad

1. ¿Requiere el sistema copias de seguridad y de recuperación fiables?  4

2. ¿Requiere comunicación de datos?  4

3. ¿Existen funciones de procesamiento distribuido?  0

4. ¿Es crítico el rendimiento?  5

5. ¿Se ejecutará el sistema en un entorno operativo existente y

fuertemente utilizado?  5

6. ¿Requiere entrada de datos interactiva?  3

7. ¿Requiere la entrada de datos interactiva que las transacciones de

entrada se lleven a cabo sobre múltiples pantallas u operaciones?  3

8. ¿Se actualizan los archivos maestros de forma interactiva?  3

9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones?  4

10. ¿Es complejo el procesamiento interno?  3

11. ¿Se ha diseñado el código para ser reutilizable?  5

12. ¿Están incluidas en el diseño la conversión y la instalación?  0

13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en

diferentes organizaciones?  4

14 ¿Se ha diseñado la aplicación para facilitar los cambios y para ser  3

fácilmente utilizada por el usuario?

∑ Fi 46

5.3.3. Cálculo de punto de función

E=20

46
PF=∑Ct*(0.65+0.01* ∑Fi)

PF = 88 * (0.65 + 0.01 * 46)

PF = 97.68

5.3.4. Cálculo del Esfuerzo

Productividad = 29,5

P = PF/E

E= PF/P

E=97.68/29.5

E=3.31

5.3.5. Cálculo de número de personas que conformarán el equipo de desarrollo del

software.

Duración = Esfuerzo / Personas

Duración = 3.31 / 2

Duración = 1.6 Meses

Se requieren 2 personas para desarrollar el sistema en 1.6 meses.

5.3.6. Costo del personal

Hora Desarrollador: 35bs

Costo = Persona x Hora$ x Horas x Días x mes

Costo = 3 x 35 x 8 x 25 x 1.6

Costo = 33600bs para 2 desarrolladores en 1.6 meses

5.3.7. Costo del Software

Costo = $horas * Puntos de Función

47
Costo = 35 * 97.68

Costo = 3418bs

5.4. Análisis y Gestión de Riesgos

5.4.1. Escala basada en el aspecto del personal

Impact Posible
Riesgo Probabilidad COSTO
o Solución
Daños en el Asegurar
área de los equipos
85 30 300
desarrollo del electrónico
proyecto s
Retiro de un Contratar
integrante del 25 20 personal 500
equipo nuevo
Daños
Asegurar
climatológicos
los equipos
en el área de 80 20 200
electrónico
desarrollo del
s
proyecto

5.4.2. Escala basada en el aspecto tecnológico

Impact Posible
Riesgo Probabilidad COSTO
o Solución
Aumentar horas
Tecnología de trabajo para
300
nueva no 30 50 capacitar sobre
probada la nueva
tecnología
Personal no Capacitar
40 30 500
capacitado personal

5.4.3. Escala basada en el aspecto del negocio

Impact Posible
Riesgo Probabilidad COSTO
o Solución
Los recursos 50 30 Informar a los ------
no están encargados del
disponibles en proyecto que el

48
 tiempo de cierre
su momento se va a ver
afectada
Nuevas
Aumentar las
características 55 50 ------
horas de trabajo
solicitadas
Los equipos
clientes no
Solicitar
cuentan con
25 30 actualización de 200
los requisitos
equipos
que el sistema
necesita
Solicitar mejora
Mayor número
de recursos del
de usuarios de 25 30 --------
servidor de
los previstos
producción

5.5. Gestión de la Calidad

5.5.1. Calidad en función a 5 métricas (Corrección, Confiabilidad, Eficiencia,

Integridad, Facilidad de Mantenimiento)

5.5.2. Normas

1.1.1.1. Norma ISO 25000

Esta proporciona una guía para el uso de las nuevas series de estándares
internacionales, llamados Requisitos y Evaluación de Calidad de Productos de
Software (SQuaRE). Es una norma que se basa en la ISO 9126 y 14598 y su
principal objetivo es determinar una guía para el desarrollo de los productos de
software con la especificación y evaluación de requisitos de calidad. Establece
criterios para la especificación de requisitos de calidad de productos software, sus
métricas y su evaluación. El producto de software debe incorporar unas
características, de tal manera que se garantice su eficiencia de uso a los
requerimientos de los clientes. Se recomienda que los requisitos de calidad deban
ser proporcionales a las necesidades de la aplicación y lo crítico que sea el correcto
funcionamiento del sistema implementado.

La norma se compone por las siguientes divisiones:

49
 SO/IEC 2500n. División de gestión de calidad. Esta división define todos los
modelos comunes, términos y referencias a los que se alude en las demás divisiones
de SQuaRE

ISO/IEC 2501n. División del modelo de calidad. Presenta un modelo de calidad

detallado, incluyendo características para la calidad interna, externa y en uso.

ISO/IEC 2502n. División de mediciones de calidad. Presenta un modelo de

referencia de calidad del producto software, definiciones matemáticas de las métricas
de calidad y una guía práctica para su aplicación. Presenta aplicaciones de métricas
para la calidad de software interna, externa y en uso.

ISO/IEC 2503n. División de requisitos de calidad. Ayuda a especificar los requisitos

de calidad. Estos requisitos pueden ser usados en el proceso de especificación de
requisitos de calidad para un producto software que va a ser desarrollado o como
entrada para un proceso de evaluación. El proceso de definición de requisitos se
guía por el establecido en la norma ISO/IEC 15288 (ISO, 2003).

ISO/IEC 2504n. División de evaluación de la calidad. Proporciona requisitos,

recomendaciones y guías para la evaluación de un producto software, tanto si la
llevan a cabo evaluadores, como clientes o desarrolladores.

ISO/IEC 25050–25099. Estándares de extensión SQuaRE. Incluyen requisitos para

la calidad de productos de software “Off-The-Self” y para el formato común de la
industria (CIF) para informes de usabilidad.

Esta norma define tres vistas diferentes respecto al estudio de la calidad de un

producto software:

Vista interna: se ocupa de las propiedades del software como: el tamaño, la

complejidad o la conformidad con las normas de orientación a objetos. Esta vista
puede utilizarse desde las primeras fases del desarrollo para detectar deficiencia del
software.

50
Vista externa: analiza el comportamiento del software en producción y estudia sus
atributos, por ejemplo: el rendimiento de un software en una máquina determinada, el
uso de memoria de un programa o el tiempo de funcionamiento entre fallos. Esta
vista se utiliza una vez el software este completo y listo para producción.

Vista en uso: mide la productividad y efectividad del usuario final al utilizar el

software. Esta vista se utiliza una vez el software esté listo y será evaluado por el
cliente y dependerá de los factores determinantes del mismo.

5.6. Presupuesto

5.6.1. Costo parcial de las tareas de desarrollo de software.

25200bs para 3 desarrolladores en 2.8 meses.

5.6.2. Costo parcial de la gestión de proyecto.

NOMBRE COSTO
PLANIFICACION 400
CALIDAD 350
RIESGO 2000
TOTAL 0

5.6.3. Costo parcial de recursos

PRECIO TOTAL
DETALLE CANTIDAD UNIDAD
(Bs.) (Bs.)
Computadora de Escritorio
2 Equipo 3500 7000
Intel Core i3
Ingeniería del proyecto 15 Días 150 150
TOTAL 7150

5.6.4. Costo parcial de servicios básicos.

DETALLE PRECIO (bs) UNIDAD TOTAL

51
 Factura de luz
375 MES 750
estimada
Factura de agua
225 MES 450
estimada
Factura de internet
por mes (Plan
278 MES 576
ADSL HIGH
SPEED)
TOTAL 1776

5.6.5. Costo parcial de material extra

DETALLE CANTIDAD UNIDAD PRECIO (Bs.) TOTAL (Bs.)

Papelería y fotocopia 1000 Hojas 150 150
Impresora PIXMA 1700 2 Equipo 500 1000
TOTAL 0

5.6.6. COSTO TOTAL DEL PROYECTO

DETALLE COSTO
Costo parcial de las tareas de desarrollo
33600
de software
Costo parcial de recursos 7150
Costo parcial de la gestión de proyecto 2750
Costo parcial de servicios básicos 1777
Costo parcial de material extra 1150
TOTAL 0

5.7. Plan de comunicación

El éxito de una organización depende de una gran medida de un estilo de

comunicación de manera efectiva entre el interesado y miembros del proyecto.

Se realizara reuniones en las instalaciones de la empresa. Se presentara avances

del proyecto en formato PDF para que el cliente vea la seriedad del equipo de
trabajo.

52
Los medios que nos comunicaremos con el cliente serán por correo electrónico,
teléfono fijo o celular, para programar alguna reunión y mantenerlo al corriente sobre
los avances del proyecto.

6. INGENIERIA DEL PROYECTO

6.1. Modelo de Requisitos

6.1.1. Requerimientos funcionales

Nombre del Como Probarlo

#
requerimiento (Atributos de calidad)
 Inicio de sesión de usuario.
 Mostrar el logo de la empresa y una
pequeña descripción
 Un menú debe tener las siguientes
opciones:
o Inicio
o Productos
RF001 Página de inicio o Clientes
o Marcas
o Compras
o Ventas
o Pedidos
o Recepciones
o Cerrar Sesión

 Permitir registrar, modificar y dar de

baja a un Producto y realizar
RF002 Gestionar Productos búsquedas.
 El código es autogenerado.

 Permitir registrar, modificar y dar de

RF003 Gestionar Clientes baja a un Cliente y realizar búsquedas.
 El código es autogenerado.
 Permitir registrar, modificar y dar de
RF004 Gestionar Marcas baja a una Marca y realizar búsquedas.
 El código es autogenerado.
 Permitir registrar, modificar y dar de
baja a una compra y la búsqueda del
RF005 Gestionar Compras mismo.
 El código es autogenerado del sistema.
 La descripción de la compra es única.

53
  Permitir registrar y dar de baja a una
venta y la búsqueda del mismo.
RF006 Gestionar Ventas
 El código es autogenerado del sistema.
 La descripción de la venta es única.
 Permitir registrar y dar de baja a un
pedido y la búsqueda del mismo.
RF007 Gestionar Pedidos
 El código es autogenerado del sistema.
 La descripción del pedido es única.
 Permitir registrar y dar de baja a una
recepción y la búsqueda del mismo.
Gestionar
RF008  El código es autogenerado del sistema.
Recepciones
 La descripción de la recepción es
única.
 Permitir el ingreso de usuarios al
sistema web, mediante el login
(nombre de usuario) y password.
 La contraseña de usuario: longitud
Autenticación del mínima 8 caracteres, máximo 12, por lo
RF008
usuario en el sistema menos un carácter especial y una letra
minúscula y mayúscula, además de un
numero).
 Los permisos dependerán del rol que
tenga.
 Permite al usuario ver un listado de
Reporte: Stock de
RF009 productos de un rango de fechas de
Productos.
registro
Reporte: Compra y  Permite al usuario saber la ganancia a
RF010
Venta detalle en un rango de fechas

6.1.2. Requisitos no funcionales

También se requiere requisitos mínimos de hardware como ser:

 Procesador Intel(R) Core(TM) i3 CPU @ 1.60GHz.

 Memoria RAM 4 Gb para mejor rendimiento.
 Mínimo 100mb de disco duro para el software, se recomienda más espacio a
medida que crezca los datos de la base de datos.
 Impresora para imprimir reportes del programa.
 Conexión de red Local (Preferiblemente inalámbrica)

54
 Requerimientos de Software

Para el desarrollo de este sistema se requiere distintas herramientas como

ser:

 Editor de Texto Brackets

 XAMP Server
 La aplicación debe desarrollarse en PHP, utilizando el framework LARAVEL
para el backend, y derivados de SQL con T/SQL para el motor de base de
datos MySQL.

Requerimientos de Software
 Durante el registro de cualquier tipo de dato se pedirá al usuario la
confirmación de la acción.
 El sistema mostrara mensajes confirmando una acción o avisando de un error.
 Todos los campos de los formularios deberán ser validados antes de realizar
una acción (Ejemplo: Guardar, Modificar y eliminar) en la base de datos.
 Copia de seguridad automática de la base de datos todas las noches en
horarios de 12:00pm.
 Modificación y actualización de datos a través de formularios.
 Se avisará del error mediante un mensaje y un sonido.
 Un manual de usuario para capacitar al personal.
 La aplicación deberá tener acceso por niveles para los diferentes roles
 Caducidad de contraseña
 Bitácora de las operaciones hechas sobre las tablas de la base de datos.

6.1.3. Descripción de los actores

CODIGO AUTOR DESCRIPCION

ADM Administrador Persona natural con

55
 acceso al sistema en
todos sus módulos
Persona natural con
acceso al sistema en los
INV Personal de Inventario
módulos de recepción y
pedidos
Persona natural con
acceso al sistema en los
MRK Encargada de Marketing módulos de productos,
marcas y reporte de
productos
Persona natural con
acceso al sistema en los
VEN Personal de Ventas
módulos de compra y
venta
Persona natural con
GER Gerencia acceso al sistema a los
módulos de reportes
Persona natural con
acceso al sistema en los
CLI Clientes
módulos de consulta de
productos y marcas

6.2. Modelo de Análisis

6.2.1. Diagrama general de los casos de uso

56
57
 6.2.2. Especificación del caso de uso “Registrar venta”.

RF006 Gestionar Ventas

Actores Vendedor
Descripción Describir la funcionalidad de registrar ventas en el sistema
Precondición El usuario con sesión iniciada tiene el rol de vendedor
Postcondició
La venta se muestra en un listado de ventas realizadas
n
Secuencia
Pas
Acción
o
El vendedor ingresa a la sección ventas en la opción del
1
menú.
El sistema muestra todas las ventas registradas en el
2
sistema
3 El vendedor hace clic en el botón de nueva venta
El sistema muestra los campos necesarios para realizar una
4
venta
El vendedor llena los campos y hace clic en adicionar
5
productos.
El sistema muestra una ventana con una lista y con un
6 buscador de productos para que el usuario seleccione los
Normal
productos que desea vender.
El usuario busca y selecciona los productos que desea
vender haciendo doble clic en la fila del producto y cuando
7
ya selecciono los productos que va a vender, presiona el
botón de adicionar productos a venta.
El sistema cierra la ventana para seleccionar productos y
8 muestra los productos seleccionados en una lista, debajo de
los campos de la venta.
El usuario llena la columna cantidad en la lista de productos
9
y hace clic en el botón de realizar venta
El sistema valida campos, registra la venta, resta productos
10 del inventario, muestra mensaje de éxito, y registra en
bitácora los cambios realizados.
Alternativa Pas
Acción
o
Si no hay ventas registradas en el sistema, se muestra un
2.1 mensaje “No se encontraron registros” en lugar de la lista de
ventas
7.1 Si el usuario selecciona 2 veces un producto, se muestra un
mensaje avisando que el producto ya fue seleccionado

58
 Si el usuario no llena toda la columna cantidad en la lista de
9.1 productos seleccionados, se muestra mensaje de error “se
deben llenar la columna cantidad”
Si faltara un campo requerido, se muestra mensaje de error
10.1 “Se deben completar todos los campos requeridos para
continuar”

6.2.3. Modelo de dominio

6.2.3.1. Diagrama de clases conceptuales

59
6.2.3.2. Modelo de datos relacional

60
6.3. Modelo de Diseño

6.3.1. Diagrama de secuencia

61
 sd Diagrama de secuencia

Vendedor Interfaz de Ventas Control de Ventas Tabla Ventas

Ingresa a interfaz()

llama a metodo para obtener datos()

envia solicitud()

envia datos()

muestra datos()

registra venta()

registrarVenta()

Envia informacion()

Informacion guardada()

Muestra venta Guardada()

Verifica Venta()

Da de baja venta()

Cambia Estado()

Enviar Informacion()

Retorna informacion guardada()

Muestra venta dada de baja()

Verifica Venta()

6.4. Modelo de Implementación

6.4.1. Modelo de Componentes

62
cmp Diagrama de Componentes

Aplicacion Web

App Web
Productos App Web
App Web App Web App Web App Web
Marcas Recepciones Clientes
Ventas Pedidos

Servicio

Serv icios

Serv idor
Web

Software

SISTEMA DE GESTION COMERCIAL PARA VUITON SRL

Base de Datos

BDPersona BD Pedidos

BD
Clientes
BD
BD Empleados
BDProductos BD Venta
DetallePedidos

BD
BD BD BD Prov eedores
DetalleVenta Recepcion DetalleRecepcion

Sistema Operatvio

Sistema
Operativ o

Linux

Conexiones Externas

Serv idor Gestor Conexiones

De BD VUITON externas

6.4.2. Modelo de Despliegue

63
cmp Diagrama de Despliegue

Aplicación Web (Estructura)

Modelo Interfaz
ORM (Obj eto) LAN - WAN
Explorador w eb
(IE10, Firefox,
Controlador Chrome)
(Negocio de Datos)

Directorio v irtual de
la Aplicación
Motor de base de Reporting Agente
datos SQL

Sistema Operativ o Serv idor de Base

Serv idor apache
Linux de datos mysql

7. CONCLUSIONES

 Se lograron determinar los requerimientos del sistema con la finalidad de

sentar las bases para la elaboración de un diseño de acuerdo a las
necesidades y dificultades identificadas.
 Se realizó la construcción del sistema de gestión que resolvió los problemas
analizados y que cumplió con los requerimientos obtenidos en la fase de
análisis y diseño.
 Se efectuó correctamente la implementación del sistema desarrollado
tomando en cuenta que software resultante que cumple con todos los
requisitos planteados y aprobados por los encargados de la empresa VUITON
SRL.

8. RECOMENDACIONES

 Diseñar, modelar y describir cada futura actualización que se realice al

sistema.
 Aplicar seguridad de información para poder tener un grado mayor de
disponibilidad, integridad y confidencialidad de los datos.

64
  Realizar un estudio de las vulnerabilidades del sistema (pentesting) y aplicar
un plan para mitigar o remover dichas vulnerabilidades.

9. BIBLIOGRAFIA

IEEE Standard Glosary of Software Engineering Terminology. (s.f.).

Masias, J. (s.f.). slideshare. Obtenido de slideshare:

https://es.slideshare.net/jose_macias/calendarizacin-de-proyectos-de-
software-10507081

McGraw, G. (s.f.). ComputerWorld. Obtenido de ComputerWorld.

Meyer, B. (s.f.).

Modelo de madurez de capacidades del personal. (s.f.).

Pressman, R. (s.f.). Ingenieria del Software. Un Enfoque Practico.

Project Management Institute. (s.f.). Project Management Institute.

Revelle, J. (1997). The QFD handbook. En J. Revelle.

Wesley, I. S. (s.f.). Ingeniería de software (sexta edición.

65