“2020, Año del Centenario Luctuoso de Venustiano Carranza, el Varón de Cuatrociénegas”

GUIA DE ESTUDIOS INGENIERIA DE SOFTWARE.

1. Que es la Especificación de Requisitos de Software ERS.
Es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de
uso que describe todas las interacciones que tendrán los usuarios con el software.
2. Características de la ERS definidas por el estándar IEEE 830-1998.
Completa, Consistente, Inequívoca, Correcta, Trazable, Priorizable, Modificable, Verificable.
3. Tipos de requisitos en las ERS.
Requisitos de Usuarios: Necesidades que los usuarios expresan verbalmente.
Requisitos del Sistema: Son los componentes que el sistema debe tener para realizar determinadas tareas.
Requisitos Funcionales: Servicios que el sistema debe proporcionar.
Requisitos no funcionales: Restricciones que afectaran al sistema.
4. Finalidad y propósito de la Norma IEEE830.
Su finalidad es la integración de los requerimientos del sistema desde la perspectiva del usuario, cliente y desarrollador.
El propósito principal es ayudarnos a elaborar un documento muy útil: el SRS (Especificación de Requerimientos de
Software). Es esencialmente una guía para redacción.
5. Para qué sirve la SRS “Solicitud de Requisitos de Sw”
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, Se tenga una base o referencia para validar o probar el software solicitado, Se facilite el traspaso
del software a otros clientes/usuarios, Se le puedan hacer mejoras (o innovaciones) a ese software.
6. Características de un buen SRS.
Correcto. No ambiguo. Completo. Consistente. Ordenado con base en importancia y/o estabilidad. Verificable.
Modificable. Rastreable.
Tipos de diagramas. Diagramas de casos de uso: Diagramas de clases: Diagramas de secuencia: Diagramas
de colaboración: Diagramas de estados: Otros diagramas: diagramas de actividad, diagramas de paquetes,
diagramas de arquitectura software, etc.
7. Preparación conjunta del ERS o SRS.
El desarrollo de un software solamente deberá iniciar cuando el cliente y el proveedor estén de acuerdo acerca de
lo que el software deberá hacer.
8. Evolución del SRS.
Un SRS puede necesitar cambios mientras el software está en etapas de diseño o de desarrollo. Los cambios pueden
estar motivados por: deficiencias, errores, omisiones o imprecisiones en el documento original.
9. Creación de prototipos y su utilidad.
Un prototipo es un pequeño programa parecido al software solicitado que sirve de ejemplo, muestra o modelo para
que el cliente vaya especificando sus requerimientos en forma progresiva junto con el desarrollador.
Su utilidad se da en: prever aspectos de la conducta del sistema, haciendo que el SRS sea más completo y preciso,
Que el cliente/usuario vea y describa más fácilmente las funcionalidades que desea, Reducir la cantidad de cambios
 “2020, Año del Centenario Luctuoso de Venustiano Carranza, el Varón de Cuatrociénegas”
durante las etapas de diseño o desarrollo, Un prototipo puede ayudar al usuario a definir detalles específicos de la
interfaz humana o de las funcionalidades que requiera, Puede facilitarle al desarrollador el diseño y la programación
del software.
10. Contenido y organización típicos de un SRS.
SECCIÓN 1: INTRODUCCIÓN: Debe incluir una descripción general del SRS, mostrando lo siguiente: Propósito del
documento, Alcance, Definiciones, acrónimos, y abreviaturas, Referencias, Descripción general del documento.
SECCIÓN 2: DESCRIPCIÓN GRAL. DEL SOFTWARE: Usualmente se incluyen estas 6 subsecciones: Perspectiva
del software, Funciones del software, Características del usuario, Restricciones, Suposiciones y dependencias,
Posposición de requerimientos.
11. El SRS da origen a otros documentos (por separado) relacionados con el ciclo de vida de un software.
Estimación de costos, Fechas de entrega, Reportes de avances, Métodos de desarrollo, Aseguramiento de la
calidad, Criterios de validación y verificación, Procedimientos de aceptación.
12. Trazabilidad de requisitos.
Es una herramienta fundamental para la gestión de requisitos. Es elemental para el control y como apoyo para la
toma de decisiones en el proyecto, se debe cuidar que su creación y uso sea lo más eficiente posible.
13. Descripción de procesos actuales.
Se apoya con la utilización de elementos gráficos, especialmente diagramas que pueden ser de mayor o menor
complejidad. Se aconseja partir por un “mapa general de procesos” que señale en forma gruesa los procesos más
importantes presentes en una determinada área de actividad y la asociación entre ellos.
14. Elementos necesarios en el levantamiento y descripción de procesos.
La clara identificación del proceso: Al cual deberá asignársele un nombre o denominación que permita identificarlo
(alfanumérica por ejemplo “P-3”).
La definición funcional: expresar en forma simple qué función central realiza o qué objetivo tiene el proceso que
se está describiendo.
Cuáles son sus límites: en el sentido de delimitarlo y poder diferenciarlo de otros procesos cercanos o relacionados;
para esto ayuda mucho el mapa de procesos.
Destinatarios del proceso: a quiénes está dirigido el proceso, quiénes son los que valoran los resultados del
proceso.
Cuáles son las expectativas, tanto de los destinatarios como de los gestores o responsables de dicho proceso.
Esto es definir las condiciones óptimas para este proceso, desde ambas perspectivas.
15. Diagrama.
Es un gráfico que puede ser simple o complejo, con pocos o muchos elementos, pero que sirve para simplificar la
comunicación y la información sobre un proceso o un sistema determinado.
16. UML.
Se trata de un estándar que se ha adoptado a nivel internacional por numerosos organismos y empresas para crear
esquemas, diagramas y documentación relativa a los desarrollos de software (programas informáticos).
17. Diagramas UML.
 “2020, Año del Centenario Luctuoso de Venustiano Carranza, el Varón de Cuatrociénegas”
Está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML
es un lenguaje, cuenta con reglas para combinar tales elementos.
18. Finalidad de los diagramas.
Es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo.
19. Estudio de factibilidad y sus tipos.
Es un instrumento que sirve para orientar la toma de decisiones en la evaluación de un proyecto y corresponde a la
última fase de la etapa pre-operativa o de formulación dentro del ciclo del proyecto.
- Factibilidad económica, técnica, operativa y financiera.
20. Análisis Costo – Beneficio.
Es una herramienta financiera que mide la relación entre los costos y beneficios asociados a un proyecto de inversión
con el fin de evaluar su rentabilidad, entendiéndose por proyecto de inversión no solo como la creación de un nuevo
negocio, sino también, como inversiones que se pueden hacer en un negocio en marcha tales como el desarrollo de
nuevo producto o la adquisición de nueva maquinaria.
21. Ejemplo para realizar la factibilidad y el costo beneficio de nuestro SW.
Supongamos que queremos determinar si nuestro software será rentable y para ello decidimos analizar la relación costo-
beneficio para los próximos 2 años. La proyección de nuestros ingresos al final de los 2 años es de $300 000, esperando una
tasa de rentabilidad del 12% anual (tomando como referencia la tasa ofrecida por otras inversiones).
Asimismo, pensamos invertir en el mismo periodo $260 000, considerando una tasa de interés del 20% anual (tomando como
referencia la tasa de interés bancario).
Hallando B/C:

B/C = VAI / VAC

B/C = (300000 / (1 + 0.12)2) / (260000 / (1 + 0.20)2)
B/C = 239158.16 / 180555.55
B/C = 1.32

Por lo tanto, como la relación costo-beneficio es mayor que 1, podemos afirmar que nuestra software seguirá siendo rentable
en los próximos 2 años. A modo de interpretación de los resultados, podemos decir que por cada peso que invertimos,
obtenemos 0.32 pesos.