Introduccin:

Como pudiste darte cuenta el PSP0 es un proceso con mediciones bsicas,

para lo cual se utilizan formas en las que se registran tiempos y defectos.

Propsito:
Analizar las herramientas de PSP0 e identificar la aplicacin de la informacin
que se genera por medio de las herramientas PSP0 con base en un caso de
anlisis.

Instrucciones:
Para el desarrollo de la actividad, tu docente en lnea te har llegar las
instrucciones necesarias, una vez que cuentes con ellas, sigue estos pasos:

1. Analiza el caso e identifica el uso de los formatos PSP0

2. Identifica el tipo de informacin que se proporciona y su aplicacin.

3. Explica la importancia del uso de las herramientas PSP0 para el

desarrollo de programas.

4. Guarda tu actividad con el nombre DMDS_U1_EA_XXYZ. Sustituye las

XX por las dos primeras letras del primer nombre, la Y por tu apellido
paterno y la Z por tu apellido materno.

5. Consulta los criterios de evaluacin de la actividad para considerarlos

en el desarrollo de la misma.

6. Enva tu Evidencia de aprendizaje a tu docente en lnea mediante el

Portafolio de evidencias. Espera y atiende la retroalimentacin
correspondiente.

Conclusiones y recomendaciones:
Cuando el ingeniero de desarrollo o programador registra sus tiempos y
defectos deber tomar en cuenta que esto es un proceso personal, que no
tiene por qu afectarse con los tiempos de otros desarrolladores, por lo cual
deber esforzarse en hacer un registro honesto para entender y mejorar su
proceso personal de desarrollo.
Planteamiento del problema

El Sistema de Administracin Tributaria estableci que a partir del 1 de enero del

2011 los contribuyentes debern expedir documentos digitales como
comprobantes por las actividades que realicen.

Una factura electrnica, tambin llamada comprobante fiscal digital, e- factura o

efactura, es un documento electrnico que cumple con los requisitos legal y
reglamentariamente exigibles a las facturas tradicionales garantizando, entre otras
cosas, la autenticidad de su origen y la integridad de su contenido.

La factura electrnica es, por tanto, la versin electrnica de las facturas

tradicionales en papel y debe ser funcional y legalmente equivalente a estas
ultimas. Por su propia naturaleza, las facturas electrnicas pueden almacenarse,
gestionarse e intercambiarse por medios electrnicos o digitales.

Contexto de la solucion

La factura electrnica es un tipo de factura que se diferencia de la factura en papel

por la forma de gestin informtica y el envo mediante un sistema de
comunicaciones que conjuntamente permiten garantizar la autenticidad y la
integridad del documento electrnico.

Una factura electrnica se construye en 2 fases:

Se crea la factura tal y como se ha hecho siempre y se almacena en un archivo

de datos.
Posteriormente se procede a su firma con un certificado digital o

electrnico propiedad del emisor que cifra el contenido de factura y anade el sello
digital a la misma.

Al terminar obtenemos una factura que nos garantiza:

que la persona fsica o jurdica que firm la factura es quien dice ser
(autenticidad) y
que el contenido de la factura no ha sido alterado (integridad).

El emisor enva la factura al receptor mediante medios electrnicos, Si bien se

dedican muchos esfuerzos para unificar los formatos de factura electrnica,
actualmente est sometida a distintas normativas y tiene diferentes requisitos
legales exigidos por las autoridades tributarias de cada pas, de forma que no
siempre es posible el uso de la factura electrnica, especialmente en las
relaciones con empresas extranjeras que tienen normativas distintas a la del
propio pas.

Los requisitos legales respecto al contenido mercantil de las facturas electrnicas

son exactamente las mismas que regulan las tradicionales facturas en papel. Los
requisitos legales en relacin con la forma imponen determinado tratamiento en
aras de garantizar la integridad y la autenticidad y ciertos formatos que faciliten la
interoperabilidad.

La factura electrnica permite que instituciones, empresas y profesionales dejen

atrs las facturas en papel y las remplacen por la versin electrnica del
documento tributario. Tiene exactamente la misma validez y funcionalidad
tributaria que la factura tradicional en papel. Todo el ciclo de la facturacin puede
ser administrado en forma electrnica.

Captulo 3. Figura 11
Solucin

El Ing. X no ve mayor dificultad en la aplicacin a desarrollar y con la

empresa acordaron en un plazo de entrega de aproximadamente 1
mes, X procede a una programacin de actividades en un diagrama de
Gantt de las actividades que tiene que realizar. Si bien sus
programaciones no sern exactas, con la experiencia se tendr que
mejorar las mismas.

2. Requisitos del Software

Solucion propuesta

Los requerimientos que debe de cumplir el sistema son:

Se solicit crear un sistema que fuera un portal web para la creacin de

comprobantes fiscales digitales que cumplan con las disposiciones del SAT y
ayude a los emisores de factura a administrar sus clientes y productos con el fin
de generar sus comprobantes de forma rpida y sencilla.

Los usuarios ingresan al sistema por medio de un login y una contrasena.

 Los usuarios podrn recuperar su contrasena para ingresar al sistema.

El usuario puede visualizar su estado, esto incluye operaciones disponibles,

carga del logo, carga de certificados, carga de folios.

El sistema debe mostrar como parte de la ayuda el manual de usuario del

sistema.

Los usuarios podrn consultar en el sistema la gua para obtener la gua

para generar la firma electrnica avanzada (FIEL) y el certificado de sello

digital (CSD).

El administrador puede crear, modificar y consultar emisores, puede

generar nuevas credenciales o agregarles saldo.

El sistema debe ser capaz de administrar paquetes de las distintas

operaciones que se pueden realizar en la empresa.

El sistema deber permitir administrar las plantillas utilizadas para la

generacin de las representaciones impresas de los comprobantes fiscales

digitales.

El usuario puede administrar los detalles de su cuenta, datos fiscales, datos

de contacto, direccin y el logo.

El sistema debe administrar los certificados del usuario proporcionados por

el SAT.

El sistema deber permitir administrar los folios personalizados con los que
contarn los comprobantes fiscales digitales.

El sistema deber permitir administrar clientes del emisor.

 El sistema debe permitir la administracin de las sucursales que manejen

las empresas de los usuarios.

El sistema deber permitir administrar los productos de los emisores, los

cuales se debern utilizar para la generacin de los comprobantes fiscales

digitales.

El sistema deber permitir administrar los usuarios del emisor, se deben

poder asignar perfiles a los usuarios as como generar nuevas credenciales.

Se debe establecer una plantilla default para la generacin de

comprobantes.

El sistema deber permitir la expedicin de comprobantes fiscales digitales

incluyendo la generacin de su representacin impresa.

El sistema deber permitir la expedicin de comprobantes CBB incluyendo

la generacin de su representacin impresa.

El sistema debe administrar los comprobantes que gener el usuario del

mismo.

El sistema deber permitir generar reportes acerca de los comprobantes

generados.

El sistema debe permitir cerrar la sesin del usuario.

3. Estimacion del Software
Ahora llega el momento de ir anotando los tiempos de las actividades
 que X realiza en el Cuaderno de Registro de Tiempos. Para empezar
X anota el tiempo de planificacin y estimacin.

Nombre: Ing. X
Programa: AFG

4. Diseo

La arquitectura propuesta para el sistema fue la siguiente:

Figura 14

Para el desarrollo de este sistema, el cual ser una aplicacin Web, se seguir el
patrn de diseno Modelo Vista Controlador (MVC), el cual permite separar los
datos de la aplicacin, la interfaz de usuario y la lgica de negocio en tres
componentes distintos.

La tecnologa a utilizar para implementar la interfaz de usuario ser JavaServer

Faces (JSF) dada la experiencia del equipo de desarrollo en esta herramienta.
Con el uso de esta tecnologa se asegura el uso de un estndar reconocido en el
medio para desarrollo de interfaces grficas dentro de aplicaciones empresariales.

Como gestor de base de datos se utilizar MySQL por ser un gestor robusto y
simple que no impone restricciones de licencia para su uso dentro del desarrollo
de este sistema. Junto con esta herramienta se usar Hibernate, una herramienta
que facilita el almacenamiento y la obtencin de los objetos de dominio
implementados en Java a travs de un mapeo Objeto/Relacional (ORM). Ambas
tecnologas constituyen la capa de acceso a datos de nuestro sistema.

La capa de servicios ser implementada utilizando Spring

Frameworkprincipalmente por la versatilidad que provee para implementar
patrones como la inyeccin de dependencias (DI) para interconectar todos
servicios que sern implementados dentro del sistema y la facilidad para
exponerlos a la capa de vista. Otros aspectos a implementar a travs del uso de
esta tecnologa son la seguridad de la aplicacin (Spring Security), el manejo de
transacciones y el uso de la programacin orientada a aspectos (AOP) para
implementar cuestiones como el logging de informacin.

Tecnologia utilizada

Lenguaje de programacin JEE 5.0

Framework para interfaces de usuario Java Server Faces 2.2

Librera de reportes Jasper Reports 4.0

Librera de componentes JSF Primefaces 2.2

Lenguaje de programacin AspectJ para la implementacin de

interceptores

con AOP.

Servidor de aplicaciones Jboss 5.0

Manejador de base de datos MySQL 5.0

Framework de persistencia Hibernate 3.6

Framework de desarrollo Spring 3.0

Actividades realizadas

Las actividades que tuve asignadas en este proyecto fueron las siguientes:

Definir la arquitectura del sistema.

Crear la instalacin del sistema.

Administracin del cdigo.

 Definir la estructura de la base del sistema.

Modelado de las entidades base del sistema.

Creacin de los servicios de Emisores.

Creacin de los servicios de Folios.

Creacin de los servicios de Clientes.

Creacin de los servicios de Sucursales.

Creacin de los servicios de Consulta.

Creacin componente de vista Comprobantes.

Creacin componente de vista Folios.

Creacin componente de vista Productos.

Creacin componente de vista Consulta.

Creacin componente de vista Sucursales.

Creacin componente de vista Usuarios.

5. Codificacion

El siguiente paso es codificar los disenos, para lo cual X necesita tener

o elaborar un estndar de codificacin. Debido a que empieza a usar
por primera vez un estndar, toma como gua uno general y corto,
como el siguiente:


Figura 15

Figura 16
Figura 17

La definicin de la arquitectura surgi del anlisis de los requerimientos, de la

experiencia de proyectos anteriores y de asesoras con los arquitectos de dichos
proyectos, se quera que la comunicacin del back con el front fuera de forma
natural por lo que se opt por utilizar JavaServerFaces como tecnologa para la
interfaz de usuario.

Despus de investigar libreras de JSF a utilizar se decidi el uso de PrimeFaces

por el numero de componentes que tiene la facilidad de uso, de tal forma que la
curva de aprendizaje no fuera tan pronunciada.

La instalacin del sistema consisti en la puesta en marcha del servidor de

aplicaciones (Jboss 6), la configuracin del framework de Spring 3, la conexin
con Hibernate 3.2 y PrimeFaces 2.2.

Dentro de la instalacin del sistema se contempl la creacin de los proyectos de

Maven de la aplicacin, esto para llevar a cabo la administracin del cdigo y no
depender de ningun IDE en el desarrollo.

Dentro de la administracin del cdigo se contempl la creacin de los repositorios

de subversin y la definicin de las polticas de administracin de cdigo. Dichas
polticas se basaron en las mejores prcticas en la administracin de versiones
con Subversion.

Se modelaron todas las entidades base del sistema de acuerdo al anexo 20

publicado por el SAT y a los requerimientos del cliente. Se mapearon las entidades
a la base de datos utilizando Hibernate como ORM.

Despus del anlisis del anexo 20 se genero el diagrama de clases del sistema de
la figura 18.

35
Reporte de experiencia profesional

Junto con el diagrama de clases tambin se obtuvo el diagrama entidad relacin

del sistema mostrado en la figura 19.
Con los diagramas de clases y de entidad relacin se definieron los mdulos del
sistema junto con su correspondiente diagrama. Figura 20. Dado que el sistema
no fue concebido en su totalidad sino que se pens que su crecimiento fuera
gradual se pens en la creacin de los componentes como un conjunto de
servicios que consumen otros servicios, es por esto que el diagrama solo refleja la
funcionalidad mas importante en el sistema y la interaccin por medio de
interfaces entre los diferentes componentes.
Los mdulos definidos y su funcionalidad fue la siguiente:
 Usuarios. Este mdulo es el encargado de llevar a cabo la administracin
de usuarios del sistema as como la asignacin de sus permisos.

Folios. Este mdulo es el encargado de llevar a cabo las operaciones

para la administracin de los folios fiscales tramitados ante el SAT y de los
folios para control interno de los emisores.

Acceso Usuarios. Este mdulo es el encargado de las operaciones de

acceso al sistema.

Encriptacin de Datos. Este mdulo es el encargado de cifrar y descifrar

la informacin en la base de datos.

Emisores. Este mdulo es el encargado de llevar a cabo las operaciones

para la administracin de los emisores.

Certificados digitales. Este mdulo es el encargado de la administracin

de los certificados digitales del emisor y sus sucursales.

Clientes. Este mdulo contiene las operaciones necesarias para llevar a

cabo la administracin de los clientes del emisor.

Sucursales. Este mdulo contiene las operaciones necesarias para llevar

a cabo la administracin de las sucursales del emisor.

Plantillas. Este mdulo es el encargado de administrar las plantillas

utilizadas en las representaciones impresas de los comprobantes fiscales.

Impuestos. Este mdulo es el encargado de las operaciones para la

administracin de los impuestos en el sistema, tambin define el clculo de
los impuestos aplicados a los productos.

Productos. Este mdulo es el encargado de la administracin de los

productos que factura el emisor.

Listas de precios. Este mdulo es el encargado de administrar las listas

de precios del emisor.

Paquetes. Este mdulo contiene las operaciones para la administracin

de los paquetes de operaciones en el sistema, define que tipo de
operaciones y cuantas, tambin administra el saldo del emisor.

Comprobantes. Este mdulo es el encargado de administrar los

comprobantes en el sistema en forma genrica.
 Generador de reportes. Este mdulo es el encargado para la generacin
de reportes en el sistema.

Envo de correos. Este mdulo es el encargado del envo de correos en

el sistema.

Comprobante CFDi. Este mdulo contiene las operaciones especficas

necesarias para manejar la lgica que atane a los comprobantes CFDi.

Comprobante CBB. Este mdulo contiene las operaciones especficas

necesarias para manejar la lgica que atane a los comprobantes CBB.

Timbrado. Este mdulo es el encargado de generar las conexiones con el

PAC para llevar a cabo el timbrado de los comprobantes.

La creacin de los servicios contempl desde la creacin del DAO

necesario hasta la creacin de los servicios, para los DAOs se utiliz un
DAO Genrico que por medio de genricos se acoplaba a cualquier entidad
del sistema.

La creacin de la vista incluye los archivos xhtml necesarios para crear la

vista, el controlador de la vista y los Backing Beans necesarios que
modelen los componentes de la vista.

6. REVISION DE CODIGO

Una vez terminada la codificacin, ahora corresponde realizar la

revisin del cdigo, mediante una la lista de comprobacin, siempre
antes de compilar. Por el momento X utilizara una lista de
comprobacin general, con el tiempo tendr que definir una lista
personalizada de acuerdo a los errores que comete. Tambin necesita
una clasificacin de defectos, por lo que usar la que propone el PSP.
7. COMPILACIN

Luego se procede a la compilacin del cdigo, se registra cada

defecto en el cuaderno de defectos y en la tabla de anlisis de
errores y el tiempo dedicado tambin en el cuaderno de registro de
tiempos.
8. Pruebas

El Ing. X llego a la parte de las pruebas, donde cada modulo se

probar con distintos valores, y se registrar en el reporte de pruebas
que sugiere PSP. Para este caso solo se probar para las primeras 3
funciones, se probara que la funcin insertar adicione datos a la Base
De Datos correctamente, y que la modificacin y la eliminacin sean
exitosas.
10. Resultados

Analizando los resultados vemos que el Ing. X logro terminar el

desarrollo del proyecto el 11 de mayo, mientras que en el diagrama
de Gantt haba estimado el desarrollo hasta antes del 3 de mayo, por
lo que tuvo un retraso de algo ms de una semana. Para el Ing. X, tal
vez este retraso no significa mucho, pero no sucede lo mismo en
proyectos grandes donde implique ms 10000 LOC, donde los errores
de etapas superiores provocan efectos domin.

En cuanto al Rendimiento que dio el resultado de 55.6%, advierte que

aun estamos eliminando pocos errores en las revisiones, por lo que
significa mas tiempo en las pruebas. Se debe apuntar como objetivo
obtener arriba del 75%.

Sobre el valor de Valoracin/Fallo de 0.52 indican que estamos

gastando mucho tiempo en las pruebas y compilacin, por lo que
debemos mejorar nuestra forma de eliminar defectos en las
revisiones. Se recomienda llegar a valores de V/F superiores a 2.

El tiempo por fase nos indica el porcentaje que requerimos para cada
fase dado un tiempo total de desarrollo. De igual manera los defectos
Introducidos y Eliminados indican el porcentaje de defectos que se
introduce y elimina en ciertas fases del desarrollo, estos datos son
tiles para nuevas estimaciones.

9. PostMortem

Hasta aqu X habra completado el software. Lo nico que falta es la

fase de PostMorten, que corresponde al completado del Resumen del
plan del proyecto con los valores reales. Debemos registrar un tiempo
de postmorten estimado en el cuaderno de registro de tiempos
11. Historiales

Estimacin de LOC Nuevas y cambiadas. X puede empezar a llenar las

tablas de Tamao de Programas para tener un historial y sirva para
prximas estimaciones por comparacin

RESUMEN SEMANAL DE ACTIVIDADES

A partir del cuaderno de registro de tiempos de las ltimas semanas,

el Ing. X puede obtener un Resumen Semanal de Actividades que le
permitir conocer el tiempo que necesita en una semana para llevar
a cabo actividades de programacin. En caso de tener otras
actividades, como por ejemplo pasar clases de actualizacin por las
maanas, el Ing. deber registrarlo en esta tabla. As se ir
obteniendo distintos resmenes semanales, tendr uno cuando
programa y pasa clases, otro cuando solo programa, etc. De esta
manera, antes de obtener un nuevo compromiso, X analizar el tipo
de semanas que vienen, y en base a criterio aceptar o rechazar. A
continuacin veamos como X obtiene un resumen semanal a partir del
cuaderno de registro de tiempos.

12. Estimacion de Nuevos Proyectos

Ahora para cualquier otro pedido de software X, ya contara con datos

reales que registr en sus anteriores Resmenes del Plan,
permitiendo que el nuevo Resumen Del Plan del proyecto se pueda
iniciar correctamente. A continuacin veamos como completar una
nueva estimacin a partir del ltimo Resumen:
X supone que las LOC Nuevas y cambiadas Estimadas = 400

A partir de aqu comienza nuevamente todo el proceso anteriormente

descrito, el cual bsicamente nos permitir empezar a adoptar el PSP,
recordando que las practicas mencionadas aqu se profundizan en el
libro de Watts Humphrey: A Discipline for software Engineering y
para aplicarlas se deben manejar las practicas que se presentan en
este tutorial gua.

Conclusiones
Bastante bueno la verdad creo que me hace falta practicarlo mas y
sobre la codificacin hace falta mas tiempo para poder hacerla puff
es largo pero muy interesante esta forma de trabajar

REFERENCIAS
http://www.ptolomeo.unam.mx:8080/xmlui/bitstream/handle/132.248.52.100/3532/I
nforme.pdf?sequence=1

HUMPHREY, Watts S.
Introduction to the Personal Software Process.
1st Edition, Addison-Wesley Professional, Reading, M.A. 1996.

HUMPHREY, Watts S.

PSP, A self-Improvement Process for Software Engineers.

1st Edition, Addison-Wesley Professional. SEI Series in Software Engineering.

2005.

MINTER, Dave.

Beginning Spring 2: From Novice to Professional (Beginning: From Novice to

Professional).

1st Edition, Apress. 2007.

BAUER, Christian; KING, Gavin.

Java Persistence with Hibernate.

Revised Edition, Manning Publications. 2006.

GONCALVES, Antonio.

Beginning Java EE 6 with GlassFish 3 (Expert's Voice in Java Technology).

2nd Edition, Apress. 2010.

NIXON, Robert.

Learning PHP, MySQL, and JavaScript: A Step-By-Step Guide to Creating

Dynamic Websites (Animal Guide).

1st Edition, OReilly Media, Inc. 2009.

Team Software Process. Overview. Software Engineering Institute. Carnegie

Mellon.

http://www.sei.cmu.edu/tsp

Consulta 20 de marzo de 2012.

PSP Personal Software Process. Cuerpo Acadmico de Tecnologas de

Aprendizaje e Ingeniera de Software. Centro de Ciencias Bsicas, Universidad

Autnoma de Aguascalientes.

http://ingsw.ccbas.uaa.mx/sitio/images/material/psp.htm

Consulta 20 de marzo de 2012.

Spring Framework. SpringSource Community.

http://www.springsource.org

Consulta 20 de marzo de 2012.

43

Reporte de experiencia profesional

PrimeFaces. Prime Technology.

http://primefaces.org

Consulta 20 de marzo de 2012.

JBoss Application Server. JBoss Community.

http://www.jboss.org
Consulta 27 de abril de 2012.

Hibernate. JBoss Community.

http://www.hibernate.org

Consulta 27 de abril de 2012.

Buenas Prcticas de Gestin de Versiones con Subversion. Tecsisa.

http://blogs.tecsisa.com/articulos-tecnicos/buenas-practicas-de-gestion-de-

versiones-con-subversion

Consulta 14 de mayo de 2012.

Productos UModel. Diagramas de perfil UML. Altova.

http://www.altova.com/es/umodel/profile-diagrams.html

Consulta 20 de noviembre de 2012.

The Java Language Environment. Design Goals of the Java TM Programming

Language. Sun Microsystems, Inc.

http://proceso-software-personal.blogspot.mx

http://www.oracle.com/technetwork/java/intro-141325.html