sábado, 26 de marzo de 2011
domingo, 20 de marzo de 2011
Matriz Requerimientos Creando Sistemas
Matriz de requerimientos Creando Sistemas (Mario Abraham, Saul, Ricardo Vasquez) >>> Ver Matriz
sábado, 19 de marzo de 2011
viernes, 18 de marzo de 2011
Utilidad de la medida del software y normativa ISO 9126
Utilidad de la medida del softwareConsecuencia de su proceso interno de asegurar la calidad, cuantificar los atributos que constituyen la calidad para el usuario final, ahí tenemos los resultados cuantitativos. Saber que aquello que al usuario final le interesa lo tenga o no un producto y permita cuantificar almacenar otros productos.
Normativa ISO 9126, medida de la calidad de software descomponiendo atributos, para no tener márgenes de error e interpretación.
Atributo de funcionalidad.
Atributo de capacidad de respuesta frente a errores externos.
Atributo de nivel de seguridad. La calidad no puede existir sin seguridad, un producto sin seguridad seria un producto sin calidad. El observador o usuario final indica que atributos más o menos importantes de seguridad
Normativa ISO 9126, medida de la calidad de software descomponiendo atributos, para no tener márgenes de error e interpretación.
Atributo de funcionalidad.
Atributo de capacidad de respuesta frente a errores externos.
Atributo de nivel de seguridad. La calidad no puede existir sin seguridad, un producto sin seguridad seria un producto sin calidad. El observador o usuario final indica que atributos más o menos importantes de seguridad
CALIDAD, NORMATIVAS, FUNCIONALIDAD, CONFIABILIDAD, CERTIFICACION, MEDICON DE S
Calidad: Es la aptitud de un producto o servicio para satisfacer las necesidades del usuario.
Es la cualidad de todos los productos, no solamente de equipos sino también de programas.
En el desarrollo de software, la calidad de diseño acompaña a la calidad de los requisitos, especificaciones y diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación; Si la implementación sigue al diseño, y el sistema resultante cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta.
Adicionalmente se puede seguir los siguientes aspectos para evaluar la calidad del software:
Funcionalidad Confiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad Escalabilidad(actualizacion)
Calidad de softwareCaracterísticas propias del software aquellas que tu quieres controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan físicamente, sino que se desarrolla; El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carácter físico.
La calidad del software se encuentra a la par con la calidad tradicional, pero un paso atrás, debido a que la calidad tradicional tiene varias décadas de historia, mientras que la calidad de software tiene 50 a 30años.
Certificación del software Consecuencia de un proceso que es asegurar la calidad pero nunca es el objetivo final. La calidad de software no se certifica, lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en función de la normalización (ISO 9000, CMMI,...)
Normativa ISO 9000Pone a disposición de un auditor o certificador los procesos internos, de forma que este indique si cumple o no la normativa al 100%, audita el sistema; Si los resultados son positivos se emite la certificación y cada cierto tiempo se tiene que renovar; La certificación es costosa, a consecuencia de costes que ocasionan la lejanía y el tiempo de duración de proceso (aprox. 6 meses). Se certifica la empresa y la metodología para el desarrollo de la aplicación.
Medición del softwareEn el software lo que se mide son atributos propios del mismo, se descompone un atributo general en otros más simples de medir, a veces se mide bien o mal ya que la descomposición del atributo genérico de calidad en otros sub-atributos se torna irreal, se mide con datos estadísticos no avalados, es imposible decir que la medición se hace en forma correcta.
El concepto de medida va de más a menos, va de lo general a lo concreto y lo concreto es asociado a la métrica, cuya combinación te daría el nivel de calidad o seguridad de tu producto. Las ciencias bien estructuradas se basan en medidas bien hechas, se basan en la matemática.
Tipos de medidas Número de errores durante un periodo determinado.
Fallo en la codificación o diseño de un sistema que causa que el programa no funcione correctamente o falle.
Tamaño de un producto informático (líneas de código)
Métrica de punto función (IBM): relaciona funcionalidades que ofrecía.
Estimación de costes y esfuerzos.
COCOMO
Es la cualidad de todos los productos, no solamente de equipos sino también de programas.
En el desarrollo de software, la calidad de diseño acompaña a la calidad de los requisitos, especificaciones y diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación; Si la implementación sigue al diseño, y el sistema resultante cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta.
Adicionalmente se puede seguir los siguientes aspectos para evaluar la calidad del software:
Funcionalidad Confiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad Escalabilidad(actualizacion)
Calidad de softwareCaracterísticas propias del software aquellas que tu quieres controlar y asegurar, el software es un producto inmaterial que no se fabrica, tampoco se degradan físicamente, sino que se desarrolla; El software puede tener errores, incidencias pero no son similares a lo que cualquier equipo de carácter físico.
La calidad del software se encuentra a la par con la calidad tradicional, pero un paso atrás, debido a que la calidad tradicional tiene varias décadas de historia, mientras que la calidad de software tiene 50 a 30años.
Certificación del software Consecuencia de un proceso que es asegurar la calidad pero nunca es el objetivo final. La calidad de software no se certifica, lo que se certifica son los procedimientos para construir un software de calidad, los procedimientos deben ser correctos y estar en función de la normalización (ISO 9000, CMMI,...)
Normativa ISO 9000Pone a disposición de un auditor o certificador los procesos internos, de forma que este indique si cumple o no la normativa al 100%, audita el sistema; Si los resultados son positivos se emite la certificación y cada cierto tiempo se tiene que renovar; La certificación es costosa, a consecuencia de costes que ocasionan la lejanía y el tiempo de duración de proceso (aprox. 6 meses). Se certifica la empresa y la metodología para el desarrollo de la aplicación.
Medición del softwareEn el software lo que se mide son atributos propios del mismo, se descompone un atributo general en otros más simples de medir, a veces se mide bien o mal ya que la descomposición del atributo genérico de calidad en otros sub-atributos se torna irreal, se mide con datos estadísticos no avalados, es imposible decir que la medición se hace en forma correcta.
El concepto de medida va de más a menos, va de lo general a lo concreto y lo concreto es asociado a la métrica, cuya combinación te daría el nivel de calidad o seguridad de tu producto. Las ciencias bien estructuradas se basan en medidas bien hechas, se basan en la matemática.
Tipos de medidas Número de errores durante un periodo determinado.
Fallo en la codificación o diseño de un sistema que causa que el programa no funcione correctamente o falle.
Tamaño de un producto informático (líneas de código)
Métrica de punto función (IBM): relaciona funcionalidades que ofrecía.
Estimación de costes y esfuerzos.
COCOMO
Control y administración de la configuración
Cuando piensa en ingeniería de software, también puede pensar de administración de configuración de software que es el proceso de control de cambios y seguimiento de los nuevos cambios. Dos importantes tareas de administración de configuración de software incluyen el establecimiento de líneas de base y de control de revisiones. La principal preocupación de las empresas practicar este tipo de administración de la configuración es averiguar si puede reproducir las acciones de otra persona (en cuanto a software), tal vez no perfectamente, pero cierra con cambios controlados. Este proceso de reproducción y la comparación de las diferencias son muy importantes para la administración de la configuración de software.
Generalmente normal configurar gestión técnicas se centrarán en la creación de productos simples en un entorno controlado, sin embargo con el software de administración de la configuración aborda los sistemas complejos y cambiante cómo se desarrollan los pequeños incrementos en el entorno controlado.
Configuración de software es la práctica de cómo utilizar los objetos de diferentes variedades y cómo pueden ser gestionados y convertidos en versiones diferentes. Este proceso incluye la creación de códigos de software, el diseño de modelos y documentos y incluso puede incluirse en la realización de la estructura del directorio.
Los propósitos de administración de configuración de software son diferentes y diversas que abarca muchos aspectos diferentes de la creación de software. El primero fue la identificación de la configuración que señala qué códigos, vamos a trabajar con. El siguiente es el control de esa configuración; Esto se utiliza en el lanzamiento de su nuevo producto con sus cambios. A continuación será la contabilidad de la situación del nuevo producto, mediante la grabación de la información relativa a sus componentes. Después de que se hayan completado estos procesos se mueve en la etapa de revisión que garanticen que todos los componentes están completas y sean compatibles con todos los otros componentes.
Otros usos de configuración de software incluyen la gestión de versiones y las herramientas que se va a utilizar para crear las versiones. También garantiza que los usuarios sigan los procesos de desarrollo normal de las organizaciones. Administra el hardware y el software del host para el sistema de la empresa. Equipos de personas permite trabajar juntos para crear y completar un proceso específico. Además de todas estas cosas, el proceso de administración de configuración de software registrará cada único defecto todos el camino de vuelta a su código fuente para que puede solucionarlo antes de que sea un producto terminado.
Generalmente normal configurar gestión técnicas se centrarán en la creación de productos simples en un entorno controlado, sin embargo con el software de administración de la configuración aborda los sistemas complejos y cambiante cómo se desarrollan los pequeños incrementos en el entorno controlado.
Configuración de software es la práctica de cómo utilizar los objetos de diferentes variedades y cómo pueden ser gestionados y convertidos en versiones diferentes. Este proceso incluye la creación de códigos de software, el diseño de modelos y documentos y incluso puede incluirse en la realización de la estructura del directorio.
Los propósitos de administración de configuración de software son diferentes y diversas que abarca muchos aspectos diferentes de la creación de software. El primero fue la identificación de la configuración que señala qué códigos, vamos a trabajar con. El siguiente es el control de esa configuración; Esto se utiliza en el lanzamiento de su nuevo producto con sus cambios. A continuación será la contabilidad de la situación del nuevo producto, mediante la grabación de la información relativa a sus componentes. Después de que se hayan completado estos procesos se mueve en la etapa de revisión que garanticen que todos los componentes están completas y sean compatibles con todos los otros componentes.
Otros usos de configuración de software incluyen la gestión de versiones y las herramientas que se va a utilizar para crear las versiones. También garantiza que los usuarios sigan los procesos de desarrollo normal de las organizaciones. Administra el hardware y el software del host para el sistema de la empresa. Equipos de personas permite trabajar juntos para crear y completar un proceso específico. Además de todas estas cosas, el proceso de administración de configuración de software registrará cada único defecto todos el camino de vuelta a su código fuente para que puede solucionarlo antes de que sea un producto terminado.
OBJETIVO DE DISEÑO DE SOFTWARE
Los 5 objetivos del diseño
Partiendo del diseño de sitios o sistemas como Diseño de la Interacción podemos determinar al menos 5 objetivos para el diseño:
Definir el producto final
Acotar y minimizar los costos
Poner foco en el usuario
Sacar la presión que el diseño implica para el equipo de programación
Hacer creíbles y "cumplibles" los cronogramas
El conocimiento a priori de objetivos genéricos para el diseño de sitios y aplicaciones, más allá del objetivo específico de diseñar dicha
aplicación o sitio, nos permite saber si vamos o no por buen camino. Preguntando por cada objetivo en concreto podemos determinar fácilmente
si estamos o no diseñando en forma acertada.
Vale la pena resaltar una vez más que el diseño precede a la programación. Primero se diseña, luego se programa y después se decora. Confundir
decoración con diseño es un error común y que se paga caro. Los objetivos aquí planteados tienen que conseguirse por tanto antes de que se
escriba la primera linea de programación.
Definir el producto final
Definir el producto final antes de empezar a programar es algo tan obvio en la teoría como difícil de encontrar en la práctica.
Vale la pena resaltar una vez más que el diseño precede a la programación. Primero se diseña, luego se programa y después se decora.
Otras ciencias más maduras que la informática, como por ejemplo la arquitectura y la ingeniería civil, trabajan el tiempo necesario
para cumplir con este objetivo antes de comenzar con las tareas de campo. Todas las herramientas son válidas: maquetas, planos, memorias
descriptivas, animaciones y un bagaje enorme de técnicas permiten dar visiones completas del producto terminado a los clientes, a los
inversores, a los constructores, a los albañiles, subcontratistas y todos los participantes de la obra sin necesidad de poner el primer
ladrillo. El ejemplo es válido para trasladarlo a la industria informática. En ésta, apenas se conocen los primeros esbozos del sistema,
se comienza a programar, con la ilusión de que programar y diseñar en paralelo ahorra tiempo y dinero. Lamentablemente muchas veces es
considerado entre los programadores una viveza, un rasgo de picardía, obviar el trabajo previo de diseño y documentación.
Partiendo del diseño de sitios o sistemas como Diseño de la Interacción podemos determinar al menos 5 objetivos para el diseño:
Definir el producto final
Acotar y minimizar los costos
Poner foco en el usuario
Sacar la presión que el diseño implica para el equipo de programación
Hacer creíbles y "cumplibles" los cronogramas
El conocimiento a priori de objetivos genéricos para el diseño de sitios y aplicaciones, más allá del objetivo específico de diseñar dicha
aplicación o sitio, nos permite saber si vamos o no por buen camino. Preguntando por cada objetivo en concreto podemos determinar fácilmente
si estamos o no diseñando en forma acertada.
Vale la pena resaltar una vez más que el diseño precede a la programación. Primero se diseña, luego se programa y después se decora. Confundir
decoración con diseño es un error común y que se paga caro. Los objetivos aquí planteados tienen que conseguirse por tanto antes de que se
escriba la primera linea de programación.
Definir el producto final
Definir el producto final antes de empezar a programar es algo tan obvio en la teoría como difícil de encontrar en la práctica.
Vale la pena resaltar una vez más que el diseño precede a la programación. Primero se diseña, luego se programa y después se decora.
Otras ciencias más maduras que la informática, como por ejemplo la arquitectura y la ingeniería civil, trabajan el tiempo necesario
para cumplir con este objetivo antes de comenzar con las tareas de campo. Todas las herramientas son válidas: maquetas, planos, memorias
descriptivas, animaciones y un bagaje enorme de técnicas permiten dar visiones completas del producto terminado a los clientes, a los
inversores, a los constructores, a los albañiles, subcontratistas y todos los participantes de la obra sin necesidad de poner el primer
ladrillo. El ejemplo es válido para trasladarlo a la industria informática. En ésta, apenas se conocen los primeros esbozos del sistema,
se comienza a programar, con la ilusión de que programar y diseñar en paralelo ahorra tiempo y dinero. Lamentablemente muchas veces es
considerado entre los programadores una viveza, un rasgo de picardía, obviar el trabajo previo de diseño y documentación.
EQUIPO : CARLOS JACOME, FLORENTINO MORENO Y RICHARD CASTELLANOS
Historia
La Ingeniería del Software, término utilizado por primera vez por Fritz Bauer en la primera conferencia sobre desarrollo de software patrocinada por
el Comité de Ciencia de la OTAN celebrada en Garmisch, Alemania, en octubre de 1968, puede definirse según Alan Davis como “la aplicación inteligente
de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento, dentro de un coste razonable, de software que satisfaga
las necesidades de los usuarios.
El término ingeniería del software empezó a usarse a finales de la década de los sesenta, para expresar el área de conocimiento que se estaba
desarrollando en torno a las problemáticas que ofrecía el software en ese momento.
En esa época, el crecimiento espectacular de la demanda de sistemas de computación cada vez más y más complejos, asociado a la inmadurez del
propio sector informático (totalmente ligado al electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la crisis del software
(en palabras de Edsger Dijkstra) entre los años 1965 y 1985.
Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas estimados, algunos de ellos eran tan críticos
(sistemas de control de aeropuertos, equipos para medicina, entre otros) que sus implicaciones iban más allá de las pérdidas millonarias que
causaban.
La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino en parte porque no es razonable estar en crisis más de
veinte años, y en parte porque se estaban haciendo progresos en los procesos de diseño y metodologías.
Así pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologías y tecnologías que se presentaban como la solución definitiva
al problema de la planificación, previsión de costes y aseguramiento de la calidad en el desarrollo de software. Entre las que se encuentran la
programación estructurada, la programación orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programación ADA, la documentación,
los estándares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solución a los problemas de la
ingeniería del software, la llamada “bala de plata” (por silver bullet). Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello.
En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que
si se probaba formalmente que los desarrollos hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas
de la ingeniería.
La Ingeniería del Software, término utilizado por primera vez por Fritz Bauer en la primera conferencia sobre desarrollo de software patrocinada por
el Comité de Ciencia de la OTAN celebrada en Garmisch, Alemania, en octubre de 1968, puede definirse según Alan Davis como “la aplicación inteligente
de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento, dentro de un coste razonable, de software que satisfaga
las necesidades de los usuarios.
El término ingeniería del software empezó a usarse a finales de la década de los sesenta, para expresar el área de conocimiento que se estaba
desarrollando en torno a las problemáticas que ofrecía el software en ese momento.
En esa época, el crecimiento espectacular de la demanda de sistemas de computación cada vez más y más complejos, asociado a la inmadurez del
propio sector informático (totalmente ligado al electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la crisis del software
(en palabras de Edsger Dijkstra) entre los años 1965 y 1985.
Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas estimados, algunos de ellos eran tan críticos
(sistemas de control de aeropuertos, equipos para medicina, entre otros) que sus implicaciones iban más allá de las pérdidas millonarias que
causaban.
La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino en parte porque no es razonable estar en crisis más de
veinte años, y en parte porque se estaban haciendo progresos en los procesos de diseño y metodologías.
Así pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologías y tecnologías que se presentaban como la solución definitiva
al problema de la planificación, previsión de costes y aseguramiento de la calidad en el desarrollo de software. Entre las que se encuentran la
programación estructurada, la programación orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programación ADA, la documentación,
los estándares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solución a los problemas de la
ingeniería del software, la llamada “bala de plata” (por silver bullet). Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello.
En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que
si se probaba formalmente que los desarrollos hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas
de la ingeniería.
lunes, 14 de marzo de 2011
Y los trabajos???
Al día de hoy no he recibido ninguna tarea de su actividad que tenían que realizar durante la semana pasada y la del sábado. Les recuerdo que para el próximo sábado su proyecto final deberán cubrir:
- Especificación de Requerimientos
- Propuesta de Solución
- Administración de la Configuración
- Plan de Desarrollo del proyecto.
Si tienen dudas me pueden mandar correo, pero es necesario que realicen sus actividades ya que el próximo sábado habrá examen de todos los temas que hemos visto incluyendo los que tenían que investigar para este sábado que paso.
Saludos
sábado, 5 de marzo de 2011
Tareas a realizar la proxima semana
Temas Actividades
| HERRAMIENTAS Y AMBIENTES PARA LA INGENIERÍA DE SOFTWARE 7.1 Desarrollo histórico de herramientas y ambientes. 7.2 Clasificación de herramientas y ambientes de software. 7.3 Herramientas más representativas 7.4 El papel del lenguaje de programación en el ambiente. 7.5 Algunos ejemplos de herramientas. 7.6 Perspectivas de evolución de la Ingeniería de Software | Crear mapa mental de clasificaciones de herramientas y ambientes de software, herramientas representativas. Investigar la historia de las herramientas y ambientes de software Investigación de las perspectivas de evolución de la Ing. Realizar un mismo diagrama (el diagrama de casos de uso que realizaron previamente) en distintas herramientas, identificar la que le resulte más conveniente y escribir el porque en el blog, junto con los diagramas realizados. Buscar 1 programa similar (cada alumno uno distinto) a Balsamiq Mookups y realizar el mookup de una interfaz del sistema relacionada con el caso de uso que han venido trabajando. Avanzar con el proyecto final. |
libro de ingenieria de software de ian summerville
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B7J9SPOPl978NTE2OGFiMDMtNTQ3OC00NTBiLTk0MWItYzcwZjExZTJmYzhh&hl=es&authkey=COLM-YoN
viernes, 4 de marzo de 2011
Mapa mental de lo visto en la materia
Realizado en Mind42.com
http://mind42.com/pub/mindmap?mid=d78c145f-0604-4326-afda-ff11af3bf1c7
http://mind42.com/pub/mindmap?mid=d78c145f-0604-4326-afda-ff11af3bf1c7
Lenguaje Unificado de Modelado - Wikipedia, la enciclopedia libre
Lenguaje Unificado de Modelado - Wikipedia, la enciclopedia libre: "En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es útil categorizarlos jerárquicamente, como se muestra en la figura de la derecha.
Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:
Diagrama de clases
Diagrama de componentes
Diagrama de objetos
Diagrama de estructura compuesta (UML 2.0)
Diagrama de despliegue
Diagrama de paquetes
Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:
Diagrama de actividades
Diagrama de casos de uso
Diagrama de estados"
Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:
Diagrama de clases
Diagrama de componentes
Diagrama de objetos
Diagrama de estructura compuesta (UML 2.0)
Diagrama de despliegue
Diagrama de paquetes
Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:
Diagrama de actividades
Diagrama de casos de uso
Diagrama de estados"
miércoles, 2 de marzo de 2011
Suscribirse a:
Entradas (Atom)