Normas y/o estándares aplicables a proyectos de T.I.

Introduccion

Las normas y los estandares que se pueden a plicar a los proyectos de T.I. en general cambian segun en lo que esten orientados, pero en su mayor parte comparten caracteristicas similares, el objetivo de esta entrada es ayduar a indentificarlas.

Concepto de Calidad

Es necesario poder indentificar que es la calidad, una definicion de esta seria un
conjunto  de propiedades y de características de un producto o servicio, que le confiera aptitud para satisfacer unas necesidades explícitas o implícitas.

Según McCall los factores que determinan la calidad del software se centran en tres aspectos importantes:

•  CARACTERISTICAS OPERATIVAS

•  CAPACIDAD DE SOPORTARCAMBIOS 

•  ADAPTABILIDADA NUEVOS ENTORNOS

Cada una de ellas es vital para saber la viabilidad del proyecto y su nivel de eficiencia, todas tienen especificaciones diferentes pero en fin de ellas es asegurar la calidad de los proyectos y su efectividad en general.

Referencias y Bibliografia

Libro: Estándares/Normas Internacionales de Información Financiera (IFRS/NIIF)

edited by Samuel Alberto Mantilla B.

Normas y estándares de calidad para el desarrollo de Software

Introducción
Para la creacion de un software, se deben de seguir reglas o direciones para saber la calidad del producto que se va a realizar, para esto existen varias lineas o guias para saber o regular la calidad de los programas de hoy en dia, esta entrada sera una breve explicacion de como funciona y que son.

Que es un estándar?
Un standard es una recomendación de buenas prácticas, de calidad (no estás obligado a cumplir) Ejemplo Standard IEC 61869-2

Que es una norma?
Una Norma son exigencias legales que estás obligado a cumplir, de lo contrario estás expuesto a sufrir sanciones ej. multas, retiro de lo construido.


A Continuacion se puede ver un link para ayudar a diferenciar las norams de los estandares, presentado por el Dr. Edmundo Flórez, en su canal de youtube.

https://www.youtube.com/watch?v=w8bUmqkO2MU

Calidad de software, normas y estandares.

En esta entrada se puede ver una pequeña introduccion a las nomas y estandares de calidad del software.

En este pequeno video se explica de manera breve que es un estandar y una norma en cuanto a calidad de software, de manera muy superficial, ya que el tema puedo tomar mucho tiempo de explicar.

Diagramas de Estado

Introducción

Los diagramas de estado son un método conocido para explicar el comportamiento de un sistema. Que explican todos los estados posibles en los que puede ingresar un objeto particular y la manera en que modifica el estado del objeto, como resultado de los eventos que llegan a el.

Un diagrama de estados es un diagrama utilizado para determinar cada una de las rutas o caminos que puede tomar un movimiento de información luego de ejecutarse cada proceso.

(Imagen: http://www.milestone.com.mx/articulos/la_vida_de_un_objeto_diagrama_de_estados.htm)

ELEMENTOS DEL DIAGRAMA DE ESTADOS:

Estado

Determina un lapso de tiempo del objeto, en el cual el objeto está esperando alguna ejecución, tiene cierta característica o puede obtener cierto tipo de estímulos. Se representa a través de un rectángulo con los bordes redondeados, que puede tener tres compartimientos: uno para el nombre, otro para el valor característico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado.

Eventos

Es una ocurrencia que puede causar el cambio de un estado a otro de un objeto. Esta ocurrencia puede ser:

• Condición que obtiene el valor de verdadero o falso

• Recepción de una señal de otro objeto en el modelo

• Recepción de un mensaje

• Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha particular

El nombre de un evento tiene alcance dentro del paquete en el cual está definido, no es local a la clase que lo nombre.

Hoy en dia para mostrar los detalles de las acciones llevadas a cabo por los objetos se puede tener una forma de expresarlo con imágenes o en este caso un diagrama el cual sirve de respuesta a eventos internos.

El diagrama de actividad se puede usar también para representar gráficamente las acciones de métodos de clases.

Fuentes y Referencias

https://wikiuml.wikispaces.com/Diagrama+de+Estados?responseToken=0aa2c71f428b768682ee88aa4de1d0b22

ANÁLISIS Y MODELADO DE DESARROLLO DE SOFTWARE CON UML.

Introducción

UML o Lenguaje Unificado de Modelado es una  forma para crear diagramas que ayuden a la comprension de los procesos o de un proyecto en general, facilitando desde su planeacion hasta su simulacion y facilitando el control sobre sus avanzes.

UML ofrece nueve diagramas en los cuales modelar sistemas en el listado siguiente se pueden ver los mas conocidos.

• Diagramas de Casos de Uso para modelar los procesos ’business’. 

• Diagramas de Secuencia para modelar el paso de mensajes entre objetos. 

• Diagramas de Colaboración para modelar interacciones entre objetos. 

• Diagramas de Estado para modelar el comportamiento de los objetos en el sistema. 

• Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones. 

• Diagramas de Clases para modelar la estructura estática de las clases en el sistema. 

• Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema. 

• Diagramas de Componentes para modelar componentes. 

• Diagramas de Implementación para modelar la distribución del sistema. 

Las bases de datos de hoy en dia se están basando en la programación orientada a objetos per aun asi la predominante sigue siendo la relacional. Los diagramas de clases de UML se pueden usar para modelar la base de datos relacional en la que el sistema está basado, sin embargo, los diagramas tradicionales de modelado de datos capturan más información sobre la base de datos relacional y son más adecuados para modelarla.

Fuentes y Referencias.

http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-sistemas-uml.pdf

http://www.monografias.com/trabajos28/proyecto-uml/proyecto-uml.shtml

www.hpl.hp.com/fusion/file/teameps.pdf

La especificación de requisitos de software 

Introduccion

La especificación de requisitos de software o (ERS) Puede ser definida como  una descripción completa del comportamiento del sistema que se va a desarrollar. Incluyendo  un conjunto de casos de uso que sirvan de ejemplo sobre como se debe desarrollar o su objetivo a realizar que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales.

Definicion

 Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación, como, por ejemplo, restricciones en el diseño o estándares de calidad.

Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado para su redacción debe ser informal, de forma que sea fácilmente comprensible para todas las partes involucradas en el desarrollo.

Acontinuacion se muestra una imagen que demuestra las diferentes formas que la gente entiende un problema con sus requisitos que se hizo muy famosa por un tiempo(Fuente:http://agilismoatwork.blogspot.mx/2011/12/gestion-de-requisitos-agil.html)

Conclusión

Se debe poder especificar el uso y la función de cada uno de los requisitos y sus características en ciertos casos dar ejemplos para informar al personal de su uso y sus necesidades de lso equipos a utilizar como detallando sus características en caso de que el personal encargado no tengo el conocimiento completo del tema o asunto a tratar, para así evitar mal entendidos y posibles cambios de cursos a medio plan o puesta en marcha.

Fuentes:

Raymond Turner. "The Foundations of Specification". Journal of Logic and Computation, Vol. 15, No. 5 (October 2005), pp. 623–663.

IEEE STD 830-1998. "Especificaciones de los requisitos del Software", pág. 3.

Estudio de factibilidad

Introduccion

Los estudios de factibilidad son aquellos estudios que se realizan para saber lo que se necesitaria al quere realizar un proyecto o un producto de tal manera que se pueda minimizar los gastos y/o riesgos que este implica. tienen mucho que ver con lso estudios de viablidad ya que ambos verifican si es posible llevar a cabo un proyecto.

VIABILIDAD

  El estudio de la viabilidad evalúa tres criterios: operacional, técnico y económico, del proyecto propuesto.

FACTIBILIDAD

El estudio de factibilidad debe conducir a:

Determinación plena e inequívoca del proyecto a través del estudio de mercado, la definición del tamaño, la ubicación de las instalaciones y la selección de tecnología.

Diseño del modelo administrativo adecuado para cada etapa del proyecto.

Estimación del nivel de las inversiones necesarias y su cronología/lo mismo que los costos de operación y el cálculo de los ingresos.

Identificación plena de fuentes de financiación y la regulación de compromisos de participación en el proyecto

Definición de términos de contratación y pliegos de licitación de obras para adquisición de equipos y construcciones civiles principales y complementarias.

Sometimiento del proyecto si es necesario a las respectivas autoridades de planeación y ambientales.

Aplicación de criterios de evaluación tanto financiera como económica, social y ambiental, que permita allegar argumentos para la decisión de realización del proyecto.
(Miranda Miranda, 2005)

Conclusión

Del estudio de factibilidad se puede concluir si se puede realizar ose debe abandonar el proyecto por no encontrarlo suficientemente viable, conveniente u oportuno o mejorarlo, elaborando un diseño definitivo, teniendo en cuenta las sugerencias y modificaciones que surgirán de los analistas representantes de las alternas fuentes de financiación, o de funcionarios estatales de planeación en los diferentes niveles, nacional, sectorial, regional, local o empresarial.

Fuentes y Referencias

https://prezi.com/zjempfftrdac/obtencion-y-analisis-de-requerimientos/

http://www.conocimientosweb.net/dcmt/ficha25211.html ( Gómez Fuentes María del Carmen, Análisis de requerimientos, editorial Publidisa Mexicana 2011.)