{"id":748,"date":"2020-06-07T05:55:18","date_gmt":"2020-06-07T05:55:18","guid":{"rendered":"https:\/\/ingenieriadesoftware.es\/?p=748"},"modified":"2020-06-07T05:58:29","modified_gmt":"2020-06-07T05:58:29","slug":"relacion-coste-tiempo-alcance-calidad-proyectos-software","status":"publish","type":"post","link":"https:\/\/ingenieriadesoftware.es\/relacion-coste-tiempo-alcance-calidad-proyectos-software\/","title":{"rendered":"Relaci\u00f3n entre el coste, tiempo, alcance y calidad en proyectos de desarrollo software"},"content":{"rendered":"<p>En esta vida no puedes tenerlo todo. Lo mismo pasa en el desarrollo de software. No se pueden tener todas las funcionalidades que quieras, muy r\u00e1pidamente y casi sin coste y encima esperar que el programa funcione.<\/p>\n<p>Esta dicotom\u00eda se conoce como el <a href=\"https:\/\/en.wikipedia.org\/wiki\/Project_management_triangle\" target=\"_blank\" rel=\"noopener noreferrer\">tri\u00e1ngulo de la gesti\u00f3n de proyectos<\/a>. Esta simple figura ilustra muy bien dos condicionantes que conviene tener muy presentes al empezar cualquier desarrollo software:<\/p>\n<ol>\n<li>La calidad del software depende del alcance (<em>scope<\/em> en ingl\u00e9s) del proyecto, su presupuesto y los plazos (<em>deadline<\/em>) del desarrollo<\/li>\n<li>Puedes buscar un equilibrio entre las diferentes restricciones. Teniendo en cuenta que cualquier cambio en una de ellas obliga a ajustar las otras para compensar si no quieres que la calidad se vea afectada.<\/li>\n<\/ol>\n<div style=\"width: 393px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"\" src=\"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/8\/88\/Project-triangle-en.svg\/1024px-Project-triangle-en.svg.png\" alt=\"Triangulo de la gesti\u00f3n de proyectos software\" width=\"383\" height=\"321\" \/><p class=\"wp-caption-text\">El tri\u00e1ngulo que conviene tener siempre presente en toda gesti\u00f3n de proyectos software<\/p><\/div>\n<p>Por ejemplo, si el tiempo es la restricci\u00f3n m\u00e1s importante, puedes acelerar el proyecto reduciendo el n\u00famero de funcionalidades del proyecto o incrementando el presupuesto (hasta cierto punto, recordad las <a href=\"https:\/\/ingenieriadesoftware.es\/leyes-fundamentales-desarrollo-software\/\" target=\"_blank\" rel=\"noopener noreferrer\">leyes fundamentales de la programaci\u00f3n<\/a>, hay un momento que a\u00f1adir m\u00e1s gente no acelera el proyecto). Si necesitas muchas funcionalidades entonces el software ser\u00e1 m\u00e1s caro y necesitar\u00e1 m\u00e1s tiempo para completarse.<\/p>\n<p>La verdad es que a m\u00ed me parece muy de sentido com\u00fan pero, \u00a1la de veces que hemos visto proyectos totalmente irreales!. Muchas veces porque la persona que tiene que &#8220;vender&#8221; el proyecto al cliente no es que lo tiene que desarrollar despu\u00e9s con lo que va a aceptar plazos y costes imposibles de cumplir si consigue cerrar la venta. Todo el qu\u00e9 ha trabajado en grandes consultoras sabe de lo que hablo \ud83d\ude42<\/p>\n<p>Y en esos casos pues pasa lo que pasa:<\/p>\n<p><iframe loading=\"lazy\" title=\"SPEED CHALLENGE: 10 Minutes | 1 Minute | 10 Seconds - Drawing Spiderman\" src=\"https:\/\/player.vimeo.com\/video\/226508728?dnt=1&amp;app_id=122963\" width=\"1080\" height=\"608\" frameborder=\"0\" allow=\"autoplay; fullscreen\" allowfullscreen><\/iframe><\/p>\n<p>o este otro ejemplo:<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"550\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Client: I want you to develop this application<br \/>Dev: Give me 2 weeks<br \/>Client: No, I want this for tomorrow.<br \/>Dev: Okay, you decide&#8230; about the result. <a href=\"https:\/\/t.co\/kacPerpWcq\" target=\"_blank\">pic.twitter.com\/kacPerpWcq<\/a><\/p>\n<p>&mdash; Fr\u00e9d\u00e9ric B????uchery (@FredBouchery) <a href=\"https:\/\/twitter.com\/FredBouchery\/status\/948903120956018688?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener\">January 4, 2018<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Hay modelos m\u00e1s complejos y variaciones de este tri\u00e1ngulo (ej, el modelo estrella con dos tri\u00e1ngulos superpuestos del <a href=\"https:\/\/en.wikipedia.org\/wiki\/Project_Management_Body_of_Knowledge\" target=\"_blank\" rel=\"noopener noreferrer\">PMBOK<\/a>) pero si tenemos \u00e9ste claro ya conseguiremos mejorar la gran mayor\u00eda de problemas en el desarrollo de software.<\/p>\n<p>Un problema relacionado (pero que ya dejamos para otro d\u00eda) es que a\u00fan cuando queremos hacerlo bien, somos muy malos estimando la complejidad de un proyecto, normalmente subestim\u00e1ndola. Por ejemplo, en mis tiempos de programador, recuerdo que cuando me tocaba estimar la complejidad (en tiempo) de nuevas funcionalidades a a\u00f1adir al sistema interno que est\u00e1bamos desarrollando, lo hac\u00eda lo mejor que pod\u00eda y al final siempre multiplicaba el resultado por dos. A mi me funcionaba aunque no tiene ning\u00fan fundamento cient\u00edfico. La explicaci\u00f3n intuitiva (\u00a1a la que llegu\u00e9 <em>a posteriori<\/em>!) era que mi estimaci\u00f3n inicial no ten\u00eda en cuenta el n\u00famero de interrupciones y &#8220;fuegos&#8221; que tendr\u00eda durante el desarrollo de la funcionalidad con lo que necesitaba un margen para acomodar ese tiempo perdido.<\/p>\n<p><em>Imagen de cabecera por <a href=\"https:\/\/unsplash.com\/@joszczepanska?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText\" target=\"_blank\" rel=\"noopener\">Jo Szczepanska<\/a>\u00a0on\u00a0<a href=\"https:\/\/unsplash.com\/s\/photos\/project-management?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText\" target=\"_blank\" rel=\"noopener\">Unsplash<\/a><\/em><\/p>\n<span class=\"et_bloom_bottom_trigger\"><\/span>","protected":false},"excerpt":{"rendered":"<p>No se puede tener toda en la vida. Y tampoco en el desarrollo de software. Este tri\u00e1ngulo define el equilibro necesario entre el coste, tiempo, alcance y calidad de un proyecto. <\/p>\n","protected":false},"author":2,"featured_media":750,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[10],"tags":[324,18,323,66,67],"hashtags":[],"_links":{"self":[{"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/posts\/748"}],"collection":[{"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/comments?post=748"}],"version-history":[{"count":0,"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/posts\/748\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/media\/750"}],"wp:attachment":[{"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/media?parent=748"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/categories?post=748"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/tags?post=748"},{"taxonomy":"hashtags","embeddable":true,"href":"https:\/\/ingenieriadesoftware.es\/wp-json\/wp\/v2\/hashtags?post=748"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}