Administración de Proyectos de TI

Nombre de la asignatura:

Administración de Proyectos de TI I

Competencias

Dirigir proyectos de tecnologías de información (TI) para contribuir a la productividad y logro de los objetivos estratégicos de las organizaciones utilizando las metodologías apropiadas. Evaluar sistemas de tecnologías de información (TI) para establecer acciones de mejora e innovación en las organizaciones mediante el uso de metodologías para auditoría.

Cuatrimestre

8

Horas Prácticas

30

Horas Teóricas

30

Horas Totales

60

Horas Totales por Semana Cuatrimestre

4

Objetivo

El alumno establecerá los parámetros de ejecución y control del proyecto de TI, para su administración en un entorno de calidad.

Evaluaciones por Unidad

Clifford Gray (2009) Administración de proyectos México, D.F. México

Harold Kerzner Ph.D. (2009) Project Management: A Systems Approach to Planning, Scheduling, and Controlling 10 edition New Jersey EE.UU.

Project Management Institute (2008) A guide to the project management 4 edition Pennsylvania EE.UU.

Cuaderno de trabajo

Da clic aquí para descargar las indicaciones

Tema 1 - Concepto de administración de proyectos de TI

La siguiente información es tomada del libro Ingeniería de Software, Sommerville, 9na Edición

1. ¿Qué es software? Programas de cómputo y documentación asociada.
2. ¿Cuáles son los atributos del buen software? El buen software debe entregar al usuario la funcionalidad y el desempeño requeridos, y debe ser sustentable, confiable y utilizable.
3. ¿Qué es ingeniería de software? La ingeniería de software es una disciplina de la ingeniería que se interesa por todos los aspectos de la producción de software.
4. ¿Cuáles son las actividades fundamentales de la ingeniería de software? Especificación, desarrollo, validación y evolución del software.
5. ¿Cuál es la diferencia entre ingeniería de software y ciencias de la computación? Las ciencias de la computación se enfocan en teoría y fundamentos; mientas la ingeniería de software se enfoca en el sentido práctico del desarrollo y en la distribución de software.
6. ¿Cuáles son los principales retos que enfrenta la ingeniería de software? Se enfrenta con una diversidad creciente, demandas por tiempos de distribución limitados y desarrollo de software confiable.
7. ¿Cuáles son los costos de la ingeniería de software? Aproximadamente 60% de los costos del software son desarrollo, y 40% de prueba. Para el software elaborado especificamente, los costos de evolución superan con frecuencia los costos de desarrollo.
8. ¿Cuáles son los mejores métodos y técnicas de la ingeniería de software? Aún cuando todos los proyectos de software deben gestionarse y desarrollarse de manera profesional, existen diferentes técnicas que son adecuadas para distintos tipos de sistema. Por ejemplo, los juegos siempre deben diseñarse usuando una serie de prototipos, mientras que los sistemas críticos de control de seguridad requieren de una especificación completa y analizable para su desarrollo. Por lo tanto, no puede decirse que un método sea mejor que otro.
9. ¿Qué diferencias ha marcado la Web a la ingeniería de software? La Web ha llevado a la disponibilidad de servicios de software y a la posibilidad de desarrollar sistemas basados en servicios distribuidos ampliamente. El desarrollo de sistemas basados en Web ha conducido a importantes avances en lenguajes de programación y reutilización de software.
10. ¿Qué tipos de productos software existen? Existen los productos genéricos y productos personalizados (o a la medida).

Estos son los atributos del buen software:

1. Mantenimiento
2. Confiabilidad y seguridad
3. Eficiencia
4. Aceptabilidad

Estos son algunos estándares de comportamiento aceptable de software:

1. Confidencialidad
2. Competencia
3. Derechos de propiedad intelectual (patentes y copyright)
4. Mal uso de computadoras (el uso incorrecto para daño a terceros)

Concepto de administración de proyecto de software
Planta y disposición que se forma para un tratado o para la ejecución de una cosa de importancia. Designio de ejecutar algo. Conjunto de escritos, dibujos y cálculos hechos para dar idea de lo que ha de ser y costar una obra de ingeniería o arquitectura. (fuente: Diccionario Léxico Hispano, W.M. JAckson, Inc. Editores)

Administración de proyectos de software

1. Planear: decidir qué se va a hacer
2. Organizar: hacer preparativos
3. Asignar personal: elegir personas adecuadas
4. Dirigir: dar órdenes
5. Monitorear: observar el progreso
6. Controlar: emprender acciones para corregir problemas de funcionamiento
7. Innovar: proponer soluciones novedosas
8. Representar: conectar con clientes y usuarios

Tema 2 - El ciclo de vida de un proyecto de T.I.

Definición: El ciclo de vida del desarrollo Software (SDLC en sus siglas inglesas, Software Development Life Cycle), es una secuencia estructurada y bien definida de las etapas en Ingeniería de software para desarrollar el producto sofware deseado.

Actividades del SDLC
El SDLC aporta una serie de pasos a seguir con la finalidad de diseñar y desarrollar un producto software de manera eficiente. El borrador del SDLC incluye los pasos que veremos a continuación:

• Comunicación
• Requisitos del sistema
• Estudio de factibilidad
• Análisis del sistema
• Diseño de software
• Códigos
• Pruebas
• Integración
• Implementación
• Operaciones y mantenimiento
• Disposición

Modelo de proceso de vida
Marco de referencia que contiene los Marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso (norma ISO 12207-1) [ISO/IEC, 1995]

Procesos del ciclo de vida Norma ISO 12207-1 [ISO/IEC, 1995]
Procesos principales

• Adquisición
• Suministro
• Desarrollo
• Explotación
• Mantenimiento

Procesos de soporte

• Documentación
• Gestión de la configuración
• Aseguramiento de la calidad
• Verificación
• Validación
• Revisión conjunta
• Auditoría
• Resolución de problemas

Procesos de la organización (generales)

• Gestión
• Mejora
• Infraestructura
• Formación

Nuevos procesos

• Usabilidad
• Evaluación de productos
• Recursos Humanos
• Gestión de "assets"
• Gestión de petición de cambios
• Gestión del programa de reutilización
• Ingeniería del dominio

Procesos del ciclo de vida del sistema Norma ISO/IEC 12207:2008 [ISO/IEC, 2008]

• Procesos de acuerdo (agreement): Adquisición, suministro
• Procesos de organización del proyecto: Gestión del modelo de ciclo de vida, gestión de la infraestructura, gestión del portafolio del proyecto, gestión de recursos humanos, gestión de la calidad
• Procesos del proyecto: Planificación del proyecto, control y evaluación del proyecto, gestión de las decisiones, gestión de riesgos, gestión de la configuración, gestión de la información, medición
• Procesos técnicos: Definción de requisitos de los stakeholders, análisis de requisitos del sistema, diseño arquitectónico del sistema

Procesos específicos del software Norma ISO/IEC 12207:2008 [ISO/IEC, 2008]

• Procesos de implementación del software: análisis de requisitos, diseño arquitectónico, diseño detallado, construcción, integración, prueba
• Procesos de soporte del software: Gestión de la documentación, gestión de la configuración, aseguramiento de la calidad, verificación, validación, revisión conjunta, auditoría, resolución de problemas
• Procesos de reutilización del software: ingeniería del dominio, gestión de assets, gestión del programa de reutilización

Tema 3 - Proceso de administración de proyectos de TI.

What is a Software Process Model?
A (software/system) process model is a description of the sequence of activities carried out in an SE project, and the relative order of these activities.
El Paradigma de desarrollo de Software ayuda al desarrollador a escoger una estrategia para desarrollar el software. El paradigma de desarrollo software tiene su propio set de herramientas, métodos y procedimientos, los cuales son expresados de forma clara, y define el ciclo de vida del desarrollo del software. Algunos paradigmas de desarrollo de software o modelos de proceso de software.
Los modelos de proceso proporcionan un marco genérico fijo que se puede adaptar a un proyecto específico. Los parámetros específicos del proyecto incluirán:

• Tamaño (persona-años)
• Presupuesto
• Duración

Parámetros del proyecto
Los parámetros del proyecto describen todo el proyecto, pero al menos debemos describir:

• recursos necesitados (gente, dinero, equipo, etc.)
• dependencia y tiempo de trabajo (diagrama de flujo, paquetes de trabajo)
• Tasa de entrega (informes, código, etc)

Clasificación de los modelos de proceso de software

1. Modelos tradicionales: formados por un conjunto de fases o actividades en las que no tienen en cuenta la naturaleza evolutiva del software:
   • Clásico, lineal o en cascada
   • Estructurado
   • Basado en prototipos
   • Desarrollo rápido de aplicaciones (RAD)
2. Modelos evolutivos: Son modelos que se adaptan a la evolución que sufren los requisitos del sistema en función del tiempo:
   • En espiral
   • Evolutivo
   • Incremental
   • Modelo de desarrollo concurrente
3. Modelos orientados a la reutilización
   • Basado en componentes
   • Proceso Unificado
4. Modelos para sistemas orientados a objetos: modelos con un alto grado de iteratividad y solapamiento entre fases
   • De agrupamiento
   • Fuente
   • Basado en componentes
   • Proceso Unificado
5. Procesos ágiles
   • Programación extrema (XP)
   • Desarrollo de software adaptativo
   • Scrum
   • Crystal
6. Modelos para sistemas web
   • UML-based Web Engineering

Tema 1 - Plan de desarrollo del proyecto

Este es un artefacto global y compuesto que recopila toda la información necesaria para gestionar el proyecto. Incluye una serie de artefactos desarrollados durante la fase inicial y se mantiene a lo largo del proyecto.
El objetivo del plan de desarrollo de software es recopilar toda la información necesaria para controlar el proyecto. Describe el enfoque del desarrollo del software, y es el plan de nivel superior generado y utilizado por los gestores para dirigir el esfuerzo de desarrollo. Las personas siguientes utilizan el plan de desarrollo de software:

• El gestor de proyectos, para planear la planificación de proyectos y las necesidades de recursos, y para supervisarlo contra la planificación.
• Los miembros del equipo del proyecto, para comprender qué deben hacer, cuándo deben hacerlo y de qué otras actividades dependen.

Objetivo del proyecto: El objetivo es la meta hacia donde vamos al hacer nuestro trabajo. Por ejemplo, nuestro objetivo puede ser un resultados, una posición estratégica, un producto o servicio, etc.

Alcance del proyecto: el alcance de un proyecto engloba todo lo que necesitamos hacer para llegar a esa meta, para obtener ese resultado, esa posición o ese producto o servicio. Incluyendo también funciones y características especiales de cada proyecto. ¿Qué hay que hacer para llegar al objetivo? Lo resumimos en el alcance de un proyecto. En nuestra empresa, cada proyecto debe ir sujeto a la definición de un alcance de proyecto. A continuación, vamos a ver cómo definir el alcance un proyecto, qué pasos hay que seguir y qué necesitamos para poner en marcha nuestros proyectos de empresa.

Plan de gestión del alcance del proyecto:

• Determinar los objetivos del proyecto. ¿Por qué hacemos el proyecto? ¿Qué queremos conseguir al finalizarlo?
• Metas concretas para alcanzar esos objetivos.
• Las fases que necesitamos para ir alcanzando esas metas.
• Identificar las actividades que necesitamos en cada fase.
• Relacionar las actividades en nuestra planificación, creando dependencias entre ellas. Por ejemplo, no podemos empezar una actividad hasta que no termine otra. Existe herramientas fáciles de usar, como Kanban, que nos permiten planificar en un calendario estas actividades, relacionarla y saber qué ruta de trabajo dentro de nuestro proyecto tenemos que hacer antes o después.

Recursos de apoyo para la elaboración de un plan de desarrollo de software

• Ejemplo1: Da clic aquí para descargarlo
• Ejemplo2: Da clic aquí para decargarlo
• Ejemplo3: Da clic aquí para descargarlo

Tema 2 - Personas involucradas en el proyecto de software

INDICACIONES: Realiza una investigación de los siguientes puestos en el área de TI y en un power point describe cada uno de ellos, sus habilidades y la experiencia que debe tener.

• Analista de inteligencia empresarial
• Científico de datos
• Desarrollador
• Técnico de soporte
• Administrador de red
• Administrador de seguridad de datos
• Administrador de sistemas
• Desarrollador: Backend, Frontend, Full-stack
• Arquitecto: de soluciones, de software, de sistemas, empresarial, SOA

INDICACIONES: Realiza una investigación de los siguientes perfiles y funciones en proyectos de TI y en un power point describe cada uno de ellos, sus habilidades y la experiencia que debe tener.

• Gerente de proyectos
• Líder de proyecto
• Analista de sistemas
• Diseñador
• Ingeniero de software
• Responsable de calidad
• Responsable de pruebas
• Administrador de la configuración del proyecto
• Cliente

Kanban

RUP

Proceso Unificado Racional - Rational Unified Process

Proceso de desarrollo de software
Un proceso en forma general es un conjunto de actividades ordenadas en las que se define:

• Responsabilidad de quién realizará las actividades
• Tiempos en los que se realizarán las actividades
• Formas de ralizar las actividades

Con el fin de alcanzar un determinado objetivo, los procesos de desarrollo además deben de ayudar a la administración del proyecto, obtención de recursos, medición del progreso y reducción de riesgos. En el caso del RUP, el objetivo será el de desarrollar software que sea predecible, repetible y medible.

Evolución del RUP
El RUP es el resultado de más de 3 décadas de conocimiento unificado:

Definición

Es un proceso de negocios genérico para la ingeniería de software orientada a objetos. Describe una familia de procesos de ingeniería de software relacionados, que comparten una estructura y arquitectura común de procesos. El RUP provee un método disciplinado para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su meta es asegurar la producción de software de alta calidad, que conozca las necesidades de los usuarios, dentro de un calendario y presupuesto predecible.

Características

• Se maneja con procesos iterativos e incrementales guiados por casos de uso
• Se centra en la arquitectura
• Implementa las mejores prácticas de ingeniería de software
• Utiliza UML como lenguaje para capturar conocimiento (semántica) acerca de una materia (en este caso un sistema) y que además tiene la capacidad de comunicarlo a quien conozca su sintaxis.

UML en RUP
UML aporta el modelado y el transporte del conocimiento a los distintos equipos de trabajo y el RUP el proceso o la logística para el desarrollo, entre los modelos mas importantes que aporta el UML están: el modelo de casos de uso, el modelo de análisis, el modelo de diseño y el modelo de distribución.

UML

Unified Modeling Language (Lenguaje Unificado de Modelado) es un lenguaje de modelado, un lenguaje visual en el que se trabaja con cajas, flechas y diagramas. Afianza las claves y conceptos más usados en la programación orientada a objetos. Permite poder representar las ideas de cómo se debe estructurar los programas de una forma más visual. UML ayuda a:

• Para poder explicar mejor las ideas
• Para plasmar ideas sin necesidad de desarrollarla totalmente
• Para una vez hecho el diseño, se puede trabajar sobre la misma

Evolución de UML

Diagramas UML

Requerimientos funcionales y no funcionales

• Requerimientos funcionales: Especifican acciones que un sistema debe ser capaz de realizar, sin considerar restricciones físicas (estéticas, documentación, tolerancia a fallos, velocidad, etc.)
• Requerimientos no funcionales: La mayoría de los requerimientos que están en este tipo tienen que ver con: Usabilidad, Fiabilidad, Desempeño y Soportabilidad (escalabilidad, mantenibilidad, configurabilidad e instalabilidad)

Un proceso centrado en la arquitectura
El RUP define la arquitectura como: la organización o la estructura de los componentes importantes de un sistema interactuando mediante interfaces. Entiendase por un componente el diagrama de clases, cliente, usuario, el modelo de casos de uso, etc. La arquitectura en el RUP se representa por medio de lo que se llama vistas arquitectónicas.

Modelo 4+1 vistas de Kruchten
El modelo “4+1” de Kruchten, es un modelo de vistas diseñado por el profesor Philippe Kruchten y que encaja con el estándar “IEEE 1471-2000” (Recommended Practice for Architecture Description of Software-Intensive Systems) que se utiliza para describir la arquitectura de un sistema software intensivo basado en el uso de múltiples puntos de vista.

Si un arquitecto nos muestra un plano de una casa (como la de la siguiente imagen), nos esta mostrando una vista de la casa y como no tenemos ni idea de arquitectura, cuando nos explique o nos de un documento en el que explique que un determinado símbolo del plano representa a una puerta u otro símbolo representa una mesa, nos estará dado un punto de vista para que podamos entender el plano de la casa. Si mas tarde nos mostrase otro plano (o maqueta) de la casa, nos estaría dando otra vista de la casa y nos tendrá que explicar el nuevo punto de vista, es decir, que nos tendrá que explicar que significa cada símbolo u objeto de esa nueva vista.

Pues sí, lo que propone Kruchten es que un sistema software se ha de documentar y mostrar (tal y como se propone en el estándar IEEE 1471-2000) con 4 vistas bien diferenciadas y estas 4 vistas se han de relacionar entre sí con una vista más, que es la denominada vista “+1”. Estas 4 vista las denominó Kruchten como: vista lógica, vista de procesos, vista de despliegue y vista física y la vista “+1” que tiene la función de relacionar las 4 vistas citadas, la denominó vista de escenario.

Cada una de estas vistas ha de mostrar toda la arquitectura del sistema software que se esté documentando, pero cada una de ellas ha de documentarse de forma diferente y ha de mostrar aspectos diferentes del sistema software. A continuación, pasamos a explicar que información ha de haber en la documentación de cada una de estas vistas.

Proceso iterativo e incremental
Consiste en la iteración de varios ciclos de vida en cascada. Al final de cada iteración se entrega una versión mejorada.

Fases del RUP

Diferencias entre UP y RUP
El Proceso Unificado es un nombre genérico para una familia de modelos de procesos que cumplen una serie de criterios, como ser iterativos e incrementales, impulsados por casos de uso y enfocados en abordar los riesgos de manera temprana. Define cuatro fases del proyecto: Inicio, Elaboración, Construcción y Transición.
El proceso unificado de racional es un refinamiento del proceso unificado que fue creado por Rational Software (ahora propiedad de IBM). Utiliza una serie de herramientas de software junto con un marco de proceso para definir cómo llevar a cabo las actividades necesarias para ejecutar un proyecto de software, pero aún así proporciona un marco para la adaptación para satisfacer las necesidades de una organización (o equipo).
Otras mejoras en el Proceso Unificado incluyen el Proceso Unificado Agile de Scott Ambler y el Proceso Unificado Abierto de la Fundación Eclipse .

Tema 1 - Trabajadores, actividades, y artefactos en las disciplinas

INDICACIONES: En el siguiente documento viene una lista resumen de los trabajadores, actividades y artefactos en las disciplinas del RUP. En tu cuaderno elabora un diagrama conceptual en donde describas el RUP con sus respectivas disciplinas y artefactos. Página 23, 24 y 25.
Da clic aquí para descargar el documento

Tema 2 - Calendarización de las actividades

INDICACIONES: En equipos, elabora un diagrama de Gantt utilizando los artefactos del tema 1 en donde asignes un tiempo correspondiente de 6 meses mínimo. Favor de incluir:

• Actividades
• Tiempos de ejecución
• Diagramas de ruta crítica

Recursos: En esta liga puedes encontrar más información sobre los diagramas de gantt

Tema 1 - Tipos de sistemas de información

Da clic aquí para conocer acerca de los tipos de sistemas de informacióon

Tema 2 - Cotización de un proyecto de software

Da clic aquí para conocer la guía básica para aprender a cotizar un proyecto de software

Herramientas para cotizar y administrar proyectos
INDICACIONES: En equipos seleccionen una de las siguientes herramientas para hacer una cotización o administrar proyectos. Preséntenla con sus compañeros y comenten en clase.

• Cosmonauta
• nuSchool - How much should I Charge?
• Pocketsuite
• Prospero
• SalesUp

INDICACIONES: En equipos elabora una cotización utilizando COCOMO II para una plataforma web de control escolar de los colegios benedictinos. Da clic aquí para descargar el software COCOMO II
Requisitos

• Se requiere una plataforma integral para los colegios benedictinos en donde se centralice la información de los procesos académicos y administrativos.
• Los colegios benedictinos son de nivel maternal, preescolar, primaria, secundaria y preparatoria.
• El personal académico y administrativo llevan el control diario de pago de colegiaturas, inscripciones, bajas, recursos humanos, contrato de docentes, nómina.
• Los profesores toman asistencia, organizan sus clases y registran sus planeaciones diarias.
• Los alumnos y padres de familia realizan pagos, checan calificaciones, tareas, reportes, etc.
• Debe estar disponible a cualquier dispositivo móvil
• La información debe estar respaldada
• Contar con soporte técnico las 24 horas

Tema 3 - Scrum

Scrum Manager
En la siguiente liga encontrarás información sobre scrum manager

INDICACIONES: Responde en tu cuaderno las siguientes preguntas sobre scrum:

1. ¿A qué nos referimos con agilidad en el entorno de desarrollo de las empresas?
2. ¿Cuáles son los 12 principios del manifiesto ágil?
3. Explica el origen del scrum:
4. ¿A qué nos referimos con scrum técnico y avanzado?
5. ¿Qué es y para qué sirve el marco teórico de scrum?
6. ¿Menciona y describe los puntos de la gestión de la evolución del proyecto?: 1) Revisión de las iteraciones 2) Desarrollo incremental 3) Autoorganización 4) Colaboración
7. ¿Por qué esta formado el scrum técnico y describe cada uno de ellos?: Roles, Artefactos y Eventos
8. Menciona los roles del scrum técnico
9. Menciona los artefactos del scrum técnico
10. Menciona los eventos del scrum técnico
11. Menciona las áreas de responsabilidad del scrum avanzado: de gerencia, de procesos y de producción:
12. Describe los conceptos de 1) desarrollo 2) trabajo 3) conocimiento:
13. Menciona la diferencia entre gestión predictiva y evolutiva:
14. Menciona cómo se utiliza el kanban en scrum:
15. ¿Qué son las historias de usuario en la ingeniería de requisitos ágil y ejemplifica un documento de historia de usuario?

Tema 4 - Aseguramiento de la calidad de software

La siguiente información es tomada de este recurso

Ámbito General

• ISO/IEC 80000: Sistema internacional de unidades. Guía de estilo para el uso de magnitudes físicas, unidades de medida y fórmulas que las involucran y símbolos.

Ámbito Project, programme and portafolio management

• ISO 21500: Guidance on project management.
• ISO 21503: Guidance on programme management.
• ISO 21504: Guidance on portafolio management.
• ISO 21505: Guidance on governance.
• ISO 21506: Vocabulary for project, programme and portafolio management.
• ISO 21508: Earned value management in project and programme management.
• ISO 21511: Work breakdown structures for project and programme management.

Ámbito Quality management systems

• ISO 9000: Fundamentals and vocabulary.
• ISO 9001: Requirements.
• ISO 9004: Managing for the sustained success of an organization. A quality management approach.
• ISO 10001: Customer satisfaction - Guidelines for codes of conduct for organizations.
• ISO 10002: Customer satisfaction - Guidelines for complaints handling in organziations.
• ISO 10003: Customer satisfaction - Guidelines for dispute resolution external to organizations.
• ISO 10004: Customer satisfaction - Guidelines for monitoring and meaasuring.
• ISO 10005: Guidelines for quality plans.
• ISO 10006: Guidelines for quality management in projects.
• ISO 10007: Guidelines for configuration management.
• ISO 10012: Measurement management systems - Requirements for measurement processes and measuring.
• ISO 10013: Guidelines for quality management system documentation.
• ISO 10014: Guidelines for managing the economics of quality.
• ISO 10015: Guidelines for training.
• ISO 10017: Guidance on statistical techniques for ISO 9001:2000
• ISO 19011: Guidelines for auditing management systems.

Ámbito Risk Management

• ISO/IEC Guide 73 - Vocabulary - Guidelines for use in standards
• ISO 31000 - Principales and guidelines
• IEC 31010 - Risk assessment techniques
• ISO/TR 31004 - Guidance for the implementation of ISO 31000

Verificar el año más reciente de emisión de las normas.

PMBOK
Es una guía para la Dirección de Proyectos del PMI. En él se describe a detalle todos los procesos necesarios para llevar acabo un proyecto de inicio a fin, el conocimiento y las prácticas descritas son aplicables a la mayoría de los proyectos, la mayor parte del tiempo, y existe una amplia aceptación sobre su valor y utilidad. El propósito general del PMBOK es proporcionar un léxico común dentro de la profesión de gestión de proyectos y la práctica para hablar y escribir sobre la gestión de proyectos.

ITIL
Information Technology Infrastructure Library (‘Biblioteca de Infraestructura de Tecnologías de Información’), frecuentemente abreviada ITIL, es un marco de trabajo de las mejores prácticas destinadas a facilitar la entrega de servicios de tecnologías de la información (TI) de alta calidad. ITIL resume un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para servir de guía para que abarque toda infraestructura, desarrollo y operaciones de TI.

IEEE 830
Objetivos: Ya conociendo lo que es un SRS (Especificación de Requisitos de Software) se debe establecer que función ubicada en el contexto de desarrollo de software por esto se plantea lo siguiente:

• Un cliente describa claramente lo que quiere
• Un proveedor entienda claramente lo que el cliente quiere
• Se establezcan bases para un contrato de desarrollo (o de compra-venta)
• Se reduzca el esfuerzo de análisis, diseño, y programación (evitando re-trabajos)

Actores: De los estándares este es uno de los que mayor importancia lleva ya que este es el que define que hará la herramienta de software o solución planteada.

• - Un cliente/usuario que vaya a definir requerimientos (características) de un software que necesite
• - Un desarrollador (interno/externo) que haga software “a la medida” mediante proyecto
• - Un desarrollador que haga software “de paquete” que se venda masivamente

Aseguramiento de la Calidad de Software ACS

Temas importantes:

• Definición de calidad de software
• FURPS+
• Surgimiento de SQA
• Definición de SQA
• SQA y SQC
• Tabla de las diferencias entre control de calidad y aseguramiento de la calidad.
• Funciones generales del SQA
• PPQA
• Metas del PPQA

Da clic aquí para descargar el documento de ACS

Documento para elaborar el examen
Da clic aquí para descargarlo