MT 02 Desarrollo Standard Software

DESARROLLO DE SOFTWARE ET-003
01/05/2019
ESTANDARES DE DESARROLLO 1/22
REVISIÓN 4
CUADRO DE REVISIONES
Nro. de
Fecha Motivo cambio Elaborado Aprobado
Revisión
1 01/04/2019 Mejora de nomenclatura de Desarrollo ITEL
tablas
2 01/04/2019 Implementación de la norma Desarrollo ITEL
ISO/IEC 17799
3 01/04/2019 Recomendaciones del Desarrollo ITEL
Análisis de Brechas del
ISO/IEC 17799
4 02/04/2019 Implementación del Acuerdo Desarrollo ITEL
Nº 07 del Comité de Calidad
Nº 009-2009 (Adecuación
referida a la denominación
del área, Nomenclatura de
Funciones e inclusión del
prefijo de un nuevo control)
5 02/04/2019 Reglas de Programación en Desarrollo ITEL
Transact - SQL
ESTANDARES DE DESARROLLO
01/05/2019
REVISIÓN 4
1. OBJETIVO .................................................................................................... 3
2. ALCANCE ..................................................................................................... 3
3. DIRECTORIOS Y ARCHIVOS ...................................................................... 3
4. CRONOGRAMA DEL PROYECTO .............................................................. 3
5. ESTANDAR DE CONFIGURACION DE BASE DE DATOS ......................... 4
6. OBJETOS DE LA BASE DE DATOS ............................................................ 5
Normas generales de nomenclatura......................................................... 5
Nomenclatura de Base de Datos .............................................................. 5
Nomenclatura de Tablas .......................................................................... 5
Nomenclatura de Parametros ................................................................... 6
Nomenclatura de Constraints ................................................................... 6
Nomenclatura de Índices .......................................................................... 7
Nomenclatura de Vistas ........................................................................... 7
Nomenclatura de Reglas (RULES) ........................................................... 7
Nomenclatura de Defaults ........................................................................ 7
Nomenclatura de Stored Procedures ....................................................... 8
Nomenclatura de Triggers ........................................................................ 8
Nomenclatura de tipos de dato definidos por el usuario ........................... 9
NOMENCLATURA DE FUNCIONES .................................................................. 9
Reglas de Programacion Transact-SQL ................................................... 9
Mantenimiento de objetos de base de datos .......................................... 11
7. SEGURIDAD DE ACCESOS ...................................................................... 12
APLICACIONES VISUALES – SQL SERVER ........................................ 12
8. PISTAS DE AUDITORÍA ............................................................................. 12
APLICACIONES VISUALES – NIVEL APLICACION.............................. 13
APLICACIONES VISUALES – SQL SERVER ........................................ 13
Estructura del Tabla OPE_AUDITOR ..................................................... 13
9. PROGRAMAS EN VISUAL BASIC .NET .................................................... 14
Programas…. ......................................................................................... 14
Variables….. ........................................................................................... 14
Controles…. ........................................................................................... 15
Procedimientos y Funciones .................................................................. 18
Reportes….. ........................................................................................... 18
10. CONTROL DE DATOS EN LAS APLICACIONES ...................................... 18
Controles de Entrada/Origen .................................................................. 18
Procesamiento, validación y edición....................................................... 20
Controles de salida ................................................................................. 21
11. DOCUMENTACIÓN DE LOS SISTEMAS ................................................... 21
Diccionario de datos ............................................................................... 22
01/05/2019
REVISIÓN 4
1. OBJETIVO
Este documento tiene por objetivo establecer los estándares que se emplearán en la
programación y documentación de aplicaciones desarrolladas en la Empresa
BELEGOST S.A.
2. ALCANCE
Aplicaciones desarrolladas por la Oficina de Informática de BELEGOST S.A., a partir

de la fecha de aprobación del presente estándar.
3. DIRECTORIOS Y ARCHIVOS
 Los archivos que conforman los proyectos de desarrollo se almacenarán en un

directorio cuyo nombre será el número de solicitud que lo generó y una breve
descripción. Este directorio estará en el servidor asignado.
TipoSolicitud-Número solicitud-Descripcion
Donde:
TipoSolicitud: SN=Solicitud nuevo sistema, SM=Solicitud mantenimiento
Ejemplo:
SM-067-2011 Matrícula
 Los script de la base de datos de los pases a producción serán almacenados por
el DBA y nombrados de acuerdo a lo siguiente:
TipoSolicitud-Número solicitud-Descripcion
Donde:
Ejemplo:
SM-067-2011 Matricula.sql
4. CRONOGRAMA DEL PROYECTO
Los nuevos sistemas y mantenimientos mayores tendrán un cronograma asociado, el

mismo que se almacenará en el directorio de red asignado al seguimiento de
proyectos, con el siguiente nombre:
TipoSolicitud-Número solicitud- Descripcion
Donde:
01/05/2019
REVISIÓN 4
Ejemplo:
SM-067-2011 Matricula.mpp
Este cronograma se creará de acuerdo con el archivo PlantillaProyectos.mpp,

modificado a propuesta del desarrollador según corresponda a cada trabajo
encomendado.
5. ESTANDAR DE CONFIGURACION DE BASE DE DATOS
Los Character ó Code Page son grupos de letras, dígitos y símbolos utilizados por el
motor de base de datos para representar la información, cada Character Set
comprende 256 caracteres divididos en 2 grupos, los primeros 128 son los mismos
para todos los Character Set, estos son los caracteres más comunes. Los 128
caracteres restantes que conforman el segundo grupo, son conocidos como
caracteres extendidos los cuales difieren de Set a Set. En este grupo se encuentran
los caracteres especiales y los símbolos utilizados por los distintos idiomas y se
serán más convenientes o una u otra región del mundo.
El Code page 1252 (ISO carácter set) es el default para Microsoft, es también
conocido como el ISO 8859-1, Latín 1 ó ANSI Character Set. Este es compatible con
los caracteres ANSI usados por todos los sistemas operativos Windows. Este código
de pagina es el apropiado si los clientes son sistemas Operativos Windows (NT,
2000, XP, 95, 98).
Microsoft recomienda el uso de ISO 8859-1(default) para evitar los problemas de
conversión de caracteres en los sistemas y porque este contiene los caracteres
adecuados para manejar la mayor parte de idiomas que comprende América y la
parte Oeste de Europa, incluso haciendo uso, de ser necesario, de tipos Unicode en
algunos campos tales como nchar, nvarchar y ntext.
El Dictionary Order, Case Insensitive es el default y el más adecuado para la mayor
parte de instalaciones, tomando en cuenta que permite comparaciones y
ordenamiento basado en la forma natural como lo haría cualquier persona para
comparar por ejemplo:
Ana = ana ó en cuanto a orden Ana, ana, Aparicio, etc.
El Binary Order no es el más adecuado para la mayoría de sistemas debido a que la
comparación y ordenamiento está basado en los valores numéricos de los caracteres
y no en el orden natural de los mismos
Character Set: ISO 8859-1 Latin ó ANSI Character Set
Sort Order: Dictionary Order, Case Insensitive.
Nota: Se debe tener en cuenta esta configuración durante la instalación en un
servidor.
01/05/2019
REVISIÓN 4
6. OBJETOS DE LA BASE DE DATOS
Normas generales de nomenclatura

El tamaño de los identificadores varía desde 1 hasta 30 caracteres, incluyendo letras,
símbolos y números. Los identificadores deben cumplir los siguientes requisitos:
 El primer carácter del identificador debe ser una letra o uno de los siguientes
símbolos: @, #. Los símbolos @ y # tienen un significado especial :
 Un identificador comenzando con @ representa a una variable local.
 Un identificador comenzando con # representa el nombre de un objeto
temporal. En caso de una tabla o stored procedure, el símbolo # representa a
un objeto temporal local.
 Los objetos temporales globales representan con los símbolos (##). Los nombres
de los objetos temporales no deben exceder los 13 caracteres, incluyendo al # o
##, debido a que SQL Server les agrega un sufijo numérico interno.
 Los caracteres posteriores al primer carácter pueden incluir letras, dígitos o los
símbolos #, $ o _.
 No se aceptan espacios en blanco en medio de los identificadores.
 La primera letra de todos los nombres de los objetos de la base de datos debe
escribirse en mayúsculas y cuando el nombre contenga más de una palabra, la
primera letra de ésta se escribirá también con mayúsculas.
Nomenclatura de Base de Datos

Las bases de datos se denominarán con una palabra que describa su contenido,
debe ser relacionada con la Aplicación
Prefijo NombreBaseDatos= AliasAplicacion_SufijoBaseDatos

Ejemplo La aplicación administradora del sistema académico tiene
como alias: SYSA, por lo cual, los nombres físicos
correspondientes son:
Archivo MDF : SYSA_UNJBG _Data
Archivo LDF : SYSA_UNJBG _Log
Comentarios El nombre físico de la base de datos debe corresponder al
alias de la aplicación.
Nomenclatura de Tablas
Prefijo NombreTabla= NemónicoSistemaProyecto_NombreTabla
Comentarios  Las tablas se nombrarán en singular

 El nombre debe ser lo más descriptivo posible, colocando
al final del mismo la descripción complementaria que
indique si es un detalle, tabla de control, histórica, de
auditoría, entre otros.
 El nombre de la tabla de ser descriptivo, en singular y
combinando mayúscula y minúsculas bajo el estilo
CamelCase.
01/05/2019
REVISIÓN 4
 El nombre de la tabla debe identificar claramente a la

entidad del sistema con un nombre completo.
 Una Tabla hija debe llevar el nombre de la tabla padre
hasta un máximo de un nivel.
 El nombre de la tabla debe comenzar con el prefijo de tres
letras nemónico SEC relacionado al concepto de System
Entity Class.
 El nemónico del sistema/proyecto es de tres caracteres y
será determinado por la aplicación que inserta, modifica o
elimina datos de la tabla. Cuando exista más de una
aplicación que inserte, modifique o elimine datos, se
colocará el prefijo GEN (General).
 Las tablas deberán llevar campos de auditoría, tales como
el usuario creador, fecha creación, usuario modificador,
fecha de modificación.
 Los campos identificadores de las tablas utilizar el prefijo
ID.
 Existen tablas de auditoría, las cuales se describen en la
sección Pistas de Auditoría.
Ejemplo CAJ_Ingreso
Antes Ahora
Matricula MAT_Matricula
Registro DOC_Registro
PlanIndividual PIT_PlanIndividual
Acta ACT_Acta
Materia ADS_Materia
Alumno OPE_Entidad
Notas Cuando se creen tabla temporales añadir el sufijo Temp para
reconocerlas.
(SAV_Producto_Temp)
En el caso de sistemas grandes como el de Operaciones, se
usará un solo prefijo para todo el sistema.
Nomenclatura de Parametros
Prefijo NombreParametroCampo= MuyDescriptivos
Ejemplo La Tabla Personal por lo cual tiene los siguientes campos:
IdPersonal
ApellidoPaterno
Comentarios Los nombres de los campos deben ser descriptivos.
Se deben usar mayúsculas y minúsculas para diferenciar los
grupos de identificación en el nombre (CamelCase).
Nomenclatura de Constraints
Prefijo PK: pk_NombreTabla

FK:fk_NombreTablaOrigen_NombreTablaReferenciada
01/05/2019
REVISIÓN 4
Unique: uq_NemónicoTabla_NombreUnique
Default: df_NemónicoTabla_NombreColumna
Check: ch_NemonicoTabla_NombreCheck
Ejemplo PK_Acta
FK_ActaFichaDetalle
UN_Entidad_ApellidosNombre
DF_Entidad_SedeOficina
CH_Entidad_Telefono
Nomenclatura de Índices
Prefijo Cluster: IC_ NombreTabla_NombreIndice

Ejemplo No Cluster: ID_ NombreTabla_NombreIndice
Comentarios Usar esta nomenclatura para índices que no dependen de un
constraint.
Nomenclatura de Vistas
Prefijo NemónicoAplicativo_VW_NombreVista
Ejemplo ADS_VW_Especialidad
Comentarios Ninguno
Nomenclatura de Reglas (RULES)
Prefijo RU_NombreRule
Ejemplo RU_CodigoCliente
Comentarios Usar reglas sólo para tipos de dato definidos por el usuario. En
caso de columnas usar CHECKS.
Nomenclatura de Defaults
Prefijo DF_Nombre_Default
Ejemplo DF_FechaSistema
Comentarios Usar DEFAULT (Procedural) solo para tipos de dato definidos
por el usuario. En caso de columnas usar DEFAULT
(Declarativo).
01/05/2019
REVISIÓN 4
Nomenclatura de Stored Procedures
Prefijo PrefijoMódulo_Accion_Nombre del Stored procedure_Tipo

Donde:
Acción:
I : Insert
U : Update
D : Delete
L : Delete Logico
S: Select
XS: Select complejo
X : Extendido
Nombre del Stored procedure:

Es el nombre de la Tabla sin el Prefijo del Módulo, solo en el
caso de que implique una acción de Update y Delete se
agregara las columnas en el nombre del Stord Procedure.
(Personal_Apellidos)
Tipo
Sólo en el caso de que el Stored Procedure devuelva datos
como parámetros OUTPUT, se pondrá al final el sufijo _OUT
@NombreParametro
Donde:
Parámetros
Los parámetros deben estar bajo el estilo CamelCase.
Los parámetros de los Stored Procedures tendrán el mismo
nombre de los campos, precedidos por un símbolo “@”
(@IdPersonal)
Ejemplo MAT_I_Matricula
MAT_U_Ficha
MAT_D_FichaDetalle
OPE_U_Entidad_Apellidos
OPE_U_Entidad_Estado
Comentarios En el caso de consultas, se debe usar SET NOCOUNT ON al
inicio, para evitar que devuelva la cantidad de registros
procesados.
Nomenclatura de Triggers
01/05/2019
REVISIÓN 4
Prefijo TR_Nombre de la tabla_Tipo de trigger
Donde:
Tipo de trigger:
I : Insert
U: Update
D: Delete
Ejemplo TR_UsuarioPotencial_I Trigger para inserción
TR_Nandina_IU Trigger para inserción y
Actualización
Comentarios Si el trigger hace más de una cosa, se pondrá IU, ID, UD, o las
respectivas combinaciones.
Nomenclatura de tipos de dato definidos por el usuario
Prefijo DT_NombreTipoDato
Ejemplo DT_FechaNacimiento
DT_RUC
Comentarios N/A
Nomenclatura de Funciones
PREFIJO FUN_NOMBREFUNCION
EJEMPLO FUN_TELEFONOPERSONA
COMENTARIOS N/A
Reglas de Programacion Transact-SQL
Stored Procedured
 Los nombres de los Stored procedures NO deben comenzar con SP_, esto
porque generalmente el SQL piensa que son system procedures y los busca
primero en la base de datos master.
 SET NOCOUNT ON elimina la notificación del nro. De registros afectados por
cada sentencia SQL lo cual incrementa el performance y en algunos casos
impide que funcione el DTS.
 Obligatoriamente todos los sistemas a desarrollarse deberán invocar
STORED PROCEDURES.
 No se deberán poner sentencias SQL en el cliente. Esto genera una gran baja
en la performance de los sistemas.
 En ningún caso el desarrollador podrá forzar el uso de un índice dentro de un
STORED PROCEDURE y tampoco deberá colocar sentencias que alteren el
comportamiento de los bloqueos.
 En el caso de los STORED PROCEDURES que son exclusivamente para
mostrar información se deberán evitar usar lógicas como la siguiente:
CREATE PROCEDURE MAT_S_Matricula
01/05/2019
REVISIÓN 4
(
@X smallint,
@Y varchar(15)
)
AS
BEGIN
SET NOCOUNT ON;
IF @X=1
SELECT * FROM Matricula
ELSE
SELECT * FROM Matricula WHERE IdMatricula=@Y
END
GO
 No es óptimo crear STORED PROCEDURES de ese tipo dado que el SQL

guarda una estadística de ejecución cada vez que se use un procedimiento,
esto quiere decir, que si la primera vez se le paso el parámetro @X=1, el SQL
no empleara índices para el SELECT, si se le pasa el @X=2 en el cual deberá
leer un código en particular el SQL tampoco usara índices debido a las
estadísticas guardadas en la ejecución anterior.
 En caso sea necesario trabajar con este tipo de STORED PROCEDURES,
deben ser creados de la siguiente forma:
CREATE PROCEDURE PEC_S_OficinasUsuario

(
@X smallint,
@Y varchar(15)
)
WITH RECOMPILE
AS
BEGIN
SET NOCOUNT ON;
IF @X=1
SELECT * FROM OficinasUsuario
ELSE
SELECT * FROM OficinasUsuario WHERE IdOficinasUsuario=@Y
END
GO
Reglas Generales
 Todo Aplicativo deberá evitar usar cursores definidos en SQLServer, dado
que estos consumen muchos recursos.
 En la mayoría de los casos que pueden transformar los cursores a Transact-
SQL.
 Las vistas deberán ser utilizadas para simplificar los queries.
 En ningún caso se otorgaran permisos sobre columnas, por lo tanto se deberá
crear una vista para que se le otorgue permiso SELECT a toda la vista
 Se deberán optimizar el uso de los Datatypes.
 Palabras del lenguaje SQL y funciones de Sistemas en MAYUSCULAS,

columnas y otras variables en mayúsculas.
 Sentencias legibles e indentadas (cada clausula SQL en una línea nueva)
01/05/2019
REVISIÓN 4
 Utilizar el tabulador para separar los campos de una condición (en la medida
de lo posible)
 Indentar el Código para conservar un orden.
Programación Transact – SQL

Stored Procedured
Vistas
Triggers
Query
Mantenimiento de objetos de base de datos

Al crear o efectuar mantenimiento a cualquier objeto de base de datos se deberá
crear un script con las sentencias correspondientes, documentándolo de la siguiente
manera:
-- DESCRIPCION: Muestra las oficinas a las cuales tiene acceso un usuario

-- del modulo de PECOSAS y Cuadro de Necesidades
-- Usado por: Modulo de Pecosas, Modulo de Programación
-- Mantenimientos:
IF EXISTS (SELECT * FROM dbo.sysobjects WHERE name = ' PEC_S_OficinasUsuario' and type = 'P')
DROP PROCEDURE PEC_S_OficinasUsuario
GO
------------------------------------------------------------------
--DESCRIPCION: Procedimiento de Selección a la tabla PEC_Oficinas
--Usado por: SYIN - Módulo de Administración
--SN ### - yyyy Proyecto ### - Módulo de Administración, Autor: NMOLLO dd/mm/yyyy
------------------------------------------------------------------
CREATE PROCEDURE PEC_S_OficinasUsuario
(
@Año smallint,
@IDUsuario varchar(15)
)
WITH ENCRYPTION
AS
BEGIN
SET NOCOUNT ON;
SELECT u.IDUser,
u.IDUnidadOrganica,
cc.Descripcion,
cc.CodigoUnidadOrganica
FROM Seguridad..UsuarioAreaModulo u
INNER JOIN Administracion..UnidadOrganica cc ON
u.IDUnidadOrganica=cc.IDUnidadOrganica
WHERE u.IDUSer = @IDUsuario AND FechaFin IS NULL
END
GO
GRANT EXECUTE ON PEC_S_OficinasUsuario
TO usersysa
GO
IF OBJECT_ID ( 'PEC_VW_OFICINAS', 'VIEW' ) IS NOT NULL
01/05/2019
REVISIÓN 4
DROP VIEW PEC_VW_OFICINAS';

GO
------------------------------------------------------------------
--DESCRIPCION: Vista de PEC_VW_OFICINAS Relación Tablas(Seguridad,Administracion,UnidadOrganica)
--Usado por: SYIN - Módulo de Administración
--SN ### - yyyy Proyecto ### - Módulo de Administración, Autor: NMOLLO dd/mm/yyyy
------------------------------------------------------------------
CREATE VIEW PEC_VW_OFICINAS'
WITH ENCRYPTION
AS
SELECT u.IDUser,
u.IDUnidadOrganica,
cc.Descripcion,
cc.CodigoUnidadOrganica
FROM Seguridad..UsuarioAreaModulo u
INNER JOIN Administracion..UnidadOrganica cc ON
u.IDUnidadOrganica=cc.IDUnidadOrganica
GO
GRANT SELECT ON PEC_VW_OFICINAS'
TO usersysa
GO
7. SEGURIDAD DE ACCESOS
APLICACIONES VISUALES – SQL SERVER

1. Los sistemas de información desarrollados en SQL Server utilizarán la base de
datos Seguridad para validar los accesos.
2. Las contraseñas se almacenarán en forma encriptada en una única tabla, que
será utilizada por todos los sistemas.
3. Las contraseñas tendrán un tiempo de vigencia de 3 meses, debiendo forzarse a
los usuarios a cambiarlas a través del sistema de información respectivo, cada
vez que ingresen a él.
4. No se permitirán contraseñas que sean idénticas a los login del usuario y tendrán
una extensión mínima de 8 caracteres alfanuméricos.
5. Se mantendrá un registro de las últimas tres contraseñas para impedir su
reutilización.
6. Las pantallas de identificación de usuario NO permitirán modificar el ID del
usuario, sino ingresar únicamente la contraseña. El ID utilizado será el
proporcionado por la sesión de red iniciada.
7. Los sistemas de información deberán manejarse por perfiles de usuario,
asignándose los derechos a través de una aplicación que permitirá establecer
derechos de lectura, escritura, borrado, entre otros.
8. En el caso de intentos fallidos, se bloqueará la aplicación al tercer intento y se
registrará este hecho en una tabla.
8. PISTAS DE AUDITORÍA
Las pistas de auditoría permiten registrar las modificaciones efectuadas sobre los
datos, haciendo referencia a los datos que sean relevantes para un seguimiento
adecuado de acciones.
01/05/2019
REVISIÓN 4
El dueño de la aplicación determinará cuáles son los datos críticos y cuáles requieren
llevar pistas de auditoría; el desarrollador incluirá dichas pistas en las tablas.
APLICACIONES VISUALES – NIVEL APLICACION

Todas las tablas SQL Server deberán ser diseñadas con pistas de nivel de
Aplicación, para cada una de las operaciones.
o Activo BIT (indica si está Disponible)

o Eliminado BIT (indica si es eliminación)
En el caso de las tablas que contengan las transacciones más importantes del
sistema o de las tablas críticas, se debe agregar campos adicionales de ser
necesario:
o Historial BIT (indica si está en estado Historial)
o Sistema BIT (indica si es pertenece el ingreso al Sistema)
APLICACIONES VISUALES – SQL SERVER

Todas las tablas SQL Server deberán ser diseñadas con pistas de auditoría mínimas,
para cada una de las operaciones de Ingreso y Modificación datos.
o IdUsuarioIngreso INT
o IdUsuarioActualizo INT
o FechaIngreso datetime
o FechaActualizo datetime
En el caso de las tablas que contengan las transacciones más importantes del
sistema o de las tablas críticas, se debe manejar adicionalmente una tabla de
auditoría, que llevará el mismo nombre que la tabla referencia, con el sufijo Auditoria.
Esta tabla tendrá la misma estructura de la tabla referencia con los siguientes
campos adicionales:
o TipoOperacion char(1) (indica si es modificación/eliminación)

o IDUsuario varchar(15) (indica el usuario que hizo la operación)
o IDEquipo varchar(15) (indica el equipo del cual se hizo la operación)
o FechaCambio datetime (indica la fecha de la operación)
Si se requiere almacenar otras pistas de auditoría, éstas deberán incluirse en la

documentación del sistema.
Estructura del Tabla OPE_AUDITOR
Nombre de Tipo y Tamaño Descripción

Campo
Tabla Caracter(11) Nombre de la tabla afectada
Registro Caracter(20) Nombre del campo afectado
Tipo Caracter(01) Tipo operación:
M=Modificación
01/05/2019
REVISIÓN 4
E= Eliminación
Usuario Caracter(15) Identificador del usuario
Equipo Caracter(20) Identificador del equipo
ValorAnt Caracter(20) Valor anterior
ValorAct caracter(20) Valor actual
FchCambio Fecha Fecha de cambio
HorCambio Hora Hora de Cambio
Si se requiere almacenar otras pistas de auditoria, éstas deberán incluirse en la

documentación del sistema.
9. PROGRAMAS EN VISUAL BASIC .NET
Programas
Los elementos mencionados serán precedidos por los prefijos indicados y el nombre.
Tipo Prefijo Ejemplo

Solución Sln SlnCompras
Proyecto Pjt PjtCompras
Formularios Frm FrmPECOSA
Módulos Mod ModCompras
Clases Cls ClsUsuario
User Control Ctl CtlOptionButton
Report Informe Rdl dsrRFuncionarioPromocion
Crystal Report Rpt RptRUsuarioPotencialEstado
Archivo de Recursos Res ResUsuarioPotencial
Asimismo, en cada programa editable, se colocará en la cabecera una sección de

comentarios que contendrá:
 Nombre del programa

 Descripción
 Fecha desarrollo
 Desarrollador
 Fecha mantenimiento
 Persona que lo realizó
 Numero de solicitud de mantenimiento
 Descripción del mantenimiento
Y en cada programa se deben colocar el mayor número de comentarios posibles.
Variables
Las variables se nombrarán con el prefijo que indique su tipo.
Tipo Prefijo
Integer Int
01/05/2019
REVISIÓN 4
Boolean Bln
String Str
Byte Byt
Double Dbl
Single Sgl
Variant Var
Currency Cur
Date Dat
Long Lng
Object Obj
Dataset ds
Datatable dt
Datarow dr
Exception ex
List(Of T) Ls
Colección Col
DialogResult Dgr
Controles
Los controles se nombrarán con el prefijo que indique su tipo.
Tipo Prefijo
TextBox Txt
Label Lbl
ComboBox en general Cbo
ListBox en general Lst
Button Btn
DataGridView en general Dgv
OptionButton Opt
CheckBox Chk
Picture Pic
CheckedListBox Chl
LinkLabel Llb
DateTimePicker Dtp
MonthCalendar Mcd
NumericUpDown Nud
ListView Lvw
TreeView Tvw
StatusStrip Sts
ToolStrip Tls
ImageList Iml
ProgressBar Pgb
Radiobutton Rdn
RichTextBox Rtx
MaskedTextBox Mtx
GroupBox Grp
01/05/2019
REVISIÓN 4
Tipo Prefijo
Panel Pnl
NotifyIcon Nfi
SplitContainer Spc
TableLayoutPanel Tlp
MenuStrip Mns
ContextMenuStrip Cms
HelpProvider Hpr
ErrorProvider Epr
Timer Tim
BackgroundWorker Bgw
CrystalReportViewer Crv
Bar Bar
AdvTree Atr
DotNetBarManager Dbm
DockContainerItem Dci
DockSite Dcs
PanelDockContainer Pdc
StyleManager Sty
CrumbBar Crb
ExplorerBar Exb
TabStrip Tsp
TabControl Tbc
TabControlPanel Tcp
TabItem Tbi
PanelEx Pnl
ButtonX Btn
ButtonItem Bti
Command Cmd
ComboBoxEx Cbo
SuperTabControl Stc
SuperTabControlPanel Stp
SuperTabStrip Sts
SuperTabItem Sti
ContextMenuBar Cmb
RibbonControl Rbc
RibbonBar Rbb
RibbonPanel Rbp
RibbonTabItem Rbt
RibbonBarMergeContainer Rbm
NavigationBar Ngb
TextBoxX Txt
CheckBoxX Chk
ItemPanel Ipn
VScrollBarAdv Vsb
HScrollBarAdv Hsb
01/05/2019
REVISIÓN 4
Tipo Prefijo
SideBar Sdb
ListViewEx Lvw
ExpandablePanel Exp
NavigationPane Nvp
DataGridViewX Dgv
WarningBox Wrb
LabelX Lbl
LabelItem Lbi
ColorCombControl Ccc
CustomColorBlender Ccb
IntegerInput Iip
DateTimeInput Dtp
MonthCalendarAdv Mca
QatCustomizePanel Qcp
MetroShell Mts
MetroToolbar Mtt
MetroStatusBar Mts
Slider Sld
ReflectionImage Rfi
BubbleBar Bbb
SlidePanel Sdp
CircularProgress Cpg
DoubleInput Dip
AnalogClockControl Acc
BalloonTip Blt
ColorPickerButton Cpb
ComboTree Cbt
IpAddressInput Iap
MaskedTextBoxAdv Mtx
ProgressBarX Pgb
TextBoxDropDown Txd
GroupPanel Grp
PageNavigator Png
ReflectionLabel Rlb
MicroChart Mch
AdvPropertyGrid Apg
SuperTooltip Stp
CalendarView Cld
DateNavigator Dng
RibbonClientPanel Rcp
SwitchButton Sbt
SuperValidator Spv
Highlighter Hgh
Wizard Wiz
RatingStar Rgs
01/05/2019
REVISIÓN 4
Tipo Prefijo
RatingItem Rgi
GaugeControl Gct
KnobControl Kct
TreeGX Trg
ItemContainer Itc
Procedimientos y Funciones
Tipo Prefijo
Función (Function) fnc
Procedimiento (Sub) Prc
Reportes
Los reportes se nombrarán usando el prefijo rpt. Si se emplean plantillas de diseño,
éstas se nombrarán con el prefijo ttx.
10. CONTROL DE DATOS EN LAS APLICACIONES
Los controles de aplicación se refieren a las transacciones y a los datos relativos a

cada sistema basado en una computadora, y por lo tanto, son específicos para cada
aplicación. Los objetivos de los controles de aplicación, que pueden ser manuales o
programados, deben asegurar la integridad y la exactitud de los registros y la validez
de las entradas realizadas, tanto sean resultantes del procesamiento manual como
programado. Los controles de la aplicación son controles sobre las funciones de
entrada (input), procesamiento y salida (output) de datos. Incluyen métodos para
asegurar:
 Que sólo se introducen y actúen datos completos, exactos y válidos en un

sistema de información.
 Que el procesamiento realice la tarea correcta
 Que los resultados del procesamiento satisfagan las expectativas
 Que se mantengan los datos
Controles de Entrada/Origen
Los procedimientos de control de entrada deben asegurar que toda transacción que
vaya a ser procesada sea recibida, procesada y registrada correcta y
completamente. Estos controles deben asegurar que sólo se introduzca información
válida y autorizada, y que estas transacciones sean procesadas sólo una vez.
01/05/2019
REVISIÓN 4
Asimismo, se deberán incluir controles de tipo de dato, longitud, rango y otros

requeridos por cada campo visualizado en el formulario.
a. Autorización de entrada de datos

La autorización de ingreso verifica que todas las transacciones hayan sido
autorizadas y aprobadas por una instancia superior.
En los casos de que se posean documentos electrónicos que deban ser

revisados por otra área, debe manejarse un “Estado” que bloqueará las
modificaciones del documento ya revisado. La revisión/aprobación/ validación se
manejará en línea a través del mismo sistema o de otro que posea tales
opciones, empleándose un usuario y contraseña para efectuarla. Asimismo,
deben guardarse los datos del usuario que autorizó el documento, la fecha y la
hora.
Deberá indicarse el estado de la transacción en el formulario; incluyéndose

información del usuario y fecha de la revisión/aprobación/ validación.
b. Edición y validación de lotes

Entre los mecanismos para la validación de datos, se tiene:
 Secuencia
 Límite
 Rango
 Paridad
 Validez
 Razonabilidad
 Parámetros
 Existencia
 Llave
 Dígito
 Integridad
 Duplicidad
 Relaciones lógicas
El desarrollador seleccionará el tipo de validación de datos para los casos de

procesamiento de lotes.
c. Controles y balanceo de lote

Los controles de lote agrupan las transacciones de entrada para proveer totales
de control. El control de lote puede estar basado en un importe monetario total,
el total de elementos, el total de documentos o los totales calculados (bash
totals).
Los archivos de procesamiento de lotes deberán generar logs de transacciones,

indicando la cantidad de registros procesados y en caso de que sea relevante:
 Importe Monetario Total. Verificación de que el valor monetario total de los
01/05/2019
REVISIÓN 4
elementos procesados es igual al valor monetario total de los documentos

del lote. Por ejemplo, el valor monetario total de las facturas de venta en el
lote coincide con el .valor monetario total de las facturas de venta
procesadas.
 Total de Documentos - Verificación de que el número total de documentos
en el lote concuerda con el número total de documentos procesados. Por
ejemplo, el número total de facturas en UD. lote concuerda con el número
total de facturas procesadas.
 Totales Calculados (Hash Totals término. en inglés) - Verificación de que el
total (aunque carezca de sentido en sí mismo) para un campo numérico
predeterminado existente en todos los documentos de un lote, concuerda
con el total calculado por el sistema. Por ejemplo, el total de números de
cuenta de cliente no tiene sentido, pero puede ser sumado manualmente y
comparado con el valor calculado por el sistema.
Asimismo, deben efectuarse checkist o llenarse bitácoras de incidencias para

los procesos, según su relevancia.
Los procesos no deberían permitir la carga de ningún dato en caso de

presentarse algún error.
d. Reporte y manejo de errores

El procesamiento de los datos introducidos al sistema requiere que existan
controles que permitan verificar que los datos son aceptados en el sistema
correctamente, y que los errores que se presentan en su ingreso son
reconocidos y corregidos.
Los errores que se presenten deberán indicar al usuario la naturaleza del error,
además de almacenar el número de error y descripción del mismo y programa
que lo originó.
No se debe aceptar el ingreso de datos que hayan generado un error.
Procesamiento, validación y edición
a. Validación y edición de datos

Ver punto Controles de Entrada/Origen, sección a.
b. Procedimientos de control de procesamiento

Los controles de procesamiento aseguran la integridad y la exactitud de los datos
acumulados. Ellos aseguran que los datos contenidos en el archivo/base de datos
sigan siendo completos y exactos hasta que sean cambiados como resultado de
un procesamiento o de rutinas de modificación autorizadas.
Las técnicas de control de procesamiento que pueden ser usadas para tratar el
aspecto de integridad y exactitud de los datos acumulados son:
01/05/2019
REVISIÓN 4
- Reportes de verificación
- Totales de Proceso a Proceso
- Verificación de Razonabilidad de los Valores Calculados
- Verificaciones de Límite sobre los Valores Calculados
- Reconciliación de los Totales de los Archivos con los documentos fuente,
sobre todo en aspectos delicados como el Ingreso y la Salida de
Mercancías.
Controles de salida
Los controles de salida proveen garantía de que los datos entregados a los usuarios
serán presentados, formateados y entregados en una forma consistente y segura.
Dentro de estos controles, se puede considerar:
a. Distribución de Reportes
Los reportes de las aplicaciones deberán ser emitidos por usuarios que tengan
autorización de acceso a ellos. Esta autorización la dará el dueño de la
aplicación.
Los reportes confidenciales deberán ser etiquetados en el momento de su

emisión.
b. Manejo de Errores
Ver Controles de Entrada/Origen, d.
11. DOCUMENTACIÓN DE LOS SISTEMAS
Cada sistema deberá generar:
 Manual del usuario: Describirá la funcionalidad del sistema a través de casos

prácticos y de una FAQ. Deberá contener como mínimo:
o Objetivos
o Responsabilidades
o Límites
o Descripción de casos
o FAQ
 Manual del sistema: Describirá la estructura y funcionamiento del sistema

utilizando diagramas.
Asimismo, para la instalación de los sistemas, los desarrolladores crearán un archivo

llamado README.TXT almacenado junto con los instaladores.
01/05/2019
REVISIÓN 4
Diccionario de datos
El diccionario de datos se almacenará en ERWIN, generándose los reportes
respectivos en HTML.

MT 02 Desarrollo Standard Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

MT 02 Desarrollo Standard Software

Cargado por

Copyright:

Formatos disponibles

DESARROLLO DE SOFTWARE ET-003

Aplicaciones desarrolladas por la Oficina de Informática de BELEGOST S.A., a partir

 Los archivos que conforman los proyectos de desarrollo se almacenarán en un

TipoSolicitud: SN=Solicitud nuevo sistema, SM=Solicitud mantenimiento

TipoSolicitud: SN=Solicitud nuevo sistema, SM=Solicitud mantenimiento

4. CRONOGRAMA DEL PROYECTO

Los nuevos sistemas y mantenimientos mayores tendrán un cronograma asociado, el

TipoSolicitud-Número solicitud- Descripcion

TipoSolicitud: SN=Solicitud nuevo sistema, SM=Solicitud mantenimiento

Este cronograma se creará de acuerdo con el archivo PlantillaProyectos.mpp,

5. ESTANDAR DE CONFIGURACION DE BASE DE DATOS

6. OBJETOS DE LA BASE DE DATOS

Normas generales de nomenclatura

Nomenclatura de Base de Datos

Prefijo NombreBaseDatos= AliasAplicacion_SufijoBaseDatos

Prefijo NombreTabla= NemónicoSistemaProyecto_NombreTabla

Comentarios  Las tablas se nombrarán en singular

 El nombre de la tabla debe identificar claramente a la

Prefijo PK: pk_NombreTabla

Prefijo Cluster: IC_ NombreTabla_NombreIndice

Nomenclatura de Reglas (RULES)

Nomenclatura de Stored Procedures

Prefijo PrefijoMódulo_Accion_Nombre del Stored procedure_Tipo

Nombre del Stored procedure:

Prefijo TR_Nombre de la tabla_Tipo de trigger

Nomenclatura de tipos de dato definidos por el usuario

Reglas de Programacion Transact-SQL

CREATE PROCEDURE MAT_S_Matricula

 No es óptimo crear STORED PROCEDURES de ese tipo dado que el SQL

CREATE PROCEDURE PEC_S_OficinasUsuario

 Palabras del lenguaje SQL y funciones de Sistemas en MAYUSCULAS,

Programación Transact – SQL

Mantenimiento de objetos de base de datos

-- DESCRIPCION: Muestra las oficinas a las cuales tiene acceso un usuario

IF OBJECT_ID ( 'PEC_VW_OFICINAS', 'VIEW' ) IS NOT NULL

DROP VIEW PEC_VW_OFICINAS';

APLICACIONES VISUALES – SQL SERVER

APLICACIONES VISUALES – NIVEL APLICACION

o Activo BIT (indica si está Disponible)

APLICACIONES VISUALES – SQL SERVER

o TipoOperacion char(1) (indica si es modificación/eliminación)

Si se requiere almacenar otras pistas de auditoría, éstas deberán incluirse en la

Estructura del Tabla OPE_AUDITOR

Nombre de Tipo y Tamaño Descripción

Si se requiere almacenar otras pistas de auditoria, éstas deberán incluirse en la

9. PROGRAMAS EN VISUAL BASIC .NET

Tipo Prefijo Ejemplo

Asimismo, en cada programa editable, se colocará en la cabecera una sección de

 Nombre del programa

Y en cada programa se deben colocar el mayor número de comentarios posibles.

10. CONTROL DE DATOS EN LAS APLICACIONES

Los controles de aplicación se refieren a las transacciones y a los datos relativos a

 Que sólo se introducen y actúen datos completos, exactos y válidos en un

Asimismo, se deberán incluir controles de tipo de dato, longitud, rango y otros

a. Autorización de entrada de datos

En los casos de que se posean documentos electrónicos que deban ser

Deberá indicarse el estado de la transacción en el formulario; incluyéndose

b. Edición y validación de lotes

El desarrollador seleccionará el tipo de validación de datos para los casos de

c. Controles y balanceo de lote

Los archivos de procesamiento de lotes deberán generar logs de transacciones,

elementos procesados es igual al valor monetario total de los documentos

Asimismo, deben efectuarse checkist o llenarse bitácoras de incidencias para