Objetivo general

Los objetivos generales corresponden a las finalidades genéricas de

un proyecto o entidad.

No señalan resultados concretos ni directamente medibles por medio

de indicadores pero si que expresan el propósito central del proyecto.
Tienen que ser coherentes con la misión de la entidad. 

Los objetivos generales se concretan en objetivos específicos.

Objetivo especifico
Se derivan de los objetivos generales y los concretan, señalando el
camino que hay que seguir para conseguirlos. Indican los efectos
específicos que se quieren conseguir aunque no explicitan acciones
directamente medibles mediante indicadores. 

Modelado de negocios
El modelado de negocios se define como un proceso de representación de uno o más aspectos o
elementos de una empresa como el propósito, su estructura, funcionalidad, dinámica, lógica de
negocios y componentes como fines, procesos, reglas, objetos, actores y unidades organizativas
entre otras.

Se puede definir el modelado de negocios como una herramienta conceptual que contiene un
conjunto de objetos, conceptos y sus relaciones con el objetivo de expresar la lógica del negocio de
una empresa (Osterwalder, Pigneur & Tucci, 2005:1). Proporciona una vista simplificada de la
estructura de negocios que actúa como la base para la comunicación, mejoras o innovación y
define los requisitos de los sistemas de información que apoyan la empresa (Ericsson & Penker,
2000:1).
 Componentes del modelos de negocios de un proyecto de software se centra en las cuatro
P's: personal, producto, proceso y proyecto. El orden no es arbitrario.
  Personal
  Personal el factor humano tan importante. Se ha desarrollado un Modelo de madurez de
la capacidad de gestión de personal (MMCGP) para aumentar la preparación de
organizaciones del software para llevar a cabo las complicadas aplicaciones ayudando a
atraer, aumentar, motivar, desplegar y retener el talento necesario para mejorar su capacidad
de desarrollo de software.
  El modelo de madurez de gestión de personal define las siguientes áreas clave prácticas
para el personal que desarrolla software: reclutamiento, selección, gestión de rendimiento,
entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y del trabajo y
desarrollo cultural y de espíritu de equipo.
  Producto
  Producto para poder planificar un proyecto, se deben establecer los objetivos, el ámbito
del producto, soluciones alternativas e identificar las dificultades técnicas y de gestión. Sin
esta información es imposible definir unas estimaciones exactas del coste, valoración efectiva
del riesgo, subdivisión realista de las tareas del proyecto o una planificación del proyecto
asequible que proporciona una indicación fiable del progreso.
  El ámbito identifica los datos primarios, funciones y comportamientos que caracterizan al
producto, y, más importante, intenta abordar estas características de una manera cuantitativa.
  Una vez que se han entendido los objetivos y el ámbito del producto, se consideran
soluciones alternativas.
  Proceso
  Un proceso de software proporciona la estructura desde la que se puede establecer un
detallado plan para el desarrollo del software. El conjunto de tareas, hitos, productos del
trabajo y puntos de garantía de calidad, permiten a las actividades estructurales adaptarse a
las características del proyecto de software, requisitos del equipo del proyecto, las garantía de
calidad del software, gestión de la configuración del software y medición cubren el modelo de
proceso. Las actividades protectoras son independientes de las estructurales y tienen lugar a
lo largo del proceso.
Proyecto Para gestionar un proyecto de software con éxito, debemos comprender qué puede
ir mal para hacerlo bien. Se define diez señales que indican que un proyecto de sistemas de
información está en peligro:
 La gente del software no comprende las necesidades de los clientes.
 El ámbito del producto está definido pobremente.
 Los cambios están mal realizados.
 La tecnología elegida cambia.
 Las necesidades del negocio cambian ó están mal definidas.
 Las fechas de entrega no son realistas.
 Los usuarios se resisten.
 Se pierden los patrocinadores ó nunca se obtuvieron adecuadamente.
 El equipo del proyecto carece del personal con las habilidades apropiadas.
 Los gestores y los desarrolladores evitan buenas prácticas y sabias lecciones.

Diagrama de Funciones Cruzadas

Use diagramas de flujo de funciones cruzadas para mostrar la relación entre un proceso
empresarial y las unidades funcionales (como departamentos) responsable de ese
proceso.
Las calles del diagrama de flujo representan unidades funcionales, como departamentos o
cargos. Cada forma que representa un paso del proceso se coloca en la calle para la
unidad funcional responsable de dicho paso.

1. Identificar el proceso 

- ¿Cuáles son las entradas?

- Indicadores 
- Documentos que intervienen en el proceso
- Recursos o materiales
Pasos para realizar un diagrama de flujo 
No se debe usar una figura que no se encuentre en la simbología 
Puntos a cuidar
Tiene un elemento 
que lo diferencia del 
diagrama de flujo básico, 
unos contenedores 
llamados "calles"
2. Identificar a los departamentos que intervienen en el proceso y de que
actividad se encargan durante el proceso
3. Comenzar con la realización en la platilla asignada para diagramas 
No incluir imágenes 
Llevar un orden y relación de los pasos a seguir entre los departamentos
Las actividades deben empezar con verbos en infinitivo (ar, er, ir)

Especificación de requerimientos
(1) Una condición o necesidad de un usuario para resolver un problema o
alcanzar un objetivo. (2) Una condición o capacidad que debe estar
presente en un sistema o componentes de sistema para satisfacer un
contrato, estándar, especificación u otro documento formal. (3) Una
representación documentada de una condición o capacidad como en (1) o
(2). 
Las características de un requerimiento son sus propiedades principales.
Un conjunto de requerimientos en estado de madurez, deben presentar
una serie de características tanto individualmente como en grupo. A
continuación se presentan las más importantes. 
Necesario: Un requerimiento es necesario si su omisión provoca una
deficiencia en el sistema a construir, y además su capacidad,
características físicas o factor de calidad no pueden ser reemplazados por
otras capacidades del producto o del proceso. 
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su
redacción debe ser simple y clara para aquellos que vayan a consultarlo en
un futuro. 
Completo: Un requerimiento está completo si no necesita ampliar detalles
en su redacción, es decir, si se proporciona la información suficiente para
su comprensión. 
Consistente: Un requerimiento es consistente si no es contradictorio con
otro requerimiento. 
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretación. 
Verificable: Un requerimiento es verificable cuando puede ser
cuantificado de manera que permita hacer uso de los siguientes métodos
de verificación: inspección, análisis, demostración o pruebas. 
Los requerimientos puedes dividirse en requerimientos funcionales y
requerimientos no funcionales.
Requerimientos funcionales
Definen las funciones que el sistema será capaz de realizar. Describen las
transformaciones que el sistema realiza sobre las entradas para producir
salidas. 

Requerimientos no funcionales
Tienen que ver con características que de una u otra forma puedan limitar
el sistema, como por ejemplo, el rendimiento (en tiempo y espacio),
interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de
equipo), mantenimiento, seguridad, portabilidad, estándares, etc. 
Documento Visión y Alcance
Define el alcance y el objetivo de alto nivel de un programa, producto o proyecto. Una
declaración clara del problema, una propuesta de solución y las características de alto
nivel de un producto ayudan a establecer expectativas y reducir riesgos

Incluye el objetivo, el alcance, las definiciones, los acrónimos, las abreviaturas, las
referencias y una visión general de todo el documento.
1.1 Objetivo: Presentar el objetivo de este documento de visión.
1.2 Alcance: Describir brevemente el alcance de este documento de visión,
incluidos los programas, proyectos, aplicaciones y procesos empresariales
asociados con el documento. Incluya cualquier otro elemento que afecte o influya
en el documento.
1.3 Definiciones, acrónimos y abreviaturas: Defina todos los términos,
acrónimos y abreviaturas necesarias para interpretar la visión correctamente. Esta
información puede ser proporcionada en relación con el glosario del proyecto, que
puede desarrollarse en línea en el repositorio de Rational Requirements
Composer.
1.4 Referencias: Enumere todos los documentos al que hace referencia el
documento de visión. Identifique cada documento por el título, número de informe
(si procede), fecha y organización de publicación. Especifique las fuentes de las
que los lectores pueden obtener las referencias; las fuentes idealmente se
encuentran disponibles en Rational Requirements Composer o en otros
repositorios en línea. Esta información puede ser proporcionada en relación con
un apéndice u otro documento.
1.5 Visión general: Describa el contenido del documento de visión y explique
cómo se organiza el documento.

Casos de uso
Un caso de uso es una descripción de las acciones de un
sistema desde el punto de vista del usuario. Es una
herramienta valiosa dado que es una técnica de aciertos y
errores para obtener los requerimientos del sistema,
justamente desde el punto de vista del usuario.

Símbolos de los casos de uso

Sistema: El rectángulo representa los límites del sistema que
contiene los casos de uso. Los actores se ubican fuera de los
límites del Sistema.

Figura 3: Sistema de Casos de Uso

Caso de uso: Se representan con óvalos. La etiqueta en el
óvalo indica la función del sistema.

Figura 4: Casos de Uso

Actor: Un diagrama de caso de uso contiene los símbolos del
actor y del caso de uso, junto con líneas conectoras. Los actores
son similares a las entidades externas; existen fuera del
sistema. El término actor se refiere a un rol específico de un
usuario del sistema.

Figura 5: Actor que inicia el caso de uso

Por ejemplo:
Un actor puede ser un empleado, pero también puede ser un
cliente en la tienda de la empresa. Incluso cuando es la misma
persona en el mundo real, se representa como dos símbolos
distintos en un diagrama de caso de uso, ya que la persona
interactúa con el sistema en distintos roles.

Figura 6: Características de los actores 

3.3. Relaciones
Las relaciones entre un actor y un caso de uso, se dibujan con
una línea simple. Para relaciones entre casos de uso, se utilizan
flechas etiquetadas “incluir” o “extender.” Una relación “incluir”
indica que un caso de uso es necesitado por otro para poder
cumplir una tarea. Una relación “extender” indica opciones
alternativas para un cierto caso de uso.

Figura 7: Ejemplo de Casos de Uso

3.3.1. Relaciones de los casos de uso
Las relaciones activas se conocen como relaciones de
comportamiento y se utilizan principalmente en los diagramas
de casos de uso. Hay cuatro tipos básicos de relaciones de
comportamiento: comunica, incluye, extiende y generaliza.
 Figura 8: Relaciones entre los Casos de Uso

Diagrama de casos de uso

os diagramas de caso de uso modelan la funcionalidad del
sistema usando actores y casos de uso. Los casos de uso
son servicios o funciones provistas por el sistema para sus
usuarios.
Especificación de casa de uso
Documentación de los casos de uso
Existen dos formas principales de documentar un caso de uso:
 Un diagrama en UML
 Un documento detallado
Documentar casos de usos no es una tarea fácil que se pueda
dominar de un día para otro, requiere de tiempo, disciplina y
experiencia, sin embargo podemos definir una serie de pasos
identificables para escribir los casos de uso.
 Figura 9: Pasos para la documentación de los Casos de Uso
Formato de la documentación de caso de uso para los actores
que participen:

Figura 10: Documentación de los actores dentro de los Casos

de Uso
Documentación de un caso de uso:
 

Figura 10: Documentación de los Casos de Uso

Bibliografía

http://gestio.suport.org/index.php?option=com_content&view=article&id=105%3Aque-es-el-pla-
estrategic&catid=34%3Apmf-activitats&Itemid=44&lang=es

https://educacioningesoftware.wordpress.com/libre/

https://www.marcoteorico.com/curso/45/ingenieria-de-software/249/componentes-del-
modelado-de-negocios

https://prezi.com/wvbaa8cemrvw/introduccion-al-diagrama-de-flujo-de-funciones-cruzadas/

https://support.office.com/es-es/article/crear-un-diagrama-de-flujo-de-funciones-cruzadas-
4a403033-9787-454f-b87e-b88452c47a21

http://requerimientos.galeon.com/

Gutiérrez, J. 2008. Diagramas UML de casos de uso y de

requisitos. (En línea). ES. Consultado 2 de Jun. 2015. Formato
PDF. Kendall, K y Kendall, J. 2011. Análisis y diseño de sistemas.
8 ed. México. Pearson Education. p 600
Merseguer, J. 2010. Diagramas de Casos de Uso. (En línea).
Consultado, 2 de Jun. 2015. Formato PDF.