CLASES TEORICAS

Clase 19/03/2010

SOFTWARE

Software - Hardware - Comunicaciones

En la actualidad, lo que hace distintivo a una empresa es el software, es el factor

distintivo de la misma.
El software diferencia a una marca de otra.
Hay software embebido en un montón de productos de uso cotidiano.
La industria del Software es cada vez más importante.

Tenemos que construir Software que sea confiable, debemos utilizar la experiencia.
Hacer Software de determinada manera  Ingeniería de Software.
Seguir determinados principios y un enfoque para cumplir con la calidad necesaria.

El Software tiene características propias en base a su construcción.

Casi siempre los productos tienen su mejor momento al comienzo.

El Software es distintivo, una vez que funciona, se mantiene hasta que dejo de
usarlo.

Lo mejor es hacer las cosas, siguiendo ciertos principios (Pasos)

Cosas mínimas a tener en cuenta, para desarrollar Software (marco de trabajo)
Cuadro sinóptico (índice de lo que va a hacer la materia). Es un marco teórico.

5 ETAPAS BÁSICAS DEL DESARROLLO DE SOFTWARE

- ANÁLISIS
- DISEÑO
- CODIFICACIÓN CICLO DE VIDA BÁSICO PARA EL DESARROLLO DE
SOFTWARE
- PRUEBA
- PUESTA EN MARCHA

PRESSMAN llama Despliegue a la etapa de Puesta en Marcha

Y pone la Etapa de Prueba, dentro de la Etapa de Codificación

ACTIVIDADES DE SOMBRILLA
Se denominan Actividades Sombrilla a una serie de actividades (paraguas) que le
dé calidad a lo que hacemos, es decir al Producto Final. Dichas Actividades
protegen la calidad del desarrollo, aunque podrían no llevarse a cabo con el riesgo
de perder calidad.

- Seguimiento y Control: ANALISIS

Los Líderes del Proyecto son quienes deben Encargarse de esto.

- Gestión del Riesgo DISEÑO

Backup de cosas que pueden afectar al proyecto.

- Asegurar Calidad CODIFICACION

- Previsiones Técnicas Formales (Auditorías)

PUESTA EN
- Mediciones y Métricas
MARCHA
Ver como estamos parados y ver si estamos bien o mal.
Ver cuantas líneas de código se pueden hacer en una hora. PRUEBA
Determinado Software, cuanto ocupa en memoria.

- Gestión de Configuraciones
Un Software puede tener varias configuraciones

- Gestión de la reutilización

- Productos de Trabajo
Todo esto hay que documentarlo y armar un producto de trabajo.

HACER SOFTWARE ES:

ETAPAS + ACTIVIDADES SOMBRILLAS

ANTES  Calidad = Costo

AHORA  Calidad = Inversión (Es Necesaria)

El desarrollo de Software, no empieza por las etapas de ANALISIS, si no hay una

Comunicación Inicial.
En el primer contacto, la primer charla con el Cliente, se ve que es lo que éste
necesita, incluso se habla de números, lo habla el Gerente (más alto nivel).

MARCO DE TRABAJO: ETAPAS + PARAGUAS + ETAPAS INICIALES

El marco de trabajo para un Proyecto Informático, tanto para hacer un Software
desde cero, como para adaptar SAP.

- COMUNICACIÓN INICIAL

INICIO - ESTUDIO DE FACTIBILIDAD Me interesa, no me interesa

Lo puedo hacer o no pueden ir
juntos
- PLAN DE TRABAJO Y PRESUPUESTO Pressman habla de esto.

ANALISIS
DISEÑO
CODIFICACION
PRUEBA
PUESTA EN MARCHA

GARANTIA  ES OBLIGATORIO  Debo cumplir con lo pactado

- Comunicación
- Estudio de Factibilidad INICIO
MANTENIMIENTO
Clase Teórica 26/03/2010

Cuando llegamos al Plan y Presupuesto, tenemos que pensar en los modelos de

desarrollo de Software.

PROBLEMAS A LOS CUALES NOS ENFRENTAMOS EN EL DESARROLLO DE

SOFTWARE:

- TAMAÑO:
No es lo mismo un Software grande, que un Software chico o construir un Software
para una empresa grande que construir un Software para una empresa chica.

- COMPLEJIDAD PARA OBTENER REQUISITOS:

No todos los desarrollos tienen claramente prefijado que es lo que necesito hacer.
Puede no estar claro en la empresa o no me lo saben transmitir correctamente, etc.

- COMPLEJIDAD TÉCNICA:
Lenguaje específico, interactúa con otro Software o persona, el tiempo real.

- TIEMPOS:
A veces el tiempo es una variable predefinida o acotada, cumplir fechas o
determinados plazos.

- RIESGOS:
Escenarios riesgosos, por las características del escenario puede hacer que el
proyecto se aborte. Ej: Temas políticos, cambio de gobierno.

MODELOS PARA EL DESARROLLO DE SOFTWARE:

Formas de desarrollar las etapas genéricas de Software, para evitar las

problemáticas mencionadas.

Hay varios modelos básicos que luego pueden combinarse de acuerdo al caso que
se nos presente.

1). MODELO LINEAL SECUENCIAL: (CASCADA O CICLO DE VIDA - 5 ETAPAS)

- INGENIERIA DE REQUISITOS:
Construir en esta etapa los requisitos para una aplicación
Analizar u observar (Puede no haber sistemas o personas)
Hago todos los esfuerzos necesarios para buscar esos requisitos.

- DISEÑO:
Vemos como solucionar el problema y cumplir con los requisitos.

- CODIFICACION:
Programo la solución siguiendo el diseño definido.

- PRUEBA:

- PUESTA EN MARCHA o DESPLIEGUE:

Puesta en marcha o funcionamiento del Software, capacitación de usuarios, etc.

Estas Etapas se introducen en forma Lineal y Secuencial

Ing. De Req.  D  C  P  D

Este modelo tiene el inconveniente que si encuentro al problema en una etapa no

podría volver para atrás (Ya que dejaría de ser secuencial)
También hay problemas de bloqueos (retrasos), demoras en la entrega.
En el sistema que menos tiempo lleve.
No lo usaría si hay mucho riesgo.
Los requisitos si ó si deben definirse al comienzo. (Ese es un problema)

2). MODELO LINEAL SECUENCIAL INTERACTIVO O INCREMENTAL:

Si se complica no hagamos todo junto, sino hagamos incrementos. Posee las

mismas etapas que el Modelo Lineal Secuencial del punto 1.

Se trabaja con versiones incrementales.

La versión es terminada y siempre debe funcionar. Ej: Módulos, Office.

- Tengo más probabilidades de definir todos los requerimientos al principio.

- Soluciona el problema de cobrar.

- Puede ocurrir que no consiga los requisitos o no me los saben explicar.

- A veces hay distintos lenguajes.

Para solucionar estos inconvenientes a veces no se construye un software, sino un

prototipo. (Maqueta del arquitecto)

3). MODELO DE PROTOTIPO (SI O SI SE VA A MEZCLAR CON OTRO MODELO)

Construir algo similar a lo que va a ser en la realidad.

Ver con el usuario para que decida si es lo que necesita.
Puede ser un Programa o una Presentación con algunas pantallas.

- Requisitos
- Diseño con Prototipo
- Construcción Ingeniería de
Requisitos.
- Prueba Sigue en la 1er Etapa de
- Despliegue y Retroalimentación Desarrollo de Software
(Puede surgir un nuevo prototipo o cambios en el prototipo

Usaríamos Prototipos cuando tenemos problema con la complejidad en los

requisitos, también cuando hay complejidad técnica.

4). MODELO ESPIRAL

Análisis de Riesgo  Debe haber un acuerdo previo con el Cliente y convencerlo

que estoy haciendo que se ahorren y no que pierdan.

Prevé la posibilidad de no continuar con el desarrollo.

Por Ejemplo, si se implementa algún otro sistema, el sistema que estamos haciendo
no tiene sentido (Escenario de Riesgo o Cambios e tipo Político). De esta forma al
analizar el riesgo perdemos menos.

¿Por qué no hacemos siempre análisis de riesgo?

No todos los proyectos pueden ser abortados, por ejemplo un sistema chico o si
están asociados a licitaciones, puede ser más caro salirse del proyecto, que
terminarlo.

A veces es difícil saber a quién creerle, si tengo que ver las encuestas a quien le
creo INDEC, como voy a saber quién gana las próximas elecciones.

Después tengo el riesgo de que el análisis o encuesta, este mal hecho.

5). MODELO DE DESARROLLO RAPIDO DE APLICACIONES (RAID)

Aparición de herramientas de desarrollo avanzada, que permiten la generación de

códigos de forma automatizada.

Asistentes, generadores de códigos.

Estas herramientas hacen que se reduzcan las etapas de Diseño, Codificación,

Prueba.

Generamos código muy rápido y de esa forma el Software se genera en muy poco
tiempo.

Dos situaciones de importancia:

1. Compromiso de la Empresa (Respuesta Rápida)

2. Debo tener a varios equipos trabajando en simultáneo, uno genera reportes, otro
construye pantallas, debe ser modularizado. (Se debe hacer a la vez)

Las Etapas son las mismas:

1. Ingeniería de Requisitos
2. Diseño  Adaptarlo a las características de la herramienta
3. Codificación  Muy rápida y semiautomatizada
4. Prueba  Más rápida, tienen herramientas de prueba, se pueden generar Lotes
de Prueba.
5. Despliegue  Implementación, como cualquier otro sistema.

- Utilizaría este modelo, cuando tengo tiempos escasos

- No lo utilizaría cuando hay complejidad Técnica, el Código automatizado es
estándar y puede no servir. Por Ejemplo un celular, tengo limitaciones de hardware,
debo tener la mínima cantidad de líneas, necesarias, sino puedo tener problemas.

6). MODELOS ADICIONALES

6.1) MODELO DESARROLLO BASADO EN COMPONENTES

Desarrollar Software adaptando y utilizando componentes ya hechos, se basa en

reutilizar cosas.

Cambia el Diseño y Codificación.

Al Programador le dice como ensamblar componentes ya hechos.

Este modelo no está del todo afianzado.

Hoy en día hay muchos sistemas y códigos libres.
Las demás etapas hay que hacerlas como siempre. (Requisitos-Prueba-Despliegue).

Le ofrezco al cliente lo que tengo.

6.2) MODELO DE MÉTODOS FORMALES

Trata de encontrar una fórmula matemática (no con modelos matemáticos, pero si
libre de errores), para desarrollar un Software libre de errores. Valida todas las
partes del Sistema, es por esto que no se usa.

Hay Software que no puede tener errores (por ejemplo, para aviones, uso medico,
militar, etc.) a veces hay que encontrarle la vuelta a esto.
Clase teórica 09/04/2010

MODELOS DESARROLLO AGIL - CMM

MODELOS
Forma de Trabajo - DESARROLLO AGIL:

- Adaptar modelos o forma de desarrollar Software a los tiempos modernos

(Escenarios dinámicos y cambiantes)

- No se definen la totalidad de Requisitos al Principio en el momento cero

- La principal característica es la Agilidad

- No se aplica a la totalidad de los Software, pero son útiles para determinar

escenarios

- Este modelo se debe usar a conciencia, es decir sino uso ningún modelo, no puedo
decir que es un desarrollo ágil.

- Hay que elegir el modelo.

- Debe ser justificado.
- No se puede construir Software sólo con desarrollo Ágil.
- El modelo se elige en función de lo que voy a desarrollar
- Siempre se usa otro modelo también (Tradicionales)

Características del Desarrollo Ágil:

- Trabajo en Grupo (Flexibles)

- Mucha comunicación con el cliente (Se reemplaza el relevamiento inicial,
por el día a día)
- Trabajo en conjunto - Personal del Negocio y Gente de Desarrollo.
- Motivación / Información / Organización del Grupo
- Rigido, pero organizado.
- Tender a la excelencia Técnica.
- Excelente Diseño
- Programación Simple - Garantía de poder hacer cambios. (En algunos casos
sirve y en otros casos no) - La elección del modelo siempre depende del tipo
de desarrollo.
- El desarrollo Ágil no salva de Revisiones Técnicas (Auditoría) / Riesgos /
Backup
- No es más barato por ser Ágil
- Las Actividades de Sombrilla hay que hacerlas:
Líder del Proyecto Para Aseguramiento de la calidad
Seguimiento

Tipos de Modelo de Desarrollo Ágil (Todo lo relacionado a Modelo ágil va en forma

genérica al Parcial, en cambio los modelos tradicionales van si o si)

1. PROGRAMACION EXTREMA

# Se basa en casos de uso (Historias de uso según Pressman)

- y en base a estos, Programas.
# Se busca:
- Simplificación
- Autodocumentación
# Caraterísticas de la Programación Extrema:
- Programación Orientada a Objetos
- Promueve la Programación en Pareja (de a Dos)
2. SCRUM

# Equipos de pocas personas

- Comprometidos con la tarea
- Grupo Adaptable / Cambiante / Flexible
# Software muy documentado  La documentación facilita el cambio.
# Tenes Software siempre listo para entregar en cualquier momento.
- Ir probando por si el cliente lo requiere
- El Software se hace listo para funcionar

MODELO CMM O CMMI

Modelo de calidad - de capacidad y madurez

Determina cuan madura esta una empresa en relación al desarrollo de Software

- Nivel de formación para el desarrollo de Software
- Que tan bien utilizan los modelos

Estándar de calidad para medir a empresas de Software

- Importante para Licitaciones

Muchas prácticas

Una vez analizada la empresa, la categorizan.

- Tiene 5 niveles y en alguno de estos va a estar la empresa.
- Es evolutivo. Se puede ir cambiando de categoría.

# Dos formas de medir el modelo

- De 0 a 4
- De 1 a 5  Es la más habitual.

* Nivel 1: Donde arranca cualquier empresa, no hay organización. El éxito es

azaroso, por que no tienen ningún proceso definido.

* Nivel 2: Hay algunos procesos definidos, algunas cosas se empiezan a

estandarizar.
Hay control y Gestión del Proyecto.
Hay Seguimiento del Control.
Es repetible, ya que existe la posibilidad de que el próximo desarrollo se haga igual
que el anterior.

* Nivel 3: Todos los procesos de Software se encuentran documentados.

Se usa modelo de Software aprobado con métricas.
Formalización de todos los Procesos.
Las empresas en Nivel 3, alcanzan un nivel de madurez confiable.
Procesos bien definidos.
Alta chance de que el próximo desarrollo cumpla con todas estas características.

* Nivel 4: Todas las cuestiones nombradas en el Nivel 3 se encuentran

administradas, con Información Estadística, Seguimiento muy fuerte de todo el
Proceso de Software.

*Nivel 5: Idem Nivel 4. Optimizado, toda la estadística y controles aplicados a la

mejora continúa.

La certificación se hace pensando en un Nivel 3:

- Pero la mayor cantidad de empresas que no certificaron en CMM, están entre el
Nivel 1 y Nivel 2.
- Hacer las cosas bien produce beneficios para la empresa.
- Nivel 4 y Nivel 5, se hace en simultaneo, por lo que ninguna empresa se encuentra
en Nivel 4, ya que si realiza información estadística, es para mejora continúa.
- No es como la ISO, que es a nivel Compañía y se certifica o no. En CMM se hace
por proyecto y se asigna un Nivel si o si, cuando se certifica, del 1 al 5, aunque el
que esta tratando de certificar apunta como mínimo a un Nivel 3, que significa que
las cosas se estan haciendo bien.
- No hay requisitos legales con respecto al Software que se produce, por eso este
tipo de certificación se hace más que nada por Marketing.
- Hay licitaciones públicas, internacionales y por la ley de Software que otorga
beneficios para la producción de Software, por eso es importante certificar, para
Licitar o para aprovechar los beneficios impositivos de la ley de Software en
Argentina.
- Controla que todos los modelos se hagan bien.
- Auditorias que certifique que se cumplan
Documentación, etc.
Clase Teórica 16/04/2010

INGENIERIA DE REQUISITOS (ANÁLISIS) - CAPITULO 7 PRESSMAN

Es una Etapa Importante:

* Conocer el problema, lo que quiere el cliente.

* Se encuentran dos personas, que hablan distinto idioma. Cliente (empresa) vs
Sistemas.
* Flexibilidad y adaptarla a las características del proyecto.
* No es bueno codificar hasta no tener claro que es lo que quiere el cliente y bien
definido el problema a solucionar con el Software a desarrollar.

FUNCIONES:

1). INICIO:

Primer contacto con el cliente, usuarios claves, preguntas básicas.

2). OBTENCIÓN:

Definir que voy a obtener, en que formato, se quieren reuniones, datos,

información, aparecen los primeros problemas de entorno y límites (teníamos una
idea del sistema, que es distinta a lo que quiere el cliente, en las primeras
comunicaciones con éste)

Problemas de comprensión: los analistas no comprenden lo que los usuarios tratan

de decir o los usuarios no comprenden lo que el analista dice. También muchas
veces el usuario no sabe lo que quiere.

Volatilidad: Cosas que cambian con el tiempo.

3). ELABORACION:

Armar la base (Quizás implica la construcción de un Prototipo)

4). NEGOCIACION:

Todo lo que se relevó, que se pueda hacer, dentro de lo pactado.

5). ESPECIFICACION:

Hacer dentro de lo programado. Especificación de los requisitos. Acá se hace el

diagnostico definitivo para pasar a la etapa de Diseño.

6). VALIDAR:

Realizar Auditoria, control para que lo que voy a mandar a Diseño, se encuentre
probado y que cumpla con las reglas de la empresa, o sea lo que se especificó.

Un error en esta etapa, no se va a solucionar durante el desarrollo.

7). GESTION DEL CAMBIO:

Como se gestionan los cambios que ocurran o sepa que va a suceder.

TRES CUESTIONES A TENER EN CUENTA SEGÚN BRIANO:

1). OJO! Hay gente del otro lado!

Las personas no pueden hacer todo lo que se les pide, hay usuarios que quieren
que se implemente el sistema para bien y otro no.

Hay que adaptarse a la organización al momento de hacer el relevamiento

- Si son Formales  Reuniones Formales
- Si son Informales  Reuniones Informales

4 o 5 preguntas claves  Las tengo que obtener si o si.

Después anoto lo básico para acordarme después y se juntan en un bar con los que
fueron a entrevistar y a bajar las ideas.

* Usuarios Tóxicos: Objetivo: Que el proyecto no funcione (tener cuidado por que
generalmente se disfrazan de buenos tipos)

2). Ingeniería de Requisitos vs. Relevamiento (Análisis)

Construcción de Requisitos  Proponer mejores formas de hacer las cosas

Actitud Proactiva: No sólo encontrar lo que el usuario nos quiere mostrar, sino lo
que yo quiero encontrar. Estos resultados se validan con el cliente, se los muestran
y se negocian los plazo y se discuten las diferencias.

3). La Primera Cita:

Es vital llegar a la segunda cita. Ya que la segunda cita es la implementación.

Relevamiento importante:

- Cuestiones técnicas y humanas

- Tener al usuario de mi lado
- Eliminar las barreras
- Conseguir información más allá de la obvia. Contactar a usuarios importantes para
el sistema.
Clase Teórica 23/04/2010

TRES ACTIVIDADES TÉCNICAS:

Hay que tener más conocimiento técnico que en la primera etapa. Especialistas con
conocimientos técnicos.

- Diseño
- Codificación
- Prueba

1). DISEÑO

Luego de haber relevado y visualizar el posible problema, empiezo a armar una

posible solución informática para resolverlo.

De un análisis puede salir, “hagamos esto o no hagamos nada”, no siempre se

desarrolla un Software.

El Diseño se puede hacer en cualquier lugar, lo habitual es hacerlo en nuestras

casas y lo más importante es que no hay nada para preguntarle al cliente.

El Diseño trabaja sobre un análisis terminado y ya se relevo todo.

A partir de acá ya tenemos un

producto

ING. DE REQ. Revisió DISEÑO PROGRAMACIO

n
N
Técnica
$ CODIFICACION
Esto sale tanto

PROTOTIPO
Si acá llamo por teléfono
para preguntar algo, es
por que fallo la ING. DE
REQ. Sino usemos
Prototipos y consultemos todo.

Al finalizar el diseño:

Al programador le doy un lineamiento, con un lenguaje técnico…

Ej: No puedo decirle el apellido en un campo grande, le digo el apellido de tipo
carácter…

Luego del Diseño:

Si un arquitecto hace un plano me cobra por el mismo, luego cualquier lo puede

construir, lo lógico es hacerlo con la gente del arquitecto.

Lo mismo en informática, la inteligencia se pone en el análisis y el diseño.

$, podemos decir, que hasta el diseño sale tanto, aunque siempre se habla del
costo del Proyecto, a veces es difícil cotizar la programación, puede hacerse
después.

La codificación se puede cotizar, presupuestar luego del diseño. El tema es estimar

el Análisis y el Desarrollo.
Hay que basarse en la experiencia y cuánto queremos cobrar.
- En está etapa de diseño es donde se empieza a construir un Software de calidad.

- No vamos a hacer el tema técnico del documento entregado al programador (esto

se ve en Metodología)

Cuando yo Diseño, que debo diseñar?

# Estructura de Datos
- Como van a estar relacionados los datos

# Diseño Arquitectónico
- Ver como esos procedimientos -cargar un dato, diseñar consulta, etc.- se van a
diseñar entre si.

# Diseño de la Interfaz de Usuario

- Hoy en día los Software tienen mucha importancia, lo que se ve y lo que está
atrás.

Conceptos Fundamentales a Nivel de Diseño:

1). GRADO DE ABSTRACCIÓN:

Tiene que ver con el grado de detalle que se analiza algo, hay que ir de lo general
a lo particular, primero debo entender la totalidad del problema y luego meterme lo
más adentro para ir a lo más detallado. Debo tener una visión general de la
situación / problema.

2). DISEÑO DE ARQUITECTURA:

Ver como se relacionan los requisitos con lo que estoy haciendo.

3). MODULARIZACIÓN:

Es muy importante, ya que seria imposible hacer una solución completa, debe
modularizarse, atacando el problema en partes, me debo ocupar de problemas
pequeños. Debo generar módulos, estos módulos son reutilizables, si hago un
módulo de calculo de IVA, puedo utilizarlo cuando quiera.

Cuantos más módulos tenga, más interfaces voy a tener.

$ Me debo situar por acá

INTERFASES

Está bueno hacer módulos

pero no tener muchas
interfases

Cantidad de Módulos

La posibilidad de modularizar tiene que ver con la posibilidad de que muchas

personas trabajen en el desarrollo del sistema, también es más fácil encontrar
errores y el mantenimiento, reduce los costos de futuras implementación o
desarrollo por la usabilidad.

4). LEY DE RENDIMIENTOS DECRECIENTES:

Si ponemos dos personas a cosechar, cosechamos el doble, pero tres personas no
es el triple, si seguimos incorporando personas, no agrega, sino que resta, se
comienzan a chocar es incomodo.

En Software llego muy rápido al rendimiento negativo.

No siempre las cosas se solucionan incorporando más programadores, muchos
programadores pueden discutir entre ellos, puede haber mucha demora.

Para que haya modularidad, debe haber ocultamiento de la información, debe haber
variables públicas, privadas y pasaje de datos por parámetro, los módulos deben
ser independientes.

5). INDEPENDENCIA FUNCIONAL:

Los módulos deben depender lo menos posible de otros módulos del Sistema.
Si un módulo tiene independencia funcional, puede ser reutilizable más fácilmente.

COHESION Y ACOPLAMIENTO:

- Cohesión: Cantidad de tareas que realiza el módulo

- Acoplamiento: Cantidad de vínculos de este módulo con otro.

Cuantas más tareas realice, menos posible es reutilizarlo.

Se desea que haya mucha cohesión (realizar pocas tareas) y con relación con toros
módulos debe haber bajo acoplamiento.

Máxima cohesión y Minimo Acoplamiento!

Refinamiento, voy de lo general a lo particular, debo ir armando todas las distintas

consideraciones, hasta llegar al final.

7). DISEÑO DE LA INTERFAZ:

Hoy en día se utiliza interfaz de usuario gráfica e interactiva.

Los sistemas entran primero por los ojos, la interfaz debe ser simple.
Es importante ver como la interfaz representa la realidad.
Los usuarios determinan si es amigable o no en base a lo que ven.
Los colores es importante por temas de simpatia.

TRES REGLAS BÁSICAS QUE HAY QUE TENER EN CUENTA AL CONSTRUIR LA

INTERFAZ DE USUARIO:

1. Darle al usuario el control de la interfaz:

El usuario debe sentir que maneja la interfaz, debe poder cambiar los colores,
cambiar tipo de letra, tamaño, que pueda usar el Mouse o el teclado, que pueda
cancelar, volver para atrás, el usuario debe tener el control.

Esto se trabaja continuamente, por ejemplo en Windows.

Todos los elementos técnicos, que no sean necesarios ocultarlos, sería deseable
que la pantalla sea configurada por el usuario a partir de tanto conocimiento vaya
teniendo..

Debemos ver que cosas pueden poner el usuario que vayan en contra del sistema,
limitemoslo, demos el control pero no en todo. El rendimiento del sistema no debe
correr peligro.

2. Reducir la carga de memoria del usuario:

Tratemos que el Usuario no tenga que recordar muchas cosas, por ejemplo la
fecha , pongamos la fecha, tratemos que no deba recordar códigos, le podemos
poner ComboBox, tratemos que la pantalla represente la realidad. Ej seguir el
diseño de un cheque o una factura, primero se pone la fecha.

Debemos cuidarnos con la ayuda y los mensajes de alerta (Deben ser en momentos
oportunos)

El usuario no debe recordar valores que ya utilizo.

3. Construyamos una interfaz consecuente:

Muy importante, en general todo funciona en todas las pantallas de la misma

manera, por ejemplo: F1 es para ayuda, no lo cambiemos.

Las nuevas versiones deben ser parecidas a las anteriores, se debe respetar las
barras de herramientas, debemos seguir los estándares que por algo ya existen, el
usuario ya está acostumbrado a usar esos estándares.
Clases Teóricas 2DO PARCIAL
Clase Teórica 07/05/2010

CAPITULO 13: ESTRATEGIAS DE PRUEBA

ETAPAS DEL PROCESO DE SOFTWARE:

ANALISIS - DISEÑO - CODIFICACION - PRUEBA - PUESTA EN MARCHA

La Etapa de Análisis y Diseño entraron para el primer parcial, la Etapa de

Codificación se ve en las Clases Prácticas.

* Pressman pone la Etapa de Prueba dentro de la Etapa de Construcción, según

Briano no está de acuerdo con incluirla dentro de esta etapa.

ETAPA DE PRUEBAS:

- Es la etapa en la que se busca que el Software falle.

- Se prueba para que algo falle y no para probar la funcionalidad del Sistema.
- El Éxito de la Prueba es encontrar errores y no buscar que haga lo que realmente
debería hacer según los requisitos solicitados.
- Al Testear Software se toma una actitud destructiva.
- Aunque como ventaja secundaria de la etapa de prueba, en caso de que no se
encuentren errores, es que se verificó que el sistema cumple con las
funcionalidades requeridas.

- Éxito de las Pruebas:

El Éxito de las pruebas se da cuando se encuentran errores, ya que al tomar una

actitud destructiva, si una prueba no encuentra problemas, es por que fallo la
prueba, esto es así por que en la historia del Software, jamás se construyo un
Software libre de errores. En caso de que la actitud que se toma al realizar la
prueba no seria destructiva, entonces el éxito seria que funcione todo bien.

- Las pruebas son iterativas:

A medida que sigo probando, va disminuyendo la tasa de error, pero siempre voy a
seguir encontrando errores.
Cuando el costo de seguir buscando errores, es mayor que los beneficios que puede
brindar el Software funcionando como está (con errores), entonces se deja de
probar (buscando también la aceptación del usuario ante está situación). En otras
ocasiones también depende del tipo de Software, ya que si es muy critico, como de
uso medicinal, aviones, etc. entonces se busca que el mismo se encuentre
prácticamente libre de errores.

Error

Tiempo $

- Quien hace la prueba?

Equipo de Prueba Independiente (Externo al Equipo de Desarrollo)

Esto es así por que psicológicamente, el programador no tiene actitud destructiva,
ya que fue quien construyo el Software, y por ende su actitud será opuesta a quien
prueba el Software, ya que el desarrollador buscará que el Software funcione y no
buscará el error.

Asimismo es útil que el desarrollador participe de las pruebas por cuestiones del
código (Algoritmos, etc.). Es mejor siempre que este equipo de prueba externo
trabaje con el desarrollador para encontrar más errores y contemplar la mayoría de
alternativas, sobre todo en Software grandes y complejos.

- La Prueba es un Elemento critico para evaluar la calidad del Software.

# Una Mala prueba implica, probablemente un software de baja calidad.

# A su vez, la prueba debe ser de calidad, pero la calidad del Software depende de
todas las actividades del Proceso de Software (incluso de la etapa de Prueba)
# Se debe controlar la calidad de la Prueba
* Revisiones Técnicas Formales (Auditoria)
* Controlar si el desarrollador estuvo presente
* Si la prueba tiene que durar 5 días, controlar que haya sido así.

- Estrategias a tener en cuenta (Más allá de ejecutar la prueba en si)

1). Preveer Auditorias

2). Deben hacerse desde el Módulo (Particular) al Todo - Menú Principal (General).
Hacerla al revés puede quedar lugares sin analizar. De está forma la prueba se
efectúa de manera inversa a la codificación que va de lo General a lo Particular.
3). Aplicar Técnicas según momento de la prueba, en ciertos casos.
4). Definir cuando empieza y cuando termina (sino dura para siempre)
Cuando está lista para probar y cuando la prueba fue superada y está listo para
seguir.
5). Definir Requisitos y Objetivos a obtener de lo que se quiere probar. Metas,
objetivos y Resultado Final (Por ejemplo, se busca que ande la interfaz)
6). Prueba <> (distinto de) Depuración
Siempre cual sea el error y el tipo, tengo que volver al análisis y no a la
codificación.
Analizar situación según error, diseñar y después codificar.
Cuando es más complejo sobretodo, se arma un miniproyecto de Software y se
siguen los pasos del proceso de Software para solucionar el error detectado.

# La prueba es la única etapa que podría eliminarse dentro del proceso de

Software, por que el resto de las etapas (A - D - C - Impl) son necesarias para crear
y poner en marcha el Software.
 Si no se prueba el Software, seguramente va a tener errores, pero asi y todo va a
funcionar aunque con baja calidad, pero funcionará igual.
 Eliminar la etapa de prueba se hace cuando no hay tiempo y presupuesto, a lo
sumo el mismo desarrollador hace algunas pruebas de funcionalidad mientras
codifica, pero no pasa por la etapa de Prueba en la que un equipo independiente
fuerza el error.
 Siempre es tentación eliminar la prueba ante presiones del entorno, para poner
en funcionamiento el Software, por esta razón es que existe Software de Baja
Calidad.

# No efectuar la prueba es una de las peores decisiones a tomar.

 Por que el costo de un error con el Software en funcionamiento es mucho más

grande que en si el mismo se detecta en las etapas previas y se puede analizar,
rediseñar y recodificar.
 Cuanto antes detecto el error, más barato será corregirlo.
 Es preferible asumir los costos y problemas de continuar con la prueba que los
problemas que generaría no efectuar la misma.

# Existen distintos tipos de pruebas según lo que quiero probar.

(Hay que definir con que orden se hacen, cuando se hacen y con que resultados).
A. Pruebas vinculadas al código
B. Pruebas vinculadas al Funcionamiento del Software

# Dos grandes Conjuntos de Prueba:

A). CAJA BLANCA

Es la que se hace con el código abierto

B). CAJA NEGRA

Es la que se hace con el producto cerrado, con el sistema operando, directamente
sobre la interfaz.

# De acuerdo a lo que se quiera probar o buscar, va a depender que tipo de prueba

es más efectiva, para algunas cosas es más efectiva las Pruebas de Caja Blanca, y
en otros casos es más efectiva la técnica de Caja Negra.
Es de acuerdo a lo que se está probando.

# Libro Pressman: Por un lado esta la clasificación Caja Blanca y por otro la de Caja
Negra.
Pero agrega otra clasificación relacionada a que es un error definir un tipo u otro de
prueba, ya que siempre se termina utilizando un mix de ambos tipos.
LO QUE QUIERE DECIR CON ESTO ES QUE QUIZAS SEA MAS CONVENIENTE DEFINIR
LA PRUEBA POR EL TIPO Y TOMAR ESTE COMO UNA CARACTERISTICA, YA QUE CASI
SIEMPRE CUALQUIERA DE LOS TIPOS MENCIONADOS POSEE UN MIX DE PRUEBA DE
CAJA BLANCA Y CAJA NEGRA.

A). CAJA BLANCA:

1). La gente que hace la prueba debe conocer el lenguaje en que se codifica.
2) Importante presencia del desarrollador para que sea más eficiente la prueba.
3). Voy a ver los caminos independientes del Software:
 Que todas las bifurcaciones del Software, lleguen a un mismo lugar
 If o Case: Dos caminos, que se cumpla la parte del “Si” y la del “Sino”
 Analizar condiciones lógicas, más complejas, AND, OR, PARENTESIS. Recurrir a
las tablas lógicas para ver si las condiciones son correctas.
 Es importante analizar los caminos.
4). Analizar que todas las condiciones de una determinada situación se cumplen.
Por ejemplo: A > B Ver que pasa en el sistema cuando: A > B y que pasa cuando B
> A y que pasa cuando A = B. Es decir que todas las alternativas esten
contempladas y no sólo la condición inicial (A> B).
5). Probar los ciclos o estructuras:
- FOR, WHILE, UNTIL, Etc.
 Primero que se ejecuten todas las veces que haga falta. Por ejemplo: Un FOR de
1 to 100 que llegue hasta 100.
6). Ver que todos los ciclos tengan salida, que exista la forma de salir y que no
quede en un Loop eterno.
7). Analizar la estructura interna de los datos.
8). Moviendo el código puedo ver las condiciones limites para probar en Caja Negra.
Me da casos de prueba para está técnica.
Ejemplo: Si es un número: Probar los límites, los muy grandes, los muy chicos, los
positivos, los negativos (ver que pasa si pongo un negativo, la interfaz avisa o no
avisa.)
B. CAJA NEGRA:

1). No se mete con el código, sino con la funcionalidad del sistema.

2). Probar cosas de rendimiento, interfaz de usuario, cosas que en el código no se
puede probar (En el código veo los limites) pero no que pasa si llego al limite.
3). Hay que ver que funcione efectivamente lo que se codifico
4). El módulo tiene que correr, funcionar para poder hacer pruebas de Caja Negra.
5). Buscar errores:
 a). De rendimiento
 b). De inicialización (Carga de variables por que excedió la memoria)
 c). Estructura de la Base de Datos: Si se grabo o no se grabo el dato, si se grabo
exactamente lo que se tenia que grabar o se grabo otra cosa. Lo veo o no lo veo.
 d). Cosas que en el código están bien, pero que en la PC tira error. No nos
podemos quedar sólo con que el código está bien.
 e). Errores de Interfaz.
 f). Funciones ausentes (que no están por ejemplo un botón que imprima, esto no
se puede ver en Caja Blanca por que el código no esta.) Si bien está en el diseño,
puede pasar que de 10 botones falte uno y es más fácil verlo por Pruebas de Caja
Negra.
Clase Teórica Viernes 14/05/2010

CAPITULO 14: TECNICAS DE PRUEBA

DIFERENTES CLASES DE PRUEBAS (Diferentes tipos de controles)

PRUEBA DE UNIDAD - CAJA BLANCA

Mediante la misma probamos que los módulos Funcionen correctamente

de manera individual.

Si superamos está Prueba es por que ya no hay Mas Errores en los

Módulos.

 Vamos de lo más chico a lo más grande.

 Verifica la Unidad más pequeña que es el módulo, se prueba:

 Ciclos
 Caminos Independientes (En el código cuando se ejecuta puede tener muchos
caminos)
 Estructura de Datos Locales (Variables)
 Interfaz

* Si quisiera probar es Caja Negra cada Módulo, tengo que ir simulando cosas, por
este motivo es problemático y se hace sólo con Caja Blanca.

PRUEBA DE INTEGRACION - CAJA NEGRA

Probamos que los módulos se integren correctamente

Si superamos está Prueba, no hay más errores en la integración de los

módulos.

- Debo ver si estos módulos se integran entre si, es decir si pasaron la prueba
anterior.
- El módulo puede andar bien, pero cuando lo empiezo a integrar puede fallar.
- Es de caja negra, por que si tiene que integrarse, tiene que correr, funcionar.
- Cual es la estrategia para integrar estos módulos?
 Integro de arriba para abajo (Descendente) - Integración Incremental
 Integración “Sandwich”, empiezo del medio y voy tomando en forma
intercalada un módulo de arriba y otro de abajo.

* Puede haber algún caso en que convenga realizar la Integración de forma NO

incremental, integrando el todo como un paquete.

PRUEBA DE VALIDACION - CAJA NEGRA

Probamos que se cumplan los Requerimientos del Usuario.

Si superamos está Prueba, significa que no hay más errores con respecto a los
requerimientos de Usuarios.

 La validación es contra los Requerimientos del Usuario (lo que pidió el Usuario
y que quedo formalmente firmado y aprobado por el Cliente) y NO se valida contra
el Usuario.

* Tiene que aparecer el Usuario:

# ETAPA DE NEGOCIACION

Negociar que pasa cuando el cliente (que siempre tiene la última palabra), dice que
no le sirve el Sistema desarrollado.

Hay que negociar, la extensión de los plazos, quien se va a hacer cargo de los
costos, etc.

PRUEBA DE SISTEMA - CAJA NEGRA

El Sistema es parte de otros Sistemas  Hay que ver como se comporta con el
Entorno.

Probar varias cosas:

1). Prueba de Recuperación:

Como se recupera el Sistema ante un fallo.

2). Prueba de Seguridad:

Como funcionan los mecanismos propios del sistema, para protegerse de virus, etc.
Por Ejemplo: Si la Base de Datos contiene información Crítica, guardarla encriptada,
por si alguien entra de afuera, no la pueda ver.

3). Prueba de Resistencia

Como responde el sistema ante situaciones Anormales, como ser:
- Poca Memoria / Se corta Internet / Sistemas Multiprocesadores - ver hasta que
Umbral / Etc.

4). Prueba de Rendimiento:

Ver si el sistema en las condiciones normales, funciona razonablemente.

# Todo esto genera recomendaciones o pautas de funcionamiento mínimo, es decir:

- Se le informa al Cliente, cuales son los Requerimientos Mínimos para que el
Sistema Desarrollado Funcione.

# Tener en Cuenta que La Prueba es Distinta a la Depuración (Debbuging)

- Con la Depuración, se efectúa una solución para el problema encontrado, que

luego se vuelve a probar

# Consideraciones a tener en Cuenta:

1). Síntomas o causas no ubicadas en el mismo lugar.

2). Síntomas intermitentes - Es lo peor que puede pasar (Múltiples Variables)

3). Cuestiones de Fallas en el Hardware

4). Errores por Redondeo  Sobre todo en Sistemas Contables - Balanceo de

Asientos.

5). Errores Humanos  Difícilmente detectables.

# MENSAJE FINAL BRIANO ACERCA DE LAS PRUEBAS

Hay Errores  Lo peor que puede pasar es que siga habiendo errores.

1). Cuando se encuentra un error, preguntar 3 cosas:

a). Si ese error puede repetirse en otra parte del Sistema.

Ejemplo: Si encontramos que valida mal el CUIT, entonces ver donde se puede
repetir este error en otra parte del sistema.

b). Que error se puede presentar con la corrección? Ver el tema de Parches.

c). Determinado Error, porque llego hasta acá? Se pudo haber prevenido la primera
vez?

2). Existen en el Mercado, herramientas de pruebas automatizadas

- Aunque no sirven para cualquier caso de prueba, se pueden utilizar para errores
de Sintaxis.
Clase Teórica martes 18 de mayo de 2010.

CAPITULO 21: CONCEPTOS DE GESTION DE PROYECTOS

CAPITULO 22: ESTIMACION PARA PROYECTOS DE SW
CAPITULO 24: CALENDARIZACION DE PROYECTOS DE SW

CONSTRUCCION DE SOFTWARE:

GESTION DE PROYECTOS

Un Proyecto de Software se gestiona de la misma forma que otro proyecto referido

a otra actividad y que tenga como resultado un producto determinado.

Se utilizan las mismas herramientas para la gestión y administración que las

utilizadas para cualquier proyecto, tales como: Diagramas Gantt, Pert y Software
Project.

Las Cuatro “P” (Según Pressman, Briano no coincide del todo con esta
denominación)

1). Gestión eficaz del PERSONAL (People)

2). PRODUCTO  Objetivos, Límites, Restricciones Técnicas.
3). PROCESO  Modelos de Proceso, Elección y Seguimiento Eficaz del Proceso.
4). PROYECTO  Planificación, Supervisión y Control.

1). PERSONAL:

- El personal en este tipo de procesos es crítico.

- Dependemos de las personas  La Elección de una buena persona, significa
trabajar con buena materia prima.

Dos cuestiones:
1. Rendimientos Decrecientes: No se puede arreglar todo, contratando más
personal.
2. Las personas no son fácilmente reemplazables. En función de los proyectos, hay
que pensar como reemplazar a un programador. Utilizando Documentación, Planes
de capacitación, etc.

# ESTIMAR:

Se estiman los recursos que voy a utilizar.

1). HUMANOS
2). ENTORNO (Hardware, Servidores, Comunicaciones)
3). SOFTWARE

 Proyecto estos recursos en el tiempo (Cuanto y Cuando), obteniendo:

Estimación del Costo

+
Beneficio
__________________
= Precio de Venta

# Todo esto se estima desde el momento cero, es decir desde la Comunicación

Inicial con el Cliente (Primer Etapa del Proceso de Software)

En esta Etapa es difícil saber cuantos programadores, que Hardware, etc.

Es Difícil que se cumpla la estimación, por diferentes motivos:

Complejidad: Cuanto más complejo es el Software, y no se parece a Software

anteriores, entonces es más difícil la estimación.

Tamaño: Cuanto más grande es el Software, más cosas hay para estimar, por lo que
hay más probabilidad de que la estimación falle.

Información Histórica: Puedo tener mucha experiencia, pero es necesario generar

documentación.

# Descomponer el Proyecto en partes. Dividir en Partes y Proyectar en Partes.

# Podría desarrollarse un modelo de estimación empírica, que facilite todo esto.

Modelo Cocomo: NO SIRVE PARA NADA. NO ESTUDIAR
Es difícil encontrar modelos empíricos para esto, más allá de que algunos estudios
grandes se basen en algún modelo.

CALENDARIZACION:

Poner estas tareas en un Calendario.

Asignar Fechas Claves y Responsables
Utilizando Diagrama Gantt, Pert, Software Project.

OUTSOURCING:

Tercerización del Desarrollo.

Al momento de desarrollar Software nos encontramos ante una primera situación

de decisión:

1ERA DECISIÓN:

SI DESARROLLO O SI COMPRO

2DA DECISION (En el caso de que lo desarrolle y no lo compre):

SI DESARROLLAMOS NOSOTROS O SI TERCERIZAMOS TODO O UNA PARTE.

# Está volviendo el Outsourcing a nivel WEB.

Clase Teórica viernes 28 de mayo de 2010.

CAPITULO 22: METRICAS

 Datos Históricos

 Información Histórica

Permite saber como estamos y como vamos mejorando respecto al proyecto actual
y desarrollos pasados.

Debe estar organizada de manera tal, que sirva para obtener estas comparaciones.

Para ello existen METRICAS, que sirven para comparar con estándares.
- Son una construcción que se hace basada en las medidas que se toman con el
objetivo de ser comparadas con estándares (propios, ajenos o generales). Por
ejemplo: Un Software determinado tiene un promedio de error por línea de código
(unidad).

- Una métrica es una formula. Por Ejemplo:

 Cantidad de Errores / Cantidad de Líneas de Código

 Cantidad de Líneas Programadas / Hora
 Cantidad de Módulos / Mes

- Una medida es algo que se mide con un elemento de medición

# No sirve usar una métrica, sino un conjunto de métricas. Este conjunto de

métricas debe estar orientado a un objetivo específico del proyecto.

# Ninguna métrica es mala o buena en sí mismo, sino que depende del historial.
Las métricas no se puede utilizar solas, si no, se debe elaborar un conjunto de
métricas

Métricas Públicas
Son aquellas que afecten al proyecto, de manera tal que los involucrados en el
proyecto conozcan el objetivo y como están respecto a ellos.

Métricas Privadas:
Cuando responde a cuestiones individuales de las personas, rendimientos
individuales. Por ejemplo: Cantidad de errores que una persona comete.

# Métricas Orientadas al Tamaño

- Son Métricas que hablan sobre “Cantidad de Líneas de Código”.
- Son fáciles de obtener.
- Están orientadas al tamaño del Software producido.
- Hacen referencia a un determinado tamaño.
- Problema: Como comparo Software de distinto tamaño, el rendimiento va a ser
distinto también. O que se encuentre desarrollado con distinto lenguaje, se puede
solucionar con un converso para igual el tamaño, por ejemplo: el código de C++ es
igual a dos veces el código de Visual Basic.

# Métricas “Orientadas al punto de función”

- Tiene que ver con la funcionalidad del Software (no interesa el tamaño)
- Puntos de Función:
 Cantidad de Pantallas de Ingreso
 Cantidad de Archivos que abre. Ejemplo: Módulo que abre 15 archivos, es
independiente del tamaño del Software, hace a la funcionalidad.
 Cantidad de comunicaciones que se establecen
  Cantidad de Parámetros.
 Cantidad de Listados.
 Cantidad de Datos que usa el Usuario.
- Ejemplo:
 Cantidad de Errores / Puntos de Función
 Cantidad de Horas Trabajadas / Punto de Función
- Pregunta Parcial: Explicar cual es el Punto de Función, ahí nombrar los que están
arriba.

# Las métricas pueden dar:

 Muy Bien algunas y
 Muy Mal otras
- Por está razón es necesario, hacer un trabajo de conciliación entre las métricas.
- Se le da bola a una y a otra no.
- Puede estar mal hecha la métrica, o un factor externo (se enfermo un
programador), puede hace que el resultado de la métrica no sea bueno.

# Lo más importante cuando se utilizan métricas, es utilizar el sentido común:

- No es la verdad absoluta una métrica determinada.

- No trabajar de por vida con la misma métrica.
- Pueden haber cambiado las condiciones y la métrica no sirve más.
- No puede ser utilizada como única medida para premiar o para castigar al
personal.

 En función de los objetivos se ponderan las métricas de acuerdo a lo que se está

buscando.
- Si es Calidad
- Si es Tiempo
CAPITULO 25: GESTIÓN DEL RIESGO

Factores que pueden afectar al presupuesto inicial.

# RIESGOS:
Amenazas contra la funcionalidad del proyecto. Debe existir una persona que
piense en estos posibles riesgos, calculando la probabilidad de ocurrencia e
impacto, gestionándolo, a fin de supervisar y de esa forma reducir los riesgos.

 Virus
 Falla en el Hardware
 Me quede sin $
 Aumento en los costos
 Cambio en el Lenguaje o Sistema Operativo
 Cambio Normativo
 Cambio de Usuarios
 Corte de Luz
 Incendio
 Cambio de Equipo de Desarrollo
 Programador enfermo
 Documentación Inadecuada o Inexistente.
 Robo de Información / Fraude

# Matriz de Riesgo:

Probabilidad

Impacto
# Probabilidad de ocurrencia e impacto en función del momento.

# Va del 0 al 1, sin incluir el 0 y el 1, por que si es cero no ocurriría nunca y si es 1

es por que nos encontramos en certeza, es decir que ya no seria un riesgo, por que
es algo que va a ocurrir si o si.

# Ocuparse de los Riesgos:

Definir determinadas estrategias para actuar frente a un determinado riesgo.

- Estrategias Proactivas. Por ejemplo contratar un Seguro de Prevención.

Anticiparme al riesgo y hacer algo antes de que el riesgo ocurra.

- Estrategias Reactivas: Por ejemplo bomberos.

Es una estrategia y no esperar a ver que pasa.
Ocurren una vez que se produce el riesgo. Estoy preparado para atacar el riesgo.

# Ninguna de las dos es mejor, ni es más cara una que otra.

No voy a estar pagando más de lo que el impacto implica. Siempre una estrategia
está asociada a un costo determinado. Si hago una aplicación que sale $5000, no
voy a pagar $15000 de seguro.

- Plan de Riesgo:
Para tratar de bajar los riesgos. Actividades de Control!.

- Plan de Contingencia
Auditoria
# Los riesgos no se terminan cuando se termina el sistema. Los riesgos continúan.

- Riesgos Técnicos: Afectan la Factibilidad.

- Riesgos Vinculados al Negocio: Ejemplo vender SW enlatados.
Clase Teórica viernes 06 de junio de 2010.

CAPITULO 26: CALIDAD

Estuvimos viendo todas las cosas que hay que hacer para construir un software de
calidad, pero….qué es calidad?

Definiciones de Calidad:

Real Academia: propiedades que pertenecen a una cosa y permiten juzgar su

valor
Pressman: es una característica o atributo de algo que puede ser comparado con
estándares

Entonces Calidad sería, encontrar en un producto una determinada característica

que permita compararlo con un producto similar y mediante esto pueda juzgar su
valor.

Puede evaluarse un producto por 2 atributos distintos, por ejemplo una persona
puede evaluar un producto porque es rico y otra porque es sano.

CONCEPTOS DE CALIDAD:

-Calidad en el proceso: a veces para hablar de calidad en el producto, debemos

ver el proceso. Los conceptos de calidad son del proceso, es importante
comunicarlos a la gente.

# SON DEL PROCESO  HAY QUE COMUNICARLOS

# Tenemos que construir un Software de Calidad, haciendo:

 Hay que darle calidad a cada uno de los procesos, cumpliendo con los
requisitos de cada uno de los procesos. (No sólo una prueba de calidad me
asegura un Software de Calidad)
 El Usuario debe percibir esto.
 Que se actualice periódicamente.

-Nosotros tenemos que hacer un software de calidad, para esto tenemos que dar
calidad a cada uno de los procesos, además de dar calidad a los procesos debemos
informarlos al usuario. Ejemplo: Windows se destaca sobre el resto porque se
actualiza todo el tiempo, eso es sinónimo de calidad.

# Para que el Software tenga Calidad, tiene que haber:

1. Concordancia con los requisitos especificados por los ingenieros, hacer lo que se
solicito para la construcción del Software.
2. Concordancia con el rendimiento.
3. Adecuada Documentación
4. Concordancia con estándares profesionales
Ejemplo: Para la construcción de un puente, se siguen estándares realizados por
profesionales de acuerdo a la experiencia.
Para el desarrollo del Software no existen estándares consensuados entre los
profesionales, como sucede en la creación de un puente.
Las empresas generalmente utilizan sus propios estándares, o utilizan alguno
parecido, pero no hay unión de los profesionales que digan como hacer tal cosa
relacionada al desarrollo de SW.

NO EXISTE FORMALMENTE PARA EL DESARROLLO DE SOFTWARE, UN

ORGANISMO / ENTE EXTERNO A NIVEL CONSEJO PROFESIONAL QUE ME EXIJA UN
 ESTANDAR PROFESIONAL, ES DECIR QUE EN LA ACTUALIDAD NO EXISTE UNA
AUTORIDAD QUE ME OBLIGUE A CUMPLIR ESTÁNDARES ESPECIFICOS PARA EL
DESARROLLO DE SOFTWARE.
ESTO NO QUIERE DECIR QUE EN LA ACTUALIDAD LAS EMPRESAS O UN
DESARROLLADOR INDEPENDIENTE, DECIDA UTILIZAR UN ESTANDAR PROPIO
PARA EL DESARROLLO DE SOFTWARE. DE HECHO LAS EMPRESAS LO UTILIZAN,
COMO POR EJEMPLO EL CMM, PERO DESPUES NO HAY AUTORIDAD QUE
CONTROLE QUE EL PRODUCTO QUE ESA EMPRESA ENTREGO SE RIGE BAJOS LOS
ESTANDARES DE CMM. (COMO SI PASA POR EJEMPLO EN LA INDUSTRIA
FARMACEUTICA CON LOS MEDICAMENTOS O EN LA CONSTRUCCION DE UN
PUENTE)

# El requerimiento de Software debe estar validado  Esto es Calidad.

Calidad es <> al Control de Calidad / Control de Calidad es <> de Las

Pruebas.

El Control de Calidad significa hacer pruebas de auditoría de Software, para

asegurar la calidad en cada uno de los proceso, las pruebas no son equivalentes al
Control de Calidad, ya que las pruebas deben tener un Control de Calidad para
asegurar que fueron realizadas correctamente.

# La Calidad tiene un Costo (No es lo mismo hacer controles que no hacerlos):

Costos de Prevención: Lo que hacen las empresas para asegurar la Calidad

Costos de Evaluación: Asegurar que el Software mejore, ande mejor, mayor
Performance. Por Ejemplo: Si sale un nuevo Sistema Operativo, aprovechar las
Características del Hardware
Costos de Fallos: Corregir defectos.
Costos Externos: Garantías - Soporte en Línea. Cuando le pasa algo al Usuario,
que no tiene que ver conmigo, pero que igual me hago cargo.

Pruebas es <> de Revisiones:

Revisiones Técnicas que se le hacen al Software.

Se aplican a cada una de las etapas del Software, luego de cada etapa debería
introducir una Revisión Técnica (Si es formal mejor), para revisar que cada una de
estas cosas sea desarrollada como corresponde, inclusive en la Etapa de Prueba.

Auditoria Formal:

- Citar formalmente a los interesados, por mail o por nota.

- Dar un Veredicto, Si se aprueba o no se aprueba.

Revisiones Técnicas Formales:

- Se realizan las que sean necesarias para asegurar la Calidad del Software. Por
ejemplo si surge algún cambio, este también se debe revisar.
- La Revisión Técnica es la que da calidad, no la prueba.

Como se relaciona esto con las Certificaciones y las Normas ISO (de
Calidad)

La Certificación en si, no da Calidad. La Certificación lo que hace es afirmar que una

empresa cumple con determinadas características que aseguran que sus Procesos
son de Calidad.

Sirve para demostrar a terceros que los productos de la empresa que certifica son
de Calidad.
Certificar tiene un Costo. Se Contrata a un Tercero Independiente para que
certifique que lo que la empresa hace tiene calidad.

Las Certificaciones:

 No son Únicas. Hay muchos tipos de Certificaciones.

 Irrefutables
 Las empresas que se encuentran certificadas no siempre significan que
hagan las cosas bien.
 Las empresas que no están certificadas no siempre significan que haces las
cosas mal.

CMM: Microsoft no está certificada en CMM, ni en ningún otro Estándar, por que
ellos consideran que están por encima de toda certificación.

Certificaciones de los pares: Cada vez se confía mucho más en opiniones de los
pares y comunidades de usuarios en Internet (Foros de Discusión). Aunque hay que
tener cuidado en que opinión confiar, por que nunca se sabe exactamente quien
está escribiendo.

# La Calidad se Comunica. Ver de que forma vamos a comunicar, todo esto

conlleva un costo también.

PLAN SQA: Plan de Aseguramiento de la Calidad del Software.

Paralelamente al proceso de Software, hay que planificar de que manera le voy a

dar calidad al proceso de Software. Es una forma de estimar como voy a darle
calidad al Software.

El responsable de la Calidad de Software es distinto al Responsable de las Pruebas.

El responsable de la Calidad tiene que tener un Plan, el cual debe contener:

1. En que ámbito? Con que propósito? para que?

2. Descripción de cada uno de los productos de trabajo, sobre que trabajar -
Documentación, Modelos.
3. Estándares en cual aplicar o construirlo, para cada cosa que se pretende.
4. Cuando y quien y en donde se van a hacer las auditorias formales.
5. Herramientas de Software para dar Soporte a SQA
6. Definir los papeles (roles) de cada uno de los miembros de la organización en
relación a estos temas.

Normas ISO
Más allá de que no es una norma utilizada frecuentemente
Existe una posibilidad de aplicar estas normas al proceso de Software. 9000, 9001,
9126.

La Norma 9126 Identifica 6 Atributos (están en el Libro de Pressman - página 465)

1). Funcionalidad:
En que grado el Software satisface las necesidades para lo que fue creado 
Performance, exactitud.

2). Confiabilidad:
Cantidad de Tiempo en que el Software está productivo.
Es decisivo en muchas empresas / Bancos.

3). Recuperación Ante Fallos:

Que tan fácilmente dentro de la Confiabilidad se recupera ante un fallo.

4). Facilidad de Uso:

Hace a la Calidad, ya que el usuario es quien lo va a utilizar.
Si el Software es muy complejo, más allá de que ande bien, si el usuario no lo puede
usar  Entonces no tiene Calidad, no sirve.

5). Eficiencia:
Hacer las cosas usando la menor cantidad de recursos.

6). Facilidad de Mantenimiento:

Actualizaciones remotas, etc.

7). Portabilidad:
- Facilidad de que un Software lo pueda llevar de un lado a otro.
- Difícil portabilidad entre el Sistema Operativo (por ejemplo Windows y Linux)
- En cambio si existe portabilidad entre una notebook y una PC de Escritorio.
- Software Online: Están disponibles en cualquier momento y lugar. Google Docs,
Hotmail, etc.
- Estar en la nube hace a la Calidad.

# Más Allá de que se certifique o no, estas características de la Norma ISO

son interesantes tenerlas en Cuenta.
Clase Teórica viernes 11 de junio de 2010

CAPITULO 27: GESTION DE CONFIGURACIONES / MANTENIMIENTO

CAPITULO 31: REINGENIERIA

# No todos los cambios que ocurren en el Software, ocurren en el final.

 Cuando los cambios ocurren durante el transcurso del proyecto se denomina

GESTION DE LAS CONFIGURACIONES.

 Cuando los cambios ocurren al final del proyecto, se denomina MANTENIMIENTO.

GESTION DE LAS CONFIGURACIONES

# Voy a tener varias configuraciones de Software

# Software Multilenguaje, un cambio de version del Software, implicaría hacer un

cambio en todos los lenguajes en el que se encuentra desarrollado el Software.

# No introducir cambios en una versión que arruinen cosas que en la versión

anterior funcionaban bien.

ESTRATEGIAS RESPECTO DE LA GESTION DE CONFIGURACIÓN

1). NO ACEPTAR CAMBIOS

No es común decir “no hay cambios”, “no hay manejo de versiones”
Se da en casos puntuales como Microsoft, por ejemplo se entregan distintas
versiones, pero si un usuario determinado solicita que cambien algo respecto a la
herramienta WORD, no le darian bola.
En un momento paso también con Software Enlatados como ser TANGO, en el que
no se realizaban modificaciones sobre el Soft que se vendia.

2) ACEPTAR CAMBIOS
Se realizan los cambios solicitados por el cliente, pero no se asegura que los
cambios persistan en versiones futuras del Software.
Por ejemplo:
- Version 1, se le realizan determinados cambios solicitados por el Cliente.
- Versión 2, de acuerdo al interés del Software, si el cambio solicitado, mejora y
beneficia al resto del Software se mantiene, pero si es algo muy especifico, puede
que se mantenga el cambio o no, en nuevas versiones.

3). CONTROL DE CAMBIOS

Que cada cambio de version, siga generando lo que generaba la version anterior
mas los cambios o agregados.

# Adecuada Gestión del Cambio

Identificar que partes del Software cambia. Si es una parte o es todo el Software lo
que cambio.

# Control de Cambios
Garantizar que se realizó adecuadamente la implementación del cambio.

# Comunicación de los cambios a los interesados.

 Cuando hay múltiples versiones. Se puede utilizar una Base de Datos. Gestor de
Base de Datos para ver como se comportan cada una de las versiones.
 Tener cuidado con los números de versión. Nombres, tener bien identificado cada
módulo para saber de que versión estoy hablando.

Sistema Gestor de Base de Datos

1). Posee Base de Datos, donde están todos los objetos (módulos) que componen la
versión final.
2). Capacidad de gestión de versiones. Permitir reconstruir el original. Para construir
el final (todas las versiones)
Gestionar las distintas versiones (actuales) y también las distintas versiones de los
módulos (anteriores).
Historial de las distintas versiones
Historial propio de cada versión  Para volver para atrás.

3). Da a quien construye Software, herramientas para que el programador no se

tenga que acordar como compilar las versiones.

4). Posibilidad de seguimiento de Bugs y de conflictos o problemas que hubo.

# Contando con un Software de estas características es más fácil manejar el

versionado.

# Entre versiones tengo que asegurar de no tocar cosas que andaban bien.

Concepto de Línea Base

Determinada porción del programa y/o documentación y/o cualquier componente

que forme parte del sistema (Casos de uso, diseño, análisis, archivos)

Esa porción es revisada y aprobada. Esto queda en un estado de Línea Base., algo
así como “Read Only”. Lo pueden ver pero no modificar.

RTF: Revisiones técnicas formales, si se somete a una RTF se decide que

determinada proción sea de línea base (Read Only). No dejo que nadie lo toque.

Kernell / Core  Si se cambi es por que salgo del proyecto original. Si funciona Ok,
no se cambia.

Para sacar el Read Only, o sea sacarlo de Línea Base, se hace a través de una RTF.
(lo que dejo de ser Línea Base, nunca más vuelve a ser línea base)
Para volver a ser Línea Base, luego de los cambios introducidos, vuelvo a hacer RTF
para conseguir el Read Only.

Línea Base: Ayuda a que cuando hay mucha gente trabajando en un mismo
proyecto, alguien toque algo e introduzca un error.

Es decisivo para lo de Gestión de Configuración (Para evitar arreglar algo y

desarreglar otra cosa)

MANTENIMIENTO:

Cambios que ocurren cuando el Software esta entregado, funcionando por alguna
cuestión (no tiene nada que ver con las versiones de la Gestión de Configuración)

Muchos dicen que es una etapa más del ciclo de vida del Software.

Briano no coincide con esto (Ver Apunte de Modelos - 1er Parcial)

Esto es por que no es una etapa obligatoria
Después de la etapa de Implementación no sigue la de Mantenimiento, sino que
sigue la etapa de Garantía.

En Argentina: Generalmente se cobra por el Mantenimiento, por que hay cosas que
no funcionan una vez que se entrega el producto. Por tal motivo es que se arma la
etapa de Mantenimiento, para llegar con el presupuesto, es decir que como muchas
veces no se cuenta con el presupuesto necesario o el mismo es mal administrado,
entonces se reducen etapas claves como la Prueba. De está forma el producto
desarrollado no cuenta con la calidad suficiente y sufre errores pos implementación.
Es ahí en donde con el supuesto Mantenimiento se intenta solucionar los problemas
que se arrastran por achicar las etapas claves para llegar con el presupuesto.

Luego de la Implementación, sigue la Etapa de Garantía, es decir que se garantiza

que el Software va a funcionar. Es importante dejar en claro que es lo que se
garantiza para no tener reclamos posteriormente, informando por ejemplo que el
Software “cumple con el Manual de Usuario”, “Cumple con los requerimientos por el
cual fue creado”, “El Software va a funcionar conforme a lo que el fabricante dice.”

# Errores No Encontrados:
No es la única causa por la cual un Software deba ser modificado, existen otras
cuestiones (incluso si hay Garantía). Hay casos en que si o si se necesita
Mantenimiento:

Según Pressman, existen 4 Tipos de Mantenimiento:

Son 4 Situaciones que generan Mantenimiento, lo importante es que hay algo para
hacer. Por ejemplo si hay una nueva norma, se divide responsabilidades entre el
cliente y el desarrollador)

1). Mantenimiento Correctivo - (CORRIJO POR QUE HAY UN ERROR)

Se ocupa de corregir errores, en general esto debería ser cubierto por la Garantía.
El Software debería entregarse Libre de Errores.
Un Ejemplo de Mantenimiento Correctivo son: Parches que corrigen errores que no
deberían haber estado en el Producto Final.

2). Mantenimiento Adaptativo - (CAMBIOS QUE IMPLICAN CAMBIOS EN LOS

SISTEMAS)
Adaptar el Software de acuerdo al contexto, adaptarlo a una situación que ocurra,
pero NO es considerado un error.
Por ejemplo: Sale una nueva Ley, sale una nueva versión del Sistema Operativo, El
Cliente cambio algún dispositivo o cambio algo del negocio.

3). Mantenimiento Perfectivo - (CAMBIO PARA MEJOR)

Entrega de una versión mejorada:
 Consumir menos recursos
 Que el Software procese más rápido
 Que sirva para más Sistemas Operativos
Perfecciona lo que ya estaba.
No estoy obligado a mejorar lo que funciona Ok.
Se puede cobrar si el cliente acepta la mejora.
Se puede hacer por un tema de imagen o servicio y cobrar lo que sigue.
Depende siempre de lo que se busca cuando se implementa una mejora.

4). Mantenimiento Preventivo - (CAMBIO PARA ANTICIPARME)

Es aquel que se hace previendo o previniendo alguna situación futura que pueda
llegar a ocurrir
Por Ejemplo: Cambio por una nueva norma que esta por salir, pero todavía no salio.
Me adelanto al cambio.

# ESPECIFICAR CLARAMENTE - Buen entendimiento al inicio

1. Cual es el alcance
2. Cuanto se cobra el Mantenimiento (que entra y que no entra)
3. Cuantos pedidos puede hacer el cliente.
4. Cambios razonables (no cambiar todo el sistema)

CAPITULO 31: REINGENIERIA

# Un Gran cambio en Software es hacer otro Software y no Reingeniería!

# Reconstruir un Software que ya está funcionando, para que el Software pueda

cumplir otra funcionalidad.

- Reinventar el Software (evito hacer todas las etapas de cero)

- Reconstruyo las etapas y agrego lo que haga falta o funcionalidad que no tiene (o
no tenia)

Partimos de la Etapa de Prueba:

1° Etapa - Análisis
2° Etapa - Reingeniería Inversa:
 Reconstruyo lo que no tengo
 Diseño
 Desde un Fuente puedo obtener los ejecutables, obtener el código y
regenerarlo (Hay herramientas para hacer esto)
 Reestructuro el código y los distintos componentes.
 Una vez que llegue al inicio, arrancó con la Ingeniería de Software
Tradicional y sigue el proceso habitual.
 Análisis  Diseño  Codificación  Pruebas  Implementación  Garantía
# Obtengo:
- Software con algún cambio
- Partiendo de un Software existente

# REPASAR ESTE TEMA DEL LIBRO DE PRESSMAN POR QUE ALGUNOS

CONCEPTOS NO FUERON VISTOS EN CLASE.