31 de Enero de 2016
Instituto Tecnológico de Morelia Ingeniería de Software Revisión del Programa de estudios
Alumnos: Ignacio Alexander Barriga Rios Prof. Ardían Núñez Vieyra
Introducción En este trabajo se describirán varios conceptos de los temas del programa de estudios de la materia de Ingeniería de software, los cuales tratan desde la planificación del desarrollo de software para los negocios hasta la seguridad y calidad del software. Dentro de este trabajo se mostrará cómo ha ido evolucionado el modelado de negocios, las diferentes metodologías de desarrollo de software entre ellas las más importantes como son la metodología en cascada, en espiral o la incremental. De igual manera en este trabajo se definirán algunas arquitecturas de desarrollo de software las cuales sirven para la solución de problemas y la presentación de estas soluciones ante los clientes, cual es la mejor opción de un desarrollo de software tomando en cuenta las necesidades y antecedentes del cliente. Por otro lado se analizará la importancia de la seguridad en cada etapa de un proyecto de desarrollo de software desde la toma de requisitos hasta su implementación o distribución de tal manera que los errores que puedan surgir no afecten demasiado la funcionalidad del software para obtener así una mejor calidad. Todo esto se verá a lo largo de este documento.
Capítulo 1: Modelado de Negocios El modelado de negocios es de gran ayuda en la etapa de análisis de desarrollo de software, ya que tener un buen modelo permite lograr comprender el ámbito de la información además de identificar las actividades y procesos que se realizan dentro de la organización para lograr una correcta operación y así lograr una buena comprensión del negocio para automatizar procesos al crear sistemas computacionales que se ajusten a la medida de una organización. Se puede definir el modelado de negocios como una herramienta conceptual que contiene un conjunto de objetos, conceptos y sus relaciones con el objetivo de expresar la lógica del negocio de una empresa (Osterwalder, Pigneur & Tucci, 2005:1). Proporciona una vista simplificada de la estructura de negocios que actúa como la base para la comunicación, mejoras o innovación y define los requisitos de los sistemas de información que apoyan la empresa (Ericsson & Penker, 2000:1). En otras palabras el modelado de negocios debe crear una representación gráfica de una empresa, donde se puedan apreciar todo los elementos que lo componen, su interacción, recursos, metas, procesos la comunicación y relaciones que existen. [1]
1.1 Evolución del modelado de negocios. Modelado de Estructuras Organizacionales. Son las diversas combinaciones, sistemas o modelos presentes en la estructura orgánica que pueden llevarse a cabo en una empresa; se expresan en las cartas u organigramas y se complementan con la descripción de puestos. Modelado de Flujos de Datos
Representación gráfica de la evolución de la información dentro de un sistema de información. Desde que la información ingresa a un S. I., va sufriendo sucesivas transformaciones, hasta que se almacena definitivamente en él o sale transformada.
Modelado de Flujos de Trabajo Permiten abordar la automatización de los procesos que tienen lugar dentro de las organizaciones. El desarrollo de estos sistemas ha tenido un fuerte componente tecnológico, centrándose más en la creación de entornos de ejecución eficientes y distribuidos, que en proporcionar un soporte formal y metodológico que garantice la obtención de modelos de flujo de trabajo de calidad. Modelado de Reglas de Negocio Para modelar esta regla de negocio se identifican los siguientes elementos:
Entidades involucradas: Reclamación. Parámetros involucrados: número de siniestro. Validaciones a realizar: si número de siniestro es < > nulo… Acción a tomar: modificar tipo de reclamación como complementaria. Caso alterno: modificar tipo de reclamación como inicial.
Modelado de Objetos de Negocio Para crear el Modelo de Objeto del Negocio se deben utilizar los siguientes estereotipos:
Actor del Negocio. Trabajador del Negocio. Entidad del Negocio
Con estos tres estereotipos se puede desarrollar un Modelo de Objeto del Negocio. Este modelo identifica todos los “roles” y “cosas” en el negocio, los cuales son representados como clases en la Vista Lógica. Modelado de Procesos de Negocio Cuando un proceso es modelado, con ayuda de una representación gráfica, pueden apreciarse con facilidad las interrelaciones existentes entre distintas actividades, analizar cada actividad, definir los puntos de contacto con otros procesos, así como identificar los subprocesos comprendidos. Al mismo tiempo, los problemas existentes pueden ponerse de manifiesto claramente dando la oportunidad al inicio de acciones de mejora.
Modelado de Fines y Objetivos Metamodelo que define los elementos que integran un Plan de Negocios:
Facilita el desarrollo, comunicación y gestión de planes de negocio. Establece claras relaciones entre: Políticas de Negocios, Reglas de Negocio y Fines & medios de la empresa
Modelado de Sistemas de Negocio Se fundamenta en:
La noción de Sistema de Negocios (Montilva, 2002). El método EKD-CMM (Barrios & Nurcan, 2004). El Método WATCH (Montilva & Barrios, 2004)
Para desarrollo de software empresarial. Ha sido aplicado en más de 20 proyectos de Desarrollo de software empresarial, mejora y documentación de sistemas empresariales. [2]
1.2 Componentes del modelado de negocios 1. Propuesta de valor: “Es la mezcla de producto, calidad, precio, servicio y garantía que ofrece la organización a sus clientes” (Michael Porter). 2. Segmento de Mercado: Es un mercado al que está dirigido ya sea un producto o servicio. Los pasos para establecer mercados objetivos son: Segmentación de mercado. Selección del mercado objetivo. Posicionamiento del producto. 3. Segmento de no mercado: En un momento debe ser conocido y puede convertirse en cliente potencial creando mercados rivales, llegando a nuevos mercados. 4. Alianzas estratégicas: Uniones entre 2 o más organizaciones cuyo propósito es generar sociedades que fortalecen y generan competitividad. 5. Dialogo cliente (mercado con conversaciones): “Debido a que el cliente opina, critica, comenta, demanda y exige; es necesario que la empresa sepa lo que se dice de ella” (David Weinberger). 6. Servicio (antes, durante y después): Son los tipos de servicios que ofrecen antes, durante y después al consumidor. 7. Fidelización: Conservar al cliente o un determinado público hacia una marca. 8. Canales de distribución y presencialización: Medio a través del cual el fabricante pone a disposición del cliente su producto para ser adquirido generando una ventaja competitiva por la presencia dentro del mercado. 9. Recursos Clave (Procesos clave, arquitectura de valor, infraestructura): Se deben definir los procesos y recursos humanos clave, así como la infraestructura para la confección del modelo de negocio. 10. El retorno del valor (beneficio). PVe, PBe: Determina el beneficio mediante la propuesta de valor para el consumidor y el coste de propuesta del valor que se ofrece al cliente. 11. Efecto marca: El cliente adquiere el concepto marca atribuyendo a la promesa de placer que trae consigo. 12. El efecto plataforma: Son las plataformas empleadas por la empresa con la creación del modelo de negocios. [3]
1.3 Orientación del modelado de negocio Orientación al valor/cliente. El modelado de negocios se orienta a explicar cómo la empresa crea valor para el cliente: Qué valor los productos o servicios de una empresa les proporcionan a sus clientes. Actualmente los clientes buscan a quienes les den algún valor por su compra, para elegir un cliente toma en cuenta dos cosas: los beneficios que se obtienen al usar un producto o servicio y el precio que implica su consumo.
Orientación a la actividad/rol. Esta orientación hace énfasis en el modelado de los procesos y actores de la empresa, que actividades realiza la empresa y quienes participan en ellas. Este modelo puede ayudar a mejorar la productividad de la organización. [2]
1.4 BPMN en el modelado del negocio Modelar un Proceso de Negocio incluye la representación de cómo una empresa realiza los pasos necesarios para lograr sus objetivos centrales y, aunque los objetivos son la parte primordial de todo el modelado, no se capturan dentro del modelo, se sobreentiende que se modelan los pasos para poder llegar a ellos. Con BPMN sólo los procesos son modelados. Un proceso de negocio es un conjunto de actividades que representan flujo de trabajo e información. Los BPMN definen diagramas de Procesos de negocios en los cuales los elementos centrales son: Eventos, Nodos de decisión y las actividades. [4]
Capítulo 2: Metodologías de Desarrollo 2.1 Metodologías clásicas 2.1.1 Cascada El modelo en cascada sugiere un enfoque sistemático, secuencial, para el desarrollo del software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento. [5]
2.1.2 Incremental El modelo incremental combina elementos del modelo en cascada (aplicados repetidamente) con la filosofía interactiva de construcción de prototipos. El modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un <<incremento>> del software. Cuando se utiliza el modelo incremental, el primer incremento a menudo es un producto esencial. Es decir se afrontan requisitos básicos, pero muchas funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. [5]
2.1.3 Evolutivo El desarrollo evolutivo se basa en la idea de desarrollar una implementación inicial, exponiéndola a los comentarios u opiniones del usuario y refinándola a través de las diferentes versiones hasta que se desarrolla un sistema adecuado. Las actividades de especificación, desarrollo y validación se encuentran en vez de separarse, con una rápida retroalimentación entre éstas. Existen dos tipos de desarrollo evolutivo:
1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para explotar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente. 2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo. [6]
2.1.4 Espiral El modelo en espiral, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo en cascada. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras interacciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.
2.1.5 Prototipos El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentras y definen los objeticos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un <<diseño rápido>>. El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente. El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteración ocurre cuando el prototipo encuentra satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer. [5]
2.1.6 Desarrollo basado en componentes La ingeniería de software basada en componentes (CBSE) o desarrollo basado en componentes se basa en la reutilización de diseños o códigos similares a los que se necesitan para el proyecto en el que se traba actualmente. Este enfoque basado en la reutilización se compone de una gran base de componentes de software reutilizables y de algunos marcos de trabajo de integración para éstos. Algunas veces estos componentes son sistemas por sí mismos (Sistemas comerciales) que se pueden utilizar para proporcionar una funcionalidad específica, como dar formato al texto o efectuar cálculos numéricos. El desarrollo de software basado en componentes tiene la ventaja obvia de reducir la cantidad de software a desarrollarse y así reduce los costos y los riesgos. [6]
2.2 Otras Metodologías 2.2.1 Ganar-ganar El método ganar-ganar extiende el modelo espiral, haciendo énfasis en la identificación de las condiciones de ganancia para todas las partes, creando un plan para alcanzar las condiciones ganadoras y los riesgos correspondientes. Se establecen las reglas para definir el proceso de desarrollo del proyecto, tomando en cuenta todas las partes implicadas. El modelo no necesita mucho tiempo de gestión, lo que permite utilizarlo tanto en proyectos pequeños, como mayores. Se consideran cuatro ciclos, compuesto cada uno de cuatro actividades:
Elaborar los objetivos, restricciones y alternativas del proceso y producto del sistema y subsistema Evaluar las alternativas con respecto a los objetivos y restricciones. Identificar y resolver las fuentes principales de riesgo en el proceso y el producto. Elaborar la definición del producto y proceso. [7]
2.2.2 Proceso Unificado (UP) La metodología de UP es un método iterativo de diseño de software que describe cómo desarrollar software de forma eficaz, utilizando técnicas probadas en la industria. El Proceso Unificado de Desarrollo de Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura, enfocado en el riesgo, y por ser iterativo e incremental, esta metodología de Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. El Proceso Unificado describe el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. Es una metodología orientada a conducir el proceso de desarrollo de software en sus aspectos técnicos; los flujos y productos de trabajo de UP no incluyen la administración del proyecto. UP es una versión libre y abierta del modelo propuesto por Jacobson, Booch y Rumbaugh. [8]
2.2.3 Ingeniería Web La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en la World Wide Web (www). En este sentido, la ingeniería de la Web hace referencia a las metodologías, técnicas y herramientas que se utilizan en el desarrollo de aplicaciones Web complejas y de gran dimensión en las que se apoya la evaluación, diseño, desarrollo, implementación y evolución de dichas aplicaciones. Uno de los aspectos más tenidos en cuenta, en el desarrollo de sitios web es sin duda alguna el diseño gráfico y la organización estructural del contenido. En la actualidad la web está sufriendo
grandes cambios, que han obligado a expertos en el tema a utilizar herramientas y técnicas basadas en la ingeniería del software, para poder garantizar el buen funcionamiento y administración de los sitios web. [9] La ingeniería web Es el proceso utilizado para crear, implantar y mantener aplicaciones y sistemas Web de alta calidad. Ingeniería Web ofrece una solución de comercio electrónico a las empresas que han decidido comercializar y administrar sus productos a través de Internet mediante una tienda virtual y que además es la aplicación de metodologías sistemáticas, disciplinadas y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en la World Wide Web. [7]
2.2.4 Metodologías Ágiles Las metodologías ágiles dan más valor al individuo, a la colaboración con el cliente y al desarrollo incremental de software con iteraciones muy cortas, en esta metodología los requerimientos y soluciones evolucionan mediante la colaboración de grupos auto-organizados y multidisciplinarios. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en lapsos cortos. El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener una «demo» (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto. [10] [7]
2.2.5 Metodologías emergentes La metodología emergente permite adaptar la forma de trabajo a las condiciones del proyecto, se utiliza mayormente en desarrollo de productos con innovaciones importantes, y para sistemas de información empresarial. ICONIX se define como un proceso de desarrollo de software práctico. Está entre la complejidad de RUP y la simplicidad y pragmatismo de XP (Programación extrema o eXtreme Programming), sin eliminar las tareas de análisis y diseño que XP no contempla. ICONIX es un proceso simplificado en comparación con otros procesos más tradicionales, que unifica un conjunto de métodos de orientación a objetos con el objetivo de acabar todo el ciclo de vida de un proyecto. [11]
2.3 Reingeniería La reingeniería de software es una forma de modernización para mejorar las capacidades y/o la facilidad de mantenimiento de los sistemas de información heredados mediante la aplicación de tecnologías y prácticas modernas. La Reingeniería de Software ofrece una disciplina de preparación para migrar un sistema de información heredado hacia un sistema que pueda fácilmente evolucionar. El proceso aplica principios de ingeniería para un sistema existente para encontrar nuevos requerimientos. [7]
Capítulo 3: Arquitecturas de Software 3.1 Descomposición modular El principal objetivo de la descomposición modula es de componer los problemas difíciles en problemas sencillos de tal manera sería más eficiente el desarrollo del sistema. La descomposición modular se enfoca en reutilizar código, además debido a esta descomposición cada módulo es desarrollado con un fin específico, de esta manera los futuros programadores comprenderán fácilmente la función de cada módulo. Las características de los módulos son:
Tamaño pequeño Independencia modular Abstracción Encapsulamiento
Mientras que los objetivos de la Descomposición Modular son:
Descomponer los problemas complejos en problemas más sencillos Reutilizar el código Facilitar la lectura de los programa
El diseño modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. Las ventajas serían: la claridad, reducción de costos y reutilización. [12]
3.2 Patrones de diseño Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias. La categoría de patrones según la escala o nivel de abstracción serían:
Patrones de arquitectura: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas de software. Patrones de diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas de software. Dialectos: Patrones de bajo nivel específicos para un lenguaje de programación o entorno concreto. [12]
3.3 Arquitectura de dominio específico Al igual que los modelos generales, también pueden usarse los modelos arquitectónicos que son específicos para un dominio particular de aplicación. Si bien las instancias de estos sistemas difieren
en los detalles, la estructura arquitectónica común puede realizarse cuando se desarrollan nuevos sistemas. Para el desarrollo de software existen diversas arquitecturas de dominio específico. Que serían: Diseño de software de arquitectura multiprocesador, diseño de software distribuido, diseño de software distribuido en tiempo real y diseño de software cliente/servidor Existen dos modelos de dominio específico: 1. Modelos genéricos que son abstracciones de varios sistemas reales. 2. Modelos de referencia que son modelos abstractos y describen a una clase mayor de sistemas. Modelo genérico: flujo de datos de un compilador Modelo de Referencia: La arquitectura OSI. [12]
3.4 Diseño de software de arquitectura multiprocesador Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma concurrente, la razón es porque actualmente la mayoría de las CPU’s sólo pueden ejecutar un proceso cada vez. La única forma de que se ejecuten de forma simultánea varios procesos es tener varias CPU’s (ya sea en una máquina o en varias, en un sistema distribuido. Los objetivos de la programación paralela, son:
Reducir el tiempo de cómputo. Reducir la complejidad del algoritmo, Aprovechar al máximo la capacidad de las computadoras multiproceso.
La programación multihilo es la que permite a una aplicación realizar varias tareas concurrentemente. Los distintos hilos que se ejecutan comparten una serie de recursos. [12]
3.5 Diseño de software de arquitectura Cliente - Servidor Es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, quien le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras. En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores. [13]
3.6 Diseño de software de arquitectura distribuida Diseñar un sistema distribuido es crear aplicaciones de software que, utilizando servicios y ayudándose de la conectividad, participen y se integren en este entorno de forma transparente a las plataformas de proceso y de almacenamiento de datos, dotándolas de los recursos necesarios para gestionarse de forma integrada con el resto del sistema distribuido.
Los sistemas distribuidos que se diseñen y construyan deben estar alineados con los objetivos de negocio de la empresa, aumentar la eficacia y eficiencia operacional de la compañía y permitir el mayor rendimiento con el menor coste en las estructuras informáticas que dan soporte. [13]
3.7 Diseño de software de arquitectura de tiempo real El software de tiempo real está muy acoplado con el mundo externo, esto es, el software de tiempo real debe responder al ámbito del problema en un tiempo dictado por el ámbito del problema. Debido a que el software de tiempo real debe operar bajo restricciones de rendimiento muy rigurosas, el diseño del software esta conducido frecuentemente, tanto por la arquitectura del hardware como por la del software, por las características del sistema operativo, por los requisitos de la aplicación y tanto por los extras del lenguaje de programación como prospectos de diseño. [13]
Capítulo 4: Seguridad en Ingeniería de Software 4.1 Seguridad de software La seguridad de software es una actividad de garantía de la calidad del software que se centra en la identificación y evaluación de los riesgos potenciales que pueden tener lugar a un impacto negativo en el software y hacer que falle el sistema completo. Si se pueden identificar pronto los riesgos en el proceso de ingeniería del software podrán especificarse las características del diseño del software que permitan eliminar o controlar los riesgos potenciales. [5]
4.2 Seguridad en el ciclo de desarrollo del software La seguridad en el ciclo de desarrollo del software es muy importante debido a que implementar la seguridad desde el inicio del proyecto de software evitaría en gran parte perdidas tanto de costos como de tiempos. Al implementar la seguridad desde la fase de análisis en el desarrollo del proyecto de software se ayuda a prevenir fallas y vulnerabilidades en el software, esto analizando el tipo de información que se manejará así como el acceso a ésta, de esta manera. En la fase de diseño esto será más visible implementarlo, de tal manera que se podrá diseñar la autorización de los usuarios para cada tipo de solicitud (roles, permisos, privilegios, etc.), el diseño de mensajes de advertencia y errores para evitar suministrar mucha información e impedir futuros ataques. Al momento de codificar el software se debe revisar la seguridad contra errores, de tipo de desbordamiento de buffer, inicio de sesión, o funcionalidades de la aplicación (errores que afecten la funcionalidad del sistema como un mal cálculo en una factura). En esta etapa es necesario y de vital importancia la revisión de los valores de entradas y salidas, esto para evitar futuras fallas. En la etapa de pruebas, se deberán hacer las pruebas que se basen en probar la aplicación con escenarios no planificados (Es decir probar algo que se espera la aplicación no realice y evitar que el software realice tareas que no debería).
En la etapa de implementación se debe revisar que las configuraciones que se requieran sean realizadas, de tal manera que el software no tenga vulnerabilidades. [14]
4.3 Confiabilidad del software La confiabilidad de software significa que un programa particular debe de seguir funcionando en la presencia de errores. Los errores pueden ser relacionados al diseño, a la implementación, a la programación, o el uso de errores. Así como los sistemas llegan a ser cada vez más complejos, aumenta la probabilidad de errores. Aunque casi todo el software tenga errores, la mayoría de los errores nunca serán revelados debajo de circunstancias normales. Un atacante busca esta debilidad para atacar un sistema. Un software es confiable cuando realiza lo que el usuario desea, cuando así lo requiera, deja de ser confiable en el momento en el que deja de hacerlo, en otras palabras aunque muy simples deja de ser confiable cuando falla, estas fallas se deben a errores en el software, si se logran corregir esos errores sin introducir nuevos se mejorará la confiabilidad del software. [15, 16]
4.4 Ingeniería de Seguridad La Ingeniería de la seguridad es una rama de la ingeniería, que usa todo tipo de ciencias para desarrollar los procesos y diseños en cuanto a las características de seguridad, controles y sistemas de seguridad. La principal motivación de esta ingeniería ha de ser el dar soporte de tal manera que impidan comportamientos malintencionados. El campo de esta ingeniería puede ser muy amplio, podría desarrollarse en muchas técnicas:
Equipos: Como el diseño de cerraduras, cámaras, sensores, etc. Procesos: políticas de control, procedimientos de acceso, etc. Informático: control de passwords, criptografía, etc. [15]
Conclusiones Los temas de la materia de ingeniería de software, realmente se me hacen muy importantes para un mejor desarrollo y sobre todo para una buena planificación de un proyecto de software. Los temas que más me llaman la atención son aquellos referentes a las arquitecturas de software porque me llama la atención cada una cómo funcionan para la búsqueda de soluciones de un problema al cual se aplique el desarrollo de un software. Otro tema que me interesa es el de seguridad debido a que se podría decir es la rama principal para llegar a la calidad del software, ya que ayuda a prevenir errores y vulnerabilidades incluso desde antes de empezar a crear las líneas de código del software porque la seguridad se empieza a ver desde que se levantan los requisitos con el cliente y durante la etapa de análisis. Referente a otros temas que me gustaría tocar, sería el de conocer algunas medidas para sacar un presupuesto de un software así como el de verificar cuales con las condiciones de ambiente gráfico recomendadas (que se debería y no hacer en base a las solicitudes del cliente) de tal manera que se pueda optimizar el software para su entrega final con la menor cantidad de errores (ocultando de
manera automática los que puedan surgir sin afectar el funcionamiento software final) y que satisfaga las necesidades del cliente.
Referencias [1] [En línea]. Available: https://educacioningesoftware.wordpress.com/libre/. [Último acceso: 29 Enero 2016]. [2] S. A. Martinez García, «Ingenieria en Software,» 11 Mayo 2015. [En línea]. Available: http://mapachessistec.blogspot.mx/search?updated-min=2015-01-01T00:00:0008:00&updated-max=2016-01-01T00:00:00-08:00&max-results=41. [Último acceso: Enero 29 2016]. [3] H. Cuevas, «Prezi: Unidad 1: Modelado de Negocios,» 04 Febrero 2014. [En línea]. Available: https://prezi.com/sz5v1t-s8l4q/unidad-1-modelado-de-negocios/. [Último acceso: 29 Enero 2016]. [4] ESAD, «Academia: Modelado de negocios Modelado de negocios,» [En línea]. Available: http://www.academia.edu/5885058/Modelado_de_negocios_Modelado_de_negocios. [Último acceso: 29 Enero 2016]. [5] R. S. Pressman, Ingeniería del Software - Un enfoque práctico, Madrid, España: McGraw Hill, 2002. [6] I. Sommerville, Ingeniería del Software, Madrid, España: PEARSON EDUCACIÓN, S. A., 2005. [7] J. L. Vite, «Ingeniería del Software,» 18 Marzo 2013. [En línea]. Available: http://ithuejutlajoseluisvite.blogspot.mx/. [Último acceso: 2016 Enero 29]. [8] D. A. Loaiza, «Ingeniería de Sofware,» 12 Julio 2012. [En línea]. Available: http://pnfiingenieriadesoftwaregrupocuatro.blogspot.mx/2012/07/proceso-unificadoproceso-unificado-de.html. [Último acceso: 29 Enero 2016]. [9] J. I. Villa Barajas, «jose ivan villa barajas,» 15 Abril 2013. [En línea]. Available: http://ingenieriaweb2584.blogspot.mx/2013/04/metodologia-ingenieria-web.html. [Último acceso: 29 Enero 2016]. [10] Grupo ISSI, «Metodologías Ágiles en el Desarrollo de Software,» de Metodologías Ágiles en el Desarrollo de Software, Alicante, España, 2003. [11] J. A. Noya Fragoso y L. A. Olivares Hernandez, «Prezi,» 30 Septiembre 2013. [En línea]. Available: https://prezi.com/ubk9cni-o1os/metodologia-emergente/. [Último acceso: 29 Enero 2016].
[12] R. Agustín Hernandéz, «UNIDAD III ARQUITECTURA DE SOFTWARE,» 03 Mayo 2013. [En línea]. Available: http://ithroshuejutla.blogspot.mx/. [Último acceso: 29 Enero 2016]. [13] H. Hernández Martínez, «UNIDAD III Arquitecturas de software,» 02 Mayo 2013. [En línea]. Available: http://humbertoith.blogspot.mx/2013/05/unidad-3-arquitecturas-de-software3.html. [Último acceso: 29 Enero 2016]. [14] H. A. Therán Martínez, «Prezi,» 14 Octubre 2012. [En línea]. Available: https://prezi.com/gu9iod4v-qkz/seguridad-en-el-ciclo-de-vida-de-desarrollo-de-software/. [Último acceso: 29 Enero 2016]. [15] M. García, «UNIDAD 4 - SEGURIDAD EN INGENIERIA DE SOFTWARE,» 10 Junio 2013. [En línea]. Available: http://magdalyithunid4.blogspot.mx/. [Último acceso: 29 Enero 2016]. [16] J. L. Roca, IEEE, UNR, FCEIA, EIE, UNR, [En línea]. Available: http://ieee.eie.fceia.unr.edu.ar/PDF_SOFTWARE.pdf. [Último acceso: 2016 Enero 31].