Categorias del blog

El blog ha ido creciendo, y es momento de hacer una division mas adecuada de las entradas del blog y he decidido hacer un acopio de las categorias que tendra este blog

1.- Analisis previo del proyecto
Aqui pondre las entradas referentes al analisis previo de un proyecto, en este caso mi microerp
entre otras, no hay aqui diagramas especificos que presentar al cliente, son diagramas generales
aqui deberian ir entradas sobre analisis de riesgos, alcance del proyecto etc, en la metodologia agil seria el llamado Sprint 0, tambien hay planificacion

2.- Analisis y del sistema
Aqui irian diagramas generales y mas especificos de los modulos, seria mas interno y no tan de cara al cliente, una planificacion mas detallada y no tan global, ademas de detalles sobre la informacion, se plantea tambien las tablas que llevaria la base de datos

3.-Diseño del sistema
Diagramas mas detallados del sistema y con mas enfasis en la posterior codificacion, se crean
igualmente diagramas Entidad-Relacion para las tablas de la base de datos que llevarian la informacion del cliente, se hacen tambien modelos de formularios

4.-Codificacion
En parte es diseño , por la naturaleza de los IDE de desarrollo actuales que pegan la fase de diseño de formularios con la codificacion, incluso algunos son capaces de interpretar diagramas UML , igualmente con los manejadores de bases de datos que ahora son capaces de interpretar un diagrama Entidad relacion, una enorme parte del codigo es desarrollada por estos IDEs, por lo que la codificacion seria en la parte de inteligencia del negocio

5.-Testeo
Igualmente , la fase de testeo va muy pegada a los IDEs que compilan y se pueden hacer inmediatas pruebas de lo que se va haciendo, sin embargo en esta fase se plantea un diseño sistematico de pruebas, un registro de los exitos y fracasos de estas pruebas por un equipo
que se dedica en exclusivo a eso e incluso pruebas hechas por el mismo cliente o personas asignadas por el cliente

6.-Implementacion
Aqui ya se instala en el sitio del cliente el sistema, servidores de base de datos, binarios de los modulos del sistema, registro de usuarios que usaran el sistema, aqui se entrena al personal de la empresa del cliente para que vaya introduciendo datos y puede irle siendo util al cliente el sistema, en la metodologia agil puede suponerse que habra varias implementaciones en tanto se vayan liberando modulos del sistema

Estas definiciones son personales, no tanto formales, aunque son parecidas a las que vienen en
los diversos libros de ingenieria de software, las modifique en cuanto a que esas definiciones no toman en cuenta en mi opinion la versatilidad de los IDEs de desarrollo existentes y pareciera que aun piensan que uno debe diseñar y codificar desde cero los formularios

Ademas de que ninguna hace mencion del constante traslape entre las etapas e incluso la posible redundancia de los diagramas entre las fases, sobre todo entre los diagramas de analisis y diseño que pareciera en mi opinion ser los mismos

Categorias Adicionales como guias cortas de lazarus, mysql, etc

Habra una seccion de opiniones personales, donde comentare acerca de lo que pienso sobre el modelado y diseño de software

Y una seccion de archivos, donde colocare algunos de los archivos de ejemplos y los archivos del ERP, posiblemente haga una entrada en sourceforge para el proyecto, eventualmente pondre los archivos en mi hosting

Los estandares de diseño y codificacion - un capitulo olvidado

Un capitulo del desarrollo que he descuidado es la eleccion de estandares para el diseño y posterior codificacion, hare una breve descripcion de los estandares que tratare de no descuidar y que en si ya estoy aplicando

Nombres de las clases
-inician con mayuscula
-las clases en lazarus (y en delphi y CBuilder) llevan el estandar de una T mayuscula al principio (y asi se quedara)
-los formularios llevan despues de la T una F (ejem TFCliente)
-El concepto del objeto tambien lleva mayuscula (ejem TFCatalogo)
-las clases principales del modulo llevaran un Sis al principio (ejem SisCliente)
-las clases que tengan que ver con bases de datos iniciaran con BD
-las clases que tengan que ver con tablas de la base de datos llevaran una T despues de BD y el nombre de la tabla debera tambien comenzar con mayuscula (BDTCliente)

Funciones de las clases
-iran en minuscula a menos que pertenezcan a la clase principal del modulo (estas comienzan en mayuscula ejem. SisCliente->Alta() )

Instancias de clases (los objetos)
-inician con una o en minuscula y luego el nombre de la clase al que pertenecen

los nombres de las variables
-tambien iran en minuscula y se tratara de que enuncien el concepto de lo que son

por el momento este sera el estandar
de ser necesario sera ampliado

Orden del DIA para el proyecto ERP

Orden del dia
Hoy jueves comenzaremos dando un repaso de lo que tenemos, como bien he escrito hice un breve analisis del proyecto, elegi la plataforma de desarrollo, hice un analisis por medio de diagramas DFD , y divide el proyecto en una serie de modulos, del cual elegi uno para comenzar, de este comenze hacer el diseño con diagramas de clases y de secuencia

queda por hacer unos diagramas mas, diagramas de actividades y tal vez alguno de implementacion, no quiero sobrecargar este pequeño proyecto con cientos de diagramas

mi objetivo es terminar el modulo mañana viernes, con formularios y conexiones a bases de datos, pero tenemos un atraso debido a la elaboracion de diagramas

Creando el modulo Clientes

La agenda del proyecto

No quiero aburrirlos con la agenda del proyecto , con los roles que debiera tener cada desarrollador , etc. ademas este ERP esta hecho por una sola persona o sea yo, ademas seria de interes que ustedes vieran cual es el tiempo que se tarda el desarrollo, la fase anterior que pudiera hacerse en un sprint 0 si adoptaramos una metodologia agil y tuvieramos un desarrollo mas grande que el que planteo, fuera mas formal y todo quedara meticulosamente por escrito pudiera tardarse una o dos semanas, aqui un solo dia debido al tamaño de nuestro proyecto y que nosotros definimos todo el alcance, nos tardamos a lo mucho un dia, ahora comenzamos ya el desarrollo completo de un modelo y adoptando la filosofia agil nos comprometemos a desarrollar solo ese modulo

Analisis del Modulo de clientes

historias de usuario
Partiendo de historias de usuario muy simples como

1.- Un usuario puede registrar un cliente
2.- Un usuario puede modificar los datos de un cliente
3.- Un usuario puede dar de baja a un cliente
4.- Un usuario puede consultar los datos de un cliente
5.- Un usuario puede consultar la lista de clientes

podemos suponer que estas mismas historias se pueden poner en notacion de casos de uso sin embargo esto nos llevaria mas tiempo

Diagrama DFD

Haremos otro diagrama DFD solo para este modulo, seria el nivel 2 , siendo formales pero solo nos concentraremos en la parte de las opciones del modulo cliente, como si le acercaramos una lupa al DFD, usaremos nuevamente el software DIA para elaborar nuestro diagrama



Gracias a este sencillo diagramas podemos suponer la cantidad de formularios necesaria, las opciones para un hipotetico menu de subsistema cliente y que es lo que pudiera imprimirse en este modulo, y los datos que utilzaria

gracias a esto podemos suponer una tabla TCliente , una clase TSistCliente, y mas o menos suponiendo que cada proceso del DFD pudiera requerir un formulario, aproximadamente cinco formularios (con una clase para cada formulario)

lo que haremos en la fase posterior de diseño conceptual