Isabel Lopes Margarido
Faculdade de Engenharia da Universidade do Porto|PhD
Word Press
14 Oct. 2013
III Conferência CMMI Portugal
No dia 17 de Outubro teremos em paralelo workshops, tutoriais e ainda um painel de discussão.
Venha aprender mais sobre Change Management, Human Centered Process Improvement ou como conjugar Scrum com CMMI. O convívio e discussão prolongam-se no jantar informal da conferência.
No dia 18 de Outubro teremos várias apresentações de peritos nacionais e internacionais, bem como dois oradores convidados internacionais. Os tópicos são os seguintes:
Consulte o programa detalhado no nosso site e inscreva-se!
Isabel Margarido
Chair do Comité Científico
III Conferência CMMI Portugal
2 Jun. 2013
Op-Ed: What do Experts in Any Area Have in Common?
According to NASA, Software Engineering provides the computing and commands that are necessary to navigate Mars Rovers. Computer programs allow the Rovers to collect reliable data they send back to Earth for scientists to analyse. If there is evidence that life can subsist in Mars we want to ensure that it is reliable, especially if it supports decisions such as sending humans there. These missions coding standards are rigorously followed. What skills should software developers have besides being experts in programming, design, architecture, systems integration and understanding aerospace requirements? They must have these skills sharpened. Actually, that is what distinguishes experts in any area. We can all achieve that!
My conscious self-improvement journey began in 2008, when I was Quality Manager in a self-managed team developing software. While programmers were applying the so called Personal Software Process℠ to program, as it was designed to, I was doing other tasks and wanted to apply the same principles. I had to assure that most mistakes would be avoided and all defects would be found and fixed before delivering the product to the client. The software teams of the Mars Rovers missions certainly do this, right? Guarantee that the Rovers do their expected job without failing: send accurate data, recognise obstacles...
Let us forget software for a second. Think about processes, remove the word "software" from Personal Software Process and call it Personal Process. Here's an example with writing:
First I identify and write down my tasks and steps to execute them. Then I do my tasks, e.g. write an article, and record the time I spend at each task, including reading other authors' work. If I happen to receive a phone call I stop the clock and restart it once I get back to work. After I finish my tasks I know how long they took me so they become predictable. My records tell me that to write a 750 words draft I spent 4h30 researching and 1h writing. I also notice that interruptions cost me time to recall what I was doing.
So I know how long the research took me, how many words I can write per minute and predict how long it will take me to write my next draft. Next I review my draft with my peers, record the time spent in review, identify and count the mistakes we find, record the time it takes me to correct each one of them. While some are just spelling mistakes, hence fast to correct, others are repeated ideas or disrespect of paragraph unity that make me reorganise my article. The review records reveal that we spent 4h30 reviewing the 750 words draft, the number of mistakes found in the review and how long it took me to correct them. I then realise that I could have pre-reviewed before the actual review, avoiding many of those mistakes.
Hence, I learnt two quality practices that I add to my personal process: pre-review by checking the spelling and reading aloud before sending the article for peer-review, and avoid interruptions by muting my phone. Now I know what activities help me prevent mistakes that take longer to solve after peer-reviews, because the work is not so fresh in my mind. I am also able to establish self-improvement goals. To reduce writing time I separate the steps of researching and writing, improving the time to create the draft. Another self-improvement goal is to prevent paragraph unity and sequence mistakes. I realise that if I outline (design) my article it emerges more organised, with fewer repetitions, consequently reducing mistakes and time spent rewriting and reviewing.
Just as I use Personal Process to write an article so can you in writing an e-mail, building an electronic circuit or programming a Mars Rover... Take this discipline into your life and see yourself becoming more organised and your plans getting more accurate than ever.
Isabel Lopes Margarido is a PhD Student of Informatics Engineering at Faculty of Engineering, University of Porto
20 Apr. 2013
Isabel Lopes Margarido
Case Study: Software Engineering Excellence - From Good to Great
Software Engineers face many challenges, not only in their area, but also in understanding different business areas. What does it take to make a Software Engineering expert? It takes "deep practice" (Coyle 14), "deliberate training" (Colvin), and something more. In this paper I explore other requirements, such as awareness of one's own skills and limitations, observation and first-hand experience. I introduce the necessary skills to be a good software engineer, explain what it takes to go from good to great by presenting the path and work of a researcher who greatly contributed to this area, and discuss what made him an expert.
Software is part of our daily life. It is everywhere: mobile phones, computers, washing machines, cars, aircrafts, space shuttles, satellites... but also in trains that can have no drivers, as the Phileas, (Wikipedia) and helicopters with reduced crew workload, as the A129 (Wikipedia); we do not want them to crash, costing lives. Evidently, software needs to work properly, without defects and doing what is intended, especially in critical systems where lives are at stake. Software Engineering is a discipline that includes good practices to develop software and manage software projects. According to van Vliet, Software Engineering researcher, it appeared from the necessity of producing software applying engineering principles (3). IEEE1 defines it as "the application of systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software" (IEEE610).
Is it enough to produce good programs to be a good software engineer? The challenges in producing software are not restricted to understanding how it is developed (e.g. the program and architecture), they also include understanding the field where it will be applied and how it will be used (van Vliet 8). I worked in projects of different areas that I had to understand: voters' registration and electoral results calculation, the editorial process and royalties' payment, etc. Executing software projects involved understanding, and sometimes developing, complex mathematical functions, and realising how the software was going to be used before it even existed (the workflow) -- for example, the doctor first reads the patient history, then requests a drug administration. Software applications and development teams can be very large, the latter may be dispersed in locations (van Vliet 7) perhaps with different time zones, and need to work together. The problem must be broken into smaller manageable pieces (van Vliet 6) that afterwards are integrated to operate together. Managing software projects is a challenge itself. Moreover, the product must be: maintainable, as often defects are found later when it is being used, and evolvable, to answer new needs and not become obsolete -- which is not trivial. What makes Software Engineering experts, then?
In Mockus and Herbsleb's experience, the key qualities of software experts are performing tasks quickly, with minimal effort and high quality results (Mockus). But are these qualities enough? Let us look at the path of a man who greatly contributed to this research area and find out. Watts Humphrey was a genius in Software Engineering Management. He worked for 28 years for IBM, managed hardware teams and thousands of software professionals, improving software quality (CMU/SEI). Then he joined the Software Engineering Institute, bringing the vision that "software could be managed by process2". Humphrey led a team that identified characteristics and best practices in Software Engineering, originating software process models used worldwide. His life journey towards the creation and improvement of those models unveils the ingredients that make experts in this research area.
Humphrey became a researcher when he dedicated to solve a real problem that he experienced. At the time, computer courses were inexistent so managing software teams was a challenge (CMU/SEI). Humphrey's life philosophy was: to teach or manage others one must respect their "knowledge and experience". Just because you manage someone, you do not necessarily know how the work is done and why so; therefore it is imperative that you ask questions. Furthermore, instead of imposing solutions Humphrey first experimented with himself and later with others. An example is the creation of the People Software Process (PSP℠): he spent months developing several computer programs and documenting the perfect development process; then he piloted it in software organisations. PSP development may be considered Humphrey's intensive training at the "edges" of his ability (14), that Coyle, sports journalist and author of The Talent Code, designated "deep practice".
Humphrey's PSP training is also a path for self-improvement and discipline, consisting of developing several products and improving the process by adding quality practices. The training is done in steps (Figure 1) beginning with PSP0, where developers write their development process and follow it. During development, programmers record information about the program: size, development time, and number of defects. At the beginning of PSP1 programmers use the data collected in the previous phases to plan their work, estimate the necessary effort to develop the program and its size. Such data is used in PSP2 to alert programmers for their mistakes, when they are made and the quality practices to avoid them. They plan expected number of defects inserted and removed in each development phase, hence learning to manage defects and yield3. The PSP principle of adding quality practices to avoid mistakes contrasts with Coyle's idea that mistakes are essential to improve a skill, by making people stop and go back to correct them (18). PSP training towards expertise goes from simple and unplanned to complex and predictable. I find that PSP is the exact application of engineering to software and, as van Vliet stated "discipline is one of the keys" to successfully complete a development project (7).
The benefit of PSP is that programmers see their results improving during training; at the end their skills and programs are unequivocally better. The processes are embraced not imposed. Furthermore, programmers become aware of their personal data, allowing them to set individual goals for improving their own development process towards making better products faster -- this requires intrinsic motivation. PSP principles resemble Colvin's concept of "deliberate practice"to become talented: "activity that is explicitly intended to improve performance, that reaches for objectives just beyond one's level of competence, provides feedback on results and involves high levels of repetition" (Colvin). I used PSP not just in software development but in all my activities, it became an indispensible tool to do my work and improve skills.
Software development is complex and requires many skills that are specific to Software Engineering, but also the capability to understand the context of its creation and utilisation. After all, "we regularly embark on software development projects that go far beyond our expertise (van Vliet 9)". Good software engineers have to be disciplined and motivated to improve their skills, know their results, and use their data to plan future projects -- PSP helps. To go beyond being a good software engineer to become an expert requires some additional ingredients such as "deep practice" (Coyle 14), and "deliberate training" (Colvin). Furthermore, what makes Humphrey a genius is also learning from others and asking questions; experiencing problems; experimenting, analysing, innovating and improving -- bottom line, being a scientist. These characteristics are useful for areas other than Software Engineering. Humphrey's work must be continued, perhaps by applying PSP principles to other disciplines.
"Phileas (public transport)". Wikipedia. 2013. Web. 12 May 2013.
"Agusta A129 Mangusta". Wikipedia. 2013. Web. 12 May 2013.
Van Vliet, Hans. Software Engineering: Principles and Practice. (Chapter 1: Introduction). New York: Willey, 2007. Print.
IEEE610. IEEE Standard Glossary of Software Engineering Terminology. IEEE Std 610.12. 1990. Print.
CMU/SEI. Watts Humphrey: An Outrageous Commitment, A Lifelong Mission. Carnegie Mellon University. 2010. Web. 19 Apr. 2013.
Pascoal Faria, João. "A Path for Performance Improvement: the Personal Software Process (PSP) and the Team Software Process (TSP)". ProDEI, TIES. Porto, Portugal. 6 November, 2009. Presentation.
Over, James. "Introduction to the Team Software Process". SEPG Europe. Porto, Portugal. 27 June, 2010. Presentation.
"Compile". Wiktionary. 2013. Web. 30 Apr. 2013.
Colvin, Geoffrey. "What it Takes to be Great" Fortune (2006). Web. 16 Apr. 2013.
Coyle, Daniel. The Talent Code. (Chapter 1: The Sweet Spot). New York: Bantam Dell, 2009. Print.
1 Institute of Electrical and Electronics Engineers.
2 Process - steps that guide people on how to do their work in order to develop better products minimising production time and defects.
3 Number of expected defects still existing in the code.
|
©2012 Isabel Margarido
