Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit db8ed8e

Browse files
author
Alejandro CR
committed
2 parents 03209b9 + 8d03b2e commit db8ed8e

39 files changed

+895
-644
lines changed

‎docs/api/library.md‎

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
[volver al inicio](/readme.md)
2+
3+
[volver a implementación](/docs/phases/implementation.md)
4+
5+
# API librería
6+
7+
A continuación se listan los datos recomendados para la especificación.
8+
9+
<br>
10+
11+
## Clase
12+
13+
- Nombre
14+
- Descripción
15+
- Atributos
16+
- Métodos
17+
- Ejemplos de uso
18+
19+
<br>
20+
21+
## Función
22+
23+
- Nombre
24+
- Descripción
25+
- Argumentos
26+
- Tipo de retorno
27+
- Excepciones lanzadas
28+
- Ejemplos de uso

‎docs/api/web.md‎

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
[volver al inicio](/readme.md)
2+
3+
[volver a implementación](/docs/phases/implementation.md)
4+
5+
# API web
6+
7+
A continuación se listan los datos recomendados para la especificación.
8+
9+
<br>
10+
11+
## Request
12+
13+
- HTTP version
14+
- HTTP method
15+
- URL
16+
- Authorization method
17+
- Query parameters
18+
- Request headers
19+
- Request body
20+
- none
21+
- application/json
22+
- application/octet-stream
23+
- application/x-www-form-urlencoded
24+
- multipart/form-data
25+
- text/xml
26+
- Cookies
27+
28+
<br>
29+
30+
## Success response
31+
32+
- Status code
33+
- 200 (listar recursos o buscar un recurso)
34+
- 201 (crear un recurso)
35+
- 202 (ejecución asincrona iniciada con éxito)
36+
- 204 (actualizar o eliminar un recurso)
37+
- Status message
38+
- Response headers
39+
- Response body
40+
- Cookies
41+
42+
<br>
43+
44+
## Error response
45+
46+
- Status code
47+
- 400 (falló en la validación de datos de la petición)
48+
- 401 (acción sin autorización)
49+
- 403 (acción prohibida)
50+
- 404 (la ruta o el detalle del recurso no existe)
51+
- 405 (método http no permitido)
52+
- 409 (hubo un conflicto al procesar la petición)
53+
- 500 (error interno del servidor)
54+
- Status message
55+
- Response headers
56+
- Response body
57+
- Cookies

‎docs/tipos.md‎ renamed to ‎docs/classification.md‎

Lines changed: 9 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -1,51 +1,35 @@
1-
# Tipos de documentación
1+
[volver al inicio](/readme.md)
22

3-
Existen diferentes tipos de documentación de software, personalmente los clasifico según tres dimensiones:
3+
# Clasificación de la documentación de software
44

5-
- **El elemento que se está describiendo** (requisitos, procedimientos, código, etc.).
6-
7-
- **El perfil del lector** (desarrollador, usuario, analista, etc.).
8-
9-
- **El propósito de la documentación** (descripción, especificación, etc.).
10-
11-
<br/>
5+
Existen diferentes tipos de documentación de software. Con el fin de facilitar su comprensión, personalmente los clasifico según tres dimensiones:
126

137
## Según el elemento
148

159
Un elemento es un concepto o componente del sistema.
1610

17-
Ejemplos de elementos pueden ser:
18-
19-
- Proyecto
20-
- Requisitos
21-
- Diseño
22-
- Código
23-
- Pruebas
24-
- Instalación
25-
- Funcionalidad
26-
- Topología
27-
- Mantenimiento
11+
Ejemplos de elementos pueden ser: requisitos, código, procesos, errores, funcionalidades, etc.
2812

2913
Dependiendo del elemento, la documentación puede variar en forma y contenido. Por ejemplo, la documentación de un proyecto puede incluir cronogramas, diagramas, listas de tareas, etc. Mientras que la documentación del código puede ser tan simple como un comentario en el código fuente.
3014

31-
<br/>
32-
3315
## Según el perfil del lector
3416

3517
El perfil define el conocimiento que se espera que tenga el lector del documento.
3618

3719
Ejemplos de perfiles pueden ser:
3820

3921
- **Expertos:** personas que conocen la arquitectura del proyecto y diseñan el producto.
22+
4023
- **Desarrolladores:** personas que construyen y mantienen los componentes del producto.
24+
4125
- **Técnicos:** personas que deben conocer y usar el producto.
26+
4227
- **No técnicos:** personas ajenas al proyecto que tienen curiosidad por aprender algo específico.
28+
4329
- **Ejecutivos:** personas que toman decisiones comerciales, económicas, administrativas, legales, gubernamentales y/o políticas sobre el proyecto.
4430

4531
Entender el perfil del lector es importante para determinar la forma en que se debe presentar la información. Por ejemplo, cuando leemos una publicación en el periódico acerca de alguna investigación, este artículo debería utilizar un lenguaje dirigido a un público no especializado. Por otro lado, el informe de la misma investigación para científicos o profesionales del tema tendrá un enfoque distinto.
4632

47-
<br/>
48-
4933
Una correcta documentación debe tener en cuenta las fórmulas:
5034

5135
> buen documento = contenido relevante + formato adecuado + lenguaje entendible
@@ -56,8 +40,6 @@ Una correcta documentación debe tener en cuenta las fórmulas:
5640
5741
> buen lenguaje = emplear palabras que el lector entienda
5842
59-
<br/>
60-
6143
## Según el próposito
6244

6345
Un documento puede tener dos tipos de propósitos: descriptivo o prescriptivo. Un documento descriptivo presenta el estado actual del sitema. Un documento prescriptivo define cómo debe ser o cómo se debe usar el sistema.
@@ -74,4 +56,4 @@ Ejemplos de propósitos prescriptivos pueden ser:
7456
- Instalación: manual de cómo se debe instalar el producto.
7557
- Uso: manual de cómo se debe usar el producto.
7658

77-
Es importante tener en cuenta que un mismo documento puede variar en su propósito según el estado del producto. Por ejemplo, la especificación del diseño del sistema puede ser considerado prescriptivo si aún no sea construído pero descriptivo tras el desarrollo.
59+
Es importante tener en cuenta que un mismo documento puede variar en su propósito según el estado del producto. Por ejemplo, la especificación del diseño del sistema puede ser considerado prescriptivo si aún no sea construído pero descriptivo tras el desarrollo.

‎docs/coding/docstrings.md‎

Whitespace-only changes.

‎docs/coding/git.md‎

Lines changed: 81 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,81 @@
1+
[volver al inicio](/readme.md)
2+
3+
[volver a implementación](/docs/phases/implementation.md)
4+
5+
# Control de versiones con Git
6+
7+
Git es un sistema de control de versiones distribuido que permite llevar un registro de los cambios realizados en el código fuente de un proyecto. Estos cambios se guardan en un repositorio, que es una base de datos que almacena los archivos y carpetas del proyecto, así como el historial de cambios.
8+
9+
<br>
10+
11+
## Repositorio
12+
13+
Un repositorio es una base de datos que almacena los archivos y carpetas del proyecto, así como el historial de cambios. Existen dos tipos de repositorios: locales y remotos.
14+
15+
**Repositorio local:** Es un repositorio que se encuentra en la computadora del desarrollador. Se utiliza para trabajar en el proyecto y guardar los cambios realizados.
16+
17+
**Repositorio remoto:** Es un repositorio que se encuentra en un servidor. Se utiliza para compartir el proyecto con otros desarrolladores y para hacer copias de seguridad.
18+
19+
<br>
20+
21+
## Ramas
22+
23+
Una rama es una línea de desarrollo independiente que permite trabajar en el proyecto sin afectar el código de la rama principal. Cada rama tiene un nombre y un punto de inicio, que es el commit del que se creó.
24+
25+
Existen diferentes flujos de trabajo con diferentes criterios para crear y fusionar ramas. Los flujos de trabajo más comunes son:
26+
27+
- Main (Master) only
28+
- Git flow
29+
- Github flow
30+
- Gitlab flow
31+
- One flow
32+
33+
<br>
34+
35+
## Commits
36+
37+
Los commits son registros de los cambios en el código fuente de un proyecto. Cada commit tiene un identificador único, un autor, una fecha y un mensaje.
38+
39+
El mensaje de un commit debe ser breve y descriptivo con un máximo de 50 caracteres y estar escrito en minúsculas. Debes escribir en tiempo pasado y no terminar en punto final.
40+
41+
Debes seguir el siguiente formato:
42+
43+
```
44+
<tipo> <complemento>
45+
46+
<detalles>
47+
```
48+
49+
**&lt;tipo&gt;** Indica el tipo de cambio realizado usando un verbos en tiempo pasado.
50+
51+
- creado: se han creado nuevos archivos.
52+
- actualizado: se han actualizado archivos existentes.
53+
- agregado: se ha agregado contenido.
54+
- cambiado: se ha cambiado contenido.
55+
- quitado: se ha quitado contenido.
56+
- renombrado: se ha renombrado contenido.
57+
- reemplazado: se han reemplazado archivos.
58+
- eliminado: se han eliminado archivos.
59+
- corregido: se han corregido errores.
60+
- reestructurado: se ha reestructurado código.
61+
- renombrado: se han renombrado archivos.
62+
- movido: se han movido archivos.
63+
- mejorado: se ha mejorado código.
64+
65+
**&lt;complemento&gt;** Indica el elemento modificado y en qué condiciones se modificó. Omite los artículos para acortar el mensaje, sólo menciona el sustantivo.
66+
67+
**&lt;detalles&gt;** Agrega información opcional que ayude a entender el cambio realizado o por qué se hizo.
68+
69+
> Ejemplo:
70+
>
71+
> creado archivo readme.md
72+
>
73+
> se agregó toda la información del proyecto y la lista de contribuidores.
74+
75+
<br>
76+
77+
## Consideraciones
78+
79+
1. Se debe hacer un commit que represente cada tarea finalizada, pero esto no significa que no se puedan hacer otros commits durante el desarrollo de la tarea.
80+
81+
2. Es una buena práctica durante la definición de tareas escribir los mensajes de los commits que se harán para cada tarea.

‎docs/coding/tasks.md‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
[volver al inicio](/readme.md)
2+
3+
[volver a implementación](/docs/phases/implementation.md)

‎docs/definición.md‎

Lines changed: 0 additions & 5 deletions
This file was deleted.

‎docs/definitions.md‎

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
# Formalización del desarrollo
2+
3+
La formalización se refiere a convertir la idea de lo que se quiere hacer en documentación.
4+
5+
La formalización se puede dar en múltiples niveles dependiendo de que tan cercano a la implementación sea el documento.
6+
7+
Estos niveles suelen ser:
8+
- Visión (vision)
9+
- Épica (epic)
10+
- Característica (feature)
11+
- Historia de usuario (user story)
12+
13+
# Característica (feature)
14+
15+
Es una característica o funcionalidad específica que un programa o aplicación ofrece.
16+
17+
# Historia de usuario (user story)
18+
19+
Es la especificación de una interacción que los usuarios podrían tener con el sistema.
20+
21+
# Dimensión del desarrollo
22+
23+
Las dimensión del desarrollo hace referencia a qué tantos archivos se deben modificar.
24+
25+
La dimensión se podría clasificar en:
26+
1. Cambios en un sólo archivo
27+
2. Cambios en varios archivos de un sólo directorio
28+
3. Cambios en varios directorios de un sólo sistema
29+
4. Cambios en varios sistemas

‎docs/fases/diseño.md‎

Lines changed: 0 additions & 26 deletions
This file was deleted.

‎docs/fases/entrega.md‎

Lines changed: 0 additions & 12 deletions
This file was deleted.

0 commit comments

Comments
 (0)