With the recent announcement of Yammer’s purchase by Microsoft, the Social Media software companies are already scrambling to figure out their strategies.  Just last week Oracle announced the acquision of Involver, a social media comany.  This would be Oracle’s third acquisition of a social media company in the last 2 months. Salesforce has also acquired Buddy Media in the social media space.  This has left leaders like Jive scrambling to determine their next move. We at Netwoven are pretty excited about this acquisition and the impact it will make to our customer’s Social media strategies.  Microsoft’s brilliant move is remniscent of the acquisitions Microsoft made several years ago in the Collboration, Web Content Management, and Business Intelligence space.  For readers, here’s a summary of the moves Microsoft made and the impact on the technology landscape: Collaboration and Document Manaement In 2003 Microsoft released SharePoint with integrated portal and collaboration features.  This hastened the acquisition of eRoom by Documentum to better compete in this integrated environment.  Later Documenum was purchased by EMC.  Filenet and Hummingbird were also later acquired by different companies. Today, there is no standalone document management system vendors out there.  They are integrated in a smart suite (as gartner calls it). Web Content Management In early 2000, Microsoft purchased nCompass Labs to improve its web content management capabilities.  This led to the acquisition of Reddot by Livelink, followed by acquisition of Interwoven by Autonomy. Today, there are no standalone web content management system vendors out there.  They are integrated into a suite. Enterprise Search In late 2000, Microsoft purchased the FAST Search engine to improve its search capabilities.  This has already shaken the entire landscape.  Oracle has purchased several companies to better compete with Microsoft.  These companies include Stellant, and Endeca.  Opentext has purchased several companies to better compete.  Autonomy has purchased Interwoven to better compete in the integrated environment. Today, there are still a few standalone search vendors remaining.  It remains to be seen if they are able to stay independent or will be acquired by other software giants. Business Intelligence Microsoft made its first acquisition of an OLAP engine in the late 1990s.  Since then it has made several acquisitions in the BI space that has changed the complete landscape.  Today Microsoft’s BI products are tightly integrated with SharePoint.  This has led to acquisition of most of the major BI vendors.  These vendors include:  Cognos, Business Objects, Crystal Reports, Hyperion, Brio and many others. Today, there are very few standalone BI vendors remaining.  The BI landscape is constantly changing so there is an expectation that innvoation will continue in this space as Big Data is becoming a big issue for enterprises to deal with. In my opinion, the purchase of Yammer will have a significant impact equal to or greater than the other purhases and will begin the cycle of further innovations. About the Author This article is written by Niraj Tenany, President and CEO of Netwoven and a Information Management practitioner.  Niraj works with large and medium sized organizations and advises them on Enterprise Content Management and Business Intelligence strategies.  For additional information, please contact Niraj at ntenany@netwoven.com .

  Yesterday, the United States Supreme Court, in an 8-1 decision, ruled that an employer that does not know that a job applicant may need a religious accommodation can discriminate against that job applicant. All that matters are the employer’s motivations. Allow me to explain. It’s not what you know; it’s what motivates you. In EEOC v. Abercrombie & Fitch, the national apparel chain declined to hire Samantha Elauf, a practicing Muslim, because she wore a headscarf. Ms. Elauf wore the headscarf for religious reasons, but never told Abercrombie that she needed a religious accommodation for her headscarf. Still, Abercrombie assumed...

By Sarah SheardMember of the Technical StaffSoftware Solutions Division This post is the first in a series introducing our research into software and system complexity and its impact in avionics. On July 6, 2013, an Asiana Airlines Boeing 777 airplane flying from Seoul, South Korea, crashed on final approach into San Francisco International airport. While 304 of the 307 passengers and crew members on board survived, almost 200 were injured (10 critically) and three young women died. The National Transportation Safety Board (NTSB) blamed the crash on the pilots, but also said "the complexity of the Boeing 777’s auto throttle and auto flight director—two of the plane’s key systems for controlling flight—contributed to the accident." In a news report, acting NTSB chairman Christopher Hart stated that "The flight crew over-relied on automated systems that they did not fully understand." The NTSB report on the crash called for "reduced design complexity" and enhanced training on the airplane’s autoflight system, among other remediations. Since complexity is a vague concept, it is important to determine exactly what it means in a particular setting. This blog post describes a research area that the Carnegie Mellon University Software Engineering Institute (SEI) is undertaking to address the complexity of aircraft systems and software. The Growing Complexity of Aircraft Systems and Software The growing complexity of aircraft systems and software may make it difficult to assess compliance to air worthiness standards and regulations. Systems are increasingly software-reliant and interconnected, making design, analysis, and evaluation harder than in the past. While new capabilities are welcome, they require more thorough validation and verification. Complexity could mean that design flaws or defects could lead to unsafe conditions that are undiscovered and unresolved. In 2014, the Federal Aviation Administration (FAA) awarded the SEI a two-year assignment to investigate the nature of complexity, how it manifests in software-reliant systems such as avionics, how to measure it, and how to tell when too much complexity might lead to safety problems and assurance complications.  System Complexity Effects on Aircraft Safety Our examination of the effects of system complexity on aircraft safety began in October 2014 and involved several phases, including an initial literature review of complexity in the context of aircraft safety.  Our research is addressing several questions, including What definition of complexity is most appropriate for software-reliant systems? How can that kind of complexity be measured?  What metrics might apply? How does complexity affect aircraft certifiability, validation, and verification of aircraft,their systems, and flight safety margins? Given answers to the metrics questions above, we will then identify which of our candidate metrics would best measure complexity in a way that predicts problems and provides insight into needed validation and certification steps. Other questions our research will address include: Given available sources of data on an avionics system, can measurement using these metrics be performed in a way that provides useful insight? Within what measurement boundaries can a line be drawn between systems that can be assured with confidence and those that are too complex to assure? The remainder of this post focuses on the findings of our literature review, which offered insights into the causes of complexity, the impacts of complexity, and three principles for mitigating complexity. Causes of Complexity While complexity is often blamed for problems, the term is usually not defined. When we performed a systematic literature search, we found this to be the case. As a result, our literature search broadened from simply collecting definitions to describing a taxonomy of issues and general observations associated with complexity.  (This work was primarily performed by my colleague, Mike Konrad.) Our literature review revealed that complexity is a state associated with causes that produce effects. We have a large taxonomy of different kinds of causes and another taxonomy of different kinds of effects. To prevent the impacts that complexity creates, one must reduce the causes of complexity, which typically include: Causes related to system design (the largest group of causes). Components that are internally complex add complexity to the system as a whole. Also, the interaction (whether functional, data, or another kind of interaction) of the components adds complexity. Dynamic behaviors also add complexity, including numbers of configurations and transitions among them. The way the system is modeled can add complexity as well. Causes that make a system seem complex (i.e., reasons for cognitive complexity). These causes include the level of abstractions required, the familiarity a user or operator (such as the pilot) has with the system, and the amount of information required to understand the system. Causes related to external stakeholders. The number or breadth of stakeholders, their political culture, and range of user capabilities also impact complexity. Causes related to system requirements. The inputs the system must handle, outputs the system must produce, or quality attributes the system must satisfy (such as adaptability or various kinds of security) all contribute to system complexity. In addition, if any of these change rapidly, that in itself causes complexity. Causes related to the speed of technological change. The added pressure that more capable, software-reliant systems place on technologies to accomplish even more also impacts complexity. Causes related to teams. The necessity and difficulty of working across discipline boundaries, and of creating process maturity in a rapidly evolving change also contributes to complexity. Impacts of Complexity After a system is deemed complex—no matter the reason—it is important to examine the problems or benefits of that complexity. Many consequences of complexity are known and considered to be negative, including higher project cost, longer schedule, and lower system performance, as well as decreased productivity and adaptability. Also, addressing critical quality attributes (e.g., safety versus performance and usability) in a system, or achieving a desired tradeoff between conflicting quality attributes, often results in additional design complexity. For example, to reduce the probability of a hardware failure causing an unsafe condition, redundant units are frequently designed into a system. The system then not only has two units instead of one, but it also has a switching mechanism between the two units and a way to tell whether each one is working. This functionality is often supported by software, which is now considerably more complex than when there was just one unit. Complexity also impacts human planning, design, and troubleshooting activities in the following ways: Complexity makes software planning harder (including software lifecycle definition and selection). Complexity makes the design process harder. For example, existing design and analysis techniques may fail to provide adequate safety coverage of high performance, real-time systems as they become more complex. Also, it may be hard to make a safety case just from design and test data, making it necessary to wait for operational data to strengthen the safety case. Complexity may make people less able to predict system properties from the properties of the components. Complexity makes it harder to define, report, and diagnose problems. Complexity makes it harder for people to follow required processes.   Complexity drives up verification and assurance efforts and reduces confidence in the results of verification and assurance. Complexity makes changes harder (e.g., in software maintenance and sustainment). Complexity makes it harder to service the system in the field. Three Principles for Mitigating Complexity Our literature review also identified three general principles for mitigating complexity: Assess and mitigate complexity as early as possible. Focus on what in the system being studied is most problematic; abstract a model; and solve the problem in the model. Begin measuring complexity early, and when sufficient quantitative understanding of cause-effect relationships has been reached (e.g., what types of requirements or design decisions introduce complexity later in system development), establish thresholds that, when exceeded, trigger some predefined preventive or corrective action. Of course, these principles overlap, and are expressed and sorted differently by different authors. One could make the case that, in general, all practices of systems engineering started from a principle of managing complexity. The table below highlights some of the principles for managing complexity that we encountered during our literature review. Looking Ahead Our literature review also describes literature search results related to measurement and mitigation of complexity. Measurement and mitigation of complexity are the basis for the practice of good systems engineering, whether addressing collaboration among organizations and disciplines, requirements and systems abstractions and models, disciplined management and engineering, or even modular design, patterns, and refactoring. The next blog post in this series will detail the second phase of our work on this project, which focuses on determining how the breadth of aspects of complexity can be measured in a way that makes sense to system and software development projects, and specifically for aircraft safety assurance and certification. We welcome your feedback on our research. Additional Resources To read the SEI report Reliability Improvement and Validation Framework, by Peter H. Feiler, John B. Goodenough, Arie Gurfinkel, Charles B. Weinstock, and Lutz Wrage, please click here. The blog post is disseminated by the Carnegie Mellon University Software Engineering Institute in the interest of information exchange. While the research task is funded by the Federal Aviation Administration, the United States Government assumes no liability for the contents of this blog post or use thereof. The United States Government does not endorse products or manufacturers. Trade or manufacturer's names appear herein solely because they are considered essential to the objective of this blog post. The interpretations, findings, and conclusions in this report are those of the author(s) and do not necessarily represent the views of the funding agency. This document does not constitute FAA certification policy.

The Office 15 release is going to be awesome! Here are some of my notes on the Office 15 features from the presentation: The office ribbon is hidden by default All clients think cloud first, then local (skydrive, roaming profiles in the cloud) Inline reply (like gmail) Peeks (image says it all) Office clients all tie into a marketplace in the cloud, reminds me of an idea that Zaplet had back in the 2000′s Tablet radial menu Signing into your office application PDF Editing Post documents directly to FaceBook "Toasts" remind you where you last were in the document Office is now social (lots of focus on "Communication scenarios") SharePoint Mysites now suggests documents you might want to follow SharePoint Mysites allows you to use hash tags SharePoint "People cards" allow you to see all social networks that the Outlook (and office) has skype integration Flash fill allows excel worksheets to autofill across Rows auto-magicly More to come once I get back to my desk

By Julien DelangeMember of the Technical StaffSoftware Solutions Division Using the Architecture Analysis & Design Language (AADL) modeling notation early in the development process not only helps the development team detect design errors before implementation, but also supports implementation efforts and produces high-quality code. Our recent blog posts and webinar have shown how AADL can identify potential design errors and help avoid propagating them through the development process, where remediation can require massive re-engineering, delay the schedule, and increase costs. Verified specifications, however, are still implemented manually, which can lead to additional errors and might break previously verified assumptions and requirements. For these reasons, code production should be automated to preserve system specifications throughout the development process. This blog post focuses on generating code from AADL and generating configuration files for ARINC653 systems, which are used by the avionics community. Avionics and other safety-critical systems are becoming increasingly reliant on software. For example, the F-35 Lighting II is a fifth-generation fighter jet that contains more than 8 million lines of software code (LOC), four times the amount of the world’s first fifth-generation fighter, the F-22 Raptor. This upsurge in software reliance motivates the need to verify and validate requirements early in the software development lifecycle, as requirements errors are often propagated from the design phase to the implementation phase.  The remainder of this blog post gives examples of how AADL is being used to generate code for software-reliant avionics systems. AADL Model Overview AADL was approved and first published as SAE Standard AS-5506 in November 2004. Version 2.1 of the standard was published in Sept 2012. AADL uses the Open Source AADL Tool Environment (OSATE), an Eclipse-based modeling framework, to design, validate, and analyze AADL models. AADL is designed for the specification, analysis, automated integration, and code generation of real-time distributed computer systems with performance-critical requirements such as timing, safety, schedulability, fault tolerance, and security. AADL provides a new tool set to allow analysis of system and system-of-system designs prior to development and supports a model-based, model-driven development approach throughout the system lifecycle. As described in our earlier blog posts, AADL can lower development and maintenance costs by providing a standard, precise syntax and semantics for performance-critical systems, so that documentation can be well defined providing the ability to model large-scale architectures from multiple contractors in a single analyzable model that can be incrementally refined capturing the "architectural API (application programming interface)" needed to evaluate the effects of change, such as the emergent properties of integration (e.g., safety, schedulability, end-to-end latency, and security) allowing early and complete lifecycle tracking of modeling and analysis complementing functional simulation with analysis of system structure and runtime behavior providing the basis to establish a reference architecture and support product lines ARINC 653 Overview ARINC 653 (Avionics Application Standard Software Interface) is an avionics standard that defines the execution platform of software that focuses on safety and determinism. ARINC653 executes software components in separated partitions so that an error that occurs within one partition cannot impact the others. This isolation is done at two levels: Time: Each partition has a fixed, preconfigured execution time slot and cannot overuse it. Space: Each partition has a memory segment to store its code and data. Partitions can communicate only with predefined and configured communication channels, and any attempt to open an unspecified channel raises an exception. The ARINC653 standard specifies an API to create and manage software resources so that a software developer can switch from one operating system (OS) to another without significant development effort. ARINC653-compliant systems must be carefully designed to ensure that resources are correctly configured and allocated to partitions. For example, system integrators must check that a partition’s execution time is sufficient to execute system tasks or that no other communication channel will disturb the execution of critical functions. These stringent resource management requirements motivate the need for carefully specifying partitions with appropriate notation—such as AADL and its annex dedicated to ARINC653 systems, the ARINC653 annex—and analyzing to make sure that they meet designers’ requirements (time, safety, etc.). Ultimately, the models should be automatically processed by dedicated tools to configure the ARINC653 platform, avoiding hazardous manual activity, such as translating textual specifications to code. Using AADL to Generate Code for Avionics Systems Our work in the area of avionics systems focuses on generating code from AADL, which produces code for ARINC653 systems from verified models. Our approach generates the code for the different layers of the system: the ARINC653 module, which ensures time and space isolation of partitions, and its associated partitions, which contain resources to execute functional code. Auto-configuring the system from the models allows developers to use the same models for other analyses. Ultimately, automatically deriving the implementation code from the architecture model ensures that the implementation will comply with other generated materials. Moreover, auto-generating the code avoids errors introduced by manually written code. OSATE is able to generate ARINC653-compliant C code from the AADL model using a bridge to the Ocarina code generator. The generated code creates all the resources of a partition—including tasks, mutexes, and communication channels—that execute the functional code, whether it is designed using pure C code or functional modeling languages such as SCADE or Simulink. In addition to creating the partition code, OSATE can configure the underlying separation kernel to execute each partition—such as the scheduling parameter and inter-partition communication channels—at runtime. OSATE, and its Ocarina bridge, is able to generate the configuration file for two ARINC653 systems: DeOS and VxWorks653. By auto-producing the ARINC653 configuration artifacts, the user no longer needs to configure anything manually, which avoids traditional development errors such as misunderstanding  requirements or specifications and making manual coding errors. In addition, using the same model throughout the development process ensures that the configuration file reflects the architecture that was validated and analyzed during previous development steps. Two AADL Code Generation Case Studies AADL models are edited with the OSATE toolset, and the code is generated using the Ocarina AADL code generator tool. We integrated the generated code from models into two commercial ARINC653 operating systems: Deos from DDC-I VxWorks653 from Windriver Our intent was to automate the code production from the AADL models. Once AADL tools have validated the models, the system can be automatically deployed on top of different operating systems while preserving the characteristics that AADL validated when it analyzed the model. The remainder of this post describes our two applications: The ADIRU Example: generating ARINC653 XML configuration and C partition code from AADL The SCADE Example: generating code from functional (SCADE) and AADL models and integrating functional models with code generated from AADL models We applied both operating systems on these applications to demonstrate the capability of AADL to generate code on a variety of OS platforms. The ADIRU model represents an air data inertial reference unit (ADIRU) system and tries to reproduce a faulty component. The model has been presented to an AADL committee meeting, and the slides are available here. The model is composed of four main partitions: one to simulate the sensors, two for health monitoring, and another one for the solver. We used the AADL model to analyze the ADIRU model and generate the module configuration and partition code. SCADE captures the functional code—the code that corresponds to the subprograms—using C code, and we use the AADL code generator to produce the execution platform code and integrate it into an ARINC653 operating system. Inter-partition communications use AADL data and event data ports, which are translated into ARINC653 queuing and sampling ports in the ADIRU model. In the SCADE example, we generated code from SCADE that will be integrated on top of the code generated from the AADL model. The SCADE model is composed of several partitions: panel: simulates the joystick and on/off buttons from the panels that are sent to the SCADE node. We use the value 5.0 for the joystick and on for the button. sensors: simulate the sensor values sent to the panel. For this demo, we use a value of 500 for the left sensor and ?200 for the right. roll control: executes the code generated from SCADE with the inputs from the panel and sensor partitions and then sends the result to the display partition. display: simulates a display that shows if there is a warning from the left or right sensor. In the present case, according to the input values, the left-sensor warning should be activated. The goal of this experiment was to test that the model exhibits the same behavior, such as task execution order and value produced or received, in either the Deos or the VxWorks653 operating system. This assurance is very important because switching from one OS to another can be challenging: each one has specific features (i.e., task scheduling) that might change the execution behavior (task execution order). Our tool auto-generated the configuration file and preserved the execution semantics of the verified model. This demo shows the correct integration of software models: the values of the system that integrates the SCADE model are the same as the values obtained when OSATE simulated the model, showing a correct integration of the code. We captured these case studies in several videos to demonstrate the SCADE model, the AADL model, and how to generate and integrate code for both Deos and VxWorks653. Please click here to view the demos. Wrapping Up and Looking Ahead The project described in this blog post focuses on auto-generating ARINC653 module configuration and the partitioning of code from verified AADL models. Our approach not only creates the necessary code to configure the execution platform but also integrates functional models (i.e., SCADE), enabling a full zero-code development approach. The ARINC653 system was initially designed with a focus on safety. We are planning to extend and apply this work on a multiple, independent levels of security (MILS) platform, an operating system that implements software isolation for security purposes. Auto-generating the OS configuration ensures the enforcement of the security policy, such as isolation between classified and unclassified data, from the model to the code. Additional Resources For more information about AADL, please visithttp://www.aadl.info/. To view our webinar, Architecture Analysis with AADL, please visithttp://www.sei.cmu.edu/webinars/view_webinar.cfm?webinarid=424907&gaWebinar=ArchitectureAnalysiswithAADL.  

                    Here are my top 10 words or expressions that none of us should dare say at the Annual Convention under penalty of listening to Barry Manilow for 24 hours straight while reading the FMLA intermittent regulations: 10.       Matrix 9.         Synergistic alignment 8.         Sea change 7.         Paradigm shift 6          Knowledge share 5.         Change agent 4.         Value proposition 3.         Leverage best practices...

By Chris TaschnerSenior Research Engineer CERT Cyber Security Solutions DirectiveThis post is the latest installment in a series aimed at helping organizations adopt DevOps. Container-based virtualization platforms provide a means to run multiple applications in separate instances. Container technologies can provide significant benefits to DevOps, including increased scalability, resource efficiency, and resiliency. Unless containers are decoupled from the host system, however, there will be the potential for security problems. Until that decoupling happens, this blog posting describes why administrators should keep a close eye on the privilege levels given to applications running within the containers and to users accessing the host system. Containers have become the hot new technology in DevOps. One company in particular, Docker, has emerged as the go-to provider for container technology. Using the Docker platform, an application can be packaged into a unit referred to as an image, along with all its dependencies. Docker can then run instances of that image. Each instance resides within a container. Docker is becoming synonymous with DevOps. If you are unfamiliar with the benefits of containers, in a nutshell they include the readily available images and easy-to-use public repository, image versioning, and the application-centric nature of Docker. (For more information see Three Reasons We Use Docker on devops.com.) Containers also offer a lot of benefit when it comes to their size. Unlike a virtual machine, a container doesn’t need the full operating system running or a virtual copy of all of the system’s hardware. The container only needs enough of the operating system and hardware information to run the application that it is responsible for. As a result, the container can be much smaller than a virtual machine, so a host system can run far more containers than virtual machines. To minimize what the container has to run, however, there are trade-offs. One of these trade-offs is less separation between the container and the host system. In contrast, virtual machines contain much more separation from the host than a container. The Docker user requires root privileges to run the containers. Problems can arise if the Docker user does not understand what is running in the container. Often these repositories are not vetted, meaning anyone can create and post an image. Obviously, there are security implications associated with putting too much trust in containers downloaded from the internet. The problem of shared namespaces is often cited as one of the largest problems with Docker. A namespace refers to groups created by the kernel that designate access levels for different resources and areas in the system. The reason that Docker does not have different namespaces for each of its containers is scaling—if you have hundreds of containers running, each must have its own namespace. In addition, if a container wants to share storage, all namespaces sharing that storage must have explicit access to the storage. In response to some of these security concerns Docker has come out with an article detailing some concerns about how they attempt to mitigate possible issues. Included in these mitigations is guidance for limiting permissions to the server both by those with access directly to the host and by applications running within the containers. In addition to Docker’s security guidance there are others that have chimed in to provide help in securing containers. One potential solution to the issue of shared namespace is to use Seccomp, a process security tool. Daniel Walsh detailed this work-around on opensource.com. Administrators should always know exactly what your containers are running. Images downloaded from Internet repositories should be carefully vetted before being run in any sensitive environments. As a general rule, unlike the name implies, containers shouldn't be expected to contain running applications within the container. Every two weeks, the SEI will publish a new blog post offering guidelines and practical advice for organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below. Additional Resources To view the webinar Culture Shock: Unlocking DevOps with Collaboration and Communication with Aaron Volkmann and Todd Waits please click here. To view the webinar What DevOps is Not! with Hasan Yasar and C. Aaron Cois, please click here. To listen to the podcast DevOps—Transform Development and Operations for Fast, Secure Deployments featuring Gene Kim and Julia Allen, please click here. To read all of the blog posts in our DevOps series, please click here.

By Kevin Fall Deputy Director, Research, and CTOSEI Software and acquisition professionals often have questions about recommended practices related to modern software development methods, techniques, and tools, such as how to apply agile methods in government acquisition frameworks, systematic verification and validation of safety-critical systems, and operational risk management.  In the Department of Defense (DoD), these techniques are just a few of the options available to face the myriad challenges in producing large, secure software-reliant systems on schedule and within budget.In an effort to offer our assessment of recommended techniques in these areas, SEI built upon an existing collaborative online environment known as SPRUCE (Systems and Software Producibility Collaboration Environment), hosted on the Cyber Security & Information Systems Information Analysis Center (CSIAC) website. From June 2013 to June 2014, the SEI assembled guidance on a variety of topics based on relevance, maturity of the practices described, and the timeliness with respect to current events.  For example, shortly after the Target security breach of late 2013, we selected Managing Operational Resilience as a topic. Ultimately, SEI curated recommended practices on five software topics: Agile at Scale, Safety-Critical Systems, Monitoring Software-Intensive System Acquisition Programs, Managing Intellectual Property in the Acquisition of Software-Intensive Systems, and Managing Operational Resilience. In addition to a recently published paper on SEI efforts and individual posts on the SPRUCE site, these recommended practices will be published in a series of posts on the SEI blog.  This post, the first in a series by Peter Feiler, Julien Delange, and Charles Weinstock, presents the challenges in developing systems for safety-critical systems and then introduces the first three technical best practices for the software development of safety-critical systems. The second post in the series will present the remaining five practices. Safety-Critical (SC) Systems - SPRUCE / SEIhttps://www.csiac.org/spruce/resources/ref_documents/safety-critical-sc-systems-spruce-sei Our discussion of technical best practices for the software development of safety-critical (SC) systems has four parts. First, we set the context by addressing the questions "What are SC systems and why is their development challenging?" Three of the eight technical best practices for SC systems are presented below. We then briefly address how an organization can prepare for and achieve effective results from following these best practices. In addition, we have added links to various sources to help amplify a point; please note that such sources may occasionally include material that differs from some of the recommendations below. Every organization is different; judgment is required to implement these practices in a way that provides benefit to your organization. In particular, be mindful of your mission, goals, existing processes, and culture. All practices have limitations—there is no "one size fits all." To gain the most benefit, you need to evaluate each practice for its appropriateness and decide how to adapt it, striving for an implementation in which the practices reinforce each other. Monitor your adoption and use of these practices and adjust as appropriate. What are SC systems and why is their development challenging? Software systems are getting bigger and more crucial to the things we do. The focus here is on SC systems—systems "whose failure or malfunction may result in death or serious injury to people, loss or severe damage to equipment, or environmental harm." Examples of SC systems include systems that fly commercial airliners, apply the brakes in a car, control the flow of trains on rails, safely manage nuclear reactor shutdowns, and infuse medications into patients. If any of these systems fail, the consequences could be devastating. We briefly expand on several examples below. Today we take for granted "fly-by-wire" systems, in which software is placed between a pilot and the aircraft's actuators and response surfaces to provide flight control, thereby replacing wearable mechanical parts and providing rapid real-time response. Fly-by-wire achieves levels of control not humanly possible, providing "flight envelope protection" in which the aircraft's behavior around a specifiable envelope of physical circumstances (specific to that aircraft) can be accurately predicted. Pilots train on the fly-by-wire system to fly that type of aircraft safely; therefore, the loss of fly-by-wire capabilities reduces safety. To provide a medical device example, the FDA is taking steps to improve the safety of infusion pumps, whose use in administering medication (or nourishment) has become a standard form of medical treatment. Infusion pump malfunctions or their incorrect use have been linked to deaths (see "FDA Steps Up Oversight" and "Medtronic Recalls Infusion Pump"). The experience with infusion pumps has similar implications for other medical devices, such as pacemakers and defibrillators.SC systems are increasingly software-reliant, pervasive, and connected. This properties present a challenge to current development practices to successfully develop and evolve such systems while continuing to satisfy real-time and fail-safe performance. The practices covered here are intended to address such objectives as the following: rigorously anticipating and addressing scenarios for how the system might fail (and not just the typical "sunny-day scenarios") identifying defects that can lead to failure early in the lifecycle, since identifying them later in the lifecycle is generally much more expensive to correct maintaining an appropriate specification of the system requirements and architecture that summarizes what the system must do and how it must do it, which experts in nonfunctional quality attributes (timing, security, etc.) can subject to analysis ensuring that the system is evolvable and developable in increments (requirements and solutions may change) Technical Best Practices for Safety-Critical Systems 1. Use quality attribute scenarios and mission-thread analyses to identify safety-critical requirements. SC requirements are typically documented through some combination of quality attribute scenarios and mission-thread workshops. A quality attribute scenario is an extended use case that focuses on a quality attribute, such as performance, availability, security, safety, maintainability, extensibility, or testability. A mission thread is a sequence of end-to-end activities and events, given as a series of steps that accomplish the execution of one or more capabilities that the system supports. Surveys and analyses of product returns and legal actions can help identify safety and related operational concerns with existing products. In the infusion pump example, faults account for a reported 710 deaths. Like other systems, despite best efforts, SC systems may still fail, but the failure must be handled in a graceful way that protects the main asset—human lives, property, or the environment. For example, in the case of an infusion pump, the definition of a graceful failure depends on the circumstances: in some cases treatment should stop, while in other cases, such as intravenous feeding and chemotherapy, halting the treatment entirely may be more dangerous than putting out too much volume. Clearly, different failure scenarios may require different outcomes. The Quality Attribute Workshop (QAW) is one mechanism for eliciting SC quality attribute scenarios and identifying and specifying SC requirements. Challenging mission-critical requirements that create the need for novel solutions are a principal source for SC requirements. For example, high-performance military aircraft, such as the F-117 Nighthawk and the B-2 Spirit flying wing, are designed to be highly aerodynamic and highly maneuverable, qualities that are achieved by transferring stability requirements from the pilot to the flight-control software. It is no longer possible for humans to fly these aircraft unaided; instead the aircraft are largely flown by the flight-control software, which must be at least as reliable as a pair of pilots would be. The effort to identify SC requirements is ongoing and tied to the other eight practices. For instance, when developing assurance cases, it is important to provide justification that the product design or development process addresses a particular failure scenario. 2. Specify safety-critical requirements, and prioritize them. This practice highlights a few of the many important considerations in the specification of SC systems. An example of a fuller set of considerations can be found in the FAA Requirements Engineering Management Handbook. For the SC system, specify mission-critical requirements (function, behavior, performance) using, for example, state-machine representations of behavior: UML state charts, Simulink state flow, or scenario-driven threads through system functions to help derive a system's behavioral requirements safety-critical requirements (safety, reliability, security) as described in Practice 1 Inherent to the specification of a quality attribute is some kind of measure of the desired outcome, which aids in specifying the intended outcome in a scenario with greater clarity and assessing success with greater objectivity. In fact, quality attribute scenarios require some unit of measure. Measures are also important when specifying SC requirements; it is important to utilize or introduce some measure of behavior or performance as a first step to setting a threshold. Such measures can often be established by thinking through what an alternative or current approach requires: returning to our flight-control example, the probability of both the pilot and copilot suffering heart attacks over a ten-hour mission is about 10^(-9), and this establishes a reliability threshold for the software. As the system's architecture emerges, identify which component (or subsystem) each safety requirement applies to in the system, recognizing that in some cases multiple components may need to meet a requirement collectively (and possibly a derived requirement would then be specified for each component). Review the requirements, identifying which ones are safety critical and which ones are not, and which are the most important. The requirements that deserve the most attention deal with incidents that are more likely to happen or that have the most catastrophic effects. For example, for a fly-by-wire aircraft, you care about the effect a coffee pot has on the electrical system, but you don't care to the same extent that you do about the flight-control software. The latter will require many times more resources and attention than the former. Priorities should be set with stakeholders who may be able to better assess the probability of failure (technologists and end users) and the impact of failure (end users and other stakeholders) in the context of particular missions. One key to not only specifying but also prioritizing requirements is therefore knowing who your stakeholders are and determining how, when, and why you will engage them during the project. Typically, the result of prioritization is a set of requirements with associated criticality levels. You'll have requirements such as "the system must operate with some minimal functionality for some period of time" and "the system needs to be ready to take over so that if some component fails, it can fail safely with probability nine 9s (i.e., 1.0 - 10^(-9))." It is often beneficial to explore alternatives in the allocation of requirements to components because alternatives may offer superior cost/feature tradeoffs (especially when alternative architectures are also considered—see Practice 4, which will appear in Part 2 of this blog posting). Such exploration should also be considered for achieving fail-safe operation. For example, some alternatives may explore use of redundancy. You are unlikely to obtain the set of requirements right the first time, so expect some iteration through the requirements and adjustment to the allocation of requirements, especially as the architecture, priorities, and tradeoffs emerge or become better understood. 3. Conduct hazard and static analyses to guide architectural and design decisions. Apply static analyses to the specification of the system (including mission threads, quality attribute scenarios, requirements, architecture, and partial implementation), or to models derived from those specifications, to help determine what can go wrong and, if something can go wrong, how to mitigate it. The analyses result in "design points" for the components that must be safety critical. In our infusion pump example, at first glance, the design seems pretty simple. Among other things, you need a pump, something to control the rate of the motor, and a keypad for someone to enter the dosage and frequency. But when you consider manufacturing for a large market, you need to carefully consider what can go wrong and document situations that you will need to address. Note that such considerations might not have been part of the original infusion-pump concept. For example, embolisms can result when air bubbles beyond a certain size enter the patient. To protect the patient from air getting in the line of the infusion pump, you will need to design certain components of the system to prevent that from happening and other components to detect it if it does happen. From a hardware standpoint, you'll need some kind of sensor that detects air bubbles of a certain size. From a software standpoint, if an air bubble is detected, the pump will need to shut down and raise an alarm (while shutting down the pump may be harmful, an embolism is generally worse). Likewise, you'll need to ensure that these actions take place, which means you'll need redundancy or some other fault-tolerance technique to make sure that these actions happen. More generally, the development of SC systems must address several operational challenges, among them how to deal with system failure. This challenge in turn means that the system must monitor its operation to detect when a fault is going to occur (or is occurring), signal that failure is imminent or in process, and then ensure that it fails in the right way (e.g., through fault-tolerant design techniques). Depending on the degree of criticality, you might need a lot of redundancy in both the hardware and software to ensure that at the very least, the fail-safe portion of the system runs. Another approach is to implement the SC system as a state machine in which once the device reaches a failed state, it automatically transitions to a safe state (albeit not necessarily an operational state).Returning to our fly-by-wire example, both redundancy and failing to a safe state have been utilized. Such fly-by-wire aircraft systems have been designed with fourfold redundancy, which requires monitoring and voting logic to resolve disagreement among duplicated subsystems  automatic reversion to manual and mechanical backup controls, as in the Tornado airplane A rich taxonomy of architectural and design tactics have been developed over the years to help in detecting, recovering from, and preventing faults. Some static analysis methods, such as hazard analysis and failure mode and effect analysis (FMEA), have been around for decades and provide broad and proven approaches to assessing system reliability. There are several forms of FMEA, but they all undertake a systematic approach to identifying failures, their root causes, mitigations for selected root causes, and the kinds of monitoring required to detect failures and track their mitigation. The result of an FMEA can engender the need for additional design, such as to add a sensor to help identify an indication of failure or progress in its mitigation, followed by another iteration of FMEA to recalculate the risk exposure and new risk priorities, and so on. The result of a hazard analysis is a characterization of the risks and mitigations associated with high-priority hazards, including likelihood, severity of impact, how hazard will be detected, and how it will be prevented. Other analysis methods focus on how the system responds in situations of resource contention or communication corruption. These include timing studies (can critical task deadlines be met?) and scheduling analyses (e.g., to eliminate priority inversion, deadlock, and livelock). Such resource contention problems were largely solved years ago for simple processor and memory configurations, and the solutions have been progressively extended to deal with distributed systems, multilayer cache, and other complexities in hardware configuration. In our infusion-pump example, specifying the device in an appropriate formal language will allow timing studies of SC requirements to be conducted. For example, a timing study could investigate whether the air-bubble monitoring process will be able to execute frequently and consistently enough (perhaps as a function of motor speed) to ensure adequate time to shut down the pump. Some of these analyses may involve creating or generating proofs that certain components or configurations of components can achieve certain properties, using theorem provers. These high-confidence software and systems analysis techniques are particularly critical for very high-risk requirements and components. In Practices 4 and 5, we will have more to say about static analyses and will note some limits to what can currently be achieved with their use. In Practice 8, we will see that the hazard and static analyses and formal proofs described in Practice 3 feed into the development of the safety case. Looking Ahead Technology transition is a key part of the SEI’s mission and a guiding principle in our role as a federally funded research and development center.  The next post will in this series will present the remaining recommended practices for developing safety-critical systems. These practices are certainly not complete—they are a work in progress. We welcome your comments and suggestions on this series in the comments section below.Additional Resources To view the complete post on the CSIAC website, which includes a detailed list of resources for developing safety-critical systems, please visithttps://www.csiac.org/spruce/resources/ref_documents/safety-critical-sc-systems-spruce-sei.  

It’s that time of year again! 30,000 of the smartest people in HR will be heading to Sin City to talk employment policy, certification process, succession planning, performance management, employee engagement, hiring, firing and a whole lotta generational stereotyping. Indeed friends, #SHRM15 is upon us! The 2015 SHRM Annual Conference & Exposition is a superb opportunity to learn and network, but what if you aren’t keen on networking? Some of us would prefer to take in sessions, receive recertification credits and be left alone. You’ll see people in the deepest corridors of...

One of the cool new features of SharePoint 2013 is this concept of SharePoint Apps. Developers that are familiar with SharePoint 2010 will compare this with a Sandbox Solution. But that doesnt do it justice, Sandboxes are for children to play in, SharePoint Apps are for fully grown developers to develop business applications and sell them (licensing is starting to be defined). Just in the few MSDN articles that have been released about them I see stark differences. For starters SharePoint Apps can cross site collections within the same "tenant" (a new SharePoint grouping that I will cover in a future article), this was a huge limitation of a sandbox solutions. Just think of what doors this opens up now, this means that all the HR site collections that are out in a farm can now talk amongst themselves if they are listed in the same tenant. Another difference is the ability to have permissions, this means the business power user who downloads and activates an App from the App store can specify the exact permissions that app can have. No longer do you have to blindly give all 3rd party webparts complete control in your site collections. Here is an excerpt from MSDN about the app permissions (http://msdn.microsoft.com/en-us/library/office/apps/fp179922(v=office.15)): Apps for SharePoint have permissions just as users and groups do. This enables an app to have a set of permissions that are different from the permissions of the user who is executing the app. Unlike Sandbox solutions, Apps can now define their entire user interface. This means you are no longer limited to developing a webpart and hosting it inside a webpart page just to do some custom code. Think of how many times people make the comment "I want it to not look like SharePoint", well now you don’t need to put your app in SharePoint and then brand SharePoint you can use an App hosted externally and get all your SharePoint lists, libraries, and context by default. Here are the UX options you have with SharePoint Apps, and here are some guidelines when styling your App: http://msdn.microsoft.com/en-us/library/jj220046(v=office.15) There is so much more to come as I continue to fumble around in the 2013 beta preview, so stay tuned.