Procedimiento de Desarrollo de Software

Procedimiento Desarrollo de SoftwareRevisin 1.0

Procedimiento de Desarrollo de SoftwareInstructivo interno

03/06/2013DINGS S.A. Claudio Rojas N.Revisin 1.0

Procedimiento Desarrollo de SoftwareRequerimientosI. Para la toma de requerimientos, se debe tener una entrevista inicial con el cliente con el fin de obtener generalidades sobre la necesidad que solicitan solucionar, en base a esta informacin se crea el Informe de requerimiento inicial.II. Se realizan reuniones idealmente con todas las personas involucradas con el proyecto, a los cuales se les realiza una entrevista en modo de encuesta, en base a esta y a base de entrevistas personales con cada implicado, se genera el informe de requerimiento unitario, que se diferencia con el anterior debido a la cantidad de detalles que informe el entrevistado adems de sus datos personales (nombre y cargo en la organizacin).III. Si es posible, se debe realizar una verificacin de los procesos actuales en terreno, cumpliendo el ciclo operativo. En base a esto se genera el informe de Procesos, el cual ser relevante para el diseo del software. Cabe mencionar que esta etapa depende de la informacin de los puntos anteriores, operando como punto de comprobacin.IV. Generacin de los Documentos de Productos o Backlog, el cual contiene un requerimiento especfico de cada versin del Software. FactibilidadI. En base a la informacin recopilada, se deben evaluar cada Informe de modo de estructurar y priorizar las fases, duracin y asignacin de recursos al proyecto. II. Una vez elegidos los requerimientos importantes, se deben seleccionar los respectivos Backlogs de estos evaluando si es posible realizarlos, si es as, se debe costear lo que implica su realizacin (mano de obra en horas, energa elctrica, internet, arriendos, etc.), en caso contrario incluir en los costos de lo que se necesitara adems para realizarlos, si aun as no es posible realizar, se desecha.III. En base a los puntos anteriores se debe crear un informe de factibilidad tcnica de que se necesita tener para implementar el sistema.IV. En base al clculo de los costos de cada Backlog, se deben totalizar y crear la cotizacin respectiva para el cliente, cabe mencionar que se debe incluir el costo hundido (lo que se ha ocupado en recursos para realizar dicha cotizacin) adems que se debe especificar el nmero de versin del software a realizar (siempre pensando en futuras versiones).DiseoI. En base a los Informes anteriores se deber generar inicialmente un diagrama de flujo de procesos DFD, con el fin de organizar, estructurar y simplificar el modelo de la solucin elegidaII. Con la creacin del DFD se puede definir el diagrama de la Base de datos a utilizar, este se tendr que diagramar utilizando MER.III. En el diagrama anterior se deben considerar Vistas y Procedimientos AlmacenadosIV. Obtenido el MER se procede a crear el Diagrama de Clases, el que ser la base del Sistema a desarrollar.

CodificacinI. En bases al diagrama de clases, estas se priorizan en base a su implicacin o relacin con las demsII. Las clases se estructuran de la siguiente forma:a. Se denominan con la entidad que representan en pluralb. Se deben agrupar en regiones las Propiedades, Mtodos, Mtodos Estticos y Constructor. A este ltimo se agregan las variables internas de la clase.c. Los mtodos bsicos deben ser : Add(Agregar), Edit(Editar), Delete(Eliminar) los cuales deben devolver como valor un bool o una instancia de la clase Comunes.Erroresd. Los mtodos estticos bsicos deben ser: Listar(un List que devolver un List con todos los registros de la tabla formateados como clase) y Seleccionar(devolver una instancia de la misma clase, esta se usa comnmente para instanciar la clase en base a la llave primaria de la entidad).III. Al terminar cada clase o durante su construccin, se debe actualizar su nmero de versin, adems se debe documentar su funcionamiento y sintaxis, esto se realiza colocando comentarios en el cdigo fuente (en vs se realiza colocando /// una lnea antes de cada variable, propiedad o mtodo).IV. Los formularios deben implementar las clases haciendo uso de sus propiedades y mtodos para conectarse a las bases de datos, lo ideal es que jams se realicen consultas a la base de datos directamente desde el formulario.V. La informacin a desplegar de un informe, debe proceder de una vista o el filtro de esta, por motivos de agilidad del sistema, es recomendable este mtodo. (por procedimiento almacenado tambin se recomienda)VI. Cada clase, formulario o informe se considerar un componente del Software, el cual deber contemplar un nmero de Versin y fecha de liberacin.TestI. Al terminar una clase o un formulario, se debe testear inmediatamente, para esto se debe crear el informe de testing, este informe deber incluir los distintos casos de error que puedan existir para este componente, debido a que reducira inmensamente el trabajo en su implementacin.II. Cada testing debe identificarse con el nmero de versin del componente ms el nmero de revisin.III. En caso de tener el 80% del componente no operativo, se debe crear un nuevo requerimiento (Backlog) y seguir los siguientes pasos:a. Evaluar su factibilidad tcnicab. Evaluar las modificaciones de los modelos realizadosc. Codificar nuevamente cambiando de versin el componente

Puesta en MarchaI. Al terminar cada versin del Software, esta debe ser implementada y explicada al cliente, esto implica realizar una pequea capacitacin de las nuevas funcionalidades de la versin del software entregada (en caso de haber versiones anteriores, solo se explica los cambios).II. Cada capacitacin se debe registrar en un libro de clases el cual incluya la fecha, horas involucradas, personal instruido y temas abordados. Este documento debe ser firmado tanto por los participantes como el encargado de proyecto de parte del cliente.III. El sistema debe ser implementado completamente en las dependencias del cliente o donde este estime conveniente, obviamente cumpliendo con lo exigido en el informe de factibilidadIV. En el transcurso de la puesta en marcha, se deber dar soporte a las consultas del cliente por dos semanas como mximo, esto en base a la marcha blanca que el cliente debe realizar.MantencinI. En caso de solicitud de nuevas mejoras, se debe realizar un nuevo Backlog y seguir el procedimiento descrito en el punto III del Test.II. En caso de cambio de plataforma, se debe considerar como un producto nuevo y realizar todos los pasos de este informe.DocumentacinI. Cada componente debe documentarse en base a su sintaxis directamente en el cdigo fuenteII. En el caso de los Formularios y Reportes, estos deben documentarse con formato de manual de usuario por separado, de modo de poder mezclarlos en caso de reutilizacin de componentes en diversos proyectos.III. Al cliente se le debe entregar solo la documentacin relacionada con la operatibilidad del sistema, las dems documentaciones son de carcter interno las cuales estarn con prioridad baja durante la ejecucin del proyecto, esto no significa que no se realice.FinalizacinEn esta etapa se debe realizar la entrega del CD con el instalador del Sistema y la documentacin funcional al Cliente, posterior a esto, el cliente debe firmar la carta de cierre del proyecto, en caso de solicitar mejoras, se debe realizar el cierre y posteriormente evaluar las mejoras.

ApendiceFormato de Informes del ProyectoInforme de Requerimiento Inicial

Entrevista

Informe de Requerimiento Unitario

Informe de Procesos

Backlog de Producto

Nomenclatura recomendada de Controles VS.Formularios: Frm_[Tabla|Vista en plural], Ej: Frm_ProductosTextbox: Txt_[Campo], Ej: Txt_UsuarioRichTextBox: Rxt_[Campo], Ej: Rxt_UsuarioNumberUpDown: Nud_[Campo], Ej: Nud_EdadDatepicker: Dt_[Campo], Ej: Dt_FechaCheckbox: Ck_[Campo], Ej: Ck_EsValorRadio Button: Rb_[Opcion], Ej: Rb_Femenino, Rb_MasculinoCombobox: Cmb_[Tabla|Vista en singular], Ej: Cmb_ProductoDatagrid: Dtg_[Tabla|Vista en plural], Ej: Dtg_ProductosListview: Lv_[Tabla|Vista en plural], Ej: Lv_ProductosSelectores: Sel_[Tabla|Vista en singular], Ej: Sel_Producto