CICLO 3

Ingenieria del
sofware
MinTIC - UIS
Yhary Estefania Arias
Indice

TEMARIO - CLASE 1

¿Qué es la ingenieria de software?

Ciclo de vida del software
Atributos de un buen software
Técnicas de desarrollo de software
Mitos del SW
INGENIERIA DEL SOFWARE

Sobre la gestión

Sobre el cliente
Sobre los desarrolladores
 1. ¿Qué es la
ingeniería del
software?
La ingeniería de software es una disciplina de la
ingeniería que se preocupa de todos los aspectos de la
producción del software.

Aplicación de métodos de la ingeniería a procesos de

desarrollo de software.

Diseño
Contrucción
Mantenimiento
Ciclo de vida Fase de
del software desarrollo
Es el proceso de desarrollo que a priori Analisis
podría parecer una tarea simple, consta de Diseño
una serie de pasos de obligado cumplimiento Implementación
que buscan garantizar que los programas Testeo
creados son eficientes, fiables, seguros y
responden a las necesidades de los usuarios
finales.
Requerimientos Requerimientos
funcionales NO funcionales
Requerimientos
funcionales
Los requerimientos funcionales de un sistema, son aquellos que describen
cualquier actividad que este deba realizar, en otras palabras, el
comportamiento o función particular de un sistema o software cuando se
cumplen ciertas condiciones.

Por lo general, estos deben incluir funciones desempeñadas por pantallas

específicas, descripciones de los flujos de trabajo a ser desempeñados por el
sistema y otros requerimientos de negocio, cumplimiento, seguridad u otra
índole.
¿Cómo se describen y clasifican los
requerimientos funcionales?

Los requisitos funcionales de un software se suelen registran en la matriz de

trazabilidad de requerimientos y en la especificación de requerimientos de
software, este último, documenta las operaciones y actividades que el sistema
debe poder desempeñar.
Entre los posibles requerimientos funcionales de un
sistema, se incluyen:
Descripciones de los datos a ser ingresados en el sistema.
Descripciones de las operaciones a ser realizadas por cada pantalla.
Descripción de los flujos de trabajo realizados por el sistema.
Descripción de los reportes del sistema y otras salidas.
Definición de quien puede ingresar datos en el sistema.
Como el sistema cumplirá los reglamentos y regulaciones de sector o
generales que le sean aplicables.
Ejemplos de requerimientos funcionales
de proceso o área de negocio
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 de
proyecto.
El sistema permitirá aprobar, cambiar o actualizar planes y cronogramas de proyecto.
Requerimientos
funcionales
Los requerimientos no funcionales representan características generales y
restricciones de la aplicación o sistema que se esté desarrollando.

Suelen presentar dificultades en su definición dado que su conformidad o no

conformidad podría ser sujeto de libre interpretación, por lo cual es
recomendable acompañar su definición con criterios de aceptación que se
puedan medir.
Requerimientos no
funcionales
Los requerimientos no funcionales pueden clasificarse en requerimientos de producto, organizacionales y
externos

Los requerimientos de producto pueden clasificarse en requerimientos de usabilidad, eficiencia,

dependibilidad y seguridad. A su vez, los requerimientos organizacionales pueden clasificarse en
requerimientos de entorno, organizacionales y de desarrollo. Así mismo, los requerimientos externos pueden
clasificarse en requerimientos regulatorios, éticos y legislativos.

Cuando se realizan las fases de levantamiento y análisis de requerimientos, los requisitos no funcionales se
pueden registrar en un documento de requerimientos de software.
Ejemplos de requerimientos no
funcionales de producto

Eficiencia
El sistema debe ser capaz de procesar N transacciones por segundo. Esto se medirá por medio de la
herramienta SoapUI aplicada al Software Testing de servicios web.
Toda funcionalidad del sistema y transacción de negocio debe responder al usuario en menos de 5
segundos.
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 la
db.
El nuevo sistema debe desarrollarse aplicando patrones y recomendaciones de programación que
incrementen la seguridad de 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.
Todas las comunicaciones externas entre servidores de datos, aplicación y cliente del sistema deben
estar encriptadas.
Si se identifican ataques de seguridad o brecha del sistema, el mismo no continuará operando hasta ser
desbloqueado por un administrador de seguridad.
Usabilidad
El tiempo de aprendizaje del sistema por un usuario deberá ser menor a 4 horas.
La tasa de errores cometidos por el usuario deberá ser menor del 1% de las transacciones totales
ejecutadas en el sistema.
El sistema debe contar con manuales de usuario estructurados adecuadamente.
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.
El sistema debe poseer interfaces gráficas bien formadas.
Requerimientos no funcionales
organizacionales
El procedimiento de desarrollo de software a usar debe estar definido explícitamente (en manuales de
procedimientos) y debe cumplir con los estándares ISO 9000.
El sistema debe ser desarrollado utilizando las herramientas CASE.
Debe especificarse un plan de recuperación ante desastres para el sistema a ser desarrollado.
Cada dos semanas deberán producirse reportes gerenciales en los cuales se muestre el esfuerzo
invertido en cada uno de los componentes del nuevo sistema.
Las pruebas de software se gestionaran con una herramienta de gestión de software testing.
Requerimientos no funcionales
externos
Sistemas de datos médicos: El nuevo sistema y sus procedimientos de mantenimiento de datos deben
cumplir con las leyes y reglamentos de protección de datos médicos.
El nuevo sistema se acogerá a las reglas de las licencias generales públicas (GNU), es decir será
gratuito, código abierto en el que cualquiera podrá cambiar el software, sin patentes y sin garantías.
Las páginas web a ser desarrolladas deben cumplir con la ley de tratamiento en condiciones de
igualdad para personas con discapacidad.
El sistema no revelara a sus operadores otros datos personales de los clientes distintos a nombres y
números de referencia.
Actividad
Quiero vender música a través de Internet.
Los usuarios comprarán créditos para adquirir canciones.
Los usuarios buscarán las canciones que deseen y las pagarán con créditos.
Los usuarios tendrán algunos días para descargar en su ordenador las canciones que
hayan adquirido.
Quiero hacer ofertas generales (afectan a todos los usuarios) y particulares (afectan a
usuarios concretos).
¿Qué características debe tener este sistema para satisfacer las necesidades de nuestro
cliente?.
Tipos de
diagramas de la
Ingenieria del
software.
Lenguaje unificado de modelado
El lenguaje unificado de modelado (UML) es el lenguaje de modelado de sistemas de
software más conocido y utilizado en la actualidad; está respaldado por el Object
Management Group (OMG).

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para

describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos
en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que
está descrito el modelo.
Estructurales
Diagrama de clases

Los diagramas de clase son, sin duda, el tipo de diagrama UML más utilizado. Es el
bloque de construcción principal de cualquier solución orientada a objetos. Muestra las
clases en un sistema, atributos y operaciones de cada clase y la relación entre cada
clase. En la mayoría de las herramientas de modelado, una clase tiene tres partes,
nombre en la parte superior, atributos en el centro y operaciones o métodos en la parte
inferior. En sistemas grandes con muchas clases relacionadas, las clases se agrupan
para crear diagramas de clases. Las diferentes relaciones entre las clases se muestran
por diferentes tipos de flechas.
De comportamiento
Diagrama de actividades

Los diagramas de actividad representan los flujos de trabajo de forma gráfica. Pueden
utilizarse para describir el flujo de trabajo empresarial o el flujo de trabajo operativo
de cualquier componente de un sistema. A veces, los diagramas de actividad se utilizan
como una alternativa a los diagramas de máquina del estado.
 Diagrama de casos de uso

Como el tipo de diagrama UML más conocido, los diagramas de casos de uso ofrecen
una visión general de los actores involucrados en un sistema, las diferentes funciones
que necesitan esos actores y cómo interactúan estas diferentes funciones. Es un gran
punto de partida para cualquier discusión del proyecto, ya que se pueden identificar
fácilmente los principales actores involucrados y los principales procesos del sistema.
 Diagrama de máquina de estados

Los diagramas de máquina de estado son similares a los diagramas de actividad,

aunque las anotaciones y el uso cambian un poco. En algún momento se conocen como
diagramas de estados o diagramas de diagramas de estado también. Estos son muy
útiles para describir el comportamiento de los objetos que actúan de manera diferente
de acuerdo con el estado en que se encuentran en el momento.
 Diagrama de secuencia

Los diagramas de secuencia en UML muestran cómo los objetos interactúan entre sí y
el orden en que se producen esas interacciones. Es importante tener en cuenta que
muestran las interacciones para un escenario en particular. Los procesos se representan
verticalmente y las interacciones se muestran como flechas. Los diagramas de
secuencia de UML forman parte de un modelo UML y solo existen dentro de los
proyectos de modelado UML.
Roles en un proyecto de ingenieria del
software
 Cliente

El cliente, es en esencia, quien pone en marcha el proyecto, paga las cuentas, o define
el resultado final. Aun si no se tiene literalmente un “cliente”, es bueno entender que
aun así existe un rol “cliente” en su proyecto. Esto puede ayudar a evitar confusiones. Si
hay varias personas diciendo que características se necesitan, hay que asegurarse de
que exista algún responsable de tomar las decisiones cuando estos requisitos sean
contradictorios.
 Analista
El analista es alguien que es responsable de entender las necesidades del cliente, y
asegurarse de que la solución que está siendo desarrollada se ajusta a esas
necesidades.

¿Qué hace el analista?

Elicitación de requisitos
Reuniones con clientes
Redacción de especificaciones funcionales
 Arquitecto de Software
El papel del arquitecto de software es traducir los requisitos, tal como se define por el
analista, en una solución técnica. Él puede crear un diseño técnico, o simplemente algunos
bocetos a mano alzada, de cómo el sistema va a estar estructurado. En cualquier caso, es
la responsabilidad del arquitecto a pensar en el sistema antes de que se desarrolle. Si se
hace bien, durante la fase de diseño que se abordarán correctamente todos los problemas
que se enfrenten en el desarrollo de la solución.
 Desarrollador de Software
Un desarrollador tiene más responsabilidades que solo escribir código. Él es a menudo
responsable de hacer el seguimiento de su propio progreso, e informar al jefe de proyecto
de los problemas a los que se enfrenta. Él es también quien implementa las ideas del
arquitecto, y como tal, puede tener que discutir las (in)posibilidades de la implementación
con el arquitecto.
Una responsabilidad importante es documentar el código. Mientras que muchos
desarrolladores piensan que la documentación es algo que será realizado mejor por
alguien más, esta es en realidad una responsabilidad importante del desarrollador.
 Tester
Las pruebas son una parte importante para asegurar que el software funciona de la
manera que debería. El papel de ‘tester’ se realiza a menudo por los desarrolladores para
los aspectos técnicos y los usuarios para los aspectos funcionales. Un problema que surge
de hacer a los desarrolladores probar su propio código es que, no importa lo bueno que
sean, se ven influidos por la forma de su código fue creado. Cuando se prueba, se tendrá
en cuenta esas mismas situaciones que que ya se tuvieron en cuenta a la hora de escribirlo.
Gestión de proyectos agiles
SCRUM
Epic
Es un conjunto de trabajo grande que puede dividirse
en tareas específicas (denominadas “historias de
usuario”) en función de las necesidades o solicitudes
de los clientes o usuarios finales.
 Creación de un epic ágil
Cuando crees un epic, piensa en lo siguiente:
Creación de informes: crea epics para los proyectos que querrán tener controlados los
gerentes y ejecutivos.
Narración: usa epics y las historias que surgen en ellos como mecanismo para contar
cómo llegaste al estado actual de una función o un producto.
Cultura: deja que la cultura de la organización dicte el tamaño y el nivel de detalle de
un epic.
Tiempo: la mayoría de equipos de desarrollo dependen de marcos de estimación en
lugar del tiempo, pero merece la pena asegurarse de que los epics tendrán un par de
semanas de duración. Ni demasiado tiempo ni demasiado poco.
Feature
Se define como una pequeña función orientada al cliente. Por pequeño
se entiende que suele durar de 1 a 3 días de desarrollo.
Su objetivo, crear una planificación inicial y asignar responsabilidades.
 User Stories
son pequeñas descripciones de los requerimientos de un cliente. Su utilización es común
cuando se aplica marcos de entornos ágiles como Scrum. Al redactar las historias de
usuario se debe tener en cuenta describir el Rol, la funcionalidad y el resultado esperado
en una frase corta. Debe venir acompañada (al reverso) de los criterios de aceptación,
hasta un máximo de 4 por historia, redactado también en una frase que indique el
contexto, el evento y el comportamiento esperado ante ese evento.
 Una User Stories sigue el siguiente
formato

Como <quién> Quiero <qué> Para <objetivo>.

Ejemplo: Como Vendedor, quiero registrar los productos y cantidades que me solicita un
cliente para crear un pedido de venta.