Políticas de versionamiento

1.- Introducción

 Esta política explicara el objetivo de la misma así como el alcance que posee además de la misma política de versión amiento

2.-Objetivo General

La política que se presenta tiene como objetivo de delimitar las herramientas que lleven el control de versión amiento durante el proceso del proyecto SAD

3.-Objetivos Específicos

La definición de los parámetros que ayudaran para el versiona miento del proyecto

Establecer las normas con las que se llevaran a cabo con el proceso de construcción del mismo

4.-Alcance

 Tiene un alcance para todas las áreas dentro del desarrollo del proyecto.

5.-Destinatarios

Está dirigida para aquellos que son responsables dentro de todo el proceso de la realización del proyecto SAD

6.-Politica de versionado

        6.1Proyecto

Para nuestra política de versiona miento en cuestión al código se empieza por el nombre para el proyecto además utilizamos 3 números y al final el calificador:

1: Indica la versión principal del software además cambios radicales en los requerimientos y funcionalidad o la creación de uno nuevo

2: Indica el arreglo de fallos en los requerimientos y funcionalidades

3: Indica la revisión y arreglos de fallos menores

Ejemplo

SAD 1.2.1-ALPHA

SAD 2.5.3-BETA

6.2Documentos (General)

Para nuestra política de versión amiento en cuestión a la documentación del proyecto se separaran de acuerdo a los ECS y a partir de ellos ser irán utilizando 3 números que indicaran lo siguiente:

1: Indica la versión principal del documento

2: Indican cambios  que se efectuaron  en el mismos o la creación de uno nuevo

3: Indica el arreglo de fallos en general

Especificación de la política de versiona miento para los ECS

1.- Diagramas de Casos de Uso (DCU)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

DCU 2.1.4

Carpeta: SAD/src/Documentos/Diagramas/DCU.mdj

2.-Diagramas de Actividades (DA)

Se utilizará el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

DA 3.1.0

Carpeta: SAD/src/Documentos/Diagramas/DA.mdj

3.-Diagramas Entidad-Relación (DE-R)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

DE-R 1.0.1

Carpeta: SAD/src/Documentos/Diagramas/DE-R.mdj

4.-Diagramas de Secuencia (DS)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

DS 2.2.1

Carpeta: SAD/src/Documentos/Diagramas/DS.mdj

5.-Diagramas Relacionales (DR)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

DS 4.2.1

Carpeta: SAD/src/Documentos/Diagramas/DR.mdj

6.-Look and Feel (LF)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

LF 1.2.1

Carpeta: SAD/src/Documentos/Diseño/LF.docx

7.-Especificacion de casos de uso (ECU)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

ECU 3.1.2

Carpeta: SAD/src/Documentos/Analisis/ECU.docx

8.-Requerimientos Funcionales (RF)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

RF 1.0.1

Carpeta: SAD/src/Documentos/Analisis/RF.docx

9.-Requeriminetos no Funcionales (RnF)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

RnF 2.1.1

Carpeta: SAD/src/Documentos/Analisis/RnF.docx

10.- Requerimientos de sistemas (RS)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

RS 3.1.2

Carpeta: SAD/src/Documentos/Analisis/RS.docx

11.-Manual de Usuario (MU)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

MU 2.1.0

Carpeta: SAD/src/Documentos/Mantenimiento/MU.docx

12.-Manual de Mantenimiento (MM)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

MM 3.1.2

Carpeta: SAD/src/Documentos/Mantenimiento/MM.docx

13.-Manual de Integración (MI)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

MI 2.0.1

Carpeta: SAD/src/Documentos/Mantenimiento/MI.docx

14.-Pruebas unitarias (PU)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

PU 4.1.2

Carpeta: SAD/src/Documentos/Pruebas/PU.docx

15.-Pruebas de integración (PI)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

PI 1.1.9

Carpeta: SAD/src/Documentos/Pruebas/PI.docx

16.-Pruebas de sistema (PS)

 Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

PS 1.4.7

Carpeta: SAD/src/Documentos/Pruebas/PS.docx

17.-Pruebas de validación (PV)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

PV 4.1.8

Carpeta: SAD/src/Documentos/Pruebas/PV.docx

18.-Pruebas de aceptación (PA)

Se utilizara el  nombre del archivo en siglas y se utilizara la política antes mencionada

Ejemplo

PA 7.1.9

Carpeta: SAD/src/Documentos/Pruebas/PA.docx

¿Qué es RAID? (1, 2, 3, 4, 5)

RAID 

¿Qué es RAID?

RAID (Redundant Array of Inexpensive Disks), por su traducción, llamado también como conjunto redundante de discos independientes es un sistema de almacenamiento de datos que utiliza diversas unidades de almacenamiento (discos duros) en los cuales los datos se distribuyen.

RAID cuenta con distintos niveles de configuración, de los cuales se desprenden distintos tipos de beneficios, los cuales son similares al de un sistema distribuído, que son:

• Tolerancia a fallos
• Mayor rendimiento
• Mayor capacidad
• Mayor velocidad
• Mayor fiabilidad
• Combinar dispositivos de bajo costo

Niveles de RAID (Nivel de Configuración)

En su primer nivel de configuración, de manera que el sistema operativo no lo detecte, combina varias unidades de almacenamiento (HDD) en un mismo dispositivo, siendo más conveniente utilizarlo en servidores y preferentemente en unidades de la misma capacidad.

• RAID 0: Conjunto dividido, volumen dividido o seccionado, distribuye los datos de manera equitativa en dos o más unidades de almacenamiento, no es un nivel como tal y no es redundante.
• RAID 1: Espejo, crea una copia exacta de un conjunto de datos en dos o más discos de almacenamiento, lo cual resulta útil cuando se quiere tener un respaldo de seguridad de los datos en un servidor
• RAID 2:Divide los datos a nivel de bytes, en lugar de un nivel de bloques, los discos son organizados por el controlador para funcionar de manera simultánea.
• RAID 4:Acceso independiente con discos dedicados a la paridad, usa una división a nivel de bloques  con un disco de paridad dedicado.
• RAID 5: Distribuido con paridad, es una distribución a nivel de bloques que distribuye la información deforma ecuánime en los discos de almacenamiento del sistema.

Conclusiones.

Creo que RAID, en sus distintas conflagraciones, es una buena manera de distribuir, respaldar, acelerar y optimizar la información de un sistema almacenada en un servidor, ya que actúa de forma distribuida.

Mesa de Ayuda

¿Qué es una mesa de ayuda?

Mesa de Ayuda, Mesa de Servicio o simplemente CAU Centro de Atención al Usuario es un conjunto de recursos tecnológicos y humanos, para prestar servicios con la posibilidad de gestionar y solucionar todas las posibles incidencias de manera integral, junto con la atención de requerimientos relacionados a las Tecnologías de la Información y la Comunicación (TIC).

Utilidades

La Mesa de Ayuda se basa en un conjunto de recursos técnicos y humanos que permiten dar soporte a diferentes niveles de usuarios informáticos de una empresa, tales como:

• Servicio de soporte a usuarios de “sistemas microinformáticos”
• Soporte telefónico centralizado en línea
• Atendido de forma inmediata e individualizada por Técnicos Especializados
• Apoyado sobre un Sistema informático de última generación

Conclusiones

Creo importante la implementación del concepto de una mesa de ayuda, ya que de esta manera se puede llevar a cabo una ayuda y apoyo al cliente de manera más personalizada.

Elementos de Configuración del Software

Elementos de Configuración del Software

¿Qué es la configuración del Software?

Dentro de la ingeniería de Software, la información creada y/o recopilada durante éste proceso se denomina como "configuración del Software".

También se denomina como gestión de la configuración del software al proceso en el cual se identifican y se definen los procesos del sistema, controlando el cambio de éstos elementos a lo largo del ciclo de vida de los mismos.

De ésta manera, se lleva a cabo un control sistemático de los cambios en la configuración y el mantenimientos de la integridad y trazabilidad de la configuración a través del ciclo de vida del software.

Los productos son:

• Software distribuído al cliente
• Documentos de requerimientos del software
• Codificación
• Elementos requeridos

Elementos de Configuración del Software:

1. Plan de Proyecto
2. Plan de Gestión de Configuración
3. Documento de Requerimientos
4. Análisis
5. Documentos de análisis
6. Documentos de diseño del sistema
7. Prototipos
8. Documentos de diseño de alto y bajo nivel
9. Especificaciones de prueba del sistema
10. Plan de pruebas
11. Código fuente
12. Código objeto
13. Pruebas de unidad
14. Diseño de bases de datos
15. datos de prueba
16. datos de proyecto
17. manuales de usuario

Referencias:

http://www.histaintl.com/soluciones/configuracion/configuracion.php

Leyes de Lehman para el Desarrollo Software

Leyes de Lehman

Como ya sabemos, el Desarrollo de Software siempre conlleva un gran proceso de evolución, precisamente, bajo este dicho, las leyes formuladas por Lehman describen el balance entre las fuerzas que impulsan nuevos desarrollos y las fuerzas que realentizan el proceso.

Las leyes de Lehman:

• Ley de Cambio Continuo: En algún momento, un programa o sistema utilizado de manera habitual, se irá volviendo, progresivamente, menos útil o menos satisfactorio al usuario.
• Ley de la Complejidad Creciente: A medida que un programa o sistema evoluciona, tiende a ser más complicado en cuento a su estructura, por lo que se deben dedicar esfuerzos extra para mantener, simplificar y preservar dicha estructura.
• Ley de la Autorregulación: La evolución de los programas o sistemas deben llevarse a cabo mediante una regulación 
• Ley de la Estabilidad Organizacional: Durante el tiempo de vida de un sistema, su tiempo de desarrollo es independiente de los recursos dedicados al sistema.
• Ley de la Conservación de la Familiaridad: Debe de mantenerse un conocimiento acerca de la aplicación durante su evolución, tanto con los clientes, usuarios, desarrolladores, manteniendo un crecimiento constante y promedio.
• Ley del Crecimiento Continuado: El crecimiento de una aplicación tiende a ser contínuo para mantener la satisfacción y comodidad del cliente.
• Ley del Decremento de la Calidad: Consiste en remarcar, más que nada, que las aplicaciones mientras evolucionan tienden a perder parte de su calidad, por lo que se debe llevar a cabo un adaptamiento integral a los cambios del entorno de dicho software.
• Ley de la Retroalimentación del Sistema: Debe de ser incorporada la retroalimentación dentro del software,con el fin de lograr una mejora significativa.

Conclusiones:

Creo que es importante resaltar las leyes de Lehman mencionadas en el documento anterior, ya que nos ayudan a precisar metodologías ágiles acerca del proceso del desarrollo y mantenimiento del Software, siendo que éstos últimos son llevados de la mano en la mayoría de las ocasiones.

Referencias:

Roger S. Pressman, "Ingeniería del Software en un Enfoque Práctico", McGrawHill, México, 1998.

Reporte Visita a Casa TELMEX

Visita a Casa Telmex

Durante la visita a la Casa TELMEX, ubicada en el centro histórico de la Ciudad de México, aprendimos un poco acerca la programación por bloques en otras plataformas, específicamente en Scratch, donde se nos fue planteada la idea de desarrollar un juego de "Busca minas" de tal forma que fuera lo más parecido posible al de la computadora, posteriormente, después de dos horas de ser guiados por el profesor, pasamos a otra sala en donde se nos fue enseñado el uso de herramientas más que nada de uso forense para extraer meta datos de las fotografías que circulan en Internet.

En otro plano, se nos fue propuesto un desafío: copiar y pegar tres elementos de una carpeta a otra sin el uso del ratón, mediante comandos de consola del sistema operativo de Windows.

Para finalizar, quisiera agregar que considero que fue una práctica muy fructífera, ya que conocimos las distintas aplicaciones que nuestra área tiene en el mundo laboral y social, así como que se nos fue propuesta la impartición de clases por parte del personal de Casa Telmex de forma gratuita. 

Soporte Técnico | Mantenimiento y Soporte de Software

       Soporte Técnico | Mantenimiento y Soporte de Software

Es bien sabido que posteriormente al desarrollo de software, siempre existirán dudas, esto es, más que nada, debido a que la interfaz o el funcionamiento de la aplicación pueden no ser muy claras para la gente, lo que nos lleva a tener que capacitar gente que resuelve dichas dudas a los usuarios.

Generalmente se sigue un proceso o ciclo de vida del software, el cual consiste en: Análisis, Diseño, manufactura, pruebas implantación y mantenimiento.

De igual forma, dicho ciclo surge de la entrega, mantenimiento y retroalimentación.

El mantenimiento es el proceso de efectuar cambios en un software después de entregado, el cual se presenta cuando el software se adapta a un nuevo ambiente, se corrigen errores, el cliente presenta funciones nuevas o cuando la aplicación presenta una reingeniería.

Por lo que existen cuatro tipos de mantenimiento:

•          Mantenimiento correctivo
•          Mantenimiento adaptativo
•          Mantenimiento de perfeccionamiento
•          Mantenimiento preventivo

COSTOS

El mantenimiento de un programa genera un costo aproximado de un tercio de la creación de la aplicación, lo que hace que muchas empresas no precisen hacer este gato, ya que el precio puede aumentar desmedidamente y las ganancias bajan.

El precio de la aplicación se incrementa debido a este hecho, por lo que, ya hecho, se debe procurar que sea lo mejor posible y de mayor calidad.

El lector puede preguntarse qué se debe considerar cuando se realiza un mantenimiento. El número y complejidad de las interfaces, los requerimientos explicados de manera específica y el proceso de negocio que utiliza el sistema, ya que es decisivo que se pueda arreglar el problema de manera óptima con unas cuantas lineas de código.

Podemos concluir que el soporte y el mantenimiento son similares sólo que cada uno se enfoca en atender una parte distinta del sistema. El soporte se da al usuario mientras que el mantenimiento se encarga del software y hardware.

REFERENCIA

Presman Roger, (2005), Ingeniería de software un enfoque practico, McGraw-Hill InteramericanaSomerville Ian, (2005), Ingeniería de software, Madrid: Pearson Educación S.A.