What Makes a Great Software Engineer

Thesis (Ph.D.)--University of Washington, 2016-06

An Active Learning Module for an Introduction to Software Engineering Course

Many schools do not begin to introduce college students to software engineering until they have had at least one semester of programming. Since software engineering is a large, complex, and abstract subject it is difficult to construct active learning exercises that build on the students’ elementary knowledge of programming and still teach basic software engineering principles. It is also the case that beginning students typically know how to construct small programs, but they have little experience with the techniques necessary to produce reliable and long-term maintainable modules. I have addressed these two concerns by defining a local standard (Montana Tech Method (MTM) Software Development Standard for Small Modules Template) that step-by-step directs students toward the construction of highly reliable small modules using well known, best-practices software engineering techniques. “Small module” is here defined as a coherent development task that can be unit tested, and can be car ried out by a single (or a pair of) software engineer(s) in at most a few weeks. The standard describes the process to be used and also provides a template for the top-level documentation. The instructional module’s sequence of mini-lectures and exercises associated with the use of this (and other) local standards are used throughout the course, which perforce covers more abstract software engineering material using traditional reading and writing assignments. The sequence of mini-lectures and hands-on assignments (many of which are done in small groups) constitutes an instructional module that can be used in any similar software engineering course.

Indian IT software engineers in Japan : a preliminary analysis

In this study, the work and life of Indian IT engineers in Japan engaged in software development were examined through a questionnaire survey. Findings were further supported by comparative analyses with Chinese and Korean software engineers. While Indian IT software engineers appeared rather satisfied with their life overall in Japan, they seemed rather dissatisfied with their work conditions including such things as fringe benefits, the working-time management of the company, levels of salary and bonuses, and promotion opportunities. It was made clear that profiles and perceptions of Indian engineers and those of Chinese and Koreans in Japan were different.

An Analysis Of The Recommended Knowledge For The Software Project Management Discipline

According to the PMBOK (Project Management Body of Knowledge), project management is “the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements” [1]. Project Management has proven to be one of the most important disciplines at the moment of determining the success of any project [2][3][4]. Given that many of the activities covered by this discipline can be said that are “horizontal” for any kind of domain, the importance of acknowledge the concepts and practices becomes even more obvious. The specific case of the projects that fall in the domain of Software Engineering are not the exception about the great influence of Project Management for their success. The critical role that this discipline plays in the industry has come to numbers. A report by McKinsey & Co [4] shows that the establishment of programs for the teaching of critical skills of project management can improve the performance of the project in time and costs. As an example of the above, the reports exposes: “One defense organization used these programs to train several waves of project managers and leaders who together administered a portfolio of more than 1,000 capital projects ranging in Project management size from $100,000 to $500 million. Managers who successfully completed the training were able to cut costs on most projects by between 20 and 35 percent. Over time, the organization expects savings of about 15 percent of its entire baseline spending”. In a white paper by the PMI (Project Management Institute) about the value of project management [5], it is stated that: “Leading organizations across sectors and geographic borders have been steadily embracing project management as a way to control spending and improve project results”. According to the research made by the PMI for the paper, after the economical crisis “Executives discovered that adhering to project management methods and strategies reduced risks, cut costs and improved success rates—all vital to surviving the economic crisis”. In every elite company, a proper execution of the project management discipline has become a must. Several members of the software industry have putted effort into achieving ways of assuring high quality results from projects; many standards, best practices, methodologies and other resources have been produced by experts from different fields of expertise. In the industry and the academic community, there is a continuous research on how to teach better software engineering together with project management [4][6]. For the general practices of Project Management the PMI produced a guide of the required knowledge that any project manager should have in their toolbox to lead any kind of project, this guide is called the PMBOK. On the side of best practices 10 and required knowledge for the Software Engineering discipline, the IEEE (Institute of Electrical and Electronics Engineers) developed the SWEBOK (Software Engineering Body of Knowledge) in collaboration with software industry experts and academic researchers, introducing into the guide many of the needed knowledge for a 5-year expertise software engineer [7]. The SWEBOK also covers management from the perspective of a software project. This thesis is developed to provide guidance to practitioners and members of the academic community about project management applied to software engineering. The way used in this thesis to get useful information for practitioners is to take an industry-approved guide for software engineering professionals such as the SWEBOK, and compare the content to what is found in the PMBOK. After comparing the contents of the SWEBOK and the PMBOK, what is found missing in the SWEBOK is used to give recommendations on how to enrich project management skills for a software engineering professional. Recommendations for members of the academic community on the other hand, are given taking into account the GSwE2009 (Graduated Software Engineering 2009) standard [8]. GSwE2009 is often used as a main reference for software engineering master programs [9]. The standard is mostly based on the content of the SWEBOK, plus some contents that are considered to reinforce the education of software engineering. Given the similarities between the SWEBOK and the GSwE2009, the results of comparing SWEBOK and PMBOK are also considered valid to enrich what the GSwE2009 proposes. So in the end the recommendations for practitioners end up being also useful for the academic community and their strategies to teach project management in the context of software engineering.

Novatests : metodología y herramienta software de apoyo para los ingenieros de prueba junior

La Ingeniería de Pruebas está especializada en la verificación y validación del Software,y formalmente se define como: “Proceso de desarrollo que emplea métodos rigurosos para evaluar la corrección y calidad del producto a lo largo de todo su ciclo de vida” [3]. Este proceso comprende un conjunto de métodos, procedimientos y técnicas formalmente definidas las cuales, usadas de forma sistemática, facilitan la identificación de la mayor cantidad de errores y fallos posibles de un software. Un software que pase un proceso riguroso de pruebas es un producto de calidad que seguramente facilitará la labor del Ingeniero de Software en la corrección de futuras incidencias, algunas de ellas generadas tras la implantación en el entorno real. Este proceso constituye un área de la Ingeniería del Software y una especialidad por tanto, de la misma. De forma simple, la consecución de una correcta Verificación y Validación del Software requiere de algunas actividades imprescindibles como: - Realizar un plan de pruebas del proyecto. - Actualizar dicho plan y corregirlo en caso necesario. - Revisar los documentos de análisis de requisitos. - Ejecutar las pruebas en las diferentes fases del desarrollo del proyecto. - Documentar el diseño y la ejecución de las pruebas. - Generar documentos con los resultados y anomalías de las pruebas ya ejecutadas. Actualmente, la Ingeniería de Pruebas no es muy reconocida como área de trabajo independiente sino más bien, un área inmersa dentro de la Ingeniería de Software. En el entorno laboral existe el perfil de Ingeniero de Pruebas, sin embargo pocos ingenieros de software tienen claro querer ser Ingenieros de Pruebas (probadores o testers) debido a que nunca han tenido la oportunidad de enfrentarse a actividades prácticas reales dentro de los centros de estudios universitarios donde cursan la carrera. Al ser un área de inherente ejercicio profesional, la parte correspondiente de la Ingeniería de Pruebas suele enfocarse desde un punto de vista teórico más que práctico. Hay muchas herramientas para la creación de pruebas y de ayuda para los ingenieros de pruebas, pero la mayoría son de pago o hechas a medida para grandes empresas que necesitan dicho software. Normalmente la gente conoce lo que es la Ingeniería de Pruebas únicamente cuando se empieza a adquirir experiencia en dicha área en el ejercicio profesional dentro de una empresa. Con lo cual, el acercamiento durante la carrera no necesariamente le ha ofrecido al profesional en Ingeniería, la oportunidad de trabajar en esta rama de la Ingeniería del Software y en algunos casos, NOVATests: Metodología y herramienta software de apoyo para los Ingenieros de Prueba Junior 4 los recién egresados comienzan su vida profesional con algún desconocimiento en este sentido. Es por el conjunto de estas razones, que mi intención en este proyecto es proponer una metodología y una herramienta software de apoyo a dicha metodología, para que los estudiantes de carreras de Ingeniería Software y afines, e ingenieros recién egresados con poca experiencia o ninguna en esta área (Ingenieros de Pruebas Junior), puedan poner en práctica las actividades de la Ingeniería de Pruebas dentro de un entorno lo más cercano posible al ejercicio de la labor profesional. De esta forma, podrían desarrollar las tareas propias de dicha área de una manera fácil e intuitiva, favoreciendo un mayor conocimiento y experiencia de la misma. ABSTRACT The software engineering is specialized in the verification and validation of Software and it is formally defined as: “Development process which by strict methods evaluates and corrects the quality of the product along its lifecycle”. This process contains a number of methods, procedures and techniques formally defined which used systematically make easier the identification of the highest quantity of error and failures within a Software. A software going through this rigorous process of tests will become a quality product that will help the software engineer`s work while correcting incidences. Some of them probably generated after the deployment in a real environment. This process belongs to the Software engineering and therefore it is a specialization itself. Simplifying, the correct verification and validation of a software requires some essential activities such as: -Create a Test Plan of the project - Update this Test Plan and correct if necessary - Check Requirement’s specification documents -Execute the different tests among all the phases of the project - Create the pertinent documentation about design and execution of these tests. - Generate the result documents and all the possible incidences the tests could contain. Currently, the Test engineering is not recognized as a work area but an area immerse within the Software engineering. The professional environment includes the role of Test engineer, but only a few software engineers have clear to become Test engineers (testers) because they have never had the chance to face this activities within the university study centers where they take study of this degree. Since there are little professional environments, this area is focused from a theoretical way instead of a more practical vision. There are plenty of tools helping the Test engineer, but most of them are paid tools or bespoke tools for big companies in need of this software. Usually people know what test engineering is by starting working on it and not before, when people start acquiring experience in this field within a company. Therefore, the degree studied have not approach this field of the Software engineering before and in some cases the graduated students start working without any knowledge in this area. Because of this reasons explained, it is my intention to propose this Project: a methodology and a software tool supporting this methodology so the students of software engineering and similar ones but also graduated students with little experience in this area (Junior Test Engineers), can afford practice in this field and get used to the activities related with the test engineering. Because of this they will be able to carry out the proper tasks of this area easier, enforcing higher and better knowledge and experience of it.

An approach to specifying software frameworks

A framework is a reusable design that requires software components to function. To instantiate a framework, a software engineer must provide the software components required by the framework. To do this effectively, the framework-component interfaces must be specified so the software engineer knows what assumptions the framework makes about the components, and so the components can be verified against these assumptions. This paper presents an approach to specifying software frameworks. The approach involves the specification of the framework’s syntax, semantics, and the interfaces between the framework and its components. The approach is demonstrated with a simple case study.

A reference architecture for instructional educational software

Our extensive research has indicated that high-school teachers are reluctant to make use of existing instructional educational software (Pollard, 2005). Even software developed in a partnership between a teacher and a software engineer is unlikely to be adopted by teachers outside the partnership (Pollard, 2005). In this paper we address these issues directly by adopting a reusable architectural design for instructional educational software which allows easy customisation of software to meet the specific needs of individual teachers. By doing this we will facilitate more teachers regularly using instructional technology within their classrooms. Our domain-specific software architecture, Interface-Activities-Model, was designed specifically to facilitate individual customisation by redefining and restructuring what constitutes an object so that they can be readily reused or extended as required. The key to this architecture is the way in which the software is broken into small generic encapsulated components with minimal domain specific behaviour. The domain specific behaviour is decoupled from the interface and encapsulated in objects which relate to the instructional material through tasks and activities. The domain model is also broken into two distinct models - Application State Model and Domainspecific Data Model. This decoupling and distribution of control gives the software designer enormous flexibility in modifying components without affecting other sections of the design. This paper sets the context of this architecture, describes it in detail, and applies it to an actual application developed to teach high-school mathematical concepts.

Developing relational navigation to effectively understand software

Effective comprehension of complex software systems requires understanding of both the individual documents that represent software and the complex relationships that exist within and between documents. Relationships of all kinds play a vital role in a software engineer's comprehension of, and navigation within and between, software documents. User-determined relationships have the additional role of enabling the engineer to create and maintain relational documentation that cannot be generated by tools or derived from other relationships. We argue that for a software development environment to effectively support the understanding of complex software systems, relational navigation must be supported at both the document-focused (intra-document) and relation-focused (inter-document) levels. The need for a relation-focused approach is highlighted by an evaluation of an existing document-focused relational interface. We conclude with the requirements for a relation-focused approach to relational navigation. These requirements focus on the user's perspective when interacting with a collection of related documents. We define the requirements for a software development environment that effectively supports the understanding of the software documents and relationships that define a complex software system.

Systematic integration of human factors in the specification of requirements for new railway technologies

Engineering design processes are necessary to attain the requisite standards of integrity for high-assurance safety-related systems. Additionally, human factors design initiatives can provide critical insights that parameterise their development. Unfortunately, the popular perception of human factors as a “forced marriage” between engineering and psychology often provokes views where the ‘human factor’ is perceived as a threat to systems design. Some popular performance-based standards for developing safety-related systems advocate identifying and managing human factors throughout the system lifecycle. However, they also have a tendency to fall short in their guidance on the application of human factors methods and tools, let alone how the outputs generated can be integrated in to various stages of the design process. This case study describes a project that converged engineering with human factors to develop a safety argument for new low-cost railway level crossing technology for system-wide implementation in Australia. The paper enjoins the perspectives of a software engineer and cognitive psychologist and their involvement in the project over two years of collaborative work to develop a safety argument for low-cost level crossing technology. Safety and reliability requirements were informed by applying human factors analytical tools that supported the evaluation and quantification of human reliability where users interfaced with the technology. The project team was confronted with significant challenges in cross-disciplinary engagement, particularly with the complexities of dealing with incongruences in disciplinary language. They were also encouraged to think ‘outside the box’ as to how users of a system interpreted system states and ehaviour. Importantly, some of these states, while considered safe within the boundary of the constituent systems that implemented safety-related functions, could actually lead the users to engage in deviant behaviour. Psychology explained how user compliance could be eroded to levels that effectively undermined levels of risk reduction afforded by systems. Linking the engineering and psychology disciplines intuitively, overall safety performance was improved by introducing technical requirements and making design decisions that minimized the system states and behaviours that led to user deviancy. As a commentary on the utility of transdisciplinary collaboration for technical specification, the processes used to bridge the two disciplines are conceptualised in a graphical model.

Uma abordagem na camada de middleware para troca dinâmica de componentes em sistemas multimídia distribuídos baseados no framework Cosmos

To manage the complexity associated with the management of multimedia distributed systems, a solution must incorporate concepts of middleware in order to hide specific hardware and operating systems aspects. Applications in these systems can be implemented in different types of platforms, and the components of these systems must interact each with the other. Because of the variability of the state of the platforms implementation, a flexible approach should allow dynamic substitution of components in order to ensure the level of QoS of the running application . In this context, this work presents an approach in the layer of middleware that we are proposing for supporting dynamic substitution of components in the context the Cosmos framework , starting with the choice of target component, rising taking the decision, which, among components candidates will be chosen and concluding with the process defined for the exchange. The approach was defined considering the Cosmos QoS model and how it deals with dynamic reconfiguration

Querying Runtime Information in the IDE

Code queries focus mainly on the static structure of a system. To comprehend the dynamic behavior of a system however, a software engineer needs to be able to reason about the dynamics of this system, for instance by querying a database of dynamic information. Such a querying mechanism should be directly available in the IDE where the developers implements, navigates and reasons about the software system. We propose (i) concepts to gather dynamic information, (ii) the means to query this information, and (iii) tools and techniques to integrate querying of dynamic information in the IDE, including the presentation of results generated by queries.

Dynamically managing sensed context data

This thesis reports on an investigation of the feasibility and usefulness of incorporating dynamic management facilities for managing sensed context data in a distributed contextaware mobile application. The investigation focuses on reducing the work required to integrate new sensed context streams in an existing context aware architecture. Current architectures require integration work for new streams and new contexts that are encountered. This means of operation is acceptable for current fixed architectures. However, as systems become more mobile the number of discoverable streams increases. Without the ability to discover and use these new streams the functionality of any given device will be limited to the streams that it knows how to decode. The integration of new streams requires that the sensed context data be understood by the current application. If the new source provides data of a type that an application currently requires then the new source should be connected to the application without any prior knowledge of the new source. If the type is similar and can be converted then this stream too should be appropriated by the application. Such applications are based on portable devices (phones, PDAs) for semi-autonomous services that use data from sensors connected to the devices, plus data exchanged with other such devices and remote servers. Such applications must handle input from a variety of sensors, refining the data locally and managing its communication from the device in volatile and unpredictable network conditions. The choice to focus on locally connected sensory input allows for the introduction of privacy and access controls. This local control can determine how the information is communicated to others. This investigation focuses on the evaluation of three approaches to sensor data management. The first system is characterised by its static management based on the pre-pended metadata. This was the reference system. Developed for a mobile system, the data was processed based on the attached metadata. The code that performed the processing was static. The second system was developed to move away from the static processing and introduce a greater freedom of handling for the data stream, this resulted in a heavy weight approach. The approach focused on pushing the processing of the data into a number of networked nodes rather than the monolithic design of the previous system. By creating a separate communication channel for the metadata it is possible to be more flexible with the amount and type of data transmitted. The final system pulled the benefits of the other systems together. By providing a small management class that would load a separate handler based on the incoming data, Dynamism was maximised whilst maintaining ease of code understanding. The three systems were then compared to highlight their ability to dynamically manage new sensed context. The evaluation took two approaches, the first is a quantitative analysis of the code to understand the complexity of the relative three systems. This was done by evaluating what changes to the system were involved for the new context. The second approach takes a qualitative view of the work required by the software engineer to reconfigure the systems to provide support for a new data stream. The evaluation highlights the various scenarios in which the three systems are most suited. There is always a trade-o↵ in the development of a system. The three approaches highlight this fact. The creation of a statically bound system can be quick to develop but may need to be completely re-written if the requirements move too far. Alternatively a highly dynamic system may be able to cope with new requirements but the developer time to create such a system may be greater than the creation of several simpler systems.

Helping End-User Programmers “Engineer” Dependable Software

Not long ago, most software was written by professional programmers, who could be presumed to have an interest in software engineering methodologies and in tools and techniques for improving software dependability. Today, however, a great deal of software is written not by professionals but by end-users, who create applications such as multimedia simulations, dynamic web pages, and spreadsheets. Applications such as these are often used to guide important decisions or aid in important tasks, and it is important that they be sufficiently dependable, but evidence shows that they frequently are not. For example, studies have shown that a large percentage of the spreadsheets created by end-users contain faults, and stories abound of spreadsheet faults that have led to multi-million dollar losses. Despite such evidence, until recently, relatively little research had been done to help end-users create more dependable software.

Incentive compatible mechanisms for group ticket allocation in software maintenance services

A customer reported problem (or Trouble Ticket) in software maintenance is typically solved by one or more maintenance engineers. The decision of allocating the ticket to one or more engineers is generally taken by the lead, based on customer delivery deadlines and a guided complexity assessment from each maintenance engineer. The key challenge in such a scenario is two folds, un-truthful (hiked up) elicitation of ticket complexity by each engineer to the lead and the decision of allocating the ticket to a group of engineers who will solve the ticket with in customer deadline. The decision of allocation should ensure Individual and Coalitional Rationality along with Coalitional Stability. In this paper we use game theory to examine the issue of truthful elicitation of ticket complexities by engineers for solving ticket as a group given a specific customer delivery deadline. We formulate this problem as strategic form game and propose two mechanisms, (1) Division of Labor (DOL) and (2) Extended Second Price (ESP). In the proposed mechanisms we show that truth telling by each engineer constitutes a Dominant Strategy Nash Equilibrium of the underlying game. Also we analyze the existence of Individual Rationality (IR) and Coalitional Rationality (CR) properties to motivate voluntary and group participation. We use Core, solution concept from co-operative game theory to analyze the stability of the proposed group based on the allocation and payments.