Ha sido de agradecer la participación de Carlos Rebate, en el congreso que prometía ser tan “tostón” como nos acostumbran congresos de este tipo, pero Carlos nos ha deleitado con su brillantes ideas y su original puesta en escena (me imagino que la publicarán en ).

Al fin, encuentro alguien que plantea ideas que en este blog y en reuniones he defendido, la terminología Factorías/Fábricas de Software (Software Factories) no representa ni de lejos la esencia ni la problemática del desarrollo software, más cercano según mi opinión a la Construcción de Software, por buscar símiles que representan mejor todos los aspectos del desarrollo y gestión de un proyecto software (ver La Arquitectura como referencia de la construcción de software ).

+

Ha metido el “dedo en la llaga” de un problema surgido estos últimos años, desde que han aparecido herramientas y piezas de “lego” para construir los edificios software que nos piden los clientes, a  los ingenieros software (Aparejadores/Arquitectos) seguimos tratándoles como programadores (albañiles), con lo que se ha creado un problema grave en las empresas (costes muy elevados para el trabajo que les ofrecemos) y una insatisfacción en los ingenieros que les lleva a un callejón sin salida.

Carlos nos ha propuesto un camino a seguir, basado en la Puesta en Valor, en contraposición con el bajo coste, para que España realmente sea un destino del nearshore.  Propuesta, que apoyándose en los avances conseguidos por las Factorías de Software, se de un salto cualitativo, buscando nuevos horizontes basados en la innovación.  Camino que que no sólo mejoraría el mercado del software de cara al exterior, sino que solucionaría problemas como el de sus trabajadores.

As software permeates every aspect of daily life and as we depend more and more on software in all walks of life, quality of software gets to be of utmost importance.

World has come a long way from the early perceptions of quality as a natural consequence of following a good process. Agile community has asserted umpteen times, reflecting in manifesto of software craftsmanship and agile manifesto, quality of software that add value to users in their context is far more importance than religious, and often dogmatic, adherence to process.

People, process and automation are three different, orthogonal but often inseparably interrelated, factors of what goes into making of a quality software. These form different dimensions that call for attention of a manager of software development project, and not conflicting goals as they are sometime made out to be. Managing software development project is not progressing on one dimension at the cost of another but working with a dynamic balancing of these dimensions through the course of project

Three dimensions of software quality

It is interesting to note, in this context, emergence of a consortium focused on software quality. It is a step in the right direction. I hope that this would help in making life better for its users and customers

Brief: Desarrollo de aplicación a medida para el control y comercialización de vehículos.

Sector de la Empresa:

Automoción

Caso

Ford INCA y Ford Polígono necesitaban coordinar los diferentes puntos de venta y controlar su stock de automóviles para mejorar el rendimiento comercial de la empresa.

Solución

eConcept Consulting ha desarrollado una aplicación a medida para Ford que le permite el control de su stock de vehículos, la comercialización a través de internet y de los diferentes puntos de venta y la coordinación del equipo comercial.

COAATMCA

Brief: desarrollo de aplicación a medida para el control de obras y seguros decenales.

Sector de la Empresa

Colegio Oficial de Aparejadores y Arquitectos Técnicos de Mallorca.

Caso

COAATMCA no disponía de un sistema automatizado para el control de obras, lo que en ocasiones generaba dificultades para que los arquitectos pudieran seguir el estado de la obra.

Solución

eConcept ha desarrollado una aplicación web que permite el control de toda la vida de una obra, facilitando su seguimiento  por parte de los arquitectos y la gestión administrativa de la obra.

En eConcept Consulting creamos nuestro propio software basándonos en la tecnología .NET, ofreciendo soluciones de gestión adaptadas a las necesidades y características de la empresa.

Con la categoría Construcción Software incluiré todos los post acerca de las similitudes y aprendizajes que se puedan obtener de la disciplina de la Arquitectura y Construcción.

Es obvio que el software y la informática en general es muy joven, y que estamos teniendo los problemas propios de una disciplina que está naciendo: procesos sin madurar, falta de estándares de calidad, proyectos imprevisibles, productos de baja calidad,…  Nos surgen las dudas propias de la juventud, vamos por el buen camino? estamos haciendo las cosas bien? hacia dónde nos dirigimos.  Creo que es importante tener un punto de referencia, que nos ayude a encontrar mejores soluciones y situarnos un poco en nuestras dudas de futuro.  Creo que la Construcción es una disciplina que nos puede ayudar, por algunas de sus similitudes y porque siempre que hay que poner algún ejemplo de la complejidad de un proyecto software nos ayuda mucho.

Jacobson, Booch, Rumbaugh en su libro El proceso unificado del desarrollo de software para explicar el concepto de  “proceso centrado en la arquitectura“  utilizan la construcción del garaje, de un edificio para visualizar el concepto de arquitectura dentro del desarrollo software.

Más referencias, El software se parece mucho a una pirámide… ejemplo que nos sitúa fielmente en el tiempo, procesos, gestión, ineficiencia, …, del Desarrollo Software.

Si tienes cualquier ejemplo o idea, por favor, escribe tu comentario o envíame un correo.

Often Software Factory and Model Driven Architecture as two orthogonal approaches.

For me, both are two different perspectives of software product engineering. Abstract and concrete modeling and transformation, and production at a software factory as dictated by production process dictated by architecture go hand-in-hand to make a successful product line

We, at Astra Infotech, enable the merge with our Ready for IBM Rational Software Astra Model Creator and Astra Test Automat

Development of quality software requires a rigorous software architecting and design effort, and development strictly controlled by defined architecture and design. Astra Infotech’s solution Astra Model Creator supporting model driven development is now ‘Ready for Rational Software’

A cada dia as pesquisas acerca de Fábricas de Software vêm se intensificando, especialmente devido ao crescimento desta atividade no cenário mundial. Fábricas da Índia e China se tornaram referência de qualidade e sucesso, fazendo com que países como o Brasil viessem a perseguir um modelo semelhante que pudesse gerir a operação de múltiplas demandas. Diante de um mercado exigente e extremamente dinâmico, no qual o equilíbrio ideal entre custo e qualidade dita o sucesso no mundo dos negócios, a produtividade passou a ser um aspecto fundamental para a sobrevivência de qualquer organização. Porém, para atingir este padrão, deve-se estar ciente que fatores como processos, padrões de qualidade e frameworks de soluções fabris interferem diretamente no resultado final. Neste contexto, este trabalho técnico-científico apresenta um estudo deste modelo de produção de software, realizando a revisão de literatura da estrutura e de três modelos fundamentais para a sua implantação: RUP – processo unificado, CMMI e o PMBOK. Assim, ele discutirá as características envolvidas e gerará uma proposta de operação de software mais efetiva em termos de custo, agregação de valor ao negócio, qualidade, previsibilidade do atendimento e eficácia na solução de problemas, ou seja, mostrará um modelo que condense os fatores relevantes do estudo, através de um mapeamento dos principais processos existentes para o funcionamento de uma fábrica de software.

Para obter a versão completa deste trabalho CLIQUE AQUI e AQUI TAMBÉM .

Day by day the research concerning Software Factories has increased, especially due to recent term growth in the worldwide scene. Indian and Chinese Factories had become quality and success reference, making countries like Brazil came to pursue a similar model that it has been able to manage multiple discussion operations. Operating an exigent and extremely dynamic market which the ideal balance between costs and quality impose the success at business world, the productivity has started to be a basic aspect for any organization survival. However, to reach this standard, it must be clear factors as processes, quality standards and manufacture solutions frameworks intervene directly with the final result. From this point of view, this technician-scientific paper presents a study of this software production model, making a literature revision of the structure and three basic models for its implantation: RUP – unified process, CMMI and PMBOK. Thus, it´s going to discuss about involved characteristics and make a more effective software operation pondering cost, business value increasing, quality, support forecasting and efficacy problem solutions, or better, it´s going to show a model which condenses the main parts of three models study; through mapping of the main software processes existents in software factories operation.

Download the complete version: CLICK HERE and HERE TOO .

In my opinion, distressed managers and business-owners have been fantasising that software development is a manufacturing process at heart. Software requirements specifications are churned, and software architects turn these complicated specifications into a high-level technical vision. Software designers charge up the architecture with detailed design documentation, which is handed to zombie robot-like coders, who drinks isotonic water in one hand while sleepily typing in the software design’s implementation with the other. Finally, Inspector Quality receives the completed code, which doesn’t receive his stamp of approval unless it meets the original specifications.

It’s no surprise that managers want software development to be like manufacturing. Managers understand how to make manufacturing process work. Programmers have decades of experience in how to build physical objects efficiently and accurately. So, applying what they’ve learned from manufacturing, they should be able to optimize the software development process into the well-tuned engine that their manufacturing plants have become.

In the so-called software churning factory, the employees are the specialists. They sit faithfully at their place in the assembly line, fastening plain old Java components together. Inspector Quality is a tester by trade, software components move down the line, and he tests and stamps them in the same way each day. J2EE designers design J2EE applications. C++ coders code in C++. The world is very clean and compartmentalized.

Unfortunately, the manufacturing analogy doesn’t work here. Software is at least as malleable as software requirements. Things always change in business, and businesspeople know that software is soft and can be changed to meet those requirements. This means architecture, designs, codes, and tests must all be created and revised in a fashion more agile than the leanest manufacturing processes can provide.

In this kind of rapidly changing environment, the flexible will survive. When the pressure is on, a smart businessperson will turn to a software professional who can solve the problem at hand. So, how do you become that person whose name comes up when they’re looking for a superhero to save the day? The key is to be able to solve the problems that may arise. What are those problems? That’s right: you don’t know. Neither do I.

What I do understand is that those issues are as diverse as deployment problems, critical design flaws that need to be solved and quickly reimplemented, heterogenous systems integration, and rapid, adhoc report generation. Faced with a problem set as diverse as this, poor Inspector Quality would be passed over pretty quickly.

En la actualidad existen  cientos de Software Factory que no tienen prácticas definidas en casi ninguna área de procesos y aún sin definir puntos de control formalistas como lo demandan los procesos más conocidos (existen muchos y variados), realizan actividades que son las que en escencia la definen como una Software Factory.

Conocen de requerimientos, análisis y diseño, implementación y testing, tienen definidos sus objetivos para cada proyecto y trabajan contra un “end line”, con un presupuesto limitado, con recursos asignados y todo esto se gestiona de alguna manera, aunque no está claro como. El no tener claro “el como” o ser variable de un proyecto a otro, puede considerarse como un proceso indefinido.

Estoy de acuerdo que cualquier empresa que trabaja con algún tipo de organización funcional, tiene un proceso que le permite llegar desde un principio hasta un fin. Esta organización funcional no define necesariamente a un proceso.

Sin embargo no podemos excluir a estas empresas del rubro software factory por el de no tener prácticas moderadas. Inclusive las podemos criticar y comparar pero no podemos ponderar en forma generalizada el grado de éxito o fracaso que estas entidades tienen.
Puedo afirmar que existen organizaciones pequeñas que no conocen los verdaderos preceptos de calidad (la gran mayoría) y ni siquiera están interezados en los procedimientos formales de verificación, ni en documentación ni en el testing tradicional, ni en métricas y para cada proyecto varía el método de trabajo, el modo de comprobación y sus certificación internas y externas.

Y aún sin definiciones formales logran entregar sus productos en muy buenos términos, pero con aspectos pocos deseados como son:

• resultados poco predecibles
• resultados poco repetitivos
• alto desgaste de los recursos
• métricas endebles o inexistentes
• calidad dudosa o no garantizada

Nuevamente me pregunto: ¿cual es la importancia de contar con un proceso bien definido?

Mitarbeiter/innen, die keinen Feierabend kennen, die nie auf die Uhr schauen, die weder Privatleben noch Urlaub brauchen, die jeden Auftrag ausführen, die nie widersprechen, die an jedem Ort der Welt einsetzbar sind, die Cobol genauso gut beherrschen wie C, C++ und Java – welcher IT-Manager könnte da widerstehen. Es gibt sie tatsächlich und sie sind nicht einmal teuer, die indischen Software-Entwickler/innen. Und das Schöne ist: Die können gar nicht anders, sie können nicht über den Schatten ihrer Kultur springen. Nur manchmal, da übertreiben sie es, da hätten sie dann doch mal etwas sagen können. Und jetzt kommen auch noch Soziologinnen und Soziologen aus Bangalore daher und behaupten, dass der Inder als solcher gar nicht so ist, und dass auch indische Entwickler/innen nicht nur willige Techno-Kulis sind.

Carol Upadhya und A.R.Vasavi hinterfragen in ihrer Studie aus dem Jahr 2006 die kulturellen Unterschiede. Kulturelle Klischees verdecken hierarchische Strukturen und rechtfertigen Ausbeutungsverhältnisse.

„Long hours are part of our psyche”

So begründet ein Top-Manager eines indischen Dienstleisters die langen Arbeitszeiten.

„This cultural justification for long hours needs to be critically challenged, for it is the social condition and status of the employees rather than a shared culture per se that accounts for this difference. As relatively new players in the global IT industry, there is pressure to prove one’s individual and collective capability.” (Upadhya/Vasavi s.89)

Wenn es um die Einhaltung von gesetzlichen Regelungen zur Arbeitszeit geht argumentieren Sprecher der indischen IT-Industrie dann mit der Eigenart der IT-Arbeit.

„On the issue of long working hours in the software industry, industry spokespersons suggested that the high salary levels compensates for this level of commitment. They also argued that because software engineers are ‘self-driven’ it is not possible to impose fixed working hours on them, nor is it practically feasible to monitor and enforce official timings. In any case, the government should not impose regulations that would undercut the main advantage that the country has in the outsourcing industry (‘flexibility’, in other words, long working hours)… it was argued that because of the nature of the work in software companies, there can be no restrictions either on breaks or on working hours.” (Upadhya/Vasavi s.182)

„They always say yes”

Neinsager sind nicht gefragt. Die Auftraggeber im Westen sind Kunden – und wer würde schon dem Kunden widersprechen? Geht nicht, gibt es da nicht.
Auch die fabrikmäßige Softwareproduktion braucht keine Neinsager. Programmierer/innen werden als austauschbaren Ressourcen gesehen. ‘Generic Programmers’ sind flexibel in jedem Projekt einsetzbar, Technologien und fachliche Domänen spielen keine Rolle. Programmierung ist auf messbare Größen reduziert: Zeit, Aufwand, Produktivität und Output. Bezeichnungen wie „IT Professional” und „Knowledge Worker” verschleiern nur diese Reduktion auf „abstrakte Arbeit”. „Ressourcen Management Systeme” steuern und überwachen die Arbeit. Jede zugewiesene Aufgabe muss übernommen werden. Gleichzeitig sollen die „Ressourcen” die Verantwortung für die Termineinhaltung übernehmen und da auch eigenständig handeln.

„Reflecting the split between subjective and direct mechanisms of control, software engineers are expected to be self-managing and proactive, but at the same time to follow ‘process’, complete assigned work on time, perform as team players, and do everything to please the customer. While they are exhorted to be more assertive, from management point of view the ‘passivity’ of Indian engineers may be a positive trait, in that they are said to be ‘good at following directions’ and so are better able to adapt to the standardised quality processes typical of ‘software factories’.” (Upadhya/Vasavi s.69)

Die kulturellen Zuschreibungen haben die Funktion, die indischen Entwickler/innen in niederwertige Tätigkeiten abzudrängen:

„Thus, cultural stereotyping in the global workplace is not a superficial phenomenon, but performs a certain function in the regulation of work. These images serve to slot Indian software engineers into certain roles and positions: they are considered to be passive and inefficient, but also to work hard and with great dedication and competence; they are technically very adept and ‘good at following directions’ (in contrast to the more ‘creative’ and self-driven European engineers). As a result, they are regarded by their European managers and customers as little more than ‘techno-coolies’ who have the technical skills needed for basic computer programming and systems maintenance work but lack the social and cultural capital (‘soft skills’) required for more demanding roles.” (Upadhya/Vasavi s.97)

„The job is not interesting”

Die indischen Entwickler/innen mögen den Prozesswahn genauso wenig wie wir. Auch sie wollen eine kreative, anspruchsvolle und selbstbestimmte Tätigkeit.

„The routinisation of work is a major complaint of many software engineers. For one, it reduces the scope for originality and individual initiative, turning computer programming, which for many programmers is a highly individualistic and creative activity, into a kind of assembly line production system.” (Upadhya/Vasavi s.66)

Je stärker die Prozessorientierung ausgeprägt ist, desto höher ist die Fluktuationsrate.

„Common reasons that were given for job dissatisfaction include ‘the job is not interesting’, ‘work is monotonous’, and ‘I am stagnating’. A major reason for wanting to move to a new job is to get ‘better work’. These responses suggest that a major reason for job dissatisfaction and consequent high attrition is the increasingly process-driven nature of software production as well as the low-end nature of much of the work available. Many software engineers complain about the routine, boring and uncreative nature of their work, and they seek more challenging work either by changing projects within the company or, if that is not possible, by changing companies.” (Upadhya/Vasavi s.52)

Und wenn es um das Gehalt geht sind, die indischen Kolleginnen und Kollegen gar nicht mehr so zurückhaltend.

„But it is noteworthy that while customers find Indian software engineers to be subservient, their HR managers find them to be too assertive and demanding when it comes to their own compensation, promotions, and benefits.” (Upadhya/Vasavi s.69)

Konflikte, Kämpfe und subtiler Widerstand

Auch im Arbeitsalltag sind die indischen Entwickler/innen nicht so passive und unterwürfig, wie ihnen nachgesagt wird.

„So despite the ‘flat structures’, employee empowerment, and informality that are supposed to characterise these ‘new workplaces’, there are conflicts and struggles over control. However, these do not usually take an overt form, and the lines of confrontation are not clearly drawn as in labour disputes in traditional industries. As discussed above, the fuzziness of the line between ‘worker’ and ‘management’ in this industry, and the fact that software engineers do not identify themselves as ‘workers’, reduce the chances of such conflicts occurring. However, there are tensions between management practices and employees, most of which are related to the systems of control that have been evolved to manage these ‘knowledge workers’.” (Upadhya/Vasavi s.58)

Klassisch sind der Kampf um Termine und die Auseinandersetzungen bei Aufwandsschätzungen.

„I negotiate with my boss over the deadline, and he in turn negotiates with the next guy; this happens at the company level also, when they have to give time estimates to the parent or customer. It’s just like haggling over vegetables in the market”. (Upadhya/Vasavi s.U 81)

Wie Tom DeMarco so schön beschreibt, ist auch hier Lachen gesund.

„Woher kennen Manager den ‚richtigen‘ Zeitplan?… Wir haben es ihnen beigebracht. Sie beobachten unsere Gesichter, wenn sie Termine vorgeben. Wenn sich darin Erleichterung spiegelt, wissen sie, dass sie die Daumenschrauben nicht stark genug angezogen haben. Wenn wir sie auslachen, ist ihnen klar, dass sie zu weit gegangen sind.” (Tom DeMarco, „Warum ist Software so teuer?)

Ausuferndes Berichtswesen, falsch oder schlampig ausgefüllte Formulare und Stundenzettel führen immer wieder zu Konflikten mit dem Management.

„… they resent the amount of non-productive reporting and documentation that is required by quality processes. Some engineers try to find ways to circumvent or shortcut these requirements, for instance by filling timesheets automatically without reference to time actually spent on various tasks — creating a fertile area for conflict with managers and quality departments…”
„Struggles over timesheets and ‘metrics’ such as productivity are one area in which one might identify subtle forms of resistance on the part of employees.” (Upadhya/Vasavi s.66 und s.74)

Auch der Verzicht auf Eigeninitiative und Handeln erst nach Aufforderung können als Widerstand gegen überbordenden Arbeitsdruck interpretiert werden.

„More broadly, the problems that software companies face in managing outsourced projects or virtual teams may arise simply from the struggles over time, deadlines, and allotment of work that take place within any software development team. … In this struggle, rather than confronting the manager directly, they may use indirect tactics to buy time or to avoid certain tasks, such as repeatedly asking for instructions or not completing work unless reminded. This behaviour pattern is then labelled by managers as stemming from Indian cultural difference.” (Upadhya/Vasavi s.99)

Die Studie von Upadhya und Vasavi zeigt, dass unsere indischen Kolleginnen und Kollegen die gleichen Wünsche haben wie wir. Ihre Strategien im Arbeitsalltag gleichen den unseren. Unterschiede in der Arbeitsweise spiegeln nicht einfach „kulturelle Eigenarten” wieder, sie sind Ausdruck von hierarchischen Beziehungen und fortgeschrittener Industrialisierung. Am Fließband sind wir alle gleich.

Lesetipp:

Carol Upadhya und A.R. Vasavi
“WORK, CULTURE, AND SOCIALITY IN THE INDIAN IT INDUSTRY: A SOCIOLOGICAL STUDY”
Bangalore 2006
idpadfinalreport.pdf

Gemeint sind hier die indischen IT-Dienstleister. Diese produzieren Software nach Fabrikmethoden, sie sind bekannt für die Qualität ihrer Prozesse. Nirgendwo werden so viele CMMI 5 Zertifikate ausgestellt wie in Indien. Die Akzeptanzbeschaffer/innen von Export-IT führen den Erfolg der indischen Unternehmen auf diese ausgeprägte Prozessorientierung zurück. Das niedrige Lohnniveau und die langen Arbeitszeiten geraten dabei aus dem Blickfeld. Soziologinnen und Soziologen aus Bangalore haben eine andere Sicht. Sie lassen sich nicht vom schönen Schein der heilen Prozesswelt blenden. In ihrer Studie aus dem Jahr 2006 analysieren Carol Upadhya und A.R. Vasavi die realen Herrschafts- und Kontrollmechanismen bei den großen indischen IT-Dienstleistern.

Bei der Analyse des Produktionsregimes der indischen “Software Factories” können drei Schichten unterschieden werden. Die oberste Schicht stellen kundenbezogene Fassaden dar. Dem Kunden wird gezeigt was er sehen will.

“It was also observed that service organisations attempt to project a particular image to customers that may not reflect the reality within, for instance by giving employees ‚fancy designations’ to impress the client. ‚There’s a difference between the way organisations really function internally and how they are demonstrated to others’, said one informant.” (Upadhya/Vasavi s.73)

Die nächste Schicht bilden die offiziellen Prozesse und die Darstellung des Managements.

“We must distinguish between what is claimed by managements or exists in the form of official policies, and what actually happens.” (Upadhya/Vasavi s.73)

Die unterste Schicht ist die reale Arbeitswelt. In Interviews wird typischerweise die offizielle Version erzählt. Zur Analyse der Herrschaftsmechanismen stützen sich Upadhya und Vasavi daher auch auf unmittelbare Beobachtungen an verschiedenen Arbeitsplätzen.

Qualitätsprozesse als Herrschafts- und Kontrollmechanismus

Prozesse schreiben die Arbeitsschritte in allen Entwicklungsphasen vor. Detaillierte Arbeitsvorgaben und engmaschige Leistungskontrollen garantieren permanenten Arbeitsdruck.

“These quality models prescribe rationalised and systematic processes for the organisation of work flows at every stage of the software cycle as well as for management practices; the setting of specific productivity goals for each worker and team on a daily and weekly basis; and detailed monitoring, measuring, reporting, and evaluation of work completed. This creates a regime of endless reporting and evaluation of work activities, and a lot of ‘paperwork’ (now of course done electronically) in the form of numerous reports to be written, timesheets to be filled, and so on, all of which adds to the pressure on employees’ and managers’ already limited time. Apart from reducing software production to a highly routinised and mechanical process, these systems put additional pressure on engineers to meet their production and quality goals in order to maintain their individual and team ratings, which are being constantly measured. (Upadhya/Vasavi s.64)

Gemessen werden beispielsweise Lines of Codes, realisierte Function Points oder die Anzahl der geprüften Testfälle. Softwareentwicklung wird so in messbare Einheiten zerlegt, das Wissen der Entwickler/innen soll in die Prozesse verlagert werden.

“A significant outcome of the rationalisation of software production is that programming and other IT work are being reduced to measurable quantities of time, effort, productivity, and output — mimicking in many ways the old Taylorist system of factory management. … A second consequence of process-orientation is that it allows management to tighten its control over the labour process as well as over the implicit knowledge of workers. … the ‘aim of quality processes is not so much to produce errorfree software as ‚… to turn the solitary activity of software programming into a managed team activity – in other words, to break the individual employee’s monopoly of knowledge over the labor process, and to make the process independent of any particular employee.’” (Upadhya/Vasavi s.65)

Da die vollständige Taylorisierung der Programmierarbeiten nicht möglich ist, werden direkte Herrschaft und Kontrolle durch indirekte Mechanismen ergänzt: Firmenkultur und der gegenseitige Druck im Team sollen die Produktivität weiter steigern.

Bei der Leistungsbeurteilung werden die Beschäftigten dann in einer Rangfolge eingeordnet, die 5-10 Prozent am unteren Ende der Skala müssen mit ihrer Entlassung rechnen. Das System scheint perfekt.

“Time slavery”

Die Arbeitstage bei den indischen IT-Dienstleistern sind lang. Nächte und Wochenenden im Büro häufen sich vor Abgabeterminen. Upadhya/Vasavi meinen, die indischen Firmen seien nicht gut im Schätzen von Aufwänden. Dann gäbe es da noch die Zeitverschiebung in internationalen Teams, vor allem aber den Projektzyklus selbst: Egal wie gut das Projekt geplant sei, immer komme es zu periodischen “last minute” – Krisen und unerwartete Problemen.

Den Zusammenhang mit der ausgeprägten Prozessorientierung benennen sie nicht. Industrielle Prozesse und Überstunden sind zwei Seiten einer Medaille. Die immer wieder auftretenden Projektkrisen mit den dann fälligen Überstunden, durchgearbeiteten Nächten und Wochenenden sind der empirische Beweis: Software kann nicht wirklich fabrikmäßig produziert werden. In der Automobilindustrie läuft ein Auto in der Regel ohne Krisen vom Band; der Motoreneinbau führt nicht jedes Mal zu unerwarteten Problemen. Bei der fabrikmäßigen Softwareproduktion haben Krisen System. Das Ganze funktioniert nur solange wie die Entwickler/innen die Last auf sich nehmen und die Fehler im System durch Sondereinsätze und flexible Mehrarbeit auffangen.

Lesetipp:

Carol Upadhya und A.R. Vasavi
“WORK, CULTURE, AND SOCIALITY IN THE INDIAN IT INDUSTRY: A SOCIOLOGICAL STUDY”
Bangalore 2006
idpadfinalreport.pdf

Nos es grato anunciar que pronto estará disponible en la página web toda la información correspondiente al servicio de desarrollo de software para microcontroladores PIC que Dinasis brinda en forma de Software Factory.

Realizamos desarrollos de firmware para dispositivos electrónicos basados en microcontroladores PIC de Microchip, en todas sus versiones. El servicio está disponible por contrato a cualquier parte del mundo.

Desarrollos para control industrial y de procesos, electrónica de consumo, desarrollos de harware para proyectos especiales. 

Se coordinan las entrevistas en línea necesarias con nuestro departamento de desarrollo para tomar conocimiento de las características del sistema buscado, y luego de recibir los planos del sistema electrónico, y en lo posible un prototipo, desarrollamos el software correspondiente con los más altos estándares de calidad, entregando un producto 100% funcional y con la documentación del proyecto que permita futuras revisiones o actualizaciones.

Garantizamos total confidencialidad.

Proximamente más detalles, pero cualquier consulta puede ser canalizada a glrodriguez@dinasis.com.ar

GLR.

Leo en Barrapunto una noticia proveniente de Cincodias.com que se titula “España se vende como paraíso para los centros de Software” que me deja pasmado.

Es tema más o menos recurrente en blog de temática tecnológica el estado del arte de la informática en nuestro país y por ende de la situación de ese marco laboral. Enrique Dans se preguntaba por el paradero de los programadores y no le faltaba razón. Por otra parte y a raíz de esa entrada Ricardo Galli diseccionaba el perfil de un buen programador en una de sus entradas en el antiguo blog con el que, por cierto, estoy totalmente de acuerdo.

Pero la noticia de hoy es algo contradictoria. Lo que a priori puede parecer un intento positivo por atraer inversión de capital extranjero para crear centros tecnológicos en España bajo mi punto de vista no es más que un error para poner la España Tecnológica en oferta. Lo que propone la “Asociación Española de Empresas de Consultoría (AEC)” según la noticia citada anteriormente de Cincodias.com es a todas luces erroneo. Si bien es cierto que se debe perseguir la inversión de capital extranjero y fomentar inversión en tecnología e innovación lo que me parece que es un error es hacerlo a toda costa y sin control. Están promoviendo que España sea el paraíso del Nearshore europeo.

¿Y esto del NearShore qué es? Pues ni más ni menos que externalizar el trabajo de una empresa hacia un país vecino en busca de unos costes salariales más bajos. Ocurre en EEUU con México y ahora “queremos” que ocurra en Europa con España. Puestos a anunciarse, en vez del lema que utilizan “España: Destino europeo del nearshore” que pongan algo como “España: carnaza que explotar” o “Vendemos el kilo de programador baratito” o, incluso, “Encarguen programar en España. Precio: la voluntad“.

Vaya cagada, madre mía, vaya cagada… Y encima tienen 300.000 euros de presupuesto…

Tom spoke about the major Software factories that are in use now -

• Web Client Software Factory
• Web Services Software Factory
• Smart client Software Factory
• Mobile Client Software Factory

He gave a demo on the current Web Service Software Factory and also the yet to be released newer version of it. The new version is an interesting one, as you first define the model using DSL and then let the Software factory generate the code after that. I actually like this approach, but Darren got me thinking about the frequency at which the p&p team make breaking changes. All the guidance automation that people would have built/extended using the old Service Software factory would now be rendered redundant. Not a very good thought for people who would have done that.

Having said that I have to admit I am looking forward to playing around with the new “Modeling edition” Service Factory.

A few days in hospital where my father was undergoing treatment.

Though this is not the first time I have been in hospital but this time, it got me thinking…

I used to attribute much of complexity of software development to creative content & team factor in it. Now, I find that healthcare is no different.

In fact, there is many parallel in definining customer needs (which goes much beyond specified), evolving technologies, new hypotheses challenging earlier ones, interplay of many skills (Specialized physician & surgeons, Nurses, Technical experts, Office staff), ….

Yet much of it is well defined eg. Much of what Nurse needs to do is well defined and action plan in exigencies are also well defined…. and strictly adhered to

It does not lead to avoidable documentation in the name of following some standards either! Documentation is kept to the right level; the key is more of delivering to customer satisfaction than meeting specification

When will software industry learn & mature? How long can we hide behind the nascent nature of the industry and rapid pace of changes.

It is not Java or .Net or application servers or platforms or SOA or MDA … what not, that matters .. it is uncompromised quality meeting the customer expectations and needs … not just the wants and specifications

One of my customers, with whom I am working very closely for last couple of months is actively into many a things which are part of software factory …. seems to be great and quite interesting …. makes a lot of difference and it works!

There have been many discussions in the past on whether software development is an art, craft, science or engineering. For convenience, I am listing below the major ones that had profound influence on my thoughts over years

1. Book Software Craftsmanship – The New Imperative
2. From Craft to Science Part 1 and Part 2
3. The great art and craft of software development
4. Software engineering and the Art of Design
5. The art, science and engineering of software development
6. Manifesto of software craftsmanship
7. The privilege and responsibility of software development
8. Commitment
9. What is software design?
10. Software that lasts 200 years

My view is that software development is a combination of all of above. My view is also that software is a construction of human mind or rather minds; and should I say human brains. Yes, mind and brain. Emotion and intellect. What is important to me is this human creation has pervaded virtually every aspect of life and business by now, unlike any other human creation, and hence business critical.

It is an art, it is a craft… beyond all that business depends on it; life and career of many depends on it. Hence, it is important to bring in continually better control, better quality, better transparency and better predictability into software development. Taking recourse to engineering is to this end. Engineering is not an end in itself but a means to an end. Engineering as a manager’s tool to have better control, better quality, better transparency and better predictability. From that standpoint, we find that apparently conflicting perspectives are not truly conflicting; they are different dimensions of software development.

Every successful software development manager knows this and manages his/her business accordingly. These fits into my overall management-engineering framework; result of applying learning into practice, and continually refining my learning based on observation.

PABRIK SOFTWARE, SOFTWARE MANUFACTURE, SOFTWARE PRODUKSI, SOFTWARE DISTRIBUSI, SOFTWARE PURCHASING, SOFTWARE PABRIK, SOFTWARE WAREHOUSE, ACCOUNTING SOFTWARE, SOFTWARE GA, SOFTWARE HRD, SOFTWARE PPIC, MANUFAKTUR SOFTWARE, SOFTWARE FACTORY, SOFTWARE HRD, SOFTWARE PRODUKSI, FACTORY SOFTWARE, Untuk Informasi lebih lanjut telpon: REKO HANDOYO, 081389411679, 081932985325.Telp: 021-36233226 PT. SIEN Technology-Jakarta.

Anda membutuhkan software pabrik, produksi software untuk di divisi GA (general Affair atau divisi Umum dan Purchasing,  pabrik, bengkel, bagian hrd, software akuntansi, software gudang, pabrik, marketing, dll atau perusahaan Anda? Kami  menyediakan software yang didevelop dengan harga murah dan bersifat customize dengan maintenance yang memuaskan.

Software yang kami sediakan antara lain

1. software Produksi mulai dari proses perencaan produksi, jumlah produksi, kapasitas mesin, jumlah mesin, output produksi sampai hasil akir dari proses produksi
2. softrware Purchasing mulai dari prose pemesanan, delivery, penyimpanan di gudang, barang retur dll.
3. software HRD yang cocok dengan divisi SDM atau HR manajemen. Di dalam software ini kami akan mendevelop software untuk salary structure, absensi, jabatan, system promosi dan lain-lain.
4. Software Gudang mulai dari proses penerimaan barang, identifikasi barang, lokasi penyimpanan, waktu kedatangan, waktu pengeluaran, dll.
5. Software Marketing mulai dari proses pencarian order, identifikasi sasaran, data detail customer, progress report, sampai tahap closing dan customer service.

Modul di atas adalah sebagian modul yg dikerjakan dalam proses produksi, kami terbuka untuk mendevelop software dengan sesuai kebutuhan dari klien.

Software yang kami develop dapat kami lakukan dimanapun bisnis anda berada. Baik untuk keperluan yang bersifat local maupun dengan system web basis.

Untuk informasi dan keterangan lebih jelas mengenai software produksi, software pabrik, software manufacture, software manufaktur, software HRD, software bengkel, dan lain-lain yang kami lakukan silahkan hubungi kami

REKO HANDOYO, S.IP

Business Consultant

PT. Sien Corpora  (SIEN Technology)

Jl. Radiul No.6 Jatipulo Tomang, Jakarta Barat, Indonesia

Mobile: 081932985325, 081389411679, 081807902678

Kantor telp:021- 36233226, 021-98567515,

Email: reko.handoyo@gmail.com, reko@sienconsultant.com

]]>