Ingeniería de Software 1

Clase 1 - Tema: Definición de software y sus características. Diferentes categorías o

clases de software. Evolución del software.
Definición de Software:
Según Pressman:
1- Instrucciones que cuando se ejecutan proporcionan las
características, función y desempeño buscados.
2- Estructuras de datos que permiten que los programas manipulen en
forma adecuada la información.
3- Información descriptiva tanto en papel como en formas virtuales que
describen la operación y uso de los programas.
Según Sommerville:
1- Programas de computadora y documentación asociada.
2- Productos genéricos.
3- Productos desarrollados a medida.
El concepto va más allá de los programas de computación en sus distintos estados:
Código fuente, binario o ejecutable; también la documentación, los datos a procesar
e incluso la información de usuario. Lo intangible.

>CARACTERÍSTICAS
El software es elemento de un sistema lógico y no de uno físico. Por lo tanto tiene
características que lo hacen diferente respecto a otros productos o hardware.

1) El software se desarrolla o modifica con intelecto. No se manufactura (fabrica,

elabora) en el sentido clásico.

SOFTWARE Y HARDWARE
Aunque hay similitudes entre el desarrollo del Software y la fabricación del Hardware,
son actividades diferentes.
- En ambas, la alta calidad se logra a través de un buen diseño, pero la fase de
fabricación del Hardware introduce problemas de calidad que no existen en el
Software.
- Ambas dependen de personas, pero la relación entre los individuos y el trabajo
logrado es diferente por completo.
- Los costos del software se concentran en la ingeniería. (Los proyectos no se
administran como si fueran proyectos de manufactura.)
2) El Software no se desgasta.

SOFTWARE Y HARDWARE
- Con el paso del tiempo el Hardware se empieza a degastar (suciedad, vibración, uso
intensivo, etc.)
- El Software no es susceptible a los problemas ambientales que hacen que el
Hardware se desgaste. Pero si se deteriora.
-El Software se deteriora como consecuencia del cambio. Con el tiempo el Software
sufrirá cambios, lo que pueden generar fallas.
- Los componentes desgastados de los Hardware se arreglan o reemplazan. Pero no
hay refacciones para el Software.
3) Aunque la industria se mueve hacia la construcción basada en componentes, la
mayor parte del software se construye para un uso individualizado.

SOFTWARE Y HARDWARE
-En el Hardware la reutilización de los componentes es natural.
-En el Software apenas se ha empezado a hacer a gran escala.
-Un componente del Software debe diseñarse e implementarse de modo que pueda
volver a usarse en muchos programas diferentes.
>CATEGORIAS
Hay 7 grandes categorías.
1) Software de sistemas: Conjunto de programas escritos para dar servicio a otros
programas. Algunos procesan estructuras de información compleja pero determinista
(compiladores, editores, etc.); otros procesan datos indeterminados (componentes de
SO, software de redes).
Deterministas: Si se puede predecir el orden y momento de las entradas, el
procesamiento y las salidas.
No deterministas: Si no pueden predecirse el orden y momento en que
ocurren éstos.
Características:
- Gran interacción con el hardware de la computadora.
- Uso intensivo por parte de múltiples usuarios.
- Operaciones concurrentes que requieren secuenciación.
- Recursos compartidos y administración de procesos.
- Manejo de estructuras complejas de datos y múltiples interfaces externas.

2) Software de aplicación: Programas aislados que resuelven una necesidad específica

de negocios. Generalmente, procesan datos comerciales o técnicos. También se usa
para controlar funciones de negocios en tiempo real (ej. Procesamiento de
transacciones en punto de venta).

3) Software de ingeniería y ciencias: Las aplicaciones van desde la astronomía a la

vulcanología.

4) Software incrustado:

5) Software de línea de productos: Diseñados para proporcionar una capacidad

específica para uso de muchos consumidores diferentes. Se centra en algún mercado
limitado y particular o se dirige a mercados masivos de consumidores.

6) Aplicaciones web: Está centrado en redes, agrupa una amplia gama de

aplicaciones. Conjunto de archivos de hipertexto vinculados que presentan
información con uso de texto y gráfica.
Están evolucionando hacia ambientes de cómputo sofisticados donde están
integrando bases de datos corporativas y aplicaciones de negocios.

7) Software de inteligencia artificial: Diseñados para resolver problemas complejos.

Incluyen robótica, sistemas expertos, reconocimiento de patrones, redes neuronales,
juegos, etc.
>EVOLUCION DEL SOFTWARE
-El rápido crecimiento de las redes inalámbricas quizá lleve pronto a la
computación verdaderamente ubicua y distribuida. El desafío para los ingenieros de
software será desarrollar sistemas y aplicaciones que permitan a dispositivos móviles,
computadoras personales y sistemas empresariales comunicarse a través de redes
enormes.
-La red mundial se está convirtiendo con rapidez tanto en un motor de
computación como en un proveedor de contenido. El desafío es desarrollar
arquitecturas sencillas que proporcionen un beneficio a mercados objetivos de
usuarios finales en todo el mundo.
- La distribución de código fuente para aplicaciones de sistemas de modo que
mucha gente pueda contribuir a su desarrollo. El desafío es elaborar código fuente
que sea auto descriptivo y desarrollar técnicas que permitan saber cuáles son los
cambios hechos y cómo se manifiestan dentro del Software.

Clase 2 - Tema: Definición de Ingeniería de Software y sus fundamentos científicos.

Conceptos de organización y de proceso. Diferencia entre proceso y producto.
>PROBLEMAS DEL SOFTWARE.
La <crisis del Software> se transformó en una “aflicción crónica” (Pressmann)
- Particulares y empresas desarrollan en forma no profesional.
- Desarrollos que afectan la calidad del Software.
- Aplicaciones críticas: Antiguas y/o falta de documentación.
- No hay planificación ni estimación de costos precisos.
- La productividad de la comunidad de Software.
- En la metodología, en el análisis de requisitos.
- Insatisfacción del cliente con el sistema terminado.
-Calidad del Software.
- Mantenimiento costoso.
La clave para resolver los problemas de “La crisis del Software” es dar un ENFOQUE
DE INGENIERÍA al desarrollo del Software.
>DIFINICIÓN
La Ingeniería de Software (IS) es una disciplina de ingeniería que se interesa por
todos los aspectos de la producción de Software.
Se busca obtener resultados de calidad dentro de una fecha y un presupuesto. Esto
requiere aceptar compromisos: Los ingenieros no deben ser perfeccionistas.

Hay 2 aspectos claves:

1- Disciplina de Ingeniería.
Los ingenieros aplican teorías, métodos y herramientas donde es
adecuado. Aunque lo hacen de manera selectiva y tratan de encontrar soluciones a
problemas.
También trabajan con restricciones organizacionales y financieras.

2- Todos los aspectos de la producción de software.

La IS no sólo se interesa por los procesos técnicos del desarrollo del
software, sino que también incluye actividades como la administración del proyecto
de software y el desarrollo de herramientas, así como métodos y teorías para apoyar
la producción de software.
>IMPORTANCIA
1- Cada vez con mayor frecuencia, la sociedad en general se apoya en los
sistemas de software.
2- Resulta más económico a largo plazo usar métodos y técnicas de ingeniería
de software para los sistemas informáticos, que diseñar programas como si fuera un
proyecto de programación personal.
>RELACIONES
Las ciencias de la computación se interesan por las teorías y los métodos que
subyacen en las computadoras y los sistemas de software. Es más aplicable a
programas pequeños.
La ingeniería de software se preocupa por los asuntos prácticos de la
producción del software.
La ingeniería de sistemas se interesa por todos los aspectos del desarrollo y la
evolución de complejos sistemas, donde el software tiene un papel principal. Por lo
tanto, se preocupa por el desarrollo de hardware, el diseño de políticas y procesos, la
implementación del sistema, así como la ingeniería de software.
Los ingenieros de sistemas intervienen en la especificación del sistema,
definiendo su arquitectura global y, luego, integrando las diferentes partes.
>FUNDAMENTOS
Existen fundamentos de ingeniería de software que se aplican a todos los tipos de
sistemas:
1- Deben llevarse a cabo usando un proceso de desarrollo administrado y
comprendido. La organización que diseña el software necesita planear el
proceso de desarrollo, así como tener ideas claras acerca de lo que
producirá y el tiempo en que estará completado.
2- La confiabilidad y el desempeño son importantes para todos los tipos de
sistemas. El software tiene que comportarse como se espera, sin fallas, y
cuando se requiera estar disponible. Debe ser seguro en su operación y,
tanto como sea posible, también contra ataques externos. El sistema tiene
que desempeñarse de manera eficiente y no desperdiciar recursos.
3- Es importante comprender y gestionar la especificación y los
requerimientos del software. Debe conocerse que esperan de él los
diferentes clientes y usuarios del sistema, y gestionar sus expectativas, para
entregar un sistema útil dentro de la fecha y presupuesto.
4- Tiene que usar de manera tan efectiva como sea posible los recursos
existentes. Donde sea adecuado, hay que reutilizar el software que si haya
desarrollado, en vez de diseñar uno nuevo.

>PROCESOS
Existen cuatro actividades fundamentales comunes a todos los procesos de software:

1-Especificacion: Clientes e ingenieros definen el software que se producirá y

las restricciones en su operación.
2-Desarrollo: Se diseña y programa el software.
 3-Validación: Se verifica el software para asegurar que sea lo que el cliente
requiere.
4-Evolución: Se modifica el software para reflejar los requerimientos
cambiantes del cliente del mercado.
>CAPAS

El fundamento en el que se apoya la IS es el compromiso con la calidad.

La IS es una tecnología con varias capas:
- El proceso define una estructura que debe establecerse para la obtención
eficaz de tecnología de IS. Forma la base para el control de la
administración de proyectos, y establece el contexto en el que se aplican
métodos técnicos, se generan productos del trabajo, se establecen puntos
de referencia, se asegura la calidad y se administra el cambio de manera
apropiada.
- Los métodos proporcionan la experiencia técnica para elaborar software.
Incluyen un conjunto amplio de tareas, como comunicación, análisis de los
requerimientos, modelación del diseño, construcción del programa,
pruebas y apoyo.
- Las herramientas proporcionan apoyo automatizado o semi automatizado
para el proceso y los métodos.
Cuando se integran las herramientas de modo que la información creada
por una pueda ser utilizada por otra, se establece un sistema llamado IS
asistido por computadora que apoya el desarrollo de software.
>EL PROCESO DEL SOFTWARE
Un proceso es un conjunto de actividades, acciones y tareas que se ejecutan
cuando va a crearse algún producto del trabajo.
No es una prescripción rígida de cómo elaborar un software, sino un enfoque
adaptable que permite que el equipo de trabajo busque y elija el conjunto apropiado
de acciones y tareas para el trabajo.
- Una actividad busca lograr un objetivo amplio y se desarrolla sin importar
el dominio de la aplicación, tamaño del proyecto, complejidad del
esfuerzo, etc.
- Una acción es un conjunto de tareas que producen un producto
importante del trabajo.
- Una tarea se centra en un objetivo pequeño pero bien definido que
produce un resultado tangible.
La ESTRUCTURA DEL PROCESO establece el fundamento para el proceso
completo de la IS por medio de la identificación de un número pequeño de
actividades estructurales que sean aplicables a todos los proyectos de software, sin
importar su tamaño o complejidad.
La estructura incluye un conjunto de actividades sombrilla que son aplicables a
través de todo el proceso del software.
ACTIVIDADES:
- Comunicación: Antes de comenzar cualquier trabajo técnico, tiene
importancia crítica comunicarse y colaborar con el cliente. Se busca
entender los objetivos de los participantes respecto del proyecto, y reunir
los requerimientos que ayuden a definir las características y funciones del
software.
- Planeación: Permite crear un <mapa> que guía al equipo mientras viaja. El
mapa (Plan del proyecto de software) describe las tareas técnicas por
realizar, los riesgos probables, los recursos que se requieren, los productos
del trabajo que se obtendrán y una programación de las actividades.
- Modelado: Se crea un “bosquejo” del objeto a construir a fin de entender el
panorama general. Se puede refinar el bosquejo con más y más detalles, en
un esfuerzo por comprender mejor el problema y cómo resolverlo.
- Construcción: Esta actividad combina la generación de código y las
pruebas que se requieran para descubrir errores en él.
- Despliegue: El software se entrega al consumidor que lo evalúa u le da
retroalimentación.
Para muchos proyectos, las actividades estructurales se aplican en forma iterativa a
medida que avanza el proyecto. Cada iteración produce un incremento del software
que da a los participantes un subconjunto de características y funcionalidad
generales del mismo. Cuanto más se incrementa, más completo.

Las actividades son completadas por actividades sombrilla, que se aplican a lo

largo de un proyecto de software y ayudan al equipo que lo lleva a cabo a
administrar y controlar el avance, la calidad, el cambio y el riesgo.
-Seguimiento y control del proyecto de software: Permite que el equipo de
software evalúe el progreso comparándolo con el plan del proyecto y tome cualquier
acción necesaria para apegarse a la programación de actividades.
-Administración del riesgo: Evalúa los riesgos que puedan afectar el resultado
del proyecto o la calidad del producto.
-Aseguramiento de la calidad: Define y ejecuta las actividades requeridas para
garantizar la calidad.
-Revisiones técnicas: Evalúa los productos del trabajo a fin de descubrir y
eliminar errores antes de que se propaguen a la siguiente actividad.
 -Medición: Define y reine mediciones del proceso, proyecto y producto para
ayudar al equipo a entregar el software que satisfaga las necesidades de los
participantes.
-Administración de la configuración: Administra los efectos del cambio a lo
largo del proceso del software.
-Administración de la reutilización: Define criterios para volver a usar el
producto del trabajo y establece mecanismos para obtener componentes
reutilizables.
-Preparación y producción del producto del trabajo: Agrupa las actividades
requeridas para crear productos del trabajo, tales como modelos, documentos,
registros, formatos y listas.

Clase 3 - Tema: Reingeniería de software: modelos y actividades.

>INTRODUCCIÓN
Escenario común: Un sistema que atendió las necesidades empresariales de
una compañía durante 10 o 15 años, se corrigió, adaptó y mejoró muchas veces. Las
personas realizaban esta tarea con las mejores intenciones, pero las buenas prácticas
de ingeniería siempre se hicieron a un lado. Ahora la aplicación es inestable: todavía
funciona, pero cada vez que se intenta un cambio, ocurren inesperados y serios
efectos colaterales. Aun así, la aplicación debe seguir evolucionando.
>UN MODELO DE PROCESO DE REINGENIERÍA (RI)
La reingeniería toma tiempo, cuenta dinero y absorbe recursos que de otro
modo pueden ocuparse en preocupaciones inmediatas. Es una actividad que
absorberá recursos de tecnología de la información durante muchos años. Por lo
tanto se necesita aplicar una estrategia para la RI.
Los principios que se enfocan en la reconstrucción de una casa, se aplican igual de
bien a la RI. Para implementar estos principios se puede usar un modelo de proceso
de reingeniería de software que define 6 actividades:
-Análisis de inventarios: Toda organización de software debe tener un
inventario de todas las aplicaciones. Puede ser un archivo planilla de
cálculo que contenga información que ofrezca una descripción detallada
de cada aplicación activa. Al ordenar esta información, aparecen los
candidatos para reingeniería. El inventario debe revisarse con regularidad.
-Ingeniería inversa: El concepto de la ingeniería inversa viene del mundo
del hardware. Una compañía “roba” un producto de otra y trata de
entender los secretos del diseño y fabricación. En Software, el programa
que se va a someter a ing. Inversa no es de un competidor, sino el mismo
trabajo de la compañía. Los “secretos” por entender son oscuros porque
 jamás se desarrollaron especificaciones. Es un proceso de recuperación de
diseño.
-Reestructuración de código: La arquitectura de programa es relativamente
sólida, pero los módulos de forma individual pueden ser difíciles de
entender, poner a prueba y mantener, por lo tanto pueden reestructurarse.
Se analiza el código fuente, se detecta mala codificación y luego el código
se reestructura.
-Reestructuración de datos: La reestructuración de los datos comienza con
una actividad de ingeniería inversa. La arquitectura existente se diseca y se
definen modelos de datos necesarios. Se identifican los objetos y atributos
de datos, y se revisa la calidad de las estructuras de datos existentes.
Cuando la estructura es débil, los datos se someten a reingeniería.
-Ingeniería hacia adelante: No sólo recupera información de diseño
existente, sino que también usa esta información para alterar o reconstruir
el sistema existente con la intención de mejorar su calidad y rendimiento.

Clase 4 - Tema: Modelos del Proceso: en cascada. Construcción en cascada con

mejora iterativa; incremental; prototipo; en espiral. Modelos alternativos.
>MODELOS DE PROCESO
INTRODUCCIÓN
Todos los modelos del proceso del software pueden incluir las
actividades estructurales generales descritas en la clase anterior, pero cada una pone
distinto énfasis en ellas y define en forma diferente el flujo de proceso que invoca
cada actividad estructural.
->Entender el problema->Diseñar el programa->Codificar el programa->Probar el
programa->Mantener el programa->
CLASIFICACIÓN
>MODELO DE PROCESO.
Los modelos de proceso pueden ser:
-Prescriptivos: Se los llama así, porque prescriben un conjunto de
elementos del proceso: actividades estructurales, acciones de IS, tareas, productos
del trabajo, aseguramiento de la calidad y mecanismos de control.
Cada modelo del proceso también prescribe un flujo del proceso (flujo de trabajo), es
decir, la manera en la que los elementos del proceso se relacionan entre sí.
-Descriptivos: Permite entender los procesos existentes, comunicar y
analizar prácticas existentes para la mejora continua.
 >DESARROLLO LINEAL SECUENCIAL
MODELO EN CASCADA
Toma las actividades fundamentales del proceso de especificación, desarrollo,
validación y evolución y las representa como fases separadas del proceso, tal como,
especificación de requerimientos, diseño de software, implementación, pruebas, etc.
FASES
1. Análisis y definición de requerimientos: Los servicios, las restricciones
y las metas del sistema se establecen mediante consulta a los usuarios del sistema.
Luego, se definen con detalle y sirven como una especificación del sistema.
2. Diseño del sistema y del software: Asigna los requerimientos, para
sistemas de hardware o de software, al establecer una arquitectura de sistema global.
El diseño implica identificar y describir las abstracciones fundamentales del sistema
de software y sus relaciones.
3. Implementación y prueba de unidad: Durante esta etapa, el diseño de
software se realiza como un conjunto de programas o unidades del programa. La
prueba de unidad consiste en verificar que cada unidad cumpla con su
especificación.
4. Integración y prueba de sistema: Las unidades del programa o los
programas individuales se integran y prueban como un sistema completo para
asegurarse de que se cumplan los requerimientos de software. Después, se libera al
cliente.
5. Operación y mantenimiento: Esta fase es la más larga del ciclo de
vida, donde el sistema se instala y se pone en práctica. El mantenimiento incluye
corregir los errores que no se detectaron en etapas anteriores del ciclo de vida,
mejorar la implementación de las unidades del sistema e incrementar los servicios
del sistema conforme se descubren nuevos requerimientos.
Ventajas: -Sencillo.
-Sirve cuando el personal está poco cualificado.
-Aplicable cuando el problema es estable y cuando se
trabaja con técnicas conocidas.

Críticas: -No se ve un producto hasta muy tarde en el proceso.

-Un error grave en las últimas fases puede ser letal.
-Especificación de requisitos estable.
-Impone una estructura de gestión de proyectos.
-Fases muy rígidas.
-Las revisiones de proyectos de gran complejidad son muy
difíciles.
CONCLUSIÓN
El resultado de cada fase consiste en uno o más documentos que se
autorizaron (“firmaron”). En la práctica, dichas etapas se traslapan y se nutren
mutuamente de información. Durante el diseño se identifican los problemas con los
requerimientos. En la codificación se descubren problemas de diseño, y así
sucesivamente. No es un simple modelo lineal, sino que implica retroalimentación de
una fase a otra. Entonces, es posible que los documentos generados en cada fase
deban modificarse para reflejar los cambios que se realizan.
El modelo en cascada sólo debe usarse cuando los requerimientos se entiendan bien
y sea improbable el cambio radical durante el desarrollo del sistema.

>DESARROLLO ITERATIVO:
MODELO INCREMENTAL
Se basa en la idea de diseñar una implementación inicial, exponer ésta al
comentario del usuario, y luego desarrollarla en sus diversas versiones hasta producir
un sistema adecuado. Las actividades de especificación, desarrollo y validación están
entrelazadas en vez de separadas, con rápida retroalimentación a través de las
actividades.
Los primeros incrementos incluyen la función más importante o la más urgente. Esto
significa que el cliente puede evaluar el desarrollo del sistema en una etapa
relativamente temprana, para constatar si se entrega lo que se requiere.
Ventajas: -Es iterativo: Con cada incremento se entrega al cliente un
producto operacional, que se puede evaluar.
-Personal: Permite variar el personal asignado a cada
iteración.
-Gestión riesgos técnicos: Por ejemplo, disponibilidad de
hardware específico.

Inconvenientes: - La primera iteración puede plantear los mismos

problemas que en un modelo lineal secuencial.
MODELO EN ESPIRAL
Cada ciclo en la espiral representa una fase del proceso de software. Por ende, el
ciclo más interno puede relacionarse con la factibilidad del sistema, el siguiente ciclo
con la definición de requerimientos, el ciclo que sigue con el diseño del sistema, etc.
El modelo combina el evitar el cambio con la tolerancia al cambio. Lo anterior
supone que los cambios son resultado de riesgos del proyecto e incluye actividades
de gestión de riesgos explícitas para reducir tales riesgos.

- Cada ciclo se divide en cuatro sectores:

1. Establecimiento de objetivos: Se definen objetivos específicos para dicha
fase del proyecto. Se identifican restricciones en el proceso y el producto, y se traza
un plan de gestión detallado. Se identifican los riesgos del proyecto. Pueden
planearse estrategias alternativas, según sean los riesgos.
2. Valoración y reducción del riesgo: En cada uno de los riesgos identificados
del proyecto, se realiza un análisis minucioso. Se dan acciones para reducir el riesgo.
3. Desarrollo y validación: Después de una evaluación del riego, se elige un
modelo de desarrollo para el sistema. Ej: Creación de prototipos desechables sería
el mejor enfoque de desarrollo, si predominan los riesgos en la interfaz del
usuario. Si el principal riesgo identificado es la integración de subsistemas, el
modelo en cascada sería el mejor modelo de desarrollo a utilizar.
4. El proyecto se revisa y se toma una decisión sobre si hay que continuar con
otro ciclo de la espiral. Si se opta por continuar, se trazan los planes para la siguiente
fase del proyecto.

Ventajas: -Enfoque realista.

- Gestión explícita de riesgo.
- Centra su atención en la reutilización de componentes y
eliminación de errores en información descubierta en fases iniciales.
- Los objetivos de calidad son el primer objetivo.
- Integra desarrollo con mantenimiento.

Inconvenientes: -Convencer cliente enfoque controlable.

-Requiere de experiencia en la identificación de
riesgos.
- Requiere refinamiento para uso generalizado.

CONCLUCIÓN
La diferencia principal entre el modelo en espiral con otros modelos de
proceso es su reconocimiento explícito del riesgo.
>DESARROLLO EVOLUTIVO
MODELO DE PROTOTIPO
Un prototipo es una versión inicial de un sistema de software que se usa
para demostrar conceptos, tratar opciones de diseño y encontrar más sobre el
problema y sus posibles soluciones. El rápido desarrollo iterativo del prototipo es
esencial, de modo que se controlen los costos, y los interesados en el sistema
experimenten por anticipado durante el proceso de software.

Se usa en un proceso de desarrollo de software para contribuir a anticipar los

cambios que se requieran:
1. En el proceso de ingeniería de requerimientos: Un prototipo ayuda con la
selección y validación de requerimientos del sistema.
2. En el proceso de diseño de sistemas: Un prototipo sirve para buscar
soluciones específicas de software y apoyar el diseño de interfaces del usuario.
Los prototipos del sistema permiten a los usuarios ver qué tan bien el sistema apoya
su trabajo. Pueden obtener nuevas ideas para requerimientos y descubrir áreas de
fortaleza y debilidades en el software.

Opciones de prototipos: No tienen que ser ejecutables para ser útiles. Los modelos
en papel de la interfaz de usuario del sistema pueden ser efectivos para ayudar a los
usuarios a refinar un diseño de interfaz y trabajar a través de escenarios de uso. Su
desarrollo es muy económico y suelen construirse en pocos días.
Una extensión de esta técnica es un prototipo de Mago de Oz, donde sólo se
desarrolle la interfaz del usuario. Los usuarios interactúan con esta interfaz, pero sus
solicitudes pasan a una persona que los interpreta y les devuelve la respuesta
adecuada.
Ventajas: - Permite identificar los requisitos incrementalmente.
- Permite probar alternativas a los desarrolladores.
- Tiene una alta visibilidad -> tanto clientes como
desarrolladores ven resultados rápidamente.
Inconvenientes: - El cliente no entiende porque hay que desechar el primer
prototipo, si simplemente ha pedido unos ajustes.
Riesgo de software de baja calidad: Compromisos de
implementación para que el prototipo funcione rápidamente y que al final son parte
integral del sistema. Ej: Utilizar un sistema operativo o lenguaje de programación
inadecuado pero que ya es conocido.
>DESARROLLO FORMAL
MODELO DE MÉTODOS FORMALES
Agrupa actividades que llevan a la especificación matemática formal del software. Los
métodos formales permiten especificar, desarrollar y verificar sistemas por medio del
empleo de una notación matemática rigurosa.

Desarrollo: Cuando durante el desarrollo se usan métodos formales, se obtiene un

mecanismo para eliminar muchos de los problemas difíciles de vencer con otros
paradigmas de la ingeniería de software. Lo ambiguo, incompleto e inconsistente se
descubre y corrige con más facilidad, no a través de una revisión ad hoc sino con la
aplicación de análisis matemático.
Diseño: Se emplean métodos formales, éstos sirven como base para la verificación
del programa, y así periten descubrir y corregir errores que de otro modo no serían
detectados. Aunque el modelo de los métodos formales no es el más seguido,
promete un software libe de defectos.
Preocupaciones: - El desarrollo de modelos formales lleva mucho tiempo y
es caro.
- Debido a que pocos desarrolladores de software tienen la
formación necesaria para aplicar métodos formales, se
requiere mucha capacitación.
- Es difícil utilizar los modelos como mecanismo de
comunicación para clientes sin complejidad técnica.
A pesar de estas preocupaciones, el enfoque de los métodos formales ha ganado
partidarios entre los desarrolladores que deben construir software de primera calidad
en seguridad, y entre los desarrolladores que sufrirían graves pérdidas económicas si
ocurrieran errores en su software.
 >DESARROLLO ORIENTADO A LA REUTILIZACIÓN
MODELO BASADO EN COMPONENTES
Los componentes comerciales de software general (COTS, Commercial Off-The-
Shelf), desarrollados por fabricantes que los ofrecen como productos, brindan una
funcionalidad que se persigue con interfaces bien definidas que permiten que el
componente se integre en el software que se va a construir.
El modelo de desarrollo basado en componentes incorpora muchas de las
características del modelo espiral. Es de naturaleza evolutiva y demanda un enfoque
iterativo para la creación de software. Sin embargo, este modelo construye
aplicaciones a partir de fragmentos de software prefabricados.
Etapas: 1. Se investigan y evalúan, para el tipo de aplicación de que se trate,
productos disponibles basados en componentes.
2. Se consideran los aspectos de integración de los componentes.
3. Se diseña una arquitectura del software para que reciba los
componentes.
4. Se integran los componentes en la arquitectura.
5. Se efectúan pruebas exhaustivas para asegurar la funcionalidad
apropiada.
Reutilización: El modelo lleva la reutilización del software, y eso da a los
ingenieros varios beneficios. Si la reutilización de componentes se vuelve
parte de la cultura, el equipo de ingeniería tiene la posibilidad tanto de
reducir el ciclo de tiempo del desarrollo como el costo del proyecto.

Clase 5 - Tema: Proceso de construcción de software. Actividades del proceso:

especificación, diseño, implementación y validación. Metodologías ágiles.
>PROCESO DE CONSTRUCCIÓN DE SOFTWARE
El proceso de construcción consta de una serie de actividades relacionadas
que conduce a la elaboración de un producto de tupo software.
Estas actividades pueden incluir:
- Un desarrollo de software desde cero en un lenguaje de programación
estándar como Java o C.
- Un desarrollo extendiendo y modificando los sistemas existentes, o
configurando e integrando el software comercial o componentes del
sistema.
Existen diferentes procesos de software, pero todos incluyen cuatro actividades
fundamentales:
1. Especificación: Se define tanto la funcionalidad del software como las
restricciones de su operación.
 2. Diseño e implementación: Diseño y desarrollo de software cumpliendo con
las especificaciones.
3. Validación: Validar el software para asegurarse de que cumple con lo que
el cliente solicitó.
4. Evolución: El software tiene que evolucionar para satisfacer las necesidades
cambiantes del cliente.
Estas 4 actividades son un poco más complejas por lo que pueden incluir
subactividades. Adicionalmente, pueden requerir actividades de soporte, como
documentación y manejo de la configuración del software.

Además de las actividades, el proceso de construcción debe incluir:

- Productos: Son los resultados de una actividad del proceso.

- Roles: Reflejan las responsabilidades del personal que intervienen en el

proceso.
- Precondiciones y postcondiciones: Son declaraciones válidas antes t
después de que se realice una actividad del proceso o se cree un producto.
No hay un proceso ideal. La mayoría de las organizaciones han diseñado sus propios
procesos de desarrollo. Los procesos han evolucionado para beneficiarse de las
capacidades de las personas en una organización y de las características específicas
de los sistemas que se desarrollan.
Clasificación:
- Procesos dirigidos por un plan: Son aquellos donde todas las actividades del
proceso se planean por anticipado y el avance se mide contra dicho plan.
- Procesos ágiles: La planeación es incremental y es más fácil modificar el
proceso para reflejar los requerimientos cambiantes del cliente.
>ESPECIFICACIÓN DEL SOFTWARE
Consiste en comprender y definir qué servicios se requieren del sistema, así
como, la identificación de las restricciones sobre la operación y el desarrollo del
sistema.
Es una etapa crítica, ya que, los errores en ésta conducen a problemas posteriores
tanto en el diseño como en la implementación.
El objetivo es producir un documento convenido que especifique los requerimientos
de los interesados que cumplirá el sistema.
Los requerimientos se representan en dos niveles de detalle:
- Usuarios finales y clientes: Informe de alto nivel de abstracción.
- Desarrolladores: Informe de bajo nivel (más detalles).
Existen 4 actividades principales en la especificación de requerimientos:
1. Estudio de factibilidad: Se realiza una estimación sobre si las necesidades
identificadas del usuario se cubren con las actuales tecnologías de software
y hardware.
El estudio considera si el sistema propuesto tendrá un costo-beneficio
desde un punto de vista empresarial, y su éste puede desarrollarse dentro
de las restricciones presupuestales existentes. El resultado debe informar la
decisión respecto a si se continúa o no con un análisis más detallado.
2. Obtención y análisis de requerimientos: Consiste en derivar los
requerimientos del sistema mediante observación de los sistemas
existentes, discusiones con los usuarios y proveedores potenciales, análisis
de tareas etc.
Esto puede incluir el desarrollo de uno o más modelos de sistemas y
prototipos, lo que ayuda a entender el sistema que se va a especificar.
3. Especificación de requerimientos: Consiste en transcribir la información
recopilada durante la actividad de análisis, en un documento que define un
conjunto de requerimientos.
Se incluyen dos clases de requerimientos: Los de usuario (alto nivel)
descripción abstracta; y los del sistema (bajo nivel) que son una descripción
detallada de la funcionalidad a ofrecer.
4. Validación de requerimientos: Verifica que los requerimientos sea realistas,
coherentes y completos. Durante este proceso es inevitable descubrir
errores en el documento de requerimientos, que luego deberán
subsanarse.
>DISEÑO E IMPLEMENTACIÓN
Consiste en convertir una especificación en un sistema ejecutable. Incluye
procesos de diseño y programación de software, aunque también puede involucrar la
corrección de la especificación.
Un diseño de software se entiende como una descripción de la estructura del
software que se va a implementar, los modelos y las estructuras de datos, las
interfaces entre componentes y, algunas veces, los algoritmos usados.
El proceso de diseño está compuesto por entradas, las actividades y los documentos
generados como salidas.
Entradas:
- Plataforma de Información: La mayoría de los sistemas tienen interfaz junto
con otros sistemas de software (sistema operativo, base de datos). Éstos constituyen
la “plataforma de software”, es decir, el entorno donde se ejecutará el software a
desarrollar. La información sobre esta plataforma es una entrada esencial al proceso
de diseño.
- Especificación de requerimientos: Es una descripción de la funcionalidad que
debe brindar el software, en conjunción con sus requerimientos de rendimiento y
confiabilidad.
- Descripción de datos: Si el sistema debe procesar datos existentes, entonces
en la especificación de la plataforma se incluirá la descripción de tales datos; de otro
modo, la descripción de los datos será una entrada al proceso de diseño, de manera
que se refina la organización del sistema de datos.
Actividades:
1. Diseño arquitectónico: Se identifica la estructura global del sistema, los
principales componentes, sus relaciones y cómo se distribuyen.
2. Diseño de interfaz: Se definen las interfaces entre los componentes del
sistema. Esta especificación de interfaz no tiene que presentar ambigüedades. Con
una interfaz precisa, es factible usar un componente sin que otros tengan que saber
cómo se implementó. Una vez que se acuerdan las especificaciones de interfaz, los
componentes se diseñan y se desarrollan de manera concurrente.
3. Diseño de componentes: Se toma cada componente del sistema y se diseña
cómo funcionará. Esto puede ser un simple dato de la funcionalidad que se espera
implementar, y al programador se le deja el diseño específico. Como alternativa,
habría una lista de cambios a realizar sobre un componente que se reutiliza o sobre
un modelo de diseño detallado. El modelo de diseño sirve para generar en
automático una implementación.
4. Diseño de base de datos: Se diseñan las estructuras del sistema de datos y
cómo se representarán en una base de datos. De nuevo, el trabajo aquí depende de
si una base de datos se reutilizará o se creará una nueva.
Salidas:
El detalle y la representación de las actividades varían consideradamente.
Para sistemas críticos, deben producirse documentos de diseño detallados que
brinden descripciones exactas del sistema.
Si se usa un enfoque dirigido por un modelo, dichas salidas serían sobre todo
diagramas.
Donde se usen métodos ágiles, las salidas no podrían ser documentos de
especificación separados, sino que tendrían que representarse en el código del
programa.
Implementación
Los programadores realizan pruebas para encontrar defectos del programa
que deben eliminarse más tarde. A esta actividad se la llama depuración (debugging).

La prueba de defectos y la depuración son procesos diferentes. La primera

establece la existencia de defectos. La segunda, los localiza y corrige.
Validación (Verificación y validación)
Se crea para mostrar que un sistema cumple tanto con sus especificaciones
como las expectativas del cliente. El proceso de prueba tiene tres etapas, donde los
componentes del sistema se ponen a prueba, luego se hace lo mismo con el sistema
integrado, y finalmente el sistema se pone a prueba con los datos del cliente.
1. Prueba de componentes: Las personas que desarrollan el sistema ponen a
prueba los componentes que constituyen el sistema. Cada componente se
prueba de manera independiente. Por lo general, se usan herramientas de
automatización de pruebas, como JUnit.
2. Pruebas del sistema: Los componentes se integran para crear un sistema
completo. Este proceso tiene la finalidad de descubrir errores que resulten
de interacciones no anticipadas entre componentes y problemas de
interfaz de componente, así como de mostrar que el sistema cubre sus
requerimientos funcionales y no funcionales.
3. Pruebas de aceptación: Ésta es la etapa final, antes de que el sistema se
acepte para uso operacional. El sistema se pone a prueba con datos
suministrados por el cliente, en vez de datos de prueba simulados. Las
pruebas de aceptación revelan los errores y las omisiones en la definición
de requerimientos del sistema. Asimismo, revelan problemas de
requerimientos, donde las instalaciones de sistema en realidad no cumplan
las necesidades del usuario o cuando sea inaceptable el rendimiento del
sistema.
>METODOLOGÍAS DE DESARROLLO
El manifiesto por el desarrollo ágil de software establece:
- Los individuos y sus interacciones, sobre los procesos y las
herramientas.
- El software que funciona, más que la documentación exhaustiva.
- La colaboración con el cliente, y no tanto la negociación del
contrato.
- Responder al cambio, mejor que apegarse a un plan.
Una de las características más atractivas del enfoque ágil es su capacidad de reducir
los costos del cambio durante el proceso de software.
¿Qué es la agilidad en el contexto de la IS?
La agilidad se ha convertido en la palabra mágica de hoy para describir un proceso
de software moderno. Todos son ágiles. Un equipo ágil es capaz de responder de
manera apropiada a los cambios.
Hay cambios en el software que se construye, en los miembros del equipo, debido a
nuevas tecnologías, a otros factores pero que tienen un efecto en el producto que se
elabora o en el proyecto que lo crea.
Por lo tanto, deben introducirse apoyos para el cambio.
Un equipo ágil reconoce que el software es desarrollado por individuos que trabajan
en equipo, y que su capacidad, su habilidad para colaborar, es el fundamento para el
éxito del proyecto.
La presencia del cambio en diversos factores, es el motor principal de la agilidad.
Cualquier proceso ágil se caracteriza por la forma en la que aborda cierto número de
suposiciones clave sobre los proyectos de software:
1. Es difícil predecir qué requerimientos de software persistirán y cuáles
cambiarán. También es difícil pronosticar cómo cambiarán las prioridades del cliente
a medida que avanza el proyecto.
2. Para muchos tipos de software, el diseño y la construcción deben ejecutarse
en forma simultánea, de modo que los modelos de diseño se prueban a medida que
se crean. Es difícil predecir cuánto diseño se necesita antes de que se use la
construcción para probar el diseño.
3. El análisis, el diseño, la construcción y las pruebas no son tan predecibles
como nos gustaría.
>PROCESO ÁGIL
El proceso ágil debe ser adaptable incrementalmente.
Para lograr la adaptación incremental, un equipo ágil requiere retroalimentación con
el cliente. Un catalizador eficaz para la retroalimentación con el cliente es un
prototipo operativo.
La “Alianza Ágil” define 12 principios:
1. La prioridad más alta es satisfacer al cliente a través de la entrega pronta y
continua de software valioso.
2. Son bienvenidos los requerimientos cambiantes, aun en una etapa avanzada
del desarrollo. Los procesos ágiles dominan el cambio para provecho de la ventaja
competitiva del cliente.
3. Entregar con frecuencia software que funcione, de dos semanas a un par de
meses, de preferencia lo más pronto que se pueda.
4. Las personas de negocios y los desarrolladores deben trabajar juntos, a
diario y durante todo el proyecto.
5. Hay que desarrollar los proyectos con individuos motivados. Debe darse a
éstos el ambiente y el apoyo que necesiten, y confiar en que harán el trabajo.
6. El método más eficiente y eficaz para transmitir información a los
integrantes de un equipo de desarrollo, y entre éstos, es la conversación cara a cara.
7. La medida principal de avance es el software que funciona.
8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores,
desarrolladores y usuarios deben poder mantener un ritmo constante en forma
indefinida.
9. La atención continua a la excelencia técnica y el buen diseño mejora la
agilidad.
10. Es esencial la simplicidad: el arte de maximizar la cantidad de trabajo no
realizado.
11. Las mejores arquitecturas, requerimientos y diseños surgen de los equipos
con organización propia.
 12. El equipo reflexiona a intervalos regulares sobre cómo ser más eficaz, para
después afinar y ajustar su comportamiento en consecuencia.
Modelos Ágiles
- Programación Extrema (XP).
- Desarrollo adaptativo de software (DAS).
- Scrum.
- Método de desarrollo de sistemas dinámicos (MDSD).
- Cristal.
- Desarrollo impulsado por las características (DIC).
- Desarrollo esbelto de software (DES).
- Modelado ágil (MA).
- Proceso unificado ágil (PUA).

Clase 6 - Tema: Herramientas y técnicas para modelado de procesos. Ingeniería de

software asistida por computadora.
> INGENIERÍA DE SOFTWARE ASISTIDA POR COMPUTADORA (CASE)
Se refiere al desarrollo y mantenimiento de proyectos de software con la
ayuda de herramientas informáticas.
Herramientas: Las herramientas CASE son un conjunto de aplicaciones
informáticas, usadas para automatizar actividades del ciclo de vida de desarrollo de
software. Son usadas por Directores de Proyectos, Analistas, Ingenieros de Software y
cualquier otro profesional vinculado al proyecto.
El objetivo del uso de herramientas es crear software de calidad en menor tiempo.
Clasificación:
- Upper CASE: Se utilizan en las etapas de planificación, análisis y
diseño.
- Lower CASE: Se utilizan en la implementación, las pruebas y en el
mantenimiento.
-ICASE: Son de utilidad en todas las fases del ciclo de vida.
-IPSE: Incluyen componentes para la gestión de proyectos y de
configuración.
Existen muchas herramientas CASE disponibles para simplificar varias etapas en el
desarrollo del ciclo de vida del software.
- Realizar análisis de especificaciones.
- Modelar el diseño de la arquitectura de un sistema.
- Llevar a cabo la implementación (codificación).
- La gestión de proyectos.
 - La administración de bases de datos.
- Generar la documentación de un sistema.
CASE para Diagramas
Se usan para representar componentes del sistema, datos o para controlar el
flujo de varios componentes y estructura de software de manera gráfica.
CASE para Modelado de Procesos
Permiten crear modelos de proceso de software que luego se usan para
desarrollar software. Ayudan a Directores a elegir un modelo de proceso o
modificarlo según los requerimientos.
CASE para Administración de Procesos
Se usan para la planificación del proyecto, el costo y esfuerzo estimados, la
temporalización y la organización de los recursos. Ayudan a almacenar y a compartir
información sobre el proyecto en tiempo real durante su organización.
CASE para Documentación
La documentación de un proyecto de software empieza antes que el proceso,
pasa por todas las fases del ciclo de vida y concluye con la finalización del proyecto.
Las herramientas de documentación generan documentos tanto para el consumidor
final como para el personal de soporte técnico.
CASE para Análisis
Ayudan a cumplir con los requisitos. De manera automática, examinan si hay
alguna inconsistencia, o información inapropiada en los diagramas, buscan posibles
redundancias u omisiones.
CASE para Diseño
Ayudan a los diseñadores de software a crear la estructura de los programas,
la cual más adelante se puede desglosar en pequeños módulos usando técnicas de
perfeccionamiento. Estas herramientas aportan los detalles de cada módulo y la
interconexión presente entre éstos.
CASE para Gestión de la Configuración
Éstas se encargan de: Control de versión, línea de desarrollo base y control de
cambios.
CASE para Desarrollo Web
Ayudan en el diseño de páginas Web. Las herramientas Web también
producen una vista preliminar en directo de lo que se está desarrollando y cómo será
una vez terminado.
CASE para Aseguramiento de la calidad
Es la supervisión del proceso de ingeniería y de los métodos adoptados para
desarrollar el producto, asegurando conformidad con la calidad según los estándares
organizativos. La calidad podemos tratar de asegurarla con herramientas de control
de cambios y configuración; pero además también, con herramientas de pruebas o
testing.
CASE para Mantenimiento
Incluye modificaciones en el producto después de ser distribuido. Algunas de
las herramientas CASE que ayudan en la organización y la fase de mantenimiento son
las técnicas de inicio automático y de reporte de error, producción automática de
etiqueta de error y de Análisis de Causa Raíz.

Clase 7 - Tema: El proceso de requerimientos. Requerimientos funcionales, no

funcionales, del usuario, del sistema. Características de los requerimientos.

El Proceso de Requerimientos
Los REQUERIMIENTOS para un sistema son descripciones de lo que el sistema debe
hacer.

El servicio que las restricciones en

ofrece. su operación.
Los requerimientos reflejan las necesidades de los clientes por un sistema que
atienda cierto propósito.
Al proceso de DESCUBRIR, ANALIZAR, DOCUMENTAR y VERIFICAR estos servicios y
restricciones se los conoce como Ingeniería de Requerimientos (IR).
Algunos PROBLEMAS durante el proceso IR, son por no hacer una separación clara
entre estos diferentes niveles de descripción.
 Requerimientos del Usuario: para presentar los requerimientos abstractos de
alto nivel.

 Requerimientos del Sistema: para caracterizar la descripción detallada de lo

que el sistema debe hacer.

USUARIO
Son enunciados, en un lenguaje natural junto con una serie de diagramas,
acerca de qué servicios esperan los usuarios del sistema, y de las restricciones
con las cuales éste debe operar.
SISTEMA
Son descripciones más detalladas de las funciones, los servicios y las restricciones
operacionales del sistema. El documento de requerimientos del sistema
(especificación funcional) tiene que definir con exactitud de que se implementará.
Puede formar parte del contrato entre el comprador del sistema y los desarrolladores
del software.
Los requerimientos del sistema no sólo detallan los servicios o las características que
se requieren del mismo, sino también especifican la funcionalidad necesaria para
asegurar que estos servicios y características se entreguen de manera adecuada.
ANALISIS COMPLETO DE UN EJEMPLO

Los diferentes niveles de requerimientos son útiles debido a que informan sobre el
sistema a distintos tipos de lectores. La figura que veremos a continuación, refleja la
diferencia entre los requerimientos del usuario y del sistema.

Sistema de administración de pacientes para apoyar la atención a la salud mental

(MHC-PMS), muestra cómo los requerimientos del usuario se extienden hacia varios
requerimientos del sistema.

R. de usuario:
1- El MHC-PMS elaborará mensualmente informes administrativos que revelen
el costo de los medicamentos prescriptos para cada clínica durante ese mes.

Especificación de los R. del sistema:

1-En el último día laboral de cada mes se redactará un resumen de los
medicamentos prescriptos, su costo y las clínicas que los prescriben.
2- El Sistema elaborará automáticamente el informe que se imprimirá después
de las 17.30 del último día laboral del mes.
3-Se realizará un reporte para cada clínica junto con los nombres de cada
medicamento, el número de prescripciones, las dosis prescritas y el coso total de los
medicamentos prescriptos.
4- Si los medicamentos están disponibles en diferentes unidades de dosis (ej.
10mg, 20mg) se harán informes por separado para cada unidad de dosis.
5- El acceso a los informes de costos se restringirá a usuarios autorizados en la
lista de control de acceso administrativo.

Se observa que el req. de USUARIO es muy general. Los del SISTEMA ofrecen
información más específica sobre los servicios y las funciones del sistema que se
implementará.
LECTORES de los requerimientos
Es necesario escribir los requerimientos con diferentes niveles de detalle, ya que,
varios lectores los usarán de distintas formas.
USUARIOS: Gerentes del clientes – Usuarios finales del sistema – Ingenieros del
clientes – Gerentes de los contratistas – Arquitectos del sistema.
SISTEMA: Usuarios finales del sistema – Ingenieros del cliente – Arquitectos del
sistema – Desarrolladores de software.

REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

Los requerimientos no son INDEPENDIENTES y que un requerimiento genera o
restringe normalmente a otros.
Clasificación
Funcionales: Son enunciados acerca de servicios que el sistema debe proveer, de
cómo debería reaccionar el sistema a entradas particulares y de cómo debería
comportase el sistema en situaciones específicas. En algunos casos, también explican
lo que NO debe hacer el sistema.
No funcionales: Son limitaciones sobre servicios o funciones que ofrece el sistema.
Incluyen restricciones tanto de temporización y del proceso de desarrollo, como
impuestas por los estándares. Se sueles aplicar al sistema como un todo, más que a
características o a servicios individuales del sistema.
Un requerimiento de usuario interesado por la seguridad, parecería un requerimiento
no funcional, pero este requerimiento puede generar otros que son evidentemente
funcionales, como la necesidad de incluir un módulo de autenticación al sistema.
Al expresar como requerimiento del usuario, los requerimientos funcionales se
describen por lo general de forma abstracta para que entiendan los usuarios del
sistema. Sin embargo, requerimientos funcionales más específicos, detallan las
funciones del sistema, sus entradas y salidas, sus excepciones, etc.

REQUERIMIENTOS FUNCIONALES – EJEMPLO.

Seguimos con el ejemplo de MHC-PMS.
Requerimientos funcionales:
1- Un usuario podrá buscar en todas las clínicas las listas de citas.
2- El sistema elaborará diariamente, para cada clínica, una lista de pacientes
que se espera que asistan a cita ese día.
3- Cada miembro del personal que usa el sistema debe identificarse de
manera individual con un número de ocho dígitos. – Falta seguridad y aclarar cosas.
4- Aclarar cómo sería la búsqueda en el punto 1.
Estos requerimientos del usuario definen las actividades específicas que debe
proporcionar el sistema.
Se tomaron del documento de requerimientos del usuario y muestran que los
requerimientos funcionales pueden escribirse con diferentes niveles de detalle
(observar el 1 y 3).
La inexactitud en la especificación de requerimientos causa muchos problemas en la
IS. Es natural que un desarrollador interprete un requerimiento ambiguo de forma
que simplifique su implementación, pero seguro no es lo que desea el cliente. Por lo
tanto, tienen que establecerse nuevos requerimientos y efectuar cambios de sistema.
Esto generará demoras en la entrega del sistema y aumentarán los costos.
En el caso del primer ejemplo de requerimiento se establece que un usuario podrá
buscar las listas de citas en todas las clínicas. El motivo para ese requerimiento es
que los pacientes con problemas de salud mental en ocasiones están confundidos.
Quizá tengan una cita en una clínica y en realidad acudan a una diferente. De ahí que
si tienen una cita, se registrará que asistieron, sin importar la clínica.
Los miembros del personal médico que especifican esto quizás esperen que
<buscar> significa que, dado el nombre del paciente, el sistema busca dicho nombre
en las citas de todas las clínicas. Sin embargo, esto no es claro en el requerimiento.
Los desarrolladores, pueden interpretar el requerimiento de forma diferente e
implementar una búsqueda, de tal modo que el usuario deba elegir una clínica y
luego buscar. Evidentemente, esto implicará más entradas del usuario y llevará más
tiempo.
Las ESPECIFICACION de los requerimientos FUNCIONALES de un sistema deben ser
completa y consistente.

COMPLETA: Se deben definir todos los servicios requeridos por el usuario.

CONSISTENTE: Los requerimientos tienen que evitar definiciones contradictorias.

REQUERIMIENTOS NO FUNCIONALES (RNF)

No se relacionan directamente con los servicios específicos que el sistema entrega a
sus usuarios. Pueden relacionarse con propiedades emergentes del sistema, como
seguridad, tiempo de respuesta y uso de almacenamiento. De forma alternativa,
pueden definir restricciones sobre la implementación del sistema, como las
capacidades de los dispositivos E/S o las representaciones de los datos.
Los RNF, como el rendimiento, la seguridad o la disponibilidad, especifican o
restringen por lo general características del sistema como un todo.
Afectan más la arquitectura global de un sistema que los componentes individuales.
Ej: Para garantizar que se cumplan los requerimientos de rendimiento, quizá se deba
organizar el sistema para minimizar las comunicaciones entre componentes.
Un RNF individual, como un requerimiento de seguridad, podría generar algunos
requerimientos funcionales relacionados que definan nuevos servicios del sistema y
podría generar requerimientos que restrinjan los requerimientos ya existentes.
CLASIFICACION
Surgen a través de necesidades del usuario, debido a restricciones presupuestales,
políticas de organización, necesidad de interoperabilidad con otro software o
hardware, o factores externos como regulaciones de seguridad o legislación sobre
privacidad.
Req del producto: Especifican o restringen el comportamiento del software.
Ej: req de rendimiento sobre qué tan rápido se debe ejecutar el sistema y
cuánta memoria requiere, req de fiabilidad que establecen la tasa aceptables de
fallas, req de seguridad y req de usabilidad.
Req de la organización: Son req derivados de políticas y procedimientos en la
organización del cliente y del desarrollador.
Ej: req del proceso operacional que definen como se usara el sistema, req
del proceso de desarrollo que especifican el lenguaje de programación, estándares
del entorno o el proceso de desarrollo a utilizar, y req ambientales que definen el
entorno de operación del sistema.
Req externos: Cubre todos los req derivados de factores externos al sistema y su
proceso de desarrollo.
Ej: req regulatorios que establecen lo que debe hacer el sistema para ser
aprobado en su uso por un regulador (banco central); req legislativos que tienen
que seguirse para garantizar que el sistema opere conforme a la ley, y req éticos que
garanticen que el sistema será aceptable para sus usuarios y el público en general.
EJEMPLO (MHC-PMS)
Requerimientos del producto, de la organización y externos.
Requerimientos No funcionales:
1-Req del producto: El MHC-PMS estará disponible en todas las clínicas
durante las horas de trabajo normales (lunes a viernes, de 8.30 a 17.30). En cualquier
día, los tiempos nuestros dentro de las horas laborales normales no rebasaran los
cinco segundos.
2-Req de la organización: Los usuarios del sistema se acreditaran a sí mismos
con el uso de la tarjeta de identidad de la autoridad sanitaria.
3-Req externo: Como establece la HStan-03-2006-priv, el sistema
implementará provisiones para la privacidad del paciente.
Un problema común con RNF es que los usuarios o clientes proponen estos
requerimientos con metas generales, como facilidad de uso, capacidad de que el
sistema se recupere de fallas, o rapidez de respuesta al usuario. Ej: la siguiente meta
del sistema es típica de como un administrador expresa los req de usabilidad.
Siempre que sea posible, hay que escribir de manera cuantitativa los RNF, para que
puedan ponerse objetivamente a prueba.

Clase 8 - Tema: Tareas de la ingeniería de requisitos: inicio, obtención, elaboración,

negociación, especificación, validación y gestión de los requisitos.

>TAREAS DE LA INGENIERÍA DE REQUISITOS

Proporciona el mecanismo apropiado para entender lo que desea el cliente, analizar
las necesidades, evaluar la factibilidad, negociar una solución razonable, especificar la
solución sin ambigüedades, validar la especificación y administrar los requerimientos
a medida de que se transforman en un sistema funcional.
Incluye 7 tareas diferentes:
- Concepción: Una conversación casual es todo lo que se necesita para
desencadenar un trabajo grande de desarrollo de software. La mayoría de
los proyectos comienzan cuando se identifica una necesidad o se descubre
un nuevo mercado.
Se establece el entendimiento básico del problema.
- Indagación: Se pregunta al cliente, a los usuarios, entre otros, cuales son
los objetivos para el sistema o producto y cómo va a usarse el sistema o
producto.
Problema de alcance: La frontera de los sistemas está mal definida o los
clientes o usuarios finales especifican detalles técnicos innecesarios que
confunden, los objetivos generales del sistema.
Problemas de volatilidad: Los requerimientos cambian con el tiempo.
Problemas de entendimiento: Los clientes o usuarios no están
complemente seguros de lo que se necesita o solicitan requerimientos
ambiguos o que no pueden someterse a prueba.
- Elaboración: La información obtenida del cliente durante la concepción e
indagación se expande y refina durante la elaboración. Esta tarea se centra
en desarrollar un modelo refinado de los requerimientos que identifique
distintos aspectos de la función del software, su comportamiento e
información.
- Negociación: No es raro que los clientes pidan más de lo que puede
lograrse dado lo limitado de los recursos del negocio. También es
relativamente común que distintos clientes propongan requerimientos
conflictivos con el argumento de que su versión es “esencial para nuestras
necesidades especiales”.
- Especificación: Puede ser un documento escrito, un conjunto de modelos
gráficos, un modelo matemático formal, etc. Algunos sugieren que para
una especificación debe desarrollarse y utilizarse una “Plantilla estándar”,
 con el argumento de que esto conduce a requerimientos presentados en
forma consistente y por ello más comprensible. Sin embargo, en ocasiones
es necesario ser flexible cuando se desarrolla una especificación.
- Validación: La validación de los requerimientos analiza la especificación a
fin de garantizar que todos ellos han sido enunciados sin ambigüedad; que
se detectaron y corrigieron las inconsistencias, las omisiones y los errores, y
que los productos del trabajo se presentan conforme a los estándares
establecidos para el proceso, el proyecto y el producto.
- Administración: Los requerimientos para sistemas basados en computadora
cambian, y el deseo de modificarlos persiste durante toda la vida del
sistema. La administración de los requerimientos es el conjunto de
actividades que ayudan al equipo del proyecto a identificar, controlar y dar
seguimiento a los requerimientos y a sus cambios en cualquier momento
del desarrollo del proyecto.

Clase 9 - Tema: Los problemas de la comunicación. Técnicas de comunicación.

Estándar IEEE 830.
>LOS PROBLEMAS DE LA COMUNICACIÓN
La especificación de requerimientos es el proceso de escribir, en un
documento específico, los requerimientos del usuario y del sistema.
Éstos deben ser claros, sin ambigüedades, fáciles de entender, completos y
consistentes. En la práctica es muy difícil de lograr.

Comunicando los requerimientos del usuario:

Los requerimientos para un sistema deben describir deben describir los
requerimientos funcionales y no funcionales, de forma que sean comprensibles para
los usuarios del sistema que no cuentan con un conocimiento técnico detallado.
Deberían especificar sólo el comportamiento externo del sistema. No se debe
incluir detalles de la arquitectura o del diseño del sistema. Solo lenguaje
NATURAL.

Comunicando los requerimientos del sistema:

Los requerimientos son versiones extendidas de los requerimientos del usuario que
los ingenieros usan como punto de partida para el diseño del sistema. Agregan
detalles y explican cómo el sistema debe brindar los requerimientos del usuario. Se
pueden usar como parte del contrato para la implementación del sistema y, por lo
tanto, deben ser una especificación completa y detallada de todo el sistema. Deben
describir de manera simple el comportamiento externo del sistema y sus
restricciones operacionales. No tienen que ocuparse de cómo se diseña o
implementa el sistema. El nivel de detalle requerido para especificar por completo
un sistema de software complejo, es prácticamente imposible excluir toda la
información de diseño. Hay varias razones:
- Tal vez se tenga que diseñar una arquitectura inicial del sistema para ayudar
a estructurar a especificación de requerimientos. Los requerimientos del sistema se
organizan de acuerdo con los diferentes subsistemas que constituyen el sistema.
- En la mayoría de los casos, los sistemas deben interoperar con los sistemas
existentes, lo cual restringe el diseño e impone requerimientos sobre el nuevo
sistema.
- Quizá sea necesario el uso de una arquitectura específica para cubrir los
requerimientos no funcionales.
Consideraciones finales:
- Los requerimientos del usuario se escriben casi siempre en lenguaje natural,
complementado con diagramas y tablas.
- Los requerimientos del sistema se escriben también en lenguaje natural,
pero de igual modo se utilizan otras notaciones basadas en formas, modelos gráficos
del sistema o modelos matemáticos del sistema.
>ESPECIFICACIÓN EN LENGUAJE NATURAL
Desde el principio, el lenguaje natural se usa para escribir los requerimientos
de software. Es expresivo, intuitivo y universal; pero es potencialmente vago,
ambiguo y su significado depende del lector.
Para minimizar la interpretación errónea se recomienda:
- Elaborar un formato estándar y asegurarse de que todas las definiciones de
requerimientos se adhieran a dicho formato.
- Utilizar el lenguaje de manera clara para distinguir entre requerimientos
obligatorios (req. del sistema y se escriben en futuro) y deseables (no son necesarios
y se escriben en condicional).
- Usar texto resaltado para seleccionar partes clave del requerimiento.
- No deducir que los lectores entienden el lenguaje técnico de la ingeniería de
software.
-Asociar una razón con cada requerimiento de usuario. La razón debe explicar
por qué se incluyó el requerimiento.

>ESPECIFICACIONES ESTRUCTURADAS
Este lenguaje es una manera de escribir requerimientos del sistema, donde
está limitada la libertad del escritor y se escribe de forma estándar.
Aunque este enfoque conserva la mayoría de la expresividad y comprensibilidad del
lenguaje natural, asegura que haya cierta uniformidad sobre la especificación.
- Emplean plantillas para especificar requerimientos del sistema.
- Utiliza construcciones de lenguaje de programación para mostrar alternativas
e iteración.
-Destaca elementos clave con el uso de sombreado o de fuentes distintas.
- Hay que definir una o más plantillas estándar para requerimientos, y
representar dichas plantillas como formas estructuradas.
Se debe incluir la siguiente información:
1. Una descripción de la función o entidad a especificar.
2. Una descripción de sus entradas y sus procedencias.
3. Una descripción de sus salidas y a dónde se dirigen.
4. Información sobre los datos requeridos para el cálculo u otras entidades en
el sistema que se utilizan.
5. Una descripción de la acción que se va a tomar.
6. Si se usa un enfoque funcional, una precondición establece lo que debe ser
verdadero antes de llamar a la función, y una post condición especifica lo que es
verdadero después de llamar a la función.
7. Una descripción de los efectos colaterales de la operación.
> EL DOCUMENTO DE REQUERIMIENTOS DE SOFTWARE O SRS
Es un comunicado oficial de lo que deben implementar los desarrolladores del
sistema. Incluye tanto los requerimientos del usuario para un sistema, como una
especificación detallada de los requerimientos del sistema.
Opiniones encontradas:
Los métodos de desarrollo tradicionales, sostienen que los documentos de
requerimientos son muy importantes.
Los métodos de desarrollo ágiles, argumentan que los requerimientos
cambian tan rápidamente que un documento de requerimientos se vuelve obsoleto
tan pronto como se escribe, así que el esfuerzo se desperdicia en gran medida.
En lugar de un documento formal, los enfoques como la programación extrema
recopilan de manera incremental requerimientos del usuario y los escriben en
tarjetas como historias de usuario. De esa manera, el usuario da prioridad a los
requerimientos para su implementación en el siguiente incremento del sistema.
Usuarios del documento:
El documento de requerimientos tienen un conjunto variado de usuarios,
desde el administrador ejecutivo de la organización que paga por el sistema, hasta
los ingenieros responsables del desarrollo del software. La figura que veremos a
continuación, muestra a los posibles usuarios del documento y cómo lo utilizan.
La diversidad de posibles usuarios significa que el documento de
requerimientos debe ser un compromiso entre: la comunicación de los
requerimientos a los clientes, la definición de los requerimientos con detalle preciso
para desarrolladores, y la inclusión de información sobre la posible evolución del
sistema.

>NIVEL DE DETALLE
El nivel de detalle que se incluya en un documento de requerimientos depende del
tipo de sistema a diseñar y el proceso de desarrollo utilizado:
- Los sistemas críticos necesitan tener requerimientos detallados.
- Cuando el sistema lo desarrolla una compañía independiente, deben
detallarse y precisarse las especificaciones del sistema.
- Si se utiliza un proceso de desarrollo iterativo interno, entonces el
documento de requerimientos suele ser mucho menos detallado y cualquier
ambigüedad puede resolver durante el desarrollo del sistema.
> ESTRUCTURA DEL DOCUMENTO
La organización para un documento de requerimientos se basa en un estándar del
IEEE para documentos de requerimientos. Este estándar es genérico y se adapta a
usos específicos. En este caso, el estándar se extendió para incluir información de la
evolución prevista del sistema. Esta información ayuda a los encargados del sistema y
permite a los diseñadores incluir soporte para características futuras del sistema.
Prefacio: Debe definir el número esperado de lectores del documento, así como
describir su historia de versiones, incluidas las causas para la creación de una nueva
versión y un resumen de los cambios realizados en cada versión.
Introducción: Describe la necesidad para el sistema. Debe detallar brevemente las
funciones del sistema y explicar cómo funcionará con otros sistemas. También tienen
que indicar cómo se ajusta el sistema en los objetivos empresariales o estratégicos
globales de la organización que encargó el desarrollo.
Glosario: Define los términos técnicos usados en el documento. No debe hacer
conjeturas sobre la experiencia o la habilidad del lector.
Definición de requerimientos del usuario: Aquí se representan los servicios que
ofrecen al usuario. También, se describen los requerimientos no funcionales del
sistema. Se puede usar el lenguaje natural, diagramas, etc.
Arquitectura del sistema: Este capítulo presenta un panorama de alto nivel de la
arquitectura anticipada del sistema, que muestra la distribución de funciones a través
de los módulos del sistema. Hay que destacar los componentes arquitectónicos que
sean de reutilización.
Especificación de requerimientos del sistema: Debe representar los requerimientos
funcionales y no funcionales con más detalle. Si es preciso, también pueden
detallarse más los requerimientos no funcionales. Pueden definirse las interfaces a
otros sistemas.
Modelos del sistema: Pueden incluir modelos gráficos del sistema que muestren las
relaciones entre componentes del sistema, el sistema y su entorno.
Evolución del sistema: Describe los supuestos fundamentales sobre los que se basa el
sistema, y cualquier cambio anticipado debido a evolución de hardware, cambio en
las necesidades del usuario, etc.
Apéndices: Brindan información específica y detallada que se relaciona con la
aplicación a desarrollar.
Índice: Pueden incluirse en el documento varios índices.
> UN ESTÁNDAR PARA EL DOCUMENTO
El estándar IEEE 830-1998 para el SRS es un conjunto de recomendaciones para la
especificación de los requerimientos o requisitos de software el cual tiene como
producto final la documentación de los acuerdos entre el cliente y el grupo de
desarrollo para así cumplir con la totalidad de exigencias estipuladas.

Teoría 11
Tema: Calidad a nivel proceso y producto en el desarrollo del software. Modelos de
calidad del software.
Introducción
Según David Garvin, sugiere que “la calidad es un concepto complejo y de
facetas múltiples” que se puede describir desde cinco puntos de vista diferentes:
- El punto de vista trascendental: dice que la calidad es algo que se reconoce
de inmediato, pero que no es posible definir explícitamente.
- El punto de vista del usuario: Concibe la calidad en términos de las metas
específicas del usuario final. Si un producto las satisface, tiene calidad.
- El punto de vista del fabricante: La define en términos de las especificaciones
originales del producto. Si éste las cumple, tiene calidad.
- El punto de vista del producto: Sugiere que la calidad tiene que ver con las
características inherentes (funciones y características) de un producto.
- El punto de vista basado en el valor: La mide de acuerdo con lo que un
cliente está dispuesto a pagar por un producto.

Calidad de un software: “Proceso eficaz de software que se aplica de manera que crea
un producto útil que proporciona valor medible a quienes lo producen y a quienes lo
utilizan”
Y ésta enfatiza tres puntos importantes:
1. Un proceso eficaz de software establece la infraestructura para la
elaboración de un producto de software de alta calidad.
Diapo 16
La calidad subjetiva de un sistema de software se basa principalmente en sus
características no funcionales. Por consiguiente, la calidad del software no sólo se
trata de si la funcionalidad de éste se implementó correctamente, sino también
depende de los atributos no funcionales del sistema.

Existen 15 atributos de calidad de software:

Protección:
Comprensibilidad:
Portabilidad: Esta categoría define aspectos relacionados con la capacidad de un
sistema software para ser transferido desde una plataforma a otra. Las sub
características son: capacidad de instalación, capacidad de sustitución, adaptabilidad,
coexistencia, compatibilidad con hardware o software , etc.
Seguridad: Visiones
- Comprobar la identidad de las personas que intentan acceder al
sistema.
- Garantizar que sólo las personas específicamente autorizadas pueden
ver determinada porción de la información del sistema.
- Garantizar que sólo las personas específicamente autorizadas pueden
modificar determinada porción de la información del sistema o bien realizar
determinada acción.
Comprobabilidad:
Usabilidad: Capacidad del producto software para adherirse a normas, convenciones
o regulaciones relacionadas con la usabilidad.
Fiabilidad: Capacidad del producto software para adherirse a normas, convenciones
o regulaciones relacionadas con la fiabilidad.
Adaptabilidad: Capacidad del producto software para ser adaptado a diferentes
entornos especificados, sin aplicar acciones o mecanismos distintos de aquellos
proporcionados para este propósito por el propio software considerado.
Reusabilidad:
Flexibilidad:También llamada modificabilidad, es la capacidad para admitir cambios
que puede ser necesarios tanto por un cambio de requerimientos como por la
detección de un error que debe ser corregido. Una variante de flexibilidad es la
extensibilidad, es decir, la posibilidad de agregar nuevos requerimientos.
Modularidad:
Eficiencia: Capacidad del producto software para adherirse a normas o convenciones
relacionadas con la eficiencia.
Robustez: Robusto es un sistema que goza de buena salud y que brinda garantías de
que va a continuar teniendo buena salud. Algunos síntomas de un sistema robusto
son:
- La capacidad de ser modificado sin introducir errores (opuesto a error
prone).
- Durabilidad del sistema funcionando correctamente (no aparecen errores
aleatorios)
Diferentes usuarios tendrán diferentes visiones de la robustez del sistema
Complejidad:
Facilidad para que el usuario aprenda a utilizarlo: “Usabilidad”: La facilidad con la
que el sistema o componentes se pueden utilizar o bien aprender a utilizar

WhatsApp es una forma rápida, segura y confiable para que las empresas lleguen a sus clientes
de todo el mundo. En esta guía, se describe cómo las empresas pueden usar la API de
WhatsApp Business para interactuar con los clientes.

Esta versión de la API usa una arquitectura de REST con formatos de datos JSON. La API usa el
intercambio estándar de solicitud y respuesta HTTP.

Nodos raíz de la API de WhatsApp Business

Nodo Descripción

Contacts Permite verificar los números de teléfono de los clientes para generar identificadores de What

Groups Permite crear y administrar grupos

Health Permite consultar el estado de la aplicación de WhatsApp

Media Permite subir, eliminar y recuperar contenido multimedia

Messages Permite enviar texto, contenido multimedia, plantillas de mensajes y mensajes grupales
 Nodo Descripción

Metrics Permite recopilar los resultados de la aplicación web

Account Permite registrar la cuenta de WhatsApp

Settings Permite configurar la aplicación de WhatsApp

Stats Permite recopilar las estadísticas de la base de datos y de la aplicación principal

Support Permite obtener ayuda para usar la API de WhatsApp Business

Users Permite iniciar sesión en el token de autenticación y administrar usuarios

Luego de investigar la documentación de la API de WhatsApp, llegamos a

la conclusión que esta se encuentra modularizada y separada en las
distintas funciones, lo que llevaría a que la modificación de un módulo no
intervenga de manera abrupta sobre el resto.