Estudio tecnico fep

INSTITUTO TECNOLÓGICO SUPERIOR DEL ORIENTE DEL ESTADO DE HIDALGO Formulación y evaluación de proyectos de inversión. Estudio Técnico “Diccionario online multidominio para invidentes” Profesor: Ing. Jaime Alberto Zaragoza Hernández Equipo: Juárez Díaz José RobertoLópez Jiménez Humberto Luna Jiménez Mariel Erandi Ortega Sánchez Wendy Waldo Olvera Brenda Yazmín Marzo 2011 CONTENIDO TOC quot;
1-3quot;
Justificación del tamaño óptimo de la planta. PAGEREF _Toc288471392 3Descripción del proceso productivo. PAGEREF _Toc288471393 4Descripción de normatividad de producción y de construcción. PAGEREF _Toc288471394 6Descripción de las especificaciones de cada etapa del proceso productivo. PAGEREF _Toc288471395 7Definición de pruebas de calidad. PAGEREF _Toc288471396 18Descripción de equipo, herramientas y herramentales de cada etapa del proceso y de inspección de calidad. PAGEREF _Toc288471397 19Criterios y cálculos de selección del equipo, herramientas y herramentales para cada etapa del proceso. PAGEREF _Toc288471398 21Dibujo de la distribución del equipo, maquinaria y disposición de materia prima en cada etapa del proceso. PAGEREF _Toc288471399 22Dibujo de la ubicación del áreas de la planta. PAGEREF _Toc288471401 23Cálculos de la justificación del tamaño de las áreas de la planta. PAGEREF _Toc288471402 24Organigrama de la empresa. PAGEREF _Toc288471403 25Normatividad legal para el establecimiento de la empresa. PAGEREF _Toc288471405 26 JUSTIFICACIÓN DEL TAMAÑO ÓPTIMO DE LA PLANTA. En esta fase del proyecto se intenta hallar una solución óptima o la más cercana, que permita satisfacer los requerimientos del mercado y la exigencia de los consumidores. Para determinar el tamaño de la planta se ha tomado en cuenta diferentes factores en función al mercado disponible o demanda, tecnología y equipos, disponibilidad de materia prima, inversión y financiamiento. DEMANDA El tamaño solo puede aceptarse en que la demanda sea claramente superior. De acuerdo con el estudio de mercado se obtuvo lo siguiente: Si bien la población total de invidentes en México esta divida en las siguientes categorías: adultos y ancianos, 17.2 % menores de 30 años; 33 % tiene entre 30 y 59 años de edad, mientras que 48.8% es mayor de 60 años. De esta población se determino que el 68% consumirá nuestro producto. Por lo consiguiente se describirá los demás factores con el fin de determinar el tamaño del proyecto y determinar si cubrirá el total de la demanda. Tecnología y equipos La tecnología y los equipos tienden a limitar el tamaño al mínimo de producción necesario para ser aplicables. Propiciará un menor costo de inversión por unidad de capacidad instalada y un mayor rendimiento por persona ocupada; por lo tanto contribuirá a disminuir el costo de producción, aumentar las utilidades y elevar la rentabilidad del proyecto. La tecnología de vanguardia que utilizáremos en el proceso de producción asegurando el correcto funcionamiento del sistema de información será la siguiente: Equipos que contengan herramientas informáticas en las que se diseñan, programan y desarrollan los sistemas de información. Los lenguajes de programación utilizables serán Java, C# y PHP. El sistema operativo será Windows Ultimate ya que ofrece un soporte de pantallas multitáctiles y la herramienta de reconocimiento de voz, además de que ocupará menos memoria y soportará diversas plataformas de procesadores. 3558540304165Para que todo el software necesario para el desarrollo del sistema, los equipos tendrán las siguientes características: -CPU INTEL Pentiun 4 2.8GHZ BOX 533MHZ 1MB PRESCOTT- CD 52X SAMSUNG- DRIVE 1,44 - HD 512 GB 7200 SAMSUNG - Memoria DDR 4GB 333MHZ Disponibilidad de materia prima 4101465578485Se cuenta con todo los recursos necesarios para llevar a cabo el desarrollo del proyecto, ya que se tiene todas las herramientas que permitirán la construcción del mismo, tales como: Equipos de cómputo conectados en red y acceso a internet. Impresoras Papelería 335851586995Equipo mobiliario (escritorios, sillas, gabinetes, etc). Infraestructura, etc. 2148840346075Al igual que se cuenta con el personal adecuado para la realización del producto, como son: 364426533655Analistas Programadores Diseñadores Líderes de proyectos Ingenieros de pruebas Personal de mantenimiento Inversión y financiamiento Todos los socios están dispuestos a invertir lo suficiente, para que se efectué la localización de la planta, donde se desarrollara el producto. DESCRIPCIÓN DEL PROCESO PRODUCTIVO. Como en cada proyecto que tenemos, el proceso para el desarrollo de nuestros sistemas es el siguiente: Los documentos que se deben obtener son: Actividad Documentos ProducidosAnálisis de Requisitos Documento de RequisitosDefinición de Requisitos Documento de RequisitosEspecificación del Sistema. Especificación Funcional, Plan de Pruebas de Aceptación.Diseño Arquitectural Especificación de la Arquitectura, y Plan de Pruebas del SistemaDiseño de InterfacesEspecificación de la Interfaces y Plan de pruebas de IntegraciónDiseño Detallado Especificación del diseño y Plan de prueba de Unidades.CodificaciónCódigo de ProgramaPrueba de Unidades Informe de prueba de unidadesPrueba de MódulosInforme de prueba de módulosPrueba de Integración Informe de prueba de integración y Manual de usuario final.Prueba del SistemaInforme de prueba del sistemaPrueba de Aceptación Sistema final y documentación El siguiente modelo muestra otra opción de desarrollo de nuestros sistemas. A comparación del anterior, este gestiona muy bien la naturaleza evolutiva del software y es iterativo, ya que de él salen versiones de SW cada vez más completas. Al igual que el modelo anterior, se adapta a cambios de requisitos. Inicialmente, el analista estudia la especificación del sistema y el plan de proyecto. Es importante comprender el contexto del sistema y revisar el ámbito de los programas que se usó para generar las estimaciones de la planificación. A continuación, debe establecerse la comunicación necesaria para el análisis, de forma que se asegure el reconocimiento del problema. El analista debe establecer contacto con el equipo técnico y de gestión del usuario/cliente y nuestra empresa. El gestor del programa puede servir como coordinador para facilitar el establecimiento de los caminos de comunicación. El objetivo del analista es reconocer los elementos básicos del programa tal como lo percibe el usuario/cliente. La evaluación del problema y la síntesis de la solución es la siguiente área principal de trabajo del análisis. El analista debe evaluar el flujo y estructura de la información, refinar en detalle todas las funciones del programa, establecer las características de la interfaz del sistema y descubrir las ligaduras del diseño, para que al momento de llevarlo a código, cumpla con las necesidades del cliente plasmadas en el diseño. Posteriormente, se harán pruebas a lo programado y si son aceptadas, se procede a la documentación, es decir, se elaboran los manuales técnico y de usuario. DESCRIPCIÓN DE NORMATIVIDAD DE PRODUCCIÓN Y DE CONSTRUCCIÓN. La normatividad en la producción y desarrollo de un sistema, tiene como objetivos: Establecer un documento normativo de carácter general y permanente que regule todo el proceso de desarrollo de los sistemas. • Asegurar eficiencia en los procedimientos de evaluación, de los proyectos de desarrollo presentados por las Áreas Administradoras de Tecnologías de Información. • Establecer mejores mecanismos de control, en la administración y actualización de los sistemas desarrollados. Normas generales de desarrollo de sistemas >>Producción<< Transportabilidad Un sistema debe poder ser “migrable” o “copiable” muy fácilmente. Permite reutilizar el trabajo en beneficio de la productividad y de los clientes, que se benefician de lo aprendido con otros clientes. Seguridad Las aplicaciones deben ser seguras y no deben permitir su ejecución por personas no autorizadas. Productividad y reusabilidad La productividad es clave para la viabilidad y el crecimiento de la empresa. Debemos escribir programas de la más alta calidad, en el menor tiempo posible y procurar que todo lo que se escriba sea fácilmente reusable. Confiabilidad Nuestros sistemas tienen que ser confiables. Si algo falla hay que hacerlo notar inmediatamente. >> Construcción << Aquí se describen en fases y segmentos: FASE 1- IDENTIFICACION DEL PROBLEMA Establecer áreas críticas. Revisar documentación. Elaborar un documento que deje ver claramente las metas que se alcanzaron. FASE 2- ANALISIS Y DISEÑO Definir grupo de trabajo que intervendrán en el desarrollo del sistema. Establecer Herramientas de equipos existentes. Encontrar las funciones y flujo de observación (datos que suministre el usuario). Definir documentos con los resultados de análisis y diseño. Entregar documentos con los resultados de análisis y diseño. FASE 3- DESARROLLO Definir el aspecto que se le dará a la aplicación (interfaz grafica de usuario). Diseñar la interfaz grafica del usuario teniendo en cuenta las solicitudes del cliente. Desarrollo el código de programación que satisfaga el objetivo principal del sistema. FASE 4-IMPLEMENTACION Poner en práctica el sistema Documentar cada uno de los procesos del programa. Capacitar al usuario. Evaluar y probar todos los procesos. FASE 5-MANTENIMIENTO Adaptar las nuevas etapas en el sistema y actualizar la información. Brindar atención del servicio posterior a la instalación. Actualizar las versiones. DESCRIPCIÓN DE LAS ESPECIFICACIONES DE CADA ETAPA DEL PROCESO PRODUCTIVO. Análisis de requisitos. Los requisitos se presentan en una lista ordenada, categorizada según su ámbito y la influencia y prioridad respecto al ámbito y entorno de aplicación del proyecto. Esta lista se ha elaborado siguiendo las recomendaciones del estándar IEEE 830-1998. Restricciones de diseño: requisitos que limitan el desarrollo al crear el producto. Se etiquetan como RD.x, siendo x el número del requisito. Requisitos funcionales: conjunto de requisitos que reflejan las funciones que debe prestar el sistema. Se clasifican en las siguientes subsecciones: Requisitos nominales: requisito para el funcionamiento del portal en situaciones normales. Se etiquetan como FN.x, siendo x el número de requisito.. Requisitos no nominales: requisitos para el funcionamiento del portal en situaciones especiales o condiciones de error. Se etiquetan como FF.x, siendo x el número de requisito. Requisitos de interfaz: conjunto de requisitos que definen las necesidades de la interacción del portal con otros sistemas y usuarios. Se etiquetan como IN.x, siendo x el número de requisito. Requisitos de calidad: exigencias en la calidad que se piden explícitamente para el producto. En esta categoría se engloban los requisitos de rendimiento, accesibilidad, facilidad de uso, etc. Se etiquetan como CA.x, siendo x el número de requisito. Requisitos de evolución: requisitos para el diseño del producto con el objetivo de facilitar la adaptación a exigencias o condiciones que puedan surgir en el futuro. Se etiquetan como EV.x, siendo x el número de requisito. Requisitos de proyecto: requisitos que afectan y condicionan el proceso de desarrollo el proyecto. Se etiquetan como PR.x, siendo x el número de requisito. Requisitos de soporte: requisitos que deben ser cumplidos por el cliente (a diferencia de los anteriores). Se etiquetan como SO.x, siendo x el número de requisito. Para cada requisito, se realiza una caracterización estructurada siguiendo este esquema: Descripción: descripción corta del requisito, que se concreta en los siguientes apartados: Importancia: pudiendo ser de una de estas tres clases: Esencial: el no cumplimiento del requisito provocaría el rechazo inmediato del producto por el cliente. Condicional: el requisito mejoraría el resultado final del desarrollo, pero su no cumplimiento no produciría su rechazo. Opcional: el requisito no tiene que se implementado, pero se puede tener en cuenta al realizar el diseño del producto. Validez: este apartado demuestra la validez del requisito. Tiene cuatro secciones, que estarán presentes sólo en el caso de ser relevantes para ese requisito concreto. Medible: describe cómo comprobar el grado de cumplimiento del requisito. Alcanzable: justifica el realismo del requisito y propone, de un modo general, un camino para lograr su consecución. Relevante: justifica la presencia del requisito en el documento, indicando cómo colabora a definir la entidad global del producto. Específico: extiende la descripción del requisito, con referencias a los casos de uso, si fuesen relevantes. Especificación del Sistema El objeto de la especificación es definir de manera clara y precisa todas las funcionalidades y restricciones del sistema que se desea implementar. El documento va dirigido al equipo de desarrollo, al grupo de calidad, a los colaboradores del grupo de “Sistemas Informáticos” y a los usuarios finales del sistema. Este documento será el canal de comunicación entre las partes implicadas, tomando parte en su confección miembros de cada parte. Esta especificación está sujeta a revisiones por el grupo de usuarios, que se recogerán por medio de sucesivas versiones del documento, hasta alcanzar su aprobación por parte del grupo de calidad y el grupo de usuarios. Una vez aprobado servirá de base al equipo de desarrollo para la construcción del sistema. Diseño arquitectural El propósito del diseño es de crear una arquitectura para la naciente implementación, el diseño arquitectural sólo puede comenzar una vez que el equipo tenga un entendimiento razonable de los requerimientos del sistema. El diseño, como el análisis, nunca termina realmente hasta que el sistema final es entregado. Durante esta fase, se alcanza un cierto grado de culminación al poner en su lugar la mayoría de las decisiones estratégicas de diseño y al establecer políticas para diversos problemas tácticos. El diseño se enfoca en la estructura, estática y dinámica, su propósito principal es de crear el 'esqueleto' concreto del sistema sobre del cual todo el resto de la implementación se basa.quot;
 Estas palabras definen claramente qué es el diseño, la creación de la estructura básica del sistema es la tarea clave, aunque también se buscan otras cosas, en particular patrones que simplifiquen el diseño y posibilidades de reúso entre otras. Durante la etapa de diseño vamos a refinar las partes fundamentales para la aplicación. Para lograrlo, es conveniente comenzar a buscar patrones de diseño, a continuación describimos esto de manera más detallada. Patrones de diseño. Un patrón es una quot;
solución simple y elegante a problemas específicos dentro del diseño de aplicaciones orientadas a objetos, los patrones capturan soluciones que han sido desarrolladas y han evolucionado a lo largo del tiempo, de ahí que normalmente no son el tipo de soluciones que se tienden a generar de manera inicial, reflejan el trabajo de los desarrolladores que han luchado por obtener una mayor posibilidad de reúso y flexibilidad en su software. Los patrones de diseño capturan estas soluciones de una manera fácil de aplicar.quot;
 Una vez que se ha terminado con el análisis, conviene detenerse a estudiar el resultado principal de esa etapa, es decir el diagrama de clases de análisis. Es importante buscar que partes pueden ser mejoradas mediante el uso de algún patrón de diseño. Para ello es útil consultar algun catálogo de patrones y mediante sus descripciones tratar de encontrar alguno que se ajuste o que provea alguna solución al problema que se tiene. Plan de Pruebas de Integración PROPÓSITO Garantizar el cumplimiento de los requerimientos planteados en el marco del proyecto en cuanto a la integración de aplicaciones. Asegurar que se tengan en cuenta todos los casos de pruebas posibles para validar la solución informática a un requerimiento o solicitud de cambio, garantizando que en el momento de entregar el producto a pruebas de usuario éste cuente con un nivel de calidad apropiado. Definir todas las actividades relacionadas con la ejecución de las pruebas de integración, las responsabilidades individuales para cada tarea, los recursos y los prerrequisitos que deben ser considerados en el esfuerzo de pruebas. Garantizar el funcionamiento adecuado de las reglas de negocio que involucran la integración de aplicaciones. Garantizar el buen funcionamiento de la infraestructura de integración utilizada. ALCANCE Aplica para el diseño y la elaboración de los planes de pruebas de integración que son ejecutadas por los desarrolladores antes de realizar la entrega de una versión estable del producto para que le sean aplicadas las pruebas de usuario. Estas pruebas son realizadas a nivel de capa de negocio en los productos y servicios comprendidos dentro del sistema de calidad. Su diseño y ejecución se apoyan en la herramienta Junit. DEFINICIONES APLICABLES. • Plan de pruebas. • Diseño del plan de pruebas. • Diseño de caso de prueba. • Criterios de aceptación. • Elaboración del plan de pruebas. PROCEDIMIENTOS ASOCIADOS. Procedimiento de ejecución de pruebas. DIAGRAMA DE ACTIVIDADES DEL PROCEDIMIENTO Diseño detallado Como sabemos el diseño es la actividad en la que se toman numerosas decisiones sobre las características del sistema que se va a construir, y además está dirigido por la información. En particular en la segunda parte del Diseño (Diseño Detallado) se toman decisiones de cómo se va a implementar concretamente el Sistema de acuerdo a la estrategia general para resolver el problema que se determina entre Usuario, Dirección y equipo de desarrollo. Durante el Diseño Detallado: Se especifica el Hardware Se especifica el software teniendo en cuenta los siguientes pasos: Diseño de los programas (Diseño arquitectónico). Diseño de las bases de datos: Del DER se pasa a las DB lógicas y de ellas a las BD físicas. Diseño del plan de pruebas que garantice la calidad del software. Conversión de los datos al nuevo modelo. Ventajas: Los módulos son más fáciles de leer y de revisar. La detección de los errores dentro de un módulo es más fácil de hacer. El mantenimiento de los módulos es más fácil. Las modificaciones, en general, implicarán a uno o a varios módulos, y no a todos y cada uno de ellos. Características de la programación modular: Los módulos deben tener un tamaño manejable (que contengan una sola función). Se debe prestar especial atención a las interfaces críticas (datos y variables de control que se pasen los módulos. Minimizar el número de módulos afectados por posibles cambios en el sistema.Mantener las relaciones jerárquicas. Codificación Para programación en lenguaje C#, si bien puede ser utilizado en muchos otros lenguajes y entornos para establecer las convenciones a utilizar. En principio, este documento se ha escrito para describir las convenciones en la codificación del proyecto anteriormente mencionado, y todo aquel código directamente relacionado. Este documento se basa en el documento de Mike Krueger titulado 'SharpDevelop C# Coding Style Guide', en su versión 0.3. Organización de los ficheros Archivos fuente. Cada clase debe estar en un solo archivo, y un archivo no puede contener más de una clase. Si bien, en un archivo, junto con su clase se pueden definir los elementos relacionados, p.e. las excepciones que puede lanzar. Árbol de directorios y espacio de nombres. El espacio de nombres de los objetos se verá reflejado en el árbol de directorios del código fuente. Sangrías Longitud de línea. No se mantendrá, siempre que sea posible, la longitud de la línea más allá de los 80 caracteres. Dividir líneas. Siempre que sea necesario dividir una línea en dos, se utilizarán las siguientes convenciones: Dada la disparidad que hay sobre la cantidad de espacios de indentación, se utilizarán tabuladores, los cuales pueden usarse con muchos editores para representarse con distintas cantidades de espacios y, sobretodo, se convierten en una pulsación por indentación. Declaraciones Número de declaraciones por línea. Por definición, nunca se utilizará una misma línea para más de una definición, la cual cosa facilita los comentarios relativos al elemento declarado. Inicialización. Siempre que sea posible las variables se inicializarán en la misma línea de declaración. Declaración de clases e interfaces. Para definir las clases e interfaces, se seguirán las siguientes reglas: ● No se usará ningún espacio entre el nombre de un método y el paréntesis de abertura de la lista de parámetros. ● La llave de abertura que contiene el código se escribe sola en la línea siguiente a la definición del prototipo. Igualmente, la llave de cierre correspondiente se escribe sola en la última línea. Sentencias Sentencias simples. Cada línea contendrá no más de una sentencia, aunque, según lo explicado en el apartado 3, una sentencia puede estar en más de una línea. Sentencias de retorno. La sentencia return no utiliza paréntesis. Sentencia de selección básica (if/if...else/if...elseif...else). Las llaves de inicio de un bloque de código se ponen al final de la sentencia if, else o elseif. Las llaves de cierre van en líneas independientes. Cuando una sentencia else o elseif vaya tras un bloque de código, la sentencia se colocará en la misma línea que la llave de cierre. Sentencias de bucle for o foreach. De forma similar a las sentencias de selección, la llave de abertura de bloque se colocará tras la sentencia de definición del for o foreach, y la de cierre en una línea independiente. Sentencias de bucle while o do while. De modo idéntico al for, pero en el caso del do while, el while se colocará en la misma línea que la última llave. Sentencias de selección múltiple (switch). Respecto a lo que concierne a las llaves, se colocarán como en el resto de casos. Respecto al código y la línea break, éstas irán con una indentación más que la línea case correspondiente, que irá con una indentación más que la línea de switch. Sentencias de captura y tratamiento de excepciones (try/catch/finally). El tratamiento de las llaves de bloque será como en el resto de sentencias. Espacios en blanco Líneas en blanco.Se pueden utilizar líneas en blanco para separar grupos de líneas que tengan cierta relación lógica. Dos líneas en blanco seguidas se usan para: ● Separar secciones de código en un fichero. ● Separar definiciones de clases, interfaces, etcétera, dentro de un fichero. Una línea en blanco separa... ● Métodos. ● Definiciones de variables locales dentro del método. ● Bloques de código que no guarden relación directa. Separaciones entre términos. En una lista de parámetros, se pondrán espacios tras las comas, pero nunca tras o antes de los paréntesis. En las asignaciones, se pondrán espacios antes y después del =. En las expresiones, se utilizarán espacios sólo cuando sean estrictamente necesarios y para separar las distintas expresiones. Separaciones en las declaraciones. Se procurará mantener una estructura tabulada para las líneas de declaraciones de variables, de manera que leer la información sea fácil. En el ejemplo siguiente se puede observar cómo mantener dicha estructura, pero hay que tener en cuenta que para el espaciado, hay que utilizar espacios, no tabuladores: Nomenclatura Es importante tener presente que no se utilizará la notación húngara para absolutamente nada, exceptuando la codificación de GUI, donde se puede utilizar, pero detallando los tipos en sufijos detallados (cancelButton, por ejemplo). Nomenclatura para las clases. El nombre de una clase debe componerse de sustantivos. Se utilizarà capitalización Pascal. No se utilizará ningún prefijo de clase. Nomenclatura para interfaces. Se nombrarán con sustantivos o adjetivos que describan el comportamiento. Capitalización Pascal. Se prefijan con una I, en mayúsculas, y la palabra que sigue también va en mayúsculas. Nomenclatura para enumeraciones. Se utilizará Pascal tanto para los nombres de los valores como para los nombres de tipo. No se utilizarán ni prefijos ni sufijos. Se utilizarán sustantivos en singular. Nomenclatura para constantes y para atributos de sólo lectura. Se utilizará Pascal con sustantivos o abreviaciones de sustantivos. Nomenclatura para parámetros y atributos normales. Se utilizarán nombres descriptivos, destacando el significado antes que la tipología del parámetro. En este caso utilizaremos capitalización Camel. Nomenclatura para variables. Se utilizará Camel. Cuando se utilicen contadores triviales, se utilizarán nombres como i, j, k, m, n, etc. Nomenclatura para métodos. Los métodos se nombrarán con verbos, en Pascal. Nomenclatura para propiedades. Se utilizarán sustantivos, en Pascal. Nomenclatura para eventos. Los eventos tendrán como sufijo EventHandler y se utilizarán dos parámetros, denominados sender y e.Se utilizará Pascal. Se utilizarán verbos en tiempos pasado y presente para dar una idea del significado del evento. Prácticas de programación Visibilidad. Preferentemente se codificarán los atributos de clase y de instancia como privadas, de modo que existirán métodos accesores. Comentarios. Se utilizará solamente el formato //, nunca se utilizará el /*...*/. Cuando haya que comentar un bloque de líneas, se utilizarán tantos // al principio de línea como convenga, como si se tratase de un # en un Shell script. Pruebas de software La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además, esta etapa implica: · Verificar la interacción de componentes. · Verificar la integración adecuada de los componentes. · Verificar que todos los requisitos se han implementado correctamente. · Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente. · Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo. La prueba es un proceso que se enfoca sobre la lógica interna del software y las funciones externas. La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta entonces. Una vez generado el código fuente, es necesario probar el software para descubrir (y corregir) la mayor cantidad de errores posible antes de entregarlo al cliente. Su objetivo es diseñar una serie de casos de prueba que tengan una alta probabilidad de encontrar errores _ Pruebas de unidad: La prueba de unidad se centra en el módulo. Usando la descripción del diseño detallado como guía, se prueban los caminos de control importantes con el fin de descubrir errores dentro del ámbito del módulo. La prueba de unidad hace uso intensivo de las técnicas de prueba de caja blanca. Prueba de integración. El objetivo es coger los módulos probados en la prueba de unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño. Hay dos formas de integración: · Integración no incremental: Se combinan todos los módulos por anticipado y se prueba todo el programa en conjunto. · Integración incremental: El programa se construye y se prueba en pequeños segmentos. En la prueba de integración el foco de atención es el diseño y la construcción de la arquitectura del software. _ Prueba de Arquitectura y Aplicaciones La arquitectura cliente/servidor representa un importante desafío para quienes prueban el software. La naturaleza distribuida de los entornos cliente/servidor, los aspectos de desempeño relacionados con el proceso de transacción, la posible presencia de varias plataformas de hardware diferentes, la complejidad de la comunicación en red, la necesidad de servir varios clientes desde una base de datos centralizada (o, en algunos casos, distribuida) y los requisitos de coordinación impuestos al servidor se combinan para que la prueba de las arquitecturas de software cliente/servidor resulte considerablemente más difícil que la prueba de aplicaciones independientes. Prueba del sistema: Pruebas de funcionalidad de la aplicación: la aplicación se prueba de manera independiente. Verifica que cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total. La prueba del sistema está constituida por una serie de pruebas diferentes cuyo propósito primordial es ejercitar profundamente el sistema basado en computadora. Algunas de estas pruebas son: Prueba de validación: Proporciona una seguridad final de que el software satisface todos los requerimientos funcionales y de rendimiento. Además, valida los requerimientos establecidos comparándolos con el sistema que ha sido construido. Durante la validación se usan exclusivamente técnicas de prueba de caja negra. Prueba de recuperación: Fuerza un fallo del software y verifica que la recuperación se lleva a cabo apropiadamente. Prueba de seguridad: Verificar los mecanismos de protección. Prueba de resistencia: Enfrenta a los programas a situaciones anormales. Prueba de rendimiento: Prueba el rendimiento del software en tiempo de ejecución. Prueba de instalación: Se centra en asegurar que el sistema software desarrollado se puede instalar en diferentes configuraciones hardware y software y bajo condiciones excepciones, por ejemplo con espacio de disco insuficiente o continuas interrupciones. Pruebas de regresión:Las pruebas de regresión son una estrategia de prueba en la cual las pruebas que se han ejecutado anteriormente se vuelven a realizar en la nueva versión modificada, para asegurar la calidad después de añadir la nueva funcionalidad. El propósito de estas pruebas es asegurar que: Los defectos identificados en la ejecución anterior de la prueba se ha corregido. Los cambios realizados no han introducido nuevos defectos o reintroducido defectos anteriores. Flujo del proceso de prueba Pruebas de Aceptación. El objetivo de las pruebas de aceptación es validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento. Las pruebas de aceptación son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecución y aprobación final corresponden al usuario. La validación del sistema se consigue mediante la realización de pruebas de caja negra que demuestran la conformidad con los requisitos y que se recogen en el plan de pruebas, el cual define las verificaciones a realizar y los casos de prueba asociados. Dicho plan está diseñado para asegurar que se satisfacen todos los requisitos funcionales especificados por el usuario teniendo en cuenta también los requisitos no funcionales relacionados con el rendimiento, seguridad de acceso al sistema, a los datos y procesos, así como a los distintos recursos del sistema. DEFINICIÓN DE PRUEBAS DE CALIDAD. Se le conoce como pruebas de calidad al el test de pruebas que nos permiten saber si un producto cuenta con las características que satisfacen una necesidad además de que está basado en ciertos estándares establecidos por órganos legales que regulan la creación de los mismos además por los estándares de la misma empresa. Pruebas de calidad. 1.- El sistema desarrollado cuenta con la capacidad de responder en cualquier plataforma de trabajo. 2.- El sistema es capaz de encontrar de manera rápida cualquier palabra incluida en el diccionario: esta prueba fue realizada comparando resultados con una búsqueda normal en un diccionario común y completada satisfactoriamente. * 3.- El sistema es a prueba de errores: Esta prueba se realizó con un conjunto de personas que utilizaron sin saber el software. 4.- El sistema no es muy robusto lo que favorece su velocidad de respuesta: prueba realizada por el equipo de trabajo. 5.- El sistema gestiona de forma rápida la información almacenada en el por lo que es muy fácil actualizarlo: prueba realizada por el equipo de trabajo. * Las pruebas de errores nos reflejan que el sistema puede trabajar sin problemas o no se cerrara si el usuario presiona teclas sin querer o realiza acciones no válidas. Una vez que nuestro sistema pasó satisfactoriamente cada una de las pruebas anteriores podemos decir que está apto para salir a la venta sin riesgo de réplicas de consumo, quedando claro que el sistema dependerá de la instalación correcta de los usuarios y de su buen y debido empleo. DESCRIPCIÓN DE EQUIPO, HERRAMIENTAS Y HERRAMENTALES DE CADA ETAPA DEL PROCESO Y DE INSPECCIÓN DE CALIDAD. Entrevistas, computadora, internet, hojas, impresora, lapicero, cuestionarios, observación. Personas involucradas: Cliente y líder del proyecto. Computadora, internet, hojas, impresora, prototipos, requisitos del sistema, reuniones de equipo, CD, USB. Personas involucradas: Cliente, analista, diseñador y líder del proyecto.Entrevistas, computadora, internet, hojas, impresora, libros, revistas, lapicero, cuestionarios, observación. Personas involucradas: Cliente, analista y líder del proyecto.Computadora, sistema desarrollado, manual de usuario, manual técnico. Personas involucradas: programador y líder del proyecto.Computadora, hojas, impresora, sistema desarrollado, CD, USB. Personas involucradas: Usuario final, ingeniero de pruebas y líder del proyecto.Computadora, internet, hojas, impresora, software de programación (JAVA, C#, PHP, etc.), diseño del sistema a programar, CD, USB. Personas involucradas: Programador, diseñador y líder del proyecto. CRITERIOS Y CÁLCULOS DE SELECCIÓN DEL EQUIPO, HERRAMIENTAS Y HERRAMENTALES PARA CADA ETAPA DEL PROCESO. Los criterios tomados en cuenta para la selección y adquisición de equipo y herramienta para el establecimiento de la empresa de desarrollo de software son: Proveedores. No se contemplan proveedores ya que la materia prima que se utiliza es de fácil acceso en los mercados nacionales. Precios. Se busca la mejor opción de acuerdo a calidad y un equilibrio con el precio. Capacidades. Para comenzar a trabajar, la empresa necesita de computadoras y especialmente discos duros de al menos 500GB para tener respaldados los proyectos que se van elaborando. Flexibilidad.Para este aspecto, se considera que las computadoras cuenten con un procesador de 4 núcleos, el cual permite la rapidez en la realización de operaciones. Mano de obra necesaria. La empresa necesita para comenzar labores, de al menos: 1 analista, 1 programador, 1 líder de proyectos, 1 diseñador, así como 1 recepcionista. Costo de mantenimiento. Consumo de energía eléctrica. Se considera tener iluminación con focos ahorradores, así como que el lugar en que se establezca la empresa, tenga suficiente iluminación para el ahorro del consumo eléctrico. También se tiene en consideración los equipos de cómputo sean de bajo consumo eléctrico. Infraestructura necesaria. Equipos auxiliares. DIBUJO DE LA DISTRIBUCIÓN DEL EQUIPO, MAQUINARIA Y DISPOSICIÓN DE MATERIA PRIMA EN CADA ETAPA DEL PROCESO. Estante de productos y prototiposLámparaAlimentador de corrienteEstaciones de trabajoBote de basuraNobrakeSwitch case DIBUJO DE LA UBICACIÓN DEL ÁREAS DE LA PLANTA. 18m28m78m22m75m 46m CÁLCULOS DE LA JUSTIFICACIÓN DEL TAMAÑO DE LAS ÁREAS DE LA PLANTA. Para obtener la proporción de la distribución ideal de las áreas de la empresa, a continuación se menciona la base del cálculo de tamaño. Recepción de material y embarque de producto terminado. Volumen de maniobra y frecuencia de recepción. Almacenes. En este aspecto hay 3 tipos de producto que podemos encontrar, como son: materia prima, producto en proceso y producto terminado. Estos pueden estar ubicados en un solo mueble con 3 divisiones. Materia prima está constituida por hojas de papel, lapiceros, cd´s, entre otros. El producto en proceso, pueden ser los manuales impresos inconclusos, documentos que sirven para el análisis de desarrollo de software, entre otros. Producto terminado, aquí podemos encontrar discos duros de respaldo de información, así como manuales y software terminado y empacado. Producción. En esta área encontramos los equipos de cómputo, que son la principal herramienta de desarrollo. El número aproximado inicial son de 4 a 5 equipos. Servicios auxiliares. Se contempla un espacio para tener 1 switch y modem que darán servicio de internet a los equipos de cómputo. Sanitarios. Como es un área en la que por el momento no hay más de 10 trabajadores, solo se tiene contemplado 1 sanitario compartido. Oficinas. Se tiene contemplado tener 1 área de juntas o análisis, en la que habrá una mesa con capacidad para 10 personas aproximadamente. Mantenimiento. ORGANIGRAMA DE LA EMPRESA. AnalistaDiseñadorProgramadorIng. de pruebasGerente generalSecretariaLíder de proyectosRecursos HumanosAdministraciónGerente de proyectos NORMATIVIDAD LEGAL PARA EL ESTABLECIMIENTO DE LA EMPRESA. Normatividad legal para el establecimiento de la empresa. 1.- Cualquier sociedad mercantil debe ser constituida ante un Notario Público o Fedatario Público, para esto se crea un instrumento notarial denominado Acta Constitutiva en donde se le da nombre y razón social a la entidad, se definen los estatutos sociales, se establecen quienes serán los socios y participaciones de los mismos, se define el órgano de administración así como los apoderados y los poderes específicos que se les conferirán, duración de la sociedad, así como otros elementos importantes que se acuerdan. El notario solicitará diversos requisitos para la protocolización de la citada acta constitutiva, entre los que se encuentran: Los accionistas deben presentar identificación oficial y tener Registro Federal de Contribuyentes. En el caso de accionistas extranjeros se deben cumplir requisitos especiales. En función del tipo de sociedad mercantil que se desee constituir deberán observarse los límites mínimos tanto en el número de socios o accionistas así como del capital social inicial a ser aportado. Es recomendable seleccionar un notario que cuente con autorización de expedir quot;
Cédula de Identificación Fiscal Provisionalquot;
, ya que esto implicará una menor inversión de tiempo en trámites subsecuentes y a los que nos referiremos más adelante. En este caso se debe proporcionar al notario la dirección fiscal (lugar donde se encuentre la administración principal del negocio) así como el formato de Hacienda R1 debidamente requisitado y firmado. Cualquier sociedad mercantil que se constituya debe inscribirse en el Registro Público de Comercio del lugar donde tenga su domicilio social, normalmente esta actividad es realizada por el notario. En caso de que la sociedad tenga accionistas extranjeros, la sociedad deberá ser inscrita en el Registro Nacional de Inversiones Extranjeras y cumplir con la presentación del Cuestionario Económico Anual así como los reportes trimestrales (en caso de estar obligada). Entre las obligaciones mencionadas en la Ley de Sociedades Mercantiles se encuentra que la empresa debe contar con libros donde se asienten las resoluciones de la asamblea de accionistas y se cubran otros aspectos, existen particularidades en cuanto a la obligación específica en función al tipo de sociedad mercantil constituida. 2.- Inmediatamente después de la constitución se debe tramitar la inscripción en el Registro Federal de Contribuyentes (RFC) a fin de obtener la cédula de identificación fiscal con el RFC correspondiente. Si el notario seleccionado contaba con autorización de emitir cédula provisional, prácticamente desde el día de la firma del acta constitutiva la empresa podrá contar con un RFC y con esto estar en posibilidad de abrir cuentas bancarias, imprimir facturas e iniciar operaciones. En párrafos anteriores mencionamos que la cédula de identificación fiscal emitida por el notario es provisional, con una vigencia de 3 meses, por lo que la empresa debe estar atenta a obtener la cédula definitiva. En caso de que el notario no contase con el sistema de emisión de cédula de identificación fiscal provisional, la empresa debe gestionar su inscripción al RFC directamente en la Oficina de Hacienda que corresponda a su domicilio (fiscal). El trámite se realiza presentando el Formato R1 debidamente llenado y firmado adjuntando documentación específica que solicita la autoridad.(Para mayor referencia ver www.sat.gob.mx). En todos los casos y a través del formato R1 se informará a las autoridades de las obligaciones fiscales a las que la empresa estará sujeta, por lo que es importante desde un inicio efectuar un diagnóstico adecuado de todas y cada una de las obligaciones fiscales a las que la empresa este obligada y deba cumplir. 3.- Otro requisito administrativo que deben cumplir las empresas establecidas en México (el cual varía en función al Estado de la República en el cual tengan su domicilio fiscal), es el de gestionar y obtener diversas licencias ante autoridades de distintos niveles y también de acuerdo a la actividad de la empresa (licencias municipales, salubridad, de uso de suelo, funcionamiento, ecológicas, etc.). Por otra parte la empresa debe registrarse ante alguna Cámara de Comercio, o por ejemplo en el Sistema de Información Empresarial mexicano (para mayor referencia ver www.siem.gob.mx). 4.- De acuerdo con la Ley de Propiedad Industrial, el Instituto Mexicano de Propiedad Industrial (IMPI) es la dependencia gubernamental que tiene como principal atribución el proteger y fomentar la propiedad industrial; Es decir, aquellos derechos exclusivos de explotación que otorga el Estado durante un tiempo determinado a aquellas creaciones de aplicación industrial, tales como un producto técnicamente nuevo, una mejora a una maquina o aparato, un diseño original para hacer más útil o atractivo un producto, un proceso de fabricación novedoso, una marca o aviso comercial, una denominación identificadora de un establecimiento, o una aclaración sobre el origen que distingue o hace especial un producto. Por lo tanto es importante estudiar y determinar dentro de la empresa que activos tangibles o intangibles son susceptibles de ser protegidos ante el IMPI y realizar los trámites y procedimientos que correspondan. 5.-Si entre los planes de negocio de la empresa se encuentra el de importar y / o exportar bienes, la empresa debe ser inscrita ante el Padrón de Importadores y obtener el registro general, en función al tipo de producto será o no necesario obtener padrones sectoriales así como Normas Oficiales Mexicanas. Es importante estar adecuadamente asesorado por un experto en comercio exterior, ya que el trámite es impersonal y puede durar un tiempo importante, afectando la operación de la entidad.En el caso de importaciones / exportaciones de servicios deberá cumplirse con regulaciones específicas aplicables. 6.- Es importante definir el esquema de empleo a través de un contrato de trabajo, así como los puestos y funciones a través de un organigrama. De igual forma debe definirse si dicho contrato debe ser individual o colectivo, en función al número de empleados así como a las actividades que la empresa desarrollará. Conforme al marco regulatorio actual la empresa debe cumplir con leyes tanto Laborales como de Seguridad Social (tanto en el ámbito local como federal). Para esto último la empresa debe gestionar su incorporación ante el Instituto Mexicano del Seguro Social (IMSS) y obtener su número de identificación patronal. Simultáneamente la empresa debe registrar por lo menos a un trabajador. Existen requisitos específicos para la incorporación, para mayor referencia ver www.imss.gob.mx.A partir de la incorporación la empresa deberá pagar las contribuciones sociales en forma mensual y en forma bimestral las contribuciones de INFONAVIT y Sistema de Ahorro para el Retiro. La empresa debe registrarse ante el padrón del 2% sobre Nóminas en la Tesorería que corresponda a su entidad local. Algunos estados de nuestro país no contemplan dentro de su legislación local el pago de este impuesto así como en algunos otros estados el porcentaje varía y no en todos los casos es el 2%. Así mismo en algunos estados existen impuestos locales específicos aplicables al pago de remuneraciones a empleados así como a otros conceptos. Es recomendable acudir a la oficina de tesorería que corresponda al domicilio de la empresa y determinar en forma apropiada todas las cargas impositivas de la empresa. 7.- En paralelo a los pasos anteriores la empresa deberá imprimir facturas (y notas de crédito) con un impresor autorizado y apertura de cuentas bancarias. Si efectúa operaciones de comercio internacional o por planeación estratégica es recomendable contar con una cuenta de cheques denominada en dólares americanos. Es necesario que la cuenta bancaria cuente con servicio de acceso a Internet, ya que los impuestos se pagan a través del portal bancario. Para el adecuado uso y destino de los fondos de la empresa deben elaborarse presupuestos que indiquen el origen de los recursos así como la aplicación de los mismos. Como siguiente paso es imprescindible comparar los presupuestos contra las cifras reales de los estados financieros, analizando las diferencias que se obtengan en su caso implementando medidas preventivas o correctivas que procedan. Finalmente es importante desde la fundación de la empresa establecer un manual de políticas y procedimientos así como controles internos claros y suficientes, estos deben ser correctamente implementados, dándole el seguimiento adecuado y que permitan una eficiente ejecución de las actividades del personal de la empresa, como por ejemplo, el contar con información financiera que se objetiva, veraz, consistente y comparable para la toma de decisiones.

Estudio tecnico fep

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (6)

Similar a Estudio tecnico fep

Similar a Estudio tecnico fep (20)

Último

Último (20)

Estudio tecnico fep