Proyecto

MODELO DE NEGOCIO

Modelo de negocio

Definición:

Un modelo de negocio es una herramienta previa al plan de negocio que te permitirá definir con claridad qué vas a ofrecer al mercado, cómo lo vas a hacer, a quién se lo vas a vender, cómo se lo vas a vender y de qué forma vas a generar ingresos. Es una herramienta de análisis que te permitirá saber quién eres, cómo lo haces, a qué coste, con qué medios y qué fuentes de ingresos vas a tener. Definir tu modelo de negocio es saber cuál es tu ADN, cómo está hecho, cómo se puede modificar, cómo pulir, cómo cambiar, cómo moldear.

Los modelos que están funcionando son aquellos que son capaces de crear valor para el cliente, es decir, que tienen una propuesta de valor clara, que son capaces de llegar al cliente, de diferenciarse, de establecer fuertes lazos con el cliente, de fidelizar y que son capaces de producirlos también de una manera especial.

En términos generales se suele usar para definir como un negocio o empresa genera valor a través de la utilización de la cadena de valor. Si bien esta es una herramienta muy importante, la misma es muy estática, lineal y que no muestra relaciones entre las actividades primarias y las actividades de apoyo.

http://www.emprendedores.es/crear-una-empresa/que-significa-modelo-de-negocio

Componentes:

-Procesos de negocios:

Se trata de un enfoque de gestión integral que, a través de los procesos del Negocio, busca la alineación de aquellos elementos o aspectos de una organización que tengan un impacto directo o indirecto en el producto o servicio que se brinda a los clientes.

Un proceso de negocio es una colección de actividades diseñadas para producir una salida específica para un cliente o mercado particular. Implica en un fuerte énfasis en ‘como’ se hace el trabajo en una organización, en contraposición al enfoque en ‘que’ de producto. Así, un proceso es un ordenamiento especifico de actividades de trabajo a través del tiempo y del espacio, con un comienzo, un fin, entradas y salidas claramente identificados.

-Reglas de negocio:

Son aquellas que se crean durante la configuración de los procesos de manera que hay que definirlas para cada clase de procesos. En otras palabras, son las reglas que definen los comportamientos de ciertos elementos de los procesos como por ejemplo las condiciones de las compuertas. Estas reglas están siempre en todos los sistemas BPM como como condiciones de funcionamiento de los procesos.

-Objeto de negocios:

Un objeto de negocio es un conjunto de compras o elementos que se utilizan conjuntamente para representar un proceso de negocio significativo. Los objetos de negocios se definen como variables para pasar información a través de un proceso de negocio. Cada objeto de negocio puede ser un tipo de datos primitivo (como una serie o un entero) o puede ser en sí mismo un objeto de negocio.

-Actores:

Son las entidades que realizan las actividades del proceso o generan eventos pueden representar a personas dentro de una organización.

Unidades organizativas:

Esto se refiere a como su nombre lo dice unidades organizativas que participan en un diagrama de negocios, se podrían definir como un rol de negocios en general por ejemplo un comprador, vendedor, proveedor.

Notaciones:

UML:
Lenguaje Unificado de Modelado (LUM o UML) es el lenguaje de modelado de sistemas de software más reconocido y usado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para especificar, visualizar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema, incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante decir que UML es un "lenguaje de modelado" para describir o para especificar métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir; es decir en el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso utilizar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
Una de la metas principales de UML es avanzar en el estado de la integración institucional proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo, para lograr un intercambio exitoso de modelos de información entre herramientas, se requirió definir a UML una semántica y una notación.
La notación es la parte gráfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado. Por ejemplo, la notación del diagrama de clases define como se representan los elementos y conceptos como son: una clase, una asociación y una multiplicidad. ¿Y qué significa exactamente una asociación o multiplicidad en una clase?, ¿Un meta modelo es la manera de definir esto (un diagrama, usualmente de clases, que define la notación)?

BPMN:

El Business Modeling Notation o BPMN (Notación para el Modelado de Procesos de Negocios) es un método de negocios que ilustra los procesos en forma similar a un diagrama de flujo. El BPMN fue desarrollado en un principio por el Business Process Management Initiative (BPMNI). Actualmente es sostenido por el Grupo de Gestión de Objetos (OMG).

El BPMN proporciona una manera fácil de definir y analizar los procesos de negocios públicos y privados. Además, brinda una notación estándar que sea comprensible para la gestión del personal, analistas y desarrolladores. La intención original del BPMN era ayudar a establecer puentes de comunicación que a menudo existen dentro de una organización o empresa. Esta notación puede ayudar a asegurarse de que el XML (documentos diseñados para la ejecución de diversos procesos de negocios), puedan ser visualizados con una notación común.

Un diagrama de BPMN es ensamblado a partir de un conjunto de elementos básicos. Los elementos se clasifican en tres grupos:
- Objetos de flujo: figuras geométricas como círculos, rectángulos o rombos de control de flujo que indican los eventos
y actividades.
- Objetos de conexión: trazos o líneas de puntos que pueden incluir flechas para indicar la dirección del proceso.
- Swimlanes (carriles de piscina): llamada así por su semejanza geométrica con las líneas de carril del fondo de  una piscina   olímpica. Rectas sólidas a lo largo y dentro de un cuadrado denominado fondo. El Swinglanes organiza el flujo de objetos en categorías con funcionalidad similar.

DFD:
Un diagrama de flujo de datos (DFD por sus siglas en español e inglés) es una representación gráfica del "flujo" de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado). Es una práctica común para un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción entre el sistema y las entidades externas. Este contexto a nivel de DFD se "explotó" para mostrar más detalles del sistema que se está modelando.
Los diagramas de flujo de datos fueron inventados por Larry Constantine, el desarrollador original del diseño estructurado, basado en el modelo de computación de Martin y Estrin: "flujo gráfico de datos" . Los diagramas de flujo de datos (DFD) son una de las tres perspectivas esenciales de Análisis de Sistemas Estructurados y Diseño por Método SSADM. El patrocinador de un proyecto y los usuarios finales tendrán que ser informados y consultados en todas las etapas de una evolución del sistema. Con un diagrama de flujo de datos, los usuarios van a poder visualizar la forma en que el sistema funcione, lo que el sistema va a lograr, y cómo el sistema se pondrá en práctica. El antiguo sistema de diagramas de flujo de datos puede ser elaborado y se comparó con el nuevo sistema de diagramas de flujo para establecer diferencias y mejoras a aplicar para desarrollar un sistema más eficiente. Los diagramas de flujo de datos pueden ser usados para proporcionar al usuario final una idea física de cómo resultarán los datos a última instancia, y cómo tienen un efecto sobre la estructura de todo el sistema. La manera en que cualquier sistema es desarrollado puede determinarse a través de un diagrama de flujo de datos. El desarrollo de un DFD ayuda en la identificación de los datos de la transacción en el modelo de datos.

IDEFO

IDEF0 constituye una técnica de modelación gráfica, especializada en la representación de las relaciones e interdependencias existentes entre los diferentes procesos, como se muestra en el esquema de la figura 1.1. [Winnik, 2008]

Su principal característica consiste en su capacidad para diferenciar entre tres tipos posibles de relación entre procesos:

1. relaciones que establecen las guías que debe tener en cuenta el proceso.
2. relaciones que aportan los recursos necesarios para llevar a cabo el proceso.
3. relaciones de encadenamiento lineal entre procesos (entrada – salida).

La capacidad de diferenciar relaciones permite modelar organizaciones completas. 

EPC

EPC es modelo dinámico que representa juntos los recursos del negocio como son los sistemas, la organización, datos e información y los organiza para brindar una secuencia de tareas o actividades (el proceso) que añaden valor al negocio. [Davis, 2001]

Esencialmente hay cuatro tipos de objetos usados en EPC:

• Eventos
• Funciones
• Reglas
• Recursos (Datos, organización, sistemas)

La filosofía básica en este tipo de modelos es representar una secuencia evento-función-evento-función-evento…, especificando para cada función las reglas y recursos que intervienen.

https://www.gestiopolis.com/lenguajes-notaciones-herramientas-modelado-analisis-procesos/

http://infoblog-ingsoftware.blogspot.mx/2010/11/las-tres-notaciones-son-y-uml-lenguaje.html

captura del project libre instalado

project libre

PROJECT LIBRE

Realizada ya la instalación y configuración inicial de ProjectLibre en nuestro sistema, revisaremos el modo de iniciar la programación de un proyecto. Para ello haremos un recorrido, principalmente visual, siguiendo una secuencia lógica de ingreso de datos: Tareas, recursos, asignaciones y costos. En esta primera parte destinada al ingreso de datos, revisaremos específicamente lo relacionado con las tareas o actividades.

Cambio del tiempo laborable

Con este fin debemos definir el modo de distribución de la jornada de trabajo, el horario de ingreso, colación y salida de acuerdo a la legislación laboral local, el calendario con los feriados acordes al lugar de ejecución del proyecto. Para ello utilizamos el botón “Calendario” del panel “Proyecto” en la cinta de herramientas.

El programa incorpora tres calendarios base: Estándar, 24 horas y Turno de noche, sobre la base de ellos se pueden crear nuevas plantillas de distribución de la jornada de trabajo. En este caso, se crearon dos plantillas, una en jornada de 9 horas de lunes a viernes, basada en el calendario estándar, y una de días corridos, basada en el calendario 24 horas.

El horario de trabajo establecido, tal como lo indica el cuadro de configuración, aplica a las duraciones de las tareas. Esta configuración se realiza en el botón “Opciones”.

Para establecer un feriado, basta con seleccionar el día desde el calendario, y establecerlo como “No laborable”.

Información del proyecto

En el botón “Información” del panel “Proyecto” en la cinta de herramientas, abrimos el cuadro de configuración para incorporar datos como el nombre del proyecto, el responsable a cargo, su fecha de inicio, el calendario base, etc.

Listado de tareas y duración

El ingreso de las tareas o actividades y sus duraciones se realiza manualmente o copiando y pegando desde una planilla de cálculo como LibreOffice Calc, como se ha hecho en este caso.

La indentación, o jerarquización de las tareas de acuerdo a una Workbase Structure o WBS, se ejecuta con el botón “Sangrar” de la pestaña “Tarea”. Se pueden seleccionar grupos de tareas para aplicar sangría en bloques.

Vinculación entre tareas

La vinculación se realiza seleccionando dos o más tareas y presionando el botón “Vincular” de la pestaña “Tarea”. El vínculo siempre se produce desde arriba hacia abajo, de modo que el listado de tareas debe respetar el orden secuencial, con las predecesoras antes de las sucesoras. Al seleccionar varias tareas, éstas quedan vinculadas en secuencia lineal.

El vínculo predeterminado es “de fin a comienzo”, pero se puede modificar esto, así como la eventaual posposición de una tarea respecto de su antecesora, haciendo clic en la flecha de vínculo, e incorporando estas modificaciones en el cuadro de configuración de “Dependencia de la Tarea”, como se muestra a continuación.

Vistas alternativas

El programa entrega la posibilidad de visualizar la estructura principal de la programación o WBS, y la estructura de red de ésta. Se trata de visualizaciones, sin posibilidad de configurar los datos que se muestran.

WBS

Red

Inserción de columnas

El programa entrega la posibilidad de incorporar columnas adicionales en la tabla de datos que acompaña a la carta Gantt. Para ello basta con hacer clic con botón derecho sobre el encabezado de una columna existente, y seleccionar la opción “Insertar Columna”.

Las opciones incluyen columnas de información predeterminadas por el programa, y columnas con campos personalizados de texto o numéricos.

Configuración avanzada de tareas

Finalmente, podemos comprobar que existe un cuadro de “Información” en la pestaña de “Tareas”, que nos permite acceder a aspectos que se clasifican como “Adelantados”, en los que podemos establecer el tipo de tarea, el tipo de restricción temporal al que está sujeta, el calendario asociado, y el porcentaje completado.

Hasta aquí la información respecto del ingreso y administración de tareas o actividades de proyecto.

FASES DE LA INGENIERÍA DE SOFTWARE

FASES DE LA INGENIERÍA DE SOFTWARE:

Cualquier sistema de información va pasando por una serie de fases a lo largo de su vida.

Su ciclo de vida comprende una serie de etapas entre las que se encuentran las siguientes.

• ·         Análisis
• ·         Diseño
• ·       Programación
• ·         Pruebas
• ·         Implementación
• ·         Mantenimiento
• ·         Etapa final EOL

Etapa de análisis: Esta etapa tiene por objeto realizar un análisis global del sistema, estableciendo los requisitos de todos los elementos del sistema y luego asignar al software la parte de los requisitos que le afectan. Este planteamiento del sistema es esencial cuando el software debe interrelacionarse con otros elementos, tales como personas, hardware y bases de datos.

Se debe tener tener en cuenta cuando se informatiza un problema que existen tareas manuales que se deben tratar dentro del sistema. Es decir, el análisis del sistema comprende el tratamiento de todas la tareas manuales e informáticas que definen el sistema. Para ello, el ingeniero informático tendrá que estudiar a fondo todo sistema, especializarse en su terminología y realizar una interacción permanente con el cliente, el experto del sistema u los usuarios de forma que la percepción que tenga del sistema coincide con la del cliente, experto y usuario.

El análisis del sistema es una etapa de la fase de planificación y en ella se realiza una descripción del entorno, software que se quiere obtener y se define los recursos humanos para su desarrollo, el coste y el calendario estimado.

En concreto, el análisis del sistema presenta los siguientes objetivos:

• Identificar las necesidades del cliente.
• Realizar un análisis técnico y económico del sistema.
• Establecer restricciones de costo y tiempo.
• Evaluar la viabilidad del sistema.
• Asignar funciones al software, a la gente, a las bases de datos y otros elementos del sistema.
• Definir el sistema.

Etapa de diseño: Es el primer paso en la fase de desarrollo de cualquier producto o sistema de ingeniería. Define como el proceso de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, proceso o sistemas con los suficientes detalles como para permitir su realización física. El objetivo del diseñador es producir un modelo o representación de una entidad que será construida mas adelante. Esta etapa se suele dividir en dos:

         1. Diseño Preliminar 

             1.1 Diseño de datos.

             1.2 Diseño arquitectónico.

             1.3 Diseño de la interfaz hombre-máquina.

         2. Diseño Detallado

             2.1 Diseño Procedimental

Etapa de Programación: Se traduce el diseño a código. Es la parte más obvia del trabajo de ingeniería de software y la primera en que se obtienen resultados “tangibles”. No necesariamente es la etapa más larga ni la más compleja aunque una especificación o diseño incompletos/ambiguos pueden exigir que, tareas propias de las etapas anteriores se tengan que realizarse en esta.

Etapa de pruebas o verificación prueba: consiste en asegurar que los componentes individuales que integran al sistema o producto, cumplen con los requerimientos de la especificación creada durante la etapa del diseño.

Etapa de implementación o entrega implantación: Consiste en poner a disposición del cliente el producto.

Etapa de mantenimiento: El software producido en la fase de desarrollo debe ser mantenido, ya que sufrirá cambios después de que se entreguen al cliente. Los cambios ocurrirán debido a:

• Errores encontrados (mantenimiento correctivo).
• Cambios en el entorno externo al que el software debe adaptarse (mantenimiento adoptativo).
• Que el cliente requiere ampliaciones funcionales o desea incrementar su rendimiento (mantenimiento perfectivo).

Esta fase comporta diferentes actividades: por un lado comprobar que toda la documentación esta disponible y es adecuada para las tareas de mantenimiento. y por otro establecer un esquema de acciones para el caso de error o modificación del software y comunicar al usuario esas acciones.

Etapa final EOL (END –OF-LIFE): el fin del ciclo del producto consiste en realizar todas las tareas necesarias para asegurar que los clientes y los empleados están conscientes de que el producto ya no será vendido ni soportado.

Conceptos básicos de ingeniería de software

Conceptos básicos de  ingeniería de software:

La ingeniería de software es una disciplina formada por un conjunto de métodos, herramientas y técnicas que se utilizan en el desarrollo de los programas informáticos (software).

Esta disciplina  trasciende la actividad de programación, que es la actividad principal a la hora de crear un software. El ingeniero de software se encarga de toda la gestión del proyecto  para que éste se pueda desarrollar en un plazo determinado y con el presupuesto previsto.

La ingeniería de software, por lo tanto, incluye el análisis previo de la situación, el diseño del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto funcionamiento y la implementación del sistema.

es una disciplina de la ingeniería que comprende todos los aspectos de la producción del software desde las etapas iniciales de la especificación del sistema hasta el mantenimiento de éste después de que se libera.

la ingenieria de Software incluye:

• Procesos(la manera en que se hace)
• Proyecto(la realizacion)
• Producto(la aplicacion de artefactos)

el proceso de modelado de software:

Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. El proceso de desarrollo de software no es único. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difícil automatizar todo un proceso de desarrollo de software.

Modelos de proceso software 1.-Modelo en cascada El más conocido, está basado en el ciclo convencional de una ingeniería, el paradigma del ciclo de vida abarca las siguientes actividades:

2.-Modelo evolutivo La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. En la Figura 6 se observa cómo las actividades concurrentes: especificación, desarrollo y validación, se realizan durante el desarrollo de las versiones hasta llegar al producto final.

Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

3.-Modelo incremental El enfoque incremental de desarrollo se ve como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema (ver Figura 10). Es una combinación del Modelo de Cascada y Modelo Evolutivo.

Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema. Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

4.-Modelo en espiral

El modelo espiral para la ingeniería de software ha sido desarrollado para cubrir las mejores características tanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo al mismo tiempo un nuevo elemento: el análisis de riesgo. El modelo representado mediante la espiral de la figura 2.4, define cuatro actividades principales:

• Planificación: determinación de objetivos, alternativas y restricciones.
• Análisis de riesgo: análisis de alternativas e identificación/resolución de riesgos.
• Ingeniería: desarrollo del producto del "siguiente nivel",
• Evaluación del cliente: Valorización de los resultados de la ingeniería.