By Eileen WrubelSenior Member of the Technical StaffAcquisition Support Program Tension and disconnects between software and systems engineering functions are not new. Grady Campbell wrote in 2004 that "systems engineering and software engineering need to overcome a conceptual incompatibility (physical versus informational views of a system)" and that systems engineering decisions can create or contribute to software risk if they "prematurely over-constrain software engineering choices" or "inadequately communicate information, including unknowns and uncertainties, needed for effective software engineering." This tension holds true for Department of Defense (DoD) programs as well, which historically decompose systems from the system level down to subsystem behavior and breakdown work for the program based on this decomposition. Hardware-focused views are typically deemed not appropriate for software, and some systems engineers (and most systems engineering standards) have not yet adopted an integrated view of the two disciplines. An integrated view is necessary, however, because in complex software-reliant systems, software components often interact with multiple hardware components at different levels of the system architecture. In this blog post, I describe recently published research conducted by me and other members of the SEI’s Client Technical Solutions Division highlighting interactions on DoD programs between Agile software-development teams and their systems engineering counterparts in the development of software-reliant systems.  Foundations of Our Research  In the last several years, the DoD has focused efforts on decreasing the length of time needed to bring new software and other technical capabilities to soldiers. To accomplish this goal, members of the DoD acquisition community are increasingly turning their attention to Agile and other iterative development methods. The DoD 5000 series and other guidance for acquisition programs still offer a system-oriented perspective on acquisition. However, they do not provide strong guidance on how to leverage iterative software development methods within the greater context of iterative development methods.  With this research, our team—which also includes Suzanne Miller, Mary Ann Lapham, and Timothy A. Chick-does not advocate a particular development method.  Instead, we explore the ways in which Agile software development teams are engaging systems engineers and associated stakeholders to identify factors that will help the DoD benefit from Agile methods and barriers to achieving those results.  As detailed in our technical note on this research, Agile Software Teams: How They Engage with Systems Engineering on DoD Acquisition Programs, two key facets of systems engineering help us to understand why systems engineering is an important player in programs adopting Agile methods:  The product side of systems engineering: Systems engineering has a key role in transforming the artifacts that communicate intent of the system as understanding of the system evolves. The service side of systems engineering: Systems engineering has an equally important role in communicating and coordinating important information about the evolving knowledge of the system among the many stakeholders, including technical staff, end users, and management. Systems engineers have a strong conflict resolution role when inevitable technical and programmatic conflicts arise among stakeholders.  When we analyzed these two facets, what emerged were two distinct possibilities of how the systems engineering community might take advantage of Agile methods.  On the product side, the incremental, iterative approach with heavy user involvement common to all Agile methods could be leveraged to increase the speed of development of key requirement and design artifacts needed to implement different mission or system threads. Some methods, such as test-driven development, could be incorporated into the activities of systems engineering to increase the connection between the two sides of the typical systems engineering V lifecycle.  On the service side, at the scale of a program that requires a separate systems engineering function, the coordination, communication, and conflict-resolution services that systems engineering provides could translate into a product owner surrogate role, a Scrum of Scrums facilitator role, or other specialty roles that show up in scaling approaches, such as the Scaled Agile Framework (SAFe), which provides an interactive knowledge base for implementing agile practices at enterprise scale. Three Different Approaches to Systems Engineering with Agile  At a high level, we envisioned three different approaches, which we refer to as engagement models:  Agile software engineering teams interacting with traditional systems engineering teams operating on that traditional systems engineering V model systems engineers acting as Agile team members systems engineering teams actually applying Agile methods to their own work and systems engineering functions In the first of these approaches—where traditional systems engineering is being used, and the systems engineering team is interacting with an Agile software team without being members of that team—we observed that Agile software engineering teams were providing deliverables to the systems engineering function at the boundary between the systems engineering function and software functions.  These deliverables can include code or documentation and work products to facilitate technical reviews. The Agile team engaged in its Agile practices up to that point, assembled what it needed to hand off to a systems engineering function, and then passed those things over those boundaries. So, the Agile team was free to operate in its iterative and incremental way until it handed everything over. The team then entered the systems engineering domain, and the systems engineering teams executed according to their plans and processes, typically, with the traditional V model. As a result, some of the decisions typically made in an Agile software project—such as the selection high business value or high technical infrastructure value—could not always be made because the programs were bound by the manner in which the systems engineering function had allocated the requirements and defined the work packages. For those teams, we did not always see all the benefit we observed in what I would call a "pure" Agile space because they had to deal with this interaction.  In the second of these approaches, a systems engineer typically operates on a software Agile team in the role of product owner, who is the person in charge of requirements and their prioritization. The systems engineer would be involved in the prioritization of features and functions going into a particular sprint. This involvement enables the systems engineer to follow the testing of the features and functionalities, so that when work products come to the boundary between the software team and the systems engineering function, systems engineers know what is coming into test and evaluation. Just as importantly, the systems engineering team is prepared. There is a smooth transition as the work product flows from one part of the engineering process to the other. With this approach, we observed a smoother transition as well as additional opportunities for making changes in the systems engineering ideas and designs. We attributed these benefits to early learning enabled by the incremental approach and more detailed involvement with software. Some of the software implementation can change some of the system designs, so the software team actually had a little more influence on the systems engineering products when systems engineers worked in this way.  In the third approach, where systems engineers apply Agile methods to their own work, they iterate requirements development, develop the baselines, establish the baselines, and establish the designs throughout the lifecycle.  The biggest issue we observed with this approach is the translation of "working software," a fundamental tenet of Agile methods when applied to software, to an equivalent in systems engineering. We observed this more often in commercial IT organizations, where there is no significant hardware development component. We did, however, observe one large project that adopted Agile systems engineering methods across system, hardware, and software tasks. Although we only found one project, we have seen indicators of increased interest in this approach. The International Council on Systems Engineering (INCOSE) established a working group on Agile and systems engineering. Also, The National Defense Industrial Association has established an Agile and systems engineering working group. While this approach is the most novel, our research team did observe instances in which that dichotomy between product and service common to systems engineering comes in to play. Systems engineering functions that recognize the service side were more prepared, because their vision isn’t limited to product artifact transformation.  Through our surveys and interviews, we observed that the greatest opportunities for successful Agile implementations occurred when systems engineering teams were, at the very least, aware of and engaged with the Agile processes. More generally, we identified successes and challenges in the following key areas:  Automation. Investment in automation can help to harmonize Agile with traditional constructs by streamlining the development of documentation deliverables and communication. Lack of automation frustrates cost- and resource-effective testing and hampers communication and transparency between software and systems engineering teams.  Insight/oversight. The constant, systemic delivery of production-ready code by Agile software teams over short iterations and the use of metrics and tools such as burn-down and cumulative flow diagrams offer up frequent, regular windows to monitor the progress and quality of the system under development, but stakeholders have to understand and actually exercise those insight opportunities to derive value from them.  Training. Teams that provide systems engineers, government program office personnel, and other stakeholders with Agile-specific training on a recurring basis have reported success with communicating and expectation setting. Government program office staff training for the various career fields involved in acquisitions (e.g., contracting, finance), however, is generally functionally oriented: respondents indicated that strict capability-based training for government personnel has hampered the ability of many program office team members to conceptualize the changes in how contracts and delivery orders must be structured to most effectively engage Agile development teams. Role of sponsors, advocates, and coaches. Sponsors, advocates, and coaches for Agile can be instrumental to teams undergoing change to meet operator needs and variations in processes and to ensure that culture can change to support Agile methods, processes, and techniques. When coaches established and delivered training on Agile, systems engineering process and software development became better intertwined, and decisions were made together instead of separately. Leadership advocacy sets expectations for communication and collaboration within and across organizations and provides support that allows Agile practitioners to explore program-specific tailoring of the processes and documents required by acquisition regulations. Pilot programs. Respondents who engaged in piloting before broader rollouts indicated that demonstrated cost and schedule savings and the repeated demonstration of functional code often made believers out of previously skeptical systems engineering teams. They also consistently reported that the demonstration of cost, schedule, quality, insight, or predictability improvements via pilot projects also garnered positive feedback from government program offices, which made it easier to secure leadership buy-in and sponsorship for expanding the use of Agile on future efforts.   Stakeholder involvement. Continuous collaboration with stakeholders is often difficult to achieve in a DoD setting due to factors such as lack of experience and lack of availability due to operations tempo or lack of funding. This collaboration is also challenging due to the variety of stakeholders that may bring conflicting requirements and/or priorities to the table. Certification and accreditation processes were cited as the most particular pain point, due to constantly evolving requirements and the typical "black box" nature of the processes. Defining and evolving requirements. Agile practitioners accept that the unknowns at the inception of a program are a natural and expected phenomenon, rather than treating those uncertainties as weak points.  Agile software practitioners still report a tendency in many acquisition programs to create detailed software requirements at the inception of the program when the system is decomposed and the initial WBS developed. When detailed requirements are placed on contract at the beginning of a program, they are typically accompanied by change control boards and engineering change proposal (ECP) processes that many Agile practitioners report to be cumbersome, time-consuming, and expensive to complete.  Verification and validation. In respondent settings where test and evaluation (T&E) personnel were included explicitly as members of the development team, they reported that many of the T&E personnel found significant benefit in developing acceptance criteria for stories and creating acceptance test fragments for portions of the system being completed. They also gained significant insight into the architecture, quality attributes, and functioning of the system, all of which translated into better test readiness when independent test activities were undertaken. Organizational issues and changes to job expectations may hamper efforts to include T&E staff as full team members, but careful communication, coordination, and use of test resources can help alleviate some of these challenges.  Aligning the program roadmap with Agile increments. Agile development teams have worked with programs in a number of ways to attempt to tailor the existing milestones and reviews to more closely align with the manner in which Agile teams deliver software functionality. Many respondents engaged in new system development reported being granted the flexibility of tailoring program milestones such as the preliminary design review (PDR) and critical design review (CDR) by engaging systems engineers and program offices in sprint and iteration reviews. Several respondents reported negotiating for requirements (expressed as capabilities to evolve under the Agile paradigm) and then time-boxing their Agile increments against CDR targets.    Looking Ahead  One of the most important aspects of an Agile implementation is the use of the continuous improvement mechanism of retrospectives. During our interviews, we noted a variety of answers to the question If you could change one thing about Agile interaction with systems engineering, what would it be?  Several themes emerged from the responses, including  improved systems engineering discipline understanding of what Agile methods entail improved communication and reporting of progress for Agile teams alignment of Agile with policies and practices systems engineering process adaptation for Agile  cultural change necessary for the DoD to fully realize the promise of Agile  These retrospectives inform future areas of work, including the appropriate use of metrics for reporting and managing programs employing Agile software development and on DoD contract vehicles and provisions that support the use of these methods.  We welcome your feedback on our research.  Additional Resources To download our technical note detailing this research, Agile Software Teams: How They Engage with Systems Engineering on DoD Acquisition Programs, please visit http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=295943.  To download the technical note, Potential Use of Agile Methods in Selected DoD Acquisitions: Requirements Development and Management, please visit http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=89158.  To view all of our recent publications regarding Agile adoption in the Department of Defense, please visithttp://www.sei.cmu.edu/acquisition/research/. 

Millions of professionals flock to Las Vegas each year for meetings and conventions, and the Society for Human Resource Management is once again part of that group in 2015. Corporate gatherings are big business in Las Vegas, where tourism and related travel activity represent the heart of the metro region’s economy. More than 41 million visitors came to Las Vegas in 2014, according to the Las Vegas Convention and Visitors Authority (LVCVA). Of that group, more than 5.1 million were convention delegates. The city hosted more than 22,000...

The first DWP Digital Academy in Fulham opened for business on 24 February 2014. It was set up to help us increase our capacity and grow more of our own digital capability across DWP. This week we reached an important milestone as our 100th student, Suzanne Butler, graduated from our Digital Academy. In this short film Suzanne talks about what she has learned at the Academy and how DWP is transforming by starting with the user. Keep in touch by following @DigitalDWP.

  Although the definition varies, millennials (also known as Generation Y) are typically considered to be those people who reached legal age around the turn of the 21st century. Currently, millennials comprise approximately 33 percent of the global work force, and estimates from the BPW Foundation project that by 2025, that number will increase to 75 percent. In short, millennials are the future of your business, and they must be managed effectively — and included in your succession planning. The Millennial Personal No generalization is universally true for all...

By Chris Taschner Project LeadCERT Cyber Security Solutions Directorate This post is the latest in a series to help organizations implement DevOps.  Software development teams often view software security as an afterthought, something that can be added on after the product is fully functional. Although this approach may have made some sense in the past, today it’s largely seen as a mistake since it can lead to unanticipated vulnerabilities in released code. DevOps provides a mechanism for change and enforcement when it comes to security. DevOps practitioners should find it natural to integrate a security focus into development iterations by adding security tests to their continuous integration process. Continuous integration is the practice of merging all development versions of a code base several times a day. This practice provides the same level of automated enforcement for security attributes as for other functional and non-functional attributes, ultimately leading to more secure, robust software systems. Making security testing a part of continuous integration enforces security standards on your software and identifies security as a first-class quality attribute of your project. Making this decision from the start on a new project enables those responsible for development and operations to make knowledgeable decisions about the architecture, design, and implementation with full consideration given to necessary security requirements. This process may mean choosing certain technologies over others based on security concerns. For instance, choosing to implement secure sockets layer (ssl) rather than sending data in the clear may improve application security. Being forced to make security decisions early may also mean that developers are incentivized to define expected development processes in a way that requires a certain level of security-focused unit test coverage for critical modules. For instance, employing tests to check that sql injection prevention is being employed properly.  By enforcing these decisions through continuous integration, teams can use their existing DevOps practices to ensure an unwavering—yet attainable and efficient—focus on software security. The image above represents one approach for adding security testing to the DevOps cycle.  While continuous security testing on new projects is clearly ideal, a strong argument exists for retrofitting security testing to continuous integration for ongoing software projects, even if security testing has been previously non-existent. As new features are secured, existing unchanged features may also see security benefits. Moreover, exposing the lack of security thinking in previous processes (e.g., by automating test coverage metrics or failing builds for security oversights) can motivate developers to refactor and secure previously unattended code. While this new security influence may take some time to propagate through existing codebases, fostering a security-aware culture in software development teams is a long-term win for any organization. Every Thursday, the SEI Blog will publish a new blog post that will offer 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.

Callum Davies - HR Fast Stream Graduate I joined my first discovery project 4 weeks ago - as part of the HR Product Owner team. I work within a digital capability team, mainly on permanent recruitment for digital talent, understanding how we can attract and retain some of the top talent out there. I’m also an HR Fast Stream Graduate freshly out of university with a degree in Philosophy. This was my first real, immersive experience of agile, and a fascinating one. It has been an incredibly different journey than traditional projects I have worked on within HR as there has been an immense focus on aesthetic working, sharing and constantly thinking outside the box to produce some brilliant ideas. It has been eye-opening as to how effective agile can be in such a small space of time with an incredible team and I can’t wait to see where else this could be applied within the department. We were discovering how to improve the way we attract people with the right talent and skills to apply for digital and technology roles in DWP. Surely that should be easy? Who wouldn’t want to work here, right? We just need a website to point everyone at and, job done. That might be where the ideas started, but thanks to agile, we ended up with a much broader, more interesting and hopefully more effective set of products. We went from ideas to an alpha product in 6 days of intensive teamwork, collaboration and challenge. What I loved about agile is that it made everyone take a step back and think about the users. Preconceived ideas about the solution don’t really work in the face of clear insight from users. We interviewed recent recruits to discover their experience and used this insight to design personas. We thought about Soph - she’s a JAVA developer, 25-32 years old, shares her code online, keeps up with her friends who work in similar jobs. Soph isn’t looking for a new job but keeps up to date with software development, and has an eye on her future when she plans to start a family while keeping her career moving. The turning point was when we mapped the user journey - we thought about how a user would get from being ‘not aware’, to ‘taking notice’, to ‘interested’, through to ‘finding out more’, then applying for a digital or technology role in DWP. Then we started building the alpha - a range of digital products across different channels, to take the user through the journey of being not aware to applying for a role, as smoothly as possible. We produced a core narrative, and this fed blogs, a twitter feed, a campaign page, a social media approach to engage with relevant sectors and professional audiences. We developed a working prototype, including graphic design and front-end development. The finale was a show and tell where people who will be recruiting into digital and technology roles in DWP liked what they saw, and agreed that the user-centred approach had delivered a better set of products. We’re now developing this into a public beta to launch in January 2015. Users will tell us whether it works, and evaluation of the user journeys will tell us which products are performing and which need to be improved. Then we’ll keep iterating.

By David Svoboda Member of the Technical Staff CERT Secure Coding Initiative A zero-day vulnerability refers to a software security vulnerability that has been exploited before any patch is published. In the past, vulnerabilities were widely exploited even when a patch was available, which means they were not zero-day. Today, zero-day vulnerabilities are common. Notorious examples include the recent Stuxnet and Operation Aurora exploits. Vulnerabilities may arise from a variety of sources, but most vulnerabilities are the result of simple coding errors. Consequently, developers need to understand common traps and pitfalls in the programming language, libraries, and platform to produce code that is free of vulnerabilities. To address this problem, CERT published The CERT Oracle Coding Standard for Java in 2011. This book is version 1 of this standard and was written primarily for Java SE 6, but also covers features introduced in Java SE 7. This coding standard provides secure coding rules that help programmers recognize and avoid vulnerabilities in their products. Each rule provides simple instructions regarding what a programmer must and must not do. Each rule description is accompanied by noncompliant code examples, as well as compliant solutions that can be used instead. In this blog post, I examine a Java zero-day vulnerability, CVE 2012-0507, which infected half a million Macintosh computers, and consider how this exploit could have been prevented through adherence to two secure coding rules. Java Security Background Java was designed in the early 1990s with security in mind. Java’s creators wanted it to have the ability to run untrusted code that could be immediately delivered and run over the network. With the growth of the World Wide Web, this requirement translated into the ability to run Java applets over the web. Because an applet need not be trusted, Java required that each applet run in a security sandbox maintained by an object called the SecurityManager. This object acts as a chaperone, overseeing what an applet does and generating a SecurityException if the applet violates a security policy. A SecurityException typically causes the applet to terminate without disturbing the rest of the user’s browsing experience. Actions forbidden by the SecurityManager include accessing the file system accessing the network (except the host it came from) running external programs disabling the SecurityManager However, a signed applet may request from the user the ability to do some or all of these privileged actions. Java’s huge (and open-source) core library provides a large attack surface that can conceal many vulnerabilities. As Java evolves, the library grows, and hackers know that a large codebase means many new vulnerabilities can be found and exploited. Each vulnerability is a golden opportunity for hackers to gain recognition among their peers or to sell their exploit for big bucks on the black market. Roger A. Grimes reported in InfoWorld that an increasing number of governments are buying hackers’ exploits—or hiring the hackers. CVE 2012-0507 and the Flashback Trojan Jeroen Frijters, technical director of Sumatra Software, first discovered the vulnerability later classified as CVE 2012-0507 in 2011 while developing IKVM, a Java Virtual Machine (JVM) for .NET. Frijters practiced responsible disclosure by notifying Oracle when he discovered the vulnerability, coordinating his publication of the vulnerability details with Oracle’s release of an update to Java (1.7.0_03), which disabled the vulnerability in February 2012. Meanwhile, the Mac Flashback Trojan had languished in obscurity for several months until it was altered to exploit the Java vulnerability in March 2012. Apple had supported Java ever since Mac OS X was released in 2001. Moreover, it had distributed and updated Java as part of OS X itself. Unfortunately, Apple had not applied Oracle’s patch until the exploit started attacking Macs in the wild. After its makeover, Flashback managed to infect over 500,000 Apple computers, and 22,000 Apple computers remained infected as of January 2014. Apple has unbundled Java from OS X and no longer distributes Java. Mac users who wish to install Java must now download it from Oracle. Preventing Flashback Earlier this year, Milton Smith, who leads the strategic security program for Java products at Oracle, asked Robert Seacord and me to participate as reviewers on the JavaOne 2014 Security Track review team. He also encouraged us to propose a Java exploit presentation for the track. Our presentation focused on how the Flashback vulnerability could have been prevented. To prevent future exploits, it is important to understand how these mistakes occurred. Two issues were at play in Flashback, which the developers could have prevented had they followed our Java coding rules: One common principle of object-oriented design is that every class has data that is private; only that class can manipulate that data. The AtomicReferenceArray class contains a private array but does not ensure that this array remains private. This class is also serializable, which allows an object of this class to be written to a file that can later be deserialized, that is, read back into memory. The diagram below illustrates the data structure they produced. This data structure could not have been produced by running Java because the AtomicReferenceArray would not have allowed its private array to be accessed by any other data structure. The attackers serialized an AtomicReferenceArrayobject to a file. They modified this file so that the deserialized object contained a public handle to the AtomicReferenceArray’s private array. Deserializing this data structure was possible because the AtomicReferenceArray failed to override the default deserialization method, which allowed outside access to the internal array. Failure to override the default deserialization method violates the following CERT rule: SER07-J Do not use the default serialized form for classes with implementation-defined invariants Oracle mitigated the vulnerability by adding the following method to AtomicReferenceArray:   private void readObject(java.io.ObjectInputStream s)                throws java.io.IOException,                       ClassNotFoundException          Object a = s.readFields().get("array", null);          if (a == null || !a.getClass().isArray())                 throw new java.io.InvalidObjectException                         "Not array type");          if (a.getClass() != Object[].class)                 a = Arrays.copyOf((Object[])a, Array.getLength(a),                         Object[].class);         unsafe.putObjectVolatile(this, arrayFieldOffset, a);} This method is invoked whenever an AtomicReferenceArrayis deserialized. By making a private copy of its internal array if the array is not of type Object, this class guarantees the privacy of its internal array, disabling the exploit. The second issue allowed an attacker to insert an object into the AtomicReferenceArray’s private array and then extract it as an object of a different class. The JVM was consequently tricked into thinking that the object is of a different type than it actually is. In the Flashback exploit, MalClassLoader is a malicious class derived from the benign ClassLoader class, which contains a defineClass() method that allows the creation of new code. This method is accessible only to subclasses, including the malicious MalClassLoader class. The Java security manager prevents an unprivileged applet from creating custom class loaders. Unfortunately, the exploit tricks the JVM into believing that a preexisting class loader object is actually a MalClassLoader object. Consequently, this object could use defineClass() to build a new Java class from an array of bytes and execute its default constructor. This new class is created with full privileges; the security manager was instructed not to prevent the new class from doing anything. The new class then disabled the security manager, which effectively enabled the rest of the exploit code to do anything normally forbidden by the SecurityManager. Java defines heap pollution as a condition in which one class is expected to contain elements of one type but can inadvertently contain an element of another type. The JVM has mechanisms to prevent heap pollution or detect if it has happened, but heap pollution can still be successfully exploited by an attacker. In confusing a ClassLoader object with a MalClassLoaderobject, this exploit polluted the AtomicReferenceArray object, which violates the following CERT rule: OBJ03-J Prevent heap pollution In Version 1.0 of the standard, OBJ03-J was titled "Do not mix generic with nongeneric raw types in new code," but was updated in response to community feedback. Future Work Java is a victim of its success: its widespread use and popularity have made it a lucrative target for hackers, similar to Microsoft Windows. Java includes a huge library with many features, some of which are obsolete or deprecated. To prevent future Java vulnerabilities, Oracle  is working to comply with Java Secure Coding rules during ongoing development and maintenance of the Java codebase. Likewise, compliance with these rules is critical for Java developers outside of Oracle even if their software is not used as widely as Java itself. We are currently updating the CERT Oracle Coding Standard for Java for Java SE 8 on our community wiki. We encourage the community to participate in the continuing evolution of the standard. Anyone is free to browse the standard and submit comments, and experts are frequently invited to become editors. Community involvement is essential to producing a high-quality coding standard. There are both commercial and open-source tools such as FindBugs that identify potential violations of the Java Secure Coding rules.  Additional Resources To sign up for a free account on the CERT Secure Coding wiki, please visit http://www.securecoding.cert.org. To subscribe to our Secure Coding eNewsletter, please click here. For more information about the CERT Oracle Secure Coding Standard for Java, please visithttps://www.securecoding.cert.org/confluence/display/java/The+CERT+Oracle+Coding+Standard+for+Java.

Chris Beardsell I’m Chris Beardsell and I’ve been working as a User Researcher in DWP for a bit under 1 year - but what brought me here? I’m constantly, endlessly, irritatingly curious about users. I want to know what makes them tick, what online services they use, what’s in their head when they think about using a government service. Users are fascinating and I want to understand more about their needs - they don’t always think like me or the organisation, they don’t act the way I might expect, they want different things to meet their needs, not my or the organisation’s needs. So how do I satisfy my curiosity? I devise different research strategies, depending on the users or the service that’s being designed. I might use focus groups, maybe a questionnaire, maybe bring users into user testing laboratory conditions to explore them in more detail. And then there’s the analysis of what I find. Actually, I like that as much as I like the curiosity. I analyse the results, identify trends, feed these into the development work for the team to come up with prototypes. But I don’t work alone - I might sound like an introvert (if anything I’m an extrovert, but let’s not get into labels…) - but collaborating with everyone in the agile team is a real buzz. All the user research in the world is worthless unless I can communicate the insights so that the team gets a strong and shared understanding of the user. The user research will define the design and development of services from early stage concept and prototypes through to building alphas and betas. But why did I indulge my curiosity as a user researcher in DWP? It’s so I can make a difference. Every day, DWP helps almost 10,000 people move off Jobseeker’s Allowance. Every year, DWP takes 4m job vacancies for 330,000 employers and processes 7.35m benefit claims. In 12 months DWP will collect or arrange over £1.2bn of child maintenance on behalf of 900,000 children. And pay 22m customers £165bn in benefits and pensions. Think of all those users - we’re designing and delivering public services that millions of people rely on. We transform lives by helping the most disadvantaged people to turn their lives around. Right now, it’s a great place to be a user researcher.

Well, "Mad Men" is no more. As AMC marketed it, we have come to an "end of an era." Or have we? While it was only a television show, or so people try to tell me, the workplace implications resonated with so many of us in the HR/business community. Perhaps that is because, while much has changed, some things are still painfully similar. Here are six themes from Mad Men which are as relevant today as they were in the "Mad Men days." Knowing...

By Tim PalkoSenior Member of the Technical Staff CERT Cyber Security Solutions Directorate This post is the latest in a series to help organizations implement DevOps. Environment 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.  Looking back on almost every problem I have seen in new production deployments, I find it hard to think of one issue that wasn't due in some part to lack of parity. For developers, this pain is felt when integrating and testing code. In a traditional sense, the problem is already solved. Virtualization is old news, even for personal machines, enabling developers to recreate the actual deployment target platforms for their local development. Provisioning an environment is a somewhat older trick with origins as old as shell scripts, made even more robust with the advent of automated environment provisioning tools like Chef and Puppet. So, why is parity still an issue? Or is it? 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. Let's look at an example Vagrantfile that stands up and provisions a RHEL 6.5 server with PostgreSQL and Nginx: Vagrant.configure("2") do |config| config.vm.box = "rhouinard/oracle-65-x64" config.vm.network :forwarded_port, guest:80, host:8000 config.vm.provision :chef_solo do |chef| chef.add_recipe "postgresql::server" chef.add_recipe "postgresql::client" chef.add_recipe "nginx" chef.json.merge!({ :postgresql => { :password => { :postgres => "idontlikerandompasswords" }, :pg_hba => [{ :type => 'host', :db => 'mydb', :user => 'mydbuser', :addr => '127.0.0.1/32', :method => 'md5' }] } }) end end This isn't the simplest example, but it shows us a sample of what we can do with Vagrant. Reading from the top, we see that we are declaring a "box" or target VM: RHEL 6.5. Vagrant will fetch this box from its own cloud provider (Vagrant Cloud), a network file system, or another URL, and work with VirtualBox automatically to stand it up. Next in the example, we forward activity from the host’s (your development machine) port 8000 to the guest VM on port 80, which allows us to run a web server listening on port 80 inside the VM, but test it by hitting port 8000 on our host system. At this point you may be asking what good this does, because isn't our code stuck on the host machine? Actually, Vagrant gives us the root folder of the project as a network share inside the VM. So, the web server in the VM can execute project code, but we still have control over it in the development environment on the host. That is Vagrant in a nutshell. But, don't forget the chef-solo provisioner block, which ultimately gives us 100 percent parity with our test and production environments. We don't need to worry about running chef as a provisioner—Vagrant will do that for us. As developers, we just need to work with the operations team to make sure this configuration is accurate and fulfills the requirements. How does it all work? The following command will kick off the entire process, and at the end, you will have a running, provisioned VM: $ vagrant up This command will start a secure shell on the VM: $ vagrant ssh There are many other Vagrant commands to reprovision, suspend, resume, and restart the VM, as well as manage the Vagrant boxes themselves. For example, you could preconfigure a VM for the team if there is a special requirement, repackage that VM as a custom Vagrant box, and distribute it on a network share. In this case, config.vm.box would look something like: config.vm.box = "http://file-share/vagrant-boxes/oracle-65-x64.box" Vagrant works with VirtualBox, but it also works with VMware Fusion or Workstation, and with some finagling can even stand up and provision VMs on an ESX host. Every Thursday, the SEI will publish a new blog post that will offer 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 read all the installments in our weekly DevOps series, please click here. To listen to the podcast, DevOps—Transform Development and Operations for Fast, Secure Deployments, featuring Gene Kim and Julia Allen, please visit http://url.sei.cmu.edu/js.