Entradas recientes
LIMITACIONES
Si comparamos una solución por software program a una solución dada por la mente humana, la limitación más evidente es que un software program no tiene inteligencia de por sí, es decir, sólo tiene funciones predefinidas que abarcan un conjunto de soluciones que para ciertas aplicaciones puede llegar a ser limitado.
Pese a que un software program no tiene inteligencia, ésta se puede emular. Es lo que se conoce como inteligencia artificial. Pero emular inteligencia es costoso en términos computacionales, ya que se necesita de una gran cantidad de memoria de trabajo. Por ello, muchos dicen que el cerebro humano tiene memoria infinita”.
Actualmente la inteligencia artificial puede emular redes neuronales y muchas cosas, pero aún así no puede emular el pensamento” humano, ya que el software program actúa bajo condiciones que, son completamente verdaderas, completamente falsas.
Otra limitación common de un software es que, por el hecho de que un software que retroalimente soluciones alternativas y de bajo tiempo de ejecución a un problema necesariamente requiere mayor esfuerzo y ello no es rentable, hay soluciones a ciertos problemas que emplean tiempos elevados de ejecución, y ello se intenta compensar siempre ejecutando el software en máquinas de mayor capacidad. Ello se puede notar en problemas que requieren de características del pensamiento humano, en los cuales un procedimiento mecánico” para hallar una solución es poco eficiente.
ESPECIFICACION DE REQUISITOS DEL SOFTWARE
Una especificación de requisitos del software es una descripción completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las interacciones que se prevén que los usuarios tendrán con el software. También contiene requisitos no funcionales ( suplementarios). Los requisitos no funcionales son los requisitos que imponen restricciones al diseño funcionamiento del sistema (tal como requisitos de funcionamiento, estándares de calidad, requisitos del diseño).
Las estrategias recomendadas para la especificación de los requisitos de software program están descritas por el estándar IEEE 830 -1998. Este estándar describe las estructuras posibles, contenido deseable y calidades de una especificación de requisitos del software.
Los requisitos se dividen en tres:
Funcionles:
Son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.
Los requerimientos funcionales de un sistema describen la funcionalidad los servicios que se espera que éste provea. Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software program. Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma common mientras que los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, and so forth.
Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de éste e incrementando el costo.
En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. La compleción significa que todos los servicios solicitados por el usuario están definidos. La consistencia significa que los requerimientos no tienen definiciones contradictorias. En la práctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de consistencia y compleción. La razón de esto se debe parcialmente a la complejidad inherente del sistema y parcialmente a que los diferentes puntos de vista tienen necesidades inconsistentes. Estas inconsistencias son obvias cuando los requerimientos se especifican por primera vez. Los problemas emergen después de un análisis profundo. Una vez que éstos se hayan descubierto en las diferentes revisiones en las fases posteriores del ciclo de vida, se deben corregir en el documento de requerimientos.
Ej.. el sistema debe emitir un comprobable al generar la entrega de mercadería.
No funcionales:
Son restricciones de los servicios funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, and so on.
Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en la interface del sistema.
Muchos requerimientos no funcionales se refieren al sistema como un todo más que a rasgos particulares del mismo. Esto significa que a menudo con más críticos que los requerimientos funcionales particulares. Mientras que el incumplimiento de este último degradará el sistema, una falla en un requerimiento no funcional del sistema lo inutiliza.
Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con otros sistemas de software program hardware a factores externos como los reglamentos de seguridad, las políticas de privacidad, etcétera.
Ej.: el soporte de almacenamiento a usar debe ser MySQL.
Empresariales u Organizacionales: son el marco contextual en el cual se implantaría el sistema para conseguir un objetivo marco. Ej: abaratar costos de expedición.
Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.
• Requerimientos del producto: Especifican el comportamiento del producto; como los requerimientos de desempeño en la rapidez de ejecución del sistema y cuánta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad.
• Requerimientos organizacionales: Se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador: estándares en los procesos que deben utilizarse; requerimientos de implementación como los lenguajes de programación el método de diseño a utilizar, y los requerimientos de entrega que especifican cuándo se entregará el producto y su documentación.
• Requerimientos externos: Se derivan de los factores externos al sistema y de su proceso de desarrollo. Incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema interactúa con los otros sistemas de la organización; los requerimientos legales que deben seguirse para asegurar que el sistema opere dentro de la ley, y los requerimientos éticos. Estos últimos son impuestos al sistema para asegurar que será aceptado por el usuario y por el público en basic.
Un problema común con los requerimientos no funcionales es que algunas veces son difíciles de verificar. Se redactan para reflejar las metas generales del usuario, como la facilidad de uso, la capacidad del sistema para recuperarse de las fallas inteligencia artificial la respuesta rápida al usuario. Estos requerimientos causan problemas a los desarrolladores del sistema puesto que dejan abierta la posibilidad a la interpretación, lo que provoca discusiones subsecuentes una vez que el sistema se entregue.
De forma excellent, los requerimientos no funcionales no se deben expresar de manera cuantitativa utilizando métricas que se puedan probar de forma objetiva.
En la práctica, la especificación cuantitativa de requerimientos es difícil. A los clientes no les es posible traducir sus metas en requerimientos cuantitativos; para algunas de éstas, como las de mantenimiento, no existen métricas que se puedan utilizar; el costo de verificar de forma objetiva los requerimientos no funcionales cuantitativos es muy alto.
En principio, los requerimientos funcionales y no funcionales se diferencian en el documento de requerimientos. En la práctica, esto es difícil. Si un requerimiento no funcional se declara de forma separada a los funcionales, algunas veces es difícil ver la relación entre ellos. Si se declaran con los requerimientos funcionales, es difícil separar las condiciones funcionales y no funcionales e identificar los requerimientos que se refieren al sistema como un todo. Se debe hallar un steadiness apropiado que dependa del tipo de sistema a especificar. Sin embargo, los requerimientos que claramente se refieren a las propiedades emergentes del sistema se deben resaltar. Esto se hace colocándolos en una sección aparte diferenciándolos, de alguna forma, de los otros requerimientos del sistema.
CARACTERISTICAS DEL SOFTWARE PROGRAM
1. El software program se desarrolla construye; no se manufactura en el sentido clásico.
A pesar de que existen similitudes entre el desarrollo del software y la manufactura del hardware, las dos actividades serian diferentes en lo fundamental. En ambas la alta calidad se alcanza por medio del buen diseño, la fase de manufactura del hardware puede incluir problemas de calidad existentes en el software program.
2. El software program no se desgasta.
El software program es inmune a los males ambientales que desgasten el hardware. Por lo tanto la curva de tasas de fallas para el software program debería tener la forma de la curva idealizada”. Los defectos sin descubrir causan tasas de fallas altas en las primeras etapas de vida de un programa. Sin embargo, los errores se corrigen y la curva se aplana: el software no se desgasta, pero si se deteriora.
3. A pesar de que la industria tiene una tendencia hacia la construcción por componentes, la mayoría del software program aun se construye a la medida.
Un componente de software se debe diseñar e implementar de forma que puede utilizarse en muchos programas diferentes.
Los componentes reutilizables modernos encapsulan tanto los datos como el proceso se aplican a estos, lo que permite al ingeniero de software program crear nuevas aplicaciones nuevas a partir de partes reutilizables.
Share this:
A %d blogueros les gusta esto: