100 lines
2.8 KiB
Org Mode
100 lines
2.8 KiB
Org Mode
+title: Primera clase
|
|
|
|
* Intro
|
|
se va a poner en juego todos los conocimientos de la carrera hasta ahora para crear un producto de software.
|
|
|
|
Además se vas a dar temas nuevos, como lo podria ser, patrones de diseño.
|
|
|
|
* Proceso de desarrollo de software
|
|
Son los pasos para desarrollar un sistema:
|
|
|
|
- Analisis
|
|
- Diseño
|
|
- Codificacion
|
|
- Testeo
|
|
- Implementacion
|
|
|
|
** Objetivos
|
|
Cuando vamos a hacer un sistema existe un cliente el cual tiene unos objetivos de su area. nosotros teenmos que descubrir cuales son sus objetivos, estos deben de ser:
|
|
|
|
- Medibles
|
|
Ejemplo, si el cliente es el duelo de una optica, un objetivo podria ser, Reducir el tiempo promedio en sala de espera por un 20%.
|
|
|
|
A partir de los Objetivos se desprenden los requerimientos.
|
|
|
|
* Seguridad 2024
|
|
Se necesita hacer un proyecto con toda la documentacion sobre un sistema a eleccion que cumpla con los siguientes requisitos:
|
|
|
|
#+begin_comment
|
|
hay que poner los puntos aca.
|
|
#+end_comment
|
|
|
|
* Metricas
|
|
si noostros no generamos antecedentes para poder backear las estimaciones del tiempo y costo de desarrollo.
|
|
|
|
* Casos de uso
|
|
estos son diagramas donde se especifican las estructuras de la interaccion actor-sistema.
|
|
|
|
** Reglas de negocio
|
|
Esta son un grupo de reglas sobre las cuales el negocio opera.
|
|
|
|
Estas tienen que estar en la especificacion de los casos de uso del negocio.
|
|
|
|
* Espeficiaciones
|
|
#+begin_quote
|
|
si hacemos un modulo de venta tiene que estar el abm de ventas
|
|
#+end_quote
|
|
|
|
- 1 diagrama de actividad o diagrama de transicion de estados.
|
|
- Diagrama de casos de uso.
|
|
- Espeficiacion de casos de uso.
|
|
- Modelo del dominio.
|
|
- Diagrama de secuencias.
|
|
- Diagrama de clases.
|
|
- Diagrama de componentes con la arquitectura del sistema.
|
|
- Patrones de diseño, implementar por lo menos dos patrones.
|
|
- Modulo seguridad.
|
|
- Auditoria.
|
|
- Reportes indicadores y estadisticas.
|
|
- backup y restauracion.
|
|
- Pruebas negra y blanca.
|
|
- Manual.
|
|
|
|
* Consideraciones
|
|
el producto de software debe estar desarrollado de forma completa, es deciur todo el soporte a los ABM y los procesos codeados y documentados.
|
|
|
|
formato de entrega: word...
|
|
|
|
Tenemos un diario y solo vemos un diario y nada más. Donde ponemos que avances hacemos.
|
|
Creamos una capeta con nuestro Apellido y Nombre. para hacer las entregas.
|
|
|
|
** Ingenieria de software
|
|
|
|
** Trabajo de diploma
|
|
|
|
* Tarea
|
|
- Repaso de la materia. "Evaluacion Diagnostica".
|
|
- Idea de proyecto, traer un borrador. puede ser un cliente real o ficticio. debe tener un alcanze amplio.
|
|
|
|
* Horarios
|
|
8:15 empieza la clase masomenos.
|
|
|
|
* Parciales
|
|
Poner enunciado del parcial y una hoja de revision con: fecha autor y desarrollo. y se entrega todo junto.
|
|
mña los publica.
|
|
|
|
* Notas
|
|
Objetivo => KMS + GUI => Metodologias.
|
|
- estado plant
|
|
#+begin_src plantuml :file estado.jpg
|
|
@startuml
|
|
[*] --> State1
|
|
State1 --> [*]
|
|
State1 : this is a string
|
|
State1 : this is another string
|
|
|
|
State1 -> State2
|
|
State2 --> [*]
|
|
@enduml
|
|
#+end_src
|