Process Driven Software Engineering Environments

Software development organizations have begun using Software Engineering Environments (SEEs) with the goal of enhancing the productivity of software developers and improving the quality of software products. The encompassing nature of a SEE means that it is typically very tightly coupled with the way an organization does business. To be most effective, the components of a SEE must be well integrated and the SEE itself must be integrated with the organization. The challenge of tool integration increases considerably when the components of the environment come from different vendors and support varying degrees of “openness”. The challenge of integration with the organization increases in a like manner when the environment must support a variety of different organizations over a long period of time. In addition to these pressures, any SEE must perform well and must “scale” well as the size of the organization changes. This paper proposes basing the Software Engineering Environment on the software development process used in an organization in order to meet the challenges of integration, performance, and scaling. The goals and services of distributed operating systems and Software Engineering Environments are outlined in order to more clearly define their roles. The motivation for using a well defined software development process is established along with the benefits of basing the Software Engineering Environment on the software development process. Components of a SEE that could effectively support the process and provide integration, performance, and scaling benefits are introduced along with an outline of an Ada program used to model the proposed components. The conclusion provides strong support for process driven SEEs, encourages the expansion of the concept into other “environments,” and cautions against literal interpretations of “process integration” that may slow the acceptance of this powerful approach

BUILDING SOFTWARE AT SCALE: UNDERSTANDING PRODUCTIVITY AS A PRODUCT OF SOFTWARE ENGINEERING INTRINSIC FACTORS

During our education at KSU, we have learned about various factors that affect productivity such as schedule, budget, and risks, but those are often controlled outside of what we could learn as software engineering principles, patterns, or practices. On top of that, other off-work factors such as health conditions, emotional distress, or political climate, just to name a few, could drastically affect the productivity of a software engineering team. We see a demarcation between those factors that affect productivity in software engineering but are not inherent to the discipline itself, which we call resistance factors, and the factors that are inherent to the discipline and drive productivity, which we call intrinsic factors. Intrinsic factors are driven by the way we learn software engineering in schools and the way we practice it in industry. During the master’s coursework in software engineering, we identified three intrinsic inputs that play a solemn role in how we build and deliver software at scale: people, processes, and tools. This thesis first provides an enriched understanding of each of the 3 factors listed above. It is an essential step to establish contextual reasoning about those factors before diving into deeper discussions concerning how those factors can drive software engineering productivity. A software engineering environment is the assembly of a team of people producing software following a defined set of processes and leveraging a specified set of tools. In a particular software engineering environment, each of those inputs will exist in some state, and those states will interact with each other to realize a nominal productivity; that is the raw potential of software to be effectively produced at scale in that environment accepting all other factors are equal elsewhere. To borrow electrical engineering language, it is the open-circuit voltage of software engineering team. That is the productivity potential that would have been attained if there were no resistance and zero risks, which we call here the nominal productivity. A nominal productivity framework exhibiting the interactions of those intrinsic inputs\u27 states will be introduced to help analyze and understand their effect on productivity. We will then conduct some theoretical experiments with this framework and review the theorical findings with industry and academia experts to evaluate the fidelity of the framework. We warn here that the goal of this thesis is not to validate the framework itself, and we recommend readers not to assess the quality of the paper by the validity of the framework introduced, but the scientific approach in answering the research questions and any advances that may fall from it. The framework introduced, if nothing else, would serve as tool to software engineering managers to evaluate their current software engineering environment and prioritize the factors that need the most investment to build an effective and high performing team

The Synergistic Engineering Environment

The Synergistic Engineering Environment (SEE) is a system of software dedicated to aiding the understanding of space mission operations. The SEE can integrate disparate sets of data with analytical capabilities, geometric models of spacecraft, and a visualization environment, all contributing to the creation of an interactive simulation of spacecraft. Initially designed to satisfy needs pertaining to the International Space Station, the SEE has been broadened in scope to include spacecraft ranging from those in low orbit around the Earth to those on deep-space missions. The SEE includes analytical capabilities in rigid-body dynamics, kinematics, orbital mechanics, and payload operations. These capabilities enable a user to perform real-time interactive engineering analyses focusing on diverse aspects of operations, including flight attitudes and maneuvers, docking of visiting spacecraft, robotic operations, impingement of spacecraft-engine exhaust plumes, obscuration of instrumentation fields of view, communications, and alternative assembly configurations.

Interfacing Oz with the PCTE OMS

This paper details our experiment interfacing Oz with the Object Management System (OMS) of PCTE. Oz is a process-centered multi-user software development environment. PCTE is a specification which defines a language independent interface providing support mechanisms for software engineering environments (SEE) populated with CASE tools. Oz is, in theory, a SEE that can be built (or extended) using the services provided by PCTE. Oz historically has had a native OMS component whereas the PCTE OMS is an open data repository with an API for external software tools. Our experiment focused on changing Oz to use the PCTE OMS. This paper describes how several Oz components were changed in order to make the Oz server interface with the PCTE OMS. The resulting system of our experiment is an environment that has process control and integration services provided by Oz, data integration services provided by PCTE, and tool integration services provided by both. We discusses in depth the concurrency control problems that arise in such an environment and their solutions. The PCTE implementation used in our experiment is the Emeraude PCTE V 12.5.1 supplied by Transtar Software Incorporation

A STUDY ON THE MANAGEMENT OF SOFTWARE ENGINEERING CAPABILITIES IN JAPAN USING PANEL ANALYSIS

We designed a survey on software engineering excellence (SEE) and administered it in 2005, 2006 and 2007 with the Japanese Ministry of Economy, Trade and Industry to better understand the mechanism of how software engineering capabilities relate to IT vendors’ business performance and business environment. We measured the SEE survey results with regard to seven factors: deliverables, project management, quality assurance, process improvement, research and development, human development, and contact with customers. In this paper, we integrated 233 valid responses to the SEE surveys received over three years into a new database and identified 151 unique IT firms. We conducted panel analyses of the seven SEE factors using the three years of data to clarify what influence SEE factors have within a year, year-to-year, and mid-term. Based on the results of the panel analysis, our first observation is that most SEE factors for a year had significant positive influences on the same factors the next year. Second, there were three paths to improving the level of deliverables through project management, quality assurance and research and development in a year. Third, some SEE factors had significant positive influence on different SEE factors in the following year. Fourth, there were some negative paths, implying that effort put toward a particular factor did not pay off during the duration of our research. These efforts, however, might be expected to have longer-term effects on other SEE factors

A synchronous cooperative architecture for the PROSOFT software engineering environment

This paper shows the evolution of a software engineering environment (SEE) called PROSOFT to support the formal development of groupware applications. This environment, which is centered in the data-driven approach for software development, evolved to support cooperation in the software development process. Its transition is founded in a client/server communication model called Distributed PROSOFT that provides software mechanisms to permit concurrent use of the environment resources. Thus, this paper presents a formal model that provides an object middleware with synchronous handling and version support for the objects created with the software tools integrated to the environment. Cooperative PROSOFT is presented as an architecture for the formal development of groupware applications that permits the formal validation of cooperative applications specified under its paradigm. A consequence of this work is the integration of the advantages found in formal specification techniques to the groupware development that provides the development of higher quality groupware applications than those obtained with the use of traditional techniques.Ingeniería de SoftwareRed de Universidades con Carreras en Informática (RedUNCI

Teaching software engineering project management-A novel approach for software engineering programs

In response to real and perceived short-comings in the quality and productivity of software engineering practices and projects, professionally-endorsed graduate and post-graduate curriculum guides have been developed to meet technical developments and evolving industry demands. Each of these curriculum guidelines identifies better software project management skills as critical for all graduating students, but they provide little guidance on how to achieve this. One possible way is to use a serious game - a game designed to teach and educate players about some of the dynamic complexities of the field in a safe and inexpensive environment. This paper presents the results of a qualitative research project that used a simple game of a software project to see if and how games could contribute to better software project management education. Initial results suggest that suitably-designed games are able to teach software engineering and project management concepts at higher-order Bloom taxonomy levels

Lessons learned applying CASE methods/tools to Ada software development projects

This paper describes the lessons learned from introducing CASE methods/tools into organizations and applying them to actual Ada software development projects. This paper will be useful to any organization planning to introduce a software engineering environment (SEE) or evolving an existing one. It contains management level lessons learned, as well as lessons learned in using specific SEE tools/methods. The experiences presented are from Alpha Test projects established under the STARS (Software Technology for Adaptable and Reliable Systems) project. They reflect the front end efforts by those projects to understand the tools/methods, initial experiences in their introduction and use, and later experiences in the use of specific tools/methods and the introduction of new ones

State Analysis Database Tool

The State Analysis Database Tool software establishes a productive environment for collaboration among software and system engineers engaged in the development of complex interacting systems. The tool embodies State Analysis, a model-based system engineering methodology founded on a state-based control architecture (see figure). A state represents a momentary condition of an evolving system, and a model may describe how a state evolves and is affected by other states. The State Analysis methodology is a process for capturing system and software requirements in the form of explicit models and states, and defining goal-based operational plans consistent with the models. Requirements, models, and operational concerns have traditionally been documented in a variety of system engineering artifacts that address different aspects of a mission s lifecycle. In State Analysis, requirements, models, and operations information are State Analysis artifacts that are consistent and stored in a State Analysis Database. The tool includes a back-end database, a multi-platform front-end client, and Web-based administrative functions. The tool is structured to prompt an engineer to follow the State Analysis methodology, to encourage state discovery and model description, and to make software requirements and operations plans consistent with model descriptions