CAPITULO IV DISEÑO DE UN ARQUETIPO ESTRATÉGICO ESTANDAR PARA EL DESARROLLO DE SOFTWARE EN LA MEDIANA EMPRESA DEL SECTOR COMERCIO EN EL AREA METROPOLITANA DE SAN SALVADOR. 1. GENERALIDADES DE LA PROPUESTA El uso de las computadoras se hace cada vez más indispensable para ofrecer un mejor servicio, ya que los procedimientos automatizados hacen a la Mediana Empresa más competitiva en el mercado globalizado de hoy. Por tal razón generar sus propios sistemas informáticos, se hace de vital importancia; es por ello que contar con un Arquetipo Estratégico Estándar para la elaboración de Software, será de gran beneficio para ella: 1. Ya que el Gerente de proyectos Informáticos podrá tomarlo de base para la toma de decisiones en cuanto a la necesidad de desarrollar software o no. Además de servir de guía para conocer el requerimiento a utilizar. 2. Reducción de costos para la empresa ya que los desarrolladores utilizarían una planificación lógica, siguiendo los pasos de una manera ordenada con el objetivo de llegar a obtener un software con calidad y con los mínimos errores posible, que cumpla con los requerimientos de la empresa en el tiempo estipulado y así también que los tiempos de respuesta de los procesos sean los adecuados para que los clientes queden satisfechos con el servicio. 3. Contará con los estándares para el desarrollo de software necesarios para la satisfacción de las necesidades de la mediana empresa, contando con los requisitos legales de hoy en día. 4. Ser competitivo en el mercado ya que todos los productos finales se tendrán en el tiempo requerido.
2. OBJETIVOS DE LA PROPUESTA 2.1 Objetivo General Servir como una herramienta para el desarrollo de los requerimientos informáticos de la Mediana Empresa del sector comercio. 2.2 Objetivos Específicos Brindar un apoyo en la toma de decisiones Gerenciales en los mandos medios para la elaboración de software, específicamente a los Gerentes de Proyectos Informáticos. Estandarizar la forma de desarrollar software en la Mediana Empresa. Servir de soporte para los desarrolladores de software. Aplicar las herramientas y técnicas más adecuadas para el desarrollo de software, que más se apeguen a las necesidades de la Mediana Empresa. 3. IMPORTANCIA DE LA PROPUESTA Disponer de un Arquetipo Estratégico Estándar para el Desarrollo de Software será de beneficios para: a) Los Desarrolladores: 1. Fácil aplicación: con la aplicación del Arquetipo el desarrollador podrá analizar y diseñar los requerimientos informáticos de una manera eficiente. 2. Accesibilidad: El desarrollador podrá contar con una herramienta de fácil acceso en el desarrollo de sus requerimientos b) Las Empresas Se podrán mejorar los costos, ya que los desarrolladores efectuaran una planificación lógica y de una manera ordenada, con el objetivo de llegar a tener un
software con calidad, que satisfaga los requerimientos de la empresa en el tiempo estipulado y así los tiempos de respuesta de los procesos serán los adecuados para que los clientes queden satisfechos con el servicio y que este sea sin errores c) La optimización de recurso humano Al contar con una planificación lógica y detallada de las actividades se tiende a optimizar el recurso, es decir menos tiempo invertido en el desarrollo de software. d) Una mejor toma de decisión por parte de las jerarquías de la empresa Al llevar a cabo paso a paso el arquetipo se podrán tomar decisiones estratégicas para llegar al cumplimiento de los objetivos de la empresa de una manera eficiente 4. JUSTIFICACIÓN DEL PROBLEMA Hoy en día la Mediana Empresa del sector comercio en el municipio de San Salvador se ve en dificultades de cumplir con sus clientes o sus procesos debido a: 1. Uso de software desarrollados sin la aplicación de un Arquetipo Estratégico Estándar para el Desarrollo de Software. 2. Aplicaciones desarrolladas de forma compleja, es decir poco amigables a los usuarios y de difícil mantenimiento, debido a la poca aplicación de técnicas para su desarrollo. 3. Alto grado de dependencia que las empresas tienen de las personas que desarrollan sus aplicativos. 4. El tiempo de respuesta para el desarrollo de requerimientos se dilate más del esperado, debido a la no aplicación de técnicas y herramientas.
5. Incremento de costos, en el aspecto técnico no existe una planificación previa y un análisis exhaustivo de la problemática, es decir que los desarrolladores pasan demasiado tiempo en un aplicativo descuidando otros requerimientos. Por lo tanto un mal sistema genera errores, lo que produce un descontento general, también repercute en todos lo demás procesos de la empresa es decir los tiempos de respuestas son mayores a los acostumbrados de manera manual. En síntesis al implementar un Arquetipo Estratégico Estándar se reducen costos en el factor tiempo, en el factor dinero, así también se obtienen grandes beneficios para la empresa como es cumplir con los clientes externos y que estos queden satisfechos con el servicio proporcionado, los empleados se ven incentivados al ver que su producción con calidad ha incrementado, lo cual lo deja bien como trabajador en la empresa, los desarrolladores ya no tienen la incertidumbre de que algo malo y no funcional va a tener el software porque se ha efectuado el análisis necesario y por lo tanto su única preocupación será el brindar mantenimiento rutinario y cotidiano. El Arquetipo Estratégico Estándar para el Desarrollo de Software, será de apoyo a los gerentes para la toma de decisiones oportunas y adecuadas para la elaboración de software buscando la maximización de utilidades y la optimización de los costos, así mismo se facilitará la auditoria informática ya que la Mediana Empresa contará con la documentación y los estándares establecidos para el desarrollo de proceso informáticos.
5. DESARROLLO DE LA PROPUESTA ANALISIS SITUACIONAL EVALUACION EJECUCION DEL ARQUETIPO IMPLANTACION DEL ARQUETIPO ENTREVISTAS METODOLOGIAS ETAPA ADMINISTRATIVA IMPLANTACION MÉTRICAS UTILIZADAS METRICAS ETAPA TECNICA CRONOGRAMA DE IMPLANTACION HERRAMIENTAS Y TECNICAS UTILIZADAS ESTRUCTURAS ADMINISTRATIVAS ETAPA OPERATIVA PRESUPUESTO DE IMPLANTACION
5.1 Etapa I Análisis Situacional 5.1.1 Metodología utilizada actualmente Para determinar la situación actual dentro del ámbito informático se han utilizado diferentes metodologías para la recopilación de información. A. ENTREVISTAS CON EL PERSONAL RELACIONADO EN EL ÁMBITO INFORMÁTICO. Para este análisis se efectuaron diferentes entrevistas con personal relacionado con el ámbito informático dentro de los cuales tenemos: Gerentes Informáticos, Analistas Informáticos y Programadores. 1. Gerentes de proyectos Informáticos Cabe aclarar que en la actualidad el Gerente Informático tiene como función principal: a. Dirigir. Asignar a cada analista-programador los requerimientos que han sido solicitados de acuerdo a la capacidad de cada individuo. b. Controlar. Que los requerimientos se estén desarrollando acorde con el tiempo que el programador o desarrollador manifestó tardarse. 2. Programadores (Analista Programador) Actualmente el Programador o Analista-Programador, tienen como función principal y única desarrollar el sistema de acuerdo a los requerimientos que el gerente o encargado de un área específica ha solicitado; cabe mencionar que el programador no pone en práctica la investigación, las entrevistas y la interacción con los futuros usuarios para lograr el software esperado, es decir no utiliza el análisis para comenzar a desarrollar
3. Digitadores. La función principal es introducir datos al sistema desarrollado para comprobar si las salidas y el funcionamiento en general es el adecuado y el solicitado. A. MÉTRICAS UTILIZADAS Actualmente la gran mayoría de la mediana empresa no utiliza ninguna técnica para medir la productividad de los desarrolladores ya que la única manera que utilizan para determinar si un desarrollador es productivo o no, es por módulos desarrollados sin tomar en cuenta la relación entre la productividad de líneas de código, puntos de función, con respecto al tiempo que se ha tardado o se tardará; por lo general es el analista programador quien determina el tiempo de duración del proyecto, por lo que el encargado del proyecto no tiene una medida real de comparación para determinar la eficacia el trabajo desarrollado y la veracidad de la estimación de tiempos que propone el analista. Quedando por fuera técnicas como: el Modelo Cocomo, las Líneas de Código, Líneas de Función y Punto de Equilibrio. C. HERRAMIENTAS Y TÉCNICAS UTILIZADAS Existen diversas herramientas y técnicas para ser utilizadas, sin embargo dentro de la mediana empresa no son utilizadas como estándares para el desarrollo de software. 1. Diagrama Entidad Relación (ER Conceptual) Este diagrama permite que el desarrollador de software especifique los objetos de datos que entran y salen de un sistema, los atributos que definen las propiedades de estos objetos, y las relaciones entre los objetos. El diagrama Entidad Relación se construye de una forma interactiva con el usuario y esta apegado a modelos de la realidad.
2. Modelo Físico El modelo físico es una representación tangible de la realidad, y muchos se diseñan o realizan en computadora, están ligado a una plataforma o motor de base de datos específica y parte del modelo conceptual, los atributos se convierten en campos y las entidades en tablas, además de incluir otros objetos que pertenecen a la base de datos y que pueden incluirse en el modelo físico de Entidad Relación. 3. Diagrama de flujo de datos Es una representación gráfica de la realidad y son de gran utilidad para el desarrollo de sistemas, es con esto que se muestra el flujo de la información y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida. Se puede usar el diagrama de flujo de datos para representar un sistema o software a cualquier nivel de abstracción de hecho los DFD pueden ser divididos en niveles que representen un mayor flujo de información y mayor detalle funcional. Por consiguiente el DFD proporciona un mecanismo para el modelado funcional así como el modelado del flujo de información. Un DFD de nivel 0 también es denominado Modelo Fundamental del Sistema o Modelo de Contexto y representa al elemento de software completo como un solo diagrama, con datos de entrada y de salida representado por flecha de entrada y de salida respectivamente.
5.2 Etapa II Evaluación de Metodologías, Métricas, Estructuras Administrativas. 5.2.1 Evaluación de Metodología 5.2.1.1 Método de Prototipado El método de prototipado puede ser o tomar una de las siguientes formas: a) Un escenario, como una simulación del uso del sistema. b) Una demostración es decir porciones de código que realizan algunas funciones. c) Una versión 0, una aplicación liberada que puede usarse bajo condiciones preliminares añadiendo, cambiando o quitando funciones existentes y creándole su documentación. El método de prototipado es usado cuando los requerimientos no son claros o no se identifican, en forma detallada los requerimientos de entrada y salida y funciones. 5.2.1.2 Modelo Espiral. Es un modelo del ciclo de meta-vida. Así cuando se completa un esfuerzo de desarrollo, otro comienza. Por lo que en cada desarrollo ejecutado, se puede seguir los siguientes pasos: a) Determinar qué se quiere lograr. (Planeación) a) Determinar las rutas alternativas que se pueden tomar para lograr las metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor. (Análisis de riesgos) b) Seguir la alternativa seleccionada en el literal anterior. (Evaluación de alternativa) c) Establecer que se ha terminado. (Retroalimentación)
5.2.1.3 Modelo Incremental Con este modelo los riesgos se reducen, ya que se construye solo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construcción en el cual se incrementan subconjuntos de requerimientos del sistema. Este modelo consta de lo siguiente: 1. El cliente usa el producto central y en base a la utilización y/o evaluación se desarrolla un plan para el incremento siguiente. 2. Este proceso se repite hasta que se elabora el producto completo. 3. Es interactivo, al igual que el de prototipos y otros enfoques evolutivos, pero a diferencia de ellos, el modelo incremental entrega un producto operacional en cada incremento. 4. Es útil cuando la dotación de personal no está disponible para una implementación completa. 5.2.2 Evaluación de Métricas Existe diversidad de métricas que pueden ser utilizadas para ser aplicadas a los desarrolladores de la mediana empresa del sector comercio y entre las cuales tenemos: 5.2.2.1 Modelo Cocomo. Esta es una métrica de gran ayuda a los Gerentes Informáticos ya que COCOMO es una jerarquía de modelos de estimación de costes de software que incluye submodelos básico, intermedio y detallado. Para utilizar en la Mediana Empresa el ideal es el modelo básico (Anexo 1)
1. Modelo Básico Este modelo trata de estimar, de una manera rápida, la mayoría de proyectos pequeños y medianos. Se consideran tres modos de desarrollo en este modelo: orgánico, semiencajado y empotrado. a. Modo orgánico. El tamaño del software varía de unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles de líneas (medio). En este modo el coste se incrementa a medida que el tamaño lo hace, y el tiempo de desarrollo se alarga. Se utilizan dos ecuaciones para determinar el esfuerzo de personal y el tiempo de desarrollo. El coste es 1.05 K m. = 2.4 S k Donde K m se expresa en personas-mes y S k es el tamaño expresado en miles de líneas de código fuente. El tiempo de desarrollo se da por 0.38 t d = 2.5 K m donde K m se obtiene de la ecuación anterior y t d es el tiempo de desarrollo en meses. b. Modo Empotrado. En este modo, el proyecto tiene unas fuertes restricciones, que pueden estar relacionadas con el procesador y el interfase hardware. El problema a resolver es único y es difícil basarse en la experiencia. Las estimaciones de tiempo y coste se basan en las mismas ecuaciones que en el modo orgánico, pero con diferentes constantes. Así, el coste se da por 1.20 K m = 3.6 S k
y el tiempo de desarrollo por 0.32 t d = 2.5 K m c. Modo Semiencajado. Es un modo intermedio entre los dos anteriores. Dependiendo del problema, el grupo puede incluir una mezcla de personas experimentadas y no experimentadas. Las ecuaciones son 1.12 K m = 3.0 S k y el tiempo de desarrollo por t d = 2.5 K m 0.35. 5.2.2.2 Líneas de Código (LDC) Son medidas básicas donde se calculan métricas de productividad, las cuales se utilizan de dos maneras: a. Como una variable de estimación para dimensionar cada elemento del software. b. Como métrica de línea base recopiladas de proyectos anteriores y utilizadas con variables de estimación para desarrollar proyecciones de coste y de esfuerzo. El dominio del proyecto debe calcular las medias de LDC/pm (Persona Mes) es decir, los proyectos se deben agrupar por tamaño de equipo, área de aplicación, complejidad y otros parámetros relevantes. Cuando se trata de un proyecto nuevo,
primero se debe asignar a un dominio, y a continuación utilizar la media de el dominio adecuado para la productividad al generar la estimación. Esta métrica es útil para proyectos de software que se realizan con un tipo de programación lineal o estructurada, es decir de forma continua sin hacer uso de orientación a objetos o a lenguajes de desarrollo visuales de 4 generación. 5.2.2.3 Puntos de Función (PF) La determinación de métricas por puntos de función es similar a las LDC con la diferencia que se intenta descomponer el software en funciones que se pueden estimar individualmente. Para cada función entonces se estima las LDC y PF, en este caso la PF seria la variable de estimación, es decir la que nos permitirá predecir el tamaño, coste o complejidad. De manera alternativa, el administrador del proyecto puede seleccionar otro componente diferente a los PF para dimensionar clases u objetos, cambios o procesos de gestión (variables de estimación) en los que puede tener impacto. Esta métrica puede ser utilizada para estimar productos desarrollados en lenguajes visuales de 4 generación y lenguajes orientados a objetos. 5.2.2.4 Métricas orientadas a clases (Orientación a Objetos) La orientación a objetos es una técnica de desarrollo que se basa en los conceptos de ocultamiento, herencia, abstracción, encapsulamiento y polimorfismo, que permiten la reutilización de componentes, a continuación se definen estos conceptos y se describen las métricas para medir la producción de acuerdo a clases.
Clase: Es la unidad fundamental de todo sistema orientado a objetos. Herencia: Es un mecanismo que hace posible que las responsabilidades de un objeto se propaguen a otro objeto y se produce a lo largo de todos los niveles de la jerarquía de clases. Encapsulamiento: Es el empaquetamiento de una colección de elementos. Abstracción: Es un concepto relativo ya que a medida asciende a niveles más elevados de abstracción se ignoran más y más detalles, se proporciona una visión más general de un concepto u objeto. Por lo que a medida que pasamos a niveles más reducidos de abstracción se presentan más detalles, es decir se proporciona una visión más específica de un concepto u objeto. Ocultamiento: Suprime los detalles operativos de un componente de un programa. Polimorfismo: Es el cambio de comportamiento de un objeto a través de diferentes interfaces. 5.2.2.4.1 Métodos ponderados por clase (MPC) La sumatoria de métodos y su complejidad para implementar y comprobar una clase. Además cuanto mayor sea el número de métodos, más complejo será el árbol de herencias. A medida que el número de métodos crece para una clase dada, es más probable que se vuelva cada vez más específico de la aplicación. 5.2.2.4.2 Árbol de profundidad de herencia (APH) Este tipo de métrica se define también como la longitud máxima desde el nodo hasta la raíz del árbol.
A medida que crece el APH, es más probable que las clases de niveles inferiores hereden muchos métodos. Una jerarquía de clase profunda lleva a una mayor complejidad de diseño. 5.2.2.4.3 Tamaño de la clase (TC) El tamaño general de una clase se puede determinar empleando las medidas siguientes: a. El número total de operaciones que están encapsuladas dentro de la clase b. El número de atributos que están encapsulados en la clase 5.2.3 Evaluación de Estructuras Administrativas Para evaluar una Estructura Administrativa dentro de la mediana empresa es necesario considerar el recurso financiero para la contratación de recurso humano especializado, por lo cual se propone la siguiente estructura. 5.2.3.1 Recurso Humano a) Gerentes de proyectos Informáticos El papel que desempeña el Gerente de Proyectos informáticos es muy importante, vital y constituye una estructura muy útil para llevar a cabo el desarrollo de proyectos informáticos y cumplir con los requerimientos solicitados a esta área. Por lo tanto las principales funciones de un Gerente de Proyectos informáticos: 1. Planificar, en el sentido de efectuar las acciones necesarias para cumplir con los requerimientos solicitados en un tiempo óptimo, tomando como base la misión de la organización y los objetivos de esta.
2. Organizar, ya que tiene que establecer una estructura de los papeles o rol que cada individuo debe desempeñar dentro de la organización, tomando en cuenta las metas que se requieren alcanzar, entre los papeles o rol están: analista programador, el digitador o usuario, el administrador de red, el administrador de base de datos. En base a los requerimientos solicitados. 3. Integración, En este punto el gerente de proyectos informáticos tiene como propósito principal el mantener ocupados todos los puestos contenidos dentro de su área o departamento así mismo integrar a los usuarios en el sentido de efectuar las pruebas necesarias cuando se ha desarrollado un requerimiento para trabajar por un mismo fin. 4. Dirección, dentro de esta función el gerente de proyectos informáticos tiene como finalidad influir en las personas en el sentido tal que se desarrollen y ejecuten los requerimientos tomando en cuenta el tiempo ya establecido para cada uno y así también que las personas encargadas de desarrollar lo efectúen de la manera óptima. 5. Controlar, este punto es muy importante ya que una vez asignadas cada una de las tareas a desempeñar por los programadores, analistas y demás personal; el gerente de proyectos informáticos debe medir y corregir el desempeño de cada uno de los individuos con el objetivo de cumplir con todos los requerimientos solicitados en un tiempo óptimo. b) Analistas programadores. El papel que desempeña el analista de sistemas es muy importante, así también multifacético; debido a que como analista tiene la función de: 1. Auxiliar. A los usuarios con el objetivo de ayudar a determinar las salidas que precisan del sistema.
2. Elaborar. Los planes necesarios para desarrollar los sistemas capaces de producir las salidas solicitadas por los usuarios. 3. Cerciorarse. Junto con lo programadores efectuar las modificaciones o desarrollar los nuevos sistemas. 4. Filtrar. El conjunto de requerimientos que han sido solicitados. 5. Desarrollar. El sistema de acuerdo a los requerimientos que el gerente o encargado de un área específica ha solicitado. c) Usuario (Digitadores) La función principal es introducir datos al sistema desarrollado para comprobar si las salidas y el funcionamiento en general es el adecuado y el solicitado. 5.2.3.2 Tecnologías de Información La tecnología de la información ha ejercido un profundo impacto en la sociedad, al grado que a esta época se le conoce como la era de la información. La información debe poseer ciertas características como son: a) Exacta. La cual debe ser puntual y carecer de errores. b) Completa. Ya que contiene todos los datos importantes. c) Económico. Evalúa el valor de la información contra el costo de producirla. d) Flexible. La información sirve para diferentes propósitos. e) Confiable. La confiabilidad de la información dependerá de la fuente de información y del método de recolección de datos.
f) Pertinente. La información debe proporcionársele a quien le pertenece. g) Simple. No debe ser compleja ni saturada; sino comprensible. h) Oportuna. Es la que se recibe justo cuando se necesita i) Verificable. Significa la posibilidad de probar que es correcta. j) Accesible. Debe ser de fácil acceso para los usuarios autorizados. k) Segura. La información debe estar protegida contra el acceso a ella de usuarios no autorizados El valor de la información está directamente relacionado con la utilidad que represente para los responsables de decisiones en el cumplimiento de las metas de la organización Esta época donde la tecnología de información ha avanzado tanto, gracias a ello es posible tener las telecomunicaciones; las cuales son la transmisión electrónica de señales de comunicación que permite a las organizaciones conectarse entres si, sistemas de computación para integrar redes. Las redes sirven para enlazar las computadoras y equipo de computación de un edificio, un país o el mundo entero, con la finalidad de establecer comunicaciones electrónicas. 5.2.3.3 Reglas del Negocio Reglas del negocio son todos aquellos puntos en los cuales el Gerente o socios de la empresa establecen y plasman las normas de acción a ejecutarse dentro de la empresa. Las normas de las reglas del negocio que el desarrollador debe tomar en cuenta al momento de elaborar el software son:
a) El giro de la empresa En este caso el giro de la empresa es de tipo comercial, es decir una empresa dedicada a la compra-venta de productos; por lo cual debe tener en cuenta el marco legal por el que esta normado el sector comercio. b) Estructura Jerárquica de la empresa. Toda empresa debe de contar con una estructura jerárquica establecida la cual debe ser del conocimiento de todo el personal y en este caso especifico del área de informática, ya que los desarrolladores deben tener plenamente identificado quienes y cuales son las personas responsables de los sistemas a desarrollar debido a sí es necesario contar con el permiso de otras áreas o departamentos para la manipulación de datos o la presentación de informes. Así también para controlar los tipos de permisos de usuario que tendrán dentro del sistema según el área o departamento que lo utilice. c) Estructura Organizacional Toda empresa debe contar con una estructura organizativa de roles plenamente definidos, la cual debe estar plasmada en un organigrama oficial de la empresa y cada puesto debe estar ocupado por miembros de la organización, donde el área o unidad informática debe estar posicionada de la siguiente forma: GERENCIA GENERAL INFORMATICA DEPARTAMENTO 1 DEPARTAMENTO 2 DEPARTAMENTO 3
5.2.3.4 Apoyo Logístico El apoyo logístico de una empresa es todo aquel soporte que se le da a todos los departamentos o áreas dentro de la empresa para poder ejecutar todas sus funciones o procesos establecidos de la mejor forma posible. El área o unidad informática necesita del siguiente apoyo: a) Apoyo administrativo. El área de informática necesita de todos los insumos necesarios para el buen desarrollo de su función dentro de la empresa, como lo es: papelería, disquetes, cartuchos de tintas, cintas magnéticas, CDS, y demás suministros necesario para el desarrollo de software. b) Apoyo al personal informático Dentro de este apoyo se espera contar con software ( paquetes para el desarrollo) y hardware específicos, con capacitaciones si fuera necesario para el desarrollo de software solicitado. c) Apoyo a las pruebas del sistema Es de vital importancia que el área de informática cuente con el poyo de todas las áreas de la empresa al momento de realizar las pruebas de los módulos desarrollados, ya que de esta forma se podrán determinar y corregir los errores de una forma rápida sin obstaculizar la producción de los usuarios.
5.2.3.5 Distribución de tiempos y actividades a) Diagrama de Gantt Es una herramienta que sirve para programar las actividades a desarrollarse dentro de un proyecto conforme a un orden y una secuencia de tiempo, siendo de gran ayuda en el área de informática para una buena planificación de las actividades y procesos a desarrollar b) Definición de Actividades Las actividades dentro del diagrama Gantt se plasmarán de una forma secuencial y lógica acordes con el desarrollo del software; estas actividades pueden ser programadas para cada analista o en general para todo el proyecto. Cabe mencionar que dichas actividades serán desglosadas ya sea por módulos, por funciones, procedimientos y/o validaciones c) Definición de Duración de Actividades Dentro del diagrama de Gantt la duración de las actividades deben estar definidas por horas laborales incluidas en los días laborales del mes calendario en el que se desarrollará el proyecto. d) Definición de Responsabilidades. Dentro del diagrama de Gantt se deben dejar definidas y plasmadas las responsabilidades de cada analista programador según las actividades que cada uno va a desarrollar
5.3 Etapa III Ejecución del Arquetipo. 5.3.1 Introducción El Arquetipo estratégico estándar esta diseñado para facilitar la toma de decisiones de los Gerentes de proyectos Informáticos y para que los analistas-programadores efectúen un seguimiento lógico en el desarrollo de software. De esta manera se pretende contribuir a la Mediana Empresa en el diseño y desarrollo de software proporcionando una herramienta estándar, estratégica ya que puede acoplarse a cualquier mediana empresa del sector comercio. A través del arquetipo se podrá establecer una planificación lógica previa a la elaboración de software, se encontrará una guía fácil y práctica, que una persona con conocimientos básicos en el desarrollo de software podrá implementar. El Arquetipo Estratégico Estándar cuenta con tres áreas importantes que se deben considerar al momento de desarrollar software, las cuales son: Área Administrativa, para los gerentes o encargados de proyectos informáticos Área Técnica, para encargados de proyectos informáticos programadores o analistas- programador Área Operativa, para programadores o analistas- programador.
ARQUETIPO ESTRATEGICO ESTANDAR PARA LA ELABORACIÒN DE SOFTWARE EN LA MEDIANA EMPRESA DEL SECTOR COMERCIO EN EL AREA METROPOLITANA DEL MUNICIPIO DE SAN SALVADOR AREA: ADMINISTRATIVA OBJETIVO: Orientar al Gerente Administrativo y a Gerentes de Proyectos Informáticos en la puesta en marcha de un nuevo proyecto informático Los pasos que un Gerente debe realizar para determinar la necesidad o no de un software son: 1. Análisis del Problema El análisis de la problemática en una empresa consta de los siguiente puntos: 1.1 Determinar las necesidades con prioridad dentro de la empresa Dentro de la determinación de necesidades prioritarias el Gerente de Proyectos o Gerente General tendrá que dividir entre aquellas necesidades meramente administrativas y las necesidades de requerimientos informáticos. Para identificar y definir entre las necesidades administrativas y las necesidades informáticas, tendrá que agruparlas de la siguiente forma: a) Las necesidades Administrativas. Son aquellas que se solucionaran con:
La modificación de algún proceso o procedimiento, en caso de ser una empresa nueva se recomienda establecer los manuales de procedimientos administrativos. La modificación o puesta en marcha de nuevos proyectos La eficacia y eficiencia en la atención al cliente La estimación correcta de los costos administrativos La compra de material y equipo necesario para agilizar los procesos de la empresa b) Las necesidades Informáticas. Desarrollando un modulo para agilizar los procesos Brindando mantenimiento oportuno a los módulos ya desarrollados Integrando los sistemas de acuerdo a las necesidades o cambios en los procesos administrativos Brindando los requerimientos y perfiles técnicos para la adquisición de equipo informático necesario para el buen desempeño de la empresa 1.2 Determinar los posibles problemas dentro de la empresa. Para determinar los posibles problemas de la empresa, el Gerente tendrá que evaluar las posibles causas del problema. Para evaluar las posibles causas de un problema, se debe indagar las causas que originan dicho problema; esto se debe realizar a través de ciertas actividades que permitan visualizar lo que se busca como: a) Realizar monitoreos del desempeño de los empleados, midiendo su productividad, evaluando su trato con los clientes, investigando sus necesidades e indagando sus inquietudes y sus desconformidades.
b) Medir el nivel de satisfacción de los clientes, realizándoles pequeñas encuestas esporádicas, escuchar sus quejas y sugerencias. c) Observar la efectividad de los diferentes procesos dentro de la empresa; midiendo el tiempo de respuesta de cada proceso y el nivel de satisfacción proporcionado a la empresa. d) Evaluar el buen funcionamiento del material y equipo utilizado para el desarrollo del trabajo dentro de la empresa. e) Determinar la rentabilidad obtenida hasta hoy y compararla con la de años anteriores. 2. Establecer el problema real Luego de haber estudiado y analizado las posibles causas del problema; se debe establecer cual es el tipo de problema con el cuál se enfrenta la empresa, elaborando un enunciado real del problema, el cual deber ser claro y sencillo de fácil compresión para toda la empresa. Dentro de este punto se debe tener claro cual es la causa del problema y cuales serian las posibles soluciones dentro de las cuales es importante que conozcamos exactamente si el problema concierne a la parte informática; mientras qué esto no se comprenda, no tiene caso pasar a la siguiente etapa en la utilización del arquetipo. 3. Toma de Decisiones Analizado el problema, posiblemente se tengan varias formas de resolverlo; lo importante es determinar cuál es la mejor alternativa para su solución, la cuál debe producir los resultados esperados en el menor tiempo y al menor costo. Para la toma de decisiones hay que determinar cuál es la mejor alternativa de solución; tomando en cuenta lo siguiente:
3.1. Factibilidad Técnica El análisis de factibilidad técnica evalúa si el equipo y software existente tiene la capacidad técnica requerida por cada alternativa del diseño que se esté considerando. Los estudios de factibilidad técnica también consideran las interfases entre los sistemas actuales y nuevos (o el diseño de un nuevo del software, si puede desarrollarse). Además este estudio de factibilidad también debe considerar si la empresa tiene el personal con la experiencia técnica requerida para diseñar, implementar, operar y mantener el sistema propuesto. Si el personal no tiene esta experiencia, puede entrenársele, emplear nuevo recursos o consultores externos. 3.2. Factibilidad Económica y Financiera Los beneficios financieros deben igualar o exceder a los costos. Las variables económicas y financieras, tienen el propósito de estimar: El costo de llevar a cabo el sistema, el costo de inversión de equipo (hardware), y el costo del software para realizar la aplicación, además de considerar los beneficios a obtener. 3.3 Factibilidad Operacional Esta factibilidad comprende una determinación de la probabilidad de que un nuevo sistema se use como se supone. Deberán considerarse tres aspectos de la factibilidad operacional por lo menos. a. El sistema debe ser amigable y de fácil comprensión para los usuarios, para que estos no deban usarlo en tal forma que cause errores o fallas en el sistema.
b. Un sistema puede hacer que los usuarios se resistan a él como consecuencia de una técnica de trabajo, miedo a ser desplazados, intereses en el sistema antiguo u otras razones. Para cada alternativa debe explorarse con cuidado la posibilidad de resistirse al cambio al nuevo sistema. c. La tecnología que ha sido anunciada pero que aún no está disponible puede ser preferible a la tecnología que se encuentra en una o más de las alternativas que se están comparando, o cambios anticipados en las prácticas o políticas administrativas pueden hacer que un nuevo sistema sea obsoleto muy pronto. En cualquier caso, la implantación de la alternativa en consideración se convierte en algo no practico. Otras posibilidades son que los programas de relaciones públicas o de entrenamiento estén diseñados para enfocarse a sobreponerse a la resistencia a un nuevo sistema, o se desarrollan formas para hacer fases en el nuevo sistema en un largo periodo para que el cambio total, que traumatizaría a los usuarios u operadores, se convierta en una serie de pequeños cambios.
ARQUETIPO ESTRATEGICO ESTANDAR PARA LA ELABORACIÒN DE SOFTWARE EN LA MEDIANA EMPRESA DEL SECTOR COMERCIO EN EL AREA METROPOLITANA DEL MUNICIPIO DE SAN SALVADOR AREA: TÉCNICA OBJETIVO: Servir como una herramienta práctica y de fácil utilización para todos los gerentes de proyectos Informáticos, analista-programadores de sistemas para el desarrollo de software o puesta en marcha de un proyecto informático 1. Determinación de requisitos por parte del Analista-Programador. Para determinar los requisitos por parte del Analistas-Programador se deben dividir en los aspectos siguientes: 1.1. Reconocimiento del Problema. En primer lugar el Analista-Programador debe reconocer si los requisitos para poner en marcha los proyectos son: a. Una empresa Nueva Determinar el número de procesos a realizar para obtener un producto final acorde con el número de procesos manuales que se efectúen dentro de la empresa, el analista-programador determinará cuales serán los requerimientos para poner en marcha el proyecto informático tomando en cuenta lo siguiente: 1. Número de procesos manuales a automatizar 2. Volumen de datos a introducir
3. Número de salidas requeridas por parte de los usuarios 4. A cuanto disminuirá el número de procesos al efectuarlo de manera automatizada 5. Estimar el tiempo de respuesta al efectuar los procesos de manera automatizada 6. Mejora de la calidad de resultados de forma automatizada. 7. Disponer de controles para monitorear la manipulación de los datos por parte del usuario final. b) Una empresa ya existente sin la tecnología adecuada o con procesos sin automatizar En este caso el analista-programador debe determinar cual de las siguientes razones son por las que existen procesos sin automatizar b.1 Para este rubro el analista-programador debe determinar si los procesos no están dando los resultados esperados debido a: 1. Capacidad de procesamientos bajos en razón al tiempo de respuesta 2. Capacidad de procesamiento bajos en razón al volumen de datos introducidos 3. Si el servicio es a través de un servidor, la capacidad de procesamiento es baja con respecto a las llamadas de los clientes 4. Disco duro del servidor con poca capacidad de almacenamiento con respecto al tamaño de la base de datos contenida. 5. Memoria RAM insuficiente para el número de procesos en el servidor. b.2 Procesos sin automatizar por nuevos requerimientos o deficiencias en análisis anteriores.
En este caso el analista programador debe determinar cuales procesos son los que están sin automatizar o que no están en un 100% automatizados y evaluar de acuerdo al punto a.1 de los puntos del 1 al 7. 1.2 Evaluación y Síntesis Luego de determinar en cual de las situaciones del punto 1 se encuentra la empresa, el analista-programador debe evaluar y emitir una síntesis. 1.2.1 Evaluación. a. Determinar si al implementar un nuevo sistema se minimizarán los tiempos de respuesta de los clientes. b. Determinar la factibilidad de desarrollo o de automatización de procesos existente c. Estimar el tiempo en que le tomará desarrollar el nuevo sistema. Dependiendo de la evaluación el analista-programador emitirá una síntesis, que debe determinar si cumple al menos con dos de los siguientes literales: a. Si minimizará el tiempo de respuesta a los clientes, justificar en que medida disminuirá los tiempos con respecto a la ejecución manual de ese proceso b. Si genera utilidad o gasto, justificar como ó hasta que tiempo genera la utilidad ya que pueden ser de tiempo, recurso humano o dinero c. Si el tiempo de desarrollo es demasiado, evaluar si puede ser minimizado aumentando recurso humano d. Justificar el ciclo de vida del proceso de desarrollo e implementación y porque se llego a esta conclusión.
1.3 Modelado Luego de haber ejecutado el reconocimiento del problema, la evaluación y síntesis; el analista programador deberá efectuar un modelado de la posible solución de la siguiente manera: a) Debe representar todos los objetos que contendrá el sistema. ( Diccionario de datos) Aquí se deberá escribir de forma breve cada uno de los objetos que se utilizarán para el desarrollo del sistema; estos objetos serán escritos de manera que puedan ser interpretados o entendidos por cualquier persona que las revise. b) Debe representar todos los sub-objetos u objetos heredados y que contendrán los objetos padres En este punto al igual que en el anterior el analista programador escribirá de forma breve y comprensible para cualquier persona que lea el código, así también deberá relacionar cada sub-objetos u objeto heredado con el objeto padre correspondiente. c) Como tercer punto el analista programador debe describir el funcionamiento general del sistema con respecto a los usuarios finales. Para este punto el analista programador puede hacer uso de información que sirva para mostrar el comportamiento del sistema, así también puede emplear el modelo de entrada y salida para mostrarlo de manera gráfica. Se puede valer de diagramas libres, DFD. 1.4 Especificaciones del Sistema. En esta etapa el analista programador describirá las funciones y el rendimiento del sistema basado en el uso de las computadoras y las dificultades que estarán presentes durante su desarrollo.
Tomando en consideración el equipo con el que cuenta la empresa o si se tiene planificado comprar nuevo equipo como funcionaría con respecto a la capacidad de procesamiento del nuevo. 2. Especificaciones del Software para el desarrollo e implementación del sistema En este punto el analista programador debe evaluar en cual de las siguientes situaciones se encuentra la empresa 2.1 Empresa sin lenguaje para el desarrollo de Software El analista programador debe efectuar un análisis exhaustivo para determinar: a. Cuál lenguaje de programación se apega a las necesidades de la empresa b. El lenguaje debe ser de fácil utilización para los analistas programadores c. Que el lenguaje sea conocido en el mercado y de fácil adquisición, y que también el costo de este sea accesible acorde con el presupuesto de la empresa d. Debe existir soporte y actualización periódica 2.2 Empresa con lenguaje para el desarrollo de Software; pero no es el adecuado El analista programador en este caso debe analizar lo siguiente: 2.2.1 Si existe lenguaje de programación, evaluar si cumple con las siguientes características: a. Reusuable, característica importante para un componente de software de alta calidad ya que puede ser reutilizado con otros programas.
b. Robusto, que posea la capacidad de efectuar todos los requerimientos del usuario c. Capaz de efectuar una conexión con cualquier base de datos d. Escalable 2.3 Empresa con lenguaje para el desarrollo de Software En este caso el analista-programador a determinado que el lenguaje existente es el adecuado para el desarrollo del nuevo sistema ya que cumple con los requerimientos de los usuarios. a. Se pueden emitir los reportes requeridos b. Capacidad de conectarse a la base de datos existente dentro de la empresa o casi cualquier base de datos ( por sí en un futuro existe cambio de plataforma) c. Escalable 3. Especificación de Hardware para el desarrollo e implementación del sistema El analista programador debe evaluar 3.1 La obsolencia o no del equipo Si el equipo existente cumple con los requisitos de hardware para poder ser implementado el nuevo software así también el tiempo de vida útil del equipo. Las condiciones para evaluar la obsolescencia son:
Espacio en disco Tamaño en RAM CPU Periféricos Arquitectura ( 32bits - 64bist) Si es servidor, Hardware de redundancia 3.2 La compatibilidad de Hardware y Software. El equipo existente debe ser compatible seleccionado y también el software desarrollado para poder ejecutar el lenguaje 4. Elaboración documento Técnico Para elaborar el documento técnico el analista programador debe seguir los siguientes pasos: 1. Redactar de manera clara, precisa y de fácil entender para el Gerente del Proyecto o Gerente General. 2. El documento técnico contendrá a) Objetivo General b) Objetivos Específicos c) Breve descripción de lo que el sistema efectuará, tanto en sus entradas como en sus salidas y tipos de reportes que emitirá d) Los requerimientos mínimos de hardware y software para implementar el sistema (capacidad en memoria, capacidad en disco, servidores, sistema operativo, tipo de licenciamientos)
e) Cantidad de hardware ( computadoras, impresores, quemadores, escáneres, servidores) que será necesarios para implementar el sistema f) Infraestructura de red si es necesario g) La herramienta que se ajuste para desarrollar el sistema especificado Nombre del paquete para el desarrollo Versión Número de Licencias a comprar Capacidad en memoria y disco duro para las computadoras donde será desarrollado el sistema Número de máquinas requeridas ( de acuerdo a las personas que trabajaran en el desarrollo de éste) h) Elaborar diagrama Entidad-Relación del sistema a desarrollar con base a la descripción y representación de los objetos (diccionario de datos). i) Elaborar diagrama jerárquico del sistema, de manera que sea de fácil visualización al Gerente del Proyecto y Gerente General. (ver anexo 2) 3. Definir que procesos se automatizarán y mostrar datos estadísticos para realizar comparación de tiempos entre los proceso manuales y actualizados de la manera siguiente tales como:
Procesos Procesos Manual Automatizados Tiempo de proceso Por transacción xxx Horas:min xxx Horas:min Número de Procesos Efectuados xxx Cantidad xxx Cantidad Número de personas necesarias xxx Hombres xxx Hombres 4. Presentar conclusiones sobre el proyecto para el desarrollo de cada uno de los siguientes items: a. Implantación b. Ejecución de procesos c. Tiempo de Respuestas d. Calidad en la información
ARQUETIPO ESTRATEGICO ESTANDAR PARA LA ELABORACIÒN DE SOFTWARE EN LA MEDIANA EMPRESA DEL SECTOR COMERCIO EN EL AREA METROPOLITANA DEL MUNICIPIO DE SAN SALVADOR AREA: OPERATIVA OBJETIVO: Orientar al analista-programador para llevar a cabo de una manera eficiente el desarrollo del sistema y su interacción con el usuario 1. Diagrama E-R A través del diagrama E-R el analista programador representará un modelo basado en la realidad, empleando entidades, atributos y las relaciones o enlace entre las entidades( ver anexo 3). De esta manera el analista-programador podrá representar de manera sencilla y rápida todas aquellas entidades o elementos principales con los que contará el sistema y así también las principales tablas con las que contará el nuevo sistema a desarrollar Los pasos que el analista-programador debe seguir en un diagrama E-R son los siguientes: 1. Identificar plenamente cuales son las entidades principales ( Ej. Transacciones, maestros, etc. ) 2. Colocar los nombres adecuados a cada una de las entidades ( Ej. Ventas, Empleado, Artículos, etc.)
3. Identificar cada una de las relaciones que existe entre las entidades y con cuales atributos estarán relacionadas. 4. Colocar los nombres adecuados a cada una de las relaciones tomando en cuenta el nombre de los atributos 5. Emplear los métodos formados de normalización de Base de Datos, reglas de normalización de 1 a la 4. Con el diagrama de flujos de datos, se puede realizar un esquema del camino que toman los datos durante todos los procesos que desarrolla el software. A partir del análisis de los objetos y el diagrama E-R se pueden definir los siguientes símbolos para la creación de un DFD Flujo de Datos Proceso Almacenamiento Entrada / salida Los símbolos pueden variar de acuerdo al autor, para realizar el DFD, se puede utilizar un software para diseñarlo o basta realizarlo en papel. Puede definirse para realizar esquemas que presenten niveles de detalle, apartir de nivel inicial o nivel 0 (ver anexo 4). 2. Metodología del Arquetipo Estratégico Estándar para el desarrollo de Software En este apartado encontraremos una guía de cómo realizar o elaborar un sistema en la mediana empresa a. Análisis del problema Una vez en la etapa anterior se ha determinado cual es el problema principal con el que cuenta la empresa, el analista-programador debe comenzar a efectuar su
análisis respectivo para enfocar y desglosar dicho problema, poniendo en práctica los siguientes pasos: 1. Determinar cual es el problema principal que se quiere resolver 2. Junto con el o los usuarios poner en claro cuales serán las entradas y salidas para elaborar el sistema (Definición final del DFD) 3. Mostrar al usuario una propuesta del diagrama jerárquico del sistema (Menú principal con todas sus opciones) 4. Efectuar los cambios necesarios al Diagrama Jerárquico del sistema para una mejor funcionalidad en los procesos e ir al paso anterior (paso 3) b. Diseño del Software El diseño es la única manera de materializar con precisión los requerimientos de los usuarios, donde el analista-programador deberá describir todos los aspectos del sistema a construir: Por lo tanto debe establecer criterios generales como: 1. Elaborar diagrama jerárquico que haga un uso inteligente del control entre los componentes del software. 2. Crear módulos, es decir que debe hacer una partición lógica del software, en elementos que realicen funciones u subfusiones especificas. 3. Presentar características de funcionamiento independiente. 4. Interfases que reduzcan la complejidad de las conexiones entre los módulos y el entorno exterior Los pasos para la fase de Diseño son los siguientes: 1. Diseño de datos. En este paso el analista-programador trasforma el diagrama entidad-relación en estructuras de datos necesarios para poner en marcha el nuevo software, acorde a los requerimientos de los usuarios y siempre teniendo en cuenta los objetivos de la empresa.
2. Diseño Arquitectónico El analista-programador hace uso de las herramientas utilizada como el diagrama entidad-relación y define cuales serán las llaves primarias en cada una de las tablas principales que posea la estructura del nuevo sistema. Así también definir plenamente la relación entre cada una de las tablas utilizadas 3. Diseño de pantallas En este paso el analista programador debe diseñar las pantallas que serán utilizadas dentro del sistema, con base al DFD, diagrama jerárquico y E-R teniendo en cuenta lo siguiente: a. El número de entradas requeridas y necesarias para futuros procesos b. Ubicación lógica y adecuada de los datos c. Colores agradables a los usuarios d. Tamaño adecuado de las etiquetas presentada en las pantallas y en las cajas de texto mostradas en la pantalla e. Diseñar de manera estándar es decir de acuerdo al número de datos presentados así será el tamaño de cada pantalla f. Diseñar los botones de manera grafica o de texto; pero solamente una de los dos en todas las pantallas y no combinado. 4. Diseño de Reportes El diseño de reportes debe ser estándar, dentro del área de informática debe implantarse estándares para el diseño y desarrollo de los reportes tomando en cuenta los siguientes pasos: 1. El encabezado de reporte contendrá: a. Nombre de la empresa b. Departamento del cual se esta generando el reporte c. Nombre del reporte
d. Dato según criterio de búsqueda: por rango, por fecha, por usuario, por rubro, etc., 2. En el cuerpo contendrá: a. Todos los datos que están almacenados en la Base de Daros según criterio solicitado por usuarios b. Ordenados en forma ascendente o descendente 3. En el pie del reporte contendrá: a. Firmas de las personas responsables del reporte b. Fecha de emisión del reporte (letra tamaño 8) c. Hora de emisión del reporte (letra tamaño 8) d. Usuario que imprimió el reporte (letra tamaño 8) Es aconsejable que el usuario elabore plantillas de los requerimientos de información de sus respectivos datos en algún editor de texto que sirva de base para la elaboración de informes. 5. Diseño de Librerías En caso de existir un grupo de funciones u objetos que son utilizables en diferentes segmentos del desarrollo del software estos deben ser ubicados en una librería para en primer lugar estandarizar lo que es la programación y en segundo lugar para que sea de fácil acceso y la reutilización desde cualquier modulo que lo invoquen. c. Desarrollo del software Para comenzar con el desarrollo del software en el área de informática se tiene que poner en práctica estándares para efectuar el desarrollo entre los cuales tenemos: