By C. Aaron CoisSoftware Engineering Team LeadCERT Cyber Security Solutions Directorate This post is the latest installment in a series aimed at helping organizations adopt DevOps. DevOps can be succinctly defined as a mindset of molding your process and organizational structures to promote business value software quality attributes most important to your organization continuous improvement As I have discussed in previous posts on DevOps at Amazon and software quality in DevOps, 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, I am going to look at another seminal case study of DevOps thinking applied in a somewhat out-of-the-box way: Netflix. 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. If you have ever used Netflix software on your computer, a game console, or a mobile device, you may have noticed that while the software is impressively reliable, occasionally the available streams of videos change. Sometimes, the ‘Recommended Picks’ stream may not appear, for example. When this happens it is because the service in AWS that serves the ‘Recommended Picks’ data is down. However, your Netflix application doesn’t crash, it doesn’t throw any errors, and it doesn’t suffer from any degradation in performance. Netflix software merely omits the stream, or displays an alternate stream, with no hindered experience to the user—exhibiting ideal, elegant failure behavior. To achieve this result, Netflix dramatically altered their engineering process by introducing a tool called Chaos Monkey, the first in a series of tools collectively known as the Netflix Simian Army. Chaos Monkey is basically a script that runs continually in all Netflix environments, causing chaos by randomly shutting down server instances. Thus, while writing code, Netflix developers are constantly operating in an environment of unreliable services and  unexpected outages. This chaos not only gives developers a unique opportunity to test their software in unexpected failure conditions, but incentivizes them to build fault-tolerant systems to make their day-to-day job as developers less frustrating. This is DevOps at its finest: altering the development process and using automation to set up a system where the behavioral economics favors producing a desirable level of software quality. In response to creating software in this type of environment, Netflix developers will design their systems to be modular, testable, and highly resilient against back-end service outages from the start. In a DevOps organization, leaders must ask: What can we do to incentivize the organization to achieve the outcomes we want? How can we change our organization to drive ever-closer to our goals? To master DevOps and dramatically improve outcomes in your organization, this is the type of thinking you must encourage. Then, most importantly, organizations must be willing to make the changes and sacrifices necessary (such as intentionally, continually causing failures) to set themselves up for success. As evidence to the value of their investment, Netflix has credited this ‘chaos testing’ approach to giving their systems the resiliency to handle the 9/25/14 reboot of 10 percent of AWS servers without issue. The unmitigated success of this approach inspired the creation of the Simian Army, a full suite of tools to enable chaos testing, which is now available as open source software. 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.

Adrian Stone I’m halfway through a 12-week Junior WebOps training program in DWP. It covers topics and skills that are essential to creating and maintaining user-centred digital services at DWP. I’ve completed another block and gained another huge stack of knowledge. It’s been a tough one for all of us, I think. At week 6 of 12, the fatigue is kicking in a bit. Don't get me wrong, it's great to be learning so much, and the course and camaraderie means it’s always fun, but the intensity can be exhausting. There is so much knowledge to take in, retain, embed - a restful weekend will do us all the world of good, I’m sure. Web programming Block 2 covered a lot of the ‘Web’ side of WebOps. This involved looking at how to use cutting-edge web technologies, as well as the importance of building websites for all kinds of platforms such as desktops, smartphones and tablets. It’s been fascinating to get an insight into how some of the websites we use every day actually look 'under the hood'. Understanding these technologies will be invaluable when it comes to building and maintaining systems on the live projects we’ll soon be working on. Version control We also spent some time learning version control using a system known as "Git". This is a simple but powerful version control tool. It enables developers and others working on projects to keep a tight control over any type of code, plus any associated documentation. The WebOps training room in the Leeds transformation hub Using Git, a developer can work on their code separate from the 'live' code. This is important when maintaining live systems used by tens of thousands of people. Being able to constantly test and iterate outside the live environment means we can be far more creative in our technical problem solving. Git is the de facto standard these days (and it's free, too). Embracing industry standards It’s great that government departments are embracing industry-standard tools now, as it means developers coming into government from the private or voluntary sectors can get straight to work using the tools they are already used to, and be productive from day one. WebOps training It’s also good for those of us in government, as we’re developing skills that will be relevant across the tech industry if we spend some time working outside government in future. Looking forward to looking back We finished this week, as we do every week, with an agile 'retrospective'. Here, we look back on the past few days’ teaching, thinking about what went well, what didn't go so well, and what could be improved upon. These sessions really help us to reflect on the week and consolidate our learning, and we all look forward to them. There’s the added bonus that by reviewing what we’ve been taught, how we’ve been taught it, and what could’ve gone better, we know that we are helping to improve the learning experience for ourselves and for future cohorts - always a nice way to end the week.

Most employees think flexibility is critical to their job satisfaction: are employers listening? The latest SHRM Job Satisfaction and Engagement survey confirms what many in HR already know: the flexibility to balance life and work issues is important to almost every employee - with 91% of workers polled saying it was either very important (55%) or important (36%) to their job satisfaction. Yes, there were differences between the sexes - 97% of women rated it as either very important or important compared with 85% of men but even...

By Christopher AlbertsPrincipal EngineerCERT Division Software is a growing component of systems used by Department of Defense (DoD), government, and industry organizations. As organizations become more dependent on software, security-related risks to their organizational missions are also increasing. Despite this rise in security risk exposure, most organizations follow a familiar pattern when managing those risks. They typically delay taking aggressive action to mitigate security risks until after a software-reliant system has been deployed (i.e., during the operation and maintenance of the system). This blog post highlights the Security Engineering Risk Analysis (SERA) Framework, a new approach developed by researchers in the CERT Division at the Carnegie Mellon University Software Engineering Institute to help organizations reduce operational security risks by proactively designing security controls into software-reliant systems (i.e., building security in up front, rather than retrofitting it as an afterthought).  Three Main Causes of Operational Security Vulnerabilities In examining the origin of operational security vulnerabilities, our team of researchers noted that they generally have three main causes: design weaknesses implementation/coding system configuration errors Over the years, significant effort (e.g., research, tool development, guidance) has been directed toward addressing vulnerabilities caused by implementation/coding issues and system configuration errors. As a result, implementation/coding vulnerabilities can be corrected during system operation and maintenance through the dissemination of security patches by vendors. In addition, secure coding practices, such as those developed by researchers on CERT’s Secure Coding Team, can proactively prevent the occurrence of certain implementation/coding vulnerabilities. System configuration vulnerabilities can be prevented (or corrected) by following accepted operational security practices, such as implementing appropriate authentication and authorization controls. The SERA research team—in addition to me, the team includes Carol Woody and Audrey Dorofee—believes that it is important to focus on correcting design weaknesses because they are so pervasive. MITRE’s Common Weakness Enumeration (CWE) provides a community-developed view of software weaknesses. As of February 2014, design-related issues account for 40 percent of the 940 total CWEs. In addition, 76 percent of the top 25 most-dangerous CWEs are design weaknesses. We are also focusing on design weaknesses because security is often neglected during early lifecycle activities. Addressing design weaknesses as soon as possible is especially important because these weaknesses are not corrected easily after a system has been deployed. Remediation of design weaknesses normally requires extensive changes to the system, which is costly and often proves to be impractical. As a result, software-reliant systems with design weaknesses often are allowed to operate under a high degree of residual security risk, putting their associated operational missions in jeopardy. Our initial research suggested that applying traditional security risk-analysis methods earlier in the lifecycle will not solve the problem because those methods cannot handle the inherent complexity of modern cybersecurity attacks. Traditional methods of identifying risk focus on the simple, linear view that assumes a single threat actor exploiting a single vulnerability in a single system to cause an adverse consequence. Our experience shows that most cyber-attacks are much more complicated. For example, consider the Target breach of late 2013. This attack was not the result of a single vulnerability that allowed the criminals to access tens of millions of credit cards and personal information including names, addresses, and other personally identifiable information. The cybercriminals instead targeted a subcontractor in the Pittsburgh area and exploited its infrastructure to gain trusted access into the Target infrastructure. From the initial entry point, they were able to exploit vulnerabilities in multiple systems in Target’s infrastructure to access the data that they wanted. Ultimately, this attack included multiple systems across two organizations. This complexity of the Target attack is not unique. Multiple actors often exploit multiple vulnerabilities in multiple systems as part of a complex chain of events. Our research indicated that a new approach was needed to handle these types of security risks. The solution that we developed, the Security Engineering Risk Analysis (SERA) Framework, focuses on minimizing design weaknesses by integrating two important technical perspectives: (1) system and software engineering and (2) operational security. The SERA Framework defines an engineering practice for analyzing risk in software-reliant systems that are being acquired and developed, with the ultimate goal of building security into those systems. The tasks specified in the framework are designed to be integrated with a program’s ongoing system engineering, software engineering, and risk management activities. Four Tasks of the SERA Framework The SERA Framework specifies the following four tasks: Establish operational context. The first task defines the operational context for the analysis. In this task, the Analysis Team (i.e., an interdisciplinary team of 3-5 people that leads the risk analysis) identifies the system of interest for the analysis (typically the system that is being acquired or developed) and then determines how the system of interest supports operations (or is projected to support operations if the system of interest is not yet deployed). The team develops models of the most critical workflows or mission threads that are supported by the system of interest.Each software application or system typically supports multiple operational workflows or mission threads during operations. The goal is to (1) select which operational workflow or mission thread the team will include in the analysis and (2) document how the system of interest supports the selected workflow or mission thread. The team develops additional models that describe the technologies that support each workflow or mission thread and how data flows among those technologies. These models establish a baseline of operational performance for the system of interest. The team then analyzes security risks in relation to this baseline. Identify Risk. The second task specified in the framework focuses on risk identification. In this task, the Analysis Team transforms security concerns into distinct, tangible risks that can be described and measured. Task 2 comprises the following steps: a. The team starts by reviewing operational models generated by the first task. The team then identifies a threat that is causing concern as well as the sequence of steps required for that threat to be realized. b. The Analysis Team then describes how each threat might affect the workflow or mission thread as well as selected stakeholders (i.e., established the consequences produced by the threat). c. Finally, the Analysis Team creates the narrative for the security risk scenario and compiles all data related to the scenario in a usable format.It is important to note that the steps specified in the second task must be performed for each risk that is identified. Analyze Risk. During this task the Analysis Team evaluates each risk in relation to predefined criteria to determine its probability, impact, and risk exposure. This evaluation involves several steps: a. Establish probability. A risk’s probability provides a measure of the likelihood that the risk will occur. In this step, the Analysis Team subjectively determines and documents the probability of the occurrence for the security risk scenario. b. Establish impact. A risk’s impact is a measure of the severity of a risk’s consequence if the risk were to occur. The Analysis Team analyzes and documents the impact of the security risk scenario. c. Determine risk exposure. Risk exposure measures the magnitude of a risk based on the current values of probability and impact. The team determines the risk exposure for the scenarios based on the individual values for of probability and impact documented in the previous two steps in this task. Develop Control Plan. The fourth task in the framework focuses on establishing a plan for controlling a selected set of risks. The Analysis Team first prioritizes the security risk scenarios based on their risk measures. Once priorities have been established, the team determines the basic approach for controlling each risk based on pre-defined criteria and current constraints (e.g., resources and funding available for control activities.) For each risk that is not accepted, the Analysis Team develops a control plan that indicates • how the threat can be monitored and the actions taken when it is occurring (recognize and respond) • which protection measures can be implemented to reduce vulnerability to the threat and minimize any consequences that might occur (resist) • how to recover from the risk if the consequences or losses are realized (recover) A subset of the control actions will have implications for the software (or system) requirements and design. The team must determine which actions might affect the requirements or design of the system of interest and document them for further analysis. Our technical note, Introduction to the Security Engineering Risk Analysis (SERA) Framework, provides examples for all four SERA tasks. Key Differentiators The SERA Framework incorporates three key features that differentiate it from other security risk assessments: Use of operational models. Traditional security-risk assessments rely on a tacit understanding of the operational context in which a software-reliant system must operate. Our experience indicates that tacit assumptions are often incorrect or incomplete, which adversely affects the results of a security risk analysis. The SERA Framework uses operational models to describe a system’s operational context explicitly and establish a baseline of operational performance to inform the risk identification and analysis. Semantic structure to document security risks. Most traditional assessments rely on linear, simplistic formats for recording risks (e.g., if-then statements). These basic structures fail to capture the complexities and nuances of modern cybersecurity attacks. To address this deficiency, the SERA Framework uses scenarios to document a cybersecurity risk and create fairly complex risk scenarios. A security risk scenario conveys information describing how one or more threat actors can exploit multiple systems to cause adverse consequences for stakeholders. A scenario essentially chains multiple basic risks together to describe how an attack might actually occur in the real world. Shared view of a system, its operational context, and its associated security risks. The SERA Framework presents a view of the system that is easily understood by multiple stakeholders including system and software engineers, security experts, and program managers. As a result, complex security risks can be evaluated effectively and then prioritized based on their impact to the operational mission of the system. These differentiators distinguish the SERA Framework from other security risk assessment of analysis approaches. They also provide the basis for analyzing complex, multi-faceted security risk scenarios early in the acquisition lifecycle. Collaborations We collaborated with Dr. Travis Breaux of CMU’s Institute for Software Research in the School of Computer Science and a renowned expert in the fields of risk management and security requirements. One aspect of Dr. Breaux’s research is exploring the roles that that expertise plays in eliciting risk. We were able to build upon this research as we developed the SERA Framework. Looking Ahead and Future Work Software is a growing component of systems across all government and industry sectors. The SERA Framework is a first step in our ongoing research to help program managers establish reasonable confidence that (1) a software-reliant system will function as intended when deployed and (2) its cybersecurity risk will be kept within an acceptable tolerance over time. The initial results from applying the SERA Framework are promising. However, we have many additional research and development activities to complete. Here, we briefly highlight two of those activities. The first is using threat archetypes (i.e., a pattern or model illustrating the key characteristics of a complex threat scenario) to facilitate risk identification. The second is working to help organizations comply with new legislative mandates, such as National Institute of Standards and Technology (NIST) 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems, which provides guidance for applying the NIST Risk Management Framework (RMF) to federal information systems. We welcome your feedback on our research. Please leave feedback in the comments section below. Additional Resources For a more detailed explanation of our research please read our recent technical note, Introduction to the Security Engineering Risk Analysis (SERA) Framework, which is available here.

DWP Technology is delivering new digital technology to meet user needs - as shown by the Carer’s Allowance Digital Service which now has 90% user satisfaction. Like all businesses, we also need to keep an eye on performance of our existing, complex, large enterprise technology estate. Our pensions, disability services, working age benefits, child maintenance and Universal Credit technology is used to annually pay £165bn for 7 million claims. These services are running at 100% uptime this year. But the systems used by 90,000 staff across 950 locations to interact with 22 million citizens have not been updated for decades. Systems were designed in isolation resulting in integration issues accumulating over the years - preventing Operations colleagues from working efficiently. The last 80 days have seen an 82% productivity improvement as a result of resolving the top outstanding IT issues. Five things stood out in the retrospective: Acknowledge the problem: Three months ago, 41 of our best people came together and acknowledged that we were not delivering a service to be proud of. You had to be in the room to feel the determination to drive change. A dedicated, integrated team: We stood up a multi-disciplinary team across organizational boundaries, with DWP experts working alongside colleagues from HP, Accenture, IBM, TCS, Atos and Cap Gemini. This team had a singular goal to resolve 40 longstanding issues. Expertise triumphed over hierarchy and contracts as a group of colleagues became a team. Begin and end with user needs: Team members sat with users to understand the issues from their perspective. These conversations helped us understand what would make the most difference to Operations users. As sprints delivered solutions, the users tested solutions in the real world across offices. Sprint to outcomes: Ambitious goals were broken down into manageable pieces of work tackled via specific sprints. Daily calls and stand-ups were used to drive progress, identify and tackle blockers, share knowledge and support problem solving to deliver at pace. Conversations were about delivering specific things, not planning to deliver. Leadership: A  group of leaders was inspired to achieve the impossible and followed through with tenacity to deliver impossible goals. The team built big relationships to listen to each other and do more together than what anyone could have done within their team. Our strategy is to deliver The results speak for themselves - in the last 80 days service hours lost due to IT issues across our IT estate have plummeted by 82%. 40 top issues have been fixed and the team also delivered: Automated interfaces to remove rekeying and errors between 2 of our major customer data systems Automated production of reports Reduced processing time by up to 1 hour per case for a system while eliminating slow-running transactions on another system, saving 15 seconds per case Reduced the time to logon to virtual desktops by over 50%. I am proud to have the opportunity to work with colleagues delivering exceptional results. Improving service to our Operations colleagues helps them to deliver excellent service to DWP’s customers.

By John Klein, Senior Member of the Technical StaffSoftware Solutions Division Acquisition executives in domains ranging from modernizing legacy business systems to developing real-time communications systems often face the following challenge:Vendors claim that model-driven engineering (MDE) tools enable developers to generate software code automatically and achieve extremely high developer productivity. Are these claims true? The simple answer might be, "Yes, the state of the practice can achieve productivity rates of thousands of function points and millions of lines of code per person-month using MDE tools for automatic code generation." The complicated reality is that MDE consists of more than code generation tools; it is a software engineering approach that can impact the entire lifecycle from requirements gathering through sustainment. While one can make broad generalizations about these methods and tools, it is more useful to consider them in the context of a particular system acquisition. Aligning MDE methods and tool capabilities with the system acquisition strategy can improve system quality, reduce time to field, and reduce sustainment cost. On the other hand, when MDE methods and tools do not align with the acquisition strategy, using them can result in increased risk and cost in development and sustainment. This blog post highlights the application of MDE tools for automatic code generation (in the context of the full system lifecycle, from concept development through sustainment) and also provides a template that acquirers can use to collect information from MDE tool vendors. Foundations of Our Work: AADL Researchers at the SEI have been doing work in MDE for several decades. In particular, Peter Feiler and Julien Delange have been working with the Architecture Analysis and Design Language (AADL) modeling notation for use in real-time embedded systems, safety-critical systems, and other high-assurance systems. Their work has focused on analysis and an up-front assurance that the system will function as intended, with less emphasis on code generation. This latest SEI MDE effort—in addition to me, the team included Harry Levinson and Jay Marchetti—focuses more on code generation, specifically in the context of business systems with code generation benefits realized by the developer. As detailed in our technical note, Model-Driven Engineering: Automatic Code Generation and Beyond, while certain domains can achieve extremely high productivity using model-driven approaches, it is important to realize that code generation is just one small piece of the entire software lifecycle. In software engineering, there is a tight coupling between the system domain (e.g., business system, command and control system, or avionics system), the methods used throughout the system lifecycle, and the tools used to support the chosen methods. Furthermore, government acquirers have the challenge of selecting contractors to develop their systems. This selection process includes evaluating the development team, the development methodology, and the tools in the context of the system acquisition strategy. Or, to state it more simply, in MDE, if you develop code using one tool it can be expensive to switch to another tool later in the software development lifecycle. In addition to acquiring code, therefore, software acquirers should also consider the tools needed to sustain the software. When an organization adopts a model-driven approach, it is also adopting a particular toolset and technology. These additional adoptions are of particular concern in the Department of Defense (DoD), where the focus is on acquiring and maintaining longer-lived systems. In many commercial contexts, there is less hesitation to rebuild a system from scratch. Code Generation in Business Systems Firms such as Gartner, Forrester, and IDC have focused their analyses of MDE technology on commercial IT developers and software providers. As stated earlier, our analysis focused on the unique acquisition concerns of the DoD and other federal agencies in which systems are acquired and maintained for longer periods of time. Specifically, we examined business systems since this is an area where code generation tools are having significant impact. This analysis included existing technologies and approaches used for commercial off-the-shelf technologies (COTS), and it investigated how those same principles can be applied to the acquisition of MDE tools. We used the PECA Method (Plan, Establish Criteria, Collect Data, Analyze Results) to organize an acquirer’s technology assessment, and used an established risk framework to identify criteria within the overall process. Acquisition Strategy Implications An acquisition strategy specifies which artifacts and data rights to acquire, as well as which artifacts to evaluate at each program decision point. The acquisition strategy also defines the approach to identifying, managing, and mitigating program risks. The use of MDE for automatic code generation has several implications for acquisition strategy, including the following: artifacts, data rights, and licenses. Development tooling is usually not a significant concern when acquiring software-intensive systems, but it can be a significant concern when acquiring a system developed using an MDE approach, particularly when using MDE for automatic code generation. In MDE-developed software, the models are the primary development artifacts, embodying the software architecture design and component designs, and ultimately driving the automatic code generation. Ideally, all software sustainment and evolution will also use the MDE approach, which requires data rights and necessary licensing for the tools, models, and generated code. When only the automatically generated source code is acquired (without the models used to generate the code), then sustainment and evolution are more difficult because the automatically generated code is not structured for human readability and comprehension. design review scope and timing. The acquirer must review and evaluate appropriate artifacts at the right time in the acquisition cycle. For example, in an approach using MDE for automatic code generation, the software architecture documentation may consist of a subset of the code-generation model, along with accompanying documentation, to provide context and design rational. The software architecture should be evaluated early in the design process (as discussed by Bergey and Jones). The evaluation scope and criteria, however, may need to be expanded to account for the use of the model not just to represent the architecture for communications among stakeholders but also to directly generate the executing software. Finally, reviewers may need to use the MDE tools to view the models—exporting the model into a generic format, such as portable document format (PDF) files, may not provide adequate visual resolution and the ability to efficiently navigate through the model. Tool availability and access to the network where the model is stored become issues that the acquirer must address in planning the evaluation. impact on program risk. While an MDE approach promises automatic code generation, improvement of cost and schedule, reduction of technical risk by enabling early analysis, and the ability to demonstrate capabilities and validate requirements by using executable models or rapid prototypes, it also introduces new risks, including the following (see our technical note for a more detailed accounting of risks introduced by an MDE approach to automatic code generation.): - a development-time dependency on the tool chosen to support the process. The chosen tool is used to create and modify the model, which is then processed to generate the code. Unlike traditional source code, which can be created and modified by many different tools, the state of the market for MDE tools is that, in most cases, a model can be edited and modified only by the tool that created it, and changing tools may require rebuilding the entire model. - cybersecurity assurance. As noted earlier, development time and run-time dependencies have several implications for cyber assurance. For example, as cybersecurity policy and practices evolve, the tool may generate compliant code (e.g., code that is compatible with required authorization mechanisms, access control policies, or encryption practices). - run-time portability. Portability concerns manifest as a desire to execute the automatically generated code in several environments, each comprising different hardware and software infrastructure. These concerns may also manifest as a desire to change the system’s hardware and software infrastructure over time. - runtime performance. The automatically generated code must satisfy the system’s runtime throughput, latency, concurrent request processing, and other performance quality requirements. While the use of an MDE approach may provide early confidence that these requirements can be met, if one or more of these requirements change, there is a risk that the automatically generated code may not satisfy the new requirement. - usability of generated user interfaces. In some system domains, such as business systems, the MDE tools may generate user interfaces as part of the automatically generated code. The generated user interfaces may support functions such as system configuration and administration, system monitoring, and end-user activities. A Template for Collecting Information from MDE Tool Vendors To help business system acquirers select and evaluate MDE tools, we have created a questionnaire template to use during the "Collect Data" step in the process, which can be downloaded here. Our accompanying technical note provides detailed guidance on how to interpret responses during the "Analyze Results" step. To develop the template, we started by reviewing guidance about how to develop criteria for developing a tool based on your program-specific acquisition issues. We wanted to understand particular risk areas that may or may not be relevant for a program. We also wanted to understand how the use of MDE tools could help mitigate some risks but also introduce or increase other risks. We also relied on earlier SEI research that created a risk taxonomy. We used that taxonomy to examine how MDE approaches can either help mitigate some of those risks or may introduce risks to a program. Wrapping Up and Looking Ahead Our premise through all of our analysis of MDE methods and tools is that it is impossible to make broad-brush statements that are true for all programs. There are many mitigating factors, including the goals of the program the context that a program is working in high priority objectives existing risks Our analysis and risk taxonomy can help programs decide whether MDE approaches can help or hurt an organization, specifically whether a particular approach will fit with a program’s risk profile and goals. MDE provides the opportunity to reduce development costs, improve the quality of the software developed, and possibly increase the agility of the development process. Programs can realize these benefits only if the concept fits with their acquisition strategies. MDE tools that specialize on a particular type of system provide high productivity but solve only a very narrow type of problem. Our analysis found that the narrower the scope of an MDE tool, the more that tool is tied to a vendor. We welcome your feedback on our work. Additional Resources You can learn about our research on MDE by reading the technical note Model-Driven Engineering: Automatic Code Generation and Beyond. The template for the accompanying questionnaire can also be downloaded from this site.    

The 2015 SHRM Annual Conference & Exposition is fast approaching and whether you’re a first-time attendee or an experienced conference veteran, there will be something for everyone at this year’s event. As thousands of SHRM members, media outlets and exposition vendors make plans to travel to Las Vegas June 28-July 1, SHRM will be working around the clock to prepare yet another amazing experience for attendees. It’s difficult to describe the excitement and electricity generated by the thousands of HR pros that attend each year. Maybe it’s the dynamic...

BBC Broadcast Centre The latest round of user research for the Access to Work team takes us to the heart of the BBC at the Broadcast Centre in White City, London. The thought of visiting the BBC, for me at least, conjures up thoughts of bumping into celebrities around each corner and perhaps getting the chance to contemplate Shep’s memorial in the Blue Peter Garden. Whilst the reality is slightly more mundane, in terms of gathering insights about how the deaf community interact with our services it proves an invaluable exercise and provides a wealth of insights. We are here to meet a couple of BBC employees who are both profoundly deaf and also existing users of the Access to Work scheme for the provision of British Sign Language (BSL) interpreters in their day to day jobs. Access to Work is a government programme delivered by Jobcentre Plus which provides advice and a financial grant for practical support to overcome work-related barriers due to disability. It is available to customers with a disability who are in paid employment or who are about to start a job. Both employees work on See Hear, the BBC flagship magazine programme for the deaf and hard of hearing. The programme has been running since 1981 and has won several awards in recognition of its services to the deaf community. I think it is fair to say that both users have, at best, mixed feelings about Access to Work. Both acknowledge that the scheme provides valuable support for the help they need in the workplace, however both are equally critical of the time it can take to process claims. The perceived "clunkiness" of the process makes life difficult for their Production Management Assistant (PMA) who liaises with DWP each time a claim is lodged. Conscious of this, we return to speak with the PMA in the near future because understanding what the employer needs from a digital service will be equally important as we take things forward. The background duly set, I proceed to let both users talk me through their thoughts via their BSL interpreters as they work through the Access to Work prototype. I want to observe how they interact with the service and discern their user needs. The immediate insight is that the experience can be different for different levels of deafness. For example, one user has very slight hearing with the use of an aid and also has a good knowledge of English. As such he moves through the form with ease. He is also comfortable giving an email address and is also content that he is giving his consent for future correspondence via email when he checks the tick box. The other user has BSL as her first language as she has been profoundly deaf from birth and English is not her first language. She consequently struggles with English and her interpreter has to help her with the form. Email will not be an option for her in terms of further communication. The prototype lets her appoint a third party to take calls on her behalf should further contact be required but for her this really needs to be a BSL interpreter. The insight is that we need to make this clearer in the form so we can meet this particular need. As there will be other users out there for whom BSL is their first language we will be looking to research with more of them to refine these needs and ensure our service can meet them. All in all, a very interesting and useful day. Both users like the prototype and return to work full of enthusiasm about the strides being taken by DWP to convert Access to Work into an online service, so much so that they are preparing a See Hear blog to reflect their experience! For us the next few weeks will see more research with both employees and employers across the spectrum of disabilities embraced by Access to Work as we move towards GDS assessment. So lots of work still to do but today feels like real progress.

By Hasan YasarTechnical ManagerCyber Engineering Solutions Group This post is the latest installment in a series aimed at helping organizations adopt DevOps. The federal government continues to search for better ways to leverage the latest technology trends and increase efficiency of developing and acquiring new products or obtaining services under constrained budgets. DevOps is gaining more traction in many federal organizations, such as U.S. Citizenship and Immigration Services (USCIS), the Environmental Protection Agency (EPA), and the General Services Administration (GSA). These and other government agencies face challenges, however, when implementing DevOps with Agile methods and employing DevOps practices in every phase of the project lifecycle, including acquisition, development, testing, and deployment. A common mistake when implementing DevOps is trying to buy a finished product or an automated toolset, rather than considering its methods and the critical elements required for successful adoption within the organization. As described in previous posts on this blog, DevOps is an extension of Agile methods that requires all the knowledge and skills necessary to take a project from inception through sustainment and also contain project stakeholders within a dedicated team. Successful implementation of DevOps in the federal government is possible thorough collaborative involvement of all stakeholders, the development of governance in regards to infrastructure, and equipping operational staff with DevOps skills. As the DevOps process gets used more and more in software development by industry firms, the common DevOps culture, automation, measurement, and sharing (CAMS) theme is used. In this post, we will begin to address some of the barriers and identify ways to enable the implementation of DevOps philosophy in the federal government space. So, where do we start? First Step: Acquisition Process The first and most important step of DevOps implementation starts in the acquisition process. The traditional government approach to any system acquisition is the waterfall model. Unfortunately, this model often starts with the development of rigid requirement specifications and sets the project on a path for failure on schedule, technical objectives, and overall project cost. In addition, acquiring the entire system at once can result in design, testing, and integration problems. In some cases, the expected product may be outdated by the time it reaches production use. In the waterfall model, there is no easy way to address requirements changes during the development or deployment stages unless the teams re-do previous tasks, which is expensive and time-consuming. Complex and software-intensive systems require a shift away from traditional waterfall models to more Agile methods. Agile methods are more effective for focusing development cycles, iterative delivery, and managing costs for actual business needs. Government organizations must remove any barriers during the acquisition process. Some barriers that prevent acquisition staff from operating more rapidly are rigid requirements and timelines delivery methods lack of formalized integration testing plan On the other hand, following Agile methods can enable organizations to see smaller, but successful incremental results, and receive early feedback on delivered capabilities, which allows early problem resolution if there are any misinterpretations of tasks. Additional information on adopting Agile methods during the acquisition process is available in previous blog posts and ongoing work by SEI researchers to help acquisition professionals in the federal government. While adapting Agile methods into the acquisition process, there are also requirements for cultural involvement, and preparation to support DevOps principles, such us continuous delivery, integration, automation, and measurement. During the contracting phase, all project team stakeholders should provide input on the contract, as well as functional requirements. As we mentioned earlier, the main principles of DevOps aim to bring the operational team together with developers, so effective communication is the cornerstone of this union. More specifically, communication between everybody is necessary: the program management team, operational team (including IT, maintenance, support, and operational testing), federal agency security experts, system architects, and legal staff among others. While it may take more upfront work to secure everyone’s input early in the contractual process, mistakes can be found and addressed before fingers hit keys for development. The input the acquisition department must have includes, but is not limited to, the following: system framework security policy/technical implementation guidelines (access control, required OS, etc.) operational testing requirements and automation testing scripts/tools identification of development platform and needs iteration cycles and delivery methods module/system integration requirements and platform/tool definition communication methods and establishing visibility across all project teams Also, automating the delivery of each capability and how the continuous integration with other systems will occur should be addressed during the acquisition process. Automation will enable the federal government to see status and capability as early as possible and allow stakeholders to gain a better understanding of the system regardless of functional state and pivot quickly should it require adjustment. After delivering a successful module, end-users will be able to begin working with new capabilities and become familiar with the system while the rest of the features are still being developed, tested, and deployed. Future posts on DevOps in government will explore cultural changes, governance structure, and automation and measurement as part of this topic in our bi-weekly DevOps blog series. 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.

Over the past several months, it has been my great pleasure to get to know SHRM members and others through a series of conversations around Sheryl Sandberg’s book Lean In. This effort began in March when I posted on SHRM’s LinkedIn page to ask for volunteers to take part in a kind of virtual book club. More than 75 people responded. Sandberg had been slated to keynote the SHRM Annual Conference & Exposition next month, but she withdrew in the wake of the recent loss of her husband Dave...