On May 13, @SHRMnextchat chatted with Sharlyn Lauby (@Sharlyn_Lauby) about Too Many Meetings in the workplace. In case you missed this excellent chat with great tips and advice, you can see all of the tweets here:   [View the story "#Nextchat RECAP: Too Many Meetings!" on Storify]  ...

By Arie GurfinkelSenior Member of the Technical Staff    Software Solutions Division When we verify a software program, we increase our confidence in its trustworthiness. We can be confident that the program will behave as it should and meet the requirements it was designed to fulfill. Verification is an ongoing process because software continuously undergoes change. While software is being created, developers upgrade and patch it, add new features, and fix known bugs. When software is being compiled, it evolves from program language statements to executable code. Even during runtime, software is transformed by just-in-time compilation. Following every such transformation, we need assurance that the change has not altered program behavior in some unintended way and that important correctness and security properties are preserved. The need to re-verify a program after every change presents a major challenge to practitioners—one that is central to our research. This blog post describes solutions that we are exploring to address that challenge and to raise the level of trust that verification provides. As we strive to ease the burden of effort surrounding verification for practitioners, we attempt to answer this question: How can we ensure that the amount of verification work is proportional to the size of the change, as opposed to the size of the system? It is possible for even a small change to a program to trigger a complete re-verification of it. In our project, we study this problem of evolving verification in the context of a compiler. Two standard tools play a role in the process we describe here. The first is the compiler, which takes the source code of a program entered by the programmer and transforms it into an executable. The second is a verifier that takes a program and a property and determines whether the program satisfies the property. Figure 1 below shows a typical interaction of the compiler and the verifier. Both take the source code of a program in and manipulate it. While to the user, the compiler is a black box that takes source code and produces binaries, internally it is structured as a series of transformations. Each transformation makes a small refinement to the program at each pass. This optimizes the program—that is, effects some improvement. For example, compilation optimizations might eliminate useless code or enable the program to use fewer resources. This iterative improvement is comparable to what happens to a program as it evolves over time. Thus, compilation provides a well-defined software evolution that we have chosen to study in our research. One of the main hazards to verification results is that the compiler and verifier might use incompatible interpretations (semantics) of the source code. We refer to this hazard as the semantics gap. The semantics gap is as a major hazard to the validity of formal verification, and mitigating this hazard is one of our research objectives. Towards our goals of overcoming the semantics gap, expanding the information provided to the practitioner, and automating the verification process, we are developing a certified compiler, which tightly integrates the compilation and verification tool chains. When verification is successful, this compiler provides a certificate—documenting a rigorous formal proof that shows why the software will behave as expected regarding a desired condition. The certificate provides an extra layer of trust to the user. One major advantage of our approach is that it does not involve building the system from scratch. Instead, we have found a way to combine an existing compiler and verifier. We use an LLVM compiler, which is designed as a set of reusable libraries with well-defined interfaces and is written in C++. Our process also involves an intermediate representation in LLVM bitcode. It is this intermediate representation that allows the compiler and verifier to overcome their semantic differences and "talk to each other." Our verifier is UFO, which we have recently pioneered; it is a framework and tool for verifying (and finding bugs in) sequential C programs. UFO is a new brand of verifier and a major reason we are hopeful for success in our endeavor. As the winner in four categories of the 2013 Software Verification Competition, it currently represents the state-of-the-art in software verification. Figure 2 below represents the architecture of our proposed certified compiler. Key to the process is the common front end that translates the input program into a formally defined intermediate representation. As the figure shows, that representation is simplified for verification, then proceeds on to be verified. If an error is detected, it is communicated to the user through an error report. Otherwise, a certificate is generated, and the compilation tool-chain takes over. The compiler first embeds the verification certificate into the program. When the program is compiled, the resulting executable is validated against this embedded certificate. If the validation passes, the certificate is removed, and the executable is returned to the user. The compiler and the verifier work on the same formal intermediate representation, so there is no semantic gap. Impact We anticipate that the certifier+compiler will provide significant benefit because it presents the user with more understandable verification messages allows for validation of correctness of compiler optimization allows for producing self-certifiable executable code Our verifier+compiler architecture will simplify the verification effort considerably, as it automatically propagates verification results across the compilation tool chain. This propagation enables safe use of optimization in safety-critical systems and will have widespread impact. If successful, our toolset will enable many new applications of verification techniques in safety- and mission-critical environments such as defense and commercial aviation domains. The verifier+compiler will also significantly speed system development and make it more efficient. Moreover, the optimized code better utilizes available resources and so will aid in fulfilling resource requirements. Development cost will decrease because automatic optimization is cheaper than the manual optimization that is currently performed. Verification costs will also decrease; for several reasons, code manually optimized for resource usage is much harder to verify than unoptimized code. For example, the (manual) optimization process often trims the code, which makes it less complete and harder to verify. In addition, many compilers have been designed to generate code that runs quickly, rather than code that can be verified quickly. Automated verification that occurs before automatic optimization resolves these issues. Looking well into the future, we see possibilities for exciting applications of our research. If we were able to achieve optimal speed and efficiency for the verifier+compiler, we might apply it, for example, to an autonomous system. Such a system uses sensors to determine what is happening in the environment and changes its behavior accordingly. For example, it could rewrite its own program as it runs. With sufficient runtime performance, our verifier+compiler could verify the system as it runs and evolves. Qualifying Tools Other new applications of verification techniques in safety- and mission-critical setting could involve qualification of tools. The DoD and related government agencies require that safety-critical systems meet certain standards, for example, as described in DO-178 B, which is guidance used to determine whether the software will perform adequately in a safety-critical airborne environment. When the system satisfactorily meets these standards, the agency declares it certified (not to be confused with software certified by the verifier as described above). Government agency certification also requires that tools used to build safety-critical systems be qualified: tools used to develop or verify safety-critical software must not introduce errors or fail to detect errors, respectively. So, to build a certifiable avionics system, for example, you must use tools that you can demonstrate to be qualified. For system analysis tools, the new verifier+compiler architecture would make such qualification easier than it is currently. In particular, closing the semantics gap with the new architecture would have a significant impact both on how the development tools are qualified and how compilers are used in safety-critical domains. Conclusion If successful, we believe that our research will have a broad impact and numerous applications, including improving scalability of automated verification, simplifying software certification, and enabling novel architectures for adaptive and/or autonomous systems that are re-verified on-the-fly. We also expect that the prototype currently under development will be valuable towards demonstrating the technology to stakeholders and find new applications in safety-critical domain. We welcome your feedback in our work in the comments section below. Additional Resources To read the paper, UFO: Verification with Interpolants and Abstract Interpretation (Competition Contribution) by Aws Albarghouthi, Arie Gurfinkel, Yi Li, Sagar Chaki, and Marsha, Chechik, please visit http://link.springer.com/chapter/10.1007%2F978-3-642-36742-7_52. To read the paper, Synthesizing Safe Bit-Precise Invariants, by Arie Gurfinkel, Anton Belov, and João Marques-Silva, please visithttp://anton.belov-mcdowell.com/baker/media/papers/gurfinkel_belov_marques-silva--tacas14.pdf. To read the paper FrankenBit: Bit-Precise Verification with Many Bits - (Competition Contribution) by Arie Gurfinkel and Anton Belov, please visithttp://anton.belov-mcdowell.com/baker/media/papers/gurfnikel_belov--tacas14.pdf. To read the paper, Incremental Verification of Compiler Optimizations, by Grigory Fedyukovich, Arie Gurfinkel, and Natasha Sharygina, please visithttp://verify.inf.usi.ch/sites/default/files/nfm2014.pdf. To view the presentation, Trust in Formal Methods Toolchains, please visithttp://arieg.bitbucket.org/pdf/2013-07-14-VeriSure.pdf.

By Derrick H. KarimiMember of the Technical Staff Emerging Technology Center This blog post is co-authored by Eric Werner. In an era of sequestration and austerity, the federal government is seeking software reuse strategies that will allow them to move away from stove-piped development toward open, reusable architectures. The government is also motivated to explore reusable architectures for purposes beyond fiscal constraints: to leverage existing technology, curtail wasted effort, and increase capabilities rather than reinventing them. An open architecture in a software system adopts open standards that support a modular, loosely coupled, and highly cohesive system structure that includes the publication of key interfaces within the system and full design disclosure. One area where the Department of Defense (DoD) is concentrating on the development of service-oriented architectures and common technical frameworks is in the intelligence community, specifically the Defense Intelligence Information Enterprise (DI2E). As this blog post details, a team of researchers at the SEI Emerging Technology Center (ETC) and the Secure Coding Initiative in the SEI’s CERT Division, are working to help the government navigate these challenges in building the DI2E framework, which promotes reuse in building defense intelligence systems. Foundations of Our Work Our work focused on development of a framework for DI2E, the non-command-and-control (C&C) part of the Distributed Common Ground System (DCGS) and the Combat Support Agencies (CSAs). The DI2E Framework provides the building blocks for the Defense Intelligence Community to more efficiently, effectively, and securely develop, deliver, and interface their mission architectures. The core building blocks of the DI2E framework are components that satisfy standards and specifications, including web service specifications that enable a stable but agile enterprise supporting rapid technology insertion. The key objective of the DI2E Framework is to increase operational effectiveness, agility, interoperability, and cybersecurity while reducing costs. The framework consists of a reference implementation (RI), a test bed, and a storefront. When completed, the DI2E will provide a fully integrated, cross-domain, globally-connected, all-source intelligence enterprise that comprises the federated intelligence mission architectures of the military services: CSAs, Combatant Commands (CCMDs), Intelligence Community (IC), and international partners. The DI2E provides functionality that transforms information collected for intelligence needs into forms suitable for further analysis and action provides the ability to integrate, evaluate, interpret, and predict current and future operations or physical environments provides the ability to present, distribute, or make available intelligence, information and environmental content, and products that provide better situational awareness to military and national decision makers The vision of the founders of the DI2E Framework Testbed is to use a distributed (interagency) development paradigm to implement a software repository focused on componentized reuse, enabled by an open architecture and systematic conformance testing of components’ interfaces to specifications allowed in the architecture. Our work on this project—the team included Shelly Barker, Ryan Casey, David Shepard, Robert Seacord, Daniel Plakosh, and David Svoboda, in addition to Eric and myself—spans two fronts: We participate in a center of excellence (COE) that consists of universities and labs working with the government to execute DI2E framework processes. Our work focuses on helping the DoD develop the framework by providing feedback to the DI2E Program Management Office about processes and practices of the framework. When completed, the DI2E framework will comprise the architecture, standards, specifications, reference implementations, components, component storefront, compliance certification, and testing, as well as the configuration management and other governance processes necessary to realize the aforementioned objectives. On a second front, we are evaluating specific components to be included in the software reuse initiative. The evaluated software is presented in a storefront of software components that can be reused when the defense intelligence community is building other systems. Open Architecture Approach As part of its approach, the government intends to reuse existing components of the DI2E enterprise, with the goal of taking advantage of free and open-source software, government-off-the-shelf software (GOTS), and commercial off-the-shelf (COTS) software. Our team of researchers participates in the framework development by contributing to the design of the software component evaluation and developing software tools to support the evaluation process. These tools provide task automation and consistent evaluations across the distributed COE network of universities and labs.  Our main focus, however, is on performing the software evaluations that are necessary to ensure quality reusable components are recommended for reuse. Evaluating Components for Reusability When a new or existing government program defines a need—be it a map, login service, or some other kind of widget to build out part of its system and fulfill some requirement—the program ideally will not have to build the system entirely from scratch. Through software reuse, the program should be able to easily identify and examine components that have already been evaluated, embedded, and tested. Our role involves evaluating and testing the software components that will be housed in the DI2E storefront for programs to view and ideally reuse. When we first began work on the DI2E Framework in 2013, together with the other COE labs, we focused on building up and designing an evaluation framework. We began in an Agile fashion, building on a checklist that now contains approximately 70 questions asking for judgments and measures of different aspects of the software including How easy is it to find the software? How easy is it to install the software? How complete is the testing? Is there a community that supports this? Can you go online and easily find information about it? Next, we used the checklist to answer these questions for each piece of software that we evaluated. We tracked down information by examining and using the software and also reading and evaluating the documentation. To answer the evaluation questions that the user experience or documentation did not address, we asked the software developers to answer such questions as What development process do you use? Do you use bug tracking? Do you have a checklist for release? What is your approach to testing? Are you measuring unit test coverage? In addition to the checklist of questions, our team generated other prose documents, including installation and integration how-tos. For more mature software components, these documents point back to the software component’s documentation. While the checklist guides the evaluation, the prose sections capture more detailed information. The completed checklist provides a naturally indexed and self-contained summary of how applicable a piece of software is to the DI2E. The prose documentation details the software evaluation, presenting the evidence used to justify the abbreviated checklist answers. Additional prose documents provide architectural details relevant to the DI2E, such as whether support is provided for deployment dependencies, data formats, and interfaces. This information can rapidly inform programs of record about the suitability of reusing a component in their system. The documented and validated data formats and interfaces will allow users to rapidly design a system from compatible components with a high level of assurance that the design is valid. Our Evaluations Our work on the DI2E framework also included software component evaluations that align with the ETC’s areas of expertise in data-intensive scalable computing.  As of July 2014, we have evaluated assets that cover the following functional requirements: data-content discovery data mediation data-handling widget framework One of the software component evaluation documents maps the component’s features to the services that the intelligence community is seeking. For example, if an agency has already identified that multiple source query capability is critical for its software, we have indexed existing software components with these services so that they may be easily identified. Collaborations At a higher level, our evaluation of the software components focuses on reusability, but security remains an underlying and important concern for every evaluation.  One aspect of our security evaluation involves code analysis. For that aspect of our work, we are working with researchers in the CERT Secure Coding Initiative, who maintain a laboratory environment for static analysis. The Source Code Analysis Laboratory (SCALe) consists of commercial, open source, and experimental tools that are used to analyze various code bases, including those from the DoD, energy delivery systems, medical devices, and more. Using SCALe, source code auditors then identify violations of the published CERT Secure Coding rules. In the Cloud Given the federal government’s embrace of cloud computing, it is important to note that DI2E is set up as a private cloud environment. The DI2E cloud offers Infrastructure as a Service (IaaS), where testing machines can be provisioned, and Software as a Service (SaaS), where common developer tools are available for use. Working in the DI2E cloud enabled us to have on-demand access to infrastructure machines to test different software components. Working in the cloud also allows us to address the "it works on my machine" problem, which my colleague Aaron Cois detailed in a recent blog post. This phrase describes a common problem in which developers, often early in their career, write software code to address a problem. After testing the code and finding that it works on their machine, the developers deploy it to customers where it may fail to work because of differences in system configuration. One positive aspect of working in the cloud is that the common environment allows configurations of systems used by collaborating organizations to be more homogenous. The configuration management systems exposed to cloud instances by the cloud administrators can enforce consistency that aids in component integration. PlugFest and Future Work Our research on DI2E aligns with ETC’s mission, which is to promote government awareness and knowledge of emerging technologies and their application and to shape and leverage academic and industrial research.  There is considerable need for this type of research since "the practice of reuse has not proven to be … simple however, and there are many misconceptions about how to implement and gain benefit from software reuse," as Raman Keswani, Salil Joshi, and Aman Jatain write in a paper presented at the 2014 Fourth International Conference on Advanced Computing & Communication Technologies. Our work also leverages various SEI skillsets such as hands-on evaluation, construction of frameworks, and data processing. My colleague Dan Plakosh and I also attended DI2E PlugFest, an annual demonstration of the DI2E framework. The Plugfest eXchange provided an environment of networked, interoperable, and reusable components where vendors deployed and showed their tools for providing flexible, agile, and data-driven capabilities to warfighters. At PlugFest, we were able to see first-hand which vendors were able to align their software with the ideals of the DI2E framework. We welcome your feedback on our work in the comments section below. Additional Resources For more information about SEI Emerging Technology Center, please visit http://www.sei.cmu.edu/about/organization/etc/. Editor’s Note: The appearance of external hyperlinks does not constitute endorsement by the United States Department of Defense (DoD) of the linked websites, or the information, products or services contained therein. The DoD does not exercise any editorial, security, or other control over the information you may find at these locations.

I LOVE innovation because of all those fantastic things that can really improve our lives. As a traveller, my smartphone brings me internet, email, calendar, photos and best of all face  to face contact with my nearest and dearest. These digital advances make it possible for me to stay close to those I love, get where I’m supposed to be on time and listen to the latest tunes. Ok, so maybe not real life changers like medical breakthroughs but these advances are designed to make life better. I’m not suggesting all digital is good, but when it’s done well it can be amazing! What is Digital? Like many of those interested in digital, I found it difficult to find the definition. Life is easier if things are defined, we don’t need to think, we simply reach a common understanding. There’s no formal definition but I think that there are some common characteristics of a digital service which I have found to be a helpful guide: Designed for users Better service produced for citizens Incrementally built, tested and continuously improved Development teams learn as they go, by doing. In DWP it’s far from clear-cut. There are lots of differences in digital delivery compared with all the other delivery methodologies such as PRINCE - they all have a place and there are pros and cons with each. My secret learning so far - and I’m not sure if it’s right - is that it’s the people and their attitude that’s making the biggest difference!  So how do we deliver a Digital Project? What goes on behind the scenes then? I’m trying to explode the myths behind digital development. One analogy that I’m going to share with you is ‘you do not need to know how to programme a phone to use one!’ and that’s exactly the point! For me it’s about designing the best you can for your users. You may have heard the terms agile or scrum to describe the ways of working? What are they? Put simply, work is broken down into manageable chunks, followed by prioritising a list of what to do first. Then you have a ‘sprint’. The sprints usually last a couple of weeks with the intention to deliver the task list, also known as a ‘backlog’. Progress is checked daily and any blockers preventing you from progressing are identified and removed. If you cannot remove the blockers move on and flag them to someone who can fix it. To summarise There’s more than one definition of ‘Digital’ We put users needs at the heart of our design We build it incrementally, try it out, learn then do it all again! Making it happen is about the right people, well led and empowered to deliver at pace.  Discover Discovery  I’m now in the room at DWP’s new Transformation Hub in Leeds. I’m super proud to be part of a multifunctional team of user researchers, product owner, business analysts and developers. Secure Communications Project team This discovery is about Secure Communications so government can communicate digitally, with claimants and others. There are huge benefits for all if we land this well! But we can’t boil the ocean so we have picked a small area to focus on. For this discovery that’s Personal Independence Payment for those that are terminally ill. Our users are claimants, doctors, Macmillan and other support functions. I don’t think I’ve been more emotionally connected between the Department’s business and our customer. We will be blogging about our experiences as we move through discovery over the coming weeks so please watch this space.

  Q: I’m at a loss on how to deal with a recent hire. He’s very eager to prove himself and do well, but instead of learning his job -which involves very specific functions, procedures and deadlines- he spends time trying to find efficiencies in other areas and coming up with improvement ideas unrelated to the job. Consequently, he’s not up to speed. I DO like employees who show initiative, but I also need him to learn his job. So what’s the best way to let him know he needs to concentrate on the job first,...

By C. Aaron Cois Software Engineering Team Lead CERT Cyber Security Solutions Directorate DevOps is a software development approach that brings development and operations staff (IT) together. The approach unites previously siloed organizations that tend to cooperate only when their interests converge, resulting in an inefficient and expensive struggle to release a product. DevOps is exactly what the founders of the Agile Manifesto envisioned: a nimble, streamlined process for developing and deploying software while continuously integrating feedback and new requirements. Since 2011, the number of organizations adopting DevOps has increased by 26 percent. According to recent research, those organizations adopting DevOps ship code 30 times faster. Despite its obvious benefits, I still encounter many organizations that hesitate to embrace DevOps. In this blog post, I am introducing a new series that will offer weekly guidelines and practical advice to organizations seeking to adopt the DevOps approach. My Background As a federally-funded research and development center (FFRDC), the SEI must maintain high standards of efficiency, security, and functionality. At the SEI, I oversee a software engineering team that works within CERT’s Cyber Security Solutions Directorate. My team develops tools and technologies to help federal agencies address cybersecurity risks, manage secure systems, and investigate increasingly complex cyber attacks and crimes. To fulfill these responsibilities, we develop many increasingly complex software applications, and DevOps has become a necessary, defining factor in our software development process. Our role in helping federal agencies assess cybersecurity risks heavily influences our approach to DevOps, necessitating that we weave security considerations into every facet of our software development lifecycle. Cybersecurity is often misunderstood or even ignored as new systems are designed and developed, falling out of view to more high profile quality requirements, such as availability or correctness of software systems. Due to CERT’s responsibility to our sponsors and the community, security is consistently a first-tier concern, addressed as an early and fundamental requirement for any system developed by our team. This focus has precipitated our research into Secure DevOps, or DevOpsSec, a topic we will revisit often in this blog series. Origins and Benefits of DevOps DevOps emerged in 2009 when a group of Belgian developers hosted DevOps Days, which advocated collaboration between developers and operational staff. Since then, organizations have rapidly adopted DevOps. In their 2014 State of DevOps report, Puppet Labs found DevOps adopters to be "deploying code 30 times more frequently with 50 percent fewer failures." In addition, the more than 9,000 people who completed the Puppet Labs survey reported the following: Firms with high-performing IT organizations were twice as likely to exceed their profitability, market share, and productivity goals. IT performance strongly correlates with well-known DevOps practices, such as use of version control and continuous delivery. Organizational culture is one of the strongest predictors of both IT performance and overall performance of the organization. For more on the origins of DevOps, see my post, An Introduction to DevOps. Addressing Challenges to DevOps AdoptionBefore an organization can consider adopting DevOps, it needs to shift the prevailing mindset and culture and gain a better understanding of how DevOps works. In my experience, some barriers to adoption are technical, and a number are cultural. The practical advice and suggestions that we will publish every Thursday will focus on three core areas of DevOps: collaboration and cooperative culture infrastructure as code automation and repetition The following are some of the specific challenges that I will address in the subsequent weeks: Continuous integration: What build server should I choose? How do I know what processes to automate? Who manages build configurations? There are many questions involved in implementing robust continuous integration in the enterprise. In this series we will cover many common issues and some advanced topics to get your organization on a successful path. Continuous deployment: This concept terrifies many organizations, but it doesn’t have to. There are many paths to continuous deployment, and many ways to implement the technology in a way that maintains stability and assurance in your delivered products. Stay tuned for more. Fear of automation: DevOps provides a means for automating repetitive tasks within the SDLC, allowing engineers to focus on the important task of writing code. However, the fear of automated tools and the technical expertise needed to use them, especially in legacy systems, is pervasive. We’ll talk about what tasks to automate, when to automate, and the cost and benefits of automation. Incomplete implementation: Agilists often encounter organizations that embrace Agile development language but ignore fundamental concepts and behaviors. This can result in a watered down process of writing code very fast without documentation. This is not Agile, this is irresponsible. In DevOps, I have witnessed the same problem. For instance, an organization may think it embraces DevOps, but it may not have any operations staff on project teams. This is not DevOps. Breaking down the silos: Altering organizational culture to enable developers and operations engineers to fully collaborate on a project is trickier than it sounds. We’ll discuss a number of issues and tactics for shaping organizational culture and thinking to achieve your goal of functional DevOps. Tailoring DevOps: There are many ways to do DevOps. It is important to note that different teams and projects may structure DevOps practices differently, depending on their needs. I, along with several members of my team, will present tactics, case studies, and alternatives throughout this series. DevOpsSec: Most software teams believe in secure software, but are unsure how to structure their process to produce verifiably, consistently secure code. We will present tools, techniques, and practices to help you increase your software security through DevOps.  Infrastructure as code: In addition to writing code for an application, software development teams practicing DevOps develop code to define their infrastructure. There are many advantages, and many pitfalls, to automated environment provisioning, and it will be a frequent topic in this series. Automation & repetition: In addition to being a significant time-saver, automation and repetition of complex tasks can give a team extreme confidence in their ability to perform these tasks when it counts. But what steps should be automated? What tools are best? We’ll discuss a variety of topics around DevOps automation throughout this series. Looking Ahead While I will use this series will provide weekly guidelines and advice on DevOps adoption, I will continue to publish more in-depth posts that take a deeper dive into issues surrounding DevOps. The next post in this series will explore continuous integration in DevOps. We welcome your feedback. What issues surrounding DevOps do you want to know more about? What challenges is your organization facing in adoption? Please leave feedback in the comments section below. Additional Resources To listen to the podcast, DevOps—Transform Development and Operations for Fast, Secure Deployments, featuring Gene Kim and Julia Allen, please visithttp://url.sei.cmu.edu/js. To view the August 2011 edition of the Cutter IT Journal, which was dedicated to DevOps, please visit http://www.cutter.com/promotions/itj1108/itj1108.pdf. Additional resources include the following sites: http://devops.com/ http://dev2ops.org/ http://www.evolven.com/blog/devops-developments.html http://www.ibm.com/developerworks/library/d-develop-reliable-software-devops/index.html?ca=dat-

We want to make better use of social media to provide a more professional and consistent experience for our claimants. Later this Autumn we’ll be testing and learning by giving access to Facebook and YouTube to staff in 3 Jobcentre sites: London Bridge, Newport and Rusholme. A new Facebook page called Find Share Connect will be our flagship social media channel. It will provide a space to bring together claimants and employers and give advice on job search, training opportunities and support recruitment activity by partners. Find Share Connect will be a national page but during the test will have a local flavour with jobs content tailored to the three test sites. You can check out some of what we’re planning do in this exciting pilot by watching this film. We will also share the experience through Twitter and future updates on this blog.

By C. Aaron Cois Software Engineering Team Lead CERT Cyber Security Solutions Directorate This post is the latest in a series for organizations implementing DevOps. A DevOps approach must be specifically tailored to an organization, team, and project to reflect the business needs of the organization and the goals of the project. Software developers focus on topics such as programming, architecture, and implementation of product features. The operations team, conversely, focuses on hosting, deployment, and system sustainment. All professionals naturally consider their area of expertise first and foremost when discussing a topic. For example, when discussing a new feature a developer may first think "How can I implement that in the existing code base?" whereas an operations engineer may initially consider "How could that affect the load on our servers?" When an organization places operations engineers on a project team alongside developers, it ensures that both perspectives will equally influence the final product. This is a cultural declaration that in addition to dev-centric attributes (such as features, performance, and reusability), ops-centric quality attributes (such as deployability and maintainability) will be high-priority. Likewise, if an organization wants security to be a first-class quality attribute, a team member with primary expertise in information security should be devoted to the project team. Every Thursday, the SEI Blog will publish a new blog post that will offer guidelines and practical advice to organizations seeking to adopt DevOps. We welcome your feedback on this series as well as suggestions for future content. Please leave feedback in the comments section below.

  Everyone has those moments when they feel blue or out-of-sorts. Most of the time these feelings come and go. But when sadness persists for more than two weeks it could be a signal of something bigger: depression that may affect a person’s ability to function at work, at home, or in other aspects of their life. As an employer, you may notice a reduction in an employee’s productivity, an increase in absences or a shift in their overall disposition. Depression is a common illness that affects more than...

"I have a dream" a man once said. He went on to describe exactly what that dream was. His articulation was so successful that many of those listening heard a call to arms and understood that it was the start of a journey that they all wanted to be part of. He really knew how to take people with him. My name is Rachel Woods and I’m the Product Owner for the Secure Communications Project. It’s my role to own, champion and protect the scope of the project. I want to describe the scope of our project to you and bring you along for the ride… I just need to work out what it is first and that’s not easy. Herding ideas Working in Government is wonderful and collaborative and hard. A lot of the great ideas in Government are not championed by individual dreams but are born from conversations which then develop and morph as more minds enter the picture, and we have a lot of (rather wonderful) minds in DWP. When I started on the project about 4 weeks ago a lot of people had already formed their own idea of what we were doing. The difficultly was that there was such a diversity of ideas that it was difficult to pinpoint not only what we might want to try to deliver but what our exam question was. There were so many questions we could try to answer. Getting the right people in the room Over the last few weeks the whole team has worked together and corralled all the outputs of those wonderful minds, gradually discounting them or putting them into a backlog until we were left with something that looked like it might be our scope. The criteria we used to de-scope was fairly wide but included some obvious things like ‘it’s being looked at elsewhere’. Each time we made a leap forward it was always down to one thing: a visit - getting the right people around our wall and having a really good discussion not only about what we are doing but why. Stakeholders are vital, but working on scope in the discovery phase has really brought home to me how important it is to have engaged stakeholders who are not afraid to challenge. Without challenge we don’t change and we don’t improve. Show the Thing… even if the ‘thing’ is just your thinking Today we had our first face to face Show and Tell and we took stakeholders on the journey we had been on, literally walking them through all our working out on our many, many walls to show how we have arrived at our current thinking. We were looking for buy in and reassurance that if we do eventually build something it will be ‘the right thing’ for the right users. Show the Thing… The result? We now know what the exam question is. Our next challenge is to take our messy workings out and decant them into a clear, concise and engaging explanation to share with those that couldn’t be with us. If you get the chance its worth revisiting the vision outlined by Martin Luther King Jr and looking at how far it has come. I’m sure if he was Product Owner for his project then he wouldn’t be signing it off as ‘done’ but I think he would be proud of what progress has been made. Me too.