METODOLOGA PARA EL DESARROLLO DE S.I.

DEL DEPARTAMENTO DE SISTEMAS

DE RENOVA S.A.C.

Departamento de Sistemas

Pgina 1

19/12/2016

ndice
Introduccin.3
Modelos....4
Modelado de Negocio..4
Modelado de Casos de uso..6
Modelado de Anlisis..9
Modelado de Diseo...10
Modelado de Implementacin.12
Modelo de prueba....16
Administracin del Proyecto...16
Modelado de la Base de Datos20
Plan de ejecucin.22

Departamento de Sistemas

Pgina 2

19/12/2016

Introduccin
En las pginas siguientes detallaremos la metodologa, estndares, procedimientos y actividades
que deben emplearse para el correcto, Planeamiento, administracin, ejecucin de un proyecto de
Sistema Software y nos ayudaran a obtener un producto mas confiable, de mayor calidad reduciendo en
gran medida los riesgos, posteriores parches e interminables correcciones al software.
La evolucin de los proyectos sern medidos con Diagramas de Gantt en los cuales se
especificarn las distintas actividades a desarrollar para la ejecucin del proyecto y el cumplimiento de
los objetivos; estas actividades son definidas por el Proceso Unificado de Desarrollo de Software
aplicando una Configuracin de la misma de acuerdo a la dimensin del proyecto y necesidades de la
Organizacin, el cual se empleara como una plantilla para proyectos cortos/medianos y base para ser
ampliada en proyectos de mayor envergadura, esta define modelos que permiten mostrar todas la
representaciones del Software.
La notacin a usar es el UML(Lenguaje Unificado de Modelado) .
La base de datos partir con un esquema conceptual teniendo como base el modelo conceptual de
clases y los diagramas de secuencia.
Hay que tener en cuenta que todo el proceso es iterativo e incremental y en constante refinacin,
tambin es necesario emplear herramientas para las distintas actividades como modelado del software,
modelado de la base de datos, diseo de prototipos, evaluacin del cdigo fuente y rendimiento.

Esfuerzo en actividades segn fase del proyecto

Fases
Concepcin

Flujos de trabajo

Elaboracin

Construccin

Transicin

Modelado del Negocio

Captura de requisitos
Anlisis y diseo
Implementacin
Prueba
Despliegue
Configuracin y cambios en la administracin
Gerenciando el proyecto
Escenarios
Iter. #1

Departamento de Sistemas

Pgina 3

-----

Iter.
#n-1

Iter.#n

19/12/2016

Sustento para el empleo de la metodologa propuesta

En la industria del software es usual escuchar de proyectos que fracasan al no poder cumplir sus
objetivos, excediendo considerablemente en cuestiones de tiempo el margen de error del plan de
ejecucin del proyecto provocando que se sobrepase el presupuesto asignado.
El fracaso de proyectos que emplean una metodologa tradicional o simplemente no la emplean
se debe a las siguientes razones:

No se comprendieron las necesidades del usuario

No se previ el impacto de los requerimientos de cambios
Se descubrieron muy tarde falencias graves en el Proyecto
Hay mdulos que no se pueden integrar
Interferencias entre los miembros del equipo
No son confiables los procesos de fabricacin y liberacin del productos
Es baja la calidad del software generado
Es difcil mantener o extender el software
El funcionamiento es inaceptable
Falla en la Evaluacin y Control del Riesgo
Pruebas insuficientes
Propagacin descontrolada de cambios
Automatizacin insuficiente del proceso
Administracin informal de requerimientos
Inconsistencias no detectadas entre requerimientos, diseo e implementacin
Encontrar y reparar un problema de software despus de la implementacin resultando de 100 a
1000 veces ms costoso

Es por las razones antes mencionadas que debemos adoptar el mtodo que en este documento
proponemos para el desarrollo de Sistemas software dentro de la organizacin, mismo que es muy usado
en la industria del software a nivel mundial garantizando un producto de calidad y coloca a la empresa
en un nivel superior en cuestiones de tecnologa de la informacin dndole un valor agregado a la
organizacin.
Los siguientes son los beneficios que obtendremos al adoptar la metodologa.
Desfase mnimo de lo ejecutado vs. lo planeado.
El incremento de los recursos asignados es progresivo de acuerdo a la necesidad y evolucin del
proyecto reduciendo el presupuesto.
Carga de trabajo mejor distribuida en el tiempo.
Este mtodo nos permite fabricar Sistemas escalables, flexibles y de mantenimiento mucho ms
sencillo, esto quiere decir que en el futuro el sistema podr soportar nuevos requerimientos a
bajo costo.

Departamento de Sistemas

Pgina 4

19/12/2016

 Los requerimientos pueden ser adecuadamente capturados y comunicados a travs de Casos de

Uso
Con el prototipo del sistema el usuario tiene una idea concreta del producto final, permitindole
realizar una retroalimentacin de sus requerimientos y aportar otros mas refinados.
Las inconsistencias entre requerimientos, diseos, implementaciones adems de los defectos se
detectan tempranamente
La integracin del sistema es progresiva, esto nos permite disminuir el tiempo que normalmente
es asignado a esta actividad.
El usuario recibe mdulos del sistema funcionando a medida que avanza el proyecto y no tiene
que esperar a la etapa final del proyecto para ver resultados.
Los casos de uso guan el proyecto desde el inicio hasta el final y permite realizar las pruebas de
calidad del mismo.
Los casos de uso, capturan la funcionalidad del sistema tal como la ve el usuario, sin
ambigedades.
El mtodo facilita la reutilizacin de bloques de software contribuyendo a la reduccin del
tiempo de la ejecucin del proyecto.
Es posible realizar evaluaciones concretas del producto por cada bloque entregado sin esperar al
trmino total del producto.
Las pruebas continuas garantizan un producto de calidad
La evaluacin del estado del proyecto es objetiva, se evalan resultados de pruebas
Las estadsticas de cantidad de cambios proveen buenas mtricas para evaluar objetivamente el
estado del proyecto
La propagacin de los cambios son evaluables y controlables.

Departamento de Sistemas

Pgina 5

19/12/2016

Departamento de Sistemas

Pgina 6

19/12/2016

Modelos
Los modelos sern desarrollados e implementados segn el Proceso Unificado de Desarrollo de
Software, con notacin UML con un conjunto de entregables al termino de cada los cuales representan
una versin del sistema Software que se esta fabricando.

Modelado del Negocio

En este modelo nos concentraremos en que hace el sistema y no como lo hace, el modelo es
proporcionado por los Ing. Industriales, Administradores, Investigadores operativos, etc. Que conocen y
definen el funcionamiento del negocio, sus objetivos y actividades que realiza para cumplirlos en la
notacin antes mencionada (UML), en ausencia de estos modelos o los actores mencionados es
responsabilidad del analista realizarlos orientados a sistemas software con los artefactos que se
especifican a continuacin, cumpliendo los objetivos y teniendo al final los entregables resultantes.
Objetivos
1.
2.
3.
4.

Identificar y delimitar los procesos de negocio y los procesos de mantenimiento existentes.

Identificar los roles implicados en los diferentes procesos de negocio.
Descripcin textual del proceso de negocio (Opcional).
Modelar el flujo de tareas de cada proceso de negocio mediante Diagramas de Actividades que
muestran la iteracin de los roles para conseguir los objetivos, si una actividad es muy compleja
detallar en un diagrama de nivel inferior.
5. Especificar las actividades que aparecen en el diagrama de actividades.
6. Especificar las informaciones que se encuentran a cada diagrama de actividades
7. Especificarla reglas de negocio.
Artefactos a usar
1. Jerarqua de objetivos:
Se construye un rbol de objetivos y se va diversificando en sub objetivos hasta un tercer nivel
como mximo identificando los objetivos de la organizacin o sistema en estudio.
2. Diagrama de Actividades:
Se construyen un diagrama de actividades para cada objetivo de ltimo nivel en donde se
detallan todas actividades a realizar para cumplir dicho objetivo, de ser necesario se deber
especificar en diagramas de segundo nivel, as como tambin
Las informaciones y los roles que implicados.

Departamento de Sistemas

Pgina 7

19/12/2016

Doc. Varios
Certificado
Recibo de
Liquidacin
Solicitud

Verificacin
de Certificados por expirar

Inspeccion

Por Expirar

Armado de
solicitud

Postegar
Renovacin

Solicitud Lista
Para ser visado
Algun Doc. no
conforme

Cancelar
Renovacin

Reporte de
inspeccin

Visado
Visado
Ok
Ejecucin
Inspeccin

Certificado
Final

Negativo
Resultado

Recepci de
Reporte y Certificado

Entregables
1. Lista de roles
2. Diagramas de Actividades
3. Diccionario de actividades, necesario cuando la actividad no sea muy evidente o cuando sea
compleja y halla necesidad de detallarla.
4. Diccionario de informaciones(opcional)
5. Lista de reglas de negocio.

Departamento de Sistemas

Pgina 8

19/12/2016

Modelo de Casos de Uso (Captura de requisitos)

En esta fase nos concentraremos en desarrollar un modelo del Sistema software que se va a
construir, mediante los casos de uso se capturan los requisitos funcionales a la vez que nos permite
identificar requisitos no funcionales.
Los casos de uso nos permiten llegar a un acuerdo sobre los requisitos entre el usuario y el
analista.
Tambin se debe describir el conjunto de secuencias de acciones incluyendo variantes y
extensiones que debe ejecutar el sistema para producir resultados observables, a la vez que se deben
incluir las interacciones de actores y sistemas.
Algo muy importante que se debe tener en cuenta y no pasar por alto a la hora de realizar este
modelo es que no solo es importante para la captura de requisitos, especificacin de las dimensiones y
fronteras del software, mas importante aun es tener claro que el Modelado de casos de uso es el que
guiara el resto del proyecto es decir ser especificado por un Modelo de Anlisis (opcional), realizado
por el Modelo de Diseo, implementado por el Modelo de Implementacin y Verificado por el Modelo
de Prueba.
Objetivos
1. Extraer los casos de uso del sistema a partir las actividades que aparecen en los Diagramas de
actividades.
2. Describir los casos de uso.
3. Establecer el modelo conceptual a partir de las informaciones incluidas en los Diagramas de
actividades.
4. Listar los requisitos no funcionales.
5. Listar y opcionalmente describir los procesos de mantenimiento.
6. Disear el prototipo de la interfase del usuario
Artefactos a usar
1. Glosario de trminos:
En este artefacto se listaran, definirn y opcional especificaran los trminos importantes usados en el
proyecto.
2. Actor:
Define y establece los roles que los usuarios del sistemas van a desempear cuando interactan con
el; esta instancia de Actor puede ser un Actor individual o un sistema externo.
3. Caso de uso:
Define la secuencia de acciones que el usuario realiza cuando interacta con el sistema y las
acciones que realiza el sistema como respuesta a estas.

Departamento de Sistemas

Pgina 9

19/12/2016

4. Diagramas de casos de uso:

En este diagrama mostraremos un conjunto de casos de uso, actores y sus relaciones.

Armado de Solicitud
(f rom Coodinador)

Inspeccin
(f rom Coodinador)

Coodinador
(f rom Actores)

N1 Veri ficaci n de Doc.

(f rom Coodinador)

Usuari oConsul ta
(f rom Actores)

Consulta de Certificaciones

5. Paquetes de Casos de uso (opcional de acuerdo a las dimensin del modelo)

Son colecciones de casos de uso, actores, relaciones, diagramas y otros paquetes dividiendo la
estructura del modelo en pequeos paquetes.

Presentation

Application

Domain

Departamento de Sistemas

Persistence

Pgina 10

Services

19/12/2016

6. Modelo conceptual (Opcional)

Se construye utilizando del diccionario de informaciones, asociaciones y alguna cardinalidades que
se puedan sacar de las restricciones de integridad y los atributos mencionados en el diccionario se
pueden incluir en este modelo, este modelo se convierte en la primera versin del la base de datos.
Pedido
Numero

1
1

Contiene

Producto

1..*

Llena

1
Vendedor

Solicita
1..*

1
Cliente

Trab ajan

Empresa

7. Lista de prioridades de casos de uso: Nos permite tener una idea inicial de la ejecucin del proyecto
ordenando las tareas por prioridades dando mayor peso a las tareas importantes ms que a las
urgentes.
8. Plantilla de caso de uso
Caso de uso Comprar Socio
Objetivo Indicar al Sistema de Distribucin que se acepta como
el contenido del carro de compra
Actores Asociado
Precondiciones
Actor:
Sistema:
1.. A: Acepta el contenido
del carro como compra

compra

2.. S: Valida login y password

4.. S: si validacin es correcta: genera un
pedido cuyas lneas de pedido son cada una
de las del carro

3.. A: Insertar login y

password
Variaciones
4.a Si validacin incorrecta: reiniciar compra
Extensiones
Poscondiciones
Cuestiones hay un numero mximo de validaciones de login y password o bien
puede estar indefinidamente insertndolo hasta que sea correcto?
Departamento de Sistemas

Pgina 11

19/12/2016

Entregables
1. Diagrama de casos de uso.
2. Plantillas de caso de uso.
3. Modelo conceptual.
4. Requerimientos no Funcionales.
5. Prototipo de la interfaz del usuario.

Departamento de Sistemas

Pgina 12

19/12/2016

Modelo de Anlisis
En el anlisis, toman los requisitos que se describieron en la captura de requisitos refinndolos y
estructurndolos, el objetivo es lograr una comprensin mas precisa de los requisitos y que nos ayude a
estructurar el sistema entero.
Para ello emplearemos uno de los Diagramas de Secuencia especficamente los de colaboracin
uno por cada caso de uso para describir el comportamiento del mismo.
Objetivos
1. Determinar a partir de los casos de uso las operaciones que demandan los Actores del Sistemas.
2. Describir cada uno de los casos de uso mediante Diagramas de colaboracin.
Artefactos a usar
1. Actores
2. Clases de interfase
3. Clases de Control
4. Clases de entidad
5. Diagrama de colaboracin
Entregables
1. Diagramas de colaboracin
2. Diagrama de secuencia (opcional)

Departamento de Sistemas

Pgina 13

19/12/2016

8: test for acceptance

3: presentSubscriptionTerms
6: presentSubscriptionOptions
1: requestSubscription
4: submitTermAcceptance(Boolean)
7: submitDesiredOptions()

: Potential Subscriber
: Subscription Boundry

2: getSubscriptionTerms
5: getSubscriptionOptions
9: createNewSubscriber
: Subscription Control

: SubscriptionTerms

Departamento de Sistemas

: SubscriptionOption

Pgina 14

19/12/2016

Modelo de Diseo
El modelo de diseo es un modelo de objetos que describe la realizacin fsica de los casos de
uso y otras consideraciones de diseo que tienen impacto en el sistema teniendo como entrada principal
los diagramas de anlisis.
Objetivos
1. Construir el diagrama de clases del sistema a partir del modelo conceptual y el diagrama de
colaboracin.
2. Considerar cuestiones de diseo.
3. Armar los Paquetes de subsistemas.
4. Armar los paquetes de diseo.
Artefactos
1. Diagrama de Clases
2. Diagramas de interaccin(opcional)
3. Clases de diseo
4. Paquetes de Diseo
5. Subsistemas de Diseo
6. interfaces
Entregables
1. Diagrama de clases
<<process>>
Content
Content ID : String
Status : Byte
PendingViewCount : Long
LastArchivedDate : Date
ContentURL : String

ContentArchive

Approve()
Reject()
Categorize()
GoToWebSite()
PageSubscribers()
contentType()
is Approved()
setCatagories()

addStory()

AdReportTypes

ContentCatagories
getCatagories Lis t()
getList()

StoryContent
Headline : String
NewsStory : Variant
StoryType : Byte
getCategories()
getHeadline()

getList()

AdContent
AdFrequency
AdDisplayHistory
StartDate
ExpirationDate
AdType

AdFrequencyTypes

setPathToAd()
setAdCatagories()
setAdFrequency()
getInfoForReport()

getList()

Departamento de Sistemas

Pgina 15

19/12/2016

2. Diagrama de interaccin(opcional)

: Potential
Subs criber

: Subs cription Boundry

: Subs cription Control

requestSubscription
getSubs criptionTerms

pres entSubs criptionTerms

s ubmitTerm Acceptance(Boolean)

getSubs criptionOptions

Departamento de Sistemas

Pgina 16

19/12/2016

Modelo de Implementacin
En la implementacin empezamos con el resultado del diseo e implementamos el sistema en trminos
de componentes, es decir cdigo fuente que se transforman en ejecutables, libreras, etc., respetando los
estndares, patrones y la arquitectura definida para el proyecto.
Objetivos
Trasladar al lenguaje de programacin elegido el diseo obtenido en la etapa anterior.
Artefactos
1. Componente
2. Interfaz
3. Subsistema
4. Plan de Integracin de Construccin.
5. Arquitectura General de las Aplicaciones (obligatorio)
6. Estndares de Programacin
* PARA NOMENCLATURA DE PROYECTOS (Proyecto/Archivo/Carpeta)

=============================================

Seguridad
Servicios Generales
Servicios del Usuarios
Servicios de Negocio
(Servicios de Datos)
Libreras
Web
Servicios Web
Mviles
Clientes Inteligentes
Instalaciones

=
=
=
=
=
=
=
=
=
=
=

sgc[Nombre_Sist]
sgc[Nombre_Sist]
sgc[Nombre_Sist]
sgc[Nombre_Sist]
sgc[Nombre_Sist]
sgc[Nombre_Sist]
sgc[Nombre_Sist]
sgc[Nombre_Sist]
sgc[Nombre_Sist]
sgc[Nombre_Sist]
sgc[Nombre_Sist]

SEG_<1er. Nombre>_<2do.Nonmbre> ...<etc>.<Extencion>

GEN
"
"
"
UES
"
"
"
NEG
"
"
"
DAT
"
"
"
LIB
"
"
"
UWB
"
"
"
SWB
"
"
"
UMB
"
"
"
USC
"
"
"
SET
"
"
"

* PARA NOMENCLATURA DE CLASES

===============================

Winform =(3 DEL

SISTEMAS)(3 DIGITOS DEL TIPO DE PROYECTO)> [BAS]_<1er.Nombre>_<2do.Nombre>
...<etc>.<Extencion>
WebForm = (3 DEL SISTEMAS) (3 DIGITOS DEL TIPO DE PROYECTO)>
[BAS(clasebase)] _<1er.Nombre>_<2do.Nombre>...
<etc>.<Extencion>
Clases de Control de Interface winform= IWI[BAS(clase base)]<Mismo nombre de winform>
Clases de Control de Interface webform= IWE[BAS(clase base)]<Mismo nombre de webform>
Modulos = MoD<1er. Nombre>_<2do.Nonmbre> ...<etc>.<Extencion>
clases
Clases
Clases
Clases

de Negocio
de Control
deEntidad
de Utilidad

=
=
=
=

NEG[BAS(clase
CTR[BAS(clase
TBL[BAS(clase
UTI[BAS(clase

base)]<1er. Nombre>_<2do.Nonmbre> ...<Nonmbre N>.<Extencion>

base)]<1er. Nombre>_<2do.Nonmbre> ...<Nonmbre N>.<Extencion>
base)]<Nombre de Tabla/Nombre de Clase de diseo>.<Extencion>
base)]<1er. Nombre>_<2do.Nonmbre> ...<Nonmbre N>.<Extencion>

* PARA DECLARACION DE CLASES

Departamento de Sistemas

Pgina 17

19/12/2016

=============================

cls<NEG>_<Alias1>_<Alias2>...<AliasN>

ATRIBUTOS:
Prefijo
at<Prefijo de tabla>_<tipoDato 2digitos><Nombre de Campo1 4 digitos>_<Nombre de Campo2
4 digitos>
PROPIEDAD:
Prefijo prop<Prefijo de tabla>_<tipoDato 2digito><Nombre de Campo1 4 digitos>_<Nombre de Campo2 4
digitos>
PARAMETRO DE ENTRADA:
prefijo i<Nombre de parametro>
PARAMETRO DE ENTRADA Y SALIDA:
prefijo r<Nombre de parametro>
Vaiables de clase

: prefijo v<Nombre de Varible>

* PARA TIPOS DE DATOS

============================
todas las variables deben ir con su prefijo de tipo de dato
enumeradores en
: en
matrices en
: ar
cadenas en
: tx
estructuras en
: st
integer en
: in
date en
: dt
..etc

prefijos de Objetos ADO.NET

===========================
Dataset
Ds<Nombre
DataTable
Dt<Nombre
DataRow
Dw<Nombre
DataColumn
Dc<Nombre
item
Di<Nombre
Dataview
Dv<Nombre
objetos de fuente de datos
===========================
Connection Cn<Nombre
DataAdapter Da<Nombre
DataReader Dr<Nombre
command
Cm<Nombre

del
del
del
del

del
del
del
del
del
del

objeto>
objeto>
objeto>
objeto>
objeto>
objeto>

objeto>
objeto>
objeto>
objeto>

semntica para mtodos y funciones

==================================
* para clase de tabla u objetos que lo necesite
deben de ser de tipo boolean y debe incluir una rutina que capture el error
y genere un registro del mismo, y retorne una variable de tipo enum que identifique donde
se produjo el error
Funciones:

Departamento de Sistemas

Pgina 18

19/12/2016

insertar nuevo registro: agregar

modificar datos
: modificar
eliminar registros
: eliminar
obligatorio recuperar un registro de Clase : Buscar
Recuperar un lote de registros : Obtener<Nombre identificador>

Mtodos Obligatorios:
Limpiar, Cargar_ Propiedades, constructor, destructor
PARA INTERFACES:
================
General:
Nuevo
Editar
Grabar
Eliminar
Cancelar
Refrescar
Previo
Imprimir
Buscar
Salir
Primero
Anterior
Siguiente
Ultimo
Detalles
Adicionar
Quitar
Cambiar

Departamento de Sistemas

Definicin de Regiones Obligatorias

===================================
Instancias
Variables
Atributos
(alias
propiedades)
Propiedades
Mtodos
Funciones
Eventos de Controles
Eventos de Generados

Pgina 19

Variables

de

19/12/2016

Entregables
1. Cdigo fuente de la aplicacin: Respetando los estndares establecidos.
2. Diagrama de Componentes

3. Diagrama de Despliegue de Nivel Descriptor (Opcional)

Modelo de Prueba
Para este modelo realizaremos las siguientes actividades:

Pruebas unitarias: Estas pruebas se dan en el modelo de implementacin al trmino de cada

implementacin de caso de uso.
Pruebas de evaluacin: son las que se realizan en cada hito del proyecto y se especifican en la
Administracin del proyecto.

La evaluacin se realizara en una carpeta Proyectos_evaluacin por el encargado de Testeo

en un equipo diferente al que desarrolla el sistema, generando un log en la carpeta de
evaluacin, y con esta evaluacin se estable los cambios, errores y refinacin desde los casos
de uso.

Luego de liberar el ltimo Release de la fase de Construccin las pruebas se realizan en paralelo con el
sistema anterior a ser reemplazado si lo hubiere hasta la aprobacin total del los usuarios o una
autorizacin directa de la gerencia.

Administracin del Proyecto

Nuestros Proyectos se dividen en 4 Fases:
Concepcin
Elaboracin
Construccin
Transicin
* En cada fase se definirn Hitos tanto parciales y finales para evaluar la evolucin y resultados de
cada fase.

Concepcin

Hito
Objetivos
Ciclo de Vida

Elaboracin

Construccin

Hito
Arquitectura

Transicin

Hito
Capacidad
Operacional
Inicial

Liberacin
Producto

* Cada Fase esta dividida por iteraciones.

Concepcin
Iteracin # 1

Iteracin # 2

Elaboracin
Iteracin # 3

Iteracin # 4

Construccin
Iteracin # 5

*Para cada iteracin se aplica un esquema de cascada.

Iteracin # 6

Transicin
Iteracin # 7

Iteracin # 8

Plan de Iteracin
Requerimientos
Anlisis & Diseo
Implementacin
Test
Prepara Versin
Iteracin 3

Iteracin 4

Chequeo de
preparacin para
la iteracin

Iteracin 5

Evaluacin de
la Iteracin

* Adicionalmente aplicaremos la filosofa en la que el Cliente en nuestro caso el usuario no tendr

que esperar al final del proyecto para tener software terminado, probado, listo para operar teniendo
en cuenta que todo el proceso esta basado en ser iterativo, incremental y el refinamiento esto quiere
decir que si mas adelante se necesitan realizar cambios estos se realizan desde los requerimientos
guiando estos el resto de modificaciones en los diferentes modelos, produciendo una nueva revisin
del software.
Para esto dividiremos el Sistema Software en paquetes que tengan el mayor nivel de
independencia y estableciendo prioridades partiendo de la lista de prioridades de casos de uso.

Evaluacin de las Iteraciones

Para cada trmino de una iteracin se establecern Hitos el cual puede ser parcial o final, al
llegar a cada hito realizaremos la evaluacin de la iteracin, para ello utilizaremos un artefacto
llamado Estado de Iteracin el cual no es mas que el reporte de la evaluacin y a su vez en un
repositorio del proyecto especficamente en una carpeta Revisiones se crearan archivos *.txt en
donde se enumeraran los errores encontrados, los cambios solicitados y los nuevos requerimientos.
De acuerdo al impacto de las actividades pendientes establecidas en el los archivos Log se
adicionaran nuevas iteraciones al plan de ejecucin del proyecto y se realizara la revisin del control
de riesgos.
Todo lo antes mencionado en esta seccin garantizara la calidad de la aplicacin y la reduccin
de riesgos.
Plan de ejecucin

La planeacin de un proyecto posee dos niveles de abstraccin: un plan para las fases y un
plan para cada iteracin.

Consultar Diagrama de Gantt SgcPry_PlanEjecucion

Distribucin de archivos del proyecto

* En cada PC de desarrollo debe existir una carpeta llamada Proyectos, dentro de esta para cada
proyecto que no sea Web o Servicio Web deber existir una carpeta con el nombre del proyecto de
acuerdo a los estndares establecidos, para los proyectos Web o Servicios Web se crearan estas
carpetas dentro de la carpeta wwwroot; dentro de la carpeta de cada proyecto principal tendremos las
siguientes subcarpetas:

Bin: Que contendr todos los compilados de la aplicacin y compilados de los que
depende.
Documentos: Contiene todos documentos del proyecto en general
Artefactos Proceso Unificado del Desarrollo.
Planos Base de datos
Planes de ejecucin del proyecto
Modelos UML
Imgs: todas la imgenes usadas en el proyecto
Log: Archivos Log donde se especifican los cambio errores y nuevos
requerimientos.
Bk: copias de seguridad del proyecto especificando como sufijo ao con el siglo,
mes, da y hora de 24 con minutos.
Scripts: Contiene la secuencia de comandos de cada procedimiento almacenado
relacionado del cual el proyecto tenga dependencia con el nombre de cada
procedimiento.
Bd: Contiene la base de datos en el caso que sea un proyecto Access o similar
Reportes: Reportes que el sistema use.
Ayudas: En el caso que sea una librera, o un servicio deber existir esta carpeta con
archivos *.txt donde se explique el funcionamiento del componente o aplicacin.
Adjuntos: Contiene los archivos externos necesario para que la aplicacin funcione
acompaado de un *.txt donde se especifique la ubicacin y otros detalles a
tener en cuenta.
* Tambin tendremos otras carpetas principales como Sgc_BK< desarrollador> copia de proyectos
de otro desarrollador con el nombre de cada proyecto del que es propietario con ao, mes, da y
hora.
* Otra de las carpetas que tendremos es Sgc_evaluacin en el cual se copiaran los proyectos para
realizar las evaluaciones y revisiones.
* En el servidor en la Carpeta Sgc_Aplicaciones existir una carpeta por cada aplicacin con el
nombre comercial de la misma que contendr los archivos Release necesarios para que la aplicacin
funcione adems un *.txt con los alcances necesarios para la implementacin de la aplicacin en
donde corresponda.

* En el cliente existir en la raz de la unidad que corresponda una carpeta por cada aplicacin que
se necesite con el nombre comercial de la aplicacin y con las siguientes carpetas dentro de ella.
Bk: donde se almacenaran las copias de las distintas versiones.
Instalador: que contendr el instalador y los archivos necesarios para el correcto
funcionamiento de la aplicacin,
Ayudas: aqu estarn contenidos los archivos de ayuda.
Reportes: si es necesario
BD: si es una aplicacin que usa MS-Access y si hace las veces de servidor.
Log: Aqu se almacenaran los archivo *.Log que registraran inicialmente toda la
ocurrencia de errores generados por la aplicacin.
Imgs (opcional): Contendr las imgenes que necesite la aplicacin.
Otras carpetas necesarias de acuerdo a los requerimientos de la aplicacin.
Expediente del proyecto
Archivador donde se almacenaran todos los artefactos, planos y documentacin del proyecto creando
un expediente por cada proyecto, as tenemos que este expediente se compone de las siguientes
secciones:

Plan de ejecucin
Modelo de Negocio
Modelo de Casos de uso
Modelos de Anlisis
Modelos de Diseo
Modelos de Implementacin
Base de Datos
Estndares
Diccionario de trminos
Control de cambios
Manual del usuario

Modelado de base de datos

Para el modelado de la base de datos realizaremos las siguientes actividades.
Desarrollar un modelo entidad relacin partiendo del modelo conceptual de clases del
Modelos casos de uso, los requerimientos identificados y el modelo de anlisis con este
paso establecemos la traza que se ira refinando con la evolucin del proyecto.
Desarrollar las 5 formas normales.
Desarrollar el diagrama lgico de la base de datos guardando la semntica en lenguaje
natural.
Desarrollar el diagrama Fsico segn los estndares establecidos.
Implementar el modelo en el administrador de base de datos
Implementar la traza entre la base de datos y el modelo de implementacin generando las
clases de la capa de servicios del usuario segn la estructura fsica de la base de datos

 Desarrollar una traza directa entre los mtodos y funciones de los objetos del modelo de
diseo y los procedimientos almacenados de la base de datos, esta actividad es
incremental y de refinacin de acuerdo a la evolucin del proyecto.

Artefactos
1.
2.
3.
4.
5.
6.
7.

Modelo conceptual de clases

Especificaciones de casos de uso
Modelos de anlisis.
Diagrama lgico
Diagrama fsico
Diccionario de base de datos
Estndar de la nomenclatura de la estructura fsica de la base de datos.
PARA NOMENCLARTURA DE TABLAS:

===========================

<NombreCortoDelSistemaMAY>_<TipoDeTablaMAY>_<1er NombreMAY>[_<2do NombreMAY>]

Tipos de tablas:
B: Del tipo Base
M: Del tipo Maestro
Detalle:<NombreCortoDelSistema>_<TipoDeTablaMaestra>_<1er
nombreTablaMaestra>_[<2do nombre tabla maestra>_]<Nombre de tabla hija>
C: Del tipo configuracin
R: Del tipo relacin que rompe la multiplicidad entre dos tablas
P: Del tipo parmetros
S: Del tipo Seguridad.
otras que se puedan ir agregando

PARA NOMENCLATURA DE CAMPOS

===============================

<4 Abrev. de Tabla MAY>_<2 tipo de dato MIN><1er Nom Semntico

MAY><2do Nom Semntico

MAY >

PARA NOMENCLATURA DE PROCEDIMIENTOS ALMACENADOS Y VISTAS

=============================================================
<NonmbreDeTabla >_<NombreDeMetodoClaseDiseo>

PARA NOMENCLATURA DE FUNCIONES

===================================
<NombreDeOperacin>

Entregables

Base de datos Fsica.

Diagrama entidad relacin.
Diagrama lgico.
Diccionario de base de datos comentada.
Diagrama de flujo de informacin por cada caso de uso realizando una traza con las mismas
Diccionario de base de datos reporte de dependencias.(Opcional)
Lista de dependencias por cada caso de uso con su respectiva traza.(Opcional)
Diagramas de relacin de tablas por cada caso de uso en la base de datos.