By Kevin Fall Deputy Director, Research, and CTOSEI This is the second installment of two blog posts highlighting recommended practices for developing safety-critical systems that was originally published on the Cyber Security & Information Systems Information Analysis Center (CSIAC) website. The first post in the series by Peter Feiler, Julien Delange, and Charles Weinstock explored challenges to developing safety critical systems and presented the first three practices: Use quality attribute scenarios and mission-tread analyses to identify safety-critical requirements. Specify safety-critical requirements, and prioritize them. Conduct hazard and static analyses to guide architectural and design decisions. This post presents the remaining five best technical best practices. Safety-Critical (SC) Systems—SPRUCE/SEIhttps://www.csiac.org/spruce/resources/ref_documents/safety-critical-sc-systems-spruce-sei4. Specify the architecture incrementally, in a formal notation.As with requirements, architectures are often specified incrementally, as new insights and risks emerge. These architectures are then communicated to developers and suppliers to align them with the selected design and implementation paths. Components with SC requirements should ideally be specified in a formal language with well-defined semantics to support rigorous model checking and theorem proving. Such notations enable evaluating the specification and predicting the component's behavior when it is successfully implemented.When the risk of making the wrong architecture decision is high, it may be necessary to consider multiple architectures and co-develop one or more of these architectures with suppliers (when there are suppliers). Appropriate stakeholders should evaluate the results to select an architecture, or multiple architectures, to pursue.We recommend to the extent possible using the same specification language (Practice 6) throughout system development for both system requirements and architecture. This commonality will enable architects and developers to(1) detect defects early (before implementation and testing) through model consistency checking and predictive analyses of operational quality attributes across requirements and solution specifications(2) allow for analysis by formal methods such as model checkers and theorem provers(3) minimize incompatible abstractions, multiple truths, and indeterminate change impactIn our presentation of these practices, we’ve separated the practices for specifying requirements from specifying architecture, but these are not serial activities in which development teams do all of one and then all of the other. Rather, requirements and design interweave and influence each other. A bit more design often yields new derived requirements, which in turn might be addressed by additional design.For example, an infusion pump needs a sensor to ensure that no air bubbles greater than a certain diameter enter the system. The presence of the sensor creates an additional point of failure, which needs to be addressed through further design. So a second sensor or other forms of redundancy are added, each of which has its own derived requirements, and the process continues.5. Sustain a virtual integration of the software through multiple levels of its specification. Applying virtual integration helps uncover issues with proposed technical solutions (candidate architectures and their implementations) before an expensive commitment to those solutions is required. Virtual integration is characterized by an "integrate then build" mindset, as opposed to the more common "build then integrate" mindset. By pursuing a virtual integration, architects can analyze and identify potential system issues so that engineers can correct their design immediately. This approach reduces development cost and avoids late delivery.In terms of current best practice, however, virtual integration is a concept not yet fully realized, except in separate, well-studied domains. It is possible to derive various domain-specific models from the specifications and subject them to domain-specific analyses, including evaluation by domain experts. But the current underlying meta-models are not yet fully semantically relatable; that is, they do not translate without loss or inconsistency in underlying semantics. These inconsistencies introduce subtly different meanings for the requirements or design. Practice 4 referred to these differences as "incompatible abstractions, multiple truths, and indeterminate change." Such different meanings would potentially invalidate transferring conclusions drawn from the static analyses to the system being developed.Nevertheless, these automated, domain-specific static analyses still offer value. They can help detect many defects early, but with some false positives and false negatives. Such automated analyses become particularly important as the complexity of the software system increases beyond the ability of a single human to comprehend it. We therefore advocate taking a virtual-integration approach when developing SC systems."Full" virtual integration is the goal of the System Architecture Virtual Integration (SAVI) Program, which is intended to advance the state of the art in virtual integration of complex systems. According to the SAVI website, SAVI aims to produce a new way of doing system integration—a virtual integration process (VIP) Models are the basis for the VIP The primary goal is to reduce the number of defects found during physical and logical system integration [resulting in] lower cost, less time Integration starts with conceptualization. "Integrate then build": Move integration forward, get it right sooner, and then keep it right as changes inevitably occur. The SAVI Program is maturing best state of the art into best practice through a number of pilot projects and transition activities. It is expected to reach best practice maturity in 2016 or 2017, according to the website. At present, we advocate pursuing virtual integration to the maximum practical extent, covering those domains posing the highest risk to the success of a project with the technology and skills available to the project.6. Use Architecture Analysis and Design Language (AADL) to formally specify requirements and architecture.The specification will need to cover interactions with the operational environment, the hardware on which the software will operate, the architecture for the software, and initial implementations for some components from a component or reuse library. Specification should also include agreements and derived requirements for components to be provided by suppliers.While other architecture definition languages have various strengths, we recommend AADL for these reasons: It has a formal definition with well-defined semantics for both software and hardware concerns. It supports specification and analysis of several quality attributes, including performance and safety. It has been proven through almost a decade of use since Version 1 in 2004. It is extensible through addition of other domains and associated static analyses. It has support from a broad community, including tools such as OSATE. The use of AADL for discovering development issues (such as safety, performance and integration) has been demonstrated in several research projects, such as SAVI. SAVI uses AADL for specifying the architecture and the main components, and AADL is the main backbone language used by SAVI. It addresses the ongoing safety-critical software development challenges by discovering issues at the earliest possible opportunity, by virtually integrating software and hardware components. 7. Monitor implementation, integration, and testing. If we’re lucky to work in a well-integrated set of mature domains, we may be able to generate all of the code from our detailed architectural specifications, perhaps through parameterization of prebuilt architectural patterns and associated code. Otherwise, and more likely, we will have to build some of the code. While the previous practices (especially Practices 3-5) have helped establish an architecture that can meet timing and other nonfunctional, safety-related requirements, implementation must proceed carefully to ensure that an architecturally conformant implementation results and that the integration proceeds smoothly. There may be some surprises. As mentioned, much of the implementation may be automatically generated from the AADL specification, which is possible in some cases, particularly when using predefined architectural templates developed for this purpose. When reusing code developed for another purpose, be alert to the possibility that the assumptions made during its initial implementation—not all of them documented—may not be appropriate in the new operational context in which it will operate. It is also necessary to carefully test the fail-safe parts of SC systems. Perhaps in part due to the general optimism with which humans approach projects and tasks, the tendency is to cover only scenarios based on the anticipated normal use, but then you and your users risk discovering that the system doesn't behave as intended during failure or restoration of system service. "Cause of Telephone System Breakdowns Eludes Investigators" and "The AT&T Crash" provide examples in which a system didn’t behave as intended during failure. An example of reusing code developed for one context and placing it in another is the Ariane 5 catastrophe, which fortunately had satellites and not humans as payload. For high-risk SC requirements and components, you might use high-fidelity models of the component annotated with formal assertions developed in a formal specification language combined with AADL (Practice 6) to specify the required behavior for that component. Then you can employ theorem proving or model checking to verify that the component’s code does in fact satisfy its specification. When architecting a system that has suppliers or draws upon code from external sources, additional care is needed to negotiate with suppliers and evaluate sources based on an understanding of the product and process capability within the appropriate product domains, relative to the project’s SC needs. Many of these activities require diligent communication with stakeholders, both in the operational environment and in the supply chain, to set expectations and ensure understanding of relevant SC requirements and the architectural, implementation, and verification approaches that will be used to address them. 8. Prepare a safety case for certification concurrent with developing the system. The question the manager responsible for developing SC software will ask is "How can I be sure that everything reasonable is being done to ensure that the developed system will behave safely in operation?" External stakeholders—in particular, regulatory agencies—will need to be sure of this too.Products that have the potential for being unsafe must go through certification or some other sort of regulatory process before being sold. Such requirements vary according to the product being built. Flight-control software in the USA is subject to Federal Aviation Administration (FAA) regulations or the non-U.S. equivalent. For an infusion pump in the USA, the Food and Drug Administration (FDA) establishes requirements. Likewise, for software to shut down a nuclear reactor, it is the Nuclear Regulatory Commission in the USA. In all three cases, software suppliers must submit documentation of what they’ve done to address safety as part of the request for certification.Apart from considering what it will take to achieve certification, your organization will not want to confront the liability arising from a catastrophe due to some oversight in how the system was designed, implemented, verified, and validated (and if applicable, manufactured). Typically, some sub-organization, perhaps Quality Assurance (QA), will take on the role of ensuring management that due diligence was (is being) taken in product development, but when it comes to systemic, critical quality attributes such as safety, taking due diligence is the responsibility of everyone involved in the development of the product. A compelling case must therefore be prepared for both internal and external stakeholders to show that the project has done all that is reasonable to ensure that the developed system will be safe in routine operation, when under stress, and if components fail. This case will reflect many of the early and ongoing considerations of a project seeking to mitigate risks to human safety.Toward this end, projects should develop an assurance case for safety, also called a "safety case." A safety case is an argument supported by evidence that the system meets its claim of safety. It provides justified confidence that the system will function as intended (with respect to the safety claim) in its environment of use. The evidence in a safety case could include process arguments, formal analysis, simulation, testing, and hazard analysis—in affect all of the techniques previously discussed. The case becomes a reviewable artifact to make development, maintenance, and evaluation significantly more effective. Special attention should be given to the fact that as SC systems become more software-reliant we rely less on failure probabilities of physical components. Software defects are design failures that will occur with probability of 1 every time the software is executed. We therefore should consider analytic redundancy approaches to mitigate such failures [reference to Lui Sha’s work on Simplex/Analytic redundancy].A compelling and thorough safety case must be planned and prepared for at the outset of a project. Indeed, a safety case can be considered an essential "component" of the product that the project will produce. As such, a safety case has requirements, a design, and content that has various functions and must be structured, as well as parts that must be related in various ways to each other and traced to the safety and regulatory requirements themselves. Because a safety case is so tightly wedded to early project design and planning considerations anyway—when the project’s needed processes, methods, tools, and skill sets will be determined—it is both prudent and efficient to begin developing the safety case early alongside the system being developed and using it to guide system development.At the beginning of system development, a safety case will be more abstract, addressing components from the top level of the product hierarchy. For example, "the infusion-pump keyboard will be resistant to errors because its keys have no bounce characteristics and because its human interface has been designed properly." As development proceeds, individual components of this argument will be extended with or supplemented by increasingly detailed arguments supported by evidence. For instance, "the keyboard has no bounce characteristics because the keyboard state is polled with high frequency to disambiguate key presses; and here are results from tests of the bounce characteristics of the selected keyboard."Initially, there will also be a focus on the processes, methods, and tools to use, but these too will get more specific (e.g., in selecting testing methods for evaluating keyboard bounce) as the system and software architecture are refined. As the project progresses, both processes and product portions of the argument will become more granular and more complete and at some point will be represented by specific results from process, method, and tool application. For example, the project manager might initially know that the project is heading toward demonstrating that the keyboard has no bounce but might not know the specific way that will be demonstrated until the keyboard is selected.As a safety case emerges, it provides context for interpreting a particular piece of evidence. For example, when provided with test results of the bounce characteristics of a particular keyboard, the manager or other stakeholders can relate that specific evidence to the broader safety case and evaluate the strengths and weaknesses of the overall argument that "this is safe because... ." As product design proceeds, you will make more decisions (e.g., to add or replicate sensors), have more claims to check, and accumulate more evidence, producing a tree of claims, which is the safety case.Thus, by concurrently developing the safety case as the system is architected and implemented, you help ensure continual attention on high-priority technical requirements and risks. You also produce an organized tree of claims linking SC requirements and architectural decisions to claims and evidence of those claims. Here, "evidence" means the results of static analyses from Practice 3, testing from Practice 7, formal methods, and process-capability arguments. For instance, "a log of many years usage has shown that this subcomponent executing in similar circumstances has not experienced a problem." Traditionally, when the device description, hazard analysis, results of testing, and other documents are filed with the appropriate regulatory agency (the FDA, in the case of the infusion pumps), there is a statutorily limited time period during which the agency reviews the documentation and makes a decision. This can be a daunting, even impossible challenge for reviewers. Typically, the reviewer probes specific claims in the documentation to assess how it supports safety rather than trying to assess every claim and all evidence.Specifically in the case of infusion pumps, the FDA has introduced a requirement that vendors include a safety case as part of their submission with the intent of eventually extending it to cover all software-reliant medical devices. The benefit for reviewers—not just at the FDA but also stakeholders inside the company and in the supply chain—is that a safety case provides a description of the product, claims about it, and a body of evidence, as well as the argument linking these together. Thus, if a reviewer has a question about particular hazards, design decisions, claims about them, or evidence, he or she can more easily relate each of these to the others and the rest of the safety case and arrive more readily at an evaluation of individual claims and the quality of the overall argument. This enables the reviewer to make more strategic use of limited review time and more rapidly identify inadequately mitigated risks for appropriate follow up."Towards an Assurance Case Practice for Medical Devices" provides a partial example of a safety case for infusion pumps. In the case of aviation, the UK MoD Defence Standard 00-56 has been requiring that a safety case be part of a vendor’s submission for a range of defense aircraft types since 2007. QinetiQ has developed an example military 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 in this series will present recommended practices for enabling agility at scale. 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.

On June 3, @shrmnextchat chatted with the #SHRM15 bloggers in an hour filled with the best tips and advice for attending the 2015 SHRM Annual Conference & Exposition.   In case you missed this amazing chat filled with great information, you can see all the tweets here:   [View the story "#Nextchat RECAP: #SHRM15 Bloggerpalooza " on Storify]  ...

By Hasan YasarTechnical ManagerCyber Engineering Solutions Group In late 2014, the SEI blog introduced a biweekly series of blog posts offering guidelines, practical advice, and tutorials for organizations seeking to adopt DevOps. These posts are aimed at the ever-increasing number of organizations adopting DevOps (up 26 percent since 2011). According to recent research, those organizations ship code 30 times faster. Despite the obvious benefits of DevOps, many organizations hesitate to embrace DevOps, which requires a shifting mindset and cultural and technical requirements that prove challenging in siloed organizations. Given these barriers, posts by CERT researchers have focused on case studies of successful DevOps implementations at Amazon and Netflix, as well as tutorials on popular DevOps technologies such as Fabric, Ansible, and Docker. This post presents the 10 most popular DevOps posts (based on number of visits) over the last six months. 1. DevOps Technologies: Fabric or Ansible In the blog post DevOps Technologies: Fabric or Ansible, CERT researcher Tim Palko highlights use cases associated with the DevOps deployment process, including evaluating resource requirements, designing a production system, provisioning and configuring production servers, and pushing code to name a few. Here is an excerpt: The workflow of deploying code is almost as old as code itself. There are many use cases associated with the deployment process, including evaluating resource requirements, designing a production system, provisioning and configuring production servers, and pushing code to name a few. In this blog post I focus on a use case for configuring a remote server with the packages and software necessary to execute your code. This use case is supported by many different and competing technologies, such as Chef, Puppet, Fabric, Ansible, Salt, and Foreman, which are just a few of which you are likely to have heard on the path to automation in DevOps. All these technologies have free offerings, leave you with scripts to commit to your repository, and get the job done. This post explores Fabric and Ansible in more depth. To learn more about other infrastructure-as-code solutions, check out Joe Yankel's blog post on Docker or my post on Vagrant. One difference between Fabric and Ansible is that while Fabric will get you results in minutes, Ansible requires a bit more effort to understand. Ansible is generally much more powerful since it provides much deeper and more complex semantics for modeling multi-tier infrastructure, such as those with arrays of web and database hosts. From an operator’s perspective, Fabric has a more literal and basic API and uses Python for authoring, while Ansible consumes YAML and provides a richness in its behavior (which I discuss later in this post). We'll walk through examples of both in this posting. To read the complete post DevOps Technologies: Fabric or Ansible please visithttp://blog.sei.cmu.edu/post.cfm/devops-technologies-fabric-or-ansible. 2. DevOps and Docker3. Development with Docker Docker is quite the buzz in the DevOps community these days, and for good reason. Docker containers provide the tools to develop and deploy software applications in a controlled, isolated, flexible, and highly portable infrastructure. In the post DevOps and Docker, CERT researcher Joe Yankel introduces Docker as a tool to develop and deploy software applications with substantial benefits to scalability, resource efficiency, and resiliency. Here is an excerpt: Linux container technology (LXC), which provides the foundation that Docker is built upon, is not a new idea. LXC has been in the linux kernel since version 2.6.24, when Control Groups (or cgroups) were officially integrated. Cgroups were actually being used by Google as early as 2006, since Google has always been looking for ways to isolate resources running on shared hardware. In fact, Google acknowledges firing up over 2 billion containers a week and has released its own version of LXC containers called lmctfy, or "Let Me Contain That For You." Unfortunately, none of this technology has been easy to adopt until Docker came along and simplified container technology, making it easier to utilize. Before Docker, developers had a hard time accessing, implementing, or even understanding LXC let alone its advantages over hypervisors. DotCloud founder and current Docker chief technology officer Solomon Hykes was on to something really big when he began the Docker project and released it to the world as open source in March 2013. Docker's ease of use is due to its high-level API and documentation, which enabled the DevOps community to dive in full force and create tutorials, official containerized applications, and many additional technologies. By lowering the barrier to entry for container technology, Docker has changed the way developers share, test, and deploy applications. In the post Development with Docker, Yankel offers a tutorial on how to get started developing software with Docker in a common software development environment by launching a database container (MongoDB), a web service container (a Python Bottle app), and configuring them to communicate forming a functional multi-container application. Here is an excerpt: If you haven’t learned the basics of Docker yet, you should go ahead and try out their official tutorial here before continuing. To get started, you need to have a virtual machine or other host that is compatible with Docker. Follow the instructions below to create the source files necessary for the demo. For convenience, download all source files from our github repository and skip to the demo section. Our source contains a Vagrant configuration file that allows you to run the demo in an environment that will work. See our introductory post about Vagrant here. To read the complete post, DevOps and Docker, please visithttp://blog.sei.cmu.edu/post.cfm/devops-docker-015. To read the complete post Development with Docker, please visithttp://blog.sei.cmu.edu/post.cfm/development-with-docker. 4. DevOps Case Study: Amazon AWS Regular readers of the DevOps blog will recognize a recurring theme in this series: DevOps is fundamentally about reinforcing desired quality attributes through carefully constructed organizational process, communication, and workflow. By studying well-known tech companies and their techniques for managing software engineering and sustainment, our series of posts can gain valuable real-world examples for software engineering approaches and associated outcomes. These case studies also serve as excellent case studies for DevOps practitioners. In the post DevOps Case Study: Amazon AWS, C. Aaron Cois explores Amazon’s experience with DevOps. Here is an excerpt: Amazon is one of the most prolific tech companies today. Amazon transformed itself in 2006 from an online retailer to a tech giant and pioneer in the cloud space with the release of Amazon Web Services (AWS), a widely used on-demand Infrastructure as a Service (IaaS) offering. Amazon accepted a lot of risk with AWS. By developing one of the first massive public cloud services, they accepted that many of the challenges would be unknown, and many of the solutions unproven. To learn from Amazon’s success we need to ask the right questions. What steps did Amazon take to minimize this inherently risky venture? How did Amazon engineers define their process to ensure quality? Luckily, some insight into these questions was made available when Google engineer Steve Yegge (a former Amazon engineer) accidentally made public an internal memo outlining his impression of Google’s failings (and Amazon’s successes) at platform engineering. This memo (which Yegge has specifically allowed to remain online) outlines a specific decision that illustrates CEO Jeff Bezos’s understanding of the underlying tenets of what we now call DevOps, as well as his dedication to what I will claim are the primary quality attributes of the AWS platform: interoperability, availability, reliability, and security. To read the complete post DevOps Case Study: Amazon AWS, please visithttp://blog.sei.cmu.edu/post.cfm/devops-casestudy-amazon-aws-036. 5. DevOps Case Study: Netflix and the Chaos Monkey While DevOps is often approached through practices such as Agile development, automation, and continuous delivery, the spirit of DevOps can be applied in many ways. In this blog post, C. Aaron Cois examines another seminal case study of DevOps thinking applied in a somewhat out-of-the-box way by Netflix. Here is an excerpt: Netflix is a fantastic case study for DevOps because their software-engineering process shows a fundamental understanding of DevOps thinking and a focus on quality attributes through automation-assisted process. Recall, DevOps practitioners espouse a driven focus on quality attributes to meet business needs, leveraging automated processes to achieve consistency and efficiency. Netflix’s streaming service is a large distributed system hosted on Amazon Web Services (AWS). Since there are so many components that have to work together to provide reliable video streams to customers across a wide range of devices, Netflix engineers needed to focus heavily on the quality attributes of reliability and robustness for both server- and client-side components. In short, they concluded that the only way to be comfortable handling failure is to constantly practice failing. To achieve the desired level of confidence and quality, in true DevOps style, Netflix engineers set about automating failure. To read the complete post DevOps Case Study: Netflix and the Chaos Monkey, please visithttp://blog.sei.cmu.edu/post.cfm/devops-case-study-netflix-and-the-chaos-monkey. 6. DevOps and Agile Melvin Conway, an eminent computer scientist and programmer, coined Conway’s Law, which states: Organizations that design systems are constrained to produce designs which are copies of the communication structures of these organizations. Thus, a company with front-end, back-end, and database teams might lean heavily towards three-tier architectures. The structure of the application developed will be determined, in large part, by the communication structure of the organization developing it. In short, form is a product of communication. In the post DevOps and Agile, C. Aaron Cois looks at the fundamental concept of Conway’s Law applied to the organization itself. Here is an excerpt: The traditional-but-insufficient waterfall development process has defined a specific communication structure for our application: Developers hand off to the quality assurance (QA) team for testing, QA hands off to the operations (Ops) team for deployment. The communication defined by this non-Agile process reinforces our flawed organizational structures, uncovering another example of Conway’s Law: Organizational structure is a product of process. To read the complete post DevOps and Agile, please visithttps://blog.sei.cmu.edu/post.cfm/devops-agile-317.  7. ChatOps in the DevOps Team Conversations between key stake holders of a project team (e.g., developers, business analyst, project manager, and security team)  and the platform on which communication occurs can have a profound impact on that collaboration. Poor or unused communication tools lead to miscommunication, redundant efforts, or faulty implementations. On the other hand, communication tools integrated with the development and operational infrastructures can speed up the delivery of business value to the organization. How a team structures the infrastructure on which they communicate will directly impact their effectiveness as a team. In the post ChatOps in the DevOps Team, CERT researcher Todd Waits introduces ChatOps, a branch of DevOps that focuses on communications within the DevOps team. The ChatOps space encompasses the communication and collaboration tools within the team: notifications, chat servers, bots, issue tracking systems, etc. Here is an excerpt: In a recent blog post, Eric Sigler writes that ChatOps, a term that originated at GitHub, is all about conversation-driven development. "By bringing your tools into your conversations and using a chat bot modified to work with key plugins and scripts, teams can automate tasks and collaborate, working better, cheaper and faster," Sigler writes. Most teams have some level of collaboration on a chat server. The chat server can act as a town square for the broader development teams, facilitating cohesion and providing a space for team members to do everything from blowing off steam with gif parties to discussing potential solutions to real problems. We want all team members on the chat server. In our team, to filter out the noise of a general chat room, we also create dedicated rooms for each project where the project team members can talk about project details that do not involve the broader team. More than a simple medium, the chat server can be made intelligent, passing notifications from the development infrastructure to the team, and executing commands back to the infrastructure from the team. Our chat server is the hub for notifications and quick interactions with our development infrastructure. Project teams are notified through the chat server (among other methods) of any build status they care to follow: build failures, build success, timeouts, etc. To read the complete post ChatOps in the DevOps Team, please visithttp://blog.sei.cmu.edu/post.cfm/chatops-in-devops-team-029. 8. DevOps Technologies: VagrantEnvironment parity is the ideal state where the various environments in which code is executed behave equivalently. The lack of environment parity is one of the more frustrating and tenacious aspects of software development. Deployments and development both fall victim to this pitfall too often, reducing stability, predictability, and productivity. When parity is not achieved, environments behave differently, which makes troubleshooting hard and can make collaboration seem impossible. This lack of parity is a burden for too many developers and operational staff.  In the blog post DevOps Technologies: Vagrant, CERT researcher Tim Palko describes Vagrant, which is a developer's tool that provides a virtualized and provisioned environment to developers using operations tools with a single, declarative script and a simple command-line interface. Vagrant increases development and environment parity by using the same preconfigured (scripted) environment across all developers or in production. Vagrant eliminates the "it works on machine" excuse in application development lifecycle Here is an excerpt: The job of an operations team often involves implementing full parity across deployment environments, such as those used for testing, staging, and production. Conversely, the development team is almost entirely responsible for provisioning development machines. To achieve 100 percent parity between both sets of environments, both teams must speak the same language and use the same resources. Chef and Puppet, both crafted for the operations role, are just slightly out of reach for a busy developer. Each has a respectable learning curve, and neither really solves the parity problem completely: developers still need to virtualize the correct production target platform. All this additional work incurs a decent amount of overhead when you just want to write code! This is where Vagrant comes in. Vagrant is a developer's tool that basically serves up a virtualized and provisioned environment to developers using operations tools with a single, declarative script and a simple command-line interface. Vagrant cuts out the grunt work needed to stand up a virtual machine (VM) and it removes the need to configure or run, for example, chef-server and chef-client. Vagrant hides all of this and leaves the developer with a simple script, an extensionless file named Vagrantfile, which can be checked into source control along with the code. To read the complete post DevOps Technologies: Vagrant, please visithttps://blog.sei.cmu.edu/post.cfm/devops-technologies-vagrant-345. 9. Addressing the Detrimental Effects of Context Switching with DevOps In a computing system, a context switch occurs when an operating system stores the state of an application thread before stopping the thread and restoring the state of a different (previously stopped) thread so its execution can resume. The overhead incurred by a context switch managing the process of storing and restoring state negatively impacts operating system and application performance. In the blog post Addressing the Detrimental Effects of Context Switching with DevOps, CERT researcher Todd Waits describes how DevOps ameliorates the negative impacts that "context switching" between projects can have on a software engineering team’s performance. Here is an excerpt: In the book Quality Software Management: Systems Thinking, Gerald Weinberg discusses how the concept of context switching applies to an engineering team. From a human workforce perspective, context switching is the process of stopping work in one project and picking it back up after performing a different task on a different project. Just like computing systems, human team members often incur overhead when context switching between multiple projects. Context switching most commonly occurs when team members are assigned to multiple projects. The rationale behind the practice of context switching is that it is logistically simpler to allocate team members across projects than trying to have dedicated resources on each project. It seems reasonable to assume that splitting a person’s effort between two projects yields 50 percent effort on each project. Moreover, if a team member is dedicated to a single project, that team member will be idle if that project is waiting for something to occur, such as completing paperwork, reviews, etc. Using our computing system metaphor, this switching between tasks is similar to the concept of multi-threading, where if one thread blocks the process for some reason, other threads can perform other work, rather than waiting for the first thread to unblock. If all work was assigned only to the first thread, progress is much slower. While multi-threading may be sound reasoning in computing systems, the problem is that human workers don’t always get a nice 50-50 effort distribution. Effort is thus lost to context switching, and productivity may drop precipitously as the worker’s effort is spread across more projects. To read the complete post Addressing the Detrimental Effects of Context Switching with DevOps, please visithttp://blog.sei.cmu.edu/post.cfm/addressing-detrimental-effects-context-switching-devops-064. 10. What is DevOps? Typically, when we envision DevOps implemented in an organization, we imagine a well-oiled machine that automates infrastructure provisioning code testing application deployment Ultimately, these practices are a result of applying DevOps methods and tools. DevOps works for all sizes, from a team of one to an enterprise organization. In the post, What is Devops, CERT researcher Todd Waits presents the foundations of DevOps.  DevOps can be seen as an extension of Agile methods. It requires all the knowledge and skills necessary to take a project from inception through sustainment to be contained within a dedicated project team. Organizational silos must be broken down. Only then can project risk be effectively mitigated. Here is an excerpt: While DevOps is not, strictly speaking, continuous integration, delivery, or deployment, DevOps practices do enable a team to achieve the level of coordination and understanding necessary to automate infrastructure, testing, and deployment. In particular, DevOps provides organizations a way to ensure collaboration between project team roles infrastructure as code automation of tasks, processes, and workflows monitoring of applications and infrastructure Business value drives DevOps development. Without a DevOps mindset, organizations often find their operations, development, and testing teams working toward short-sighted incentives of creating their infrastructure, test suites, or product increment. Once an organization breaks down the silos and integrates these areas of expertise, it can focus on working together toward the common, fundamental goal of delivering business value. Well-organized teams will find (or create) tools and techniques to enable DevOps practices in their organizations. Every organization is different and has different needs that must be met. The crux of DevOps, though, is not a killer tool or script, but a culture of collaboration and an ultimate commitment to deliver value. To read the complete post What is DevOps, please visithttps://blog.sei.cmu.edu/post.cfm/what-is-devops-324. Every two weeks, the SEI will publish a new blog post that offers guidelines and practical advice to 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.

          Another very cool new feature of SharePoint 2013 is its Request Management capabilities. This pairs up an old feature in 2010 called "Resource Throttling" with a new feature called Routing Rules. These Resource Rules allow you to redirect traffic coming to your farm based on the following properties: Url UrlReferrer UserAgent Host IP HttpMethod SoapAction CustomHeader The operators that you can use on these rules are: StartsWith, EndsWith, Equals, and even RegEx. This is a very similar function that you might already have in your application load balancers (F5, Cisco). So what does this mean to my SharePoint Farms? Well Request Manager allows you to now direct traffic to Web Front Ends that are tailored to the type of requests. An example of this is that one of my clients makes heavy use of the SharePoint Client Object Model, so there are tons of web service calls. For that scenario we could setup a SharePoint WFE that has IIS settings tuned for web services. Another example I have faced in the wild is a department that want faster responses, or dedicated resources. So in the scenario where an entire company shares one SharePoint Farm, departments within the company may want the flexibility to pay for faster responses or dedicated resources. With Request Manager you now can let Marketing buy a server for your farm, add it, and then use Request Manager to direct all marketing site collections (based on URLs) to this pool of WFEs that Marketing bought. Another example would be housing mission critical apps on the same farm as non-critical apps. You can direct all traffic of the mission critical applications to your faster more powerful front ends, and your non critical apps to the older hardware. I think it will be interesting to see some performance metrics (once Microsoft provides them) on how much of a hit your farm takes implementing these rules. My guess is that this is great for small IT shops that have 2 or 3 servers but don’t want to invest in a network application that load balances and directs traffic. But big companies that have network appliances in place will continue using their proven technics. Also keep in mind in a virtualize SharePoint environment it is best practice to offload the software load balancers (MS NLB) to a network appliance for performance issues. So I would assume the same holds true for Request Manager’s routing rules. Last thing I want to mention is a gotcha with RM; if you implement the routing rules and a request does not meet any of them it will be discarded. Yup, it just throws it away. So to make sure this doesn’t happen we suggest implementing a catch all rule, put it at the bottom in Execution Group 2, and have it catch all requests. Read more at the MSDN training for IT Pros: http://technet.microsoft.com/en-us/sharepoint/fp123606.aspx

A towering yellow excavator dug into packed dirt and placed it into the back of a dump truck.  As the truck backed up, it let out a loud, "BEEP... BEEP... BEEP..." and forced an awkward explanation to my co-workers on the other end of the conference call.  I'd spend a good part of my afternoon that day watching the construction site outside of my office. All the while, reminiscing about when I was a kid playing with my trucks and action figures in the dirt. Kids do it all the time, why can't we? Adults who play are shown to...

By Jeff BolengPrincipal ResearcherAdvanced Mobile Systems Initiative In their current state, wearable computing devices, such as glasses, watches, or sensors embedded into your clothing, are obtrusive. Jason Hong, associate professor of computer science at Carnegie Mellon University, wrote in a 2014 co-authored article in Pervasive Computing that while wearables gather input from sensors placed optimally on our bodies, they can also be "harder to accommodate due to our social context and requirements to keep them small and lightweight." For soldiers in battle or emergency workers responding to contingencies, seamless interaction with wearable devices is critical. No matter how much hardware soldiers wear or carry, it will be of no benefit if they have to stop what they are doing to interact while responding to enemy fire or another emergency situation. This blog post describes our joint research with CMU’s Human Computer Interaction Institute (HCII) to understand the mission, role, and task of individual dismounted soldiers using context derived from sensors on their mobile devices and bodies to ensure they have the needed information and support. A Model for Context-Aware Computing In beginning this research, we partnered with Dr. Anind Dey, an early pioneer in context-aware computing and director of HCII. Dey wrote one of the seminal papers on contextual computing, "Understanding and Using Context," while completing his doctoral work at Georgia Institute of Technology. At HCII, Dey researches sensors and mobile technology to develop tools and techniques for understanding and modeling human behavior, primarily within the domains of health, automobiles, sustainability, and education. Our collaboration with Dey and other HCII researchers aims to use burgeoning computing capabilities that are either worn on users’ bodies and/or tied to users’ smartphones through the infrastructure of a cloud. We want to ensure this technology works with the user in an unobtrusive way and anticipates the user’s informational and other needs. Helping Soldiers on the Battlefield Through our joint research effort, we developed a framework and a data model that involved codifying a soldier’s role and task within the context of a larger group mission. We then examined data streams available from sensors on smart phones that soldiers use in the field. We augmented our experimentation with other body-worn sensors. Take the example of an explosives disposal technician sent to investigate an unexploded ordnance. As the technician approaches it, his or her smartphone or wearable device, sensing the location, would automatically disable all wireless communications used by the technician, and any of those in use by nearby soldiers, that could trigger the ordnance. Other nearby wearable devices or smartphones that remain a safe distance away may then send notifications to other soldiers in the unit to retreat to a standoff distance. Another scenario might involve a wearable camera. As the technician approaches an explosive device, a wearable camera, such as Google Glass, could conduct object detection and recognition. The camera would then, ideally, provide information, such as type of device, amount of yield, type of fuse, or whether the device is similar to one that had been previously defused. The camera may even provide common disabling techniques without the soldier having to scroll through options or issue commands. Knowing a soldier’s mission, role, and task, our framework incorporates all the sensory data—including audio, video, and motion sensors—and then delivers information that, ideally, is the most appropriate for a soldier in a given scenario. We then extended the framework for a group context because soldiers and first responders almost always work in teams. A group of soldiers or emergency responders have a mission, and, based on that mission, they all have roles they have to fulfill (for instance, radio, gunner, or commander). Based on those roles and that mission, they all have a number of tasks they must complete. We developed a framework and mobile device prototype that would share context among all the handheld devices used by a team working on a mission to help the team coordinate tasks most effectively. Testing Our Framework in the (Paintball) Field Each of the smartphones or wearable devices that we experimented with had, on average, between eight and 12 raw sensor streams tracking temperature barometric pressure location data from GPS received signal strength from various local wireless networks inertial measurement unit (IMU) measured by six-axis devices that not only detail whether a user is moving up, down, left, or right, but which also provide accelerations rates for each plane Next, we designed several scenarios that were representative of small-unit tactics, everything from an ambush to a patrol to a coordinated retreat. We decided to test our scenarios in paintball sessions because the feedback mechanism (the sting of being struck by a paintball) provided enough incentive for the volunteers (who were drawn from the 911th Airlift Wing) to react realistically. At an outdoor paintball course, we attached sensors to the bodies of our volunteers. We then filmed the volunteers in scripted scenarios and recorded the sensory data streams. Relying on activity recognition research, we then took the data from a dozen high-bandwidth (high-sampling-rate) streams for each volunteer and determined, based on those sensor streams, the activity of the volunteer and also the larger context the group was performing. This work is another area in which we are collaborating with Dey. We tested two approaches: Taking the individual sensor streams and recognizing each individual activity (leveraging machine learning), then looking at the activities performed by each volunteer to try to infer a group activity. Taking all the raw sensor feeds from all of the volunteers directly into the machine-learning algorithms. This approach allowed us to jump from raw data to the understanding that, for example, a group of soldiers is under attack or retreating without first exploring the individual context. Currently, we are examining the raw sensory data captured during the paintball exercises and labeling it. By so doing, we are trying to determine, for example, whether an individual was running, retreating, or part of an entire group that was being ambushed and returning fire. With the video capture providing a ground truth of their activity, we run the raw sensory data in every combination we can think of through the machine-learning algorithms and try to determine which sensor streams (and combination of sensor streams) are most accurately able to predict an individual’s activity. For example, in some instances we needed to combine the inertial measurement unit data from the leg and the head to accurately predict the individual’s position. The benefit of using machine-learning algorithms is that they are classifiers and relatively opaque to data. We can combine any set of sensor streams to the classifiers and compare it to the labeled data for accuracy. This comparison allows us to effectively determine which sensor streams are most applicable to recognize each type of individual and group activity. We conducted three paintball exercises in 2014 and, using the vast amount of data we recorded, developed trained models. We then applied these trained models to help recognize individual and group activity. Our objective was to use all those data streams to infer an individual’s activity or physical position and then determine how those inferences relate to the individual’s pre-defined set of roles and tasks. For example, it is not enough to know that someone’s role is "disposal technician"; it is also beneficial to provide particular phases of the mission. For example, is our disposal technician getting suited up? If so, it would be of value to provide background information on the layout of the site that the technician is traveling to. Once a technician arrives at the ordnance, he or she would require different information: What type of device am I looking at? How big should my safety cordon be? How do I dismantle the device? How do I warn people? Am I able to warn people? Results and Challenges We conducted three rounds of paintball exercises, and our results improved with each exercise. In our first two exercises, with certain combinations of the sensors, we were able to identify exaggerated behaviors for an individual (i.e., running or falling) with 90 percent accuracy. While other researchers have conducted similar work in this field, our objective was to recognize group behavior in addition to individual behavior. Our aim is to determine whether a squad is under attack before a member of the squad must spend precious seconds to radio that information back to a command center or supporting forces. Knowing immediately when soldiers in a squad have come under fire will allow the forward operating base to deploy support seconds or even minutes earlier. One challenge we currently face is that models trained for a general population do not perform as accurately for specific individuals. Once we apply a general model to an individual, one of our future challenges is to learn the quirks of a particular person, for example, if an individual runs with a slightly different gait from everyone else in the world. Our objective is onboard continuous learning so that the model becomes personalized to an individual. This personalization will enable us to do highly accurate activity recognition and information delivery. Another challenge that we faced—and we are not the first people to have this challenge—is to simplify the logistics of working with human volunteers. Simply coordinating volunteers, sensors, wireless data gathering, and cameras proved hard. We learned that it worked best to be very specific in our communications: laying out a strict agenda and informing volunteers of the agenda. After the exercises, we also faced massive amounts (hundreds of gigabytes) of data including video and raw sensor data. We wrote several utilities that automate distillation of the data. We also wrote some apps that would pull the data off the cameras automatically during an experiment and archive them on a local hard drives. In addition, we wrote a remote control app for the cameras on the Android phones that were distributed around the paintball field. Looking Ahead Soldiers today carry much of the same gear their predecessors have carried for the last several decades (a radio, water, personal protective gear, ammunition, and weapons). Currently, soldiers pay a price to have computing on the battlefield. The hardware is heavy, the batteries are heavier still, and battery life is not optimal. Right now, the benefits of computing have not been sufficiently beneficial for soldiers and first responders to pay the price to carry the weight and deal with the added complexity. Our work in this area will continue until wearable computers are less intrusive, especially for soldiers, and they bring benefits and an information advantage that clearly offsets the added weight and complexity. We welcome your feedback on our research in the comments section below. Additional Resources To listen to the podcast SEI-HCII Collaboration Explores Context-Aware Computing for Soldiers, which provides additional details on the SEI's research collaboration with Dr. Dey's group, please click here.  To read "Understanding and Using Context" by Anind Dey, please visithttp://www.cc.gatech.edu/fce/ctk/pubs/PeTe5-1.pdf. To learn about the research of the Advanced Mobile Systems Initiative, please visithttp://www.sei.cmu.edu/about/organization/softwaresolutions/mobile-systems.cfm.

Key facts: IDC estimates that in 2010 alone we generated enough digital information worldwide to fill a stack of DVDs reaching from the earth to the moon and back. That’s about 1.2 zettabytes, or more than one trillion gigabytes - a 50% increase over 2009. IDC further estimates that from 2011 on, the amount of data produced globally will double every 2 years. Every 2 days we generate more data than we did from the dawn of time through 2003 Worldwide volume of data is growing at 59% per year Between 75% and 85% of data is unstructured In 5 years the majority of analytic data will come from unstructured sources The industry calls this the "Big Data" problem. It is typically a data collection that has grown so big that it has become difficult to handle it using conventional Relational Data Management system or search systems. This includes data that was too voluminous, complex or fast-moving to be of much use before, such as meter or sensor readings, event logs, Web pages, social network content, email messages and multimedia files. As a result of this evolution, the Big Data universe is beginning to yield insights that are changing the way we work. As a result, the world of business intelligence is changing. The user community is demanding new forms of business intelligence applications. Most of these new forms of BI require technologies that have been around for some time, but have been alien for most business intelligence environments until now: search technology. Although search technology and business intelligence technology have both been around for A long time, they have lived separate lives. The business intelligence community hasn’t really adopted search technology nor has search technology seriously entered the business intelligence market. In this article we introduce search based BI applications and its business benefits. What is Search Based Application (SBA)? Imagine an application with which users can look up customer or product information. In a more traditional application the user sees a number of input fields for entering data, such as name and address. The application then tries to find the right customers or products. In most cases, nothing will be found if the entered values are not correct. Search Based Business Intelligence Applications Search based application is a new category of application that enables users to find information from any source and in any format With a search-based application, the user can enter anything he knows about the customer or product, and the search engine will try to find those customers or products that resemble the keywords entered by the user. It’s a more free format search. Search based applications integrate data from various sources and provide a single unified view. Why Search Based Applications? Amazingly fast Highly scalable Low cost Deeper insight What are business benefits of Search Based BI Application? Easy to use interface that end users understand Enables the integration and search of any data source Search Across Multiple Sources Easily integrates structured and unstructured data sources Indexes the sources in Real Time Provided Assisted Navigation To Filter the Search Results there by reducing the time it takes to find information Ability to display results in highly visual and interactive form For additional information on how to create search based applications using FAST search, click here to download our conference material presented by Newoven consultants. About Netwoven 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.

  To read the June 2015 SHRM Leading Indicators of National Employment Report, please click here.   ...

By Joe YankelMember of the Technical StaffCERT Cyber Security Solutions Directorate This post is the latest installment in a series aimed at helping organizations adopt DevOps. Since beginning our DevOps blog in November, and participating in webinars and conferences, we have received many questions that span the various facets of DevOps, including change management, security, and methodologies. This post will address some of the most frequently asked questions. How does Change and Release Management integrate with DevOps? First off, the DevOps culture involves embracing change. One of the core principles of DevOps, the second of the Three Ways according to Gene Kim, is to amplify feedback loops. The Second Way is the continual, iterative feedback loop allowing us to respond quickly to customer needs. This feedback loop is where change management comes into play. Often, change management occurs when things don't work the way you expected, or the customer (who can be internal or external) decides that a change should be made to increase business value. This type of change is OK. In fact you should embrace it. Without DevOps and the encouragement of continuous integration (CI) and continuous delivery (CD), a requested change usually didn't occur until after an official release. But with CI and CD in place teams can achieve faster and more frequent releases. Our customers therefore potentially see those changes in their products earlier. These rapid updates allow them to more quickly evaluate the product and their own requirements, which in turn leads to change requests. Let's face it, nothing brings about a change to requirements quite like actually seeing and using the product. In such an iterative environment/process how do you ensure that security requirements are always considered? Should we have a security person also in the DevOp process? Security must be a first-class citizen throughout the DevOps processes. Here is the typical Venn diagram you see describing DevOps. Actually, security is often overlooked, and its circle is not even pictured. When describing secure DevOps, which we preach here at the SEI’s CERT Division, the diagram should look like this Security must always be considered and a security expert should be involved in the DevOps process from the beginning. You cannot expect a developer or an operations team member to make the necessary security decisions for a given project. If security is a concern (and these days it should always be a concern) to your business, then there is obviously room for a full-role dedicated to a primary subject matter expert in security/privacy. Your developer or operations professional should be an expert on topics such as data privacy intrusion detection threat vectors Common Vulnerabilities and Exposures (CVEs) package security authentication authorization security standards compliance Microsoft has worked on a Security Development Lifecycle that shows how to include security into a project's lifecycle. The bottom line is that a security professional should collaborate with your DevOps team from the beginning of a project, because this individual will think of security-related items that others in the room will not, and you'll be glad for it. Is DevOps used for Agile methodology only or can it be really useful for any kind of development life cycle? DevOps is really an extension of Agile methodologies, but it is also more of a culture or philosophy (See the Three Ways link in the first question). You can adopt DevOps without practicing Agile methodologies since there is clearly more to DevOps than just your software development lifecycle (SDLC), but it may be harder. Agile certainly compliments DevOps with its iterative processes more than other SDLC's, such as the Waterfall model.  You can still be successful without following Agile methods, but software development projects typically realize more successes with Agile practices. Every two weeks, the SEI will publish a new blog post that offers guidelines and practical advice to 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.

I am on the fence about this new feature of SharePoint 2013. I guess I drank the Kool-Aid about how the ribbon was the best UI invention every, and how your average user will perform 95% of all actions in the first tab. So when I got to play around with the 2013 preview I was ehhh about the ribbon being hidden by default. I had to click on a document then click on the ribbon to get my actions for that document. Introducing an extra click for a user is a little puzzling, but I guess MS got such negative feedback about how "in your face" the ribbon was in 2010 that they had to change it in SharePoint 2013. So what is the alternative? SharePoint 2013 gives us a new list of common actions (and preview) in their new Ellipsis feature. This is probably the answer that will your users are looking for when they come and ask you what happened to the drop down, or how do I access the actions with a single click. As you can see from the screen shot, there are only 3 actions available though (Share, Edit, and Follow). New Ellipsis options for a word document: What if your users demand that the ribbon shows when they click on the document? I wrote a quick little script using the new mQuery (see my future post about what mQuery is) that clicks the "Files" or "Items" tab when you click on an item. EnsureScriptFunc("mquery.js", "m$", function() { m$("#onetidDoclibViewTbl0 > tbody > tr").click( function() { m$(".ms-cui-ct-first > a").click(); }); }); Before: After: