El documento describe varios conceptos clave relacionados con el desarrollo de software, incluyendo la modularidad, la arquitectura de software, la jerarquía de control, las estructuras de datos, los procedimientos de software, y las técnicas para el análisis de requerimientos como la descomposición funcional, la especificación de texto, el modelado de procesos, el modelo de dominio, los casos de uso, las listas de verificación, la inspección y los prototipos. También discute conceptos como la calidad del software, las p
4. 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 fácilmente 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
Arquitectura de Software
La arquitectura del software se refiere a:
1. La estructura jerárquica de los
componentes procedimentales.
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
5. Usando alguna de las metodologías de diseño del software seproducirá
un determinado tipo de estructura del software.
6. 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. 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.
La estructura de datos dicta la organización, los métodos de acceso, y las
alternativas de procesamiento para la información.
8. El 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. El diseño orientado a objetos (DOO) es una fase de la metodología
orientada a objetos para el desarrollo de software. Su uso induce a
desarrolladores y programadores a pensar en términos de objetos,
en vez de procedimientos, cuando planifican el código. 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. 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).
10. Consiste en los medios de la supervisión tecnología de dotación
lógica los procesos y los métodos aseguraban calidad. Hace esto
por medio de intervenciones de sistema de gerencia de la calidad
debajo de cuál se crea el sistema de software. Estas
intervenciones son movidas hacia atrás por unos o más
estándares, generalmente ISO 9000. 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
11. Un enfoque de gestión de calidad .
Tecnología de Ingeniería de Software efectiva (métodos y
herramientas).
Revisiones técnicas formales que se aplican durante el proceso del
software.
Una estrategia de prueba multiescalada.
Un control de la documentación del software y de los cambios
realizados
Un procedimiento que asegure un ajuste a los estándares de
desarrollo de software.
Mecanismos de medición y de generación de informes.
12. La prueba del software es tanto un arte como una ciencia. En grande, los usos
complejos, tales como sistemas operativos. Diversos usos del software requieren
diversos acercamientos cuando viene a la prueba, pero algunas de las tareas mas
comunes del QA del software incluyen:
Prueba de Validación
Es el acto de los datos que
entran que el probador sabe
para ser erróneo en un uso.
Comparación de los Datos
Se compara la salida de un uso
con parámetros específicos a
un sistema previamente creado
de los datos con los mismos
parámetros que se saben para
ser exactos
13. Prueba de la Tensión
Es cuando el software se utiliza tan pesadamente como sea posible por
un período de la hora de considerar si hace frente a los altos niveles de
la carga.
Prueba de la Utilidad
Consiguiendo a los usuarios que
son desconocedores con el
software intentarlo durante algún
tiempo y ofrecer la regeneración a
los reveladores sobre lo que
encontraron difíciles de hacer es la
mejor manera de llevar a cabo
mejoras a un interfaz
14. Es la modificación de un producto de software después de la entrega,
para corregir errores, mejorar el
rendimiento, u otros atributos. El mantenimiento del software es una de
las actividades más comunes en la
ingeniería de software.
El mantenimiento de software es también una de las fases en el ciclo de
vida de desarrollo de sistemas (SDLC,
sigla en inglés de 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.
15. Descomposición funcional
Especificación vía Sentencias
Textuales
Modelado del proceso
Modelo de dominio
Casos de Uso
Checklists
Inspección
Prototipos
16. • 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.
• Por lo general, la descomposición funcional se realiza para identificar y
entender los componentes o partes
que constituyen un todo (o función global). En este proceso, es vital
identificar las interacciones entre
componentes.
• 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.
17. • 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
18. 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.
19. • 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.
20. 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.
21. 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:
• ¿Se han especificado los requisitos de hardware y software?
• ¿Se han realizado consideraciones de seguridad?
• ¿El nivel de granularidad del requerimiento se ha incluido?
• ¿Se ha incluido el código de referencia en para identificar el requisito en el
desglose de requerimientos?
• ¿Está escrito el requerimiento en un lenguaje claro y conciso?
• ¿El requerimiento es único? (no existe duplicidad con otro requerimiento).
Y muchas preguntas más.
La lista de chequeo sirve de marco de trabajo y procedimental para revisar
el requerimiento, facilitando su
análisis de forma estructurada.
Los requerimientos se pueden revisar sobre la matriz de trazabilidad de
requerimientos o sobre la definición del
alcance.
22. 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.
23. • Consiste en elaborar representaciones visuales (interfaz gráfica con el
usuario) de los requerimientos de
software.
• Es una herramienta muy útil para validar con los usuarios, clientes e
interesados de proyecto que el diseño
funcional corresponde con los requerimientos de software (Que existe
entendimiento común entre
desarrolladores de software y usuarios).
• 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
24. En el diseño de Software suelen tomarse en cuenta muchos factores, tales
como sus objetivos funcionales, los
parámetros a seguir y los recursos con los q se debe interactuar dentro del
entorno de desarrollo.
Esto tiene un impacto directo en el enfoque, estructura, utilidad y la
optimización que pueda llegar a tener, a
través de esto se realizan diversas pruebas para comprobar si el software
desarrollado cumple con los estándares
de calidad y garantía, a demás de establecer una conclusión mas firme y
saber si cumplirá con su objetivo de
manera optima o necesitaría mas complementes y desarrollo.
Dentro de las diversas pruebas de software, se aprecia que son utilizadas
de manera que los resultados sean
contundentes y claros, ya sea desde comprobar dato a dato hasta realizar
una prueba de estrés a todo en
conjunto para saber si podrá con la tensión exigida dentro del campo real
donde será aplicado como solución.
