Ingeniería de Software 1

Ingeniería de software 1
Autor: Fredy Alonso León Socha

Ingeniería de software 1 / Fredy Alonso León Socha, / Bogotá D.C.,
Fundación Universitaria del Área Andina. 2017
978-958-5459-11-3
Catalogación en la fuente Fundación Universitaria del Área Andina (Bogotá).
© 2017. FUNDACIÓN UNIVERSITARIA DEL ÁREA ANDINA

© 2017, PROGRAMA INGENIERIA DE SISTEMAS
© 2017, FREDY ALONSO LEÓN SOCHA
Edición:
Fondo editorial Areandino
Fundación Universitaria del Área Andina
Calle 71 11-14, Bogotá D.C., Colombia
Tel.: (57-1) 7 42 19 64 ext. 1228
E-mail: publicaciones@areandina.edu.co
http://www.areandina.edu.co
Primera edición: noviembre de 2017
Corrección de estilo, diagramación y edición: Dirección Nacional de Operaciones virtuales

Diseño y compilación electrónica: Dirección Nacional de Investigación
Hecho en Colombia
Made in Colombia
Todos los derechos reservados. Queda prohibida la reproducción total o parcial de esta
obra y su tratamiento o transmisión por cualquier medio o método sin autorización escrita
de la Fundación Universitaria del Área Andina y sus autores.
Ingeniería de software 1

i
Índice
UNIDAD 1 Introducción a la Ingeniería de

software
Introducción 7
Metodología 8
Desarrollo temático 9
UNIDAD 1 Introducción a la Ingeniería de

software
Introducción 17
Metodología 18
UNIDAD 2 Introducción a la ingeniería de

requisitos
Introducción 30
Metodología 31
UNIDAD 2 Especificación y validación

Introducción 42
Metodología 43
i
Índice
UNIDAD 3 Diseño orientado a objetos de

sistemas de software
Introducción 54
Metodología 55
UNIDAD 3 Modelado de procesos

Introducción 70
Metodología 71
UNIDAD 4 Conceptos de seguridad

Introducción 89
Metodología 90
UNIDAD 4 Metodologías vigentes

Introducción 100
Metodología 101
Bibliografía 112
1
UNIDAD
1 Unidad 1
Introducción a
la Ingeniería de Ingeniería de software
software
Introducción El presente módulo tiene como objetivo dar a conocer como
ha sido el proceso evolutivo de la información, desde sus co-
mienzos; en el paleolítico; hasta cuando aparecieron las pri-
meras computadoras.
Se inicia con las primeras formas utilizadas para comuni-

cación, como los pictogramas y se continúa con el proceso
evolutivo de la información antes, durante y después de la re-
volución industrial. Finalmente se presentan los eventos más
importantes en la evolución de las telecomunicaciones.
Estas temáticas le ayudaran a saber de dónde han surgido las

tecnologías que conocemos actualmente, pues la mayoría se
basan o han sido una evolución de tecnologías que se han
venido utilizado o se han generado hace mucho tiempo.
Fundación Universitaria
Fundación Universitaria del
del Área
Área Andina
Andina 7
3
U1 Metodología
El módulo se basa en la lectura individual de la presente cartilla y posterior desarrollo de

actividades planteadas en la plataforma online.
Se espera una participación y acceso a plataforma a su consideración, como mejor pueda

organizarse, para cubrir los objetivos de aprendizaje y participación. Por mi experiencia, re-
comiendo la asistencia diaria para aprovechar al máximo el curso. Es interesante seguir los
hilos de participación 2-3 veces al día y dedicar uno momento para analizar y participar
inteligentemente.
La comunicación conmigo la pueden realizar abiertamente a través del Foro y personalmen-

te a través del email.
Fundación
Universitaria del
del Área
Área Andina 8
Andina 4
U1 Desarrollo temático
Introducción a la Ingeniería de dación y administración de tiempos y pre-

supuestos establecidos en un proyecto de
software desarrollo.
Definiciones Analista de negocio
Conjunto de conocimientos y técnicas cien- Se encarga de entender lo que quiere el
tíficas, empíricas y prácticas aplicadas a la cliente y lo transforma en requerimientos.
invención, el diseño, el desarrollo, la cons-
trucción, el mantenimiento y el perfeccio- Arquitecto de software
namiento de tecnologías, estructuras, má-
quinas, herramientas, sistemas, materiales Ve el software a nivel de diseño y transfor-
y procesos para la resolución de problemas ma los requerimientos.
prácticos.
Analista de calidad
Software Verifica que el software entregado por el
desarrollador, funcione bien y cumpla los
Conjunto de programas, instrucciones y re-
requerimientos del cliente.
glas informáticas que permiten que se pue-
dan ejecutar distintos procesos o tareas es- Jefe de proyecto
pecíficas en un computador.
Gestiona el equipo de desarrollo.
Programador/Desarrollador
Evolución del software
Persona encargada de escribir el código
necesario en un lenguaje de programación A continuación se muestra los eventos que
que pueda ser entendido por una computa- han marcado un referente en la evolución
cronológica del software. Este ha estado
dora, usando para ello algoritmos y estruc-
muy ligado al proceso evolutivo del hard-
turas de datos.
ware computacional, pues en la medida que
se generaban componentes más pequeños
Ingeniero de software
y más rápidos, el software necesariamente
Persona utilizan técnicas de ingeniería para debía ajustarse a dichos recursos físicos, a
el diseño, especificación, codificación, vali- fin de obtener el mayor rendimiento.
Fundación
Universitaria del
del Área
Área Andina 9
Andina 5
■ Los procesos de desarrollo de software los realizaban las mismas organizaciones para sus propios
requerimientos. No existía documentación de soporte, no había una planificación y los progra-
1950 madores tenían que trabajar con los pocos métodos que existían.
a
1965
■ Los procesos de desarrollo de software los realizaban las mismas organizaciones para sus propios
requerimientos. No existía documentación de soporte, no había una planificación y los progra-
1965 madores tenían que trabajar con los pocos métodos que existían.
a
1975
■ Se empezaron a realizar procesos de planificación para el desarrollo.

■ La ejecución de funciones permitían la comunicación de información entre múltiples computado-
ras, lo que se le llamo Procesamiento Distribuido.
■ Los requerimientos empezaron a centrarse en acceder a los datos en forma instantánea.
1975 ■ El software empezó a aplicarse en “sistemas inteligentes” , los cuales podían realizar procesos sin
a intervención humana, por ej. los hornos microondas, robots, etc.
1985
■ Se masifico la programación orientada a objetos.

■ Se comenzó a utilizar el software para simular el procesamiento de información basada en redes
neuronales artificiales.
■ Se crearon los llamados entornos cliente-servidor.
■ Se empezaron a implementar mejores prácticas y etapas de desarrollo de software.
1985
■ La información se centralizaba en internet y de allí se recogían o transportaban datos desde y
hacia diferentes sistemas ,por lo que las aplicaciones web comenzaron a tener un mayor auge.
a
2000
Fundación
Universitaria del
del Área
Área Andina
Andina 10
6
Importancia del software
Para abordar este tema, es necesario abordarlo desde diferentes puntos de vista, de acuerdo
al uso que se le dé.
Permite iniciar procesos de autoformación.

En educación
Permite el acceso a la información.
En actividades En este caso, estaría enfocado a las capacidades que permiten los dispositivos
diarias móviles.
Optimizar tareas. Sin el software, una lavadora no podría llevar a cabo correc-
En el hogar
tamente la labor para la cual fue diseñada y fabricada.
Permite mejorar proceso.
Mejorar la eficiencia.
En el ámbito
Incrementar el desarrollo y los alcances de la empresa.
empresarial
Permite la automatización de procesos.
Optimizar los tiempos.
Si se habla de software libre, se podría decir Disminuye costos: el costo de obtener soft-
que es importante porque: ware libre es mucho menor que el coste de
obtener una licencia comercial. De esta ma-
Genera Autonomía tecnológica, ya que los nera se optimizan los recursos económicos
usuarios pasan de tener un rol meramente ya sea para usuarios o para empresas.
de consumo a ser creadores de nuevos.
Problemas del software
Permite la estandarización e integración:
al ser producido por estándares y especi- Abarcaremos esta temática sin plantear
ficaciones libres y públicos, permite que problemas específicos de una determinada
fácilmente pueda ser ajustado a los reque- solución de software, si no que se realizara
rimientos de una entidad o proceso deter- una generalización de problemas comunes
minado. en el desarrollo de software, sea cual sea su
objetivo.
Permite una mayor seguridad: al manejar
información abierto se conoce que infor- Falta de planificación
mación maneja y como lo hace, a quien la
comparte, etc. Por otro lado, los hacker no Una mala planificación implica que se ex-
ven como objetivo generar virus pues son tiendan los tiempos de entrega del produc-
fácilmente detectables por la misma natu- to, se incrementen los costos de personal al
raleza del código abierto. no tener bien definido el perfil del personal
necesario, diseñador, grafico, de multime-
Genera Independencia de proveedores: ya dia, fotógrafo, etc. Al final los pocos inte-
no se necesitará del fabricante para obtener grantes del equipo resultan haciendo fun-
actualizaciones, pues es el mismo usuario es ciones que nada tienen que ver con su rol o
quien las realiza. perfil profesional.
Fundación
Universitaria del
del Área
Área Andina
Andina 11
7
La estimación de costos te, pero seguramente con el tiempo reque-
Nunca se sabe cuánto tiempo y trabajo im- rirá de ajustes, mejoras en funcionalidades,
plicara realmente un desarrollo hasta que etc. y esto genera nuevos costos de desarro-
no se empiecen a realizar y es en este pro- llo, independientemente si es para actuali-
ceso donde muchas veces no se tuvieron en zación o ajustes.
cuenta los costos de horas de desarrollo que
eran necesarias para lograr el objetivo. Requerimientos no claros
Calidad en el producto final Normalmente el desarrollo de software se
Cuando se inicia con las pruebas finales, em- inicia con una indicación superficial de los
piezan a salir a flote deficiencias en el mis- requisitos por parte del cliente, sin haber
mo, pues este normalmente ha sido proba- indagado a profundidad, cada uno de ellos,
do en condiciones optimas y por personal sus implicaciones. En la marcha, surgen las
capacitado, pero la realidad es que el usua- dudas respecto a cómo debe desarrollarse,
rio o cliente final, es quien realmente debe o como debería, generando retrasos, pérdi-
hacer las pruebas finales, en el entorno en el
que finalmente va a funcionar. das de tiempo, tanto del equipo de desarro-
llo como del cliente.
Estos problemas generan insatisfacción, fal-
ta de confianza en la empresa o equipo de El cliente normalmente una idea abstracta
desarrollo contratado, etc. Un cliente solo del resultado final, pero no sobre las funcio-
mira el resultado. nes que debería cumplir el software.
Altos costos de mantenimiento A continuación se presenta una muy buena

Puede que un producto de software cumpla imagen que contextualiza la falta de comu-
los requerimientos solicitados por un clien- nicación en un desarrollo de software.
Imagen 1
Fuente: http://image.slidesharecdn.com/01-elprocesodedesarrollodesoftware-120911090848-
phpapp01/95/01-el-procesodedesarrollodesoftware-5-728.jpg?cb=1347354573
Fundación Universitaria del Área Andina 12

Falta de documentación almacenamiento, comunicación con otros
¿Que pasaría si el programador, se va de la sistemas, etc.
empresa o deja el proyecto? Si no hay docu-
Seguridad: debe contar un control de la
mentación al respecto, seguramente quien
información almacenada, de tal forma que
tome las riendas tendrá que invertir tiem-
esté protegido contra ataques externos.
po en «entender» como se hizo, generando
pérdidas de tiempo y dinero para la empre-
Características de transición
sa.
Interoperabilidad: permitir el intercambio
Por otro lado si un cliente no tiene docu- de información con otros sistemas o aplica-
mentación de cómo funciona, seguramente ciones, de tal forma que permita la escala-
se generaran problemas de uso y abuso del bilidad.
software, salvo en aquellos casos en el mis-
mo, sea altamente intuitivo. Reutilización: el código debe estar escrito
de tal forma que pueda reutilizarse en otros
Características del software desarrollos, realizando pequeñas modifica-
Se definen las siguientes categorías: operaciones o ajustes.
tivas, de transición, de revisión.
Portabilidad: que pueda ejecutar en dife-
Características operativas rentes plataformas o entornos, las funciones
incluidas en el desarrollo.
Se refieren a la forma como es presentado el
software al cliente final o usuario y se inclu- Características de revisión
yen los siguientes aspectos:
Se refieren a factores internos de funciona-
Corrección: realizar los ajustes necesarios a miento como su estructura, eficiencia y do-
fin que cumpla con todos los requerimien- cumentación. Desglosando algunos aspec-
tos que el cliente ha establecido. tos, se pueden relacionar:
Usabilidad: se refiere a que sea sencillo de Mantenimiento: debe poder realizarse sin
utilizar o sea fácil de aprender a usarlo. complicaciones
Integridad: una vez instalado, no debe Flexibilidad: capacidad para que los ajustes
afectar el normal funcionamiento de otros o modificaciones se puedan realizar sin pro-
programas o tareas del equipo donde se en- blemas.
cuentre instalado.
Extensibilidad: aumentar su escalabilidad,
Fiabilidad: el producto de software no de- debe ser fácil de incluir nuevas funciones.
bería tener ningún defecto. No sólo esto, no
debe fallar mientras la ejecución. Escalabilidad: debe ser muy fácil de actuali-
zar para más trabajo.
Eficiencia: debe optimizar los recursos dis-
ponibles en el ambiente en que se ejecuta. Capacidad de prueba: pruebas del software
Por ejemplo, usar eficazmente el espacio de debe ser fáciles.
Fundación
Universitaria del
del Área
Área Andina
Andina 13
9
Modularidad: debe estar compuesto por Control de calidad del software
unidades y módulos independientes entre Son las técnicas y actividades operativas que
sí. se utilizan para realizar una verificación de
requisitos que permitan mantener un control
Conceptos de calidad del proceso de desarrollo y eliminar todas
Características para medir la calidad del aquellas causas que puedan generar algún
software defecto o anomalía, en alguna de las fases
del ciclo del vida del producto de software.
Utilidad
Aseguramiento de la calidad
Que cumpla los requerimientos exigidos
por el cliente o usuario. Implica todas las actividades que se requie-
ren para que el producto de software pueda
Confiabilidad generar confianza y cumpla a cabalidad con
los requerimientos planteados.
Que permita realizar las funciones preesta-
blecidas, en las condiciones reales de uso, Dentro de estas actividades se pueden men-
durante un tiempo determinado, sin que se cionar:
afecte la funcionalidad y manteniendo la in-
Revisiones técnicas y de gestión, a fin de
tegralidad de datos que se manejen.
evaluar (su objetivo es la evaluación).
Claridad Inspección, con el fin de verificar si se está
Deben ser fáciles de entender: internamen- construyendo el producto que ha solicitado
te y externamente. el cliente.
Económico Pruebas y validación, para determinar si el

software se está construyendo en forma co-
Que su desarrollo, uso y mantenimiento se rrecta.
pueda costear. El software debe optimizar y
disminuir los recursos humanos, de tiempo Auditorias, para confirmar el cumplimiento
o materiales que se requerían antes de ha- de funciones.
ber sido adquirido.
A continuación se muestra un grafico donde
se resumen los procesos incluidos dentro de
Gestión de la calidad del software
la Gestión de calidad. Cada una de las eta-
La gestión de calidad del software implica pas implica un desarrollo conjunto de estra-
dos procesos fundamentales: el control de tegias o actividades que permiten lograr la
calidad y el aseguramiento de la calidad. calidad de software y todas.
del Área
Área Andina
Andina 14
10
Gestion de la calidad
Revisiones y Control de la Aseguramiento Estrategia de

auditorias calidad de la calidad mejora
Producto final y Revisiones y Revisiones y

organizaciones auditorias auditorias
Productos
Procesos
(entregables)
Figura 1
Fuente: Propia.
del Área
Área Andina
Andina 15
11
1
UNIDAD
1 Unidad 1
Introducción a
la Ingeniería de Ingeniería de software
software
Introducción La presente cartilla muestra la evolución que han tenido las
telecomunicaciones, los medios de transmisión usados en
la actualidad y una introducción a los conceptos básicos de
electricidad y electrónica. Una situación practica de las temá-
ticas expuestas, es a la hora de implementación de un sistema
de información, ya que usted deberá conocer cuál es el consu-
mo de corriente o voltaje de los equipos para en base a esto,
utilizar un cable de conexión especifico que soporte esa carga
y poder realizar la implementación de la red.
Por otro lado, al conocer las características ventajas, o desven-

tajas de un medio de transmisión u otro, podrá determinar
cuál es la mejor alternativa a la hora de la implementación de
un sistema de comunicación.
del Área
Área Andina
Andina 17
3
U1 Metodología


comiendo la asistencia diaria para aprovechar al máximo el curso. Es importante seguir los
inteligentemente.

Fundación
Universitaria del
del Área
Área Andina
Andina 18
4
Introducción a la Ingeniería de software
Mitos del software

Mitos del cliente
Mitos del cliente

Mito Realidad
Se requiere de una excelente comunicación entre el cliente y
Sé que me hago entender analista ,de tal forma que pueda establecer claramente cada uno
con comentarles la idea de de los requerimientos que el cliente necesita para su software:
lo que necesito. información, interfaces gráficas, funciones, rendimiento, diseño,
ejercicios de validación, etc.
Si los cambios son solicitados cuando el software ya está en
proceso de diseño, pueden incrementarse significativamente los
Agregar una nueva
costos de desarrollo (tiempos de entrega, horas de desarrollo,
funcionalidad es sencillo,
mas personal técnico, etc.), pues en esta etapa ya están definidos
pues me dijeron que el
los recursos que se necesitan y también se tiene un diseño inicial
software es flexible.
sobre el que se está trabajando. Si el cliente solicita cambios al
final del proyecto, los costos serán mucho más altos.
Cuadro 1
Fuente: Propia.

19
Mitos del desarrollador
Mitos del desarrollador

Mito Realidad
Mas del 50% del esfuerzo que se le dedica a un desarrollo, se reali-
za, después que al cliente se le ha entregado el primer prototipo, si
se ha seguido alguna metodología tradicional como: RUP (Rational
Unified Procces), MSF (Microsoft Solution Framework), Win-Win
Para que metodologías,
Spiral Model, Iconix.
si lo que se necesita es
que el software funcione
Por lo que para disminuir ese porcentaje de esfuerzo, es necesario
y listo...ahí terminamos.
implementar metodologías agiles de desarrollo, por ejemplo: XP
(Extreme Programming), Scrum, Crystal Clear, DSDM (Dynamic Sys-
tems Developmemt Method), FDD (Feature Driven Development),
ASD (Adaptive Software Development), XBreed, Extreme Modeling.
Solo podemos
Las actividades que permiten una revisión técnica del software es
comprobar la calidad
un filtro de calidad que se debe implementar durante todo el pro-
hasta que tengamos el
yecto, ya que permite detectar defectos de funcionamiento.
software funcionando.
El software implica el programa como tal, los datos que manejan el
Solo necesitamos programa y la documentación del mismo.
entregarle al cliente su
software funcionando y La documentación permite contar con una guía para las labores de
ya! mantenimiento, haciendo que estas se puedan hacer en un tiempo
más corto.
Cuadro 2
Fuente: Propia.
Distribución del esfuerzo en un proyecto ■ Análisis y diseño: Se proyectan interfaces

de programación gráficas, casos de uso, funcionalidades,
etc.
Grafica de distribución del esfuerzo
■ Codificación: escribir el código fuente
Se entiende por esfuerzo a la cantidad de que permita llevar a cabo lo que se de-
recursos humanos que se requieren para termino en la etapa de análisis y diseño.
llevar a cabo las tareas de un proyecto de
software, donde ya se ha realizado un aná- ■ Pruebas: verificar si lo que se codifico y
lisis documentado y detallado de todos los ejecuta el software cumple con los re-
requerimientos solicitados por el cliente. querimientos.
Este esfuerzo es medido en meses/hombre. ■ Adaptación: reutilizar código.
Un proyecto de software involucra las si- ■ Mejoras: incluir nuevas funcionalidades.
guientes etapas: ■ Arreglos: corrección de errores.
Fundación
Universitaria del
del Área
Área Andina
Andina 20
6
Cada una de estas etapas se ha llevado a la centaje de esfuerzo de cada una, durante el
siguiente una gráfica que representa el por- ciclo de desarrollo. Los porcentajes.
Imagen 1
Fuente: Propia.
Teniendo en cuenta la grafica anterior, se Utilizar técnicas de descomposición sen-

puede determinar que un 60% del esfuerzo cillas
está concentrado en las etapas de adapta- Descomponer el proyecto en secciones más
ción, mejoras y arreglos, es decir a mejorar pequeñas, de acuerdo a la descomposición
el producto. del problema y descomposición del proce-
so (Pressman, 2005). Es importante que se
Opciones actuales para estimación conozca profundamente el alcance del soft-
Usar proyectos similares ware que se pretende construir, para luego
realizar un proceso de estimación del tama-
Puede funcionar, siempre y cuando los pro- ño del mismo.
yectos de referencia tengan gran similitud
con el que se está realizando. El problema es Desarrollar un modelo empírico
que se puede llegar a necesitar datos esta-
dísticos que no siempre están disponibles o Se basa en utilizar formulas empíricas para
que aunque estén disponibles, no represen- proyectar costos, esfuerzos y tiempos de
tan indicadores exactos de los que requiere desarrollo. Los datos han sido obtenidos de
el proyecto. muestras limitadas de otros proyectos.
Fundación
Universitaria del
del Área
Área Andina
Andina 21
7
Usar herramientas automáticas t= Duración del proyecto en meses o años.
Permiten estimar costos y esfuerzos, du-
B= Factor especial de destrezas.
ración, riesgos, análisis de situaciones de
acuerdo a fechas de entrega, selección del P= Parámetro de productividad.
personal, etc.
Según [Putnam, 1992], en la medida que
Los modelos más comunes de estima- aumentan las necesidades de integración,
ción garantías de calidad, pruebas, documenta-
COCOMO II ción y habilidad de gestión se aumenta el
factor B.
Constructive Cost Model II (segunda ver-
sión). Considera la construcción de prototi- El parámetro P refleja el estado de madurez
pos, el desarrollo basado en componentes y de:
el uso de programación con bases de datos,
para el desarrollo de software. Se compone ■ Proceso de desarrollo.
de tres sub modelos: ■ Prácticas de gestión.
• Composición de aplicaciones. Se ■ Uso correcto de las normas de la ingenie-
utilizan componentes reutilizables, ría de software.
scripts y programación de bases de
datos, para realizar estimaciones de ■ El nivel de los lenguajes de programa-
desarrollo de prototipos. ción utilizados.
• Diseño Inicial. Se utiliza en las prime- ■ Habilidades y experiencia del equipo.

ras etapas de diseño, basándose en la ■ Complejidad de la aplicación.
exploración de diferentes arquitectu-
ras del sistema y conceptos de ope- Administración de proyectos de soft-
ración, siempre y cuando los requeri- ware
mientos ya hayan sido definidos.
• Post – Arquitectura. Se utiliza cuando
Conceptos básicos
ya se ha finalizado el diseño del siste- Administrar un proyecto de software con-
ma y se tiene su respectiva documen- siste en llevar un control del desarrollo, pla-
tación detallada. Permite realizar es- zos y recursos establecidos. Involucra tam-
timaciones para las diferentes etapas bién la organización técnica y dirección del
del ciclo de vida de desarrollo. recurso humano que conforma el equipo de
trabajo.
Ecuación del software de Putnam
Modelo multivariable dinámico que fue La administración de un proyecto de soft-
planteado por Putnam (Pressman, 2005) y ware involucra 4 áreas:
asume una distribución especifica del es- • Estructura. Con cuales elementos se
fuerzo durante el ciclo de vida del mismo. conformará la organización.
Maneja la siguiente ecuación:
• Proceso administrativo. Asignación
de responsabilidades y actividades
de supervisión del personal.
E = [ LDC × B0, 333 ⁄ P ]3 × ( 1 ⁄ t4 )
• Proceso de desarrollo. Los métodos,
lenguajes de programación, herra-
mientas a utilizar, fuentes de docu-
Donde;
mentación y apoyo.
L= Esfuerzo en personas mes o personas / • Programación. Cronograma para rea-
año. lizar las actividades propuestas.

Y debe controlar los siguientes factores: ■ Determinar la estructura organizativa:
• El costo total del proyecto: aumen-
elementos de la organización involucra-
dos y su interacción. Ej.: departamentos,
tar/disminuir gastos o costos.
compañías, lideres
• Capacidades del proyecto: agregar/
■ Identificar el proceso administrativo:
eliminar funcionalidades. como se llevará a cabo el modelo de orga-
• Calidad del producto: como aumen- nización y las responsabilidades que cada
tar el tiempo entre fallos de una cier- participante tiene dentro del proyecto.
ta severidad. ■ Programar el proceso: cronograma para
• Duración del proyecto: aumentar/ realizar las actividades propuestas, con
reducir tiempo programado de ter- tiempos establecidos para cada una.
minación. ■ Establecer equipo de trabajo: debe estar
conformado de acuerdo a las actividades
Secuencia de actividades fundamentales a ejecutar.
de administración ■ Analizar los riesgos y buscar soluciones:
■ Comprender el contenido, alcance y esto ayuda a garantizar que el proyecto
tiempos del proyecto: para tener un en- tenga éxito.
tendimiento global ya que lo especifico
corresponde al personal técnico
■ Identificación de productos finales: debe
establecerse los productos de documen-
■ Identificar el proceso de desarrollo: mé- tación o código que deben generarse, los
todos, herramientas, lenguajes, docu- cuales deben estar asociados al crono-
mentación, ayudas. grama de actividades
Tipos de estructura organizativa en equipos de trabajo

Organización jerarquía
Director del proyecto
Experto Líder de Experto en

mercado desarrollo calidad
Ingeniero Ingeniero Ingeniero Técnico
Figura 1
Fuente: Propia
Fundación
Universitaria del
del Área
Área Andina
Andina 23
9
Consta de un director general del proyec- Organización horizontal
to y bajo su mando se encuentran 3 líneas:
Experto en mercado, Equipo de desarrollo y
un área de calidad. Tiene como ventaja que Técnico
las líneas de autoridad y decisión están bien Ingeniero
definidas, el inconveniente es que los miem- Técnico
bros ubicados en la parte inferior, tienen Líder
una baja participación en las decisiones.
Ingeniero Técnico
Organización homogénea
Figura 3
Fuente: Propia.
Ingeniero Todos los integrantes tienen la misma rele-

vancia, excepto el líder, quien es el encar-
gado de incentivar la participación de cada
uno. Si todos tienen las mismas capacida-
Ingeniero Ingeniero des, cada uno puede asumir una responsa-
bilidad en un área específica (implementa-
ción, diseño, calidad, etc.).
Gestión del riesgo

Un riesgo es cualquier hecho que puede
Ingeniero Ingeniero afectar en forma negativa el proceso de
desarrollo de un proyecto. Si se identifican
estos riesgos durante el proceso, es posible
Figura 2 prevenir sus consecuencias o cambiar su
Fuente: Propia. enfoque para minimizarlas.
La gestión del riesgo implica identificar, eli-

Los integrantes del equipo tienen la misma minar o minimizar cada una de los posibles
autoridad, lo que permite aumentar la moti- riesgos. Esto puede ser llevado a cabo por
vación de cada uno, frente a sus actividades. un integrante del equipo que hace la labor
El inconveniente es que se generan dificul- de coordinador de riesgos, pero todos deben
tades a la hora de resolver diferencias, pues adoptar una «mentalidad de riesgo» para
no hay una cabeza líder y la toma de deci- identificarlos en todo momento del proceso.
siones se hacen por mayoría, lo que puede
presentar inconformidades. Tipos principales de riesgos
• Evitables: por ejemplo, que alguno
Este tipo de organización puede funcionar de los integrantes del equipo decide
correctamente, en equipos pequeños, cu- retirarse. En este caso puede corre-
yos integrantes estén acostumbrados a tra- girse o mitigarse para continuar el
bajar en equipo. proceso.
del Área
Área Andina
Andina 24
10
• No evitables: por ejemplo, cuando se • Planificar su eliminación.
cambian las condiciones o requeri-
mientos, después que han sido desa-
• Priorizar los riesgos para su elimina-
rrolladas. Este tipo de riesgos pueden ción.
ser beneficiosos, pues el proyecto • Eliminación o atenuación.
podría no continuarse y así no seguir
gastando recursos innecesariamente. Estas actividades pueden ser plasmadas en
Actividades principales en la gestión de una tabla que se muestra a continuación y
riesgos que representa un plan de trabajo para la
• Identificación. gestión de los mismos.
Imagen 1
Fuente: http://www.ctr.unican.es/asignaturas/Ingenieria_Software_4_F/Doc/M2_08_Administracion-2011.pdf
Una vez identificados los riesgos, se le asig- Algunas fuentes de riesgos

na un puntaje de acuerdo a diferentes fac- •Que los líderes del proyecto no ten-
tores, como prioridad, costo, impacto, etc.
gan el compromiso suficiente.
Esto dependerá del tipo de proyecto que se
esté desarrollando. Tener organizados los • Que el cliente o usuario no tenga el
riesgos ayuda a tener una mejor visión del compromiso suficiente.
impacto que pueden causar y en esta medi-
da darles el tratamiento necesario • Requisitos mal comprendidos.
del Área
Área Andina
Andina 25
11
• Mala participación del usuario o • CENTRAL DESKTOP Central Desktop
cliente en el proceso. • CONFLUENCE Confluence
• Que el producto final no cumpla las • KAPOST Kapost
expectativas del cliente o usuario fi-
nal. • PRODUCTEEV Producteev
• Que cambie el alcance, objetivos o • TEAMBOX Teambox
requerimientos. • TEAMLAB TeamLab
• Que las aptitudes o conocimientos • TIMEDOCTOR Time Doctor
del personal no sean suficientes.
Paradigmas de la Ingeniería de software
Herramientas online para gestión de pro-
yectos Modelo en cascada o clásico (modelo
tradicional)
Con el avance que ha tenido internet y la
cobertura que los gobiernos han venido La característica principal es que para poder
implementando en las ciudades, ha aumen- avanzar a una siguiente etapa del ciclo de
tado también la tendencia del trabajo cola- vida del software, se debe haber finalizado
borativo online. Y es aquí donde las herra- la etapa inmediatamente anterior. La meto-
mientas online para gestión de proyectos dología que sigue el modelo en cascada es:
juegan un papel muy importante.
A continuación relacionaremos algunas fun- ■ Análisis de requisitos

cionalidades de este tipo de herramientas:
1
• Intercambiar archivos en tiempo real.
• Enviar o recibir notificaciones instan- ■ Diseño del sistema
táneas de reuniones, cambios, etc. 2
• Control y seguimiento de los plazos
establecidos. ■ Diseño del programa
• Seguimientos de costes. 3
• Gestión de la relación con clientes o
usuarios del proyecto. ■ Codificación
• Actividades de facturación. 4
• Creación de wiki y versiones de desa-
■ Pruebas
rrollo.
• Chat y videoconferencias.
5
Dentro de las muchas opciones que existen ■ Implementación

en la red, se han seleccionado 10 herramien- 6
tas que por sus características, se resaltan
de las demás. A cada una se le ha incluido el
link respectivo del sitio oficial para que us- ■ Mantenimiento
ted conozca sus características específicas: 7
• ACTIVE COLLAB ActiveCollab
• ASSEMBLA Assembla Figura 4
• BASECAMP Basecamp Fuente: Propia.

Si por ejemplo, se detecta algún error de di- el proyecto se divide en proyectos más pe-
seño, se debe rediseñar y realizar una nueva queños y en cada uno de ellos se identifican
programación, lo que aumenta los costos
los riesgos más importantes a fin de con-
de desarrollo.
trolarlos. Se van desarrollando versiones in-
Modelo en espiral (modelo evolutivo) crementales de cada uno, hasta obtener el
En un modelo orientado a riesgos, en el que producto final.
Imagen 2
Fuente: http://1.bp.blogspot.com/_S5W0bf4uECM/TL5uOoqW4MI/AAAAAAAAABI/wk8pbHQALHU/s1600/
espiral2.png
Modelo de prototipos teractuar con el equipo de trabajo, para ir

Permite al usuario evaluar el producto des- verificando el cumplimiento de los requeri-
de las primeras etapas de desarrollo e in- mientos exigidos.
del Área
Área Andina
Andina 27
13
El modelo sigue la siguiente metodología:
• Definir objetivos globales.
• Identificar requisitos conocidos.
• Identificar áreas que requieren mejor
definición.
• Diseño rápido de prototipo y mode-
lado.
RAD (Rapid Application Development)

Busca reducir los riesgos segmentando el
proyecto para facilitar cualquier cambio
que se requiera. Hace uso de la iteración
por prototipos en cada una de las etapas de
desarrollo, involucrando al usuario en todo
momento y utilizando herramientas de soft-
ware, para así generar productos de alta ca-
lidad y en el menor tiempo posible.
Las herramientas de software pueden ser:

• Generadores de Interfaz gráfica de
usuario (GUI).
• Computer Aided Software Enginee-
ring (CASE).
• Sistemas de gestión de bases de da-
tos (DBMS).
• Lenguajes de programación de cuar-
ta generación.
• Generadores de código.
• Técnicas orientadas a objetos.
Fundación
Universitaria del
del Área
Área Andina
Andina 14
28
1
UNIDAD
2 Unidad 2
Introducción a
la ingeniería de
requisitos Ingeniería de software

Introducción La formación del Ingeniero en sistemas involucra el cono-
cimiento de dispositivos físicos encargados de soportar el
procesamiento y transmisión de la información, los cuales se
convierten en elementos fundamentales al momento de de-
sarrollar una solución en estos campos.
El conocimiento y manejo adecuado de estas tecnologías

permite resolver problemas de sistemas, usando el soporte
de soluciones computacionales e informáticas eficientes apli-
cando el conocimiento científico.
De esta forma, la presente asignatura es fundamental para el

estudiante que se inicia en esta profesión, ya que le permi-
te visualizar y conocer, los fundamentos de la formación en
tecnología, su evolución histórica, los campos de acción, y las
principales herramientas que utiliza un ingeniero en sistemas.
De igual manera, este curso aporta las bases para reconocer y
entender los diversos dispositivos físicos relacionados con su
objeto de estudio, así como la labor que estos cumplen en la
implementación de soluciones en el campo de los sistemas,
de tal forma que puedan realizar la mejor elección, en el mo-
mento de desarrollar un proyecto de apropiación o desarrollo.

U2 Metodología
Para el desarrollo de los temas teóricos del curso se asignarán a los estudiantes algunas acti-
vidades de investigación y exposición, actividades que serán guiadas y apoyadas por el tutor
y complementarán los contenidos publicados en plataforma. Las evaluaciones de las activi-
dades serán utilizadas como retroalimentación para los expositores y para el mismo grupo.
El tutor realizará una teleconferencia semanal de un tema especifico, en el cual se presenta-

rán ejemplos para reforzar dicho tema. En cada semana se publica el material de estudio que
apoyara el desarrollo de los contenidos temáticos correspondientes a dicha semana, ya sea
en recursos bibliográficos, archivos digitales o referencias electrónicas (páginas web).
Se recomienda el ingreso diario a la plataforma para aprovechar al máximo el curso.

U2 Introducción a la ingeniería de Deben ser verificables mediante análisis,

inspección, demostración o pruebas.
requisitos
Deben ser necesarios, por lo que omitirlos
Concepto de requisito causarían un mal funcionamiento del sistema.
Es una funcionalidad que un sistema debe Deben ser consistentes en el sentido que no
realizar para que cumpla con el objetivo debe contradecir otro requerimiento.
para el cual fue desarrollado.
Ejemplo: interfaces graficas, control de erro-
Es diferente un requisito a un deseo del res, estándares utilizados, capacidad de ren-
dimiento, seguridad de los datos, que sea
cliente. portable, usabilidad, etc.
La misión del Ingeniero de software es trans- A continuación se muestra una grafica que
formar las solicitudes del cliente o usuarios representa como se encuentran organiza-
en requerimientos. ción los requisitos según (Pohl, 1997).
Imagen 1
Fuente: http://ocw.usal.es/ensenanzas-tecnicas/ingenieria-del-software/contenidos/Tema3-
IntroduccionalaIR-1pp.pdf

Requisitos de información el comportamiento frente entradas o situa-
Hacen una descripción de los datos que el ciones particulares.
sistema debe almacenar y procesar para po- Ejemplo: el usuario deberá poder buscar los
der cumplir los objetivos para los cuales fue artículos por nombre o código.
desarrollado.
Ejemplo: se deberá almacenar información Requisitos de funcionalidad

referente a préstamos realizados en el ban- Permiten especificar como deberá ser el
co, tales como nombre, tipo de préstamo, comportamiento de un sistema.
cantidad, fecha del préstamo, fecha finaliza-
ción, domicilio del cliente, etc. La herramienta más utilizada para el levan-
tamiento de este tipo de requisitos son los
Requisitos de interfaz Casos de Uso. Estos describen simbólica-
mente como es la interacción de los dife-
Definen la forma en que interactuara con rentes actores que intervienen en el sistema
otros sistemas. y las acciones que realizan sobre el mismo
Ejemplo: el sistema deberá establecer co- sistema. Todas las acciones deben obtener
municación bluetooth con la impresora por- un resultado que sea observable y de valor
tátil para realizar la impresión del recibo. Los para cada uno de los actores.
datos deben ser enviados en formato XML.
Los casos de uso hacen parte del Lenguaje
Requisitos funcionales Unificado de Modelado UML. Este tema será
tratado más profundamente en la semana 4.
Representan aquellas tareas especificas que La siguiente tabla resume los elementos que
el sistema debe realizar y como deberá ser componen un diagrama de casos de uso:
Representación
Nombre Función
grafica
Actor Role que realiza un usuario dentro de un sistema.
Casos de Acción específica que se realiza después de una orden de una

Uso entrada externa.
Asociación: indica la invocación desde un actor o caso de uso a
otra operación (caso de uso).
Dependencia o Instanciación. Indica cuando una clase depende
Relaciones
de otra, es decir, se instancia (se crea).
de Uso,
Comuni- Generalización: es exclusivo para casos de uso. Puede ser de Uso
cación y (<<uses>>) o de Herencia (<<extends>>).
Herencia extends: se usa cuando un caso de uso tiene características
similares a otro.
uses: se usa cuando varios caso de uso tienen un conjunto de
características similares.
Cuadro 1
Fuente: Propia.

Para comprender un poco más el tema, a muestra un modelo de casos de uso para un
continuación encontrara una imagen se sistema de compra de obras de arte.
Imagen 2
Fuente: http://www.geocities.ws/vidalreyna/usecase
Requisitos de datos Requisitos no funcionales

Se refieren a los tipos de datos que maneja- A continuación se relacionan algunas carac-
ra el sistema con el fin de determinar la for- terísticas que tienen los requisitos no fun-
cionales:
ma en que deben ser procesados.
Se encuentran por fuera de la forma en que
Ejemplo: fechas, enteros, float, string. debe funcionar el sistema.
Fundación
Universitaria del
del Área
Área Andina
Andina 34
7
Se asocian con restricciones que tendrá un Hacen una definición de las funcionalidades
sistema, ya sean internas o externas. Una globales que tendrá el sistema.
restricción es una limitante que hace que el
problema se pueda resolver de una forma
Se relacionan con aquellas propiedades adi-
determinada ej.; que al final de un proceso
haya que imprimir automáticamente un do- cionales de un sistema.
cumento en una impresora con unas carac-
terísticas especificas. A continuación se muestra un mapa con-
La tarea de verificación normalmente es di- ceptual referente a requisitos no funciona-

fícil de realizar. les:
Imagen 3
Fuente: http://vignette3.wikia.nocookie.net/requerimientos-software/images/3/30/CLASIFICACION_DE_
REQUERIMIENTOS_NO_FUNCIONALES.png/revision/latest?cb=20140430011055&path-prefix=es
Requisitos de seguridad Ejemplo: Se usara por personas con disca-

Nivel de protección de los datos que alma- pacidad auditiva.
cena el sistema, para uso no autorizado,
Para medir la usabilidad se toman algunos
perdidas de información, accesos no auto-
rizados etc. puntos de referencia tales como:
Tiempo de capacitación para que un usua-

Requisitos de usabilidad
rio puedan manipularlo correctamente.
La forma en que puede ser usado por el
usuario. Tiempos para realizar tareas específicas.
Fundación
Universitaria del
del Área
Área Andina
Andina 35
8
Interfaces amigables para el usuario. Objetivos de la ingeniería de requisitos
Documentación de uso, tipo y forma de pre- Identificar y documentar los que los clientes
y usuarios necesitan.
sentación, configuraciones, ayudas, etc.
Crear la documentación necesaria donde se
Requisitos de mantenimiento describa el comportamiento externo y res-
Reflejan la facilidad, periodicidad, y costos tricciones de un sistema, de tal forma que
que deben tenerse en cuenta para realizar cumpla las necesidades identificadas.
las tareas de mantenimiento, con el fin de
corregir defectos, hacer mejoras, etc. Analizar y validar la documentación de re-
quisitos para determinar que sean viables,
Requisitos de comprobabilidad que estén completos y consistentes.
El nivel en el que un sistema permite ser Realizar la devolución de necesidades.

comprobado, verificado o medido, en cuan-
to a las funciones que realiza Conceptos de ingeniería de requisitos
A continuación se relacionaran algunas de-
Requisitos de disponibilidad
finiciones planteadas por especialistas en
Relacionan el tiempo total que el software esta rama:
está disponible y operable para su uso, to-
mando como referencia un patrón de tiempo. Según (Reifer, 1994), “Es el uso sistemático
de procedimientos técnicas, lenguajes y he-
Ejemplo: el servidor de hosting debe tener rramientas para obtener con un coste redu-
el 99.9% de disponibilidad online. cido el análisis, documentación, evolución
continua de las necesidades del usuario y la
Requisitos de escalabilidad especificación del comportamiento externo
de un sistema que satisfaga las necesidades
Grado en el que el sistema puede aumentar
del usuario”.
sus capacidades. Por ejemplo: Aumentar el
número de conexiones o usuarios conecta- Según (Loucopoulus y Karakostas, 1995),
dos. “Es un proceso sistemático de desarrollo
de requisitos mediante un proceso coope-
Requisitos de extensibilidad rativo consistente en analizar el problema,
Miden la capacidad del sistema para incre- documentar las observaciones resultantes
mentar las funcionalidades. en una variedad de formatos de represen-
tación, y comprobar la exactitud de la com-
Ejemplo: que adicional a conectarse a otros prensión conseguida”.
dispositivos mediante wifi, que pueda co-
nectarse vía bluetooth. Actividades básicas de la Ingeniería de
requisitos
Otros requisitos no funcionales Para completar el proceso adecuadamen-
Requisitos de entorno, de presentación, re- te es necesario realizar una especificación
quisitos culturales, requisitos legales. y administración de cada uno de los requi-
Fundación
Universitaria del
del Área
Área Andina
Andina 36
9
sitos de los clientes o usuarios. Es por esto ■ Asegurar viabilidad técnica, de costes y
que para lograr este objetivo se siguen cua- planificación.
tro etapas fundamentales:
Tareas del análisis de requisitos
Extracción
Reconocimiento del problema
Se enfoca al descubrimiento de requisitos
del sistema. Evaluar las situaciones planteadas por el
cliente a fin de identificar la necesidad exis-
Análisis tente y se realiza un plan de trabajo. Tam-
bién se inicia un proceso de comunicación
Se analiza el documento levantado en la
etapa de extracción. Se realiza una lectura, con el equipo de trabajo a fin de reconocer
conceptualización, investigación de los re- y analizar grupalmente el problema a solu-
quisitos, se identifican problemas y solucio- cionar.
nes .También se programan reuniones con
el equipo de trabajo y con el cliente para Evaluación y síntesis
discutirlos. Analizar, evaluar y condensar el documento
de requerimientos, detallando las funciones
Especificación del sistema, interfaces, diseño, etc.
Se escribe el documento formal de requisi-
tos en forma detallada. Aquí se hace uso de Modelado
técnicas como UML y otros estándares de Utilizar técnicas de modelado como UML,
documentación.
Casos de Uso, para definir roles y funciones
de cada uno de los actores que intervienen
Validación
en el sistema, partiendo de los objetivos y
Se enfoca en la verificación de los requisi- requisitos documentados
tos planteados en el documento final, de tal
forma que realmente hagan una represen- Especificación
tación valida de lo que el sistema debe rea-
lizar. Las validaciones son internas porque Para dar una representación del programa
debe verificarse lo que se hace y externas que pueda ser revisada y aprobada por el
porque deben ser aprobadas por el cliente cliente. Se realiza la documentación
o usuario.
Revisión
Análisis y negociación de requeri- En esta etapa normalmente se generan
mientos cambios de comportamiento, funciones
establecidas para el sistema, la forma en
Objetivos del análisis de requisitos que se va a presentar la información, crite-
■ Realizar una detección temprana de pro- rios de validación y se reevalúa globalmen-
blemas. te el plan de proyecto a fin de reafirmar las
■ Construirun modelo de software que proyecciones realizadas durante la etapa
condense los requisitos del sistema. de análisis.
Universitaria del
del Área
Área Andina
Andina 37
Fundación 10
Gestión de cambios en los requisitos Roles que interactúan en la gestión de
Busca evaluar y planificar los cambios al pro- cambios
yecto de una forma eficiente, de tal forma
La siguiente tabla resume los roles principa-
que se pueda asegurar la calidad y continui-
dad del servicio. Debe existir una comuni- les que intervienen en el procedimiento de
cación con asertiva con los demás proceso. control de cambios.
Rol Descripción
Comité de control de cambios Se encarga de aprobar o rechazar solicitudes de cambios. Con-
(GCC) formado por clientes y Desarrolladores.
Quien lidera y hace genera la solicitud para un cambio de requi-
Promotor del cambio
sitos.
Se encarga de analizar el impacto que puede causar la petición
Evaluador de cambio en el sistema, ya sea a nivel técnico, de cliente, de
marketing.
Se encarga de realizar el cambio solicitado, de acuerdo al análi-
Modificador
sis que previamente ha sido revisado y aprobado.
Se encarga de verificar si los cambios se han hecho en forma
Verificador
correcta.
Normalmente el cliente final, quien es el que hace una valida-
Validador
ción del cambio realizado.
Cuadro 2
Fuente: Propia.
del Área
Área Andina
Andina 38
11
Diagrama del proceso
La siguiente figura muestra las actividades que se desarrollan durante la gestión de un cam-
bio de requerimientos de un proyecto de software.
Aceptar o rechazar
Registro de la petición Análisis del
el cambio (comité de
de cambio impacto
control de cambio)
Aceptado: se revisan costos, recursos, fechas de entrega

El comité de control
y se realizan los cambios para la nueva versión y se hace
de cambios notifica la
seguimiento.
decisión al solicitante
Rechazado: fin del procedimiento de gestión.
Figura 1
Fuente: Propia.
Flujos de entrada y salida

A continuación se muestra las diversas entradas y correspondientes salidas que se requieren
para la gestión de cambios por parte del Comité de Control de Cambios.
Imagen 4
Fuente: Propia.
del Área
Área Andina
Andina 39
12
Proceso de negociación
La tarea principal es la de realizar una dis-
cusión de los problemas encontrados y bus-
car una solución que sea benéfica para los
usuarios y personas involucradas en el de-
sarrollo del proyecto.
Durante este proceso se llevan a cabo 3 ta-

reas importantes:
1. Discutir los requisitos que presentan
conflictos.
2. Establecer una prioridad para cada uno.
3. Definir un compromiso final sobre los
mismos.

1
UNIDAD
2 Unidad 2
Especificación
y validación Ingeniería de software

Introducción Como Ingenieros de sistemas es muy importante conocer el
hardware asociado a los sistemas computacionales, así como
la labor que desempeñan cada uno de los componentes, den-
tro de dichos sistemas. Esta unidad se ha diseñado para cum-
plir ese objetivo, por lo que usted conocerá la configuración
básica de un computador, los puertos disponibles para cone-
xión de periféricos y los dispositivos más comunes que se co-
nectar al computador, ya sea como entradas o salidas.
Conociendo estos elementos usted podrá plantear solucio-

nes, frente a la configuración básica o fallas comunes en el
hardware del sistema de cómputo o en los elementos conec-
tados al mismo.

U2 Metodología


inteligentemente.

Al final de cada sección enviaré un breve mensaje resumen destacando los mejores en sus
intervenciones individuales y en los trabajos de grupo de esa sección.
Aquellos que hayan llamado mi atención negativamente por su falta de participación o por
lo inadecuado de las mismas les enviaré un mensaje privado.
Fundación
Universitaria del
del Área
Área Andina
Andina 43
4
Especificación y validación proyecto ha avanzado, lo que generaría al-

tos costos.
Proceso de validación de requisitos ■ Como se muestra en la figura 1, la valida-
Busca garantizar que los requisitos cuenten ción de requisitos recibe como entradas:
con las características de calidad suficientes el documento de requisitos (creado du-
para poder continuar a la siguiente fase del rante la fase de especificación).
proceso de desarrollo. Algunas de estas ca-
racterísticas son: ■ Los estándares o lineamientos por los
que deben regirse.
■ Que sean consistentes.
■ Completitud. ■ El conocimiento que el equipo de trabajo
encargado de realizar la validación.
■ Precisos.
■ Acordes con la realidad. Una vez realizado el proceso, como produc-
tos finales se tendrán: Un listado de proble-
■ Que puedan ser verificados. mas y un listado de acciones que permiten
El proceso también busca disminuir el ries- dar solución a dichos problemas y mejorar
go de tener que corregir después que el el documento de requisitos.
Documento de
requisitos Lista de
problemas
Estándares Validación
relacionados
de Lista de acciones
recomendadas
Conocimiento de requisitos
la organización
Figura 1.Entradas y salidas del la validación de requisitos

Fuente: Propia.
Fundación
Universitaria del
del Área
Área Andina
Andina 44
5
Técnicas de validación de requisitos cuenta la especificación de requisitos que
dicho producto debe tener.
Prototipado
El prototipado busca construir un mode- Existen diferentes tipos de prototipos, los
cuales se muestran a continuación:
lo usable de un producto de software, de
tal que clientes o usuarios puedan realizar Mock-ups: se enfoca en hacer una represen-
pruebas y determinar las correcciones o me- tación de la interfaz grafica de la aplicación
joras que se deberán realizar, teniendo en y las pruebas se limitan a este contexto.
Imagen 1
Fuente: Propia.
Storyboards: muestra gráficamente diferentes tareas que debe realizar la aplicación.
Imagen 2
Fuente: Propia.
Fundación
Universitaria del
del Área
Área Andina
Andina 45
6
Maquetas: se crea un prototipo funcional, con las pantallas propuestas para la interfaz grá-
fica, botones, conexiones entre pantallas. Dependiendo de la fidelidad que se requiera, se
puede programar acciones básicas para mostrar resultados concretos del sistema.
Independientemente del tipo de prototipo que se utilice, se deben seguir una serie de
pasos para realizar el proceso de validación de requisitos, como se muestra en la siguiente
figura.
Figura 2
Fuente: Propia.
Generación de casos de prueba realizar, ni que resultados deberían gene-

También se le llama revisión de requisitos o rarse. Esto pasa porque el requisito no está
bien definido y algunas razones son las si-
Test de requisitos. Este método se centra en
guientes:
la verificabilidad, una de las características
de la calidad del software. Se definen unos ■ No se indica cuales son los datos base
casos de prueba de tal forma que se pueda para generar el informe.
comprobar cada uno de los requisitos fun- ■ ¿El informe debe ser semanal, entre fe-
cionales del software. chas, de un pedido, por un cliente, de
ventas, etc.?
Para que se pueda cumplir la verificabilidad
de un requisito debe ser posible definir uno
■ ¿En qué momento del proceso se debe
generar?
o varios casos de prueba.
■ ¿Quién lo genera, automáticamente o
A continuación se desarrollara un ejemplo manualmente?
de desarrollo de un caso de prueba para el
Teniendo en cuenta lo anterior, el caso de
siguiente requisito:
prueba seria:
X. El sistema deberá generar un informe. 1. Se seleccionarán los datos A, B, C, para
generar el informe. Estos datos ya deben
Para este caso se define la tarea que debe estar bien definidos, con sus respectivos
realizar el software, mas no el cómo lo debe datos (cantidades, fechas, detalles, etc.).

46
2. Se deberá invocar la función de generar • No hay comprensión de los proble-
informe (Automática o Manual). mas técnicos que generan.
3. Se generará un informe con los datos A, • No hay comprensión del proceso de
B, C.…indicando además fecha y hora desarrollo.
de generación. Se debe incluir en la par-
te superior, el titulo del informe, el cual Relacionados con el área de análisis
es ingresado por el usuario, etc. • Falta de homogeneidad y claridad en
la redacción del documento de re-
Creación de manuales de usuario querimientos.
Lo que busca es que se pueda crear el ma- • Demasiado uso de condicionales.
nual de usuario, partiendo de las especifica-
ciones de requisitos. De no poderse lograr, • Poco uso de terminología propia de
seguramente dicha especificación no es su- la aplicación.
ficientemente detallada.
Relacionados con el personal de desarro-
Animación y validación de modelos llo
Consiste en realizar animaciones de los mo-
• Diferentes terminologías usadas en-
tre los ellos y los usuarios.
delos de pantallas del sistema y demás es-
pecificaciones, para que el cliente o usuario • Desarrollar sistemas basados en mo-
pueda visualizar como quedara el producto delos existentes, dejando a un lado
final. las necesidades reales del cliente.
• Dejar el análisis de requisitos en ma-
Problemas en la determinación de requi- nos de personas que no cuentan con
sitos el perfil adecuado para este tipo de
Relacionados con los usuarios actividades, con el fin de disminuir
• No hay claridad en lo que quieren. costos.
• Falta de vinculación en el proceso de
Gestión de requisitos y herramien-
elaboración de requisitos.
tas
• Tienden a agregan nuevos cambios,
después de haber definido costes y Procedimiento para revisión de requisi-
cronogramas de trabajo. tos
• Baja comunicación entre ellos y el El siguiente es el procedimiento normal que
equipo de trabajo. se debe ser a la hora de hacer la revisión del
• Falta de participación en revisiones. documento de especificación de requisitos:
Fundación
Universitaria del
del Área
Área Andina
Andina 47
8
Figura 3
Fuente: Propia.
Fundación
Universitaria del
del Área
Área Andina
Andina 9
48
Gestión de cambios de los requerimientos
A continuación se muestra un diagrama del proceso general que se sigue en la gestión de
requisitos.
Figura 4
Fuente: Propia.
El proceso inicia con una fase de explora- quisitos, listos para que el área de desarrollo
ción que busca conocer las necesidades comience su trabajo.
que tienen los usuarios o clientes. También
se debe documentar el contexto en el que Proceso de negociación
se desenvolverá el proyecto. En esta etapa se identifican los requisitos
Continua con la Captura de requisitos, que que presentan conflicto y se discuten con
es cuando se crea un documento de reque- el cliente, con el fin de llegar a un acuerdo
rimientos, los cuales pasaran a una etapa de que beneficie a ambas partes. Los conflictos
Análisis para determinar problemas y una se generan a raíz que en el proyecto están
etapa de Negociación, ya que seguramente involucrados diferentes personas, cada uno
se deberá llegar a un acuerdo con el clien- con sus propios intereses.
te, teniendo en cuenta que habrá requisitos En esta etapa se deben desarrollar las si-
imposibles de cumplir, por tiempo, tipos de guientes tareas:
tecnología, costos, etc.
Realizar una discusión de los requisitos que
Definidos los requerimientos finales, se presentan conflicto
pasa a la etapa de documentación, cuyo
producto final es un documento con lista Definir el nivel de prioridad para cada uno
definitiva de requerimientos, que pasaran a de los requisitos que presentan conflicto.
una etapa de validación para realizar ajustes
de calidad. Finalizada esta etapa se tendrá Eliminar, combinar o modificar los requisi-
entonces la lista definitiva y corregida de re- tos necesarios
del Área
Área Andina
Andina 49
10
Establecer el compromiso final al que se lle- IRqA (Integral Requisite Analizer)
go con el cliente ■ Brinda soporte para Captura, Analisis, Es-
pecificacion y validación de requerimien-
Herramientas comerciales tos.
Rational Requisite Pro ■ Gestiona el estado de arte.

■ Desarrollado por IBM. ■ Los requisitos son almacenados en docu-
■ Los requisitos son almacenados en forma mentos MS Word.
de documentos.
Telelogic Doors
■ Gestiona el control de cambio de requi- ■ Está diseñado para realizar tareas de cap-
sitos, para especificaciones de software y tura y enlace de requisitos.
pruebas.
■ Analizar y gestionar cambios a la infor-
■ Usa Oracle como motor de base de datos, mación.
corriendo sobre Unix o Windows. ■ Ligado a especificaciones técnicas de
■ También soporta SQL Server sobre Win- proyectos a los requisitos y normas espe-
dows. cificas.
■ Página oficial: http://www.ibm.com/de- ■ Permite mejorar los procesos de comuni-
veloperworks/ssa/library/IBM_Rational_ cación, colaboración y validación.
RequisitePro.html ■ Página oficial: http://telelogic-doors.soft-
ware.informer.com/
CaliberRM
■ Permite la captura y comunicación de las Visure Requirements
necesidades del usuario. ■ Soporta captura manual de requisitos,
■ Permite adaptarse a procesos de nego- servicios/soluciones y casos de prueba.
cio. ■ Permite importar requisitos desde MS
■ Ofrece variedad de soportes para clien- Word, Excel o XRI.
tes finales: Navegadores Web, Eclipse, ■ Permite definir tipos de requisitos funcio-
Microsoft Visual Studio y Windows. nales y no funcionales.
■ Ofrece un repositorio seguro y centra- ■ Gestiona los cambios durante las fases
lizado de acuerdo a las necesidades del del ciclo de vida.
proyecto. ■ Gestiona la trazabilidad de requisitos y su
■ Facilita el trabajo colaborativo. respectivo ciclo de vida.
■ Permite el análisis de impacto Trazabili- ■ Página oficial: http://www.visuresolu-
dad en tiempo real. tions.es/
■ Página oficial: http://www.borland.com/ ■ CASE Spec

en-GB/Products/Requirements-Manage- ■ Gestión , especificación y análisis de re-
ment/Caliber quisitos
del Área
Área Andina
Andina 50
11
■ Trabajo colaborativo OSRMT (Open Source Requeriments Ma-
■ Análisis de trazabilidad nagement Tool)
■ Permite la trazabilidad completa del Ci-
■ Diseño de especificaciones y documen- clo de vida de desarrollo de software: ca-
tación racterísticas, gestión de requisitos, dise-
■ Testeo y validación ño, implementación y pruebas.
■ Página Oficial: http://analysttool.com/ ■ Control de versión de documento de re-

quisitos.
Herramientas libres ■ Página oficial: http://sourceforge.net/
projects/osrmt/
REM (Requisite Management)
■ Brinda el soporte necesario para las fases Heler
de Ingeniería de Requisitos de proyectos ■ Monousuario
de software.
■ Soporte para Windows y licencia GPL
■ Creado por el profesor Amador Durán (GNU, 2008).
Toro, de la universidad de Sevilla
■ Creada bajo el Modelo Vista Controlador.
■ Permite agregar objetivos, actores. ■ Escrito en JAVA.
■ Crear casos de uso. ■ Usa PostgreSQL como motor de base de
■ Crear diferentes tipos de requisitos: Fun- datos.
cionales, no funcionales, de restriccion, ■ Usa Poseidon para modelado de diagra-
de almacenamiento de información. mas UML.
■ Genera matrices de rastreabilidad. ■ Módulos contenidos: Proyecto, stakehol-
■ Página oficial: https://www.lsi.us.es/des- der, actores y casos de uso, requisitos.
cargas/descarga_programas.php?id=3
Herramientas en la nube
DRES Gather Space
■ Basado en PHP. ■ Gestor de requerimientos.
■ La administración del proyecto se hace ■ Casos de uso e historial de usuario.
mediante navegadores web.
■ Jerarquía y asociaciones.
■ La documentación ese genera en forma-
to HTML. ■ Casos de prueba.
■ Usa MySQL como motor de base de datos ■ Seguimiento de validaciones.
y CORBA como servidor para almacena- ■ Página oficial: http://www.gatherspace.
miento y gestión de requerimientos. com
■ Soporte para extensiones en XML, direc- ITestMan
torios jerarquicos, resportes, etc.
■ Permite generar un repositorio de la in-
■ Página oficial: http://sourceforge.net/ formación que se genera duran te el pro-
projects/dres/ ceso de gestión de requisitos.
Fundación
Universitaria del
del Área
Área Andina
Andina 12
51
■ Puede generar automáticamente las es-
pecificaciones de requisitos así como la
documentación de pruebas de valida-
ción.
■ Generar informes en formatos diferentes
y para cada una de las áreas creadas para
el proyecto.
■ Acceso a la información en tiempo real,
respecto a avances de requisitos, prue-
bas, problemas etc.
■ Está ligado con estándares de desarrollo
como MIL-STD 498, ISO 12207, ED109,
CMMI nivel 3, etc.
■ Página oficial: http://www.polar-consul-
tores.es
Accept software
■ Permiten recopilar, organizar y requisitos
del producto, ideas, estrategias y directo-
rios.
■ Uso de componentes modulares.
■ Anticipación de problemas y conflictos.
■ Priorización y reducción de tiempos ba-
sada en información real de mercado.
■ Toma de decisiones en los diferentes ni-
veles.
■ Página oficial: http://www.accept360.
com/

1
UNIDAD
3 Unidad 3
Diseño orientado a
objetos de sistemas
de software Ingeniería de software

Introducción El Ingeniero de sistemas debe estar preparado para realizar
diseños e implementaciones de redes cableadas e inalám-
bricas, por lo que debe conocer los medios disponibles para
la transmisión de datos, sus características, equipos y todos
los conceptos relacionados con esta temática. En la presente
cartilla encontrará la fundamentación teórica relacionada con
la implementación de redes cableadas e inalámbricas, que le
permitirá tener las bases suficientes para enfrentarse a un di-
seño de red en la vida practica.

54
U3 Metodología


inteligentemente.

Fundación
Universitaria del
del Área
Área Andina
Andina 55
4
Diseño orientado a objetos de sis- y la comunicación con otros objetos se hace

a través del envío de parámetros
temas de software
Operaciones: métodos o servicios. Se refiere
Un objeto se compone de datos y procedi-
a las acciones que puede realizar el objeto.
mientos que representan una entidad. Para Estas pueden cambiar las propiedades de
el objeto también se define las diferentes los objetos o iniciar un evento con nueva in-
formas de interacción con otros objetos, lo formación para otro objeto del sistema.
que comúnmente se la llama la “Interfaz del
objeto”. Mensajes: solicitudes hechas a objetos para
que ejecuten operaciones o procedimientos
Teniendo en cuenta lo anterior, el DOO se y devuelvan información. Cuando se envina
centra en la creación de objetos e interac- mensajes a un objeto que tiene una parte
ciones que estos tienen entre si y que permi- privada, se está ocultando la información y
ten cumplir las funciones establecidas para los detalles de implementación del objeto,
un sistema. De esta forma la información y ya que el único acceso son los datos que se
el procesamiento se modularizan, permi- le envían al objeto y el resultado que este
tiendo incluir las tres características en las devuelve a quien le envío el mensaje.
que se basa cualquier método de diseño:
Abstracción, Ocultamiento de información Metodologías de desarrollo de software
y Modularidad.
OOHDM
Conceptos del diseño orientado a obje- OOHDM - Object Oriented Hypermedia De-
tos sign Method.
Esta enfocada al desarrollo hipermedia y
Objetos, operaciones y mensajes web.
Objeto: es la asociación de un elemento del El proceso de desarrollo se centra en 4 fases:
mundo real con su rol dentro del software. Modelado conceptual.
Por ejemplo; en un sistema de pedidos, un Diseño navegacional.
Diseño abstracto de interfaz.
objeto podría ser el usuario, el administra-
Implementación.
dor o un elemento de información.
Estas actividades se realizan en una mezcla
Los objetos encapsulan su estado y la forma de estilo incremental, iterativo y basado en
en que están representando la información prototipos de desarrollo.
Fundación
Universitaria del
del Área
Área Andina 56
Andina 5
Los modelos orientados a objetos se cons- como técnica de elicitación y definición de
truyen en cada paso que mejora los mode- requisitos, mediante la utilización de DFD.
los diseñados en iteraciones anteriores y Enfocado a aplicaciones web.
consta de las siguientes fases: La siguiente imagen muestra las fases que
sigue la metodología SOHDM:
Fase Conceptual. Construcción de esquema
conceptual, el cual se representa por obje-
tos, relaciones y colaboraciones entre ellos.
El esquema conceptual se constituye de cla-
ses, relaciones y subsistemas.
Fase Navegacional. Centrada en establecer

los modelos de navegación del sistema y se
expresa por un lado mediante Clases nave-
gacionales: Nodos, enlaces y estructuras de
acceso y por el otro, mediante el esquema
de contextos navegacionales, que es un
conjunto de nodos, enlaces, clases de con-
textos, y otros contextos navegacionales
(contextos anidados), los cuales se definen
por comprensión o extensión, o por enume-
ración de sus miembros.
Fase de Diseño de interfaz abstracta. Define

los objetos de interfaz con los que el usuario
va a interactuar, cuáles de estos objetos van
a intervenir en los procesos de navegación y
como se va a llevar a cabo la sincronización
de los objetos multimedia y el interfaz.
Fase de Implementación. Los modelos se

llevan a lenguaje de programación, con el
fin de obtener el ejecutable de la aplicación.
Utilizando las herramientas y Mecanismos Imagen 1
que ofrece el lenguaje de programación se- Fuente: Propia.
leccionado.
WSDM
SOHDM ■ Método de Diseño para Sitios Web (Web
Diseño en Escenarios Orientados a Objetos Site Design Method).
en Hipermedia (Scenario - based Object- ■ El usuario hace parte del diseño de los
oriented Hypermedia Design Methodolo- objetos de información, de acuerdo a los
gy). La primera fase del ciclo de vida que requisitos de información para el sitio
comienza con la creación de los escenarios web.
Fundación
Universitaria del
del Área
Área Andina
Andina 57
6
■ El diseño Navegacional se cimenta en 3 ■ Usada principalmente para proyectos
capas: Contexto, Navegación e Informa- web.
ción.
Las fases de la metodología WSDM se pre-

sentan a continuación:
Imagen 2 Imagen 3
Fuente: Propia. Fuente: Propia.
RNA UML
■ Relationalship Navigational Analisys o ■ UML - Unified Modeling Language, es
Método de Análisis de navegación rela- un lenguaje grafico para hacer modelos
cional. independientemente de los métodos de
■ Hace énfasis en las tareas de análisis de análisis y diseño.
entorno y elementos de interés en la fase ■ Permite representar, visualizar, especifi-
de especificación de requisitos. car, construir y documentar los elemen-
■ Los requisitos conceptuales s y navega- tos de un sistema de software, como el
cionales se analizan en forma indepen- diseño, comportamiento, arquitectura,
diente. etc.
Fundación
Universitaria del
del Área
Área Andina
Andina 58
7
UML sigue las siguientes fases: Vista de componentes: muestra cómo están
organizados los componentes de código.
Vista concurrente: muestra los aspectos de

comunicación y sincronización.
Vista de distribución: muestra la arquitectu-

ra física del sistema.
Las partes que componen el UML son:

■ Las vistas.
■ Los diagramas.
■ Los elementos del modelo.
■ Lo mecanismos de extensión.
NOTA: esta metodología será tratada con
más detalle en la semana 6.
Modelos de proceso y ciclos de vida.

Modelo fuente.
Permite el desarrollo de sistemas en forma
iterativa y encapsulada.
Las etapas que sigue son las siguientes:

1. Planificación: es independiente de la
metodología orientada a objetos
Imagen 4 2. Construcción: esta se divide en: Plani-
Fuente: Propia. ficación, Investigación, Especificación,
Implementación y Revisión
UML maneja el concepto de vistas, enten- 3. Entrega: es independiente de la meto-
dida como un conjunto de diagramas que dología orientada a objetos.
juntos muestran las funcionalidades del sis-
tema. Las vistas que maneja UML son: Estas fases se desarrollan en 2 periodos de-
finidos que son:
Vista use-case: muestra las funcionalidades
desde el punto de vista de actores externos.
• Crecimiento: tiempo durante el cual
se hace el diseño del sistema.
Vista lógica: muestra el diseño de funcionali- • Madurez: tiempo durante el cual se
dad interna del sistema, teniendo en cuenta desarrollan las actividades de mante-
su estructura estática y conducta dinámica. nimiento y mejora del producto.

La siguiente grafica muestra el ciclo de vida que sigue el Modelo Fuente:
Imagen 5
Fuente: http://3.bp.blogspot.com/-ys_bK8WaRrA/T61OUjmFm1I/AAAAAAAAALo/DlQBW-8QZio/s1600/
Orientado+a+Objetos.png
Modelo de agrupamiento
■ El conjunto de clases son separadas de acuerdo al objetivo para la cual fueron creadas,
formando así diferentes clúster de clases.
■ Cada clúster tiene sus propios subciclos de vida que pueden anidarse durante el periodo
de desarrollo. Todos los subciclos de vida siguen las mismas fases: Especificación, Diseño,
Implementación, Verificación/Validación y Generalización.
La siguiente imagen representa como es la agrupación en el modelo de agrupamiento:
Imagen 6
Fuente: Propia.

60
Modelo remolino dos estilos diferentes: El primero es el Modo
Maneja el concepto de dimensiones, las Seguro, que es usando tecnologías y méto-
cuales pueden organizarse en forma dife- dos que ya han sido probados y el segundo,
rente, de acuerdo a las necesidades y tipo el Método Limite, que es aventurarse a utili-
de proyecto las cuales se relacionan a con- zar nuevas tecnologías y métodos.
tinuación: La pelota siempre va a estar moviéndose
entre los obstáculos por lo que el paso de
los mismos se hace en forma iterativa y está
en la Habilidad del equipo de desarrollo so-
brepasarlos correctamente y en el menor
tiempo posible.
La siguiente imagen muestra como seria la

implementación del método Pinball:
Figura 1
Fuente: Propia.
Modelo pinball
Relaciona el juego de Pinball con la forma
en que se desarrolla el proyecto. Quien jue-
ga es el Equipo de desarrollo, la pelota es el
Proyecto y los obstáculos a sobrepasar son
las clases, atributos, métodos, relaciones,
colaboraciones, herencias, agregaciones y
sub-sistemas. Estos obstáculos se pueden
sobrepasar en cualquier orden, lo importan-
te es sobrepasarlos correctamente.
Sobrepasando poco a poco los primeros

obstáculos, el jugador se aproxima a la par-
te final del juego, que son las fases de pro- Imagen 7
gramación y pruebas. Para jugar se plantean Fuente: Propia.
del Área
Área Andina
Andina 61
10
Metodologías ágiles ■ Proyectos en los que se requiere de altos
grados de innovación, competitividad,
Scrum flexibilidad y productividad.
■ Para cuando se requieren productos fina- ■ Cuando se ha extendido demasiado el
les en plazos cortos de desarrollo. tiempo de entrega del producto final, se
han generado altos costos de desarrollo
■ Cuando los requisitos del proyecto cam- y la calidad no es la que se esperaba.
bian regularmente. ■ El equipo trabaja en forma colaborativa
para minimizar riesgos.
■ Cuando se quieren tener equipos de tra-
bajo. El proceso Scrum se muestra a continuación:
Imagen 8
Fuente: https://scrumenespanol.files.wordpress.com/2015/09/diagrama-proceso-scrum.gif?w=553&h=414
del Área
Área Andina
Andina 62
11
La siguiente tabla muestra un resumen de los roles que existen en Scrum:
Roles principales
Product Owner Representa el punto de vista del cliente.
ScrumMaster Asegurar que el proceso de desarrollo se lleve a cabo sin distracciones
(o facilitador) y bajo los parámetros, reglas y condiciones establecidos.
Su fin es el de entregar el producto final.
Equipo de desarrollo Equipo interdisciplinario con habilidades de análisis, diseño, desarrollo,
pruebas, documentación, etc.
Roles secundarios
Administradores
Establece las condiciones de ambiente de trabajo para el desarrollo.
(managers)
Stakeholders Involucrados alrededor del proyecto: Clientes, Proveedores, Vendedores, etc.
Tabla 1
Fuente: Propia.
RAD
RAD (Rapid Application Development) o Desarrollo Rápido de Aplicaciones, comprende el
desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE, a usabilidad,
utilidad y la rapidez de ejecución. Se enfoca a que el ciclo de vida del desarrollo sea lo más
corto posible.
del Área
Área Andina
Andina 63
12
La siguientes son las fases que sigue la metodología RAD:
Imagen 9
Fuente: Propia.
Dentro de las características principales se Hace uso de herramientas especializadas:

puede señalar: Por ejemplo para crear prototipos, multilen-
guaje, herramientas colaborativas, librerías,
Se compone de equipos híbridos: normal- Apis, Calendario de trabajo, etc.
mente lo conformas 6 personas. Cada desa- Timeboxing: todo lo que no sea esencial se
rrollador debe tener capacidades de analis- elimina con el fin de cumplir el calendario
ta, diseñador y programador. propuesto.

64
Prototipos Iterativos. Se hacen reuniones requisitos. De ahí en adelante se realizar
JAD (Join Application Development), don- iteraciones hasta finalizar el producto, si-
de se reúne el cliente y desarrolladores, guiendo el esquema que se muestra a con-
a fin de generar el documento inicial de tinuación:
Imagen 10
Fuente: Propia.
Extreme Programming (XP) Comunicación: preguntas y contra pregun-

tas que permitan determinar las caracterís-
Centrada en resaltar las relaciones interper-
ticas del sistema finalizado.
sonales como base fundamental para el tra-
bajo de desarrollo. Coraje: para exponer dudas, miedos y expe-
riencias. Un equipo de desarrollo extremo
Promueve el trabajo en equipo. se basa en la confianza hacia sus miembros.
Apoya el aprendizaje de los integrantes del Simplicidad: para mantener el software lo
equipo de desarrollo. más sencillo posible.
Busca crear un buen clima de trabajo. Feedback: capacidad de respuesta ante

cambios del proyecto, tomando las retroa-
La metodología XP se fundamenta en los si- limentaciones del cliente, miembros del
guientes elementos: equipo y el entorno.
del Área
Área Andina
Andina 65
14
Un proyecto XP sigue el siguiente Ciclo de vida:
Imagen 11
Fuente: Propia.
KANBAN • Limitar y establecer metas de trabajo

■ Palabra japonesa que significa “tarjetas en proceso.
visuales”. Kan= visual, y Ban=tarjeta. • Realizar un seguimiento del tiempo
■ Su objetivo es gestionar la forma en que dedicado a cada actividad.
se van completando las tareas laborales a • Lectura de indicadores visuales.
fin de mejorar su fluidez.
• Identificar cuellos de botella y buscar
■ Se utiliza una tarjeta Kanban para visua- alternativas.
lizar las tareas durante el flujo de trabajo.
• Garantizar la calidad, mas no la rapi-
Principios básicos de KABAN: dez.
• Visualizar las tareas propias de su tra- • Continuo mejoramiento.

bajo. • Flexibilidad de acuerdo a necesidades.
del Área
Área Andina
Andina 66
15
La siguiente imagen muestra como se implementa en forma practica la metodología Kan-
Ban:
Imagen 12
Fuente: http://www.snl19.es/wp-content/uploads/Tablero-kanban-izenius.jpg.png
A continuación se presentan los pasos a se- 2. Visualizar las fases del ciclo de producción:
guir para crear una estrategia KanBan.
• Dividir el trabajo en distintas partes
1. Definir el flujo de trabajo de los proyec- como en el desarrollo incremental.
tos:
• Cada parte se escribe en un post-it y
Cada columna corresponde a un esta- se pega en la fase que corresponda.
do de la tarea de acuerdo al proyecto,
por ejemplo: Sin iniciar, en espera, en • Se busca que queden totalmente cla-
desarrollo, en pruebas diagnóstico, de- ras las tareas asignadas a cada perso-
finición, programación, ejecución, fina- na del equipo de trabajo, las priorida-
lizado, etc. des y metas asignadas.
del Área
Área Andina
Andina 67
16
3. “Stop Starting, start finishing”
• Este es el lema de KanBan.
• Priorizar el trabajo en curso en lugar
de iniciar nuevas tareas.
• Deben existir un número máximo de
tareas en curso y para cada fase.
• No se puede abrir otra tarea sin finali-
zar alguna que se encuentre en curso.
4. Control de flujo
• Para hacer seguimiento al trabajo
realizado.
• Mantener al equipo con un flujo de
trabajo constante.
• Mantener las Tareas importantes en
cola para su desarrollo.
• Seguimiento pasivo para evitar la in-
terrupción al trabajo que está desa-
rrollando cada integrante.
Las anteriores son algunas de las metodo-
logías agiles que existen, la invitación es a
investigar otras metodologías como:
■ DSDM
■ MODELADOAGIL
■ LEANDEVELOP
■ CRYSTALMETHOD
del Área
Área Andina
Andina 68
17
1
UNIDAD
3Unidad 3
Modelado de
procesos Ingeniería de software

Introducción El Ingeniero de sistemas debe conocer los modelos sobre los
cuales se implementan las redes de comunicación, así como
también las normas que rigen estas implementaciones y com-
ponentes de hardware asociados.
En esta semana se abordarán los temas mencionados, para

que de esta manera el estudiante pueda tener la fundamenta-
ción necesaria que le permita afrontar situaciones de diseño
de redes e implementación del cableado estructurado que se
requiere para las mismas.
Fundación
Universitaria del
del Área
Área Andina
Andina 70
3
U3 Metodología


inteligentemente.

Aquellos que hayan llamado mi atención negativamente por su falta de participación o por
lo inadecuado de las mismas les enviaré un mensaje privado.

71
Modelado de procesos UML maneja el concepto de vistas, enten-

dida como un conjunto de diagramas que
juntos muestran las funcionalidades del sis-
Conceptos de modelado
tema. Las vistas que maneja UML son:
Modelo: representación de un sistema y las ■ Vista use-case: muestra las funcionalida-
tareas que este realiza, de forma tal que sea des desde el punto de vista de actores
lo más aproximadamente posible con la externos.
realidad del mismo. Cuando se modela un
proceso mediante una representación grafi-
■ Vista lógica. muestra el diseño de funcio-
nalidad interna del sistema, teniendo en
ca, se denomina “diagrama de proceso” y de cuenta su estructura estática y conducta
esta forma se puede diferenciar claramente dinámica.
las interrelaciones, actividades, subproce-
sos y problemas que podrían existir.
■ Vista de componentes: muestra cómo
están organizados los componentes de
Diagramado: tomar los procesos y subpro- código.
cesos y establecerles una representación vi- ■ Vista concurrente: muestra los aspectos
sual, de tal forma que se pueda conocer sus de comunicación y sincronización.
características tales como, tamaño, tiempos ■ Vista de distribución: muestra la arqui-
de ejecución, actividades, etc. tectura física del sistema.
Dominio: contexto en el cual se genera y Importancia del modelado UML

desenvuelve un problema.
Facilita la intercomunicación entre analistas,
diseñadores, especialistas y programadores
El Modelo UML del proyecto; ya que UML posee más carac-
■ UML - Unified Modeling Language, es terísticas visuales que de programación, de
un lenguaje grafico para hacer modelos tal forma que todos pueden participar en el
independientemente de los métodos de diseño y análisis del sistema.
análisis y diseño.
El diseño y análisis se realiza de forma in-
■ Permite representar, visualizar, especifi- dependiente al lenguaje de programación
car, construir y documentar los elemen- que se utilice para desarrollo del sistema y
tos de un sistema de software, como el se puede establecer los requerimientos y
diseño, comportamiento, arquitectura, estructuras, antes de los procesos de codi-
etc. ficación.

72
Al utilizar como base un diseño visual del permiten hacer una representación de la
sistema, es más fácil detectar las relaciones, arquitectura general del proyecto.
dependencias y problemas que se podrían ■ Utiliza diferentes niveles de abstracción
generar en los procesos del mismo. Realizar para hacer la descripción de un sistema,
cambios en la etapa de análisis es más fácil de tal forma que el equipo de trabajo
que hacerlos en etapas avanzadas del desa- puede comprender de forma clara y deta-
rrollo. llada las características de dicho sistema.
Características principales
■ No es un modelo estándar para el desa-
rrollo, sino un lenguaje de modelado.
■ Utiliza la notación orientada a objetos.
■ Los procesos de desarrollo se especifican
■ Se basa en las especificaciones BOOCH, de acuerdo al dominio y contexto del
RUMBAUGH y COAD-YOURDON. proyecto de software.
■ Cada proyecto es dividido en igual nú- ■ Desarrollado para representar, visualizar,
mero de diagrama, los cuales que repre- especificar, construir y documentar los
sentan las diferentes vistas y en conjunto elementos de un sistema de software.
Ventajas e inconvenientes
Ventajas Desventajas
• Se puede utilizar para diferentes tipos de • Limitado al modelamiento y no puede
sistemas. usarse como un método de desarrollo.
• Al utilizar modelado visual, facilita su com- • Se requiere adicionalmente de una meto-
prensión. dología orientada a objetos.
• Útil en el modelado visual de cualquier • Hace uso de notaciones y conceptos de la
proyecto, independientemente si es de metodología orientada a objetos, por lo
software o no. que quien no ha tenido experiencia previa
• Promueve la reutilización. no le será fácil aprenderlo.
• Mejora los tiempos de desarrollo, al poder • No funciona en el diseño de sistemas
clarificar cada tarea de los actores que distribuidos.
intervienen en el sistema. • En la documentación, hacen falta muchos
• Permite el escalamiento en sistemas com- más ejemplos que sirvan de guía para el
plejos. usuario.
• Mejora la planeación y control del proyec- • Tiene fallos respecto a las necesidades de
to de software. especificación del proyecto.
• Hace énfasis en la reutilización y minimiza- • No se define la documentación ni el dise-
ción de costos. ño de interfaces de usuario.
Cuadro 1
Fuente: Propia.
Fundación
Universitaria del
del Área
Área Andina
Andina 73
6
Objetivos de UML ■ Los atributos y métodos se definen utili-
■ Ser independiente del lenguaje de pro- zando la siguiente sintaxis: Nombre_Atri-
gramación utilizado en el proceso de de- buto / Método: Tipo_Dato.
sarrollo. ■ Los parámetros se definen en forma simi-
■ Brindar la información de notaciones y lar: Nombre parámetro: Tipo de dato.
semánticas que permitan abarcar el ma-
yor numero de aspectos del modelado A continuación se muestra como se imple-
orientado a objetos, teniendo hacia don- menta una clase teniendo en cuenta las re-
de apunta el desarrollo de software. glas antes mencionadas:
■ Brindar extensiones que permitan a los

proyectos implementar el meta-modelo
a un bajo costo y desarrollar futuras for-
mas de modelado utilizando como ase
UML.
■ Simplificar al máximo la forma de uso,
manteniendo las capacidades que per-
mitan hacer el modelamiento de diferen-
tes tipos de sistemas.
■ Convertir el lenguaje UML en un lenguaje
universal y en un estándar mundial.
■ Proporcionar las herramientas suficien- Imagen 1
tes que permitan migrar las interfaces a Fuente: Propia.
bibliotecas o API, con el fin de utilizarlas
en procesos de comparación y almacena-
miento de componentes del modelo. Relaciones binarias
Modelo UML de un sistema ■ Se establecen entre clases y objetos.
En UML se utiliza el Modelo Estático, el cual ■ Se representan mediante una línea recta
representa las clases, objetos y relaciones indicando el nombre de la relación.
de un sistema, mediante “diagrama de cla- ■ En los extremos de la línea se indica al-
ses” y “diagrama de objetos. guno de los siguientes tipos de multipli-
cidad:
Diagrama de clases. Para definir una clase se
siguen las siguientes reglas: • Uno a muchos (1 - *).
■ La nomenclatura para niveles de acceso • Uno a Uno (1 – 1).

de métodos y atributos es la siguiente: • Uno a Cero o Uno (1 – 0..1).
+ (Publico) • Uno a Cero o Muchos (1 – 0..*).
# (Protegido) • Uno a Uno o Muchos (1 – 1..*).
- (Privado) • Muchos a Muchos (* - *).
Fundación
Universitaria del
del Área
Área Andina
Andina 74
7
Teniendo en cuenta las nomas anteriores, la implementación de las relaciones binarias se
indica a continuación:
Imagen 2
Fuente: Propia.
Los otros tipos de relaciones se indican en el numeral 1.5 Relaciones
La siguiente imagen muestra un diagrama de clases para una biblioteca:
Imagen 3
Fuente: http://goo.gl/IXc1Ff
Fundación
Universitaria del
del Área
Área Andina
Andina 75
8
Diagrama de objetos • Se usan para probar la precisión de
• Es una instancia de un diagrama de los diagramas de clases
clases.
• Ayudan a explicar clases y heren-
• Describen la estructura estática de
cia
un sistema.
• Incluye los objetos y los valores de • Un objeto se define de la siguiente
sus datos. forma:
Nombre_Objeto: Nombre_clase
___________________________ :______________
Nombre_clase
Atributo1 = valor1 Atributo1: valor1

Atributo2 =valor2 Atributo2: valor2
Atributo3 = valor3 Atributo3: valor3
Cuadro 2
Fuente: Propia.
■ Los atributos siempre llevaran un valor ■ El nombre y clase siempre van subraya-
asignado. dos.
Imagen 3
Fuente: http://goo.gl/TdnSd5
Fundación
Universitaria del
del Área
Área Andina
Andina 76
9
Para revisar el proceso de modelamiento http://es.slideshare.net/RafaelDiaz12/mo-
de un sistema, se recomienda visitar los delado-uml-de-sistema-punto-venta
siguientes links: Bloques de construcción

La siguiente tabla resume los elementos
https://msdn.microsoft.com/es-es/library/ que componen las 3 áreas de los bloques de
bb972214.aspx construcción usados en UML:
Bloques de construcción
Elementos Relaciones Diagramas
Clases
Objetos
Casos de uso
Estructurales Dependencia
Secuencia
Comportamiento Asociación
Colaboración
Agrupación Generalización
Estados
Anotación Realización
Actividades
Componentes
Despliegue
Cuadro 3
Fuente: Propia.
A continuación se hace una descripción de cada uno de los elementos relacionados.
Elementos estructurales
Parte estática de los modelos UML y representan elementos conceptuales o materiales. Se
compone de 7 elementos:
Clases. Descripción de varios objetos que tienen los mismos atributos, operaciones, relacio-
nes y semántica. Su representación grafica es la siguiente:
Imagen 4
Fuente: Propia.
del Área
Área Andina
Andina 77
10
Interfaces. Colección de operaciones y sus especificaciones, relacionadas a un servicio de
una clase. Su representación grafica es la siguiente:
Imagen 5
Fuente: Propia.
Colaboraciones. Definen las interacciones de roles y otros elementos de las clases y en con-
junto generan un comportamiento mayor. Una clase puede estar en varias colaboraciones.
Imagen 6
Fuente: Propia, basado en http://goo.gl/TpKc9K
Casos de uso. Descripción de las diferentes secuencias que un actor realiza dentro de un sis-
tema, las cuales generan un resultado observable y de interés para el actor. Los casos de uso
se realizan por una Colaboración y se representan gráficamente por una elipse.
del Área
Área Andina
Andina 78
11
Imagen 7
Fuente: http://goo.gl/op5lCw
Clases activas. Clase en la cual los objetos otros elementos de otros objetos. Gráfica-
tienen uno o más Hilos de ejecución, que mente es la misma que una clase, pero con
pueden iniciar actividades de control con líneas más gruesas.
Imagen 8
Fuente: Propia.
del Área
Área Andina
Andina 79
12
Componentes. Representa el empaquetamiento físico de clases, interfaces, códigos fuentes
y colaboraciones, como por ejemplo; COM+ o JavaBeans. Su representación física es la si-
guiente:
Imagen 9
Fuente: Propia.
Nodos. Representa un recurso computacional que tiene capacidad de procesamiento de in-

formación. Su representación grafica es un cubo.
Imagen 10
Fuente: http://www.monografias.com/trabajos28/proyecto-uml/Image305.gif
del Área
Área Andina
Andina 80
13
Elementos de comportamiento
Son los diferentes mensajes, secuencias

de acción y enlaces, que intercambian los
Interacciones Nombre de la Interacción
diferentes objetos de un sistema, con el
objetivo de cumplir una tarea específica.
Representa los diferentes estados por que

Maquina de
pasa un objeto o una interacción ,como
estados
respuesta a un evento.
Cuadro 4
Fuente: Propia.
A continuación se muestra un diagrama que muestra los diferentes estados de un proceso y

sus interacciones.
Imagen 11
Fuente: http://goo.gl/0Tn7CJ
del Área
Área Andina
Andina 81
14
Elementos de agrupación
Paquete. Permite organizar en grupos, los elementos estructurales, de comportamiento u
otros paquetes. Su representacion grafica es la siguiente:
Imagen 12
Fuente: Propia.
Elementos de anotación
Notas. Se utiliza para mostrar restricciones o comentarios de un elemento o colección de
elementos. Su representación grafica es la siguiente:
Imagen 13
Fuente: Propia.
del Área
Área Andina
Andina 82
15
Relaciones
Tipo Descripción Representación
Relación entre dos elementos en la cual cualquier

Dependencia cambio en el elemento independiente puede
afectar al elemento dependiente.
Relación de tipo estructural, que describe las Asociación

conexiones entre objetos. Un tipo especial de
Asociación
asociación es la agregación, que representa la
relación entre un todo y sus partes. Agregación
Los objetos de un elemento especializado (hijo),

pueden sustituir a los objetos del elemento gene-
Generalización
ral (padre).Tanto hijo como padre, comparten la
estructura y comportamiento.
Acciones entre Interfaces/Clases y componentes

Realización que las ejecutan o entre. casos de uso y las cola-
boraciones que las ejecutan.
Cuadro 5
Fuente: Propia.
del Área
Área Andina
Andina 83
16
Diagramas estructurales y de comportamiento
Área Vista Diagramas Conceptos Uso

Clase, asociación, gene-
De Modelar la estructura estática
ralización, interfaz
clases de las clases.
Vista dependencia, realización.
lógica Casos de uso, actor,
E De casos Modelar los procesos de
asociación, extensión,
s de uso negocio.
generalización.
t
a
t
i De Componente, interfaz, Modelar componentes del
c Vista componentes dependencia, realización. sistema.
a física
De Nodo, componente, de- Modelar la distribución del

implementación pendencia, realización. sistema.
Estado, evento, Modelar el comportamiento

De
transición, acción. de los objetos.
D Vista estados
i lógica Estado, actividad, tran- Modelar el comportamiento
n De sición, determinación, de los casos de uso, objetos u
a actividad división, unión. operaciones.
m
i De Interacción, objeto, men- Modelar el paso de mensajes
c Vista secuencia saje, activación. entre objetos.
a física Colaboración, interac- Modelar interacciones entre
De colaboración
ción, rol, mensaje. objetos.
Cuadro 6
Fuente: Propia.
del Área
Área Andina
Andina 84
17
Mecanismos comunes
Especificaciones
Permite explicar la sintaxis y semántica cada elemento del sistema, como por ejemplo; la
información de operaciones, atributos, comportamiento y signaturas.
Imagen 14
Fuente: http://goo.gl/Xohpny
Adornos
Representa los detalles adicionales de un elemento, por ejemplo el tipo de clase, si los atri-
butos y operaciones son visibles o no, tipos de datos de los atributos, etc.
Imagen 15
Fuente: http://goo.gl/Xohpny

Divisiones comunes ■ Nombres: como identificar los elemen-
tos, relaciones y diagramas.
Mecanismos de extensibilidad
■ Alcance: contexto que le da el significado
Permiten ampliar el lenguaje UML, utilizan- a un nombre.
do alguno de los siguientes perfiles:
■ Visibilidad: la forma en que se pueden
■ Estereotipos: añadir nuevos bloques de ver y utilizar los nombres.
construccional.
■ Integridad: relación apropiada y consis-
■ Valores etiquetados: modificar o caracte- tente entre los elementos.
rizar la especificación de los nuevos blo-
ques de construcción.
■ Ejecución: como se llevan a cabo los pro-
cesos.
■ Restricciones: añadir nuevas reglas o mo-
dificar las existentes. Vistas arquitecturales
El modelo 4+1 fue diseñado por Philippe
Reglas
Kruchten para “describir la arquitectura de
Se refieren a cómo pueden combinarse los sistemas software, basados en el uso de
elementos, relaciones y diagramas. Estas se múltiples vistas concurrentes”. La siguiente
agrupan de la siguiente manera: imagen muestra la estructura del modelo:
Imagen 16
Fuente: https://goo.gl/Uk2tKf
del Área
Área Andina
Andina 86
19
Se dividen en físicas y Lógicas, como se muestra en el siguiente diagrama:
Figura 1
Fuente: Propia.
del Área
Área Andina
Andina 87
20
1
UNIDAD
4Unidad 4
Conceptos de
seguridad Ingeniería de software

Es importante conocer las líneas de equipos y terminales que
Introducción fabrican las diferentes empresas desarrolladoras de hardware
en telecomunicaciones, a fin de tener un concepto global al
momento de realizar una implementación de un sistema de
comunicaciones, hardware, etc.
Esta cartilla presenta un resumen de los equipos fabricados

las marcas Intel, AMD, Motorola e IBM.El documento se enfoca
por un lado a presentar una breve descripción de cada empre-
sa y relacionar principalmente las últimas líneas de equipos
fabricados en las áreas computación, telefonía móvil o comu-
nicaciones, en base a cada empresa.
Fundación
Universitaria del
del Área
Área Andina
Andina 89
3
U4 Metodología


comiendo la asistencia diaria para aprovechar al máximo el curso.

Se realizará una teleconferencia semanal de un tema especifico, en el cual se presentarán

ejemplos para ampliar la temática semanal.
En cada semana se publica el material de estudio que apoyara el desarrollo de los conteni-
dos temáticos correspondientes a dicha semana, ya sea en recursos bibliográficos, archivos
digitales o referencias electrónicas (páginas WEB).
Fundación
Universitaria del
del Área
Área Andina 90
Andina 4
Conceptos de seguridad
Bien informático Elementos que componen un sistema informático.

Sistema informático Conjunto de bienes informáticos que ejecutan unas tareas específicas.
Amenaza Posible riesgo que puede causar daño a un bien informático.
Riesgo Probabilidad que una amenaza se materialice.
Proceso que permite determinar vulnerabilidades de un sistema, las
Análisis de riesgo
posibles amenazas y su probabilidad de ocurrencia e impacto.
Riesgo después de haber implementado controles de seguridad para
Riesgo residual
minimizarlo.
Impacto Daño producido o causado por una amenaza.
Seguridad Minimizar los riesgos de un bien informático a niveles adecuados.
Debilidades o aspectos atacables de un sistema informático y que per-
Vulnerabilidad
miten calificar el nivel de riesgo.
Cuadro 1
Fuente: Propia.
Propiedades del software seguro Disponibilidad: debe estar con total funcio-
nalidad y accesibilidad para usuarios auto-
Propiedades fundamentales rizados en el momento que lo requieran y
que puedan realizar en forma corecta las ta-
Confidencialidad: debe asegurar que sus ca-
racterísticas, contenidos, datos solo puedan reas para las cuales fue desarrollado:
ser accedidos por para usuarios autorizados.
Responsabilización (accountability): regis-
Integridad: debe ser resistente y flexible a tro y trazabilidad de acciones relacionadas
modificaciones no autorizadas del código, con la seguridad del software, que debe de-
configuraciones, ajustes por parte de usua- sarrollar una entidad usuario, a fin de esta-
rios autorizados. blecer responsabilidades y seguimientos.
Fundación
Universitaria del
del Área
Área Andina
Andina 91
5
No repudio. habilidad para evitar que las en- Protección: si el sistema sufre alguna falla o
tidades usuario de un software, no asuman ataque debe funcionar parcialmente o en
la responsabilidad de acciones que han sido modo seguro para evitar pérdidas humanas,
ejecutadas sobre el mismo, de tal forma que de activos, medio ambiente, etc.
no se pueda eludir la propiedad responsabi-
lización (accountability). Metodologías vigentes
Propiedades conducentes Correctness by Construction (CbyC)

Dependability: asegura que el software Conceptos
siempre funcionara sin defectos y debilida-
Para cuando se requiere de niveles críticos
des
de seguridad y que además se puedan de-
Correcto: operar incluso en aquellas condi- mostrar. Busca minimizar el nivel de defec-
ciones en las que se presenta un ataque. De- tos y una alta resistencia al cambio. Esto se
ben especificarse requerimientos de com- logra bajo los siguientes principios:
portamiento seguro, para garantizar que un Que los errores sean difíciles de introducir
software correcto sea seguro. en el software.
Predecible: el software siempre ejecutara Que si dichos errores se han inyectado, estos
las operaciones implementadas bajos las deben removerse los más pronto posible.
condiciones de ambiente, entradas sobre
las cuales fue diseñado. Generar pruebas de aptitud como un sub-
producto del proceso y de esta forma usar-
Confiable: la ejecución debe ser predecible las en todo el desarrollo.
y correcta, aun cuando existan defectos no
intencionales, debilidades o cambios en el Lo anterior se logra a través del desarrollo
ambiente en el cual se ejecuta. de las siguientes actividades:
1 • Planificación de los procesos
2 • Capacitación del personal y de competencias

3 • Trazabilidad de los requisitos desde la especificación de casos de código de pruebas
4 • Gestión de fallos
5 • Gestión de cambio
6 • Gestión de la configuración
7 • Recolección de métricas
Figura 1
Fuente: Propia.
Fundación
Universitaria del
del Área
Área Andina
Andina 92
6
Para el desarrollo de las actividades plan- ■ Se evita al máximo la repetición de requi-
teadas, se utilizan las técnicas que se rela- sitos ambiguos.
cionan a continuación: ■ Simplificar al máximo las cosas, para que
sea fácil su revisión y desarrollo.
■ Se hacen notas de audio para disminuir
ambigüedades en la especificación de
■ Hacer una gestión adecuada de los ries-
gos para poder tener una mejor respues-
requisitos. ta ante las situaciones.
■ Se hace una estricta validación de los ■ Tener un pensamiento fuerte enfocado a
productos que se entregan en cada eta- lograr los objetivos.
pa de desarrollo.
Fases de CbyC
■ Se utiliza el desarrollo incremental. Cada La siguiente figura muestra el proceso de
código escrito se debe ir verificando. desarrollo que en sigue en CbyC:
Imagen 1
Fuente: Propia.
Fase de requerimientos especificar requerimientos no funciona-

■ Especificar el propósito, funciones, reque- les de protección y seguridad.
rimientos no funcionales, requerimientos Fase de especificación del software
de usuario con diagramas contextuales,
de clase y definiciones operativas. ■ Documentar especificaciones de interfaz
de usuario, documentar especificaciones
■ Pasar los requerimientos por un proceso de niveles superiores, desarrollar un pro-
de trazabilidad y requerimiento de segu- totipo para validación.
ridad a la amenaza correspondiente.
Fase de diseño detallado
Fase de diseño de alto nivel
■ Definir los módulos y procesos con sus
■ Definir estructura interna del sistema: funcionalidades usando notación formal
funcionalidades, bases de datos, transac- para evitar ambigüedades de interpreta-
ciones, comunicaciones, interacciones y ción en el diseño.
Fundación
Universitaria del
del Área
Área Andina
Andina 93
7
Fase de especificación de los módulos Security Development Lifecycle (SDL)
■ Definir estado y comportamiento encap- Conceptos
sulado de los módulos definidos en la ■ Propuesto por Microsoft en 2004.
etapa anterior, según el flujo de informa-
■ 16 actividades enfocadas a mejorar la se-
ción, con el enfoque de bajo acoplamien- guridad del desarrollo de un producto de
to y alta cohesión. software.
Fase codificación ■ Se realiza un modelado de amenazas con
el fin que los desarrolladores puedan en-
■ Aplicar el lenguaje SPARK 1
en partes criti-
contrar código vulnerable de ataques.
cas del sistema.
■ Realizar pruebas de análisis al código con Fases de la Metodología SDL
el fin de eliminar errores, así como su res- El proceso de desarrollo SDL plantea 2 op-
pectiva actualización. ciones:
Fase de las especificaciones de las pruebas Versión rígida

■ Efectuar pruebas de valores limites, de ■ Apropiada para equipos de desarrollo y
comportamiento, y de requerimientos proyectos grandes, que no cambien de-
no funcionales a nivel de sistema. masiado durante el proceso.
■ De acuerdo a especificaciones del soft- ■ Frecuencia de actividades para asegura-
ware, requerimientos y diseño de alto miento de calidad es más lenta.
nivel.
Orientada al desarrollo ágil
Fase de construcción del software ■ Usa como base el desarrollo incremental.
■ Se basa en el desarrollo ágil entregan- ■ Frecuencia de actividades para asegura-
do en una primera versión, el esqueleto miento de calidad es más rápida.
completo del sistema con interfaces, co-
■ Para desarrollos enfocados a la web.
municación; funcionalidad muy limitada
que aumenta con cada iteración del ciclo. En la siguiente figura se muestran las etapas
1 Lenguaje de programación diseñado para que sigue el proceso de desarrollo SDL y las
sistemas en los que se requiere alta integridad 16 actividades que se deben realizar.
Fundación
Universitaria del
del Área
Área Andina
Andina 94
8
Entrenamiento
• Entrenamiento de seguridad básica
Requerimientos • Establecer requerimientos de seguridad

• Crear umbrales de calidad y límite de errores
• Evaluación de los riesgos de calidad y privacidad
Diseño • Establecer requerimientos de diseño

• Análisis de la superficie de ataque
• Modelado de amenazas
Implementación • Utilizar herramientas apropiadas

• Prohibir funciones no seguras
• Análisis estático
Verificación • Análisis dinámico

• Fuzz testing
• Revisión de la superficie de ataques
Lanzamiento • Plan de respuesta a incidentes

• Revisión de seguridad final
• Aprobar y archivar lanzamiento
Respuesta
• Ejecutar el plan de respuesta a incidentes
Figura 2
Fuente: Propia.
Fundación
Universitaria del
del Área
Área Andina
Andina 95
9
Fase de entrenamiento: el equipo de de- guías de diseño en la cual queden identifi-
sarrollo debe recibir capacitación en con- cados los componentes vulnerables. Para
ceptos básicos y tendencias en el área de esto se utiliza el enfoque de privilegios mí-
seguridad y privacidad. El área técnica (de- nimos y la reducción del área de ataques. Se
sarrolladores, evaluadores y administrado- realiza un modelado de las posibles ame-
res de programas) debe recibir capacitación nazas componente por componente, esta-
(por lo menos una vez al año) en las siguien- bleciendo la probabilidad que ocurran y las
tes temáticas: medidas a tomar para minimizar ese riesgo.
■ Conceptos fundamentales de seguridad. Fase de implementación. codificar, probar
■ Mecanismos de defensa. e integrar el software, teniendo en cuenta
■ Principio de privilegios mínimos. el modelado de amenazas. Esto con el fin
de evitar inyección de fallas, detectar vul-
■ Modelos de riesgos. nerabilidades. Se aplican técnicas de Fuzz
■ Saturaciones de búfer. Testing, consistente en inyectar al software
datos al azar, inválidos y no esperados. Se
■ Inyección de código SQL. utilizan herramientas de escaneo de Micro-
■ Criptografía débil. soft.
■ Evaluación de riesgos. En el siguiente link podrá conocer algunas
■ Procedimientos de desarrollo de privaci- de estas herramientas:
dad.
http://www.caminogeek.com/lista-de-he-
Fase de requerimientos: un consultor de se- rramientas-de-seguridad-gratuita-de-mi-
guridad apoya al equipo de desarrollo en crosoft/
revisión de planes, generando recomenda-
ciones con el fin de cumplir metas de segu- Finalmente se hace una nueva revisión de
ridad propuestas. Adicional a esto, el equipo código con el fin de identificar vulnerabili-
de producción también debe: dades que no fueron detectadas por las he-
rramientas de escaneo.
■ Determinar la forma en que deberá inte-
grarse la seguridad en el proceso de de- Fase verificación: en esta fase ya se tiene un
sarrollo. software beta totalmente funcional. Lo que
■ Identificar los objetivos de seguridad. se busca es revisar exhaustivamente el có-
digo y ejecutar pruebas en aquellas partes
■ Identificar la forma que se integrará el del software que habían sido identificadas
software en conjunto. como vulnerables.
■ Verificarán que sean incluidos todos los
requerimientos de seguridad. Fase de lanzamiento: se hace una revisión fi-
nal para saber el nivel de seguridad del pro-
Fase de diseño: identificar requerimientos ducto y nivel de probabilidad de soportar
y la estructura que llevara el software. Se ataques, una vez que se libere al cliente. Si
identifican los requerimientos y una arqui- se encuentran vulnerabilidades, se regresa a
tectura segura del software, también unas la fase anterior hasta solucionar estas fallas.
del Área
Área Andina
Andina 96
10
Fase de respuesta: debido a que no es po- vulnerabilidades, y software de última
sible entregar un software 100% seguro, el hora. y las Actividades constructivas
equipo de desarrollo debe estar preparado como el diseño, la defensa, y la funciona-
para atender los incidentes de seguridad lidad.
que puedan generarse y hacer una retroa- ■ Fueron publicadas por primera vez en
limentación de los errores para proyectos 2004 en la revista “IEEE Security & Privacy”.
futuros.
■ Aunque no se tiene que adoptar los 7
Cigital Touchpoints Touchpoints para empezar a construir la
seguridad de un software, es muy reco-
Conceptos mendable hacerlo.
■ Es un consolidado de mejores prácticas ■ Están diseñados para llenar la brecha
aplicadas a seguridad.
existente entre la teoría y práctica, algo
■ Son una mezcla de actividades destruc- que se puede hacer sólo a través de la
tivas (ofensa) y constructivas (defensa). adopción común de las mejores prácti-
Actividades destructivas como ataques, cas.
Imagen 2
Fuente: Propia, basado en: http://www.swsec.com/resources/touchpoints/
del Área
Área Andina
Andina 97
11
Los 7 TouchPoint 5. Casos de abuso: describen el compor-
A continuación se realiza una explicación tamiento del sistema en situaciones de
resumida de cada uno de los 7 Touchpoint: posibles ataques. La construcción de
casos de abuso requiere una cobertura
1. Revisión de código: debe convertirse en explícita de lo que debe ser protegido,
una práctica necesaria, soportándose de quien, y por cuánto tiempo
con la utilización de herramientas de es-
caneo de código. Este tipo de seguridad 6. Requerimientos de seguridad: la seguri-
debe ser implementada a lo largo del cidad debe integrarse explícitamente en
clo de vida del desarrollo el nivel de requisitos. Unos buenos re-
quisitos de seguridad cubren la seguri-
2. Análisis de la arquitectura de riesgos: dad funcional manifiesta (por ejemplo,
diseñadores, arquitectos y analistas de- el uso de la criptografía aplicada) y las
ben identificar y documentar claramen- características emergentes (Se capturan
te los posibles ataques; en la etapa de por los casos de abuso y patrones de
la arquitectura basada en las especifica- ataque).
ciones, así como en la etapa de diseño
de la clase-jerarquía. Por otro lado, los 7. Operaciones de seguridad: el monitoreo
analistas de seguridad descubrir y clasi- del comportamiento del software du-
ficar defectos de arquitectura para que rante su uso en ataques de seguridad,
pueda comenzarse una mitigación de es una técnica defensiva esencial y debe
riesgos. Es recomendable que el análisis ser realizada por personal de operacio-
de riesgos este presente durante todas nes. Las experiencias adquiridas frente
las etapas del ciclo de vida con el fin de a estas situaciones deben retroalimen-
evitar problemas durante el camino. tarse hacia el proceso de desarrollo del
software.
3. Pruebas de penetración: proporcionan
una buena comprensión del software
en su entorno real, siempre y cuando
dichas pruebas estén acordes con la ar-
quitectura del software, de lo contrario
no reflejara la realidad de los riesgos de
seguridad.
4. Pruebas de seguridad basadas en ries-
go: un buen plan de pruebas debe abar-
car dos estrategias:
• Probar la funcionalidad de seguridad
con técnicas estándares funcionales
de pruebas.
• Pruebas de seguridad basado en el
riesgo sobre la base de patrones de
ataque.

1
UNIDAD
4Unidad 4
Metodologías
vigentes Ingeniería de software

Es importante conocer las líneas de equipos y terminales que
Introducción fabrican las diferentes empresas desarrolladoras de hardware
en telecomunicaciones, a fin de tener un concepto global al
momento de realizar una implementación de un sistema de
comunicaciones, hardware, adquisición de software, etc.
Esta cartilla presenta un resumen de los equipos fabricados

las marcas Hewlett Packard, Dell, Sun Microsystems y Apple. El
documento se enfoca por un lado a presentar una descripción
de cada empresa y relacionar en forma general, los productos
de hardware y software generados por las mismas.
Fundación
Universitaria del
del Área
Área Andina
Andina 100
3
U4 Metodología


comiendo la asistencia diaria para aprovechar al máximo el curso.

Se realizará una teleconferencia semanal de un tema especifico, en el cual se presentarán

ejemplos para ampliar la temática semanal.
En cada semana se publica el material de estudio que apoyara el desarrollo de los conteni-
dos temáticos correspondientes a dicha semana, ya sea en recursos bibliográficos, archivos
digitales o referencias electrónicas (páginas web).

101
Metodologías vigentes Componente: pequeño grupo de requisi-

tos específicos y detallados. Es el menor
Common Criteria (Criterios Comunes) elemento seleccionable para incluir en los
documentos de Perfiles de Protección (PP)
Conceptos y Especificación de Objetivos de seguridad
■ Se encuentran estandarizados bajo la se- (ST).
rie de normas ISO/IEC 15408 (ISO 15408-
1,2005), (ISO 15408-2,2008) y (ISO 15408- Teniendo en cuenta lo anterior, a continua-
3,2008).
ción se relacionan los requisitos de seguri-
■ Web oficial: http://www.commoncriteria- dad relacionados con la autenticación:
portal.org/
■ Se definen un conjunto de criterios es- Clase:
tándar usados como referencia para eva- • Identificación y autenticación.
luar las propiedades y características de
seguridad de productos de software o Familias de la clase:
sistemas de Tecnologías de Información.
• Fallos de autenticación.
■ La implementación de dichos criterios
permite una equiparación entre los re- • Definición de atributos de usuario.
sultados de diferentes e independientes • Autenticación de usuario.
evaluaciones, pudiéndose obtener una
certificación oficial de nivel de seguridad • Identificación de usuario.
que puede satisfacer
Componentes de la familia “Autenticación
Clasificación de usuario”
La clasificación se establece de la siguiente • Tiempo de espera para la autentica-
manera: ción.
Clase. Conjunto de familias que comparten • Acciones antes de autenticar.

un mismo objetivo de seguridad. • Mecanismos de autenticación sim-
ple.
Familia: grupo de componentes que com-
parten objetivos de seguridad pero con di- • Mecanismos de autenticación múlti-
ferente énfasis o rigor. ple.

102
Fases ■ Establecer la forma en la que se realiza-
ran las especificaciones formales de sis-
El proceso inicia con las siguientes activida- temas o productos de TI de acuerdo a los
des: aspectos de seguridad de la información
■ Definir los principios, conceptos y mode- y su tratamiento.
lo general de la evaluación de la seguri- En esta fase se manejan los siguientes con-
dad. ceptos:
Protection Profile (PP) Security Target (ST):

Conjunto de requisitos funcionales y de ga-
Conjunto de requisitos funcionales y de ga-
rantías independientes de implementación
rantías que se usan como especificaciones de
enfocadas a la identificación de un conjunto
seguridad que debe satisfacer o proporcionar
de objetivos de seguridad en un determinado
un producto o sistema. Ejemplo: ST para Chec-
dominio. Ejemplo: PP sobre un firewall, PP
kPoint Firewall-1, para Oracle v.7, etc.
sobre un sistema de control de accesos, etc.
Cuadro 1
Fuente: Propia.
A continuación de definen los Requisitos Funcionales de Seguridad, los cuales están agru-
pados en las siguientes clases:
Imagen 1
Fuente: Propia.

Se continua con la definición de Requisitos funciones de seguridad del producto o sis-
de Garantía de Seguridad, los cuales defi- tema. Estos se encuentran organizados bajo
nen los niveles de confianza que ofrecen las las siguientes clases:
Imagen 2
Fuente: Propia.
Una vez se han definido los requisitos, clases, se debe iniciar un proceso de evaluación, el
cual se representa en la siguiente imagen:
Imagen 3
Fuente: Propia.
Fundación
Universitaria del
del Área
Área Andina
Andina 104
7
Se inicia el proceso con una definición y do- para otros productos o sistemas. Puede
cumentación de los Objetivos de Evaluación ser usado como punto de partida para
(TOE) del producto o sistema a evaluar. En definir requisitos destinados a establecer
este documento también se relacionan los un Objetivo de Seguridad (ST).
recursos y dispositivos que utiliza, la docu- ■ Evaluación de Objetivos de Evaluación
mentación que genera y el entorno en el (TOE): busca demostrar que todos los re-
que funcionara. Se pueden realizar los si- quisitos establecidos en el Security Tar-
guientes tipos de evaluación: get (ST) han sido implementados en el
■ Evaluación de Perfiles de Protección (PP): producto o sistema. Esto se hace toman-
do como base un Objetivo de Seguridad
busca demostrar que un Protection Profi-
(ST) que ya ha sido evaluado.
le (PP) es completo, consistente y sólido.
Además permite definir especificaciones Como resultado de la evaluación, se pue-
de seguridad independientemente de den certificar distintos Niveles de Seguridad
la forma de implementación, por lo que (EAL). Gráficamente podemos ver estos ni-
pueden ser la base de especificaciones veles de la siguiente forma:
Niveles de seguridad (EAL)
Imagen 4
Fuente: Propia.
EAL 1. Functionally tested formales res pecto a: Funcionalidades, de

Nivel básico de seguridad, el cual se reali- interfaz, guías y documentación del pro-
za analizando las funciones de seguridad ducto, con el fin de entender el compor-
y mediante el uso de especificaciones no tamiento respecto a seguridad. Se aplica
Fundación
Universitaria del
del Área
Área Andina
Andina 105
8
cuando se necesita una confianza respecto ■ Usar controles de seguridad en los proce-
a la correcta operación, pero las amenazas sos de desarrollo para garantizar que el
de seguridad no representan un gran pe- producto no ha sido manipulado duran-
ligro sobre el sistema.EAL 1 indica que las te su desarrollo. Para esto, se analizan las
funciones de seguridad del TOE han sido funciones de seguridad con base en las
implementadas consistentemente en la especificaciones funcionales de alto nivel,
documentación y que existe una adecuada la documentación, guías del producto y
protección contra las amenazas que han los test obtenidos en la fase de prueba.
sido identificadas
EAL 4. Methodically designed, tested and
EAL 2. Structurally tested reviewed
Adicional a los requisitos del nivel EAL 1, re- Además de los requisitos de EAL 3, requiere
quiere: de:
■ Una descripción detallada e informal del ■ Un análisis independiente de la vulne-
diseño. rabilidad, de tal forma que se pueda de-
mostrar la resistencia contra intrusos que
■ Realización de pruebas en el desarrollo tengan un bajo potencial de ataque.
de acuerdo a las especificaciones funcio-
nales y confirmarlas en forma indepen- ■ Una especificación de bajo nivel del dise-
diente. ño de la implementación.
■ Análisis de la fuerza de las funciones de EAL 5. Semiformally designed and tested
seguridad implementadas y evidencias
de la verificación de la respuesta del pro- ■ Requiere de descripciones semiformales
del diseño y la arquitectura
ducto a las vulnerabilidades más comu-
nes. ■ Una completa documentación de la im-
■ Cooperación del equipo de desarrollo
plementación.
para la entrega de información sobre el ■ Se debe realizar un análisis completo de
diseño y resultados de pruebas. vulnerabilidad, de tal forma que se pue-
da probar la resistencia frente a atacan-
EAL 2 es adecuado cuando desarrolladores tes de potencial medio.
o usuarios requieren cierto nivel de garan-
tías de seguridad y no tienen acceso a toda
■ Se deben mejorar los mecanismos de
control, de tal forma que se garantice y
la documentación generada en la fase de
se demuestre que durante el desarrollo,
desarrollo.
el producto no es manipulable frente a
EAL 3. Methodically tested and checked las especificaciones establecidas para el
mismo.
Además de los requisitos de EAL 2, EAL3
obliga a: EAL 6. Semiformally verified design and tes-
ted
■ Que se implemente un desarrollo metó-
dico determinado durante la fase de di- Adicional a los requisitos del EAL 5, se re-
seño. quiere:
Fundación
Universitaria del
del Área
Área Andina
Andina 106
9
■ Un análisis detallado de las funciones de ■ Está diseñado para ayudar a los equipos
seguridad. de desarrollo de software a construir la
seguridad del producto, en las primeras
■ Una representación estructurada de su
etapas del ciclo de vida, de una manera
implementación. estructurada, repetible y medible.
■ Una representación semiformal de la re- ■ Se basa en un gran trabajo de campo por
lación entre las especificaciones de alto y parte del equipo de desarrollo, en el cual
bajo nivel con la implementación. se descomponen los recursos del sistema
■ Demostrar que la robustez de las funcio- de muchos ciclos de vida de desarrollo
nes de seguridad frente a atacantes de para crear un amplio conjunto de requi-
alto potencial de daño, han sido proba- sitos de seguridad. Los requisitos gene-
das durante el proceso de desarrollo. rados forman la base de CLASP’s Best
Practices (Mejores Prácticas de CLASP),
■ Que el desarrollo ha sido probado con las cuales permiten a las organizaciones
un análisis de vulnerabilidades indepen- a analizar y tratar sistemáticamente las
diente. vulnerabilidades de sus productos.
EAL 7. Formally verified design and tested CLASP Views (Vistas CLASP)
Adicional a los requisitos de EAL 6, se debe: Permiten a los usuarios CLASP entender de
forma rápida el proceso CLASP, la interac-
■ Probar formalmente las fases de desarro- ción de sus componentes y como aplicarlos
llo y prueba. en el ciclo de vida del proceso de desarrollo.
■ Evaluar en forma independiente la con- Vista de Concepto. Proporciona una intro-
firmación de los resultados obtenidos
ducción de alto nivel a CLASP en cuanto a:
de las pruebas realizadas para detectar
vulnerabilidades durante el proceso de ■ Interacción de las cinco vistas.
desarrollo. ■ Siete mejores prácticas.
■ Demostrar la robustez de las funciones ■ Taxonomía.
de evaluación.
■ Relación con las políticas de seguridad.
■ Realizarse un análisis independiente de ■ Ejemplos para aplicar componentes del
vulnerabilidades para demostrar resis-
proceso.
tencia frente a un atacante de alto poten-
cial. Vista Basada en Roles. Hace una introduc-
ción basadas en roles para el proceso CLASP.
Comprehesive Lightweight Application
Security Process (CLASP) Vista Actividad-Evaluación. Ayuda a los ad-
ministradores de proyectos a evaluar la
Conceptos idoneidad de las 24 Actividades CLASP y
■ Es una actividad impulsada, mediante un seleccionar un subconjunto de ellos. CLASP
conjunto basado en roles de componen- ofrece dos medios para ayudar a seleccionar
tes de procesos guiados por las mejores las actividades aplicables: La herencia y el
prácticas formalizadas. nuevo inicio.
del Área
Área Andina
Andina 107
10
Vista Actividad-Implementación. Contiene combinación de problemas que crean una
las 24 Actividades CLASP relacionadas con condición de seguridad que conduce a una
la seguridad, las cuales se pueden integrar vulnerabilidad en el código fuente.
en un proceso de desarrollo de software. La
fase de actividades del SDLC (System Deve- Asociados a Vista de Vulnerabilidad se en-
lopment Life Cycle), se transforman en un cuentran los Casos de Uso de la vulnerabi-
ejecutable de software, de cualquier sub- lidad CLASP, los cuales representan condi-
conjunto de las 24 actividades relacionadas ciones en las que los servicios de seguridad
con la seguridad que fueron evaluadas y son vulnerables a los ataques en la capa
aceptadas en la Vista Actividad-Evaluación. de aplicación. Proporcionan a los usuarios
CLASP, ejemplos fáciles de entender, espe-
Vista de Vulnerabilidad. Contiene el listado cíficos de la relación entre la seguridad del
de los 104 “tipos de problemas” identifica- código fuente y las posibles vulnerabilida-
dos por CLASP que forman la base de las des que pueden generarse en servicios de
vulnerabilidades de seguridad en el código seguridad básicos.
fuente de la aplicación. Un tipo de proble-
ma individual no siempre es una vulnerabi- A continuación se presenta la relación exis-
lidad de seguridad; con frecuencia, es una tente entre las diferentes vistas de CLASP.
Imagen 4
Fuente: https://buildsecurityin.us-cert.gov/sites/default/files/clasp-figure1.gif
del Área
Área Andina
Andina 108
11
Las 7 Mejores prácticas de CLASP Es fácil para los arquitectos de aplica-
Son la base de todos los programas de desa- ciones y administradores de proyectos
rrollo relacionados con la seguridad de ac- centrarse en la funcionalidad a la hora
tividades, ya sea la planificación, el diseño de definir los requisitos, ya que sopor-
o la implementación, incluyendo el uso de tan el mayor propósito de la aplicación
todas las herramientas y técnicas que apo- para ofrecer valor a la organización. Las
yan CLASP. Estos son los siete CLASP Mejo- consideraciones de seguridad pueden
res Prácticas: ir fácilmente en el camino, por lo que
1. Instituir programas de sensibilización es fundamental que los requisitos de
seguridad sean una parte explícita de
Es imprescindible educar al equipo de cualquier esfuerzo de desarrollo de apli-
desarrolladores, gerentes y demás per- caciones. Entre los factores a considerar
sonas involucradas, en conceptos y téc- son:
nicas de seguridad. Se pueden imple-
mentar programas de sensibilización, a
• Comprender como se usará la aplica-
ción y cómo podría ser mal utilizada
través de la experiencia de expertos ex-
ternos, según sea necesario y ayudando o bloqueada.
a asegurar que las actividades de pro- • A cuales activos (datos y servicios) la
moción de software seguro se lleven a aplicación dará acceso o que niveles
cabo de manera efectiva de protección son apropiados, de
2. Realizar evaluaciones de aplicación acuerdo la exigencia de riesgo por
parte de la organización, las regula-
Las evaluaciones automatizadas pue- ciones a las que está sujeta, y el im-
den encontrar problemas de seguridad pacto potencial sobre su reputación
que no pueden ser detectados duran- deben ser explotados en la aplica-
te la codificación o pruebas de la apli- ción.
cación; permiten encontrar riesgos de
seguridad introducidos por el entorno • La arquitectura de la aplicación y los
operativo, y actuar como un mecanismo tipos de ataque probables.
de defensa en profundidad por la cap- • Posibles controles de compensación,
tura de los fallos en el diseño, especifi- su costo y efectividad.
cación, o implementación.
4. Implementar prácticas de desarrollo se-
Las funciones de prueba y evaluación guras
son propias de un analista de prueba o
por la organización de control de cali- Para crear y mantener el código fuente
dad, pero pueden abarcar todo el ciclo reutilizable que permita fortalecer los
de vida. servicios básicos de seguridad en una
3. Captura de requisitos de seguridad aplicación, se requiere de la implemen-
tación de prácticas de desarrollo de se-
Asegurar que los requisitos de seguri- guras en el proceso de desarrollo del
dad tienen el mismo nivel de “ciudada- SDLC. Las Mejores Practicas CLASP per-
nía”, como todos los demás “debe tener.” miten:
del Área
Área Andina
Andina 109
12
• Poner a disposición un amplio con- dad de la aplicación y son cruciales para
junto de componentes de proceso. evaluar la situación actual de seguridad
• Proporcionar actividades basadas en de una organización. También ayudan a
roles bien definidos, permitiendo a enfocarse en las vulnerabilidades más
los equipos de proyecto, tener una críticas, y revelan lo bueno y lo malo de
guía en la implementación de los la inversión de la organización en la me-
principios de seguridad para diseñar, jora de la seguridad.
integrar el análisis de seguridad en el
proceso de administración de origen, 7. Publicar directrices de la seguridad ope-
y la implementación / elaboración de racional
las políticas de recursos y tecnologías
de seguridad. La seguridad no termina cuando se ha
• Proporcionar muchos ejemplos de
completado una solicitud y desplega-
do en un entorno de producción. Para
directrices de codificación, como los
104 Tipos de Problemas CLASP, que aprovechar al máximo la red existente
ayudan al equipo de proyecto detec- y las inversiones en seguridad opera-
tar y resolver vulnerabilidades de se- cional se requiere que los encargados
guridad en código fuente. de la supervisión y la gestión de la se-
5. Construir procedimientos de enmendar guridad del sistema, sean informados y
vulnerabilidades educados; necesitan un asesoramiento
y orientación sobre los requisitos de se-
Acelera la respuesta y minimiza el ries- guridad que requieren las aplicaciones
go mediante la definición de funciones, y cómo optimizar las capacidades inte-
responsabilidades y procesos a seguir
gradas en la aplicación.
después de la identificación de la vulne-
rabilidad, en el contexto de actualizacio-
nes y mejoras de las aplicaciones. Estos Las 24 Actividades CLASP
procesos permiten definir las medidas Cada Actividad CLASP se divide en compo-
que se tomarán para identificar, evaluar, nentes de proceso discretos y vinculados
priorizar y remediar dichas vulnerabili- a una o más funciones específicas del pro-
dades y a menudo son alimentados por
yecto; de esta forma CLASP brinda una guía
las evaluaciones de software, tanto en
forma local o de un tercero, y ayudan a para que los participantes en el proyecto
controlar la información que debe pro- (jefes de proyecto, auditores de seguridad,
ducirse para su divulgación. desarrolladores, arquitectos, probadores,
etc.) puedan adaptarlas fácilmente a su for-
6. Definir y monitorear las métricas
ma de trabajar. Esto genere mejoras incre-
Los indicadores son un elemento esen- mentales a la seguridad que son fácilmente
cial de un esfuerzo general de seguri- alcanzables, repetible y medible.
del Área
Área Andina
Andina 110
13
Mejores prácticas Roles de proyecto
Actividades CLASP
CLASP relacionados
1. Instituir
Instituir programas de concientiza-
programas de Gerente del proyecto.
ción sobre la seguridad.
sensibilización
Realizar análisis de la seguridad de
los requisitos del sistema y el diseño Auditor de seguridad.
(modelado de amenazas).
Propietario: auditor de seguridad.
Realizar revisión de seguridad a
Colaborador clave: implementador,
nivel de fuente.
diseñador.
2. Realizar eva-
luaciones de Identificar, implementar y realizar
Analista de pruebas.
aplicación pruebas de seguridad.
Verifique los atributos de seguridad
Tester.
de los recursos.
Investigue y evaluar la postura de Propietario: diseñador.
seguridad de soluciones tecnológi- Colaborador clave: proveedor de
cas. componentes.
Identificar políticas de seguridad
Requisitos especificador.
global.
Propietario: Arquitecto.
Identificar los recursos y los límites
Colaborador clave: requisitos espe-
de confianza.
cificador.
Propietario: Arquitecto.
Identificar las funciones de usuario y
Colaborador clave: requisitos espe-
capacidades de recursos.
cificador.
3. Captura de re-
Propietario: requisitos especifica-
querimientos
Especificar entorno operativo. dor.
de seguridad
Colaborador clave: arquitecto.
Detalle casos de uso indebido. dores.
Factor clave: los grupos de interés.
Identificar superficie de ataque Diseñador.
Requisitos de documentos de segu-
dor.
ridad pertinentes.
Colaborador clave: arquitecto.
Aplicar principios de seguridad al
Diseñador.
diseño.
Anotar diseños clase con propieda-
Diseñador.
des de seguridad.
4. Identificar
practicas Implementar y elaborar políticas de
Implementador.
seguras de recursos y tecnologías de seguridad.
desarrollo Implementar contratos de interfaz. Implementador.
Integrar el análisis de seguridad en
Integrador.
el proceso de gestión de la fuente.
Realizar la firma de código. Integrador.
Construir pro- Administrar proceso de divulgación Propietario: director del proyecto.

cedimientos de problema de seguridad. Colaborador clave: diseñado.
remediación de Dirección reportó problemas de Propietario: diseñador
vulnerabilidades seguridad. reportero de falla.
Definir y monito-
Monitorear métricas de seguridad. Gerente de proyecto.
rear las métricas
Especifique la configuración de
Publicar directri- Diseñador de la base de datos
seguridad de base de datos.
ces de seguridad
operativa Construir Guía dirección seguridad
Construir guía seguridad operativa.
operativa.
Cuadro 2
Fuente: Propia.
Bibliografia
■■Alcalde, E. & García, J. (1996). Introducción a la teleinformática. Colombia: McGraw-Hill.
■■Jacobson, I. (2000). El proceso unificado de desarrollo de software. (3ª. Ed.). Londres: Pear-
son PLC.
■■Long, L. (1996). Introducción a las computadoras y al procesamiento de información. (4ª.
Ed.). México: Prentice Hall.
■■Norton, P. (2000). Introducción a la computación. (3ª. Ed.). México: McGraw-Hill.
■■Pressman, R. (2005). Ingeniería de software: un enfoque práctico. México: McGraw-Hill.

Esta obra se terminó de editar en el mes de noviembre
Tipografá Myriad Pro 12 puntos
Bogotá D.C,-Colombia.

Ingeniería de Software 1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingeniería de Software 1

Cargado por

Copyright:

Formatos disponibles

Ingeniería de software 1

Autor: Fredy Alonso León Socha

Catalogación en la fuente Fundación Universitaria del Área Andina (Bogotá).

© 2017. FUNDACIÓN UNIVERSITARIA DEL ÁREA ANDINA

Primera edición: noviembre de 2017

Corrección de estilo, diagramación y edición: Dirección Nacional de Operaciones virtuales

Autor: Fredy Alonso León Socha

UNIDAD 1 Introducción a la Ingeniería de

UNIDAD 1 Introducción a la Ingeniería de

UNIDAD 2 Introducción a la ingeniería de

UNIDAD 2 Especificación y validación

UNIDAD 3 Diseño orientado a objetos de

UNIDAD 3 Modelado de procesos

UNIDAD 4 Conceptos de seguridad

UNIDAD 4 Metodologías vigentes

Desarrollo temático 102

Se inicia con las primeras formas utilizadas para comuni-

Estas temáticas le ayudaran a saber de dónde han surgido las

El módulo se basa en la lectura individual de la presente cartilla y posterior desarrollo de

Se espera una participación y acceso a plataforma a su consideración, como mejor pueda

La comunicación conmigo la pueden realizar abiertamente a través del Foro y personalmen-

Introducción a la Ingeniería de dación y administración de tiempos y pre-

■ Se empezaron a realizar procesos de planificación para el desarrollo.

■ Se masifico la programación orientada a objetos.

Permite iniciar procesos de autoformación.

Altos costos de mantenimiento A continuación se presenta una muy buena

Fundación Universitaria del Área Andina 12

Económico Pruebas y validación, para determinar si el

Revisiones y Control de la Aseguramiento Estrategia de

Producto final y Revisiones y Revisiones y

Por otro lado, al conocer las características ventajas, o desven-

El módulo se basa en la lectura individual de la presente cartilla y posterior desarrollo de

Se espera una participación y acceso a plataforma a su consideración, como mejor pueda

La comunicación conmigo la pueden realizar abiertamente a través del Foro y personalmen-

Introducción a la Ingeniería de software

Mitos del software

Mitos del cliente

Fundación Universitaria del Área Andina 5

Mitos del desarrollador

Distribución del esfuerzo en un proyecto ■ Análisis y diseño: Se proyectan interfaces

Teniendo en cuenta la grafica anterior, se Utilizar técnicas de descomposición sen-

• Diseño Inicial. Se utiliza en las prime- ■ Habilidades y experiencia del equipo.

Fundación Universitaria del Área Andina 22

Tipos de estructura organizativa en equipos de trabajo

Director del proyecto

Experto Líder de Experto en

Ingeniero Ingeniero Ingeniero Técnico

Ingeniero Todos los integrantes tienen la misma rele-

Gestión del riesgo

La gestión del riesgo implica identificar, eli-

Una vez identificados los riesgos, se le asig- Algunas fuentes de riesgos

A continuación relacionaremos algunas fun- ■ Análisis de requisitos

Dentro de las muchas opciones que existen ■ Implementación

Fundación Universitaria del Área Andina 26

Modelo de prototipos teractuar con el equipo de trabajo, para ir

RAD (Rapid Application Development)

Las herramientas de software pueden ser:

Autor: Fredy Alonso León Socha

El conocimiento y manejo adecuado de estas tecnologías

De esta forma, la presente asignatura es fundamental para el

Fundación Universitaria del Área Andina 30

El tutor realizará una teleconferencia semanal de un tema especifico, en el cual se presenta-

Se recomienda el ingreso diario a la plataforma para aprovechar al máximo el curso.

Fundación Universitaria del Área Andina 31