ELECTIVA  III Entregables  Minimos Entregable Sistema Código  fuente Suite  de  Pruebas  de   Regresión

Scripts  de  Instalación

Descripción El  software  de  trabajo,  el  hardware  y  la  documentación  para  ser   liberada  a  producción. El  código  de  programa  para  su  sistemas

Sugerencias Hay  más  en  su  sistema  que  sólo  el  software  que  se   escribe.

Requerido

Siga  las  directrices  de  codificación  común.

SI

Una  colección  de  casos  de  prueba,  y  el  código  para   Automatice  sus  pruebas. correrlas  en  una  orden  adecuado.  El  suite  de  pruebas  de   regresión  incluirá  un  gran  rango  de  pruebas,  tomando  en   Ejecútelas  tan  frecuentemente  como  sea  posible,   sobre  todo  cuando  ocurre  algún  cambio. cuentaapruebas  de  aceptación,  unidad  de  pruebas,  

Código  para  instalar  su  sistema  su  ambiente  de  pre-­‐producción.

Necesitará  un  script,  o  scripts,  para  instalarlo  en  un   ambiente  de  pre-­‐producción  tan  exacto  como  el  de   producción.

SI

NO

SI

Probablemente  deba  desinstalar  los  scripts  si  su   instalación  falla. Documentación  del   Sistema

Notas

Modelado  de   requerimientos

La  documentación  liberada  como  una  parte  del  sistema  para  ayudar   al  usuario  al  trabajar  con  él,  y  a  los  desarrolladores  para  mantenerlo   Mantenga  su  documentación  tan  liviana   actualizado.    Integra  potencialmente   como  sea  posible.   lasoperaciones,  soporte,  usuarios,  y  una  documentación  general  del   sistema. Sus  notas  deben  resumir  "las  buenas  cosas  a  saber"  acerca  de  las   Una  lista  puntual  es  a  menudo  suficiente. versiones  actuales  que  se  están  construyendo. Su  objetivo  es  entender  y  luego  construir  lo  que  sus   usuarios  quieren,  no  escribir  montículos  de   documentación.

Describe  los  requisitos  que  su  sistema  debe  cumplir.  Consta  de  una   variedad  de  productos  de  trabajo,  incluyendo   potencialmente  apruebas  de  aceptación,  oportunidades  de   automatización,  modelos  de  procesos  del  negocio,  reglas  del   negocio,  modelo  del  dominio,  modelo  de  la  organización,  glosario   del  proyecto,  requerimientos  técnicos,  modelo  de  casos  de  uso,  y  

SI

NO

No  necesita  mantener  todos  los  aspectos  para  su   modelo  de  requerimientos,  sólo  la  porción  que   resuma  el  alcance  de  su  sistema.

SI

Modelado  de   requerimientos

Describe  los  requisitos  que  su  sistema  debe  cumplir.  Consta  de  una   variedad  de  productos  de  trabajo,  incluyendo   potencialmente  apruebas  de  aceptación,  oportunidades  de   automatización,  modelos  de  procesos  del  negocio,  reglas  del   negocio,  modelo  del  dominio,  modelo  de  la  organización,  glosario   del  proyecto,  requerimientos  técnicos,  modelo  de  casos  de  uso,  y   el  modelo  de  interface  de  usuario.  

Considere  mantener:

Diagramas  de  Procesos  del  Negocio(s)  el   cual  resume  qué  es  su  sistema. El  glosario  del  proyecto. Cualquier  otro  requisito  de  productos,   como  puntos  de  forma  de  los  casos  de  uso,   que  todavía  no  han  sido  implementados.

SI

Pruebas  de  aceptación  para  requerimientos   implementados  (que  son  parte  de  su  suite  de   pruebas  de  regresión). Mantenga  su  modelo  tan  simple  como  sea  posible,  y   descarte  en  cuanto  le  sea  posible  una  vez  que  haya   extraído  el  valor  de  ellos.

Modelo  de  Diseño

Describe  el  diseño  de  su  sistema.  Consta  de  una  variedad  de   El  mejor  lugar  para  documentar  es  en  su  unidad  de   productos  de  trabajo,  incluye  potencialmente  un  modelo  de   pruebas  y  código  fuente. despliegue,  un  modelo  de  objetos,  un  modelo  de  datos  físico  (PDM),   un  modelo  de  seguridad  de  amenazas,  un  documento  de  resumen   Mantenga  el  documento  de  resumen  del  sistema  y   del  sistema,  y  un  modelo  de  interface  de  usuario. el  modelo  físico  de  datos  para  documentación  

NO

permanente.  Debe  también  mantener  unos  pocos   diagramas  de  diseño  detallados,  tales   como  diagramas  de  secuencia  o  diagramas  de  las   máquinas  de  estado.

Entregables  Sugeridos Entregable Pruebas  de  Aceptación AUP

Descripción

Sugerencias

Pruebas  de  aceptación  que  describen  los  requerimientos   Ver  Introductión  a  los  Casos  de  Prueba  de   de  caja-­‐negra,  identificados  por  sususuarios  del  proyecto,   Aceptación a  los  cuales  su  sistema  se  debe  ajustar. El  Proceso  Unificado  Ágil.

Requerido

SI NO

Oportunidades  de   Automatización Presupuesto

Modelado  de  Procesos   del  Negocio

Una  indicación  de  actividades  manuales  en  las  que  potencialmente   Esto  podría  fácilmente  ser  un  simple  punto  de  la   podrían  ser  automatizados. lista. Una  indicación  del  monto  del  presupuesto,  cuando  será  recibido  y  el   criterio  (si  fuera  el  caso)  que  su  equipo  debe  cumplir  para  recibir  el   fondo  para  soportar  el  esfuerzo  del  proyecto.

Una  descripción  de  las  actividades  del  negocio,  la  información  de   flujo  a  través  de  ella,  y  los  orígenes  y  destinos  de  la  información.  

Diagramas  de  Flujo  de  Datos  (DFDs),  Diagramas  de   Actividad  de  UML,  y  los  diagramas  del  flujo  de   trabajo  que  son  una  excelente  opción  para   visualizar  la  descripción  de  los  procesos  del  negocio.

SI NO

SI

Si  se  nombran  bien  los  elementos  del  negocio   probablemente  no  necesitará  escribir  alguna   documentación  de  soporte.

Especificaciones  de  las   Reglas  del  Negocio

Esquema  de  Datos

Reporte  de  Defectos

Una  especificación  de  reglas  del  negocio  captura  la   colección  de  reglas  del  negocio  implementadas  por  el   sistema.    Una  regla  del  negocio  define  o  limita  un  aspecto   de  su  negocio  que  pretende  hacer  valer  la  estructura  o   influencia  del  comportamiento  del  negocio.  Las  reglas  del   negocio  se  concentran  frecuentemente  los  problemas  de   controles  de  acceso,  cálculos  del  negocio  o  políticas  de  su   organización.

Use  herramientas  que  describen  las  reglas  del   negocio  en  una  forma  humanamente  legible  y  eso   genera  código  de  trabajo  desde  la  definición  de   reglas  del  negocio.

El  esquema  de  sus  almacenes  de  datos.  En  el  caso  de  las  bases  de   datos  relacionales,  es  descrito  por  el  lenguaje  de  definición  de  datos   Su  esquema(s)  de  datos  debe  evolucionar  de   (DDL),  para  los  almacenes  de  datos  XML  se  usa  un  esquema  de  XML  o   acuerdo  al  código  de  la  aplicación. XML  DTDs. Podría  ser  tan  simple  como  un  email  o  una  lista  en   una  hoja  de  cálculo. Un  tipo  de  solicitudes  de  cambio  que  definen  problemas  relacionados   Considerar  la  utilización  de  programas   al  sistema;  es  decir,  el  sistema  no  está  funcionando  de  la  forma  en   informáticos  específicos  para  el   que  tiene  que  hacerlo.

seguimiento  de  defectos  durante  la  fase   de  Transición  cuando  el  sistema  está   desplegado  en  producción.

SI

NO

NO

Manténgalo  simple. Modelado  de  Despliegue

Describe  cómo  se  va  a  organizar  los  aspectos  de  hardware  y  software   Frecuentemente  diagramado  usando  un  Diagrama   del  sistema. de  Despliegue  UML,  un  diagrama  de  red,  o   un  boceto  de  formato  libre. Enfocarse  en  las  dependencias  de  otros  grupos.

SI

Identifica  su  liberación  temprana  de  ventanas  en  el   proyecto.

Plan  de  Despliegue

Describe  el  acercamiento  del  despliegue  del  sistema  en  producción.

Trabaje  cerca  con  las  personas  de  operación  y   soporte.

SI

Debe  indicar  los  esfuerzos  de  capacitación  y   educación.

Los  detalles  técnicos  serán  capturados  por   su  script  de  (des)instalación. Inicie  creando  un  Modelo  de  dominio   liviano Modelado  de  Dominio

Describe  las  principales  entidades  empresariales,  las  relaciones  entre   Debe  controlar  el  desarrollo  de  su  modelo  de   ellas  y,  potencialmente,  sus  responsabilidades. objetos  y  el  esquema  de  datos(s)

NO

Considere  identificar  responsabilidades  (datos  y   comportamiento)  en  vez  de  sólo  sus  datos. Presente  la  estimación  en  un  rango. Estimación

Los  costos  de  proyecto  para  completar  el  proyecto.

Actualice  su  estimación  a  lo  largo  del  proyecto.

NO

Sugerencias  de  Estimación  Ágiles. Estimaciones   Individuales

Una  estimación  hecha  por  un  individuo  del  tiempo  y  costo  para   ejecutar  la  tarea.

La  mejor  persona  para  realizar  la  estimación  es   aquella  quien  es  responsable  de  ejecutar  la  tarea.

SI

Estimaciones   Individuales

Una  estimación  hecha  por  un  individuo  del  tiempo  y  costo  para   ejecutar  la  tarea.

SI Las  cosas  más  pequeñas  son  más  fáciles  de  estimar.

Modelado  de  Objetos

Operaciones  de   Documentación Evaluación  de  la   Organización Modelo  de  la   Organización

Describe  su  esquema  de  objetos,  el  código  que  comprende  su   software.  Frecuentemente  comprendido  por  varias  vistas  por  una   estructura  estática  y  los  aspectos  dinámicos  del  esquema.

Para  las  estructuras  estáticas,  considere  el  diagrama   de  clases  de  UML,  diagramas  de  componentes  de   UML,  y  diagramas  de  paquetes  de  UML.

NO Para  los  aspectos  dinámicos,  considere  el  diagrama   de  secuencia  de  UML,  diagrama  de  comunicación   de  UML  ,  y  diagramas  de  máquinas  de  estado  de   UML.

Captura  la  información  de  apoyo  y  los  procedimientos  para  operar  el   sistema  una  vez  que  estén  en  producción. Describe  la  organización  (tal  vez  una  división  de  su  empresa)  en  el   que  su  sistema  se  desplegará,  con  una  indicación  de  la  capacidad  de   la  organización  a  adoptar  y  utilizar  el  nuevo  sistema.

NO NO

Indica  a  las  personas  que  participan  en  su  proyecto  y  la  estructura  de   información  entre  ellos.  Debe  indicar  tanto  los  miembros  del  equipo   del  proyecto,  como  los  principales  interesados  y  sus  funciones.

NO Su  modelo  de  dominio  debe  conducir  el  desarrollo   de  su  PDM

Modelo  de  Datos   Físico  (PDM)

Describe  el  esquema  físico  de  un  almacén  de  datos,  tales  como  una   base  de  datos  relacional  o  archivo  XML.

Evolucione  su  PDM  y  su  modelado  de   objetos  en  paralelo

NO

Considere  usar  una  notación  UML Vea  las  facilidades  de  Introducción  al   Glosario Glosario  del  Proyecto

Describe  los  términos  críticos  y  técnicos  del  negocio  en  su  proyecto.

Reutilice  las  definiciones  del  glosario  existente  del   negocio

SI

Considere  usar  un  Wiki  para  su  proyecto. Debe  ser  concisa Resume  los  objetivos,  plan,  y  la  misión  del  proyecto.   Descripción  General  del   Potencialmente  compuesta  de  una  declaración  de  las   Proyecto metas  del  proyecto,  estatutos  de  la  visión  del  proyecto,  y  

SI

Resume  los  objetivos,  plan,  y  la  misión  del  proyecto.  

Descripción  General  del   Potencialmente  compuesta  de  una  declaración  de  las   Proyecto

SI

metas  del  proyecto,  estatutos  de  la  visión  del  proyecto,  y   Lista  de  puntos  debe  ser  suficiente.

Plan  del  Proyecto Recursos  del  Proyecto

Comprende  el  plan  de  iteraciones,  el  cronograma  del  proyecto,  lista   de  riesgo,  estimación,  ypresupuesto. Compuesto  de  financiación,  de  hardware  /  software,  y  las  facilidades   (como  las  habitaciones).

SI SI Un  diagrama  de  Gantt,  o  tal  vez  un  gráfico  pert,  es   el  método  más  común  para  hacer  un  cronograma   del  proyecto.

Cronograma  del   Proyecto

Indica  las  actividades,  las  dependencias  entre  ellos,  y  los  hitos  del   proyecto.

Observe  las  sugerencias  de  cronograma  de   proyecto  ágil.

SI

Calendario  de  actividades  a  largo  plazo  a  un  alto   nivel,  a  corto  plazo  y  actividades  en  más  detalle. La  gente  debe  planificar  su  propio  trabajo  y,  como   máximo,  asistida  por  el  gerente  del  proyecto. Prueba  del  Concepto   Prototipo

Código  de  trabajo  que  demuestra  un  enfoque  técnico  de  trabajo.

Registro  de  Revisión

Los  resultados,  incluidos  los  puntos  de  acción,  de  una  revisión.

Lista  de  Riesgos

Una  lista  de  los  riesgos  identificados,  y  las  estrategias  de  mitigación   (si  procede).

Durante  la  fase  de  Elaboración  debe   crearse  una  prueba  del  concepto  del   prototipo,  la  cual  muestre  la  arquitectura   de  extremo  a  extremo.

NO NO

Actualiza  tu  lista  de  riesgo  a  lo  largo  de  su  proyecto.

SI Mitigar  los  riesgos  tan  pronto  como  sea  posible.

Ver  Introducción  a  Modelado  de  Amenazas   de  Seguridad. Modelado  de  Amenazas   Un  modelo  que  analiza  las  amenazas  de  la  seguridad  de  su  sistema. de  Seguridad

NO

Modelado  de  Amenazas   Un  modelo  que  analiza  las  amenazas  de  la  seguridad  de  su  sistema. de  Seguridad

Documentación  de   Soporte

Las  amenazas  de  seguridad  son  frecuentemente   representadas  en  un  diagrama  de  despliegue   UML  o  un  diagrama  de  arquitectura  de  libre   formato,  por  lo  que  podrían  no  tener  un  esquema   para  ello.

La  documentación  requerida  por  el  personal  de  apoyo,  solución  de   problemas  tales  como  guías,  información  de  contacto  para  el  equipo   de  desarrollo,  que  les  permite  apoyar  a  los  usuarios  finales.

NO

NO La  concisión  es  fundamental

Documento  de  la   Documentación  técnica  de  las  personas  responsables  de   Descripción  General  de   mantenimiento  y  evolución  del  sistema. Sistema

Típicamente  incluye  diagramas  de  arquitectura  de   forma  libre,  una  visión  general  de  los  procesos  del   negocio  respaldada  por  el  sistema,  una  indicación   de  que  elcódigo  fuente  se  almacena,  y  una  lista  de   decisiones  de  diseño.

NO

Si  el  equipo  de  desarrollo  original,  o  una  porción  de   él,  es  responsable  de  mantener  el  sistema,  entonces   se  necesitará  mucho  menos  documentación Comprende  AUP,  orientación,  y  plantillas  ajustadas  a  sus   necesidades  del  equipo  del  proyecto. No  describe  los  problemas  de  comportamiento  tales  como  los  de   Requerimientos  Técnicos usabilidad,  seguridad  y  rendimiento  a  menudo  se  define  como   requerimientos  no  funcionales.

Procesos  ajustados   (adopción)

Plantillas

Pruebas  Modelado Estrategia  de  Pruebas Herramientas

NO Ver  Introducción  a  los  Requerimientos   Técnicos

Manténgalas  simples.  Plantillas  que  contiene  cada   Una  "forma  electrónica"  que  contiene  información  común  a  llenar  los   item  posible  que  usted  quiera  para  motivar  las   campos  para  un  determinado  tipo  de  producto  de  trabajo. personas  para  hacer  más  información  que  ellos   necesitan. Comprende  un  Suite  de  Pruebas  de  Regresión  y  cualquier  Reporte   de  Defectos. Una  descripción  de  su  enfoque  general  de  prueba. Reutilice  lo  de  otros  proyectos. Los  paquetes  de  software  utilizados  para  desarrollar  el  sistema

SI

NO NO NO SI

Materiales  de   Capacitación Casos  de  Uso

Las  notas  de  cursos,  documentación  general,  tareas  y  mucho  más   utilizado  para  ayudar  el  entrenamiento  de  usuarios,  personal  de   soporte  y  operaciones  de  soporte  que  funcionan  con  el  sistema. Casos  de  uso  describe  algo  de  valor  a  los  usuarios  y  son  un   requerimiento  primario  del  producto  de  trabajo  del  Agile  UP.

NO Los  casos  de  usos  de  forma  puntual  son   frecuentemente  suficientes.

SI

La  parte  más  importante  de  un  caso  de  uso  es  la   descripciones  del  modelo  de  caso  de  uso Modelado  de  Casos  de   Uso

Un  modelo  de  caso  de  uso  está  compuesto  por  cero  o   Los  casos  de  uso  de  forma  puntual  a  veces  son   más  diagramas  de  casos  de  uso,  descripciones  de  casos  d   suficientes. uso  y  descripciones  de  actores.

Documentación  de   Usuario

Diagramas  de  casos  de  uso  son  usados  con   frecuencia  para  administrar  presentaciones,   diagramas  de  procesos  de  alto  nivel. Los  manuales,  documentación  de  ayuda,  etc;  que  los  usuarios  finales   Recuerde  que  debe  indicar  cómo  ponerse  en   utilizan  para  ayudarles  a  entender  el  sistema. contacto  con  personal  de  apoyo. Propiedades  escritas  en  papel  y  bocetos  de  pizarra   de  pantallas  son  suficientes  para  obtener  el  punto   para  conocer  qué  es  lo  que  se  desea  construir.

Modelo  de  Interface  de   Describe  las  interfeces  de  usuario  de  su  sistema. Usuario

Las  interfaces  de  Usuario  son  útiles  durante  las   Iniciación  y  quizás  la  Elaboración,  pero  durante  la   Construcción  se  debe  escribir  el  código  actual  de   trabajo  y  no  el  código  del  prototipo. La  navegación  de  los  Diagramas  de  Interfaces  de   Usuario  UI  es  utilizada  para  ver  la  vista  general  de   sus  interfaces  de  usuario  y  explorar  los  problemas   de  usabilidad.

NO

SI

NO