-

1. República Bolivariana de Venezuela
Ministerio del Poder Popular para la Educación Superior
I.U.P.” Santiago Mariño”.
Sede Barcelona.
Bachiller:
Luisa Valentina Hurtado.
C.I: 23.997.291
Profesora:
Amelia Vásquez
Barcelona, 05 de Abril de 2018.
Software

2. Introducción
Se conoce como software al soporte lógico de un sistema informático, que comprende
el conjunto de los componentes lógicos necesarios que hacen posible la realización de
tareas específicas, en contraposición a los componentes físicos que son llamados
hardware. La interacción entre el Software y el Hardware hace operativa una
computadora (u otro dispositivo), es decir, el Software envía instrucciones que el
Hardware ejecuta, haciendo posible su funcionamiento.
Los componentes lógicos incluyen, entre muchos otros, las aplicaciones informáticas,
tales como el procesador de texto, que permite al usuario realizar todas las tareas
concernientes a la edición de textos; el llamado software de sistema, tal como el
sistema operativo, que básicamente permite al resto de los programas funcionar
adecuadamente, facilitando también la interacción entre los componentes físicos y el
resto de las aplicaciones, y proporcionando una interfaz con el usuario.

3. Diseño del Software
El diseño de software es la primera de tres actividades técnicas:
1. Diseño
2. Codificación
3. Prueba
Mediante alguna de las metodologías existentes para el diseño se realizan tres
tipos de diseño:
a) Diseño de Datos. Transforma el modelo del campo de la información en las
estructuras de datos que se van a requerir para implementar el software.
b) Diseño Arquitectónico. Define las relaciones entre los principales elementos
estructurales del programa.
c) Diseño Procedimental Transforma los elementos estructurales en una
descripción procedimental del software. d) Diseño de la Interfaz. Establece la
disposición y los mecanismos para la interacción Hombre-Máquina.

4. Fundamentos del Diseño del Software
Modularidad
 El software se divide en componentes con nombres determinados que se
denominan módulos.
 Un programa compuesto de un solo módulo no puede ser facilmente manejado
intelectualmente. Es más fácil resolver problemas complejos cuando se
descomponen en trozos más manejables.
 Puede concluirse que si partiéramos el software indefinidamente el esfuerzo
para desarrollarlo sería insignificantemente pequeño. Sin embargo existen otros
factores que hacen inválida esta conclusión. Debemos modularizar, pero
debemos evitar tanto una excesiva modulización como una pobre.

5. Fundamentos del Diseño del Software
Arquitectura del Software
La arquitectura del software se refiere a:
1.- La estructura jerárquica de los componentes procedimentales, y
2.- La estructura de los datos.
La arquitectura del software se obtiene mediante un proceso de partición, que
relaciona los elementos de una solución de software con partes de un problema del
mundo real definido en el análisis de requisitos.

6. Fundamentos del Diseño del Software
Jerarquía de Control
La jerarquía de control, también denominada “estructura del programa”, representa
la organización de los componentes del programa ( módulos ). Esto no representa
aspectos procedimentales del software, tales como la secuencia de procesos, la
ocurrencia u orden de las decisiones o la repetición de operaciones. Para
representar la jerarquía de control lo más común es usar un diagrama en forma de
árbol.

7. Fundamentos del Diseño del Software
Estructura de Datos.
La estructura de datos es una representación de la relación lógica existente entre
los elementos individuales de datos. Debido a que la estructura de la información
afectará invariablemente al diseño procedimental final, la estructura de datos es
tan importante como la estructura del programa en la representación de la
arquitectura del software.

8. Fundamentos del Diseño del Software
Procedimiento del software
Se centra sobre los detalles de procesamiento de cada módulo individual. El
procedimiento debe proporcionar una especificación precisa del procesamiento,
incluyendo la secuencia de procesos, las decisiones y la repetición de operaciones.
La representación procedimental del software se realiza por capas. .

9. Programación Orientada a Objetos

10. Diseño Orientado a Objetos
 Es una fase de la metodología orientada a objetos para el desarrollo de
software.
 El diseño orientado a objetos es la disciplina que define los objetos y sus
interacciones para resolver un problema de negocio que fue identificado y
documentado durante el análisis orientado a objetos (AOO).
 Su uso induce a desarrolladores y programadores a pensar en términos de
objetos, en vez de procedimientos, cuando planifican el código.

11. Diseño Orientado a Objetos
 Un objeto agrupa datos encapsulados y procedimientos para representar una
entidad. La "interfaz del objeto", esto es, las formas de interactuar con el objeto,
también se definen en esta etapa.
 Un programa orientado a objetos se caracteriza por la interacción de esos
objetos.

12. Garantía de calidad de software
Consiste en los medios de la supervisión tecnología de dotación lógica los
procesos y los métodos aseguraban calidad.
La calidad del software es el conjunto de cualidades que lo caracterizan y que
determinan su utilidad y existencia. La calidad es sinónimo de eficiencia,
flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad,
seguridad e integridad. La calidad del software es medible y varía de un sistema a
otro o de un programa a otro.
“La calidad del software es el grado con el que
un sistema, componente o proceso cumple los
requerimientos especificados y las
necesidades o expectativas del cliente o
usuario”.

13. Garantía de calidad de software
 El control de la calidad es una serie de revisiones, y pruebas utilizados
a los largo del ciclo de desarrollo para asegurar que cada producto
cumple con los requisitos que le han sido asignados.
 La garantía de calidad o aseguramiento de la calidad consiste en la
auditoria y las funciones de información de la gestión.
 El objetivo de la garantía de la calidad es proporcionar la gestión para
informar de los datos necesarios sobre la calidad del producto, por lo
que se va adquiriendo una visión más profunda y segura de que la
calidad del producto está cumpliendo sus objetivos.

14. Garantía de calidad de software
SQA (Software Quality Assurance)
Es un conjunto de actividades sistemáticas y planeadas para asegurar
que los procesos y productos de software cumplen con los
requerimientos, estándares y procedimientos.
Objetivos :
1. Planificar las actividades de aseguramiento de la calidad.
2. Revisar y auditar objetivamente los productos y las actividades para
verificar que estén conformes con los procedimientos y estándares.
3. Proporcionar los resultados de estas revisiones o auditorías
informando a la dirección.

15. Técnicas de pruebas de software
 Pruebas Estáticas
Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación.
Puede referirse a la revisión de documentos, ya que no se hace una ejecución de
código. Esto se debe a que se pueden realizar "pruebas de escritorio" con el
objetivo de seguir los flujos de la aplicación.
 Pruebas Dinámicas
Todas aquellas pruebas que para su ejecución requieren la ejecución de la
aplicación.
Las pruebas dinámicas permiten el uso de técnicas de caja negra y caja blanca
con mayor amplitud. Debido a la naturaleza dinámica de la ejecución de pruebas
es posible medir con mayor precisión el comportamiento de la aplicación
desarrollada.

16. Mantenimiento de software
Es una de las actividades en la Ingeniería de Software y es el proceso de mejorar y
optimizar el software desplegado (revisión del programa), así como también
remediar los defectos.
El mantenimiento de software es también una de las fases en el Ciclo de Vida de
Desarrollo de Sistemas (SDLC ó System Development Life Cycle), que se aplica al
desarrollo de software.
La fase de mantenimiento es la fase que viene después del despliegue
(implementación) del software en el campo.
La fase de mantenimiento de software involucra cambios al software en orden de
corregir defectos y dependencias encontradas durante su uso tanto como la
adición de nueva funcionalidad para mejorar la usabilidad y aplicabilidad del
software.

17. Tipos de Mantenimiento de software
 Perfectivo: Mejora del software (rendimiento , flexibilidad , reusabilidad ..) o
implementación de nuevos requisitos. También se conoce como mantenimiento
evolutivo .
 Adaptativo: Adaptación del software a cambios en su entorno tecnológico
(nuevo hardware, otro sistema de gestión de bases de datos , otro sistema
operativo ...)
 Correctivo: Corrección de fallos detectados durante la explotación.
 Preventivo: Facilitar el mantenimiento futuro del sistema (verificar
precondiciones, mejorar legibilidad...).

18. Métodos de análisis de requerimiento
Descomposición Funcional.
 La descomposición funcional se refiere al proceso de identificar y resolver las
relaciones funcionales en sus partes constituyentes, de tal forma que la función
global pueda ser reconstruida a partir de sus partes.
 Aplicado a la Ingeniería de requisitos, consiste en tomar los requerimientos de
software, dividirlos en partes y analizarlos individualmente. De ser necesario, se
pueden descomponer en más partes hasta lograr un nivel adecuado de detalle.
 En cierto sentido, el proceso es similar al de la elaboración de una estructura de
desglose de trabajo de un proyecto.
 En Ingeniería de sistemas, la descomposición funcional consiste en definir un
sistema en términos funcionales, para luego definir funciones de más bajo nivel
y establecer las relaciones con estas funciones de alto nivel.

19. Métodos de análisis de requerimiento
Especificación vía Sentencias Textuales
 Es la forma tradicional de la especificación de requerimientos de software.
 Se usan especificaciones textuales en lenguaje natural, que se documentan en
matrices de trazabilidad de requerimientos o definiciones del alcance.
 El procedimiento consiste en tomar el requerimiento producto del levantamiento
de información, para desarrollar una narrativa más detallada.
 No usa herramientas visuales como los flujogramas o estructura como los
casos de uso, es simplemente una descripción más detallada del requerimiento
en lenguaje natural.

20. Métodos de análisis de requerimiento
Modelado del proceso.
 Comprende la elaboración de diagramas de flujo de procesos (Flujogramas) a
partir de los requerimientos del software.
 Existen diversas herramientas de modelado de procesos, cada una de las
cuales posee sus propios símbolos y reglas.
 Es muy útil para entender el trabajo realizado en múltiples pasos, tareas, roles y
departamentos intervinientes.
 Los procesos son iniciados por eventos y pueden abarcar actividades
automatizadas, manuales o combinación entre ambas.
 Su naturaleza visual ayuda a la comprensión y comunicación a terceros.
 Cuando los procesos son complejos, deben desglosarse en componentes
(subprocesos).

21. Métodos de análisis de requerimiento
Modelo de dominio.
En Ingeniería de software, en análisis de dominio consiste en analizar sistemas o
software relacionados en un dominio, con la finalidad de encontrar sus partes
comunes y partes que los diferencian.
Produce un modelo de contexto de negocio para todo el sistema.
Un modelo de dominio comprende diagramas conceptuales que incluyen tanto el
comportamiento de un sistema como sus datos.
Un tipo de modelo de dominio son los diagramas de funcionalidades (Features
Diagrams), que es una representación “compacta” del sistema o aplicación en
términos de sus características.

22. Métodos de análisis de requerimiento
Casos de uso.
En el Lenguaje de Modelado Unificado (UML), un caso de uso es una secuencia de
interacciones entre un sistema y alguien o algo que usa alguno de sus servicios.

23. Métodos de análisis de requerimiento
Checklist.
La lista de chequeo (Checklist) consiste en una serie de preguntas o revisiones
que se realizan sobre los requerimientos de software, que nos sean presentados
de forma escrita.
Una lista de chequeo puede realizar preguntas como:
o ¿Se han especificado los requisitos de hardware y software?
o ¿Se han realizado consideraciones de seguridad?
o ¿El nivel de granularidad del requerimiento se ha incluido?
o ¿Se ha incluido el código de referencia en para identificar el requisito en el
desglose de requerimientos?
o ¿Está escrito el requerimiento en un lenguaje claro y conciso?
o ¿El requerimiento es único? (no existe duplicidad con otro requerimiento).
o Y muchas preguntas más.

24. Métodos de análisis de requerimiento
Inspección.
Revisión no destructiva de los requerimientos de software. Por ejemplo:
 Examinar un software visualmente para constatar que las pantallas solicitadas
se encuentran incluidas.
 Verificar la inclusión de los campos necesarios para el ingreso de datos.
 Verificar la existencia de los botones necesarios para iniciar la funcionalidad que
ha sido requerida.
 Verificar que el requerimiento se apega a los estándares definidos para la
aplicación. Por ejemplo estándares de navegación entre pantallas y estándares
de interfaz gráfica.
De forma similar al uso de la lista de chequeo, la inspección consiste en tomar el
requerimiento definido en la matriz de trazabilidad o definición de alcance, leerlo y
producir un resultado para su corrección.

25. Métodos de análisis de requerimiento
Prototipos.
Consiste en elaborar representaciones visuales (interfaz gráfica con el usuario) de
los requerimientos de software.
Permite a desarrolladores y usuarios entender mejor los requerimientos,
determinar cuáles son indispensables y cuales deseables, e identificar riesgos de
forma temprana.
 Puede enfocarse en toda la solución o sólo en áreas específicas.
 Puede extenderse innecesariamente en el tiempo si las discusiones se realizan
en torno al como en lugar de en torno al que.
La elaboración de prototipos conlleva iteraciones entre desarrolladores y usuarios,
en los cuales se van elaborando varios prototipos y sometidos a evaluación del
cliente.

26. Conclusión
El análisis global de los requisitos de una aplicación es un proceso de
conceptualización y formulación de los conceptos que involucra de forma
concreta. Es una parte fundamental del proceso de desarrollo de una
aplicación, la mayor parte de los defectos encontrados en el software entregado
se originan en la fase de análisis de requisitos, y además son los mas caros de
reparar.
Siempre se ha discutido quién es el dueño de los requisitos: el cliente o el
desarrollador.
Para gestionar esto, es habitual presentar el análisis de requisitos en dos
secciones:
•Requisitos de cliente: documentan los deseos y necesidades de los clientes y
se expresan en lenguaje claro para él.
•Requisitos detallados: Determina los requisitos de manera específica y
estructurada y están destinadas específicamente hacia los desarrolladores.

27. Bibliografía
https://es.wikipedia.org/wiki/Software.
http://www.itlalaguna.edu.mx/academico/carreras/sistemas/ingsofware1/unidad6.pd
f
https://es.wikipedia.org/wiki/Dise%C3%B1o_orientado_a_objetos
http://arielvargasu.blogspot.com/2010/10/garantia-de-calidad-de-software-
sqa_18.html
https://es.wikipedia.org/wiki/Pruebas_de_software#Pruebas_est%C3%A1ticas
http://www.sincows.com/sincows/index.php?option=com_content&view=article&id=
70&Itemid=68
http://www.pmoinformatica.com/2016/08/tecnicas-analisis-requerimientos.html