Introducción a las TIC

Semana 7
DESARROLLO DE SOFTWARE

Mtro. José Uriel León Solórzano

¿Qué tema se trató la sesión anterior?

➢ Sistemas Operativos
 Logro de aprendizaje de la sesión

Al finalizar la unidad, el estudiante reconoce la utilidad del

diseño como parte fundamental del desarrollo de software y
maneja sus conceptos, herramientas y técnicas,
contrastando la exposición con la tecnología de la ingeniería
de diseño y las oportunidades profesionales de desarrollo en
esa línea dentro del cambio tecnológico mundial.
 ¿Qué debemos saber para la presente sesión?

➢ Fundamentos de las TIC

➢ Sistemas de Información y Comunicación
➢ Redes de comunicación
➢ Hardware y el manejo de los sistemas numéricos
➢ Sistemas Operativos
 ¿Cuál es la utilidad del tema para nuestro desarrollo?

Reconocer el provecho de incorporar las herramientas del

desarrollo de software en general, tales como la arquitectura,
lenguajes de programación y técnicas de la ingeniería de
diseño, lo que nos permitirá desarrollar un software
profesional de calidad y altamente comprometido con la
transformación tecnológica mundial.
Ciclo de vida del
desarrollo de
software
 Contenido

➢ DESARROLLO DE SOFTWARE
✓ Arquitectura de software
✓ Lenguajes de Programación
✓ Paradigmas de Programación
✓ Versionamiento Git
DESARROLLO DE SOFTWARE
Proceso de desarrollo de aplicaciones software
Un proceso de desarrollo de software es la descripción de
una secuencia de actividades que deben ser seguidas por un
equipo de trabajadores para generar un conjunto coherente
de productos, uno de los cuales es el programa del sistema
deseado.
El objetivo básico del proceso es hacer predecible el trabajo
que se requiere:
➢ Predecir el costo.
➢ Mantener un nivel de calidad
➢ Predecir el tiempo de desarrollo
Naturaleza de las aplicaciones software

No existe un proceso de desarrollo universal.

Debe configurarse de acuerdo con la naturaleza del producto

y de la experiencia de la empresa.
Tipos de aplicaciones:
➢ Aplicaciones Monoprocesadoras: Se ejecutan en un solo
computador. No se comunica con otras aplicaciones. Ej.
Procesador de texto.
➢ Aplicaciones Embebidas: Se ejecuta en un entorno computarizado
especial. Requiere codiseño hardware/software. Ej: Teléfono
móvil.
➢ Aplicaciones de Tiempo Real: Tiene entre sus especificaciones
requerimiento temporales; es de naturaleza reactiva. Ej: Software
de radar.
➢ Aplicaciones Distribuidas: Se ejecuta en múltiples procesadores.
Requiere intercomunicación a través de la red. Ej: Aplicaciones de
red.
Objetivos de un proceso de desarrollo
Proporcionar una guía de ejecución del proyecto que defina
para los técnicos la secuencia de tareas que se requieren y
los productos que deben generar.
Mejorar la calidad del producto en:
✓ Disminuir el número de fallos
✓ Bajar la severidad de los defectos
✓ Mejorar la reusabilidad
✓ Mejorar la estabilidad del desarrollo y el costo de
mantenibilidad
✓ Mejorar la predictibilidad del proyecto en:
▪ La cantidad de trabajo que requiere
▪ El tiempo de desarrollo que se necesita

✓ Generar la información adecuada a los diferentes

responsables de forma que ellos puedan hacer un
seguimiento efectivo.
Elementos básicos de un proyecto
Planificación
Escalabilidad

Es una propiedad importante de un

proceso, ya que las dimensiones de
los proyectos de software son muy
variables.
Describe, si el esfuerzo que se
requiere en el desarrollo de un
proyecto varía suavemente
(linealmente) con su complejidad.
➢ Cuando la complejidad de un proyecto crece:
✓ Aumentan los niveles de abstracción que se usan.
✓ Se incrementa la intercomunicación entre los miembros.
✓ Es más difícil localizar los errores.
Hay que buscar que el esfuerzo crezca linealmente y no
exponencialmente.
➢ Formas de conseguir la escalabilidad:
✓ Disponer de diferentes escalas temporales para generar
las actividades.
✓ Hacer que las guías y plantillas tengan optatividad de
acuerdo con las características del proyecto.
 Llaves
tecnológicas
para los
procesos de
desarrollo
Principales tareas de los procesos software

➢ Entender la naturaleza de la aplicación.

➢ Establecer el plan de trabajo.
➢ Generar y gestionar la documentación.
➢ Captura de los requerimientos.
➢ Diseñar y construir el producto.
➢ Probar y validar el producto.
➢ Entregar y mantener el producto.
Niveles de madurez de los procesos de desarrollo
➢ Primitivo: No existe.
➢ Programado: Tiene definido una secuencia de etapas y los
resultados que deben generar cada una de ellas.
➢ Sistemático: Esta formulado de forma sistemática.
➢ Administrado: Incorpora criterios para cuantificar el
rendimiento de cada fase y del proceso.
➢ Optimizado: Dispone de parámetros de control que
permite su optimización a las características del proyecto.
Modelo de procesos lineales

Modelo Túnel:
➢ Ausencia de modelo
➢ No hay ningún control
➢ Sólo válido en proyectos muy pequeños.
Modelo en cascada
Problemas del proceso en cascada

❑ La prueba efectiva solo se hace cuando ya está todo

diseñado.
❑ Presupone que el producto está perfectamente definido
antes de iniciar el desarrollo.
❑ Cuando se descubren problemas en la fase de
mantenimiento sólo cabe adaptar el problema a la
aplicación, y no al revés.
Proceso en espiral
❑ La aplicación es desarrollada en sucesivas fases por
evolución de sistemas mas simples a sistemas más
complejos.
❑ En la naturaleza y en la tecnología, los sistemas
complejos han sido siempre resultado de la evolución de
sistemas más simples.
❑ La programación orientada a objetos facilita la
programación evolutiva:
✓ Se diseñan prototipos con solo algunos objetos.
✓ Se diseñan prototipos con objetos con funcionalidad
limitada.
Características del proceso iterativo

❑ El proceso iterativo se basa en producir sucesivos

prototipos (sistemas ejecutables) que van evolucionando
desde requerimientos muy simples hasta los completos.

❑ El desarrollo evolutivo de los prototipos facilita afrontar los

problemas de mayor riesgo al principio.
❑ A lo largo del desarrollo se van mostrando prototipos
reales a los usuarios y clientes:
✓ El usuario se enfrenta al producto de forma real.
✓ El cliente se hace colaborador del proyecto.
✓ El equipo está continuamente motivado por objetivo
próximos.
✓ La integración de los componentes es gradual.
✓ Los progresos se evalúan de forma tangible y no sobre
papel.
N minicascadas

En el proceso iterativo, cada ciclo reproduce básicamente un

ciclo en cascada, solo que con objetivos mas simples.
Variantes de ciclo iterativo
Generación de requerimientos
Proceso de desarrollo de Rational (USPD)

Rational propone un proceso basado en tres criterios:

➢ Guiado por “Casos de Uso”.

➢ Centrado sobre la “Arquitectura”.
➢ Estrategia “Iterativa e Incremental”.
Casos de uso

❑ Los casos de uso definen la funcionalidad de la

aplicación.
❑ Los casos de uso constituyen guías transversales que
dirigen todas las fases del proceso:
✓ Especificación
✓ Análisis
✓ Diseño
✓ Verificación y prueba
Arquitectura de software
 Esquema

Definiciones de arquitectura software

¿Qué es arquitectura del software?
Stakeholders
Atributos de calidad
Restricciones
¿Qué es la arquitectura?

Etimológicamente, viene del griego:

Arquitectura = ἀρχιτέκτων
ἀρχι - "jefe"
Τέκτων - "creador"
Architecture = Proceso y producto de planificar, diseñar y
construir edificios u otras estructuras.
Vitruvius, "De arquitectura"
Escrito entre 30 y 15 antes de Cristo.
3 pilares de una buena arquitectura:
Utilitas (utilidad):
Ser útil y funcionar bien para las personas que lo van a
usar.
Firmitas (durabilidad):
Mantenerse de forma robusta y en buena condición.
Venustas (elegancia):
Ser agradable a las personas.
Lo mismo puede aplicarse a los sistemas de software.
Arquitectura [ISO/IEC/IEEE 42010:2011, 3.2]
Conceptos fundamentales o propiedades de un Sistema en su
entorno representados por sus elementos, relaciones y los
principios de su diseño y evolución.

Descripción de arquitectura
Producto de trabajo explícito que expresa una arquitectura de
un sistema, normalmente a través de modelos, texto o
gráficos.
Diseñar una arquitectura (architecting)
Proceso de crear una arquitectura
Arquitectura vs diseño
Arquitectura se enfoca en estructura de alto nivel de un
sistema de software.

Decisiones principales de diseño del sistema:

Si hay que cambiarlas ⇒ Coste elevado

"Toda arquitectura conlleva diseño

pero no todo el diseño es arquitectura“
G. Booch
Arquitectura de edificios vs software
Similaridades
Pero muchas diferencias ...
Edificios tradicionales:
▪ Entornos y contexto más estables
▪ Servicio/producto físico
▪ Límites físicos
▪ Gran tradición e historia
▪ Nos sirve para inspiración
Sistemas complejos
Desarrollados por equipos/organizaciones
Utilizados por personas
Ambos emplean estilos, patrones, tácticas, ...
Y están afectados por tendencias.
Software:
▪ Múltiples cambios en contexto
▪ Servicio/producto virtual
▪ No suele haber límites físicos
▪ Disciplina relativamente nueva
▪ Podemos aprender mucho de otras
Otras disciplinas similares:
Ingenierías Civil, Mecánica, Aeronáutica ...
Otras arquitecturas:
✓ Arquitectura de negocios
✓ Arquitectura empresarial
✓ Arquitectura de sistemas
✓ Arquitectura de la información
✓ Arquitectura de datos
✓...
Cosas comunes a todas: Estructura y visión
Beneficios arquitectura del software
✓ Proporcionar visión y mapa a seguir por el equipo
✓ Liderazgo y coordinación técnica
✓ Responder cuestiones sobre decisiones significativas,
atributos de calidad y otras preocupaciones
✓ Marco para identificar y mitigar riesgo
✓ Gestión consistente de estándares y código
✓ Fundamentos firmes del producto a desarrollar
✓ Estructura para comunicarla solución a diferentes niveles
de abstracción y audiencias
Retos de la arquitectura del software:

Arquitectos en la torre de marfil

Falta de comunicación
Centralización de todas las decisiones
Arquitecto = cuello de botella
Tomar demasiadas decisiones
Retrasar ciertas decisiones puede ser mejor que deshacerlas
Big DesignUp-Front
Demasiados diagramas y documentos innecesarios
Retardos debidos al proceso de arquitectura
Arquitectura de software ágil
➢ Arquitectura que puede reaccionar a cambios en el
entorno.
➢ Adaptación a cambios continuos.
➢ También conocidas como arquitecturas evolutivas.
➢ Buena arquitectura permite agilidad.
➢ Mejor comprensión de decisiones y soluciones de
compromiso.
➢ Anti-patrón común: adopción de técnicas de desarrollo de
software ágil que crean arquitecturas que no son ágiles.
➢ Causado por demasiado enfoque en funcionalidad.
Leyes de la arquitectura del software
1er ley:
Todo en arquitectura del software es una solución de compromiso.

2ª ley:
Porqué es más importante que cómo
Cuestionar todo
Documentar decisiones tomadas
Proceso de diseñar una arquitectura
Dominio del problema Dominio de la solución

ARQUITECTO

Diseño de la
Arquitectura
(ENTRADAS) (SALIDA)
Motivaciones proceso de arquitectura

Entradas
✓ Objetivos de diseño
✓ Requisitos funcionales
✓ Atributos de calidad
✓ Restricciones
Preocupaciones
Objetivos de diseño

Aclarar porqué se diseña un sistema.

Ejemplos:
Propuesta de pre-venta: diseño rápido de una solución
inicial para obtener una estimación.
Sistema a medida con un tiempo y coste establecido que
no puede variar mucho una vez enviado.
Incremento nuevo ó versión de un sistema que está
continuamente evolucionando.
Requisitos funcionales
➢ Funcionalidad que debe soportar los objetivos de negocio
➢ Lista de requisitos como casos de uso o historias de
usuario

Use cases User stories

Atributos de calidad
Características medibles de interés para usuarios o desarrolladores.
También conocidos como requisitos no-funcionales:
Rendimiento, disponibilidad, modificabilidad, testabilidad, …
También conocidos como –idades (-ities en inglés)
Pueden especificarse mediante escenarios
Técnica estímulo-respuesta
“Si ocurre un fallo interno durante la operación normal, el sistema
reanuda la operación en menos de 30 segundos y no se pierden datos”
Priorizados por:
El cliente de acuerdo al éxito del sistema
El arquitecto de acuerdo al riesgo técnico
ISO 25010: lista de algunos requisitos no funcionales.
Atributos de calidad
Los atributos de calidad determinan la mayoría de las decisiones de
diseño en arquitectura.
Si la única preocupación fuese la funcionalidad, un sistema monolíticos
sería suficiente.
Sin embargo, es habitual ver:
Estructuras redundantes para fiabilidad
Estructuras concurrentes para rendimiento
Capas para modificabilidad
…
Priorizados por:
El cliente de acuerdo al éxito del sistema
El arquitecto de acuerdo al riesgo técnico.
Restricciones
Restricciones del sistema que vienen impuestas.
▪ Muy poco software tiene libertad total
▪ Pueden ser técnicas u organizativas
▪ Pueden surgir del cliente o también de la organización de desarrollo
▪ Limitan las alternativas a considerar para decisiones de diseño
particulares
Ejemplos:
Marcos de aplicaciones (frameworks)
Lenguajes de programación, ...
Normalmente son tus “amigos”.
Preocupaciones
Decisiones de diseño que deben tomarse aunque no estén
enunciadas explícitamente en los objetivos o requisitos.

Ejemplos:
▪ Crear una estructura física o lógica consistente
▪ Validar campos de entrada
▪ Gestión de excepciones y logging
▪ Migración de datos y backup
▪ Organización del código fuente
▪ …
Creatividad vs método:
Arquitecto del software
La disciplina evoluciona.
Arquitecto debe conocer:
Avances en técnicas de construcción
Estilos y patrones
Mejor herramienta = experiencia (no silverbullet)
Experiencia propia
Experiencia de la comunidad.
Papel del arquitecto de software
Lenguajes de Programación
Un lenguaje de programación consiste en un conjunto de
órdenes o comandos que describen el proceso deseado.
Cada lenguaje tiene sus instrucciones y enunciados verbales
propios, que se combinan para formar los programas de
cómputo.

Los lenguajes de programación no son aplicaciones, sino

herramientas que permiten construir y adecuar aplicaciones.
Existen muchos lenguajes de programación con
características y aptitudes muy diferenciadas. Todo ello se
encuentra en dos grandes grupos:

➢ Los lenguajes máquina.

➢ Los lenguajes simbólicos. Lenguaje de programación en el
que las instrucciones de los diferentes programas se
codifican utilizando los caracteres de las lenguas
naturales. La ejecución de un programa.
Entre los primeros se encuentran los denominados lenguajes
en código máquina. En estos lenguajes, la codificación de
estos lenguajes se hace utilizando un lenguaje binario de
ceros y unos que son los únicos símbolos que puede
entender cualquier computador.

Cada sistema físico tiene su código máquina distinto por lo

que un programa escrito en un determinado código máquina
sólo vale para un sistema físico.
A los lenguajes máquina les sucedieron, los lenguajes
simbólicos los cuales utilizan caracteres naturales para
escribir las instrucciones de los programas. Los lenguajes
simbólicos se dividen a su vez en:

✓ Lenguajes simbólicos de bajo nivel o ensambladores.

✓ Lenguajes simbólicos de alto nivel.
Dentro de los segundos se puede distinguir a su vez
los lenguajes procedurales y los relacionales.

1. Un lenguaje procedural es aquel lenguaje de programación en el

que hay que señalar tanto lo que se quiere hacer como el modo
de hacerlo. Los lenguajes de tercera generación son de tipo
procedural.

2. Un lenguaje relacional es un tipo de lenguaje de programación en

el que sólo hay que especificar lo que se quiere obtener, sin
necesidad de especificar a su vez el camino a seguir para obtener
los resultados deseados. Este tipo de lenguaje son de muy alta
productividad en desarrollo pero muy ineficientes en ejecución.
Los lenguajes de alto nivel permiten a los
profesionales resolver problemas convirtiendo sus algoritmos
en programas escritos en alguno de estos lenguajes de
programación.
Traductores de lenguaje:
el proceso de traducción de un programa

El proceso de traducción de un programa fuente escrito en

un lenguaje de alto nivel a un lenguaje máquina
comprensible por la computadora, se realiza mediante
programas llamados “traductores”.
Los traductores de lenguaje son programas que traducen a
su vez los programas fuente escritos en lenguajes de alto
nivel a código máquina. Los traductores se dividen en
compiladores e intérpretes.
Intérpretes

Un intérprete es un traductor que toma un programa fuente,

lo traduce y, a continuación, lo ejecuta. Los programas
intérpretes clásicos como BASIC, prácticamente ya no se
utilizan, más que en circunstancias especiales. Sin embargo,
está muy extendida la versión interpretada del lenguaje
Smalltalk, un lenguaje orientado a objetos puro.
El sistema de traducción consiste en: traducir la primera
sentencia del programa a lenguaje máquina, se detiene la
traducción, se ejecuta la sentencia; a continuación, se
traduce la siguiente sentencia, se detiene la traducción, se
ejecuta la sentencia y así sucesivamente hasta terminar el
programa.
Intérprete.
Compiladores

Un compilador es un programa que traduce los programas

fuente escritos en lenguaje de alto nivel a lenguaje máquina.
La traducción del programa completo se realiza en una sola
operación denominada compilación del programa; es decir,
se traducen todas las instrucciones del programa en un solo
bloque.
El programa compilado y depurado (eliminados los errores
del código fuente) se denomina programa ejecutable porque
ya se puede ejecutar directamente y cuantas veces se
desee; sólo deberá volver a compilarse de nuevo en el caso
de que se modifique alguna instrucción del programa. De
este modo el programa ejecutable no necesita del
compilador para su ejecución.

Los lenguajes compiladores típicos más utilizados son: C,

C++, Java, C#, Pascal, FORTRAN y COBOL.
La compilación de programas.
La compilación y sus fases

La compilación es el proceso de traducción de programas

fuente a programas objeto. El programa objeto obtenido de
la compilación ha sido traducido normalmente a código
máquina.
Para conseguir el programa máquina real se debe utilizar un
programa llamado montador o enlazador (linker). El proceso
de montaje conduce a un programa en lenguaje máquina
directamente ejecutable como se muestra en la figura
siguiente.
Fases de la compilación.
El proceso de ejecución de un programa escrito
en un lenguaje de programación y mediante un compilador
suele tener los siguientes pasos:

1. Escritura del programa fuente con un editor (programa que

permite a una computadora actuar de modo similar a una
máquina de escribir electrónica) y guardarlo en un
dispositivo de almacenamiento (por ejemplo, un disco).
2. Introducir el programa fuente en memoria.
3. Compilar el programa con el compilador C.
4. Verificar y corregir errores de compilación (listado de
errores).
5. Obtención del programa objeto.
6. El enlazador (linker) obtiene el programa ejecutable.
7. Se ejecuta el programa y, si no existen errores, se tendrá
la salida del programa.
Ejecución de un programa.
 Fases de
ejecución de un
programa.
Elementos del lenguaje
Instrucciones
Datos: literales, variables, tipos
Subprogramas (funciones)
Comentarios
Directivas
Sintaxis y semántica de los lenguajes

Sintaxis
➢ Reglas que determinan cómo se pueden construir y
secuenciar los elementos del lenguaje
Semántica
➢ Significado de cada elemento del lenguaje ¿Para qué
sirve?
Un programa que muestra un saludo en la pantalla:
Análisis
del
programa:
Hola Mundo!
Casi todo es infraestructura

Sólo:
cout << "Hola Mundo!" << endl
hace algo palpable

La infraestructura (notación, bibliotecas y otro soporte) hace

nuestro código simple, completo, confiable y eficiente
¡El estilo importa!
Paradigmas en lenguajes de programación
Existen diversos lenguajes y paradigmas de programación
que se han diseñado para facilitar la tarea de la
programación en diferentes ámbitos.

Existen cuatro modelos básicos de computación que

describen casi todos los lenguajes de programación
actuales: el imperativo, el aplicativo, el lenguaje con base en
reglas y el orientado a objetos.
Lenguajes imperativos

Los lenguajes imperativos o de procedimiento son lenguajes

controlados por mandatos u orientados a enunciados
(instrucciones).

Un programa se compone de una serie de enunciados, y la

ejecución de cada enunciado hace que el intérprete cambie
el valor de una localidad o más en su memoria, es decir, que
pase a un nuevo estado.
El desarrollo de programas consiste en construir los estados
de máquina sucesivos que se necesitan para llegar a la
solución.

Esta suele ser la primera imagen, que se tiene de la

programación, y muchos lenguajes de uso amplio (por
ejemplo, C, C++, FORTRAN, ALGOL, PL/I, Pascal, Ada,
Smalltalk, COBOL) manejan este modelo.
Lenguajes aplicativos

Un punto de vista alternativo de la computación

representado por un lenguaje de programación consiste en
examinar la función que el programa representa y no sólo los
cambios de estado conforme el programa se ejecuta,
enunciado por enunciado.

Esto se puede conseguir observando el resultado deseado

en vez de los datos disponibles.
En otras palabras, en vez de examinar la serie de estados a
través de los cuales debe pasar la máquina para obtener una
respuesta, la pregunta que se debe formular es: ¿Cuál es la
función que se debe aplicar al estado de máquina inicial
accediendo al conjunto inicial de variables y combinándolas
en formas específicas para obtener una respuesta?

Los lenguajes que hacen énfasis en este punto de vista se

conocen como lenguajes aplicativos o funcionales.
Lenguajes con base en reglas
Los lenguajes con base en reglas se ejecutan verificando la
presencia de una cierta condición habilitadora y, cuando se
satisface, ejecutan una acción apropiada. El lenguaje más
común con base en reglas es Prolog, que también se conoce
como de programación lógico, puesto que las condiciones
habilitadoras básicas son ciertas clases de expresiones
lógicas de predicados.

La ejecución de un lenguaje con base en reglas es similar a

la de un lenguaje imperativo, excepto que los enunciados no
son secuenciales.
Programación orientada a objetos.

En este tipo de lenguaje, se construyen objetos complejos de

datos y luego designa un conjunto limitado de funciones para
que operen con esos datos. Los objetos complejos se designan
como extensiones de objetos más simples y heredan
propiedades del objeto más sencillo.

Al construir objetos concretos de datos, un programa orientado a

objetos gana la eficiencia de los lenguajes imperativos, y al
construir clases de funciones que utilizan un conjunto restringido
de objetos de datos, se construye la flexibilidad y confiabilidad
del modelo aplicativo.
Versionamiento Git
¿Qué es Git?

Como seguramente sabrás, Git es un sistema de control de

versiones distribuido desarrollado por Linux Torvalds en el
ano 2005 y que se ha hecho tremendamente popular gracias
a servicios como GitHub, Bitbucket o GitLab y a su amplia
aceptación en proyectos importantes como el Kernel de
Linux, Android, Ruby on Rails, Eclipse, GNOME, KDE, Qt,
Perl o PostgreSQL o por empresas como Google, Facebook,
Microsoft, Twitter, LinkedIn o Netflix.
¿Por qué Git?

Si eres programador, desarrollador web, administrador de

sistemas, diseñador, … es muy probable que en algún
momento de tu trabajo te encuentres con un proyecto en el
que tengas que colaborar con otras personas usando Git.

Puede que trabajes solo pero que te interese tener un

seguimiento y control de tu trabajo.
En estos dos casos y en muchos más un conocimiento mas
o menos profundo de Git te permitirá ser mucho mas
productivo en tu trabajo y, sobre todo, evitar muchos de los
problemas con los que se encuentra a menudo la gente que
no trabaja con un sistema de control de versiones.

Si tu ámbito de trabajo es técnico y aun no usas Git, cuando

lleves unos meses usándolo te preguntarás cómo es posible
que no lo hubieras empezado a usar antes.
Git:
Git es una herramienta gratuita y de código abierto para el
control de versiones en forma distribuida, diseñado para
manejar desde un proyecto pequeño hasta un gran proyecto
en forma rápida y eficiente.

GitHub:
GitHub es un repositorio web basado en Git que presta
servicios de hosting, ofrece todas las opciones de control de
versiones distribuido y la administración del código fuente
similar a Git, así mismo agrega algunas funciones
adicionales.
¿Qué es un sistema de control de versiones?

Un Sistema de Control de Versiones (SCV) es una aplicación

que permite gestionar los cambios que se realizan sobre los
elementos de un proyecto o repositorio, guardando así
versiones del mismo en todas sus fases de desarrollo.
➢ Registra cada cambio en el proyecto o repositorio, quién y
cuándo lo hace, en una base de datos.
➢ Permite volver a estados previos del desarrollo.
➢ Permite gestionar diferentes versiones del proyecto
(ramas) para trabajar en paralelo y luego fundirlas.
➢ Permite colaborar entre diferentes usuarios en un mismo
repositorio, facilitando la resolución de conflictos.
➢ Se utiliza principalmente en proyectos de desarrollo de
software, pero sirve para cualquier otro tipo de proyecto.
Configuración de Git
git config
Establecer el nombre de usuario:
git config --global user.name "Your-Full-Name"
Establecer el correo del usuario:
git config --global user.email "your-email-address"
Activar el coloreado de la salida:
git config --global color.ui auto
Mostrar el estado original en los conflictos:
git config --global merge.conflictstyle diff3
Mostrar la configuración:
git config --list
 Proceso ROPES
(Rapid Object-Oriented Process for Embedded Systems)

El proceso ROPES es un proceso de desarrollo de

aplicaciones software de propósito general (aplicable a
cualquier tipo de aplicación) que enfatiza los aspectos de
ingeniería software, integración de los sistemas y sus
pruebas.
1 año
Iteración de cada Microciclo en el proceso ROPES
 Ciclo de vida de
desarrollo de
sistemas/software
 Ciclo de vida de
desarrollo de
sistemas/software
 Ciclo de vida de
desarrollo de
sistemas/software
 Ciclo de vida de
desarrollo de
sistemas/software
 Ciclo de vida de
desarrollo de
sistemas/software
 Ciclo de vida de
desarrollo de
sistemas/software
 Ciclo de vida de
desarrollo de
sistemas/software
 Ciclo de vida de
desarrollo de
sistemas/software
 Ciclo de vida de
desarrollo de
sistemas/software
 Ciclo de vida de
desarrollo de
sistemas/software
Conclusiones
➢ Luego de ver algunos de los modelos de desarrollo de software
más utilizados surge la pregunta con la respuesta más codiciada:
¿qué modelo de ciclo de vida elegir? Sabemos que ninguno
predomina sobre los otros. Por ello, debemos elegir el modelo que
mejor se adapte al proyecto que desarrollaremos.
➢ Podemos analizar, para guiarnos en nuestra elección, la
complejidad del problema, el tiempo que disponemos para hacer
la entrega final, o si el usuario o cliente desea entregas
parciales, la comunicación que existe entre el equipo de
desarrollo y el usuario y, por último, qué certeza (o incertidumbre)
tenemos de que los requerimientos dados por el usuario son
correctos y completos.
¿Qué hemos aprendido en la sesión?

• Los modelos de desarrollo de software y sus

características.
• Las características arquitectónicas de todo software.
• Los leguajes y paradigmas de programación en
vigencia.
• Las características del versionamiento Git y su
vigencia.