SOFTWARE DELIVERY

Metodologías de Desarrollo de Software

Metodologías Tradicionales / Waterfall o Cascada

Software System Engineering - Definiciones

System Engineering – Puntos de Control

Proyecto vs Operaciones
 Software Delivery - Fundamentos
• Los proyectos de Desarrollo de Software usan diferentes tipos de
metodologías de software development life cycle (SDLC),
dependiendo de su naturaleza y requerimientos, los cuales
básicamente definen como se organizará el trabajo.
Tradicional o método en cascada (waterfall) Cuales son sus diferencias?
Las dos metodologías
mayormente en uso son:
Cual es conveniente elegir
Método de Desarrollo Agile (Agil).
para mi Proyecto?

Estas preguntas son las que se hacen muchas Empresas, Gerentes y Project Managers hoy en día.
Explicaremos cada una de estas metodologías para poder sacar nuestras propias conclusiones.

En los próximos slides veremos las diferentes alternativas de metodologías en cascada

en función de diferentes normas de uso habitual
 Software Delivery - Fundamentos
• Roles en proyectos Tradicionales o en Cascada:
Dirije el proyecto maneja el presupuesto, tiempo,
recursos, es quien negocia con el cliente.
Project Manager
Ayuda al Project Manager en llevando a cabo las
Project Manager Office (PMO) reunions y archivando la documentación
Business Analyst - analista Diseña el Sistema lógicamente

Lider de Desarrollo – Technical Lead Lidera a los programadores

Desarrollador
Nombre del Rol:
Lider de Testing – Test Lead Lidera a los testers

Tester
Diseña el Sistema físicamente
Arquitecto
Configuration Manager Realiza las implementaciones del sistema
IT Support Mantienen el hardware necesario para el proyecto
 Waterfall Delivery Methodology – Alternativas
Concept Plan Qualify EOL
DCP DCP DCP DCP
Management
Process

BTOP
Pre-Concepto Concept Plan Desarrollo Qualify Rollout Life Cycle
(Opcional)

BRR SRR PDR CDR TRR PRR

System Development
Process

Waterfall Method Solution Solution Micro Acceptance

Macro Design Build Deploy Production
Design Outline Design Test
supplemented by
System Component
Preliminary Component Integration and
Waterfall Method Requirements & Requirements & Production
Assessment Architecture Architecture Develop & Test Test
Change
Management Release Content Management
Process (Manage Changes to Customer Baseline - System Baseline - Architecture Baseline - Design Baseline)

Inicial Pre-Concept Exit Concept Exit Plan Exit

ROM Costo Estimado Refinar Costo Estimado Costo Final Estimado
Change Request

Project Office

Reunir y analizar Requerimientos finales y Diseñar y Component Test Puesta en Produccion

Requerimientos iniciales Definir System Architecture Desarrollar Integration Test Comienzo de SW Life-Cycle Management
Definicion Preliminar Desarrollar Requerimientos Detallados La Solución System Test
Solucion Técnica Performance & Stress Test
User Acceptance Test

03.12.2019
 Waterfall Delivery Methodology - Baselines
Logical Physical
Data Model Data Model

System Baseline Functional & Physical Architecture

P roject O bjectives D ocument

Physical
System Functional
Architecture
Architecture Architecture
(Context Diagram)

Customer Baseline Component Requirements

P roject O bjectives D ocument
Requirements
Business System
Traceability Component Requirements
Need & Requirements
Matrix Requirements Traceability
Rationale Specifications Matrix

System
Business System Component
Customer Requirements Component
Process Acceptance Requirements Component
Requirements Verification Acceptance Component
Flows Criteria Verification Design
Matrix Criteria Test Plan
Matrix Specifications

Customer System Architecture Design

Baseline Baseline Baseline Baseline

BRR SRR PDR CDR

(Optional)

Necesidad Conceptual Preliminary Detail Design &

Oportunidad System Design System Design Development

CONCEPT PLAN DEVELOP

Customer Provided Produced by IT Architect IT Architect Provided Data Modeler Provided Application Developer Provided
03.12.2019 in collaboration with Customer
 Waterfall Delivery Methodology – Qualify Phase

03.12.2019
 Waterfall Delivery Methodology

03.12.2019
 Waterfall Delivery Methodology

Trabajando desde el principio del proyecto en SQA asegura una etapa de test mas limpia !!!
Asegurando un limpio y corto User Acceptance Test !!!
Proveyendo confianza para IT y los Usuarios en las aplicaciones que llegan a UAT !!!
 Waterfall Delivery Methodology – Qualify Phase

Pre-Concept and Plan Build Qualify Rollout

Concept Phase Phase Phase Phase

Ideas Planificacion Haciendo el Test Go live

Trabajo
Que debe hacer hacer SQA Que debe hacer hacer SQA Que debe hacer hacer SQA
Comprender la idea. Que debe hacer hacer SQA Build SAT environment Lessons Learned
Comprender la Arquitectura, Test Plan TC´s cycles execution Complete Documentation
Complejidad, lenguaje, etc. Test Cases Design Defect Management Metricas de Efectividad (TEI)
Test Data Elaboration Code Review
SAT Certificate
Provide elements to build
SQA Review SQA Review UAT environment
Requirements Review Architecture Inspection User training
Project Test Strategy Design Inspection User Support
Identificación de Test UAT Certificate SQA Review
Cases temprana Post Implementation
SQA Review Review
Component Test (SAT)
Integration Test (SIT)
User/acceptance Test (UAT)
Regression Test
10
 Waterfall Delivery Methodology

Software Systems Engineering

Definiciones - Guias

03.12.2019
 System Context Diagram Definition Guidelines

System Context Diagrams (Diagramas de Contexto):

 Representan la solución técnica diseñada para satisfacer los requisitos del cliente,
 Describen el sistema operando como una "caja negra" dentro de su entorno,

 Identifican todos los componentes a nivel del sistema necesarios para lograr la solución
técnica,

 Identifican todas las entidades externas con las que el sistema interactúa,
 Especifica el tipo de información que se manejará en cada interfaz externa,

 Ayuda a establecer los límites del sistema (alcance).

03.12.2019
 System Requirements Definition Guidelines
System Requirements:
 están documentados en el lenguaje del ingeniero de sistemas,
 se derivan de los requisitos del cliente,
 son trazables a los requisitos que cumplen del cliente,
 pueden especificar un requisito funcional o no funcional,
 se definen de manera que cada requisito sea verificable individualmente durante la prueba
de integración,

 se definen desde la perspectiva del sistema que funciona como una "caja negra" dentro de
su contexto;

 elaboran la naturaleza de las interfaces entre el sistema y las entidades externas,

 elabora el comportamiento del sistema de "caja negra",
 cada requisito se identifica con un número único para permitir la trazabilidad de los
requisitos y la gestión del cambio.

03.12.2019
 Arquitectura Funcional Definición - Guías

Functional Architecture:

 descompone la arquitectura a nivel de sistema (Diagrama de contexto),

 identifica los componentes funcionales que se desarrollarán, mejorarán o utilizarán "tal cual"
para generar cada interfaz externa y cada función nueva/modificada del sistema,

 identifica todas las interfaces internas, entre componentes funcionales,

 incluye una descripción E2E (End to End) de principio a fin de la función del sistema,
 asigna los requisitos del sistema a los componentes funcionales,

 es una entrada clave para el desarrollo de los requisitos de los componentes.

03.12.2019
 Arquitectura Fisica Definición - Guías

Physical Architecture:

 define todos los componentes físicos necesarios para implementar la arquitectura a nivel
del sistema,

 Incluye una representación gráfica de los componentes físicos del sistema,

 Identifica todas las conexiones entre componentes físicos,

 Identifica todos los protocolos de acceso y comunicación de datos que deben estar
disponibles entre los componentes físicos,

 Asigna componentes funcionales a componentes físicos,

 Incluye una definición de todos los nombres de software y versiones que se instalarán en
cada componente físico.

03.12.2019
 Component Requirements Definition Guidelines

Component Requirements:

 están documentados en el lenguaje del ingeniero de sistemas,

 se derivan de los requisitos del sistema,
 son trazables de nuevo a los requisitos del sistema que cumple,
 puede especificar un requisito funcional o no funcional,
 se definen de manera tal que cada uno sea verificable individualmente durante la prueba de
componentes,

 define la elaboración y la naturaleza de las interfaces internas entre componentes

funcionales,

 define la elaboración y el comportamiento del componente funcional como una "caja negra"
dentro de su contexto.

03.12.2019
 Waterfall Delivery Methodology

Systems Engineering
Technical Checkpoint Reviews
Puntos de Control

03.12.2019
 System Requirements Review (SRR)
SRR Objetivos:
 Revisar y aprobar los requisitos documentados del sistema y los procesos de negocio
 Establecer la línea de base técnica
 Revise los requisitos de performance, datos, disponibilidad y soporte al desarrollo
 Establecer trazabilidad, identificar riesgos técnicos y revisar planes de mitigación.
 Identificar dependencias y establecer planes de gestión

 Debe ser realizado al final de la fase de concepto

 Items a Revisar:
 Requerimientos del Cliente (Customer Requirements)
 System Requirements
 Context Diagram
 Requirements Traceability Matrix: System Requirements to Customer Requirements
 Draft System Requirements Verification Matrix (SRVM)
- Criterio de Acceptación Acceptance Criteria para cada Customer y System Requirement
 Riesgos Tecnicos y Planes de Mitigación
 Dependencias y Planes de Gestión.
 Visto bueno del Cliente y Project Manager (Customer & Project Manager Sign-Off) y se establece la Customer
Baseline
 Guardar las plantillas y puntuación de cada punto en el repositorio del proyecto
03.12.2019
 Preliminary Design Review (PDR)
PDR Objetivos :
Revisar la descomposición functional y la arquitectura física
Verifcar la Arquitectura Funcional contra los System Requirements relevados
Revisar la Arquitectura de Test (software y hardware)
Revisar y aprobar los component requirements documentados y los escenarios de negocio
Establecer Trazabilidad, Identifocar Riesgos técnicos y Revisar los planes de mitigación
Identificar Dependencias y Establecer los planes de gestión
Se debe conducir durante la fase de PLAN

Items Revisados:
Functional Architecture – descompuesta al nivel de detalle de cada componente funcional
System Requirements trazados con los functional components
Arquitectura Fisica
Functional components trazados con los components físicos
Arquitectura de Test (software y hardware)
Component Requirements

Requirements Traceability Matrix: Component Requirements vs System Requirements

Component Requirements Verification Matrix (CRVM)
Criterio de Aceptación para cada Component Requirement
Riesgos Tecnicos y Planes de Mitigación
Dependencias y Planes de Gestión
Customer & Project Manager Sign-Off (Aprobación del Cliente y Project Manager) y establecer la System Baseline.

Guardar las plantillas y puntuación de cada punto en el repositorio del proyecto

03.12.2019
 Critical Design Review (CDR)
CDR Objetivos :
Verificar que el diseño técnico cubre el total end-to-end de los components requirements
Verificar el plan detallado de test de componentes
Verificar end-to-end que el test valida los system requirements
Verificar que la capacidad de la infraestructura de producción soporta los system requirements.
Establecer la Trazabilidad, Identificar los riesgos Técnicos y revisar los Planes de Mitigación
Identificar Dependencias y Establecer los planes de gestión

Conducida tempranamente en la fase de DESARROLLO

Items Revisados:
Especificaciones de diseño de Componentes
Component Requirements vs Component Designs
Component Test Strategy y Planes de Test
Test Architecture
Guardar las plantillas y puntuación de cada punto en el repositorio del proyecto

03.12.2019
 Test Readiness Review (TRR)
TRR Objetivos :
Verificar Test requirements vs system requirements
Trazar aplicaciones, infraestructura, estructuras de soporte
Revisar y aprobar los métodos de test (test, inspección, o análisis)
Revisar el test plan de riesgos, & los planes de mitigacion

Conducido al comienzo de la Fase de Calidad (Qualify Phase)

Guardar las plantillas y puntuación de cada punto en el repositorio del proyecto

03.12.2019
 Production Readiness Review (PRR)

PRR Objetivos :
Evaluar los resultados de los test
Evaluar la completitud del plan de puesta en producción
Revisar el Lifecycle management y plan de soporte a producción

Conducido al final de la Fase de Calidad (Qualify Phase)

Guardar las plantillas y puntuación de cada punto en el repositorio del proyecto

03.12.2019
 Solution Delivery Methodology Architecture

Technical Architecture Solution Framework

Fundamentals
Based on Zachman International Concept

03.12.2019
 ARCHITECTURE FRAMEWORK
DATA FUNCTION NETWORK PEOPLE TIME MOTIVATION
(What) (How) (Where) (Who) (When) (Why)

Scope List of Things Important to List of Processes the List of Locations in which List of Organizations List of Events Significant List of Business Goals & Scope
(Contextual) the Business Business Performs the Business Operates Important to the Business to the Business Strategies (Contextual)

Business Business
Executive's Entity=Class of Business Function=Class of Business End = Major Business Goals Executive's
View Things Processes Node = Business Location People = Major Organizations Time = Major Business Events Means = Critical Success Factors View
Enterprise Subject Area Data Model Business Process Model Logistics Network Work Flow Model Master Schedule Business Plan Enterprise
Model Model
(Conceptual) (Conceptual)
2
Process Process
Owner's Owner's
View Entity = Business Entity Process = Business Process Node = Business Unit People = Organization Unit Time = Business Events End = Business Objectives View
Relation = Business Rule I/O = Business Resource Link = Business Linkage Work = Work Product Cycle = Business Cycle Means = Business Strategy
System Model Logical Data Model Application Architecture Distributed Systems Human Interface Processing Structure Business Rule Model System Model
(Logical) Architecture Architecture (Logical)

Entity = Data Entity Process=Application Function Node = Processor/Storage/Access People = Roles Time = System Events End = Structure Assertion
Architect's View Relation = Data Relationship I/O = User Views Link = Line Characteristics Work = Deliverables Cycle = Processing Cycle Means = Action Assertion Architect's View
Technology Physical Data Model System Design System Architecture Presentation Architecture Control Structure Rule Design Technology
Model Model
(Physical) (Physical)

Entity = Segment/Table/etc. Process=Computer Function Node = Hardware/System Software People = Users Time = Execute End = Condition
Designer's View Relation = Keys/Pointers/etc. I/O = Screen/Device Formats Link = Line Specification Work = Screen Format Cycle = Component Cycle Means = Action Designer's View
Detailed Data Definition Program Network Architecture Security Architecture Timing Definition Rule Specification Detailed
Description Description

(Out of Context) (Out of Context)

5

Entity = Field Process=Language Statement Node = Addresses People = Identify Time = Interrupt End = Sub-condition
Developer's View Relation = Addresses I/O = Control Blocks Work = Job Cycle = Machine Cycle Means = Step Developer's View
Link = Protocols
FUNCTIONING FUNCTIONING
SYSTEM DATA FUNCTION NETWORK ORGANIZATION SCHEDULE STRATEGY SYSTEM
6
User's View User's View
03.12.2019 Copyright - John A. Zachman, Zachman International
 Architecture Framework –System Deliverables

Business Need and Rationale

Business Process Flows
Customer Requirements
System Architecture (Context)
System Requirements
Functional Architecture
Physical Architecture
Logical Data Model
Component Requirements Specifications

Component Design
Physical Data Model
Source Code
Data Definition Language
Executable Object Code
Instantiated DataBase
Physical System Infrastructure

03.12.2019
 Solution Delivery Methodology Architecture

Proyectos vs Operaciones
Conceptos

03.12.2019
 Proyectos
(Cada hombre debería) plantar un árbol, tener un hijo, y escribir un libro.

– frase atribuida al Talmud y a Jose Martí, revolucionario y poeta cubano

El Proyecto
Corto plazo No hay revenue No hay daño a los clientes o a la compañía por defectos
 Operaciones

Hacer crecer a un niño Hacer crecer al árbol Hacer que la gente lea
el libro

Operaciones

Medio o largo plazo Produce revenue Se generan daños al cliente o compañía por defectos
 Proyectos vs Operaciones
Alguna gente dice:

Tener un hijo, plantar un árbol y escribir un libro no es la parte difícil

Lo difícil es hacer crecer al niño, hacer crecer el árbol, hacer que la gente lea el libro

El punto es que el objetivo de los proyectos es que produzcan un software a ser operado por largo tiempo

Uno tiene dependencias en el otro

¿Quien haría un proyecto que nunca va a estar operativo?

Y como se puede implementar una mejora o crear un nuevo servicio sin un proyecto

Ambas partes son importantes, aún asi la satisfacción del cliente por llevar a cabo un buen proyecto
se da cuando la implementación cubre las expectativas generadas y las operaciones requeridas,
son simples y efectivas.
 Proyecto vs Operaciones
+/- 10 a 20% + / - 80 a 90 % del E2E lifecycle

Proyecto Operaciones

Debemos comenzar a End to End Lifecycle Las soluciones deben

pensar en todo el Life tener todas las
cycle para diseñar una funcionalidades
buena solución. necesarias y un sencillo
mantenimiento y
upgrade.

Pensamos …. Este es el proyecto REAL asi ???!!

 Proyecto vs. Operaciones
Pensar desde el comienzo
• Diseño de 3 capas • Diagramas de • El Test Automation debe
• Middleware para arquitectura de Alto ser pensado desde el
conectar el back y Nivel de: principio
frontend. – Logical design • Non functional
– Physical design
• Lenguaje de Requirements deben ser
programación con una • Prototipos cuando es capturados desde el
amplia y solida base de posible principio
programadores. • Requerimientos con fase • Volumen de datos vivos
• Sin codigo hardcodeado de clarificación: a ser administrados
– Cada requerimiento debe deben ser medidos
• Comentarios claros por ser específico
sección y en caso de ser – Cada requerimiento debe
desde el principio.
muy complejo por línea. poder ser medido o • Volumen de datos a ser
validado por un test case archivados deben ser
• Glosario y definición de – Debe haber Suppert
uso de las variables. Matter Experts del cliente
medidos desde el
para dar ayuda al principio.
• Uso de subrutinas, store
procedures y librerías
desarrollo.
• Disaster Recovery debe
– Simulaciones del diseño
todo lo posible. deben ser posibles. ser pensado desde el
principio
• Perfiles de Seguridad
bien definidos.
 Diferencias entre Crecimiento & Desarrollo

Crecimiento Desarrollo
Crecer es incrementar la medida o El Desarrollo involucra incrementarlos skills y competencias.
cantidad. Es la respuesta a lo que Podemos hacer con lo que tenenos.

Development
Growth

No es suficiente con hacer las cosas, estas deben estar bien hechas en tiempo y forma de una manera efectiva.

03.12.2019
GRACIAS POR SU ATENCION !!!!