Unidad I Software e Ing Software

ASIGNATURA:
GESTIÓN DE CALIDAD DE
SOFTWARE
Docente: Ing. MSc Samira Khazmou
Email: samira13@gmail.com
UNIDAD I
1
SOFTWARE E ING SOFTWARE
Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

UNIDAD I
 INTRODUCCIÓN
2  NOCIONES GENERALES
 INGENERIA DE SOFTWARE
 OBJETIVOS DE LA INGENERIA DEL SOFTWARE
 CICLO DEL SOFTWARE
 MODELO DE NEGOCIO
 CUÁL ES LA DIFERENCIA ENTRE INGENIERÍA DEL SOFTWARE E INGENIERÍA
DE SISTEMAS?
 HISTORIA DE LA INGENERIA DE SOFTWARE
 CRISIS, PROBLEMAS RELACIONADOS, CAUSAS
 PROCESOS, PROCEDIMIENTOS
 INGENERIA DE REQUERIMIENTOS
 CONCEPTOS BÁSICOS
 REQUERIMIENTOS FUNCIONALES
 REQUERIMIENTOS NO FUNCIONALES
 LAS 4 P DE LA INGENERIA DEL SOFTWARE
Unidad I: SOFTWARE E INGENIERÍA DE SOFTWARE.
3
La Ingeniería de Software es la rama de la ingeniería que estudia todo lo
relacionado con la informática o sistemas de computación, con una
orientación metódica, ordenada y cuantificable al incremento, ejecución y
conservación del software.
Ingeniería de software ¿qué es?

Es una especialidad que consiste en: SISTEMA TÉCNICA INSTRUMENTO
S S S
emplean en el desarrollo de los programas

informáticos.

Unidad I: SOFTWARE E INGENIERÍA DE SOFTWARE.
CICLO DEL 1-CONCEPCIÓN 3 - CONSTRUCCIÓN

4 ETAPAS
SOFTWARE
2- ELABORACIÓN 4- TRANSICIÓN
MODELO
1 CONCEPCIÓN  MODELO DE NEGOCIO ES LA REPRESENTACIÓN
DE
ABSTRACTA DE UNA EMPRESA
NEGOCIO
2. ELABORACIÓN Planificación del proyecto, características y apoya la arquitectura
3- CONSTRUCCIÓN  Elaboración del producto software
4 TRANSICIÓN  Entrega del producto terminado a los usuarios

¿Qué es la Ingeniería del software?
5
 Disciplina que se ocupa del desarrollo del software
 Se enfrenta al software como un producto de

ingeniería que requiere: planificación, análisis,
diseño, implementación, pruebas y mantenimiento.
 Trata de las teorías, métodos y herramientas que

los profesionales del desarrollo del software deben
utilizar.
6
Objetivos de la Ingeniería del software
 Mejorar la calidad del software
 Acortar los tiempos de desarrollo
 Aumentar la productividad
 Necesidad:
Incrementar la reutilización
del software

¿Cuál es la diferencia entre Ingeniería del
7
Software e Ingeniería de Sistemas?
 La Ingeniería de Sistemas tiene que ver con todos los
aspectos del desarrollo de sistemas basados en
computadoras: hardware, software e Ingeniería de
procesos.
 Ingeniería del Software es una parte de este

proceso

Historia de la ingeniería de software (cuento largooo)
8

El ascenso de la guerra fría: madurez de la computación y el nacimiento de la
ingeniería de software
9
En los años 60s, era notorio el avance del software comercial, que se estaban
desarrollando sistemas complejos (como el SAGE y en general por la industria
espacial), es en este contexto donde Margaret Hamilton acuñó el término
“ingeniería de software” y en el que la OTAN declaró que había una "crisis del
software".
De los años sesenta a la Años ochenta: la maduración

Programación proceso en
modular cascada
Ed Yourdon
acoplamiento y , Tom DeMarco
cohesión

Los años ochenta y más adelante:
10
la edad de oro
problemas de calidad del

software
Sistemas distribuidos
Globalización
PROGRAMACIÓN
ORIENTADO A
OBJETOS (OO)

 Nacerían entre otras:
11 • El modelo de vistas 4+1 por Philippe Kruchten
• El modelo espiral del desarrollo de software y muchos aportes a
la economia de desarrollar software por Barry Boehm
• Métricas de software por Capers Jones
• El modelo formal clean-room por Harlan Mills
• La programación literaria por Donald Knuth
• El modelo de madurez de capacidades (CMM) por Watts
Humphrey
• Modelos de component-based engineering

Los años noventa y el milenio:
la era de las disrupciones
12
BIG DATA
IA
METODOLOGÍAS
ÁGILES
Frameworks:
Bootstrap,
NUEVOS
JQuery, React,
SERVICIOS LENGUAJES
MongoDB
Javascript,
WEB
Python
DISPOSITIVO
S MOVILES
PLATAFORMAS
DISTRIBUIDAS
BOOM DE
INTERNET
HABÍA
LLEGADO AL
MUNDO DE LOS
NEGOCIOS
CRISIS DEL SOFTWARE
13
 Durante años se ha hablado de crisis en el desarrollo de software, y de su bajo

número de proyectos exitosos y del gasto millonario en esfuerzos de desarrollos que
no cumplen los requerimientos del negocio y que son desechados sin retribuir a
quienes hicieron la inversión.
 Los síntomas de la crisis son dolorosamente conocidos por los gerentes de software
y por todos los que viven la administración y operación de un área de sistemas.

PROBLEMAS RELACIONADOS A LA
14
CRISIS
 No son cubiertas las necesidades del negocio.
 Requerimientos mal definidos.
 Módulos que no se integran.
 Código difícil de mantener.
 Descubrimiento tardío de defectos
 Baja calidad del software.
 Usuarios finales insatisfechos.
 Bajo desempeño sobre altas cargas.
 Esfuerzo no coordinado del equipo.
 Problemas en el control de versiones y cambios.

15 CAUSAS DE LA CRISIS
 Es de conocimiento general que para eliminar los síntomas de una
enfermedad hay que tratar las causas que la originan.
 En la industria de software se han identificado las causas que ocasionan los

problemas más comunes para su desarrollo y un pequeño conjunto de
prácticas que, si se adoptan, solucionarán de raíz el problema, situando a la
industria en una mejor posición para desarrollar software de calidad.

PROCESOS Y PROCEDIMIENTOS
 16
PROCESOS DE SOFTWARE: Es un conjunto de actividades sucesivas y coordinadas que se realizan
con un fin determinado.
 En la informática los procesos de software se han transformado en un factor clave para el desarrollo de
aplicaciones, por la creciente complejidad que esta actividad presenta, porque se deben coordinar
esfuerzos creativos que, principalmente, dependen de las personas, organización y procedimientos
utilizados
 Lonchamp [1993]: establece un marco conceptual y terminológico para la ingeniería de procesos de
software. Allí un proceso es definido como: un conjunto de pasos del proceso parcialmente ordenado,
relacionado con un grupo de artefactos, recursos humanos y computarizados, estructuras
organizacionales y limitaciones, destinados a producir y mantener las prestaciones del software
solicitado.
 Conradiet [1994]: todos los elementos del mundo real envueltos en el desarrollo y mantención de un
producto (artefactos, herramientas de soporte para la producción, actividades, actores y procesos de
soporte). Está compuesto por un proceso de producción, un meta proceso y un proceso de soporte que
sirve a estos últimos dos (con notaciones y métodos de modelado de procesos, modelos de proceso y
herramientas de proceso).
 La norma ISO/IEC 12207 [1995], define un proceso como: un conjunto de actividades interrelacionadas,
que transforma entradas en salidas. Además, un proceso está compuesto de actividades, éstas son un
conjunto detallado de tareas y las tareas son acciones con entradas y salidas
 Un proceso de software efectivo habilita a la organización a incrementar su productividad
17 al desarrollar software:
• Permite estandarizar esfuerzos, promover reuso, repetición y consistencia entre proyectos.
• Provee la oportunidad de introducir mejores prácticas de la industria.
• Permite entender que las herramientas deben ser utilizadas para soportar un proceso.
• Establece la base para una mayor consistencia y mejoras futuras.
 Un proceso de software mejora los esfuerzos de mantenimiento y soporte:

• Define cómo manejar los cambios y liberaciones a sistemas de software existentes.
• Define cómo lograr la transición del software a la operación, y cómo ejecutar los esfuerzos
de operación y soporte.

18

19 ¿Qué es un REQUERIMIENTO?
Los requerimientos/requisitos de un sistema describen

los servicios que ha de ofrecer el sistema y las
restricciones asociadas a su funcionamiento.

INGENERÍA DE REQUERIMIENTOS
20 VERIFICAR
RECOPILA
ANALIZAR NECESIDADE
R
S
META DE LA ING DE REQUERIMIENTOS  es entregar una especificación de requerimientos de

software correcta y completa
 La ingeniería de requerimientos apunta a mejorar la forma en que comprendemos y definimos
sistemas de software complejos.
 Varias definiciones importantes:
Los Requerimientos fueron definidos por la IEEE como [IEEE90]:
Condición o capacidad requerida por el usuario para resolver un problema o alcanzar un objetivo
Según Zave:
Rama de la ingeniería del software que trata con el establecimiento de los objetivos, funciones y
restricciones de los sistemas software.
Según Boehm: es la disciplina para desarrollar una especificación completa, consistente y no ambigua,
la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se
describen las funciones que realizará el sistema.

21

22
REQUERIMIENTOS FUNCIONALES
23  Deben redactarse de tal forma que el lector pueda entender el
funcionamiento del sistema sin tener conocimientos técnicos
particulares de su funcionamiento.
 Pueden usarse diagramas o flujos de processos, Casos usos etc.
El resultado del levantamiento

TECNICAS DE de requisitos se documenta en
LEVANTAMIENT
el documento de
O DE
REQUISITOS requerimientos de software

¿Puede un software operar
24
sin los requerimientos
funcionales?
NOTA: A veces, también

es conveniente indicar lo
que indicar lo que NO
hará el sistema el sistema
Ejemplos de requerimientos funcionales de proceso o área de
negocio
25
 El sistema enviará un correo electrónico cuando se registre alguna de las siguientes transacciones: pedido de venta de
cliente, despacho de mercancía al cliente, emisión de factura a cliente y registro de pago de cliente.
 Se permitirá el registro de pedidos de compra con datos obligatorios incompletos, los cuales podrán completarse
posteriormente modificando el pedido. Antes de poder aprobarse los datos del pedido deben estar completos.
 Al aprobar un pedido, la solicitud pasará al siguiente paso del flujo de trabajo (workflow) de aprobación configurado en el
sistema.
 El sistema permitirá a los usuarios autorizados el ingresar planes y cronogramas
 El sistema permitirá aprobar, cambiar o actualizar planes y cronogramas
 El sistema permitirá el envío automatizado de cartas de entrega de órdenes directamente al almacén.
 A cada orden se le asignará un identificador único, que será utilizado para identificarla en todos los procesos subsecuentes
que se realicen sobre esta.
 Al ingresar ordenes de entrega, toda orden de entrega estará asociada a un pedido de venta.
 Los elementos de la solicitud de cotización serán los mismos de la requisición asociada, al igual que los de la orden de
compra. El sistema permitirá la emisión de solicitudes de cotización y órdenes de compra parciales.
 El software debe poder emitir los siguientes estados financieros: Balance general, Estado de ganancias y pérdidas, Estado de
flujos de efectivo. Además, debe poder emitir un listado de mayor general y mayor analítico.
 Los pedidos de compra que excedan los montos establecidos en el flujo de liberaciones de pedidos configurados deberán
pasar por las aprobaciones establecidas en dicho flujo de aprobación.
Ejemplos de requerimientos funcionales de interfaz
gráfica
26
 La solución validara automáticamente el cliente asociado a una orden con el sistema de
gestión de contactos.
 El campo de monto acepta únicamente valores numéricos con dos decimales.
 El campo fecha de transacción acepta únicamente fechas anteriores al día de hoy (día
actual).
 El campo nombre acepta caracteres alfabéticos únicamente.
 El campo dirección acepta caracteres alfabéticos, numéricos y especiales.
 El campo país consistirá en una lista de preselección. El país asociado a una dirección debe
ser previamente registrado en el sistema.
 El campo material de elemento de la pantalla de requisiciones de compra será una lista de
preselección, que mostrará únicamente los materiales registrados en el maestro de
materiales.
 El campo fecha contable acepta únicamente fechas que correspondan con periodos
contables que estén abiertos en el sistema.
 La pantalla de registro de pago puede imprimir los datos en pantalla a la impresora.
Ejemplos de requerimientos funcionales legales o
27 regulatorios
 El sistema controlará el acceso y lo permitirá solamente a

usuarios autorizados.
 Las hojas de cálculo aseguraran los datos usando firmas
electrónicas.
 El sistema permitirá elaborar y emitir el reporte regulatorio
XX, según los requerimientos establecidos en el
reglamento y ley aplicable.
 Los libros de venta y de compras serán emitidos en el
formato establecido por las autoridades tributarias de dicha
materia.
Ejemplos de requerimientos de seguridad
28
 El sistema controlará el acceso y lo permitirá solamente a usuarios
autorizados. Los usuarios deben ingresar al sistema con un nombre de
usuario y contraseña.
 El sistema enviará una alerta al administrador del sistema cuando ocurra
alguno de los siguientes eventos: Registro de nueva cuenta, ingreso al
sistema por parte del cliente, 2 o más intentos fallidos en el ingreso de
la contraseña de usuario y cambio de contraseña de usuario.
 Los integrantes del grupo de usuarios de analistas pueden ingresar
solicitudes, pero no pueden aprobarlas o borrarlas.
 Los integrantes del grupo de usuarios de gerentes pueden ingresar y
aprobar solicitudes, pero no pueden borrarlas.

29 Ejemplos de requerimientos de interfaces
externas
(Hardware y Software)
 El software podrá ser utilizado en los sistemas operativos

Windows, Linux y MAC
 La aplicación debe poder utilizarse sin necesidad de instalar
ningún software adicional además de un navegador web.
 La aplicación debe poder utilizarse con los navegadores web
Chrome, Firefox e Internet Explorer.

Piensa en algunos requerimientos y
30
clasifícalos de proyectos realizados

REQUERIMIENTOS NO FUNCIONALES
31  Son los que especifican criterios para evaluar la operación de un servicio de
tecnología de información
Se detalla en la ARQUITECTURA DEL SISTEMA, mientras

que en los Requerimientos FUNCIONALES SE ESPECIFICA
EL DISEÑO
Categorías en las que pueden clasificarse:

1. Cualidades observables en tiempo de ejecución, como por
ejemplo la usabilidad y la seguridad.
2. Cualidades relacionadas con la evolución del sistema, como por

ejemplo Mantenibilidad, Comprobabilidad, Extensibilidad y
Escalabilidad
EJEMPLOS DE REQUERIMIENTOS NO FUNCIONALES
32 Eficiencia
 El sistema debe ser capaz de operar adecuadamente con hasta 100.000
usuarios con sesiones concurrentes.
 Los datos modificados en la base de datos deben ser actualizados para todos los
usuarios que acceden en menos de 2 segundos
Seguridad lógica y de datos

 Los permisos de acceso al sistema podrán ser cambiados solamente por el
administrador de acceso a datos
 Todos los sistemas deben respaldarse cada 24 horas. Los respaldos deben ser
almacenados en una localidad segura ubicada en un edificio distinto al que reside
el sistema.

EJEMPLOS DE REQUERIMIENTOS NO FUNCIONALES
33 Usabilidad
 El sistema debe proporcionar mensajes de error que sean informativos y orientados a
usuario final.
 El sistema debe contar con un módulo de ayuda en línea.
 La aplicación web debe poseer un diseño “Responsive” a fin de garantizar la adecuada
visualización en múltiples computadores personales, dispositivos tableta y teléfonos
inteligentes.
Requerimientos de producto
• La aplicación debe ser compatible con todas las versiones de Windows, desde
Windows 2000.
• La aplicación deberá consumir menos de 500 Mb de memoria RAM.
• La aplicación no podrá ocupar más de 2 GB de espacio en disco.
• La nueva aplicación debe manejar fuentes del alfabeto en Inglés, Idiomas latinos
(Español, Frances, Portugués, Italiano), Arábico y Chino.
34 Los requisitos
funcionales definen
qué debe hacer un
sistema.
Los requisitos no
funcionales definen
cómo debe ser el
sistema.
Especificación de requerimientos en lenguaje
35 natural
 MAL
 Para facilitar el uso del editor gráfico, se podrá activar
y desactivar una rejilla que permitirá alinear las figuras
del diagrama. Cuando se ajuste la figura al tamaño de
la pantalla, se reducirá el número de líneas de la rejilla
la pantalla.
 ¿Por qué?
Amalgama de varios requisitos.

BIEN
36
El editor permitirá el uso de una rejilla de líneas
horizontales y verticales que aparecerán dibujadas tras el
diagrama.
Justificación: La rejilla facilita la creación de diagramas,
cuidados en los que las figuras se puedan alinear con
facilidad.
¿Por qué?
Preciso, conciso y justificado correctamente.
MAL
37  El sistema será lo más fácil de utilizar posible.
 El sistema proporcionará una respuesta
 El sistema se recuperará automáticamente tras
producirse un fallo.
¿Por qué?
Objetivos generales, vagos y abiertos a distintas
interpretaciones.

38
LAS 4 P,
DE LA INGENERÍA DE
SOFTWARE
Personas Encargadas de llevar a cabo el producto mediante los
procesos del proyecto.
• Arquitectos
• Desarrolladores
• Ingenieros de prueba
• Personal de gestión
39
Proyecto Elemento organizativo a través del cual se
gestiona el desarrollo del software
40

Producto Artefactos que se crean en la vida del proyectos
41

42
Proceso
Conjunto completo de
actividades que se realizan
para convertir las peticiones
del usuario en el producto

43 Fuentes:
 https://micarrerauniversitaria.com/c-ingenieria/ingenieria-de-software/
 https://sg.com.mx/revista/1/procesos-software
 https://sites.google.com/site/jonathanmorenonunez/ing-de-requerimientos-1
 http://www.pmoinformatica.com/2017/02/requerimientos-funcionales-ejemplos.html
 https://monivela.wordpress.com/las-4-p-de-la-gestion-de-proyectos/
 https://our-academy.org/posts/software-engineering-history

44
¿PREGUNTAS? ¿DUDAS?
¿OBSERVACIONES?

Unidad I Software e Ing Software

Cargado por

Información del documento

Título original

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

Unidad I Software e Ing Software

Cargado por

Copyright:

Formatos disponibles

ASIGNATURA:

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

Ingeniería de software ¿qué es?

emplean en el desarrollo de los programas

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

CICLO DEL 1-CONCEPCIÓN 3 - CONSTRUCCIÓN

2. ELABORACIÓN Planificación del proyecto, características y apoya la arquitectura

3- CONSTRUCCIÓN  Elaboración del producto software

4 TRANSICIÓN  Entrega del producto terminado a los usuarios

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

 Se enfrenta al software como un producto de

 Trata de las teorías, métodos y herramientas que

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

 Ingeniería del Software es una parte de este

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

De los años sesenta a la Años ochenta: la maduración

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

problemas de calidad del

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

 Durante años se ha hablado de crisis en el desarrollo de software, y de su bajo

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

 Requerimientos mal definidos.

 Módulos que no se integran.

 Código difícil de mantener.

 Descubrimiento tardío de defectos

 Baja calidad del software.

 Usuarios finales insatisfechos.

 Bajo desempeño sobre altas cargas.

 Esfuerzo no coordinado del equipo.

 Problemas en el control de versiones y cambios.

 En la industria de software se han identificado las causas que ocasionan los

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

 Un proceso de software mejora los esfuerzos de mantenimiento y soporte:

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

Los requerimientos/requisitos de un sistema describen

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

META DE LA ING DE REQUERIMIENTOS  es entregar una especificación de requerimientos de

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

El resultado del levantamiento

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

NOTA: A veces, también

 El sistema controlará el acceso y lo permitirá solamente a

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

 El software podrá ser utilizado en los sistemas operativos

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

Se detalla en la ARQUITECTURA DEL SISTEMA, mientras

Categorías en las que pueden clasificarse:

2. Cualidades relacionadas con la evolución del sistema, como por

Seguridad lógica y de datos

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

Universidad Central de Chile .Asignatura: Gestión de Calidad de Software

También podría gustarte