Escuela Colombiana de Ingeniera

Arquitecturas de Software ARSW

Plan de trabajo Proyecto segundo tercio.

Fecha

Medio

Entregable

Febrero 26

Papel (mano alzada

o impreso).

Modelo de clases del ncleo de la

aplicacin (aquella parte de la
aplicacin
que
se
modificar
concurrentemente).

Marzo 3

GITHUB/Google
Docs.

- Documento de arquitectura (ver

plantilla) compartido en Google
Docs al usuario
hector.at.eci@gmail.com, con el
nombre ARSW-2015-1DOCUMENTO_ARQ_NOMBRE_PROYECT

y con la seccin 1 terminada.

- Primera versin del modelo del
ncleo, incluyendo pruebas unitarias
(para casos no concurrentes)
compartido en GitHub (repositorio
privado) para el usuario hectorateci.
O,

Marzo 10

GITHUB/Google
Docs.

Marzo 17

GITHUB/Google
Docs.

Modelo de la aplicacin actualizado,

considerando consistencia ante la
concurrencia (thread-safety).
Primer avance de artefactos
complementarios (interfaces de
usuario, etc).
Documento de arquitectura
actualizado: secciones 2.2, 2.3 y 3.
Implementacin(primera
versin)
de lo indicado en las secciones 2.2 y
3 del documento de arquitectura
(elementos de integracin).

Marzo 24

GITHUB

Marzo 26

GITHUB

avance
de
artefactos
complementarios
(interfaces
de
usuario, etc).
Versin preliminar del proyecto
completamente funcional.
- Versin final del documento de
arquitectura (considerando todas
las observaciones hechas al mismo).
Evaluacin

Condiciones generales.

An

cuando

hay

proyectos

con

funcionalidades

similares,

sus

especificaciones iniciales son muy generales, por lo cual se espera que cada
grupo presente una arquitectura y una implementacin de la misma
completamente diferente a la de sus compaeros. Los grupos deben tener
presente que por lo anterior, resulta muy fcil identificar plagio, an
cuando los nombres de clases y mtodos sean diferentes.

Se debe manejar un sistema de control de versiones desde el inicio del

trabajo (en este caso GITHUB). No se revisar cdigo presentado con
otros medios, ni se aceptar un repositorio con un nico commit. De la
misma manera, se espera que en los proyectos hechos por dos personas
haya evidencia de colaboracin (si slo aparecen commits a nombre de una
persona ser necesario evaluar si la otra persona s trabaj). Para revisar
cmo trabajar colaborativamente con GIT en un repositorio centralizado,
puede consultar:
https://www.atlassian.com/git/tutorials/comparing-workflows (slo hasta
Mary resolves a merge conflict).

El proyecto debe estar configurado como un arquetipo de Maven, no debe

tener dependencias locales (todas deben ser hacia el repositorio central).

Aunque se acepta la colaboracin entre compaeros para resolver dudas o

problemas tcnicos, cada grupo debe cuidar que su solucin planteada
(arquitectura) no sea conocida por los dems para evitar malos entendidos.

Se espera que el trabajo sea desarrollado en grupos de 2 personas, pero se

acepta el trabajo individual (en estos casos se buscar un alcance menor).
Sin embargo, si en los equipos de dos personas se observa que un
compaero no trabaja, debe notificar esto con suficiente anticipacin para
dividir dicho grupo (esto implica una reduccin del alcance). De lo
contrario, esta persona deber asumir la evaluacin estndar obtenida para
su proyecto.

La nota individual no necesariamente ser la misma nota del proyecto. En

caso de que durante la sustentacin no se muestre conocimiento de lo
desarrollado, dicha nota podr ser deficiente.