Business Case
Transcripción
Business Case
<Nombre empresa> <Nombre del proyecto> Business Case Versión <1.0> [Nota: Esta plantilla se proporciona para que se use como parte del Proceso Unificado de Rational. El texto que aparece entre corchetes y que aparece en letra cursiva azul (estilo=InfoBlue) se incluye para guiar al autor y debería borrarse antes de publicar el documento. Un párrafo que se haya introducido siguiendo este estilo se cambiará a normal (estilo=Body Text)] [Para adaptar los campos automáticos (los que aparecen con un fondo gris cuando se seleccionan) de Microsoft Word, selecciona Archivo>Propiedades (en inglés: File>Properties) y sustituye los campos título, asunto y organización con la información apropiada para este documento. Después de cerrar el diálogo, los campos automáticos se pueden actualizar en todo el documento seleccionando Edición>Seleccionar todo (o Ctrl-E) y pulsando F9, o simplemente haciendo clic en un campo y pulsando F9. Esto debe hacerse de manera separada para los encabezamientos y pies de página. Alt-F9 cambiará entre mostrar los nombres de los campos y el contenido de los mismos. Si quieres más información sobre el trabajo sobre campos, consulta la ayuda de Word]. <Nombre del proyecto> Business Case <identificador del documento> Versión: <1.0> Fecha: <dd/mmm/yy> Historia de revisiones Fecha <dd/mmm/yy> Confidencial Versión <x.x> Descripción <detalles> <Nombre empresa>, 2017 Autor <nombre> Page 2 of 5 <Nombre del proyecto> Business Case <identificador del documento> Versión: <1.0> Fecha: <dd/mmm/yy> Tabla de contenidos 1. Introducción 4 1.1 1.2 1.3 1.4 1.5 4 4 4 4 4 Propósito Ámbito Definiciones, acrónimos, y abreviaturas Referencias Visión general 2. Descripción del producto 4 3. Contexto de negocio 4 4. Objetivos del producto 4 5. Previsión financiera 4 6. Restricciones 5 Confidencial <Nombre empresa>, 2017 Page 3 of 5 <Nombre del proyecto> Business Case <identificador del documento> Versión: <1.0> Fecha: <dd/mmm/yy> Business Case 1. Introducción [La introducción de la especificación del sistema ofrece una visión general de todo este documento. En ella se incluye el propósito, el ámbito, definiciones, los acrónimos, abreviaturas, referencias y una visión general de esta especificación del sistema]. 1.1 Propósito [Especificar el propósito de esta especificación del sistema]. 1.2 Ámbito [Una breve descripción de esta especificación del sistema; con qué proyectos están asociadas y cualquier otra cosa que se vea afectada o influenciada por este documento]. 1.3 Definiciones, acrónimos, y abreviaturas [Este subapartado ofrece las definiciones de todos los términos, acrónimos y abreviaturas que se necesiten para interpretar adecuadamente la especificación del sistema. Esta información se puede proporcionar haciendo una referencia al glosario del proyecto]. 1.4 Referencias [En este subapartado se debería proporcionar una lista completa de todos los documentos a los que se hace referencia en el documento de especificación del sistema. Identifica cada documento por su título y número de informe si fuese aplicable, fecha y entidad editora. Especifique las fuentes mediante las cuales se pueden obtener las referencias. Esta información se puede proporcionar mediante una referencia a un apéndice u otro documento]. 1.5 Visión general [Este subapartado describe lo que contiene el resto del documento de especificación del sistema y explica cómo está organizado el documento]. 2. Descripción del producto [Para darle al lector un contexto, describe brevemente el producto que se está desarrollando. Incluye el nombre del sistema y quizás el acrónimo, si es que se usa uno. Explica qué problema resuelve y por qué vale la pena el desarrollo del mismo. Haz referencias al documento de Visión]. 3. Contexto de negocio [Define el contexto de negocio para el producto. ¿En qué dominio va a funcionar (por ejemplo, telecomunicaciones o banca)? Y en qué mercado –¿Quiénes son los usuarios? Indica si es producto se desarrolla para cumplir con un contrato o se trata de un producto comercial. También debería mencionarse si es la continuación de un proyecto existente]. 4. Objetivos del producto [Indica los objetivos del desarrollo del producto –las razones que hacen que valga la pena su desarrollo. En este apartado se debería incluir un plan tentativo y algún tipo de evaluación de los riesgos de dicho plan. Unos objetivos definidos y expresados de manera clara ofrecen una buena base para establecer hitos y gestionar riesgos; es decir, para mantener el proyecto encarrilado y asegurar su éxito]. 5. Previsión financiera [Para un producto de software comercial, este documento debería incluir un conjunto de suposiciones Confidencial <Nombre empresa>, 2017 Page 4 of 5 <Nombre del proyecto> Business Case <identificador del documento> Versión: <1.0> Fecha: <dd/mmm/yy> acerca del proyecto y el orden de magnitud del retorno de la inversión (Return Of Investment –ROI) si es que se cumplen las previsiones. Por ejemplo, el ROI tendrá una magnitud 5 si finaliza en un año, 2 si lo hace en dos y un número negativo si se hace más tarde. Estas suposiciones se comprueban de nuevo al final de la fase de elaboración, cuando el ámbito y el plan son conocidos con más precisión. El retorno se basa en la estimación de costo y la estimación de los beneficios potenciales. La estimación de recursos rodea todo el proyecto, hasta el envío al cliente. Esta estimación se actualiza en cada fase y en cada iteración, y se hace más precisa a medida que se completan iteraciones. Se debe incluir una explicación de la base de las estimaciones]. 6. Restricciones [Expresa las restricciones sobre las que se ha comprometido el proyecto. Estas restricciones tienen impacto en los riesgos y el coste. Podrían ser cosas como interfaces externas a las que el sistema se tenga que adherir, certificaciones o aproximaciones técnicas empleadas por razones estratégicas, tales como usar una cierta tecnología de bases de datos o un mecanismo de distribución]. Confidencial <Nombre empresa>, 2017 Page 5 of 5