Buscar en el Blog

Mostrando entradas con la etiqueta ingenieria software. Mostrar todas las entradas
Mostrando entradas con la etiqueta ingenieria software. Mostrar todas las entradas

martes, 3 de noviembre de 2015

Casos de Uso 2.0 - Ivar Jaconson




La guia para ser exitoso con los casos de uso
CASOS DE USO 2.0: LA GU

La guia para ser exitoso con los casos de uso
Ivar Jacobson
Ian Spence
    Kurt Bittner
Traducción de:
  Luis Antonio Salazar Caraballo
Carlos Mario Zapata Jaramillo

viernes, 19 de junio de 2015

Asuntos de la Ingeniería de Software, Volumen II - Luis Salazar Caraballo

Asuntos de la Ingeniería de Software
Volumen 2
Casos de Uso y otros elementos suby acentes de la Ingeniería de
Softw are
Luis Antonio Salazar Caraballo
Ingenier ía e Infor mática
Gazafatonar io IT
http://www.gazafatonar ioit.com




Par te 1 – Algunos Aspectos Esenciales de la Ingenier ía de Softwar e
1. Pr olegómenos Sobr e el Lenguaje de Modelado Unificado (UML)
Resumen
Palabras Clave
Generalidades
El Lenguaje
Los Diagramas de UML
Diagramas de Casos de Uso
Diagramas de Secuencia
Diagramas de Comunicación
Diagramas de Clases
Diagramas de Estados
Diagramas de Actividad
Diagramas de Componentes
Diagramas de Despliegue
Paquetes, Subsistemas y Modelos
Otros Conceptos Básicos
Lo Que NO ES UML
Mitos Sobre UML
Conclusiones y Recomendaciones
Referencias
2. De Pr ocesos y de Humanos
La Primera Ley del Proceso de Software
La Segunda Ley del Proceso de Software
La Tercera Ley del Proceso de Software
Referencias
3. El Proceso Unificado o Todo lo que quisiste saber alguna vez de UP y
no te atr eviste a pr eguntar …
Framework, Proceso y Metodología
Comentario del Autor
Raíces
Metas de las Fases
Metas de las Disciplinas
Variaciones del Proceso Unificado
Referencias
4. UP: Fase de Concepción
UP es Dirigido por Casos de Uso y es Centrado en la Arquitectura
Roles y Responsabilidades Durante Concepción
El Ingeniero de Procesos
El Analista de Procesos del Negocio
El Gerente del Proyecto
Referencias
5. UP: Fase de Concepción, Par te 2
El Analista de Requisitos
De Artefactos y Otros Menesteres Durante la Concepción
Sobre la Arquitectura Preliminar
En el Final
Referencias
6. Or ientación a Objetos: Un Enfoque Teór ico Moder no (Actualizado)
Introducción
Biología Informática
Conceptos Fundamentales
¿De dónde surgen los objetos?
El Siguiente Paso en la Evolución
Conclusión
Referencias
Par te 2 – Ingenier ía de Requisitos con Casos de Uso: Volumen 1
7. Casos de Uso: De Vuelta a lo Fundamental
Introducción
Escenarios
Caso de Uso Esencial
Caso de Uso Descompuesto Funcionalmente
Ejemplo: el caso de uso “ Hola Mundo”
8. Casos de Uso: Or igen, Especificación y Evolución
Introducción
Caso de Uso y Actor del Negocio
Características de un Caso de Uso Típico
El Actor
Ejemplo, Ejemplo, Ejemplo.
9. Casos de Uso: Del Todo y de Sus Par tes
La Descripción Breve
Las Precondiciones
La Secuencia Básica
Las Secuencias Alternativas
Las Poscondiciones
Los Requisitos Especiales
Conclusión
Referencias
10. Casos de Uso: ¿Cuándo Están Ter minados?... ¿Y qué hacer con
ellos a continuación?
Ley de la Terminación de un Caso de Uso
¿Y qué hacer con los casos de uso cuando están terminados?
11. Realización de Casos de Uso: De los Objetos y sus Inter acciones
Presentación
Sobre el Lenguaje de Modelado Unificado
El Caso de Estudio (o sea, el Ejemplo)
Interacciones
Diagramas de Secuencia, Paso a Paso
De Estereotipos y Otros Menesteres
Comentarios Finales
Referencias
12. Casos de Uso: de Extensiones y de Inclusiones
Introducción
Generalización de Actores
Relaciones Entre Actores y Casos de Uso
Relaciones Entre Casos de Uso
Relación de Inclusión
Relación de Ex tensión
Generalización Entre Casos de Uso
Conclusiones
¿Quiere Saber Más?
Referencias
13. Los Casos de Abuso o De Cómo Usar Cor r ectamente los Casos de
Uso Cor r ectos y Sobr evivir en el Intento
Introducción
Caso de Abuso 1: El caso de uso se usa en todos los casos.
Caso de Abuso 2: Lo que no está documentado en los casos de uso no hace parte
del proyecto.
Caso de Abuso 3: El caso de uso es la única documentación necesaria para
construir el software.
Caso de Abuso 4: Lo que no está documentado en los casos de uso no hace parte
del proyecto.
Caso de Abuso 5: El caso de uso se identifica, elabora, diseña, implementa y
prueba en la misma iteración.
Caso de Abuso 6: El caso de uso contiene detalles de formularios (pantallas) y otros
aspectos técnicos (bases de datos, componentes, etc.)
Caso de Abuso 7: Un escenario y un caso de uso es lo mismo
Caso de Abuso 8: La realización o diseño de un caso de uso siempre se hace
Caso de Abuso 9: Precondiciones vs. Validaciones y Poscondiciones vs.
Resultados
Caso de Abuso 10: Todos los requisitos funcionales se documentan en casos de
uso
Caso de Abuso 11: Los flujos de eventos en los casos de uso son escritos en
pseudocódigo
Caso de Abuso 12: Cada caso de uso se diseña e implementa de manera
independiente
Caso de Abuso 13: Todos los casos de uso se identifican y especifican durante la
fase de inicio del proyecto.
Caso de Abuso 14: El caso de uso solo se presenta cuando está completamente
terminado y aprobado.
Caso de Abuso 15: El caso de uso tiene más de un actor “ activo”
Caso de Abuso 16: El Ingeniero de Requisitos es un psíquico
Desenlace: Los casos de abuso o de cómo hacer un mal uso de los casos de uso
Resumen de los Casos de Abuso
Para No Cometer Más Abusos
(Aclaración)
Conclusiones
Referencias
14. Diez Consejos Útiles y Simples Par a Escr ibir Efectivamente Casos de
Uso Efectivos
Presentación
Consejo 1
Consejo 2
Consejo 3
Consejo 4
Consejo 5
Consejo 6
Consejo 7
Consejo 8
Consejo 9
Consejo 10
Consejo Adicional: ¿Cómo luce un caso de uso inefectivo?
¿Y cómo luce un caso de uso efectivo?
Conclusiones y Recomendaciones
Apéndice A IGML – Per fil de UML par a Aplicaciones Web
IGML: Per fil de UML par a Aplicaciones Web
I. INTRODUCCIÓN
Presentación
Motivación
Beneficios de un Perfil UML para Aplicaciones Web en Intergrupo
Trabajos Relacionados
II. El Meta-Modelo
Metamodelo de las aplicaciones Web
Estereotipos
III. Conclusiones y trabajo futuro
Referencias

jueves, 26 de febrero de 2015

Compiladores, principios, técnicas y herramientas


Alfred V. Aho
Monica S. Lam
Ravi Sethi
Jeffrey D. Ullman

R e q u is ito s p re v io s
E l lector d eb e poseer cierto “conocim iento orientado a las cien cias com putacionales” , lo que
incluye por lo m enos un segundo curso sobre program ación, adem ás d e cursos sobre estructuras
d e d a tos y m atem áticas discretas. E s ú til tener un conocim iento sobre varios lenguajes de
program ación.

E je rc ic io s
E ste libro contiene gran cantidad d e ejercicios para ca si to d a s las secciones. P ara indicar los
ejercicios difíciles, o partes d e ellos, utilizam os un signo d e adm iración. Los ejercicios todavía
m ás difíciles tien en doble sign o d e adm iración.

lunes, 26 de enero de 2015

Propuesta De Metodología Y Estándares Para La Administración De Proyectos En Las Pequeñas Y Medianas Empresas De Software






UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL
(UCI)



Propuesta De Metodología Y Estándares Para La Administración De Proyectos En Las Pequeñas Y Medianas Empresas De Software Con Base En Los Estándares Del PMI

Paginas 326


domingo, 25 de enero de 2015

Buenas prácticas de calidad en el desarrollo de aplicaciones - Seguridad





Índice:
1. Introducción
2. Principios del desarrollo seguro
3. Recomendaciones
 3.1 Acceso a base de datos
3.1.1 Inyección SQL
3.1.2 Control de acceso
3.2 Acceso al sistema de ficheros
3.2.1 Manipulación de rutas
3.2.2 Inyección de comandos
3.2.3 Uso indebido: subida de archivos
3.3 Gestión de logs
3.3.1 Falsificación de log
3.3.2 Usos indebidos
3.4 Configuración
3.4.1 Contraseñas en ficheros de configuración
3.4.2 Esquema XML débil
3.5 Generación de contenido web
3.5.1 Cross-Site Scripting (XSS)
3.5.2 Manipulación de cabeceras
3.5.3 Cross-Site Request Forgery
3.6 Criptografía
3.6.1 Encriptación débil
3.7 Control de acceso
3.7.1 Fijación de sesión
3.8 Diseño
3.8.1 Condición de carrera: Variable miembro Singleton
3.8.2 Almacenar objetos no serializables en sesión
3.9 Gestión de recursos
3.9.1 Recurso no liberado
3.9.2 Denegación de servicio
3.10 Revelación de información
3.10.1 Violación de privacidad
3.10.2 Fuga de información del sistema
3.10.3 Contraseñas escritas directamente en el código
4. Verificación
5. Valoración de la seguridad de las aplicaciones
6. ENS (Esquema Nacional de Seguridad) 



sábado, 24 de enero de 2015

Buenas prácticas para el Desarrollo de Software



Solid y Grasp
Buenas prácticas para el Desarrollo de Software
Juan García Carmona
Páginas 43

¿Estás pensando en hacer una evaluación de TMMi?





TMMi es una certificación internacional complementaria a CMMI y fundamentada en un proceso evolutivo que integra ISO 15504.

¿Qué propone TMMi?

La certificación aborda el tratamiento de la calidad en el sentido más amplio y complejo frente al ciclo de vida del software. TMMi (Test Maturity Model Integration) es un modelo diseñado para la mejora de los procesos de prueba. Está pensado como complemento al modelo CMMI y posee un alto valor diferenciador para las organizaciones en las que las pruebas software tienen mucha.
Además de la certificaciones institucionales, TMMi también cuenta con una certificación personal para profesionales de sistemas, que puede tomarse en más de 10 puntos de exámen autorizados en Argentina, al igual que certificaciones como “Cisco, JAVA, HP, etc”. En Latinoamérica, QAustral posee profesionales miembros de TMMI Foundation desde 2010 y actualmente es un centro acreditado para la formación de “TMMi Professional”. Además de la certificación propiamente dicha, el esquema de organización que se propone en la norma brinda soluciones esquemáticas, de estrategias de calidad e integradoras de conocimiento y certificaciones personales en aseguramiento de calidad como los conocimientos que se proponen ISTQB, CAT e IREB y otras certificaciones personales.
El estándar que es utilizado más ampliamente para mejorar los procesos de desarrollo es el Modelo de la Capacidad de Madurez Integrado (CMMi). No obstante, a pesar de que el 30-40% de los costos totales de un proyecto a menudo se destinan a los procesos de prueba, en CMMi no se encuentran totalmente abordados y tampoco en la norma ISO 15504 que son modelos de referencia pero menos específicos en Calidad de Software. Por esa razón, la comunidad de procesos de pruebas, actualmente encabezada por TMMi Foundation, ha desarrollado el TMMi (Test Maturity Model Integrated), que proporciona un enfoque más amplio y estructurado al proceso de pruebas de una organización lo que redunda en un impacto positivo sobre la calidad del producto. De hecho casi el 50% de los elementos de prueba que cubre TMMi no están contemplados en CMMi, por lo que ofrece un estándar con un nivel de pruebas más riguroso que el CMMi.

Los niveles de madurez TMMi son:
·         Nivel 1: Inicial
Representa un estado donde no existe un proceso de pruebas formalmente documentado o estructurado. Las pruebas son típicamente desarrolladas de un forma “ad-hoc” luego de escribir código, y las pruebas se tratan de la misma forma que la depuración. El objetivo de las pruebas es probar que el software trabaja. Depende de “héroes” y no existe entendimiento del costo de la calidad

·         Nivel 2: Gestionado
El segundo nivel se alcanza cuando los procesos de prueba están claramente separadas de depuración. Se puede llegar mediante el establecimiento de políticas y objetivos de la prueba, la introducción de los pasos que se encuentran en un proceso de prueba fundamental (por ejemplo, la planificación de la prueba), y la aplicación de técnicas y métodos de prueba básicos. Se usan ambientes de pruebas.

·         Nivel 3: Definido
El tercer nivel se alcanza cuando un proceso de prueba esta integrado dentro del ciclo de vida de desarrollo de software, y se documenta usando estándares, procedimientos y métodos formales. Se realizan revisiones y debe haber una funcion de pruebas de software distinta que puede ser controlada y monitoreada. Se realizan pruebas no-funcionales.

·         Nivel 4: Medido
El nivel cuatro se logra cuando el proceso de prueba es capaz de ser medido de manera efectiva y gestionado a nivel de organización en beneficio de proyectos específicos. Se implementa un proceso de evaluación de la calidad del producto.

·         Nivel 5: Optimizado
El último nivel representa un estado de madurez de los procesos de prueba donde los datos del proceso de prueba se puede utilizar para ayudar a prevenir defectos, y la atención se centra en la optimización del proceso establecido. Se establece un grupo de mejora del proceso de pruebas permanente.

Documentación oficial http://www.tmmi.org/?q=downloads