{"id":225,"date":"2020-01-31T14:56:03","date_gmt":"2020-01-31T20:56:03","guid":{"rendered":"https:\/\/www.imds.org.mx\/blog\/?p=225"},"modified":"2020-01-31T14:56:05","modified_gmt":"2020-01-31T20:56:05","slug":"fases-del-proceso-de-desarrollo-de-software","status":"publish","type":"post","link":"https:\/\/www.imds.org.mx\/blog\/fases-del-proceso-de-desarrollo-de-software\/","title":{"rendered":"Fases del proceso de desarrollo de software"},"content":{"rendered":"\n

An\u00e1lisis de requisitos<\/strong><\/p>\n\n\n\n

Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingenier\u00eda de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del an\u00e1lisis de requisitos con el cliente se plasma en el documento ERS, Especificaci\u00f3n de Requerimientos del Sistema, cuya estructura puede venir definida por varios est\u00e1ndares, tales como CMM-I. Asimismo, se define un diagrama de Entidad\/Relaci\u00f3n, en el que se plasman las principales entidades que participar\u00e1n en el desarrollo del software. La captura, an\u00e1lisis y especificaci\u00f3n de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque a\u00fan no est\u00e1 formalizada, ya se habla de la Ingenier\u00eda de Requisitos. La IEEE Std. 830-1998 normaliza la creaci\u00f3n de las Especificaciones de Requisitos Software (Software Requirements Specification).<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Dise\u00f1o y arquitectura<\/strong><\/p>\n\n\n\n

Se refiere a determinar c\u00f3mo funcionar\u00e1 de forma general sin\nentrar en detalles. Consiste en incorporar consideraciones de la implementaci\u00f3n\ntecnol\u00f3gica, como el hardware, la red, etc. Se definen los casos de uso para\ncubrir las funciones que realizar\u00e1 el sistema, y se transforman las entidades\ndefinidas en el an\u00e1lisis de requisitos en clases de dise\u00f1o, obteniendo un\nmodelo cercano a la programaci\u00f3n orientada a objetos.<\/p>\n\n\n\n

Programaci\u00f3n<\/strong><\/p>\n\n\n\n

Reducir un dise\u00f1o a c\u00f3digo puede ser la parte m\u00e1s obvia del trabajo de ingenier\u00eda de software, pero no es necesariamente la porci\u00f3n m\u00e1s larga. La complejidad y la duraci\u00f3n de esta etapa est\u00e1 \u00edntimamente ligada al o a los lenguajes de programaci\u00f3n utilizados.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Pruebas<\/strong><\/p>\n\n\n\n

Consiste en comprobar que el software realice correctamente\nlas tareas indicadas en la especificaci\u00f3n. Una t\u00e9cnica de prueba es probar por\nseparado cada m\u00f3dulo del software, y luego probarlo de forma integral, para as\u00ed\nllegar al objetivo. Se considera una buena pr\u00e1ctica el que las pruebas sean\nefectuadas por alguien distinto al desarrollador que la program\u00f3, idealmente un\n\u00e1rea de pruebas; sin perjuicio de lo anterior el programador debe hacer sus\npropias pruebas. En general hay dos grandes formas de organizar un \u00e1rea de\npruebas, la primera es que est\u00e9 compuesta por personal inexperto y que\ndesconozca el tema de pruebas, de esta forma se eval\u00faa que la\ndocumentaci\u00f3n]entregada sea de calidad, que los procesos descritos son tan\nclaros que cualquiera puede entenderlos y el software hace las cosas tal y como\nest\u00e1n descritas. El segundo enfoque es tener un \u00e1rea de pruebas conformada por\nprogramadores con experiencia, personas que saben sin mayores indicaciones en\nque condiciones puede fallar una aplicaci\u00f3n y que pueden poner atenci\u00f3n en\ndetalles que personal inexperto no considerar\u00eda.<\/p>\n\n\n\n

Documentaci\u00f3n<\/strong><\/p>\n\n\n\n

Todo lo concerniente a la documentaci\u00f3n del propio desarrollo del software y de la gesti\u00f3n del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales t\u00e9cnicos, etc; todo con el prop\u00f3sito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Mantenimiento<\/strong><\/p>\n\n\n\n

Mantener y mejorar el software para enfrentar errores\ndescubiertos y nuevos requisitos. Esto puede llevar m\u00e1s tiempo incluso que el\ndesarrollo inicial del software. Alrededor de 2\/3 de toda la ingenier\u00eda de\nsoftware tiene que ver con dar mantenimiento. Una peque\u00f1a parte de este trabajo\nconsiste en arreglar errores, o bugs. La mayor parte consiste en extender el\nsistema para hacer nuevas cosas. De manera similar, alrededor de 2\/3 de toda la\nIngenier\u00eda civil, Arquitectura y trabajo de construcci\u00f3n es dar mantenimiento.<\/p>\n\n\n\n

Se puede decir que con la mejora continua garantiza la\ncalidad del producto, ya que el estarla aplicando d\u00eda con d\u00eda es la mejor\ndecisi\u00f3n que puede llegar a tener cualquier empresa, porque de esta manera\nevita grandes problemas en la elaboraci\u00f3n o desarrollo de los productos. Esto\nes fundamental para todas las empresas ya que se vuelven competitivas, con\nmayor productividad y eficiencia. No hay que olvidar que la mejora se da porque\nel cliente es el rey y hay que satisfacer todas y cada una de sus necesidades\nsiempre garantizando la calidad.<\/p>\n","protected":false},"excerpt":{"rendered":"

An\u00e1lisis de requisitos Extraer los requisitos de un producto de software es la primera etapa…<\/p>\n","protected":false},"author":1,"featured_media":229,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[5],"tags":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.imds.org.mx\/blog\/wp-json\/wp\/v2\/posts\/225"}],"collection":[{"href":"https:\/\/www.imds.org.mx\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.imds.org.mx\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.imds.org.mx\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.imds.org.mx\/blog\/wp-json\/wp\/v2\/comments?post=225"}],"version-history":[{"count":1,"href":"https:\/\/www.imds.org.mx\/blog\/wp-json\/wp\/v2\/posts\/225\/revisions"}],"predecessor-version":[{"id":230,"href":"https:\/\/www.imds.org.mx\/blog\/wp-json\/wp\/v2\/posts\/225\/revisions\/230"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.imds.org.mx\/blog\/wp-json\/wp\/v2\/media\/229"}],"wp:attachment":[{"href":"https:\/\/www.imds.org.mx\/blog\/wp-json\/wp\/v2\/media?parent=225"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.imds.org.mx\/blog\/wp-json\/wp\/v2\/categories?post=225"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.imds.org.mx\/blog\/wp-json\/wp\/v2\/tags?post=225"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}