Ingenieria de Software

Preguntas detonantes
• ¿ Q u e e s l a i n g e n i e r í a d e s of t w a re ?
• ¿ C u a l e s l a d i f e re n c i a e n t re P ro g r a m a d o r
d e S of t w a re , D e s a r ro l l a d o r d e S of t w a re e
I n g e n i e ro d e S of t w a re ?
Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

CONCEPTO
Ingeniería de Sof tware
Enfoque sistémico, disciplinado y cuantificable del
desarrollo de software, con calidad, en el tiempo
determinado y con el presupuesto previsto, apoyado por
metodologías, herramientas y técnicas

Ingeniería de Software
I n g e n i e r í a d e S o f t w a re
• Evaluación del proyecto
• Gestión de la Configuración
• Aseguramiento de la Calidad
• Gestión de la Seguridad de la Información
• …
Desarrollo de Software
• Análisis
• Diseño
Programación
• Codificación
• Pruebas
• Implementación
• Mantenimiento

SDLC
¿Que es el SDLC?
¿Cuantas y cuales son sus fases?

CONCEPTO
Ciclo de Vida del Desarrollo de Sof tware
Secuencia estructurada y bien definida de las etapas
(fases) en Ingeniería de software para desarrollar un
producto de software con calidad.

Procesos del ciclo de vida
ISO 12207
2. Métodos de Desarrollo de sof tware

Product
Governance
Assessment
Implementation and
Life Cycle Processes Assessment Characteristics
42010 And
42030 Systems Engineering Software Engineering Certification
9001 Architecture
Quality System
15288 12207 15504 9126
330xx 14598
38500 24748-2 24748-3 14756
Governance 29169 Software Quality
15289 Process
26511 24748-4 Assessment
26512 90005 19770-1 25000

Fundation 26513 90003 Series
19770-5 Software Quality
26514 19770-8 SQuaRE
24765 26515 24748-1 29110 Asset
Vocabulary Documentation Management
Life Cycle Management Very Small Entities
14143
24774 IT Service 19761
Process
Description
29148 29119 14764 Management 20926
Requirements Testing Software Manintenance 20968
20000 24570
BOK 16326 15026, 16085 15939, 29155 29881
and Prject Management Risk and Integrity Measurement 90006 Software Functional
Size Measurement
Professionalization
16337
19759 3535, 5806 14102, 14471 10746, 13235, 14750 8807, 15437 14568
Tools and
BOK
Methods
5807, 8631 15940, 18018 14752, 14753, 14769 15909, 19501 15474
24773 8790, 11411 23026, 24766 14771, 15414, 19500 19505, 19793 15475
29154 12182, 14759 26500, 26501 19770-2, 19770-3 24744, 19505 15476
Cerification
SC7 Legacy Standards Tools, Methods and
Envirinment 19770-6, 19770-7 19507 19506
Specification Modeling Interchange

Forward
12207.0
1. Scope
2. References
3. Definitions
4. Application
5. Primary processes
6. Supporting processes
7. Organizational processes
Annexes A - D
Annexes E - J
12207.2

ISO/IEC/IEEE 12207
5. Primary Processes / Procesos primarios 6. Supporting Processes
https://www.dote.osd.mil/Portals/97/docs/TEMPGuide/IEEE_EIA_12207.2_1997.pdf
/ Procesos de apoyo
5.1. Acquisition / Adquisición
6.1. Documentation / Documentación
5.2. Supply / Suministro
6.2. Configuration Management /
5.4. Operation / Gestión de la configuración
5.3. Development Operación
/ Desarrollo 6.3. Quality Assurnce / Aseguramiento
5.5. Maintenance /
Mantenimiento de la calidad
6.4. Verification / Verificación

7. Organizational Processes
/ Procesos Organizacionales 6.5. Validation / Validación
7.1. Management / Gestion 6.6. Joint Review / Revisión conjunta

7.2. Infrastruture / Infraestructura 6.7. Audit / Auditoría
7.3. Improvement / Mejoramiento
6.8. Problem Resolution / Resolución del
7.4. Training / Capacitación problemas

5 . P ro c e s o s P r i m a r i o s
5.1.- Proceso de adquisición: Define las actividades del adquiriente, la organización
que adquiere un sistema, producto de software o servicio de software.
5.2.- Proceso de suministro: Define las actividades del proveedor, organización que
proporciona un sistema, producto de software o servicio de software al adquiriente.
5.3.- Proceso de desarrollo: El Proceso de Desarrollo contiene las actividades y tareas
del desarrollador.
5.4.- Proceso de operación: Define las actividades del operador, organización que
proporciona el servicio de operar un sistema informático en su entorno real, para sus
usuarios.
5.5.- Proceso de mantenimiento: Define las actividades del responsable de
mantenimiento, organización que proporciona el servicio de mantenimiento del
producto software; esto es, la gestión de las modificaciones al producto software
actualizada y operativa.

5.1. Acquisition / Adquisición 5.2. Supply / Suministro
5.1.1. Initiation / Iniciación 5.2.1. Initiation / Iniciación
5.1.2. Request-for-proposal Preparation / Preparación de solicitud de propuesta 5.2.2. Preparation of response / Preparación de respuesta
5.2.3. Contact / Contacto

5.1.3. Contract preparation and update / Preparación del contrato y actualización
5.2.4. Planning / Planificación
5.1.4. Supplier Monitoring / Monitoreo de proveedores
5.2.5. Execution and control / Ejecución y control
5.1.5. Acceptance and completion / Aceptación y finalización
5.2.6. Review and evaluation / Revisión y evaluación
5.3. Development / Desarrollo 5.2.7. Delivery & completion / Entrega y finalización
5.3.13. Software acceptance support 5.4. Operation / Operación

5.3.1. Process implementation
5.3.12. Software installation 5.4.1. Process implementacion 5.4.2. Operational testing
5.4.3. System operation 5.4.4. User support

5.3.2. System requirements analysis 5.3.11. System qualification testing
5.5. Maintenance / Mantenimiento
5.3.3. System architecture analysis 5.3.10. System Integration
5.3.4. Software requirements design 5.3.9. Software qualification testing 5.5.2. Problem and modification analysis
5.5.3. Modification implementation

5.3.5. Software architecture design 5.3.8. Software Integration
5.5.4. Maintenance review - acceptance
5.3.6. Software detailed design
5.5.5. Migration
5.3.7. Software coding and testing 5.5.6. Software retrement

CONCEPTO
ISO/IEC/IEEE 12207
Norma encargada del ciclo de vida del software, cubre
desde la conceptualización hasta su retirada y proporciona
una estructura y un lenguaje en común para todos los
involucrados en el desarrollo.

Procesos del ciclo de vida
ISO 12207

ISO/IEC/IEEE 12207
/ Procesos de apoyo
5.5. Maintenance /







5.5.5. Migration

Ciclo de Vida del Desarrollo de Software
Proceso de adquisición
Define las actividades del adquiriente, la organización que adquiere un sistema, producto de
software o servicio de software.
Las obligaciones y derechos

Del CLIENTE del servicio





5.5.5. Migration

5.2 Proceso de suministro
Define las actividades del proveedor, organización que proporciona un sistema, producto de
software o servicio de software al adquiriente.
Incluye el Plan de Gestión del Proyecto – Project Management Plan
Las obligaciones y derechos del

PROVEDDOR del servicio

5.3.13. Software acceptance support /
5.3.1. Process implementation / Soporte de aceptación de software
Proceso de implementación 5.3.12. Software installation /
Instalación de software
5.3.2. System requirements analysis / 5.3.11. System qualification testing /

Análisis de requisitos de sistema Prueba de calificación del sistema
5.3.3. System architecture analysis / 5.3.10. System Integration /
Análisis de arquitectura de sistema Integración de sistema
5.3. Development / Desarrollo
5.3.4. Software requirements design / 5.3.9. Software qualification testing /

Diseño de requisitos de software Prueba de calificación de software
5.3.5. Software architecture design / 5.3.8. Software Integration /

Diseño de arquitectura de software Interacción de software
5.3.6. Software detailed design /

Diseño detallado de software
5.3.7. Software coding and testing /

Codificación y pruebas de software

Codificación
Se codifica la solución de software mediante la selección de la metodología de desarrollo
HACER la solución
Pruebas de software en busca de:
• Errores | Mal funcionamiento | Situaciones no deseadas
BUSCAR y CORREGIR errores





5.5.5. Migration

Implementación / Operación
Se instala la solución, y se:
• Capacita a los usuarios finales y personal técnico que administrara el sistema
• Planea y ejecuta la migración del sistema antiguo al nuevo, si se requiere.
• Construye la estructura de datos
• Configura la plataforma final
Existen cuatro tipos de implementación:

• Directo
• Paralelo
• Piloto
• fases
Poner en operación





5.5.5. Migration

Mantenimiento
Se modifica el software para corregir, mejorar, o adaptar las necesidades cambiantes del
cliente o el entorno, es decir, se aplica una evaluación y el software sufre una evolución.
Tipos de mantenimientos:
• Mantenimiento Correctivo
• Mantenimiento Adaptativo
• Mantenimiento Perfectivo
• Mantenimiento Preventivo
Incluye la retirada del Software
Evaluación y evolución

Proyecto de consola .Net core

Comandos básicos
Windows PowerShell / Linux / Mac OS Description

ls List files and folders
pwd Full path of current folder/directory
cd <path> Change folder/directory
cd .. One directory up in directory tree
clear Clear the terminal screen
mkdir Folder Create new directory

rmdir Folder Remove a directory (/s)
rm File Remove a file*

cp File <path> Copy a file
mv File <path> Move a file
more File Show content of file
Crear y ejecutar una aplicación .Net
\> mkdir Project
Directorio: C:\Users\user
Mode LastWriteTime Length Name

---- ------------- ------ ----
d----- 04/07/2020 08:40 a. m. folder
\> cd Project
\Project> dotnet new console

The template "ASP.NET Core Console App" was created successfully.
This template contains technologies from parties other than Microsoft, see https://aka.ms/aspnetcore/3.1-third-party-notices for details.
Processing post-creation actions...

Running 'dotnet restore' on C:\Users\user\folder\Program.csproj...
Determinando los proyectos que se van a restaurar...
Se ha restaurado C:\Users\user\folder\Program.csproj (en 193 ms).
Restore succeeded.
\Project> dotnet run

Hello World!

Crear y ejecutar una aplicación .Net
\Project> code .

Arquitectura de sistemas

CONCEPTO
Arquitectura
Es la organización fundamental de un sistema que
representa sus componentes y sus relaciones entre sí y con
ANSI / IEEE 1471

el medio ambiente, además de los principios que rigen su
diseño y evolución

SA SA
Solution Business
Architecture
Data /
Processes
MACRO
POINT
TA
Enterprise Architecture
Architecture
DETAILED
Applications
Technical
TA
Infraestructure
EA

Arquitectura
Niveles
Enterprise Architecture | Architectural Frameworks and Models
Solution Architecture | Architectural Styles | Architectural Patherns
Technical Architecture | Software Design Patterns
EA Enterprise
System
Abstract
Architectural Frameworks and Models

Architecture
SA Solution Architectural Patherns

Architecture
Architectural Styles
MACRO
POINT
TA Technical
DETAILED
Software
Architecture
Software Design Patterns
Detail

CONCEPTO
Arquitectura Empresarial
Práctica estratégica que explica las estructuras
fundamentales y su funcionamiento en la organización,
permite alinear las estrategias del negocio con TI desde la
visión actual hacia una visión futura.
Se centra en la construcción de ecosistemas empresariales

complejos y resuelve problemas estratégicos de alto nivel.
CONCEPTO
Marcos y Modelos de Arquitectura
Provee un lenguaje común y herramientas de soporte que
proporciona directrices sobre cómo describir o documentar
la arquitectura de manera uniforme y consistente.
Instrumento principal para implementar la Arquitectura Empresarial, y a su vez,

habilita o permite hacer realidad la Estrategia de Negocio.
Enterprise Architecture EA
Marcos y Modelos de Arquitectura Empresarial
• Zachman framework (IBM de los años 80)
• DoDAF (United States Department of Defense Architectural Framework)
• FEAF (United States Office of Management and Budget Federal Enterprise Architecture)
• MODAF (United Kingdom Ministry of Defence Architectural Framework)
• AGATE (French Délégation Générale pour l'Armement Atelier de Gestion de l'ArchiTEcture des
systèmes d'information et de communication)
• Service-Oriented Modeling Framework (SOMF)
• Gartner
• OBASHI (The OBASHI Business & IT methodology and framework)
• TOGAF (The Open Group Architecture Framework)
• 4+1 Model
• ISO/IEC/IEEE 42010

TOGAF (The Open Group
Architecture Framework)
4+1 Model

CONCEPTO
Arquitectura de Solución
Descripción abstracta de una solución específica desde
diferentes puntos de vista (empresarial, informativo y
técnico) y que permiten cumplir con las expectativas de
calidad (requerimientos, tiempo y costo).
Se centra en la construcción de soluciones tecnológicas especificas y resuelve la

brecha entre los problemas empresariales y las soluciones tecnológicas.
CONCEPTO
Arquitectura Técnica
Descripción detallada centrada principalmente en una
tecnología de implementación en particular, es el
responsable del diseño a nivel de código (módulos, clases y
funciones)..
Se centra en la construcción de software y resuelve los problemas en ingeniería de

software.

Salida estándar por pantalla
C#

Program.cs
using System;
namespace ConsoleApp
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hola mundo");
_ ÿ X
Hola mundo
}
}
}
Variables
VS Code | .Net Core | Consola

Va r i a b l e s
int edad;
edad
edad = 19;
edad
edad;
edad

Va r i a b l e s
Una variable se conforma de tres elementos:
• Un tipo de dato que declara el tipo de valor que Identificador Tipo Valor
aceptara. int edad 19

• Un identificador que debe ser único para evitar string nombre "Juan"
ambigüedades. double promedio 9.14
• Un valor el cual es el dato almacenado del tipo bool estado true
definido.
valor
value
tipo
type int edad = 19;
identificador
edad identifier

Ejemplo
Área y perímetro de un cuadrado:
Equipo 0
𝑨𝑨 = 𝑙𝑙 2
l 𝑷𝑷 = 4𝑙𝑙
Cuadrado

Program.cs
using System;
x y
namespace p01
{
class Program
{
{
double l = 5;
A = Mat.Pow ( l , 2 )
double P = 4 * l;
double A = Math.Pow(l, 2); // double A = l * l;
Console.WriteLine("El perímetro del cuadrado es: " + P + " cm");

Console.WriteLine("El área del cuadrado es: " + A + " cm2");
}
}
}

Uso de Herramientas CASE
C om puter-Aided Softwa re Engineering

I n g e n i e r í a d e S of t w a re A s i s t i d a p o r C o m p u t a d o r a
CASE
Permiten aumentar la productividad y reducir el costo y tiempo en todos los aspectos del
SDLC, ademas de:
• Aumentar la biblioteca de conocimiento.
• Permite la automatización de: documentación, integración, implementación, generación de
código y pruebas.
• Ayuda a la reutilización del software y la estandarización.
Costo
y
Productividad Tiempo

Herramientas CASE
Automatización y soporte de las
INTEGRADO
actividades en las fases iniciales
SUPERIOR
1. Análisis
una tarea de una fase del SDLC

Automatizan y se especializan en
2. Diseño
JUEGO DE HERRAMIENTAS
3. Desarrollo
También llamadas workbench,
procesos en todo del SDLC
4. Pruebas
apoyan en actividades y
INFERIOR
5. Implementación
6. Mantenimiento
Automatización y soporte de las
actividades dirigidas a las ultimas
fases desarrollo

CONCEPTO
Herramientas CASE
Soluciones de software destinadas a aumentar la
productividad en el desarrollo de software reduciendo el
costo y el tiempo en todas las fases del SDLC.

1. Análisis
U-CASE
I-CASE
2. Diseño
3. Desarrollo
L-CASE
4. Pruebas
5. Implementación
6. Mantenimiento

Equipos

𝑏𝑏𝑏
Equipo 1, 11 𝑨𝑨 =
2
Triangulo
𝑷𝑷 = 𝑎𝑎 + 𝑏𝑏 + 𝑐𝑐
Equipo 2, 12 𝑨𝑨 = bn(a+h)
Prisma poligonal regular 𝑎𝑎𝑎𝑎𝑎𝑎

𝑽𝑽 =
n, es el numero de lados 2

En equipo
Realizar el calculo de la figura correspondiente por equipo, ejemplo:
Ejercicio
Program.cs
x y
Mat.Pow

Solution Architecture SA
Arquitectura de Solución

CONCEPTO
Estilo arquitectónico
Familia de sistemas que proveen una guía para dar
Mary Shawn y David

solución a problemas específicos determinando sus
componentes y conectores, así como su combinación y
restricciones.
Garlan
Se encarga de la coherencia de toda la solución en todos los aspectos y
actividades la organización. Se encarga de garantizar la integridad técnica y la
coherencia de la solución en cada etapa de su ciclo de vida.
Estilos arquitectónicos
Structure Deployment Communication Domain
Component Tier
SOA BDD
- Based Architecture
1 Tier
SDK Monolithic REST TDD
1960-1970
Object - 2 Tiers Micro-

Oriented Client - Server DDD
1980 services
Layered 3-Tiers Message Bus Hexagonal

Architecture 1990
Pipes - N-Tiers
2000 Peer to Peer Onion
Filters
Broker Clean
https://docs.microsoft.com/es-mx/previous-versions/msp-n-
p/ee658117(v=pandp.10)?redirectedfrom=MSDN

CONCEPTO
Arquitectura en capas
Separación de responsabilidades y funciones en
componentes llamadas capas, teniendo en cuenta el
software, siendo las mas comunes: presentación, lógica
empresarial y acceso a datos.

Estilos arquitectónicos
Arquitectura lógica
Cada capa tiene una responsabilidad específica y se trata por separado, esto hace que los componentes sean
modulares y facilitan su mantenimiento.
Presentación: Responsable de presentar

información al usuario e interactuar con
éste (interfaz de usuario)
Aplicación - Lógica empresarial
Response
(Bussines Logic): Contiene las reglas de
Request
negocio y resuelve las peticiones de los

clientes (capa de presentación)
Datos - Acceso a datos y almacenamiento:

Gestiona todos los elementos de
información de la aplicación, conocida
como capa de dominio

CONCEPTO
Arquitectura limpia

U n a a rq u i t e c t u r a l i m p i a s e c a r a c t e r i z a p o r :
• Independiente de los frameworks. Los frameworks deberían ser herramientas, y no
obligarnos a actuar de una determinada manera debido a sus restricciones.
• Testable. Debemos poder probar nuestras reglas de negocio sin pensar en base de datos,
interface gráfica u otros componentes no esenciales de nuestro sistema.
• Independiente de la UI. Si la UI cambia a menudo esto no puede afectar al resto de nuestro
sistema, que tiene que ser independiente.
• Independiente de la base de datos.
Deberíamos poder cambiar de Oracle, a
SQL Server, a MongoDB, a Casandra o a
cualquier otra base de datos sin que
afectara demasiado a nuestro sistema.
• Independiente de cualquier entidad externa.
No deberíamos saber nada de entidades
externas, por lo que no deberemos depender
de ellas.

C re a r u n a s o l u c i ó n q u e i m p l e m e n t e u n a
a rq u i t e c t u r a l i m p i a
Ejercicio
User
Mobile Interface
Web
System Test
CLI
Integration Test
Application Unit Test
DB
Mail
Infrastructure Files

proyectos
Crear una solucion y dos
Ejemplo
Equipo 0
Cuadrado

Program.cs

CONCEPTO
Arquitectura de niveles
Distribución de los componentes en niveles físicos,
teniendo en cuenta: el hardware, la topología de redes y su
localización.

SOA - Service-oriented
Monolithic application
P2P - Peer-to-peer
Client-server

SOA - Service-oriented
Microservices

P2P Cliente SOA Microservicios
Servidor
Monolítica
UI UI UI UI
UI UI UI UI BL UI UI BL
UI DA BL DA BL DA BL DA BL
DA DA
DA BL
UI UI BL SE SE
SE
DA
DA BL DA BL DA DA
DA
SE SE SE SE
DA DA DA DA

CONCEPTO
Patrones arquitectónicos
Esquema de organización estructural que describe los
elementos y sus relaciones a soluciones de problemas de
estilos arquitectónicos.
También llamados arquetipos, ofrecen una solución a un problema de estilo

arquitectónico de software.
A r c h i t e c t u r a l Pa t t e r n
Client-server

Pa t r o n e s a r q u i t e c t ó n i c o s
• Microkernel
Input
• PM
Presentation-Model
• SCA Input
Sensor-Controller-Actuator
• MVP
Model–View–Presenter MVC MVVM
• MVC
Model-View-Controller
Input
• MVVM
Model–View–ViewModel
• MVPVM Input
Model-View-Presenter-ViewModel
Arquitectura
• REST
Representational State Rransfer MVP - PM MVP - SC
Technical Architecture TA
• Arquitectura Técnica

CONCEPTO
Patrones de Diseño de Sof tware
Solución general reutilizable a un problema común en el
diseño de software que proporciona paradigmas de
desarrollo probados.
Responsable del diseño a nivel de código, como lo que hace cada módulo, el alcance de
las clases y los propósitos de las funciones.

P r i n c i p a l e s p a t ro n e s G o F ( G a n g O f F o u r )
Patrones creacionales: solucionan problemas de creación de instancias (ayudan a encapsular y abstraer la creación)
• Singleton (instancia única): garantiza la existencia de una única instancia (restringe la instanciación) para una clase y
su acceso global.
• Prototype (prototipo): crea nuevos objetos clonándolos de una instancia ya existente.
• Builder (constructor virtual): abstrae el proceso de creación de un objeto complejo, centralizando en un único
punto.
• Factory Method (método de fabricación): centraliza la creación de objetos de un subtipo de un tipo determinado,
ocultando la diversidad de casos particulares que se pueden prever. Parte del principio de que las subclases
determinan la clase a implementar.
• Abstract Factory (fábrica abstracta): permite crear objetos de diferentes familias de manera que no se mezclen y
haciendo transparente el tipo de familia concreta que se esté usando.

Principales patrones GoF (Gang Of Four)
Pa t r o n e s e s t r u c t u r a l e s
Patrones estructurales: solucionan problemas de composición (agregación) de clases y objetos:
• Adapter o Wrapper (Adaptador o Envoltorio): Adapta una interfaz para que pueda ser utilizada por una clase que
de otro modo no podría utilizarla.
• Bridge (Puente): Desacopla una abstracción de su implementación.
• Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase.
• Decorator (Decorador): Añade funcionalidad a una clase dinámicamente.
• Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un
subsistema.
• Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información.
• Proxy: Proporciona un intermediario de un objeto para controlar su acceso.

Principales patrones GoF (Gang Of Four)
Pa t r o n e s d e c o m p o r t a m i e n t o
Patrones de comportamiento: solucionan problemas de comunicación entre clases y objetos:
• Chain of responsibility (Cadena de responsabilidad): Una forma de pasar una solicitud entre una cadena de objetos
• Command (Comando): Encapsular una solicitud de comando como un objeto
• Iterator (Iterador): Acceso secuencialmente a los elementos de una colección
• Mediator (Mediador): Define la comunicación simplificada entre clases
• Interpreter (Intérprete): Una forma de incluir elementos del lenguaje en un programa
• Memento (Recuerdo): Capturar y restaurar el estado interno de un objeto
• Observer (Observador): Una forma de notificar el cambio a varias clases
• State (Estado): Modificar el comportamiento de un objeto cuando cambia su estado
• Strategy (Estrategia): Encapsula un algoritmo dentro de una clase
• Template method (Método de plantilla): Aplazar los pasos exactos de un algoritmo a una subclase
• Visitor (Visitante): Define una nueva operación a una clase sin cambios

Singleton
Singleton o instancia única permite using System;
restringir la creación de objetos y así
public class Clase
garantizar que solo exista una {
(constructor protegido o privado). public string atributo;
public Clase() { } Clase c1
Puede ser usado en programas con }
https://www.youtube.com/watch?v=K902i_tsXl0
Valor 1
múltiples hilos, si dos hilos de ejecución class Program
intentan crear la instancia al mismo {
tiempo y esta no existe todavía, solo static void Main(string[] args)
{
uno de ellos debe lograr crear el objeto. Clase c1 = new Clase(); Clase c2
c1.atributo = "Valor 1";
Ejemplo: acceso a un recurso físico único Valor 2
(como el ratón o un archivo abierto) o Clase c2 = new Clase();
cuando cierto tipo de datos debe estar
disponible para todos. Console.WriteLine("Clase 1: " + c1.atributo);
Console.WriteLine("Clase 2: " + c2.atributo);
}
}
//Clase 1: Valor 1
//Clase 2: Valor 2

using System;
public class Clase

{
public string atributo;
private static readonly Clase instance = new Clase();
private Clase() { }
public static Clase Instance

{
get
{
return instance;
}
}
Clase
} Valor 2
class Program
{
{
Clase c1 = Clase.Instance;
Clase c2 = Clase.Instance;
Console.WriteLine("Clase 1: " + c1.atributo); //Clase 1: Valor 2

}
}

Prototype
• Tiene como finalidad crear nuevos using System;
objetos clonando una instancia creada abstract class Clase
previamente. {
public string atributo;
abstract public Clase Clone();
• La clase que servirán de prototipo }
deberá incluir en su interfaz la manera
https://www.youtube.com/watch?v=K902i_tsXl0
class Concret : Clase
{
de solicitar una copia, que será override public Clase Clone()
desarrollada luego por las clases {
// Copia superficial
concretas de prototipos. return (Clase)this.MemberwiseClone();
}
}
• Ejemplo: en un editor gráfico, se
pueden crear copias de algún
class Program
{
rectángulo, círculos u otros, en ese static void Main(string[] args)
{
caso, son clonados y el nuevo objeto Concret c1 = new Concret();
será una copia exacta.

Concret c2 = (Concret)c1.Clone();

}
}

Forward
12207.0
1. Scope
2. References
3. Definitions
4. Application
Annexes A - D
Annexes E - J
12207.2

ISO/IEC/IEEE 12207
6. Supporting Processes / Procesos de apoyo
6.1.1. Process implementation 6.1.2. Design and development 6.1.3. Production 6.1.4. Maintenance
6.2. Configuration Management / Gestión de la configuración

6.2.1. Process implementation 6.2.2. Configuration identification 6.2.3. Configuration control
6.2.4. Configuration status accounting 6.2.5. Configuration evaluation 6.1.6. Release management and delivery
6.3. Quality Assurnce / Aseguramiento de la calidad

6.3.1. Process implementation 6.3.2. Product assurance 6.3.3. Process assurance 6.3.4. Assurance of quality systems
6.4. Verification / Verificación 6.4.1. Process implementation 6.4.2. Verification
6.5. Validation / Validación 6.5.1. Process implementation 6.5.2. Validation
6.6. Joint Review / Revisión conjunta

6.6.1. Process implementation 6.6.2. Project management reviews 6.6.3. Technical reviews
6.7. Audit / Auditoría 6.7.1. Process implementation 6.7.2. Audit
6.8. Problem Resolution / Resolución del problemas

6.8.1. Process implementation 6.8.2. Problem Resolution

CONCEPTO
Gestión de la Configuración de Sof tware
S oft w a r e C on fi gu r a t i on M a n a gem en t , S C M
Procesos destinados a asegurar la calidad a través del
estricto control de los cambios realizados sobre el software
y de la disponibilidad constante de una versión estable para
todos los involucrados en el desarrollo

Gestión de la Configuración SCM
Gestión de Proyectos PM Proceso de Desarrollo Dev
Nueva Elemento
versión versionado
Gestión de la Configuración SCM
Elemento Nueva
versionado versión
Aseguramiento de la Calidad QA

Control de cambios
La Gestión de Configuración y Control de Cambios se encarga de:

• Identificar los elementos del proyecto que deben estar bajo
configuración.
• Restringir los cambios a dichos elementos.
• Auditar los cambios a estos elementos.
• Gestionar la configuración de estos elementos.
El objetivo es asegurar que los cambios realizados en un sistema

no afectarán negativamente a los otros.

Git
Pronunciado "guit“, es un software de control de versiones distribuido, diseñado por Linus
Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de
código fuente. Su propósito es:
• Registrar los cambios en los archivos del proyecto, y
• Coordinar el trabajo de varias personas del proyecto.

Azure - DevOps
https://d3vsof t-
my.sharepoint.com/:b:/g/per sonal/luis_
edu_d3v_mx/EfEzzjiShitIjGpPN8zaZWM
Solo
BcmTauNTSAripkE2FHUY5sQ Repos
Git - Basic
https://d3vsof t-
my.sharepoint.com/:b:/g/per sonal/luis_
edu_d3v_mx/EbXlr tAf7QtHnNVjZwGVC8
sBag jNMtnuRAFigMq9NuY8TA

Forward
12207.0
1. Scope
2. References
3. Definitions
4. Application
Annexes A - D
Annexes E - J
12207.2

ISO/IEC/IEEE 12207





CONCEPTO
Calidad del Sof tware
El grado con el que un sistema, componente o proceso
Eléctricos y Electrónicos, IEEE

cumple los requisitos especificados y las expectativas del
Instituto de Ingenieros
cliente a un costo y en un tiempo aceptable

• Es mucho menos costoso detectar los problemas antes de entregar el sistema a los
revisiones
Esfuer zo realizado, con y sin
usuarios.
• Una parte de las pruebas las realizan los programadores; otra junto con los analistas.
• Los planes de prueba se crean en las primeras etapas del SDLC y se refinan a medida
que el proyecto progresa.
Without
inspections
With
Pressman
inspections
QA

errors and defects
Relative cost of correcting
Pressman
Mejora Continua de la Calidad del software
Q C / Q A / TQ M
La mejora continua de la calidad es uno de los 8 principios de la gestión de la calidad dice que
“la mejora continua del desempeño global de la organización debería ser un objetivo
permanente de ésta” (ISO 9000).
El objetivo no es alcanzar una calidad perfecta, sino la necesaria y
suficiente para cumplir con las necesidades reales del usuario.
Los modelos de calidad:
• QC / Calidad a nivel de producto
Está orientado a verificar el cumplimiento de los requisitos que permitan alcanzar la
satisfacción del cliente definidos en las etapas iniciales.
• QA / Calidad a nivel de proceso
La calidad debe ser programada desde el inicio, y posteriormente en cada fase del desarrollo,
controlar y dar seguimiento a los aspectos de la calidad.
• QM / Calidad a nivel de sistema
Esta orientada a la gestión y en el Servicio.

Calidad a nivel de producto

Actividades planificadas y sistemáticas implementadas dentro del sistema de
calidad que pueden demostrarse para proporcionar confianza en que un
producto o servicio cumplirá los requisitos de calidad

Modelos de calidad a nivel de producto
• Boehm: Modelo incremental, dividido en regiones y estas a su vez en tareas, las cuales se
ajustan a la cantidad de iteraciones definidas, dividido en: planeación, análisis de riesgo,
ingeniería y evaluación.
• FURPS: Modelo que provienen de criterios que evalúan: Funcionalidad, usabilidad,
confiabilidad (reliability), desempeño (performance) y soportabilidad.
• GILB: Modelo de evaluación a partir de atributos: Capacidad de trabajo, adaptabilidad,
disponibilidad y utilizabilidad, los cuales se dividen en subatributos, para solucionar problemas
y detectar riesgos.
• ISO/IEC 9126
• ISO/IEC 14598
• SQAE o Software Quality Assessment Exercise: Modelo, basado en Boehm, McCall, Dromey
e ISO 9126, está orientado a realizar evaluación por terceros siguiendo tres capas: área, factor
y atributo de calidad.
• WebQEM: Orientada a sitios Web basado en seis fases: planificación y programación de la
evaluación de calidad, definición y especificación de requerimientos de calidad, definición e
implementación de la evaluación elemental, definición e implementación de la evaluación
global, análisis de resultados, conclusión y documentación, y validación de métricas.
• ISO/IEC 25000 o SQuaRE

ISO/IEC 9126
ISO/IEC 14598
ISO/IEC 25000 o SQuaRE
Modelos de calidad a nivel de
producto

Modelos a nivel de producto
ISO/IEC 9126
Orientada a la Calidad en Uso, proporcionan una base útil para mediciones indirectas y una
lista de comprobaciones para evaluar la calidad.
Este sistema se identifican cuatro elementos:

• Modelo de calidad
• Métricas externas
• Métricas internas
Calidad de métricas en uso:

• Eficiencia (Efficiency): Grado en el que el software emplea óptimamente los recursos.
• Funcionalidad (Functionality): Grado en el que el software satisface las necesidades en: adaptabilidad, exactitud,
interoperabilidad, cumplimiento y seguridad.
• Mantenibilidad (Maintainability): Facilidad al efectuarse reparaciones: analizable, cambiable, estable, susceptible a
pruebas.
• Portabilidad (Portability). Facilidad con la que se puede llevar de un ambiente a otro según: adaptable, instalable,
conformidad y sustituible.
• Confiabilidad (Reliability): Cantidad de tiempo que el software se encuentra disponible según la: madurez,
tolerancia a fallas y recuperación.
• Usabilidad (Usability): Grado en el que el software es fácil de usar, es decir: entendible, aprendible y operable.

ISO/IEC 14598
Marco de trabajo para evaluar la calidad de los productos de software mediante métricas y
requisitos de evaluación.
Las 6 partes en las que se divide son:
• ISO/IEC 14598-1, panorama general y su relación con ISO 9126.
• ISO/IEC 14598-2, planificación y gestión, contiene los requerimientos y las guías de soporte
para la evaluación del software.
• ISO/IEC 14598-3, procesos para desarrolladores, cuando la evaluación es conducida en
paralelo con el desarrollo y se lleva a cabo por el desarrollador.
• ISO/IEC 14598-4, proceso para compradores, garantizar a los compradores si este cumple
los requisitos especificados.
• ISO/IEC 14598-5, proceso de evaluadores, cuando las diversas partes intentan comprender,
aceptar y confiar los resultados de la evaluación.
• ISO/IEC 14598-6, documentación de los módulos de evaluación.

ISO/IEC 25000 SQuaRE
SQuaRE (System and Software Quality Requirements and Evaluation), permite evaluar la calidad
del producto software, al organizar, enriquecer y unificar las series que cubren dos procesos
principales: especificación de requisitos de calidad del software y evaluación de la calidad
del software.
La familia de normas ISO/IEC 25000:2005 reemplaza a dos estándares relacionados:
• ISO/IEC 9126 (Software Product Quality) e,
• ISO/IEC 14598 (Software Product Evaluation).

estándar 25000
ISO/IEC 9126, 14598 y el
Relación entre los estadales
2500n: Gestión de calidad
25000: Guía de SQuaRE
25001: Planificación y Gestión
9126: Calidad del Producto 2501n: Modelo de Calidad
1: Modelo de calidad 25010: Guia y modelo de calidad
2: Métricas externas 2502n: Medidas de Calidad
3: Métricas internas 25020: Guía y modelo de referencia
4: Métricas de calidad en uso 25021: Medidas primitivas
25022: Medidas internas
25023: Medidas externas
14598: Evaluación del producto 25024: Medidas de calidad en uso
1: Resumen 2503n: Requisitos de Calidad
2: Planificación y Gestión 25030: Guía y Requisitos de Calidad
3: proceso para desarrolladores 2504n: Evaluación de Calidad
4: Proceso para compradores 25040: Guía y resumen de evaluación
5: Proceso para evaluadores 25041: Módulos de evaluación
6: Módulos de evaluación 25042: Proceso para desarrolladores
25043: Proceso para compradores
25044: Proceso para evaluadores

3pts CLI
3pts Libreria
4pts Código alojado en Git

Ejemplo
Equipo 0
Cuadrado

Calidad a nivel de proceso

Actividades planificadas y sistemáticas implementadas dentro del sistema de
calidad que pueden demostrarse para proporcionar confianza en que un
producto o servicio cumplirá los requisitos de calidad

Parte de la gestión de calidad centrada en el cumplimiento de los requisitos de calidad mediante
técnicas y actividades operativas.

Modelos a nivel de proceso
• ISO/IEC 15504 (SPICE)

• Bootstrap: Permite la mejora de procesos a partir de seis actividades básicas.
• Dromey: Se estructura con características y subcaracterísticas de calidad;
propone tres modelos a partir de la evaluación establecida en cinco etapas.
• Personal Software Process (PSP): Está enfocado al desarrollo profesional del
ingeniero.
• Team Software Process (TSP): Fase posterior de PSP diseñado para el trabajo
de equipos.
• CMMI (Capability Maturity Model Integration)
• Moprosoft: Norma mexicana, (basado en 15504) estandariza operaciones y
prácticas en ingeniería de software

ISO/IEC 15504
SPICE
Modelos de calidad a nivel de proceso

ISO/IEC 15504 (SPICE)
La norma para empresas que se dedican al desarrollo de productos y aplicaciones de Software.
También conocido como Software Process Improvement Capability Determination, abreviado
SPICE, en español, “Determinación de la Capacidad de Mejora del Proceso de Software”.
Su objetivo es evaluar la madurez o calidad los procesos mediante 3 elementos principales:
• Un marco para la evaluación con 6 niveles de capacidad de proceso definido.
• Nivel 5: Optimizado. El proceso se monitoriza para su mejora continua y así cumplir los objetivos de negocio
actuales y futuros. Se establecen objetivos cuantitativos de eficacia y eficiencia.
• Nivel 4: Predecible. Los procesos se miden y analizan; esto permite mantenerlos dentro de límites
predefinidos, así como disponer de una mejor posición para poder cuantifica la capacidad del proceso y
predecir su comportamiento.
• Nivel 3: Establecido. Los procesos se realizan, se gestionan y documentan utilizando procedimientos
estándar.
• Nivel 2: Gestionado. Los procesos se planifican y se dan seguimiento. También se tiene definidos plazos y
recursos.
• Nivel 1: Realizado. Se alcanzan los objetivos en términos generales, pero no se planifica ni se dan
seguimiento.
• Nivel 0: Incompleto. La implementación de los procesos no es efectiva.
• Un conjunto de requisitos para definir procesos.
• Un conjunto de requisitos sobre cómo realizar evaluaciones consistentes.
5
PA. 5.2 Se optimizan los procesos estándar.
PA. 5.1 Se mejora continuamente los procesos estándar Nivel
Optimizado
4
PA. 4.2 Se miden los procesos estándar usando técnicas cuantitativas.
PA. 4.1 Se controlan los procesos estándar. Nivel
Predecible
3
PA. 3.2 Se utilizan los procesos estándar.
PA. 3.1 Se tienen procesos estándar.
Nivel
Establecido
Nivel 2
Gestionado
PA. 2.2 Se establecen, controlan y mantienen los procesos.
1
PA. 2.1 Se gestiona la realización del procesos.
Nivel
PA. 1.1 Existe evidencia de la realización de procesos. Realizado
Nivel 0
Incompleto
Risk
Quality
CMMI
Capability Maturity Model Integration
Modelos de calidad a nivel de proceso

CMMI (Capability Maturity Model Integration)
Es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos
niveles sirven para conocer la madurez de los procesos que se realizan para producir software.
• Nivel 1. Inicial: Proceso impredecible, poco controlado y reactivo. Los presupuestos se disparan, no es posible
entregar en fecha planeada. No hay control y es completamente opaco.
• Nivel 2. Gestionado: Proceso reactivo. El éxito se puede repetir (gestionado y controlado). Los procesos son:
• Gestión de requisitos, Planificación de proyectos, Seguimiento y control de proyectos, Gestión de proveedores,
Aseguramiento de la calidad, y Gestión de la configuración.
• Nivel 3. Definido: Proceso organizado y proactivo. El desarrollo de proyectos está establecido, documentada y
existen métricas (datos objetivos). Los procesos para alcanzar este nivel son:
• Desarrollo de requisitos, Solución Técnica, Integración del producto, Verificación, Validación, Desarrollo y mejora
de los procesos de la organización, Definición de los procesos de la organización, Planificación de la formación,
Gestión de riesgos, y Análisis y resolución de toma de decisiones.
• Nivel 4. Gestionado Cuantitativamente: El proceso es controlado cuantitativamente. Los proyectos usan objetivos
medibles para alcanzar las necesidades de los clientes y la organización. Los procesos que hay que implantar para
alcanzar este nivel son:
• Gestión cuantitativa de proyectos, y Mejora de los procesos de la organización.
• Nivel 5. En Optimización: Enfoque en la mejora del proceso. Los procesos de los proyectos y de la organización
están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante
métricas son identificadas, evaluadas y puestas en práctica. Los procesos que hay que implantar para alcanzar este
nivel son:
• Innovación organizacional, yAnálisis y resolución de las causas.

Mejora continua
Predecible
Consistente
5
4
Disciplinado
Optimizado
3 Medible
2
1
Definido
Administrado
Initial
Target Target Target Target Target

Probability of success
Time Time Time Time Time

Comparativa de capacidades de madurez
Nivel SPICE CMMI

0 Incomplete
1 Performed Initial
2 Managed Repeated
3 Established Defined
4 Predictable Managed
5 Optimizing Optimizing

A s e g u r a m i e n t o y c o n t ro l d e l a c a l i d a d
Q u a l i t y As s u r a n ce QA / Q u a l i t y C on t r ol Q C
QC: actividades destinadas a evaluar el producto del desarrollo de software (fase de testing).
QA: actividades planificadas y sistemáticas interesadas en el proceso de desarrollo del
producto de software, aplicadas para asegurar que los requisitos sean satisfechos.
Entre las actividades se encuentran la medición sistemática, la comparación con estándares, el seguimiento de los
procesos y la realimentación de información.
QC
Phases
Analysis Design Development Testing Deploy Maintenance
Analysis Design Development Deploy Maintenance

Process
Testing
QA
Gestión de la Calidad
Calidad a nivel de sistema

QC, QA y QM
Aseguramiento de la Gestion de la calidad

Control de la calidad Quality Management
calidad
Quality Control
Quality Assurance

CONCEPTO
Gobierno encargado de asegurar que los objetivos sean
cumplidos, evaluando y monitoreando las necesidades de
todos los involucrados (stakeholders) en tiempo y forma.

CONCEPTO
Gobierno de TI
Marco de estructuras, procesos y mecanismos relacionales
que permiten alinear las Tecnologías de la información (TI)
con los objetivos y estrategias del negocio.

Modelos a nivel de sistema
• ISO/IEC 90003 + 9001

• COBIT: Control Objectives for Information and related Technology - Conjunto
de herramientas orientadas a garantizar el control y seguimiento de
gobernabilidad de Sistemas de Información a largo plazo a través de
auditorías. Enmarca todo el proceso de información de la empresa, desde la
creación de la información hasta su disposición final para garantizar un control
de calidad preciso.
• ISO/IEC 20000 + ITIL
• ISO/IEC/IEEE 38500

ISO/IEC 90003 + 9001

ISO 90003 + 9001
Especifica los requisitos básicos para el desarrollo, producción, instalación y servicio. La
estructura de la familia de estándares es:
• ISO 9000, Fundamentos y vocabulario.
• ISO 9001, Requisitos para aseguramiento de la calidad.
• ISO 9004, Directrices para la mejora del rendimiento (mejora continua).
• ISO 9011, Directrices para auditoría de sistemas de gestión de calidad y/o ambiental.
• ISO 90003 (ISO 9000-3), Guía de aplicación de ISO 9001 al software de computador.
ISO 9001:2000 define cinco secciones:

• QMS Sistema de Gestión de la Calidad (SGC): Requisitos generales y Requisitos de
documentación.
• Responsabilidad de la Gestión: Compromiso de la dirección, Política de la calidad, Planificación, …
• Gestión de los Recursos: Recursos humanos, Infraestructura, …
• Realización del Producto: Planificación, Clientes, Diseño y desarrollo, Compras, …
• Medición, Análisis y Mejora: Supervisión, Control de servicio no-conforme, Mejora, …

ISO/IEC/IEEE 90003:2018
Quality Management System (QMS)

Costumer
satifaction
Organoization Support and

and ITS Operations
Context PLAN (Clause 7 and 8) DO Employes
(Clause 4) Engagement
Customer Performance Results of the

Planning Leadership
requirements (Clause 6) (Clause 5) Evaluation QMS
(Clause 4) (Clause 9)
Needs and Products an

expectations services
parties ACT Improvement
CHECK
(Clause 4) (Clause 10)
Continuous
Improvement

ISO/IEC 20000 + ITIL

Calidad a nivel de sistemas
ISO 20000 están basadas en ITIL
ITIL (Biblioteca de Infraestructura de Tecnología de la Información): Colección de mejores prácticas
para la administración efectiva de los Sistemas de Información.
ISO 20000 ofrece certificación a organizaciones mientras que ITIL se centra en las personas.
ISO 20000 permite verificar si una organización está cumpliendo con las prácticas propuestas por ITIL
Sus requisitos son independientes de otros

marcos de referencia existentes, por lo que
se puede apoyar en uno o varios marcos
ISO/IEC 20000
(ITIL, eTOM, COBIT, etc.).
ITIL
Procedimientos propios de la empresa

ISO/IEC/IEEE 38500

ISO/IEC 38500
Estándar para las buenas prácticas del Gobierno de las Tecnologías de la Información (TI)
basada en seis principios y tres procesos.
Principios:
1. Establecer responsabilidades claramente entendidas para el área de TI.
2. El planear las TI para apoyar de mejor forma a la empresa.
3. La adquisición de las TI sea por análisis y validaciones previas.
4. Asegurarse que las TI tienen un rendimiento satisfactorio para cubrir las necesidades del negocio.
5. Asegurar que la informática cumpla con las reglas formales previamente establecidas.
6. Asegurar que el uso de las TI respeta los factores humanos.
Procesos:
1. Evaluar: Examinar y juzgar el uso actual y futuro de las TI (internos y externos).
2. Dirigir: Dirigir la preparación y ejecución de los planes y políticas, asignando las responsabilidades al efecto.
3. Monitorizar: Medir y vigilar el rendimiento de la TI, asegurando que se ajusta a lo planificado.

ISO/IEC 38500
Corporate
Gobernance of IT
Evaluate
Direct Monitor
Proposals
Plans Policies Performance
Conformance
Business Processes
IT Projects IT Operations

Proyecto de consola .Net core

/> mkdir Proj ; cd Proj
---- ------------- ------ ----
d----- 7/15/2021 1:40 PM Proj
/Proj> dotnet new classlib -o src/Application

The template "Class library" was created successfully.
Running 'dotnet restore' on src/Application\Application.csproj...
Determining projects to restore...
Restore succeeded.
/Proj> dotnet new console -o src/ConsoleUI

The template "Console Application" was created successfully.
Processing post-creation actions... Proj
Running 'dotnet restore' on src/ConsoleUI\ConsoleUI.csproj...
Restore succeeded.
/Proj> dotnet new webapp -o src/WebUI

The template "ASP.NET Core Web App" was created successfully.
ices for details.
Running 'dotnet restore' on src/WebUI\WebUI.csproj...
Restored E:\codes\is\Proj\src\WebUI\WebUI.csproj (in 59 ms).
Restore succeeded.
/Proj> dotnet add src/ConsoleUI reference src/Application

Reference `..\Application\Application.csproj` added to the project.
/Proj> dotnet add src/WebUI reference src/Application

/Proj> dotnet run -p src/ConsoleUI

Hello World!
/Proj> dotnet run -p src/WebUI

Building...
info: Microsoft.Hosting.Lifetime[0]
Now listening on: https://localhost:5001
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
Hosting environment: Development
Content root path: C:\Users\user\Cubo\UI.Web

Salida estándar por pantalla
C#

Program.cs
using System;
namespace ConsoleApp
{
class Program
{
{
Console.WriteLine("Hola mundo");
Hola mundo
}
}
}
Variables
VS Code | .Net Core | Consola

Va r i a b l e s
int edad;
edad = 19;
edad;

Va r i a b l e s
Una variable se conforma de tres elementos:
Un de dato que el tipo de valor que
aceptara. int edad 19
Un que debe ser para evitar string nombre "Juan"
ambigüedades. double promedio 9.14
Un el cual es el dato del tipo bool estado true
definido.
value
type int edad = 19;
identifier

Ejemplo
Cuadrado

Program.cs
using System;
x
namespace ConsoleUI
{
class Program
{
{
double l = 5;
A = Mat.Pow ( l , 2 )
double P = 4 * l;
double A = Math.Pow(l, 2); // double A = l * l;
Console.WriteLine("El perímetro del cuadrado es: " + P + " cm");

Console.WriteLine("El área del cuadrado es: " + A + " cm2");
}
}
}

Entrada estándar por teclado
C#

Program.cs
using System;
namespace ConsoleUI
{
class Program
{
{
Console.Write("Escribe tú nombre: ");
String cadena = Console.ReadLine();

Escribe tú nombre: Juan
Hola Juan
Console.WriteLine("Hola " + cadena);
}
}
Program.cs
using System;
namespace ConsoleUI
{
class Program
{
{
Console.Write("Escribe tú edad: ");

Escribe tú edad: 59
int entero = Convert.ToInt32(cadena); Tienes 59 años
Console.WriteLine("Tienes " + entero + " años");
}
}
Program.cs
using System;
namespace ConsoleUI
{
class Program
{
{
//Cadena
//Entero
int entero = Convert.ToInt32(Console.ReadLine());
//Double Juan
double flotante = Convert.ToDouble(Console.ReadLine()); 32
//Booleano 12.5
bool booleano = Convert.ToBoolean(Console.ReadLine());
true
Console.WriteLine(cadena);
Console.WriteLine(entero);
Console.WriteLine(flotante);
Console.WriteLine(booleano);
}
}
Git
Sof tware de control de ver siones
distribuido, pensando en la eficiencia y
la confiabilidad del mantenimiento de
ver siones de código fuente.

acepta código y todos permite múltiples
Descentralizado
Centralizado -
sincronizan su trabajo con él. repositorios remotos y locales.

push push
pull clone pull
commit add add commit

push
fetch clone
rebase
commit add

Git
Clonar repositorio remoto

clone

Clonar el repo remoto a local
git clone https://dev.azure.com/unitec-is/Project/_git/Project
Cloning into 'Project'...

remote: Azure Repos
remote: Found 25 objects to send. (92 ms)
Unpacking objects: 100% (25/25), 20.99 KiB | 127.00 KiB/s, done.
cd Project
\Project dotnet new console
Running 'dotnet restore' on Program\Program.csproj...
Determinando los proyectos que se van a restaurar...
Se ha restaurado C:\Users\juan_\Project\Program\Program.csproj (en 75 ms).
\Project code . Restore succeeded.

Git
Modificar y subir al repositorio remoto

push
commit add

Subir el proyecto al repo remoto
\Project git add .
\Project git commit -a -m "Init"
[main c9cc359] Init
4 files changed, 89 insertions(+)
create mode 100644 .vscode/launch.json
create mode 100644 .vscode/tasks.json
create mode 100644 Program/Program.cs *** Please tell me who you are.
create mode 100644 Program/Program.csproj Run
git config --global user.email [email protected]
git config --global user.name "Your Name"
to set your account's default identity.
Omit --global to set the identity only in this repository.
fatal: unable to auto-detect email address (got 'user@mail.(none)')
git config --global user.email "[email protected]"

\Project git push git config --global user.name "Fname SName"
Enumerating objects: 9, done. git commit -a -m "Init"

Counting objects: 100% (9/9), done.
Delta compression using up to 8 threads
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.50 KiB | 769.00 KiB/s, done.
Total 8 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Analyzing objects... (8/8) (8 ms)
remote: Storing packfile... done (60 ms)
remote: Storing index... done (30 ms)
To https://dev.azure.com/unitec-is/Project/_git/Project
5c591fe..c9cc359 main -> main

Git
Bajar los cambios del repositorio
remoto

pull

Subir el proyecto al repo remoto
\Project git pull
[main c9cc359] Init
4 files changed, 89 insertions(+)
create mode 100644 .vscode/launch.json
create mode 100644 .vscode/tasks.json
create mode 100644 Program/Program.cs
create mode 100644 Program/Program.csproj

Resumen
git clone <repo>
git add . git commit -a git push
git pull

Git
Corregir conflictos en los repositorios

push push
commit add add commit

pull push
add commit

Resolver conflictos
1. Se traen los cambios del repo remoto
git pull
2. Se modifica el archivo para eliminar los conflictos
git diff HEAD
<<<<<<< HEAD
En el repo local.
=======
En el repo remoto.
>>>>>>>
3. Agregar los archivos, se hace el commit y el push
git add .
git commit -m "Fix"
git push

Git
Uso de ramas

Crear rama
1. Revisar las ramas
git branch
* main
2. Creamos la rama fix01

git branch 'luis/fix01’
git branch
luis/fix01
* main

Fusionar ramas
1. Cambia a la rama 'origin/main’
git checkout main
Switched to branch 'master'
2. Se fusuina la rama luis/fix01 a la rama main

git merge luis/fix01
Merge made by the 'recursive' strategy.
index.html | 1 +
1 file changed, 1 insertion(+)

Forward
12207.0
1. Scope
2. References
3. Definitions
4. Application
Annexes A - D
Annexes E - J
12207.2

ISO/IEC/IEEE 12207
/ Procesos de apoyo
5.5. Maintenance /



ISO/IEC/IEEE 12207
/ Procesos de apoyo
5.5. Maintenance /



ISO/IEC/IEEE 12207





ISO/IEC/IEEE 12207





Product
Governance
Assessment
Implementation and
42010 And
9001 Architecture
Quality System
15288 12207 15504 9126
330xx 14598
38500 24748-2 24748-3 29169 14756
Software Quality
Governance Process
15289 Assessment
26511 24748-4
26512 90005 19770-1 25000
26514 19770-8 SQuaRE
24765 26515 24748-1 29110 Asset
14143
Process
Description
29148 29119 14764 Management 20926
Requirements Testing Software Manintenance 20968
20000 24570
BOK 16326 15026, 16085 15939, 29155 29881
Size Measurement
Professionalization
16337
19759 3535, 5806 14102, 14471 10746, 13235, 14750 8807, 15437 14568
Tools and
BOK
Methods
5807, 8631 15940, 18018 14752, 14753, 14769 15909, 19501 15474
24773 8790, 11411 23026, 24766 14771, 15414, 19500 19505, 19793 15475
29154 12182, 14759 26500, 26501 19770-2, 19770-3 24744, 19505 15476
Cerification
Envirinment 19770-6, 19770-7 19507 19506

La idea es que la ISO 29119 unifique unas normas previas, principalmente:
• Estándares BSI:
• BS 7925-1, SW Testing: Part 1 - Vocabulary
• BS 7925-2, SW Testing: Part 2 - Software Component Testing
• Estándares IEEE testing:
• IEEE Std 829, Software Test Documentation
• IEEE Std 1008, Software Unit Testing
IEEE Std 1012-1998 Software Verification and Validation V&V

CONCEPTO
Pruebas de sof tware
Proceso de verificar que un sistema de software cumple con
las especificaciones y validar que cumple con el propósito
previsto

Ve r i f i c a c i ó n y Va l i d a c i ó n ( V & V )
El objetivo es garantizar que el sistema ha sido
desarrollado correctamente. Se le conoce como
verificación y validación (V&V).
Verificación: garantiza que el software

implementa correctamente las
funcionalidades.
¿Construimos el producto
correctamente?
Validación: asegura que sigue los

requerimientos del cliente.
¿Construimos el producto correcto?

Pruebas de operación y validez
Ve r i f i c a c i ó n y Va l i d a c i ó n
Operations
Acceptance
Problem Analisys and
(User)
Maintenance
System
Design
(Version)
SDLC STLC
Integration
Build
Unit

Va l i d a c i ó n y v e r i f i c a c i ó n d e l s o f t w a r e
S D LC
Pruebas de Unidad: El probador (tester) debe buscar situaciones límite que expongan las
limitaciones de los componentes individuales con entradas fake.
Pruebas de Integración: Se prueba el funcionamiento para asegurar que los componentes
funcionan correctamente a nivel de infraestructura de soporte (base de datos, el sistema de
archivos y la red).
Pruebas de Sistema (End to End): Se prueba el sistema completo
para verificar que cumpla con los requerimientos.
Pruebas de Aceptación (UI): La aceptación operativa (usuarios)
se lleva a cabo la preparación operacional (prelanzamiento) del
sistema como parte de la gestión de calidad.
Una prueba es un éxito cuando se detecta un error (y no al revés).

Pruebas
S T LC
Acceptance
(User)
System
(Version)
STLC
Integration
Unit

Ve r i f i c a c i ó n y Va l i d a c i ó n ( V & V )
Garantiza que el software implementa
Garantiza que el software cumple los

correctamente las funcionalidades.
¿Construimos el producto correctamente? Verificación Validación
Verification Validation
requerimientos del cliente.

¿Construimos el producto correcto?
Pruebas de
Pruebas de Regresión Pruebas de
Unidad Regression Testing Aceptación
Unit Test de Usuario
User Acceptance Test
Pruebas de Sistema
Pruebas de System Test
Integración Prototipado
Integration Test Prototyping
Pruebas Beta
Pruebas Beta Test Pruebas de
Automatizadas Usabilidad
Automated Testing Usability Test

Prueba de unidad
Verificar la unidad más pequeña (componente o módulo), se enfocan en la
lógica de procesamiento interno y de las estructuras de datos dentro de las
fronteras.
fake input output
Pressman
Prueba de unidad
• La técnica de Casos de Prueba generados a partir del Caso de Uso (ó Historia
de Usuario) se diseñan para descubrir errores debidos a cálculos erróneos,
comparaciones incorrectas o flujo de control inadecuado.
• La técnica de prueba de Caja Negra es utilizada para realizar pruebas
funcionales enfocadas solamente en las entradas y salidas del sistema del
sistema sin tomar en cuenta la estructura interna de código.
Pressman
Pruebas de integración
Verificar el software en su conjunto probando sus interfaces.
Entrada
Real
Salida
Pressman
• La técnica de Prueba de regresión es toda prueba que intenta descubrir
errores (bugs) o mal funcionamiento con respecto al esperado, causados
por la realización de un cambio en el programa.
• La técnica de Prueba de humo es diseñada como un mecanismo de ritmo
para proyectos críticos en el tiempo para exponer los errores “paralizantes”
que evitarán a la construcción realizar adecuadamente su función y que
tengan la mayor probabilidad de retrasar el proyecto. La construcción se
integra con otras construcciones, y todo el producto (en su forma actual) se
somete a prueba de humo diariamente.
Pressman
Pruebas de sistema
Verifica y valida mediante la integración de componentes para crear una versión del sistema
y, luego, poner a prueba el sistema integrado.
La principal meta es convencer de que el sistema

es suficientemente apto para su uso, y así
liberarse como un producto o entregarse al
cliente.
Una prueba de sistema pretende ejercitar por

completo el sistema, algunas de ellas son:
• Carga
• Esfuerzo
• Seguridad
• Despliegue
• Recuperación
• Basadas en requerimientos
• De escenario
Aceptación
Validación mediante el cumplimiento de las expectativas razonables del cliente.
La prueba de aceptación del usuario

(UAT) es la última fase del proceso de
prueba del software. Durante la UAT, los
usuarios reales de software prueban el
software para asegurarse de que pueden
manejar las tareas requeridas en
escenarios del mundo real, de acuerdo
con las especificaciones.

Pruebas del sistema
Pruebas de aceptación (UI)
Alfa: los usuarios trabajan con el equipo de Pre-Alpha
diseño para probar el software en el sitio del

desarrollador. Alpha
Beta: donde una versión previa se pone a

disposición de los usuarios, para permitirles Beta
experimentar y descubrir problemas.
RC: los clientes prueban el sistema para decidir si Release Candidate RC

está o no listo para ser aceptado por los
desarrolladores del sistema y desplegado en el
entorno del cliente.
Release to Manufacturing RTM
Gold

Pruebas Unitarias
xUnit Net Core
https://docs.microsoft.com/es-mx/aspnet/core/test/razor-pages-tests

Pruebas Unitarias
Las pruebas unitarias usan componentes fabricados como fakes (mocks o
stubs), en lugar de componentes de infraestructura como:
• Base de datos
• Canalización de solicitud-respuesta
• Sistema de archivos
• Aplicaciones de red
Mock: emulación que decide si una prueba se ha superado o no.

Stub: reemplazo controlable para una dependencia existente (o colaborador)
en el sistema.

Características de una buena prueba unitaria
• Fast (rápida): Las pruebas deberían tardar muy poco tiempo en ejecutarse
(milisegundos), esto debido a que los proyectos maduros normalmente tienen
miles de pruebas unitarias.
• Isolated (aislada): Las pruebas no deben tener ninguna dependencia con
ningún factor externo (sistemas de archivos o bases de datos).
• Repeatable (repetible): Las pruebas deben ser reiterativas, es decir, devolver
siempre el mismo resultado si no cambia nada entre ejecuciones.
• Self-Checking (auto-comprobable): La prueba debe detectar si el
resultado ha sido correcto o incorrecto sin necesidad de intervención
humana.
• Timely (oportuna): Una prueba no debe tardar mas en escribirse que el
código que se va a probar.
Arrange: Organiza los datos, los crear y configura.
Pa t r ó n Ar r a n ge - Act - As s er t
Set up
Act: Actuar en un objeto. prerequisites If
Assert: Afirmar si algo es como se esperaba. Any
Arrange Data
using Xunit;
public class CalculatorTests

{
[Fact]
Perform Test
public void Calculator_Sum_ReturnsSuccess()
{ Act to Test
// Arrange – Set up
var arrange = new Calculator();
Unit Text
// Act – Perform
var act = arrange.Sum(5, 5);
Verify the Test
// Assert – Verify
Assert.Equal(10, act);
Assess the Test
}
}
Fa c t s - T h e o r i e s
Facts: Pruebas siempre ciertas (condiciones invariantes).
Theories: Pruebas solo ciertas para un conjunto de datos.
Facts Theories
using Xunit; using Xunit;
public class CalculatorTests public class CalculatorTests

{ {
[Fact] [Theory]
public void Calculator_Sum_Success() [InlineData(-1, 2)]
{ [InlineData(0, 4)]
Assert.Equal(5, Add(3, 2)); [InlineData(1, 30)]
} public void Calculator_Sum_Success(int n1, int n2)
[Fact] {
public void Calculator_Sum_Fail() Assert.Equal(6, Add(n1, n2));
{ }
Assert.Equal(6, Add(2, 2));
}
} }

Afirmaciones Descripción
Asser tions xUnit.net 2.x

Equal Valida que un objeto es igual a otro objeto
NotEqual Valida que un objeto no es igual a otro objeto
Same Comprueba que dos objetos son del mismo tipo
NotSame Comprueba que dos objetos no son del mismo tipo
Aserción/método sobrecargado y comprueba que una cadena contiene una
Contains
subcadena determinada o una colección contiene un objeto
Aserción/método sobrecargado y comprueba que una cadena
DoesNotContain
no contiene una subcadena determinada o una colección no contiene un objeto
DoesNotThrow Verifica que el código no arroje excepciones
InRange Verifica que un valor esté en un rango inclusivo dado
IsAssignableFrom Verifica que un objeto sea de un tipo dado o un tipo derivado
Empty Verifica que una colección esté vacía
NotEmpty Verifica que una colección no está vacía
False Verifica que una expresión es falsa
True Verifica que una expresión es verdadera
IsType<T> Verifica que un objeto es de un tipo dado
IsNotType<T> Verifica que un objeto no es de un tipo dado
Null Verifica que una referencia de objeto es nula
NotNull Verifica que una referencia de objeto no es nula
NotInRange Verifica que un valor no sea en un rango inclusivo dado
Throws<T> Verifica que el código arroja una excepción exacta
xUnit
.Net Core Console
xUnit

User
Interface
Web
CLI
Application
Infrastructure

/> mkdir Proj ; cd Proj
---- ------------- ------ ----
d----- 7/15/2021 1:40 PM Proj
/Proj> dotnet new classlib -o src/Application

The template "Class library" was created successfully.
Running 'dotnet restore' on src/Application\Application.csproj...
Restore succeeded.
/Proj> dotnet new console -o src/ConsoleUI

Processing post-creation actions... Proj
Running 'dotnet restore' on src/ConsoleUI\ConsoleUI.csproj...
Restore succeeded.
/Proj> dotnet new webapp -o src/WebUI

ices for details.
Restore succeeded.
/Proj> dotnet add src/ConsoleUI reference src/Application


/Proj> dotnet run -p src/ConsoleUI

Hello World!
/Proj> dotnet run -p src/WebUI

Building...
Now listening on: https://localhost:5001
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
Hosting environment: Development
Content root path: C:\Users\user\Cubo\UI.Web

User
Interface
Application Unit Test
Infrastructure

/Proj> dotnet new xunit -o tests/Application.UnitTest
The template "xUnit Test Project" was created successfully.
Running 'dotnet restore' on tests/Application.UnitTest\Application.UnitTest.csproj...
Restore succeeded.
/Proj> dotnet add tests/Application.UnitTest reference src/Application

Reference `..\..\src\Application\Application.csproj` added to the project.
/Proj> dotnet build src/Application Proj

Microsoft (R) Build Engine version 16.10.2+857e5a733 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
src
All projects are up-to-date for restore.
Application -> E:\codes\is\Proj\Application\bin\Debug\net5.0\Application.dll
Application
Build succeeded.
0 Warning(s) ConsoleUI
0 Error(s)
Time Elapsed 00:00:01.89 WebUI
/Proj> dotnet test tests/Application.UnitTest tests
Restored E:\codes\is\Proj\Test.Unit\Test.Unit.csproj (in 319 ms). Application.UnitTest
1 of 2 projects are up-to-date for restore.
Application -> E:\codes\is\Proj\Application\bin\Debug\net5.0\Application.dll
Test.Unit -> E:\codes\is\Proj\Test.Unit\bin\Debug\net5.0\Test.Unit.dll
WebUI.IntegrationTest
Test run for E:\codes\is\Proj\Test.Unit\bin\Debug\net5.0\Test.Unit.dll (.NETCoreApp,Version=v5.0)
Microsoft (R) Test Execution Command Line Tool Version 16.10.0
Copyright (c) Microsoft Corporation. All rights reserved.
Starting test execution, please wait...

A total of 1 test files matched the specified pattern.
Passed! - Failed: 0, Passed: 1, Skipped: 0, Total: 1, Duration: < 1 ms - Test.Unit.dll (net5.0)

Clase base y test
public class Calculator using Xunit;
{
public double Sum(double num1, double num2) namespace Program.Unit.Tests
{ {
return num1 + num2;
{
}
[Fact]
public double Subtract(double num1, double num2) public void Calculator_Sum_Success()
{ {
return num1 - num2; // Arrange – Set up
} var arrange = 10;
public double Multiply(double num1, double num2) var calculator = new Calculator();
{
return num1 * num2; // Act – Perform
} var act = calculator.Sum(5, 5);
public double Division(double num1, double num2)
{
Assert.Equal(arrange, act);
return num1 / num2;
}
}
} [Fact]
public void Calculator_Sum_Fail()
{
var arrange = 8;
var calculator = new Calculator();
// Act – Perform
var act = calculator.Sum(5, 5);
}
}
}

Modificación del test
using Xunit;
namespace Program.Unit.Tests
{
{
[Theory]
[InlineData(-1, 2, 1)]
[InlineData(0, 4, 4)]
public void Calculator_Sum_Success(int n1, int n2, int res)
{
var arrange = res;
var calculator = new Calculator();
// Act – Perform
var act = calculator.Sum(n1, n2);
}
}
}

HTML
Conceptos basicos

H T M L e s e l l e n g u a j e d e m a rc a d o e s t á n d a r p a r a l a s
p á g i n a s We b .
<h1>
Título principal
</h1>
Título principal
<h6>
Título secundario Título secundario
</h6>
<p>
Lorem ipsum dolor sit amet,
Lorem ipsum dolor sit amet, consectetur consectetur adipiscing elit. Proin at
<strong>adipiscing</strong> elit. Proin
at consectetur odio.<br/>Praesent
consectetur odio.
iaculis tincidunt <em>urna</em>, eget Praesent iaculis tincidunt urna, eget
pellentesque justo tempus vitae.
</p>
pellentesque justo tempus vitae.
<img src="//placehold.jp/24/cc9999/993333
/150x100.png">

HTML Forms
<form>
First name:
<input type="text" name="fname">
<br>
Last name:
<input type="text" name="lname">
<br>
<br>
<button>Submit</button>
</form>

/Proj> dotnet new web -o src/WebUI
ices for details.
Restore succeeded.

https://gist.github.com/jyacomp/c07a55fac8b0d7e79b3a36e2126cae05

using System;
Proj using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
namespace WebUI
{
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddRazorPages();
}
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)

{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
app.UseRouting();
app.UseEndpoints(endpoints =>
{
endpoints.MapRazorPages();
// endpoints.MapGet("/", async context =>
// {
// await context.Response.WriteAsync("Hello World!");
// });
});
}
}
}

Proj @page
src @addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers
Application
Cuadrado.cs @using Application
ConsoleUI @functions
Program.cs {
double perimetro;
double area;
WebUI
public void OnPost(double lado)
Index.cshtml
{
Startup.cs area = Cuadrado.CalcularArea(lado);
perimetro = Cuadrado.CalcularPerimetro(lado);
}
Application.UnitTest }
UnitTestCuadrado.cs
<h1>
Calculadora de Área y Perímetro del Cuadrado
</h1>
<form method="POST">
Dame el lado: <input type="number" name="lado" step="0.01">
<br />
<button>Calcular</button>
</form>
<p>
Área: @(area)cm2<br />Perímetro: @(perimetro)cm
</p>

Proj using System;
src
Application namespace Application
Cuadrado.cs {
PrismaCuadrangular.cs public class PrismaCuadrangular
{
ConsoleUI public static double CalcularVolumen(double area, double altura)
Program.cs {
return area * altura;
}
WebUI
}
}
Index.cshtml
Startup.cs
Application.UnitTest
UnitTestCuadrado.cs

Proj using System;
src using Xunit;
Application using Application;
Cuadrado.cs
PrismaCuadrangular.cs namespace Application.UnitTest
{
ConsoleUI public class UnitTestPrismaCuadrangular
Program.cs {
[Theory]
WebUI
public void TestVolumen(double area, double altura, double volumen)
Index.cshtml {
Startup.cs // Arrange – Set up
// Act – Perform
Application.UnitTest double resultado = PrismaCuadrangular.CalcularVolumen(area, altura);
UnitTestCuadrado.cs
UnitTestPrismaCuadrangular.cs // Assert – Verify
Assert.Equal(resultado, volumen);
}
}
}

Proj using System;
src
Cuadrado.cs
PrismaCuadrangular.cs namespace ConsoleUI
{
ConsoleUI class Program
Program.cs {
{
WebUI
double perimetro;
double area;
Index.cshtml double volumen;
Startup.cs
Console.WriteLine("Calculadora de Perímetro, Area y Volumen de un Prisma Cuadrangular");
Application.UnitTest Console.Write("Dame el lado: ");

UnitTestCuadrado.cs double lado = Convert.ToDouble(Console.ReadLine());
Console.Write("Dame la altura: ");

double altura = Convert.ToDouble(Console.ReadLine());
perimetro = Cuadrado.CalcularPerimetro(lado);
area = Cuadrado.CalcularArea(lado);
volumen = PrismaCuadrangular.CalcularVolumen(area, altura);
Console.WriteLine($"Perímetro: {perimetro}cm\nÁrea: {area}cm2\nVolumen {volumen}cm3");

}
}
}

Proj @page
src @addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers
Application
Cuadrado.cs @using Application
PrismaCuadrangular.cs
@functions
ConsoleUI {
Program.cs double perimetro;
double area;
double volumen;
WebUI
public void OnPost(double lado, double altura)
Index.cshtml {
Startup.cs perimetro = Cuadrado.CalcularPerimetro(lado);
area = Cuadrado.CalcularArea(lado);
volumen = PrismaCuadrangular.CalcularVolumen(area, altura);
Application.UnitTest }
UnitTestCuadrado.cs }
<h1>
Calculadora de Área y Perímetro del Cuadrado
</h1>
<form method="Post">
Dame el lado: <input type="number" name="lado" step="0.01">
<br />
Dame la altura: <input type="number" name="altura" step="0.01">
<br />
<button>Calcular</button>
</form>
<p>
Área: @(area)cm2<br />Perímetro: @(perimetro)cm<br />Volumen: @(volumen)cm3
</p>


Integration
Tests
User Interface
Web Domain Mail
Application
Infrastructure

Pruebas de integración de inter faces internas
Desde una perspectiva sintáctica y semántica, las pruebas de integración (internas) no son tan
diferentes de las pruebas unitarias.
En una prueba unitaria se verifica los componentes aislados, y en las de integración se prueba la
comunicación entre los componentes y su dependencia con sistemas externos (bases de
datos, sistemas de archivos, etc).

/Proj> dotnet new xunit -o test/Application.IntegrationTest
Restore succeeded.
/Proj> dotnet add test/Application.IntegrationTest reference src/Application

Reference `..\..\src\Application\Application.csproj` added to the project.
https://gist.github.com/jyacomp/40f598667feb7bfd20a564dc18b44176

Proj using System;
src using Xunit;
Cuadrado.cs
PrismaCuadrangular.cs namespace Application.IntegrationTest
{
ConsoleUI public class IntegrationTestApplication
Program.cs {
[Theory]
WebUI
public void TestVolumen(double lado, double altura, double volumen)
Index.cshtml {
Startup.cs // Arrange – Set up
double area = Cuadrado.CalcularArea(lado);
Application.UnitTest // Act – Perform

UnitTestCuadrado.cs double resultado = PrismaCuadrangular.CalcularVolumen(area, altura);
UnitTestPrismaCuadrangular.cs
Application.IntegrationTest Assert.Equal(resultado, volumen);
IntegrationTestApplication.cs }
}
}

Ejemplo Proyecto Final Sof tware
git
.net 5
xUnit

BlackBoard
Sof tware
2ª par te del Proyecto de
Tests
Todos los integrantes
using System;
namespace Program
{
deben hacer por lo

class Program
{
static void Main()
{
Calculator cal = new Calculator();
menos un commit
double p = cal.Perimetro(8.5);
Console.WriteLine("P: " + p);
double a = cal.Area(8.5);
Documento.pdf
Console.WriteLine("A: " + a);
Metería:
}
}
}
Tema:
Integrantes:
Equipo:
Fecha:
Git*:
Git
src test
https://gist.github.com/jyacomp/92ddd3ef58d12cf8362c28f38d30bef0
https://d3vsoft-my.sharepoint.com/:w:/g/personal/luis_edu_d3v_mx/EXW4KWE3EIBKulxsYpBfeZIBl3nTNW3i2q5liUW6O2QHiA

Integration
Tests
User Interface
Web Domain Mail
Application
Infrastructure

/Proj> dotnet new xunit -o test/WebUI.IntegrationTest
Restore succeeded.
/Proj> dotnet add test/WebUI.IntegrationTest package Microsoft.AspNetCore.Mvc.Testing

Writing C:\Users\jlcar\AppData\Local\Temp\tmp193E.tmp
info : Adding PackageReference for package 'Microsoft.AspNetCore.Mvc.Testing' into project 'E:\codes\is\Proj\tests\WebUI.IntegrationTest\WebUI.IntegrationTest.csproj'.
...
info : Writing assets file to disk. Path: E:\codes\is\Proj\tests\WebUI.IntegrationTest\obj\project.assets.json
log : Restored E:\codes\is\Proj\tests\WebUI.IntegrationTest\WebUI.IntegrationTest.csproj (in 2.88 sec).
/Proj> dotnet add test/WebUI.IntegrationTest reference src/WebUI

Reference `..\..\src\WebUI\WebUI.csproj` added to the project.
https://gist.github.com/jyacomp/015b4768662c5756293529214b752053

Proj

Proj
src
Application
Cuadrado.cs
ConsoleUI
Program.cs
WebUI
Index.cshtml
Privacy.cshtml
Startup.cs
UnitTestCuadrado.cs
Application.IntegrationTest
IntegrationTestApplication.cs
IntegrationTestPages.cs

Proj
src
Application
Cuadrado.cs
ConsoleUI
Program.cs
WebUI
Index.cshtml
Privacy.cshtml
Startup.cs
UnitTestCuadrado.cs

Proj
src
Application
Cuadrado.cs
ConsoleUI
Program.cs
WebUI
Index.cshtml
Privacy.cshtml
Startup.cs
UnitTestCuadrado.cs

Recapitulación

CALIDAD EN EL CICLO DE VIDA DEL SOFTWARE
SDLC • ISO 12207 Software Process Life Cicle
CALIDAD EN EL PRODUCTO
PRODUCTO • ISO 9126 Software Engineering – Product Quality
• ISO 14598 Software Product Evaluation
• ISO 25000 (SQuaRE) Product Quality & Evaluation
SOFTWARE CALIDAD EN LOS PROCESOS

NORMATIVAS DE CALIDAD PROCESOS
• ISO 15504 (SPICE) Maturity Evaluation Level
• CMMI Capability Maturity Model Integration
CALIDAD EN LA GESTION Y SERVICIO

GESTION • ISO 9001+90003 Governance
• ISO 20000+ITIL IT Services Governance
• ISO 38500 IT Governance

CALIDAD EN EL CICLO DE VIDA DEL SOFTWARE
• ISO 12207 Software Process Life Cicle
SDLC
CALIDAD EN EL PRODUCTO
PRODUCTO • ISO 9126 Software Engineering – Product Quality
• ISO 14598 Software Product Evaluation
• ISO 25000 Product Quality & Evaluation
SOFTWARE CALIDAD EN LOS PROCESOS

PROCESOS ISO 15504 Maturity Evaluation Level
NORMATIVAS DE CALIDAD
•
• CMMI Capability Maturity Model Integration
CALIDAD EN LA GESTION Y SERVICIO

ISO 9001+90003 Governance
GESTION
•
• ISO 20000+ITIL IT Services Governance
• ISO 38500 IT Governance
SEGURIDAD
CALIDAD EN VARIABLES
• ISO 27001, SGSI Security Manamen

Revisión de proyectos

Sof tware metrics
Métricas de sof tware

E s t á n d a re s d e m e d i c i ó n
El objetivo es obtener mediciones objetivas, reproducibles y cuantificables en: plazos,
estimación de costos, control de calidad, pruebas, depuración de software, optimización
del rendimiento y asignaciones de tareas.
Principales marcos para medir el avance de un proyecto:

• McCall: Define tres etapas (factores, criterios y métricas) y once criterios (Exactitud,
confiabilidad, eficiencia, integridad, usabilidad, mantenibilidad, testeabilidad, flexibilidad,
portabilidad, reusabilidad e interoperabilidad).
• GQM o Goal Question Metric.

GQM Goal Question Metric
El modelo GQM es una estructura jerárquica que especifica a partir de un objetivo los efectos de
la medición, a partir de tres niveles. Su objetivo es medir el avance como los resultados de
algún proyecto, trabajando sobre metas, preguntas y métricas.
Nivel Conceptual (objetivo)

Se establece un objetivo para cada elemento de
medición, considerando el producto, proceso y los G1 G2
Análisis e Interpretación
recursos, desde diferentes puntos de vista.
Nivel Operacional (Pregunta)

Definición
Con base en los objetivos se establece un conjunto de

preguntas que permiten caracterizar la evaluación /
Q1 Q2 Q3 Q4 Q5
logro de un objetivo específico.
Nivel Cuantitativo (métrico)

A cada pregunta se le asocian métricas que permitan
dar respuesta cuantitativa a los objetivos, de manera M1 M2 M3 M4 M5 M6
objetiva o subjetiva.

Estimación de costos
Métricas de sof tware

Estimación de costos
Enfoque de estimación Categoría
Source Lines Of Code, Function Point Analysis,Use Case
Basada en el tamaño Modelo de estimación formal Analysis, Use Case Points, SSU (Software Size Unit), Story
points-based estimation, Object Points
Basada en analogía Modelo de estimación formal ANGEL, Weighted Micro Function Points
Project management software, company specific activity

Basada en WBS Estimación de expertos
templates
Modelos paramétricos Modelo de estimación formal COCOMO, SLIM, SEER-SEM, TruePlanning for Software
Estimación del grupo Estimación de expertos Planning poker, Wideband delphi
Estimación basada en Average of an analogy-based and a Work breakdown

Combinación mecánica
combinaciones structure-based effort estimate
Combinación de Estimación basada en Expert judgment based on estimates from a parametric

sentencia combinaciones model and group estimation

S o u rc e L i n e s O f C o d e S LOC
• Medida directa del producto de software
• Genera un histórico de información (se obtiene métricas útiles):
• Una funcionalidad puede variar sus SLOC dependiendo del lenguaje de programación
• Las SLOC varían entre deferentes desarrolladores (mas eficientes que otros) definiéndose :
• Physical line of code LOC
• Logical lines of code LLOC
/* Now how many lines of code is this? */

for (i = 0; i < 100; i++)
{
printf("hello");
}
for (i = 0; i < 100; i++) printf("hello"); /* How many lines of code is this? */

M e d i c i ó n d e s of t w a re e n i n g e n i e r í a d e s of t w a re
La medición del software se define y rige por la norma ISO/IEC 15939 (proceso
de medición de software).
El método más fiable de medición debe estar basado en el punto de vista del usuario (puntos
de función FP), los cuales se encuentran descritos en la norma ISO/IEC 14143 y que define
varias normas como:
• COSMIC: ISO/IEC 19761:2011 Software engineering. A functional size measurement method.
• IFPUG: ISO/IEC 20926:2009 Software and systems engineering – Software measurement – IFPUG
functional size measurement method.
• Mark-II: ISO/IEC 20968:2002 Software engineering – Ml II Function Point Analysis – Counting Practices
Manual
• Nesma: ISO/IEC 24570:2018 Software engineering – Nesma functional size measurement method
version 2.3 – Definitions and counting guidelines for the application of Function Point Analysis
• FiSMA: ISO/IEC 29881:2010 Information technology – Systems and software engineering – FiSMA 1.1
functional size measurement method.

Product
Governance
Assessment
Implementation and
42010 And
9001 Architecture
Quality System
15288 12207 15504 9126
330xx 14598
38500 24748-2 24748-3 29169 14756
Software Quality
Governance
15289 Process
Assessment
26511 24748-4
26512 90005 19770-1 25000
26514 19770-8 SQuaRE
24765 26515 24748-1 29110 Asset

Process
Management 19761
Description
29148 29119 14764 20926
Requirements Testing Software Manintenance
20968
20000 24570
BOK 16326 15026, 16085 15939, 29155 29881
Size Measurement
Professionalization
16337
19759 3535, 5806 14102, 14471 10746, 13235, 14750 8807, 15437 14568
Tools and
BOK
Methods
5807, 8631 15940, 18018 14752, 14753, 14769 15909, 19501 15474
24773 8790, 11411 23026, 24766 14771, 15414, 19500 19505, 19793 15475
29154 12182, 14759 26500, 26501 19770-2, 19770-3 24744, 19505 15476
Cerification
Envirinment 19770-6, 19770-7 19507 19506

IFPUG - ISO/IEC 20926 - functional size
m e a s u re m e n t m e t h o d
• Identificación de los componentes necesarios para el cálculo.
• Cálculo de los Puntos Función no ajustados.
• Ajuste de los Puntos Función.
FPA = PFNA * FA
FA = 0.65 + (0.01 * SVA)
Complejidad
Descripción Cuenta Total
Simple Medio Complejo
Entradas Externas (EI) x3 x4 x6
Salidas Externas (EO) x4 x5 x7
Numero de Consultas Externas (EIN) x3 x4 x6
Ficheros Internos Lógicos (ILF) x7 x 10 x 15
Ficheros Externos Lógicos (ELF) x5 x7 x 10
Puntos de Función No Ajustados (PFNA)
IFPUG - ISO/IEC 20926
Atributos Influencia
1 Comunicación de datos
2 Funciones distribuidas
3 Prestaciones
4 Gran uso de la configuración
5 Velocidad de las transacciones
6 Entrada de datos en línea
7 Diseño para la eficiencia del usuario final
8 Actualización de datos en línea
9 Complejidad del proceso lógico interno de la aplicación
10 Reusabilidad del código
11 Facilidad de instalación
12 Facilidad de operación
13 Localizaciones múltiples
14 Facilidad de cambios
Suma de los valores de los atributos (SVA)

Mark-II: ISO/IEC 20968 – Counting Practices Manual
Evolución del método de Allan J. Albrecht () que
contempla el sistema como una colección de
transacciones lógicas compuestas por componentes
de entrada, de proceso y de salida
PFA = PFNA * ACT

ACT = 0.65 + 0.005 * TGI

CO CO M O
COnstructive COst MOdel (Modelo Constructivo de Costos), es un modelo matemático de
regresión con base en SLOC (número de líneas de código) y que define 3 modelos: básico,
intermedio y detallado
Las ecuaciones que se utilizan en los tres modelos son:

𝒃𝒃
𝑬𝑬 = 𝒂𝒂 𝑲𝑲𝑲𝑲
donde:
• E es el esfuerzo requerido por el proyecto, en persona-mes
• Tdev es el tiempo requerido por el proyecto, en meses
• P es el número de personas requerido por el proyecto
• a, b, c y d son constantes con valores definidos en una tabla, según cada submodelo
• Kl es la cantidad de líneas de código, en miles.
• m(X) Es un multiplicador que depende de 15 atributos.

COCOMO
Submodelos
Cada submodelo ofrece un modo (nivel de detalle y aproximación cada vez mayor), a medida que avanza
el proceso de desarrollo del software.
Modo KLDC a b c d
Simple – Orgánico < 50 2.40 1.05 2.50 0.38
Moderada – Semiorganico < 300 3.00 1.12 2.50 0.35
Incrustada - Empotrado > 300 3.60 1.20 2.50 0.33
Cada submodelo se divide en modos que representan el tipo de proyecto, y puede ser:
• Simple - orgánico: proyectos pequeños de < 50KLDC y con experiencia en proyectos similares; para
pequeños grupos de programadores experimentados.
• Moderado - semiorganico, semilibre o semiencajado: complejidad media de < 300 KLDC y con poca
experiencia en proyectos similares; el grupo de desarrollo puede incluir una mezcla de personas
experimentadas y no experimentadas.
• Incrustado - rígido o empotrado: proyectos complejos donde la experiencia es nula y se utiliza
tecnologías de frontera; el proyecto tiene fuertes restricciones, que pueden estar relacionadas con la
funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es difícil basarse en la
experiencia, puesto que puede no haberla.

Simple (Básico): m(X) = 1
Intermedio: m(X) = RELY * DATA * CPLX * TIME * STOR * VIRT * TURN * ACAP * AEXP * PCAP * VEXP * LEXP * MODP * TOOL * SCED
Valor
Atributos
Muy bajo Bajo Nominal Alto Muy alto Extra alto
Atributos de software
Fiabilidad 0,75 0,88 1,00 1,15 1,40
Tamaño de Base de datos 0,94 1,00 1,08 1,16
Complejidad 0,70 0,85 1,00 1,15 1,30 1,65
Atributos de hardware
Restricciones de tiempo de ejecución 1,00 1,11 1,30 1,66
Restricciones de memoria virtual 1,00 1,06 1,21 1,56
Volatilidad de la máquina virtual 0,87 1,00 1,15 1,30
Tiempo de respuesta 0,87 1,00 1,07 1,15
Atributos de personal
Capacidad de análisis 1,46 1,19 1,00 0,86 0,71
Experiencia en la aplicación 1,29 1,13 1,00 0,91 0,82
Calidad de los programadores 1,42 1,17 1,00 0,86 0,70
Experiencia en la máquina virtual 1,21 1,10 1,00 0,90
Experiencia en el lenguaje 1,14 1,07 1,00 0,95
Atributos del proyecto
Técnicas actualizadas de programación 1,24 1,10 1,00 0,91 0,82
Utilización de herramientas de software 1,24 1,10 1,00 0,91 0,83
Restricciones de tiempo de desarrollo 1,22 1,08 1,00 1,04 1,10

Ejemplo
propio equipo anteriormente han desarrollado aplicaciones
similares
𝒃𝒃 𝒅𝒅 𝑷𝑷 = 𝑬𝑬/𝑻𝑻𝒅𝒅𝒅𝒅𝒅𝒅
𝑬𝑬 = 𝒂𝒂 𝑲𝑲𝑲𝑲 𝒎𝒎(𝑿𝑿) 𝑻𝑻𝒅𝒅𝒅𝒅𝒅𝒅 = 𝒄𝒄 𝑬𝑬
𝟏𝟏.𝟎𝟎𝟎𝟎 hombres en
𝑬𝑬 = 𝟐𝟐. 𝟒𝟒 𝟑𝟑𝟑𝟑 𝟏𝟏 𝑬𝑬 = 𝟗𝟗𝟗𝟗. 𝟑𝟑𝟑𝟑 𝑬𝑬 = 𝟗𝟗𝟗𝟗 un mes
𝟎𝟎.𝟑𝟑𝟑𝟑 𝑻𝑻𝒅𝒅𝒅𝒅𝒅𝒅 = 𝟏𝟏𝟏𝟏. 𝟖𝟖𝟖𝟖

𝑻𝑻𝒅𝒅𝒅𝒅𝒅𝒅 = 𝟐𝟐. 𝟓𝟓 𝟗𝟗𝟗𝟗 𝑻𝑻𝒅𝒅𝒅𝒅𝒅𝒅 = 𝟏𝟏𝟏𝟏. 𝟗𝟗 meses
𝑷𝑷 = 𝟗𝟗𝟗𝟗/𝟏𝟏𝟏𝟏. 𝟗𝟗 𝑷𝑷 = 𝟔𝟔. 𝟓𝟓𝟓𝟓 𝑷𝑷 = 𝟕𝟕 hombres

Ingenieria de Software

Cargado por

Copyright:

Formatos disponibles

Ingenieria de Software

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingenieria de Software

Cargado por

Copyright:

Formatos disponibles

Preguntas detonantes

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

26512 90005 19770-1 25000

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

6.4. Verification / Verificación

7.1. Management / Gestion 6.6. Joint Review / Revisión conjunta

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

5.2.3. Contact / Contacto

5.3. Development / Desarrollo 5.2.7. Delivery & completion / Entrega y finalización

5.3.13. Software acceptance support 5.4. Operation / Operación

5.4.3. System operation 5.4.4. User support

5.5.3. Modification implementation

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

6.4. Verification / Verificación

7.1. Management / Gestion 6.6. Joint Review / Revisión conjunta

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

5.2.3. Contact / Contacto

5.3. Development / Desarrollo 5.2.7. Delivery & completion / Entrega y finalización

5.3.13. Software acceptance support 5.4. Operation / Operación

5.4.3. System operation 5.4.4. User support

5.5.3. Modification implementation

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

Las obligaciones y derechos

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

5.2.3. Contact / Contacto

5.3. Development / Desarrollo 5.2.7. Delivery & completion / Entrega y finalización

5.3.13. Software acceptance support 5.4. Operation / Operación

5.4.3. System operation 5.4.4. User support

5.5.3. Modification implementation

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

Incluye el Plan de Gestión del Proyecto – Project Management Plan

Las obligaciones y derechos del

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

5.3.2. System requirements analysis / 5.3.11. System qualification testing /

5.3.4. Software requirements design / 5.3.9. Software qualification testing /

5.3.5. Software architecture design / 5.3.8. Software Integration /

5.3.6. Software detailed design /

5.3.7. Software coding and testing /

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

BUSCAR y CORREGIR errores

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

5.2.3. Contact / Contacto

5.3. Development / Desarrollo 5.2.7. Delivery & completion / Entrega y finalización

5.3.13. Software acceptance support 5.4. Operation / Operación

5.4.3. System operation 5.4.4. User support

5.5.3. Modification implementation

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

Existen cuatro tipos de implementación:

Juan Luis Carrillo Garcia | j u a n _ ca r r i l l og @ my. u ni te c. e d u. mx | @ jyacomp | linkedin.com/in/jlcarrillog/

5.2.3. Contact / Contacto

5.3. Development / Desarrollo 5.2.7. Delivery & completion / Entrega y finalización