6 - MANTENIMIENTO

o como mantener el valor de la inversión

 Todo software instituido presentara problemas que se manifestaran en disconformidades y/o fallas

  Algún defecto de procesos anteriores se manifestara como una falla , o sera la causa de           algún problema
  Ademas , los requerimientos del ambiente donde esta instituido , cambian con el tiempo

Esta problematica se ha enfrentado con el concepto de "mantenimiento"

Las fallas y /o disconformidades son la causa de las actividades que conocemos como "MANTENIMIENTO"
Según la IEEE mantenimiento es la molificación de un producto de software después de liberado , para corregir fallas , mejorar perfomance u otros atributos , o adaptar un producto a un ambiente cambiante

La esperanza matemática de que se manifieste una falla o disconformidad    es =0
El soft es una inversión , por lo tanto el mantenimiento es el costo por alcanzar los beneficios esperados .
Depende del área que afecten y del concepto de costo que una empresa utilice.
De cualquier manera debe ser un costo planificado porque es un gasto esperado
Son de utilidad las normas ieee 1219 , iso 9216 ,14764
Mantenimiento es
             Correctivo
                      Modificación en respuesta a una falla descubierta después de la institucion
             Adaptativo
                      Modificación hecha para mantener el soft funcionando ante cambios en el medio                                   ambiente
             Perfectivo
                     Modificación hecha para dotar al soft de nuevas propiedades
                     básicamente , mantenibilidad y perfomance
             Preventivo
                    No se considera en la IEEE 1219.
                    "Modificación del producto software tras la entrega para detectar y corregir
                    fallos latentes antes de que se conviertan en fallos efectivos".(ISO 9216)
                    Modificaciones hechas para mejorar  y optimizar el soft  . Revisión continua y mejora                         para anticipar rigidez de uso (bsicamente mantenibilidad  y perfomance).
                    Si un soft tiene demasiadas rigideces , esta "muerto" , todo soft necesita ser revisado para                     asegurar que se mantienen "los grados de libertad esperados" , caso contrario se                                   generaran gastos mayores
                    Este mantenimiento es una cuestión %100 técnica ,

Las Fallas de "mortalidad infantil" son un síntoma de defectos en las etapas anteriores y no es eficiente encararlas con una "orden de trabajo de mantenimiento"

5- instalación , institucion

Instalación:

Colocar un cosa en un lugar para que funcione correctamente o realice la función que le corresponde.

proceso durante el cual el soft desarrollado es preparados para ser ejecutados en el  ámbito real (destino o sistema objeto), para cumplir la función por la cual fueron desarrollados
Hay que asegurar la compatibilidad con los recursos disponibles y la accesibilidad
Se puede ensayar el funcionamiento a escala reducida (prueba piloto) para verificar  la compatibilidad y accesibilidad
Hay que asegura la disponibilidad  de servicios imprescindibles , caso contrario instalarlos
Hay que  configurar con datos apropiados para que el soft funcione de la forma esperada , para ello
seteamos  información necesaria ,asegurando  acceso a información  externa y a infraestructura    
Las habituales tareas de esta etapa

•        Generación de accesos
•        Prueba de funcionamiento
•        Generacion de instaladores
•        Guias de uso para usuarios
•        Entrenamiento de uso

Institucion

Instituir significa: crear ,erigir , establecer , instaurar (se parece al termino implantar del diccionario IBM)
Se instituye una alteración en el sistema de trabajo (un cambio que perdurara)
Eso altera la regla del equilibrio P-R-S  (propósito - recurso - sistema)
Tendremos que trabajar para que se produzca un desplazamiento hacia un nuevo equilibrio conveniente.
En sistemas conocidos , o de reemplazo basta con asegurarse que los usuarios resuelven sus problemas  explotando las nuevas herramientas.
En otros casos , la llegada de un nuevo sistema puede implicar reorganizacion de funciones , cambios en el flujo del trabajo , etc.
Esos casos requieren de manuales , entrenamiento en resolucion de problemas , talleres , help desk y un trabajo cercano con los promotores para que puedan apreciar que el cambio :es el que esperaban
Esta etapa ya empieza a generar cambios (todos urgentes) en el soft , hay que estar listo para el mantenimiento correctivo de prioridad urgente
Hay que prepararse porque se alteran todas las tareas de soporte

Documentación
Configuracion
Calidad
Vinificación
Validacion
Reuniones
Auditorías
Resolucion de problemas
Organizacionales
Gerenciamiento
Infraestructura
Mejora
Entrenamiento

El final de esta etapa es cuando el soft y todo su impacto , es parte normal del trabajo diario

4-Pruebas

 

4.1.1)Prueba: de integracion

En este caso probamos cómo es la interacción entre dos o mas unidades del software.

Este tipo de pruebas verifican que los componentes de la aplicación funcionan correctamente actuando en conjunto.

Siguiendo con el caso anterior, las pruebas de integración son las que comprobarían que se ha mandado un email, la conexión real con la base de datos etc.

Este tipo de pruebas son dependientes del entorno en el que se ejecutan. Si fallan, puede ser porque el código esté bien, pero haya un cambio en el entorno.

Por ejemplo, también podríamos usar JUnit para realizar pruebas de integración, si no hacemos mocks o stubs, y nos centramos en probar el comportamiento de los componentes en su conjunto.

4.1..2)Pruebas de sistema

Aquí se engloban tipos de pruebas cuyo objetivo es probar todo el sistema software completo e integrado, normalmente desde el punto de vista de requisitos de la aplicación.

Aquí aparecerían las pruebas funcionales, pruebas de carga, de estrés etc.

4.1..3)Pruebas de carga

Las pruebas de carga son un tipo de prueba de rendimiento del sistema. Con ellas observamos la respuesta de la aplicación ante un determinado número de peticiones.

Aquí entraría por ejemplo ver cómo se comporta el sistema ante X usuarios que entran concurrentemente a la aplicación y realizan ciertas transacciones.

4.1..4)Pruebas de estrés

Este es otro tipo de prueba de rendimiento del sistema. El objetivo de estas pruebas es someter al software a situaciones extremas, intentar que el sistema se caiga, para ver cómo se comporta, si es capaz de recuperarse o tratar correctamente un error grave.

4.1..5)Pruebas de aceptación

Por último, las pruebas de aceptación se realizan para comprobar si el software cumple con las expectativas del cliente, con lo que el cliente realmente pidió.

4.2)Prueba de instalacion (o despliegue)

       Se trata de emular el ambiente donde se instalara el soft con el objetivo de verificar que el soft es instalable.

      Experimentar configuraciones optimas posibles  de cada server , servicio , puesto de trabajo , flujo de tareas

       -Generar instaladores 
      - Documentacion del entorno requerido/esperado

3-Implementación: codificacion o traslado del diseño en un lenguaje

4.1 diseño
      En el ámbito de la programacion , pensando la mejor forma de cumplir las especificaciones
4.2  Construccion
       Generación de código a partir de : reuso , componentes , rad  , codificacion artesanal de partes            visuales y   no-visuales
              /      
                                         

  4.3       depuración
            Para conseguir programas efectivos y libres de errores. Pulido / espulgado
  4.4       Pruebas unitarias y de programa
            Se trata de verificar que se cumplen requisitos funcionales y de integracion
  4.5       Documentacion
            Lo mas importante es documentar las decisiones del programador , las excepciones incorporadas , los problemas resueltos.
             los contratos asumidos y salidas correctas esperadas

Extensiones:
Es una mejora . Una propiedad o atributo nuevo . Una innovación en la aplicacion
Las extensiones no afectan el servicio básico del app existente.
Son propiedades que se piensan buscando el beneficio . No alteran la ecuación Propósito- Recurso- Sistema
Buscamos aplicar la máxima : los procesos deben minimizarse , eliminando , combinando o simplificando procesos existentes

2- Diseño:

Es una fase conceptual , diseñar consiste en decidir una alternativa para los procesos ; seleccionando y particionando con un criterio eficiente las estructuras de información  , los procesos y algoritmos de tal forma que sea posible desarrollar aplicaciones que impacten positivamente (mejorando)  en el sistema concreto servido.
Creo que es un acto unipersonal , eso asegura unidad conceptual . Los diseños por comité han sido de utilidad para sistemas o aplicaciones muy ambiciosas , muchas fueron un exceso de burocracia en su desarrollo y en sus resultados
Arquitectura
la arquitectura de software trata con el diseño e implementación de las estructuras de alto nivel del soft. Es el resultado de ensamblar un cierto numero de elementos en componentes bien seleccionados para satisfacer la mayor parte de los requerimientos de funcionalidad y perfomance del sistema, como también otros requerimientos no funcionales como escalabilidad , portabilidad  ,confiabilidad
Perry y wolfe lo puso en una formula modificada por bohem
Software architecture = {Elements, Forms, Rationale/Constraints}
La arquitectura de software lidia con abstracción,descomposición y composición, con estilo y estética

Especificación
1. Definición del problema
2. Descripción funcional
3. Restricciones
4. Diagramas de flujo de datos
5. Modelo de datos
6. Diccionario de datos
7. Casos de uso
8. Documentos adicionales

 La especificación y el código son descripciones formales del resultado
– Tal vez en diferentes niveles de abstracción
– Tal vez con distinto detalle
– Tal vez con otro nivel de declaratividad
– Las dos pueden tener errores
La especificación  se verifica; el software se prueba
Al software lo probamos ejecutando test con la computadora
Si la especificacion esta descripta utilizando un lenguaje formal , entonces la vinificación puede hacerse con la computadora
Si no tenemos especificación, no hay  control
Las especificaciones se presentan como
   1- Documentar el proceso
   2- Documentar el producto

                                        El Proceso del Sofware

El proceso de ingenieria aplicado al Soft como producto , es el proceso de transformacion  de requerimientos en soft util. Ese proceso ademas debe ser administrado para que se lleve a cabo en un ambiente de equilibrio con las metas seleccionadas par el proceso
tenemos ya para onsiderar
1- el proceso
2- los actores y facilitadores
3- las metas del proceso
4- el soft o producto
5- el sistema o ambiente beneficiario , donde el soft desarrollar sus propiedades

Todo esto , para empezar. Porque es necesario considerar que estos factores nunca son los mismos
Osea , no sirve una Maquina generadora de requerimientos , ni una Maquina generadora de soft
Aunque tampoco el caos de que todo se reduzca a generar soft
El proceso es un framework , una parte del  habitual concepto de Proyecto de cualquier empresa
Aunque sea solo conceptual , es beneficioso considerarlo como el marco de nuestro trabajo
Esto nada que ver con teorias , aunque obvio se basa y se toma lo beneficioso que hay (y mucho)

1-Anteproyecto

Esta etapa es imprescindible , en el ambiente del PERT seria la etapa 0. En una vision minima seria la etapa de deliberacion . La de las decisiones y descubrimientos.En ambientes clasicos de informatica seria la etapa de analisis
Por lo menos respondernos
✶si hay algo para hacer ,
✶si vale la pena ,
✶si podremos hacerlo y
✶si podremos describirlo anticipadamente.

Puede ser un trabajo recursivo hasta que se concluye en
➤Especificacion de Requisitos
➤Plan del proyecto

       Formulación del Problema

                 Como están las cosas ahora? (Propósito - Recurso - sistema)
                 Como estarán después de instituido nuestro soft?  (Propósito - Recurso - sistema)
                 Restricciones
                        Que debe suceder?
                        Que no debe suceder?
                         Costos que no pueden superarse?
                        Cuales son los requisitos del tiempo? (limites, precedencias)
                 Que señal aprovecharemos para indicar  el éxito del proyecto?
             
             

Conceptos:

                         el problema es una dificultad ; que factores ayudan a superarla? , que factores dificultan la solución?
                           inversión: es la utilizacion de unos recursos escasos en el proyecto , con la esperanza de que nuestro soft permita obtener beneficios superiores a su aplicacion en otros proyectos
acuerdos: El cliente y tambien nuestros tecnicos pueden tener visiones diferentes , percepciones , ventajas y/o dificultades que para aprovecharlas positivamente deben fusionarse en acuerdos previos
                          Objetivos y metas: los objetivos y metas se deben seleccionar con vision de ingenieria del sistema dondes sera instiuido nuestro soft, genralmente son propiedad de los propietario o gerentes . Es importante incorporarlos a partir de acuerdos con ellos

Requerimientos y Requisitos 

¿Qué es un requisito? (wikipedia)

• Condición o capacidad que un usuario necesita para poder resolver un problema o lograr un objetivo (IEEE).
• Condición o capacidad que debe exhibir o poseer un sistema para satisfacer un contrato, estándar, especificación, u otra documentación formalmente impuesta (IEEE).
• Una condición o capacidad que debe ser conformada por el sistema (RUP).
• Algo que el sistema debe hacer o una cualidad que el sistema debe poseer (Robertson - Robertson).
• ---------------------------------------
• Generalmente el sistema a servir es de nivel mayor o incluye al de nivel menor. Por lo que se puede inferir, que para conocer los requerimientos del sistema menor debemos primero conocer los requerimientos del sistema mayor a servir. Es decir, que para definir los requerimientos de software, en el campo de las tecnologías de información, primero debemos definir los requerimientos de los niveles mayores en el siguiente orden: nivel organización, proceso de negocio (sistema de trabajo) y sistema de información; para evitar convertir un problema real en un problema virtual.

        Plan del proyecto
Una definicion de plan:Determinacion sistematica previa de los fines productivos ,   de los recursos y actividades necesarias para conseguirlos
Una actividad es: una "unidad de control" , un proceso que adquiere insumos , le aplica recursos y metodos y genera productos. Para facilitr el control se debe seleccionar la cantidad minima de insumos y generar un producto. Para facilitar el control tanto los recursos como los metodos deben ser standard de la industria.La unidad debe tener caracteristicas medibles. El /los productos deben ser entregables
El enfoque funcional es el mas aplicable: una funcion o servicio=una unidad=un moduo=una componente
Un calendario del proyecto es un calendario de entregables

PRIORIDADES
Categorización de incidentes
La categorización del incidente a resolver es fundamental para su adecuado
tratamiento y pronta resolución (o sea, eficiencia y eficacia).
La categoría define el recorrido del incidente en la organizacion . Una categoría equivocada puede hacer que un incidente “navegue sin rumbo” dentro del área TI.

Prioridad: secuencia en que se tratarán los incidentes.
 Se determina por el impacto, la urgencia y el esfuerzo.
 Impacto: desde el punto de vista del negocio.
 Urgencia: es la velocidad con la que debe resolverse el incidente.
 La prioridad y la urgencia no se definen en base a la presión del usuario
sino según los procedimientos y los acuerdos de servicio. Deben usarse
criterios uniformes y preestablecidos

IMPACTO

El criterio típico debería incluir:
Coste potencial de la no-resolución  (para el cliente)  ej: (2/4) grande,0 pequeño(1/4) desconocido
Amenaza de lesión a clientes o empleados              ej: (2/4) grande,0 pequeño,(1/4) desconocido
Implicaciones legales                                                   ej:(2/4)  grande,0 pequeño(1/4) desconocido
Trastorno a clientes y empleados                               ej:(2/4)  grande,0 pequeño,(1/4) desconocido
El impacto no trata de la complejidad de la solución

ESFUERZO

0 pequeño 1/2 dia
1 intermedios o desconocidos 1-2 dias
2 grande   minimo3 dias

URGENCIA (fecha compromiso-hoy)

 entre 0 y 3 dias                         -> 2
 entre 3 y 5 dias o desconocido -> 1
 mayor de  5                    ->  0

Un esquema de PRIORIDAD

1->normal esfuerzo (0)    ,pequeña urgencia (0) ,impacto (0)
2->importante esfuerzo (1),normal urgencia  (1) , impacto (1) ,
3->alta  : esfuerzo es (2),alta urgencia    (2) , impacto (2)

ORDENES DE PAGO

Este tema es una de las encrucijadas de empresas productivas / servicio/comerciales
Es un "nudo" , una intersección de transacciones
El proveedor nos emite facturas por sus servicios /productos
Esos y otros comprobantes constituyen la "deuda" con el proveedor
Al momento de disminuir el nivel de lo adeudado , surgen una serie de preguntas
Que esta pendiente de pagar a xxxx?
Cuando fue el ultimo pago hecho?
Que cheque recibimos de clientes como pago y están a tiempo para utilizarlos?
Cuanto se pago de la factura xxxxx?
Que saldo hay en el banco yyyy?
Como quedara la deuda después del pago?
Sera conveniente pagar el 100% de lo adeudado ?
Que pasa si se paga una parte?
Los procesos informatizados generan registracion de la deuda?
etc
etc
etc
Por ejemplo una empresa de transporte contrata camiones para sus servicios
El sistema de transporte genera la registracion de la deuda de cada viaje
Cuando se paga , además de actualizar las cuentas de los proveedores y bancos , se actualizan la caja y el iva compras

Esta es una versión refinada y extendida de lo citado en post anterior
Se ha dado mucha importancia a la necesidad de manejo sencillo para que no sea imprescindible la existencia de una función de tesorería o administración de pagos
Cualquier persona responsable y cuidadosa puede obtener resultados importantes

Cilcos de desarrollo:
ciclo de desarrollo evolutivo o iterativo o que?
El concepto de un desarrollo evolutivo implica cambio y eso esta muy bien . Pero quien asegura que el cambio es una evolucion ?
La teoria hace muy apetitosa la idea de un proceso de desarrollo guiado por el concepto de evolucion.
Un proceso de desarrollo iterativo hace pensar en la famosa espiral
Entonces nos auxilia el concepto del prototipo
Pero en el mundo de todos los dias me parece mas correcto el proceso de : versiones sucesivas
porque aparte de los errores y defectos que seran mejorados en las proxmas versiones , es fundamental el siguiente tema: requerimientos cambiantes o nuevos que implican una nueva version del soft

Factura  electronica

Se desarrollo una etension de las app existentes

El usuario genera una factura ; el app lo manda al web service del afip y devuelve su aprobacion

O sea que sobre un tradicional sistema de stocks nuestro ; corriendo una conversion de tablas y agregado datos de configuracion , se puede agregar la componente de FACTURACION ELECTRONICA .

Y extiende un sistema con:

-Multiples depositos

-Multiples puestos de trabajo

-Multiples operadores del sistema

-Multiples vendedores

-Multiples precios

-Recargos / Limite de venta y deuda a Clientes 

-Circuito de reposicion de mercaderia

-Remitos y posterior facturacios de remitos

-Presupuestos y posterior facturacion

-Control de Formas de Pago

-Cuentas corrientes
-Tarjetas de credito
-Analisis de Venta
-Analisis de Margenes
-Analisis Anual
-Valorizacion de stoks
-etc
-etc
-etc