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