Analisis y diseño - Ingeneria de software - Nixon Ortiz

Vista previa del material en texto

UNIVERSIDAD TÉCNICA 
LUIS VARGAS TORRES 
CAMPUS 
ESMERALDAS 
 
 
 
UNIDAD ACADÉMICA 
INGENIERIA EN TECNOLOGIAS DE LA 
INFORMACIÓN 
 
 
TEMA: 
ANÁLISIS Y DISEÑO 
 
 
CURSO: 
5TO A TICS 
 
 
ESTUDIANTES: 
 
NIXON ORTIZ QUIÑONEZ 
 
 
PROFESOR: 
 
ING. BASTER ESTUPIÑAN 
 
 
 
ESMERALDAS, 2022
 
1. Objetivos. 
 
a. Objetivo General. 
Analizar y sintetizar los diferentes conceptos de análisis y diseño de software 
mediante el uso de parámetros descriptivos conceptuales. Todo esto para la 
concepción de una definición general de los mismos dentro del área de estudio 
en ingeniería de software. 
 
b. Objetivos Específicos. 
• Resumir los diferentes parámetros de diseño que estable la Norma 
IEEE830. 
• Analizar los principios de trazabilidad de requisitos, estudio de factibilidad, 
conceptos de diseño, abstracción y arquitectura. 
 
2. Resumen. 
2.1. Norma IEEE-830. 
 
Los diferentes tipos de estándares internacionales para el desarrollo del software dan 
apogeo a diferentes contextos de distribución de requerimientos y desarrollo. El estándar 
IEEE 830 es una normativa de desarrollo basada en la creación de diferentes 
requerimientos o normas que se debe aplicar al momento de construir o desarrollar 
software de manera técnica-profesional. 
 
2.1.1. ¿Qué es la norma IEEE 830, como funciona y para qué sirve? 
 
Según el Universidad del Instituto Colombiano de Estudios Superiores de Incolda, “El 
estándar IEEE 830-1998 para el SRS (en inglés) o ERS (Especificación de 
requerimientos de software) es un conjunto de recomendaciones para la especificación 
de los requerimiento o requisitos de software el cual tiene como producto final la 
documentación de los acuerdos entre el cliente y el grupo de desarrollo para así cumplir 
con la totalidad de exigencias estipuladas.” (Universidad ICESI, s.f.) 
 
Por lo cual dicha norma señala el comportamiento esperado al construir software, usando 
como guía los estatutos de la misma, todo esto para poder evaluar a futuro su 
funcionamiento y lograr el mejoramiento continuo de los servicios que este puede traer 
anexado dentro de su documentación y así mismo establece varios requisitos para el 
correcto desarrollo del software. 
 
Según la Universidad de Cantabria, “Los requisitos de un proyecto representan una 
comprensión entre el comprador y el distribuidor sobre materias contractuales que 
pertenecen a la producción de un programa y de esta forma no tienen que ser integrados 
en el SRS.” 
 
Éstos comúnmente integran los siguientes aspectos de acuerdo a diferentes 
puntos de vista, como son: 
• El Costo. 
• Los tiempos de la entrega. 
• Informando los procedimientos. 
• Los métodos de desarrollo de Software. 
• La convicción de Calidad. 
• La Aprobación y criterio de la comprobación. 
• Los procedimientos de aceptación. 
 
 
 
2.2. Trazabilidad de Requisitos 
 
Al hablar de trazabilidad de requisitos nos referimos a aquel camino a seguir para definir 
aquellos puntos críticos o aspectos a monitorear al momento de entablar un esquema 
que contenga los diferentes requisitos de nuestro software. 
 
De acuerdo a Gotel (1994), “La trazabilidad es la capacidad de describir y de seguir la 
vida de un requisito, tanto en dirección hacia adelante y hacia atrás, es decir, desde sus 
orígenes, a través de su desarrollo y especificación, a su despliegue y uso subsecuentes, 
y a través de períodos de refinamiento y de la iteración en curso en cualesquiera de 
estas fases”. 
 
Esto involucra que un requerimiento debería de ser rastreable a partir de que se define y 
a lo largo de todo el desarrollo del programa, lo que asegura una correcta gestión del 
cambio con el objetivo de evaluar el efecto en lo demás del sistema. 
 
Por consiguiente, el marco de desarrollo de software de la junta de Andalucía (s.f) afirma 
que, “La trazabilidad de requisitos es, por definición, la correspondencia entre cada 
requisito del software y/o uno o más requisitos del usuario, u otras fuentes (trazabilidad 
hacia atrás) o una o varias partes del diseño o la implementación (trazabilidad hacia 
adelante) “. Es por ello que se debe ser conscientes del valor de hacer el mantenimiento 
de la trazabilidad de manera sistemática y eficiente. 
 
 
2.3. Estudio de Factibilidad 
 
El análisis de factibilidad es la investigación que se desarrolla para decidir si nuestro 
sistema va a ser bueno o malo, y cuáles van a ser las tácticas que se tienen que 
desarrollar para que sea rentable. 
 
A lo largo del análisis de factibilidad se examina por qué y para qué se estima desarrollar 
el sistema. Dentro de esta se estable diferentes tipos de factibilidad, en este caso de uso 
común se implementa un desarrollo de estudio con una factibilidad de tipo técnica y 
económica del plan de la cual parte el desarrollo de requerimiento. 
 
Así mismo se establecen objetivos para determinar la viabilidad como pueden ser: 
 
• Reducción de errores y mayor precisión en los procesos. 
• Reducción de costos mediante la optimización o eliminación de los recursos no 
necesarios. 
• Integración de todas las áreas y subsistemas 
• Actualización y mejoramiento de los servicios a clientes o usuarios. 
• Hacer un plan de producción y comercialización. 
• Aceleración en la recopilación de los datos. 
• Reducción en el tiempo de procesamiento y ejecución de las tareas. 
• Automatización óptima de procedimientos manuales. 
• Disponibilidad de los recursos necesarios para llevar a cabo los objetivos 
señalados. 
• Saber si es posible producir con ganancias. 
• Conocer si la gente comprará el producto. 
2.4. Conceptos de diseño 
 
El diseño de Programa es un proceso que transforma los requisitos del cliente de una 
forma correcto, lo cual ayuda al programador a en la codificación y utilización del 
programa. 
 
Para evaluar los requisitos del cliente, un archivo SRS se crea como para codificar como 
para llevar a cabo, existe una necesidad de especificar de un modo más descriptivo los 
requisitos en términos de Programa. El resultado de este proceso podría ser utilizado de 
forma directa en la utilización de idiomas de programación. 
 
El diseño de Programa es el primer paso en el periodo de vida del diseño de programa, lo 
cual cambia la atención y trascendencia a partir de problema de dominio a solución de 
dominio. Aspira especificar cómo saciar los requisitos mencionados en el SRS. 
 
2.5. Abstracción 
 
La abstracción es la capacidad de reducir la información de un componente a la necesaria 
para manejarlo en un nivel de desarrollo 
 
Hay varios grados de abstracción, entre más grande sea el nivel de la misma se estima 
una solución general, entre menor sea su nivel se refiere a recursos de más grande 
especificidad. 
 
• Abstracción procedimental: Permite describir procesos omitiendo detalles 
específicos. 
• Abstracción de datos: Describe las características de un objeto. 
 
 
2.6. Arquitectura 
 
Esta representa la estructura general del software y la forma como interactúan sus 
componentes. En esta parte se describen las relaciones junto a la representación de sus 
elementos de mayor importancia para el software. 
 
Hay diferentes modelos de arquitectura de software, pero los más utilizados son: 
 
• Modelos estructurales 
• Modelos Dinámicos 
• Modelos funcionales 
• Modelos de marco de trabajo 
• Modelos funcionales 
 
3. Conclusión 
 
De acuerdo a la información presentada, los diferentes criterios enmarcan un orden 
normativo en cuanto a la construcción de software, este estándar liga el 
estructuramiento, requerimientos, documentación, requisitos y planificación en cuanto al 
modelo de desarrollo de software de forma profesional. Es un modelo adecuado para el 
uso correcto de implementación, desarrollo y documentación de sistemas o programas 
basados en la modelación de desarrollo de software. 
4. Recomendación. 
 
Como recomendación principal, se incita a leer detalladamente los estatutos 
fundamentales y los modelos de procesos de construcción de proyectosque nos emplea 
las diferentes normativas, como la IEEE830 o el modelo de análisis y diseño de software, 
todo esto para el eficaz análisis de los complementos de construcción del mismo y una 
correcta implementación en futuros proyectos. 
 
5. Bibliografía. 
 
• Conceptos básicos del diseño de software. (s. f.). Tutorialespoint. Recuperado 16 
de mayo de 2022, de 
https://www.tutorialspoint.com/es/software_engineering/software_design_basics.ht
m 
• Marco de desarrollo de software de la junta de Andalucía. (s. f.). Mantener la 
trazabilidad de los requisitos del sistema. Recuperado 16 de mayo de 2022, de 
https://www.juntadeandalucia.es/servicios/madeja/print/929 
• Medina, Dapozo, Ferraro, & Estayno. (s. f.). especificación y trazabilidad de 
requerimientos en el desarrollo de aplicaciones web. Universidad Tecnológica 
Nacional. Recuperado 16 de mayo de 2022, de 
https://repositorio.unne.edu.ar/bitstream/handle/123456789/1617/RIUNNE_AC_Fer
raro_MdelosA_.pdf?sequence=1&isAllowed=y#:~:text=La%20trazabilidad%20de%
20requerimientos%20se%20define%20como%20la%20habilidad%20para,proceso
%20de%20desarrollo%20de%20software. 
• Sandoval, M., Universidad Nacional, Escuela de Informática., & Costa, H. (s. f.). La 
trazabilidad en el proceso de requerimientos de software. Universidad Nacional, 
Escuela de Informática. Recuperado 16 de mayo de 2022, de 
https://www.iiis.org/cds2008/cd2008csc/cisci2008/paperspdf/c601uz.pdf 
• Silva, J. D. (2014, 26 marzo). Conceptos de diseño de software. Slideshare. 
Recuperado 16 de mayo de 2022, de 
https://es.slideshare.net/josefabiandiazs/conceptos-de-diseo-de-software 
• U. (2022, 16 mayo). Estudio de Factibilidad. 
http://ingenieriaabril.blogspot.com/2016/11/estudio-de-factibilidad.html. 
Recuperado 16 de mayo de 2022, de 
http://ingenieriaabril.blogspot.com/2016/11/estudio-de-factibilidad.html