MANUAL DE ESTNDARES Desarrollo de Proyecto de Seguimiento y Control de Aprendices CEAI

Estndar de Procedimientos

Integrantes: Laura Norea Akerman Stephanie Fernandez Catherin Sanchez C. Jhon Jairo Chagendo P.

Tecnologa en Anlisis y Desarrollo de Sistemas de Informacin Sena - Valle Abril 10 de 2010

OBJETIVO Este documento establece los lineamientos para el desarrollo de software desde la etapa de Anlisis hasta la etapa de Implantacin, sirve de gua para la elaboracin de documentacin que se refiera a polticas, normas y estndares. ALCANCE Los lineamientos emitidos a travs de este documento, sern de aplicacin obligatoria para toda la documentacin generada referente a polticas, normas y estndares informticos, del proyecto de Seguimiento y Control de aprendices. ABREVIATURAS BD ERS. SECAP. Base de Datos Especificacin de Requerimientos de Software Seguimiento y Control de Aprendices

RESPONSABILIDAD Es responsabilidad de todos los integrantes del grupo de Desarrollo del Proyecto de Seguimiento y Control de Aprendices que realice alguna poltica, norma, procedimiento o estndar, cumplir el estndar de emisin de documentacin establecido en este Manual. DESCRIPCION DEL ESTNDAR Toda la documentacin que soporte las actividades en el desarrollo del proyecto, debe de iniciar con una portada que contiene cuatro lneas. La primera se refiere al ttulo del manual, En la siguiente lnea se anota el ttulo de la poltica, norma, procedimiento o estndar especfico. Ej. MANUAL DE ESTNDARES (lnea 1) ESTANDAR DE PROCEDIMIENTOS (lnea 2). En la tercera lnea anotar el nombre completo de los integrantes del proyecto, y en la cuarta lnea anotar la fecha.

FORMATO PARA LA DOCUMENTACION: El formato de estas lneas ser arial 22, negrita. La lnea 1 debe de llevar adems, fondo azul. A partir de la segunda pgina, el documento deber contener un encabezado con el siguiente contenido:

Primera fila El logo del grupo desarrollador del proyecto. Al costado derecho del logo, anotar un ttulo que se escoge de los cuatro siguientes: Manual de Polticas, Manual de Estndares, Manual de Procedimientos o Manual de Normas, segn corresponda. Segunda fila Se debe de anotar el cdigo del documento: ES (si es Manual de Estndares) un guin y un consecutivo. Ej. ES-01. Seccin, se refiere al nmero de seccin dentro del documento, cuando el mismo se compone de varias secciones, en caso de no tener secciones, se debe anotar 01. Versin, se refiere a la versin del documento, cuando este ha tenido variaciones o modificaciones, lo que permite llevar un control sobre los ltimos documentos generados. Fecha de vigencia, se refiere a la fecha en la cual qued aprobado el documento. Luego el documento debe llevar el siguiente contenido que se especifica seguidamente, donde el usuario, puede describir cada uno de los puntos que a continuacin se solicitan.

1. Anteproyecto. El anteproyecto es un documento previamente definido bajo los estndares del Sena, con el logotipo y los colores institucionales, en donde se hace una descripcin de lo que se va a desarrollar, cumpliendo con unos parmetros ah especificados. 2. Documento acuerdo requerimientos: Es un documento que contiene la informacin necesaria para iniciar el levantamiento de requerimientos, en la parte superior, contiene el logotipo del grupo de proyecto, se titula Documento Acuerdo de Requerimientos con el Cliente, en este, se comentan todas las peticiones que el cliente desea con el software, se deben documentar al pie de la letra, textualmente como el cliente lo expresa, el analista, debe con esa informacin establecer un requerimiento realizable, y explicito sin dejar dudas, y de esta manera se deben especificar en el documento de acuerdo, al final, bajo el titulo de requerimientos Finales, se deben numerar cada requerimiento, profundizando en cada uno de ellos con el fin de no dejar de incluir todo lo que se espera que realice el software, ya que despus de firmar este documento se debe hacer cumplir dicho acuerdo. 3. Recoleccin de la informacin Se usaron tres tcnicas de recoleccin de informacin, encuesta, entrevista y observacin, para la encuesta se dise un modelo bsico de entrevista de seis preguntas con cuatro opciones de respuesta, (ver anexo), los resultados de la encuesta de disearon en la barra de funcionalidad de insertar grafico. A entrevista, se realizo basada en el modelo de entrevista personal, en donde se interacta con las personas directamente involucradas, se recolectan datos importantes y que puedan enfocar el desarrollo del software hacia una solucin viable del problema inicial. La entrevista se grabo con una grabadora periodstica, y se realizo un acta en la que se incluyeron los datos ms relevantes. En la Observacin, se deben recolectar datos que ayuden a comprender los requerimientos del cliente de una forma especfica. Se toman muestras de los datos, y se realizan actas de levantamiento de informacin. 4. Levantamiento de Requerimientos: Se usa un documento que se denomina Modelo de especificacin de Requerimientos de Software, hay diferentes tipos, unos ms elaborados que otros, en el caso especifico del proyecto de seguimiento y control de aprendices se uso el Modelo estndar, que contiene las siguientes especificaciones: En la primera pagina, el logo debe ir a la derecha, como ttulo deber ir especificacin de Requerimientos de Software, como subtitulo el nombre del

proyecto, y en la parte inferior deber ir la fecha en que se est elaborando, la ciudad. Introduccin: En esta seccin se proporcionara una introduccin a todo el documento de Especificacin de Requisitos Software (ERS). Consta de varias subsecciones: Propsito, mbito del sistema, definiciones, referencias y visin general del Documento. En la siguiente pgina se incluir el contenido, con la numeracin de pginas. Y a continuacin se empieza a desarrollar el documento, con las siguientes subsecciones. Propsito En esta subseccion se definir el propsito del documento ERS y se especificara a quien va dirigido el documento. mbito del Sistema En esta subseccion Se podr dar un nombre al futuro sistema (p.ej. Mi Sistema) Se explicara lo que el sistema har y lo que no har. Se describirn los beneficios, objetivos y metas que se espera alcanzar con el futuro sistema Se referenciaran todos aquellos documentos de nivel superior (De ingeniera de software que incluyen Hardware y Software, deber mantenerse la consistencia con el documento de especificacin de requisitos Globales del sistema, si existe) Definiciones, Acrnimos y Abreviaturas En esta subseccion se definirn todos los trminos, acrnimos y abreviaturas utilizadas en la ERS. Referencias En esta subseccion se mostrara una lista completa de todos los documentos Referenciados en la ERS. Visin General del Documento Esta subseccion describe brevemente los contenidos y la organizacin del resto de la ERS. Descripcin General En esta seccin se describen todos aquellos factores que afectan al producto y a sus requisitos. En esta seccin no se describen los requisitos, sino su contexto. Esto permitir definir con detalle los requisitos en secciones posteriores, haciendo que sean ms fciles de entender. Normalmente, esta seccin consta de las siguientes subsecciones: Perspectiva

del producto, funciones del producto, caractersticas de los usuarios, Restricciones, factores que se asumen y futuros requisitos. o Perspectiva del Producto Esta subseccion debe relacionar el futuro sistema (producto software) con Otros productos. Si el producto es totalmente independiente de otros productos, Tambin debe especificarse aqu. Si la ERS define un producto que es parte de un sistema mayor, esta subseccion relaciona a los requisitos del sistema mayor con la funcionalidad del producto descrito en la ERS, y se identificaran las interfaces entre el producto mayor y el producto aqu descrito. Se recomienda utilizar diagramas de bloques. o Funciones del Producto En esta subseccion de la ERS se mostrara un resumen, a grandes rasgos, de las funciones del futuro sistema. Por ejemplo, en una ERS para un programa de contabilidad, esta subseccion mostrara que el sistema soportara el mantenimiento de cuentas, mostrara el estado de las cuentas y facilitara la facturacin, sin mencionar el enorme detalle que cada una de estas funciones requiere. Las funciones debern mostrarse de forma organizada, y pueden utilizarse grficos, siempre y cuando dichos grficos reflejen las relaciones entre funciones y no el diseo del sistema. o Caractersticas de los Usuarios Esta subseccion describir las caractersticas generales de los usuarios del Producto, incluyendo nivel educacional, experiencia y experiencia tcnica. o Restricciones Esta subseccion describir aquellas limitaciones que se imponen sobre los Desarrolladores del producto. Polticas de la empresa Limitaciones del hardware Interfaces con otras aplicaciones Operaciones paralelas Funciones de auditoria Funciones de control Lenguaje(s) de programacin Protocolos de comunicacin Criticidad de la aplicacin Consideraciones acerca de la seguridad.

o Suposiciones y Dependencias Esta subseccion de la ERS describir aquellos factores que, si cambian, pueden afectar a los requisitos. Por ejemplo, los requisitos pueden presuponer Una cierta organizacin de ciertas unidades de la empresa, o pueden presuponer que el sistema correr sobre cierto sistema operativo. Si cambian

Dichos detalles en la organizacin de la empresa, o si cambian ciertos detalles tcnicos, como el sistema operativo, puede ser necesario revisar y cambiar los requisitos. o Requisitos Futuros Esta subseccion esbozara futuras mejoras al sistema, que podran analizarse e implementarse en un futuro. Requisitos Especficos Esta seccin contiene los requisitos a un nivel de detalle suficiente como para permitir a los diseadores disear un sistema que satisfaga estos requisitos, y que permita al equipo de pruebas planificar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos. Todo requisito aqu especificado describir comportamientos externos del sistema, perceptibles por parte de los usuarios, operadores y otros sistemas. Esta es la seccin mas larga e importante de la ERS. Debern aplicarse los siguientes principios estndar: El documento deber ser perfectamente legible por personas de muy distintas formaciones e intereses. Debern referenciarse aquellos documentos relevantes que poseen alguna influencia sobre los requisitos. Todo requisito deber ser unvocamente identificable mediante algn cdigo o sistema de numeracin adecuado. Lo ideal, aunque, en la practica, no siempre realizable, es que los requisitos posean las siguientes caractersticas: 1. Correccin: La ERS es correcta si y solo si todo requisito que figura aqu (y que ser implementado en el sistema) refleja alguna necesidad real. La correccin de la ERS implica que el sistema implementado ser el sistema deseado. 2. No ambiguos: Cada requisito tiene una sola interpretacin. Para eliminar la ambigedad inherente a los requisitos expresados en lenguaje natural, se debern utilizar grficos o notaciones formales. En el caso de utilizar trminos que, habitualmente, poseen mas de una interpretacin, se definirn con precisin en el glosario. 3. Completos: Todos los requisitos relevantes han sido incluidos en la ERS. Conviene incluir todas las posibles respuestas del sistema a los datos de entrada, tanto valido como no valido. 4. Consistentes: Los requisitos no pueden ser contradictorios. Un conjunto de requisitos contradictorio no es implementable.

5. Clasificados Normalmente, no todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por importancia (esenciales, Condicionales u opcionales) o por estabilidad (cambios que se espera que afecten al requisito). Esto sirve, ante todo, para no emplear excesivos recursos en implementar requisitos no esenciales. 6. Verificables: La ERS es verificable si y solo si todos sus requisitos son Verificables. Un requisito es verificable (testeable) si existe un proceso finito y no costoso para demostrar que el sistema cumple con el requisito. Un requisito ambiguo no es, en general, verificable. Expresiones como \a veces", \bien", \adecuado", etc. introducen ambigedad en los requisitos. Requisitos como \en caso de accidente la nube toxica no se extender mas all de 25 Km" no es verificable por el alto costo que conlleva. 7. Modificables: La ERS es modificable si y solo si se encuentra estructurada de forma que los cambios a los requisitos pueden realizarse de forma fcil, completa y consistente. La utilizacin de herramientas automticas de gestin de requisitos. 8. Trazables: La ERS es trazable si se conoce el origen de cada requisito y se facilita la referencia de cada requisito a los componentes del diseo y de la implementacin. La \trazabilidad hacia atrs" indica el origen (documento, persona, etc.) de cada requisito. La trazabilidad hacia adelante" de un requisito R indica que componentes del sistema son los que realizan el requisito R. 9. Interfaces Externas: Se describirn los requisitos que afecten a la interfaz de usuario, interfaz con otros sistemas (hardware y software) e interfaces de comunicaciones. Casos de uso: En esta seccin se describen las caractersticas del sistema, se describir el comportamiento del software o de los sistemas, deber contener una descripcin textual de todas las maneras que los actores previstos podran trabajar con el software o el sistema. Se representara de la siguiente forma:

o Funciones Esta subseccion (quiz la ms larga subseccion del documento) deber especificar todas aquellas acciones (funciones) que deber llevar a cabo el software. Normalmente, son aquellas acciones expresables como \el sistema deber". Si se considera necesario, podrn utilizarse notaciones graficas y tablas, pero siempre supeditadas al lenguaje natural, y no al revs. En el estndar, de IEEE 830 de 1983 establece que las funciones debern expresarse como una jerarqua funcional (en paralelo con los DFDs propuestos por el anlisis estructurado). Pero el Estndar de IEEE 830, en sus ltimas versiones, ya permite organizar esta subseccion de mltiples formas, y sugiere, entre otras, las siguientes: Por tipos de usuario: Distintos usuarios poseen distintos requisitos. Para cada clase de usuario que exista en la organizacin, se especificaran Los requisitos funcionales que le afecten o tengan mayor relacion con sus Tareas. Por objetos: Los objetos son entidades del mundo real que sern reflejadas En el sistema. Para cada objeto, se detallaran sus atributos y sus funciones. Los objetos pueden agruparse en clases. Esta organizacin de la ERS no quiere decir que el diseo del sistema siga el paradigma de Orientacin a Objetos. Por objetivos: Un objetivo es un servicio que se desea que ofrezca el sistema y que requiere una determinada entrada para obtener su resultado. Para cada objetivo o subobjetivo que se persiga con el sistema, se detallaran las funciones que permitan llevarlo a cabo. Por estmulos: Se especificaran los posibles estmulos que recibe el sistema y las funciones relacionadas con dicho estimulo. Por jerarqua funcional: Si ninguna de las anteriores alternativas resulta de ayuda, la funcionalidad del sistema se especificara como una Jerarqua de funciones que comparten entradas, salidas o datos internos. Se detallaran las funciones (entrada, proceso, salida) y las subfunciones del sistema. Esto no implica que el diseo del sistema deba realizarse segn el paradigma de Diseo Estructurado. Para organizar esta subseccion de la ERS se elegir alguna de las anteriores alternativas, o incluso alguna otra que se considere mas conveniente. Deber, eso si, justificarse el porque de tal eleccin. Requisitos de Rendimiento Se detallaran los requisitos relacionados con la carga que se espera tenga Que soportar el sistema. Por ejemplo, el nmero de terminales, el nmero Esperado de usuarios simultneamente conectados, numero de transacciones por segundo que deber soportar el sistema, etc.

 Restricciones de Diseo Todo aquello que restrinja las decisiones relativas al diseo de la aplicacin, Restricciones impuestas por otros estndares, limitaciones del hardware, etc. Atributos del Sistema Se detallaran los atributos de calidad (las \ilities") del sistema: Fiabilidad, Mantenibilidad, portabilidad, y, muy importante, la seguridad. Deber especificarse que tipos de usuario estn autorizados, o no, a realizar ciertas Tareas, y como se implementaran los mecanismos de seguridad (por ejemplo, Por medio de un 'login' y una 'password') Otros Requisitos Cualquier otro requisito que no encaje en ninguna de las secciones anteriores. Apndices Pueden contener todo tipo de informacin relevante para la ERS pero que, Propiamente, no forme parte de la ERS. Por ejemplo: 1. Formatos de entrada/salida de datos, por pantalla o en listados. 2. Resultados de anlisis de costes. 3. Restricciones acerca del lenguaje de programacin 5. Modelo entidad relacin Se pretende 'visualizar' los objetos que pertenecen a la Base de Datos como entidades. Para su diseo se deben tener en cuenta los siguientes pasos: Se parte de una descripcin textual del problema o sistema de informacin a automatizar (los requisitos). Se hace una lista de los sustantivos y verbos que aparecen. Los sustantivos son posibles entidades o atributos. Los verbos son posibles relaciones. Analizando las frases se determina la cardinalidad de las relaciones y otros detalles. Se elabora el diagrama (o diagramas) entidad-relacin. Se completa el modelo con listas de atributos y una descripcin de otras restricciones que no se pueden reflejar en el diagrama. La herramienta de diseo grafico utilizada para el desarrollo de esta actividad es E-draw 3.1, e utilizan las siguientes figuras para representar los elementos que la componen. Se representan las relaciones

Entidad Atributo

Conexin entre entidades 1: 1 1: N N: 1

Cardinalidad

6. Modelo relacional En este modelo se incluyen todas las entidades con sus atributos, resultantes del proceso de normalizacin del modelo entidad relacin, en el diseo, se deben manejar los siguientes formatos de figuras: Nombre de la entidad Atributos

7. Scripts Para la documentacin de los scripts de las bases de datos, se realizaron en Php myadmin. 8. Diagramacin Diagrama de Secuencia Muestra la interaccin de un conjunto de objetos en una aplicacin a travs del tiempo y se modela para cada mtodo de la clase contiene detalles de implementacin del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos. Los mensajes se dibujan cronolgicamente desde la parte superior del diagrama a la parte inferior; la distribucin horizontal de los objetos es arbitraria. Durante el anlisis inicial, el modelador tpicamente coloca el nombre 'business' de un mensaje en la lnea del mensaje

Modelo de negocio Arquitectura del proceso

Diseo Navegabilidad Codificar