There is no shortage of hype around digital transformation but never has the mantra: ‘innovate or die’ been more true. There are some who see technology and the internet as disruptive, forcing organisations to break with the past and re-engineer how they work. Others see it as a game-changing force for good - breaking down the barriers of entry for new businesses and creating a level playing field for both entrepreneurs and innovators. Both are true but it won’t surprise you that I’m definitely drinking from a glass that’s more than half-full rather than half-empty. That said, I do not underestimate the unique challenges and opportunities that digital transformation brings for Government. At DWP, it provides the opportunity to revolutionise how we interact with millions of people everyday and improve the services we provide. Already 80% of Jobseeker’s Allowance claims are made online, but we know there is more to do to bridge the digital gap. Anyone contacting our staff today will probably go to a Jobcentre or call us on the phone. In the coming years, our vision is that most of those interactions will be done via the web or a mobile phone interface. We will continue the move over to automated transactions, which will improve the claims process and free up resources so that our frontline staff can focus more on helping people into work. What DWP does matters for society and the millions of customers who depend on our services. We are reforming the welfare system to ensure it promotes work and helps people lift themselves out of poverty. We are also bringing in root-and-branch change to the pensions system, including a new state pension that increases the attractiveness of saving for retirement. The scale of the change and the challenge is huge. It is this unique intellectual, cultural and operational challenge that persuaded me to come to DWP, having spent most of my career at companies like Goldman Sachs and Vodafone. I have seen for myself during various visits, such as one to Hackney Jobcentre, the pride and passion of DWP staff and the excitement about the potential for change. I am not alone in embracing this challenge, it is a trend we are seeing across the Department with more and more best-in-class digital talent from outside Government seeing DWP as their Whitehall destination. At DWP, we offer the chance to get involved in something that is genuinely transformational and unparalleled in terms of complexity and scale by anything in the UK private sector. Today we take the next step in a journey of changing the DNA of the DWP. We are starting the recruitment for 25 posts to further enhance our already burgeoning digital talent and capability. It builds on the steps we have already taken including launching the DWP’s first-ever Digital Academy. The Academy will provide a range of intensive training courses in how to work in our digital programmes. It is supported by other departments, including Government Digital Service who are forerunners in blazing the trail for digital innovation in Government. We want hundreds of our key employees to go through it in coming months. The new recruitment focuses on the following roles: Web Ops, Developers and User Experience (UX) designers. They will make a huge difference in improving the customer and claimant experience. The projects the successful individuals will work on are across a whole range of major programmes including the Single Tier pension, Carers Allowance and Personal Independence Payment as well as Universal Credit. This most radical transformation of the welfare state in Britain has understandably attracted attention in the media. But, as I saw recently in Hammersmith Jobcentre, Universal Credit is profoundly better than the service it replaced and is changing lives for the better. I truly believe that we are making good progress in the development of an enhanced future service that we will start testing later this year. But we are not complacent about the digital challenges ahead and we need to embrace digital change in Government. We need to be even more confident and bold, embracing digital innovation and taking a radically new approach, testing new ideas like Buzzfeed. It might mean that instead of the DWP working with suppliers to develop a piece of software in six months, that we up the pace and try to do it every two weeks - allowing us to continually improve the service and test new ideas. Enhancing our digital capability will help us do this and deliver a better service for the public. Today is another important step in that journey. You can find out more detail about the jobs on offer here: Web Ops: http://ow.ly/wKhxI Java Developers: http://ow.ly/wKhiL User Experience designers: http://ow.ly/wKg74

By Joseph Elm Program Integration Manager Software Solutions Division In today’s systems it’s very hard to know where systems end and software begins. Software performs an integrating function in many systems, often serving as the glue interconnecting other system elements. We also find that many of the problems in software systems have their roots in systems engineering, which is an interdisciplinary field that focuses on how to design and manage complex systems over their life cycles. For that reason, staff at the Carnegie Mellon University Software Engineering Institute (SEI) often conduct research in the systems engineering realm. Process frameworks, architecture development and evaluation methods, and metrics developed for software are routinely adapted and applied to systems. Better systems engineering supports better software development, and both support better acquisition project performance. This blog post, the latest in a series on this research, analyzes project performance based on systems engineering activities in the defense and non-defense industries. The Case for Systems Engineering An understanding of the value of systems engineering is necessary to justify a project’s investment in systems engineering resources and activities. In 2010, the DoD encouraged the National Defense Industrial Association (NDIA) and the SEI to develop a stronger business case for systems engineering by expanding on a 2007 survey of systems developers. We responded by conducting a new survey in collaboration with not just the NDIA, but other professional organizations including the IEEE-Aerospace and Electronic Systems Society, and the International Council on Systems Engineering (INCOSE). For this latest study, we surveyed 148 individual projects at organizations developing systems to obtain answers to the following questions: What systems engineering activities do you perform on your project? How well does your project perform against cost, schedule, and technical objectives? How challenging is your project? Although most of the surveyed projects supply systems for the U.S. defense sector, we also received some responses from organizations serving other market sectors and operating in different countries. We distributed a questionnaire that collected information from participating projects along three dimensions: systems engineering (SE) capability. We assessed systems engineering capabilities deployed on the project by investigating both the presence and the quality of work products resulting from SE activities. These work products were selected from those listed in the CMMI framework by a panel of SE experts. Based on this assessment, SE deployment for each project was categorized as low, medium, or high. project performance. We assessed project performance as a combination of cost performance (satisfaction of budget), schedule performance, and technical performance (satisfaction of requirements). Again, based on this assessment, project performance for each project was categorized as low, medium, or high. project challenge (PC). Some projects are inherently more challenging than others due to factors such as size, duration, technology maturity, interoperability, requirements, etc. Based on the combination of these factors, project challenge was categorized as low, or high. In the 2012 report The Business Case for Systems Engineering Study: Results of the Systems Engineering Effectiveness Study, we reported our initial results, which found a strong relationship between SE deployment and project performance. In particular, as projects applied more SE capabilities, they delivered better performance. For example, among those projects deploying the least SE, only 15 percent delivered the highest level of project performance. Among those deploying the most SE, however, 56 percent delivered the highest level of project performance. As one would expect, our initial analysis also showed an inverse relationship between project challenge and project performance—more challenging projects do not perform as well as less challenging ones. But, we also learned that SE practices became even more valuable when used with these challenging projects. For the most challenging projects, the number of projects delivering high project performance increased from 8 percent to 62 percent with increased SE deployment. This result shows the increasing need for SE as projects become more challenging. Defense vs. Non-Defense Projects In our latest research, we revisited this data to study differences between projects in the defense and non-defense domains. We wanted to know if there were differences in the application of systems engineering, the performance of projects, and the effectiveness of the applied SE. Our aim with this most recent analysis was to identify best practices in one domain that could be transplanted to the benefit of the other domain. As detailed in our recently published report on this latest research, The Business Case for Systems Engineering: Comparison of Defense-Domain and Non-Defense Projects, our latest analysis compared 75 defense projects with 32 non-defense projects from the fields of electronic equipment, communications, and health care. The 75 defense projects were a subset of the 116 defense projects responding to the 2012 survey. This subset was chosen to produce a sample of projects representing the same degree of project challenge as the non-defense projects. We found that—when examining budget, schedule, and requirements satisfaction—performance against budget and technical requirements was the same in both defense and non-defense domains. With respect to schedule, however, non-defense projects performed somewhat better than did defense projects. We examined the degree to which systems engineering was deployed among defense and non-defense projects. We measured deployment of SE practices on a scale of 1 (little SE deployment) to 4 (significant SE deployment). We also examined both the total SE applied to the project, and the SE applied in specific areas such as product architecture development, requirements, and verification. As shown in the figure below, we found that, for almost all specific areas, non-defense projects performed less systems engineering than defense projects. When we analyzed the relationship between SE deployment and project performance, we found results similar to those of the initial study. In both the defense and non-defense domains, projects that deployed more SE delivered better performance. However, we also found that most of the relationships between SE deployment and project performance were stronger in the non-defense domain than they were in the defense domain. Thus, the non-defense projects seem to getting a larger return from the SE investments. This result is shown in the figure below. Wrapping Up and Looking Ahead The findings of our analysis are summarized as follows: For both defense domain projects and non-defense projects, projects with better SE deployment deliver, on average, better project performance. Non-defense projects deploy slightly less SE than defense projects Non-defense projects deliver slightly better project performance than defense projects, primarily due to better adherence to schedule. The strength of the relationships between SE deployment and project performance is stronger for non-defense projects than for defense projects. The data we have collected does not provide any insight into the root causes of these differences; it merely indicates a measurable difference. These differences may be the result of an evolutionary construct. Perhaps non-defense projects are adopting new development technologies more rapidly than defense projects. Or the difference could be attributed to the processes that defense projects follow. Further study of these questions may identify processes and practices that can be transplanted from the non-defense domain to the defense domain to produce improved performance and acquisition in the Department of Defense. Looking ahead, I am interested in conducting further research with projects in non-defense domains to gain insight into how they deploy their systems engineering and to develop a more concrete understanding of why non-defense projects are more effective in their systems engineering performance, with respect to schedule. We welcome your feedback on this research in the comments section below. Additional Resources The technical report The Business Case for Systems Engineering: Comparison of Defense-Domain and Non-Defense Projects, can be downloaded at http://resources.sei.cmu.edu/asset_files/SpecialReport/2014_003_001_91760.pdf. The technical report The Business Case for Systems Engineering may be downloaded at http://www.sei.cmu.edu/library/abstracts/reports/12sr009.cfm.

Think about your workplace and the meetings that you attend throughout the week. Which ones are well-run and which are a waste of time? What is it about the well-run meetings that make them so useful and effective? Do they start on time, end on time and stick to an agenda? Are there next steps and assignments? Are side conversations quickly averted? Time Wasted How much time do we spend in meetings?  According to the online article How Much Time Do We Spend in...

Its been a busy few weeks since our last update. Some of us have started on a new project, we’ve delivered a presentation to a conference of 400 people whilst still continuing on the journey of building our capability. Shortly after the hack day we were asked to present our team at the ITPD Conference. The theme was "Capability" so it was a natural for us to be asked to demonstrate our skills. We decide the use the Raspberry Pi robot we’d already built and talk about the journey we have been on, demonstrating the skills we’ve learnt so far. We were allocated 30 minutes for our session. By using Skype we were able to show live the robot moving around our purpose built maze. We demonstrated the robot moving, first by user input (which resulted in a lot of errors and crashing!) and automated script (which worked perfectly). We were very well received with many people commenting on how what we were doing was long over due and interested to follow what we were doing. We also received quite a lot of interest from people with coding experience on wanting to join the team! Also on the day we had a session on Agile Delivery, presented by Jim Downie. This involved nominating a project manager around our table, who were then given a list of requirements, weighted with differing scores depending on complexity. We were then tasked to build the requirement using coloured blocks. Queue lots of discussions and frantic searching for "one more green 2×2 block!". PM’s, BA’s and "Dev’s" working in harmony……(!)   Also in May, four of the team (Nathalie, Mike, Donna and Paul) started work with the PIP project, providing some assistance with writing a PIP Information Service. There is an aggressive deadline for delivery of PIPIS (anticipated go-live for PIPIS to coincide with phase 3 release for PIPCS in September ‘14). We have been using html and css and using the Razor syntax based on the C# programming language, the language used most often with ASP.NET MVC. There are also elements of JavaScript and JQuery which we have been getting to grips with, and we have been using the MVC framework [model view controller] which is a software architectural pattern for implementing user interfaces (for example, the PIPIS screens for Personal Details, Entitlement Details, Payments Details etc) This week, Capgemini have transferred the work we have done into their own dev environment and are guiding us through our first Agile project management environment, with co-location, pair programming, daily stand ups, 2 week time-boxed delivery Sprints and the like. Seeing first hand what a true Agile delivery should look like - and at pace - is going to be invaluable to us and we hope to bring what we have seen and learned back into DWP Finally, Adrian and I are still here in Carers. We are learning Java (from a real life, thick, heavy textbook!) continuing our learning of Agile in a live environment and gleaning as much knowledge as possible from the guys on the project. We have been busy compiling a list of software used by the project that will need procuring, following the processes involved for the fortnightly releases. In the coming weeks we have been asked to talk at Civil Service Live (North West) about building capability within DWP IT and continuing our own learning in our respective projects.

By David Keaton Senior Researcher CERT Secure Coding Initiative According to a 2013 report examining 25 years of vulnerabilities (from 1998 to 2012), buffer overflow causes 14 percent of software security vulnerabilities and 35 percent of critical vulnerabilities, making it the leading cause of software security vulnerabilities overall. As of July 2014, the TIOBE index indicates that the C programming language, which is the language most commonly associated with buffer overflows, is the most popular language with 17.1 percent of the market. Embedded systems, network stacks, networked applications, and high-performance computing rely heavily upon C. Embedded systems can be especially vulnerable to buffer overflows because many of them lack hardware memory management units. This blog post describes my research on the Secure Coding Initiative in the CERT Division of the Carnegie Mellon University Software Engineering Institute to create automated buffer overflow prevention. For greenfield software development projects, which are projects developed without constraints from any previous system, it may be practical to mandate a language subset or annotations. Most development efforts, however, are extensions or modifications of existing code. It is therefore necessary to find a solution to eliminating buffer overflows that can work with legacy code. The catalyst for this research occurred prior to my arrival at CERT, while I was consulting for a large company that deployed a 3-million-line code base. The same potential buffer overflow problem kept cropping up, so I launched a project at that company to remediate the problem. We picked several thousand instances of the potential buffer overflow bug. We then assembled 10 engineers and, after dividing the work equally, went in and fixed the bugs manually. What we found was that while we were successful in preventing a lot of bugs associated with buffer overflows, we introduced more bugs than we would have introduced had we been writing the code from scratch. We knew this because that company kept very good records about the quality of their code at each stage. Clearly, our approach was sound, but how we went about it was wrong. We needed an automated approach to buffer overflow protection to eliminate the potential for human error. Foundations of an Automated Approach Because C focuses on performance and being close to the hardware, bounds checks on array references and pointer dereferences are not part of the language. Sometimes a compiler can prove at compile time that an access is in bounds, but usually this is not the case. If the user desires bounds checking, then for the memory accesses that cannot be resolved at compile time, the compiler must insert additional instructions into the generated code to perform the checks. The time the processor takes to execute those extra instructions at run time is the performance overhead of a bounds checking mechanism. I have found that many researchers report excellent low overheads for automated buffer overflow elimination schemes while in practical use they are actually substantially higher. For example, one set of researchers may report very low overheads by taking advantage of a trap on misaligned memory accesses, but many processors do not trap when dereferencing misaligned pointers. As a result, the check for misalignment must be performed by software, which causes a much higher overhead. Another set of researchers may use a shadow memory by dividing up the address space for the program and for the overflow checking. Again, this may not work in the practical domain because it requires operating system modifications. I investigated what performance could be achieved in the practical realm and how that performance could be improved for deployment of an automated, compiler-based memory safety checking tool. Because the goal was to support legacy code, there were additional constraints: any approach used could not require changes to the source code application binary interface (ABI) compatibility should also be maintained because developers do not have control over the complete system on which the application will run  it should be possible to link checked code with unchecked binary libraries for which the source code might not be available I began with two memory safety checkers that meet these criteria, SAFECode and SoftBound.  Methodology I selected a small set of programs to use as a benchmark from the SPEC CPU 2006 suite because they are written in C and compile cleanly with Clang/LLVM 3.2, the latest version of the compiler for which both SAFECode and SoftBound were available. I measured the overhead with just the source code available on the Internet and then applied my own optimizations and measured it again. As described in an August 2014 technical note I wrote with Robert Seacord, Performance of Compiler-Assisted Memory Safety Checking, I made three performance enhancements to SoftBound to investigate their effects on performance. First, I hoisted spatial memory access checks out of loops when the loop bounds were known on entry. As an example, consider the following function: #include <stddef.h>void foo(int *a){  for (size_t i = 0; i < 100; ++i)    a[i] = i;} The figure below shows the generated LLVM code, including the effect of hoisting the check of the store to a[i] out of the loop. The optimization removes the struck-out text preceded by minus signs in the figure and inserts the bold text preceded by plus signs. The beginning of the check is adjusted to be the first element accessed (the beginning of array a), and the length of the check is adjusted to include all accesses that will be performed by the loop (400 bytes), rather than checking each iteration separately. define void @foo(i32* nocapture %a) nounwind uwtable ssp {entry:  %0 = tail call i8* @__softboundcets_load_base_shadow_stack(i32 1) nounwind  %1 = tail call i8* @__softboundcets_load_bound_shadow_stack(i32 1) nounwind+ %bitcast = bitcast i32* %a to i8*+ tail call void @__softboundcets_spatial_store_dereference_check(i8* %0, i8* %1, i8* %bitcast, i64 400) nounwind  br label %for.bodyfor.body:                                         ; preds = %for.body, %entry  %i.04 = phi i64 [ 0, %entry ], [ %inc, %for.body ]  %conv = trunc i64 %i.04 to i32  %arrayidx = getelementptr inbounds i32* %a, i64 %i.04- %bitcast = bitcast i32* %arrayidx to i8*- tail call void @__softboundcets_spatial_store_dereference_check(i8* %0, i8* %1, i8* %bitcast, i64 4) nounwind  store i32 %conv, i32* %arrayidx, align 4, !tbaa !0  %inc = add i64 %i.04, 1  %exitcond = icmp eq i64 %inc, 100  br i1 %exitcond, label %for.end, label %for.bodyfor.end:                                          ; preds = %for.body  ret void} Figure 1: LLVM Code Showing the Effect of Hoisting a Bounds Check Out of a Loop To prevent spurious error reports, with the check being executed and the offending access not executed, the check is hoisted only if it post-dominates the first basic block inside the loop. The check post-dominates the loop’s first basic block if all possible execution paths from that basic block to a loop exit pass through the check. I next hoisted bounds checks out of a function and into its callers when the compiler could see all calls to the function, so that a bounds check will be executed somewhere (if necessary) if it is deleted from its original function. To see how this might be beneficial, consider the following program: #include <stdio.h>#include <stdlib.h>static void foo(unsigned char *a){  for (size_t i = 0; i < 100; ++i)    a[i] = i;}int main(void){  unsigned char a[100];  foo(a);  for (size_t i = 0; i < 100; ++i)    printf(" %d", a[i]);  putchar('\n');  return EXIT_SUCCESS;} If the bounds check for the access to a[i] is first hoisted outside the loop in foo and then up to main, it is now in a position where the size of array a is known. Because the length of the bounds check is also known, it can be compared against the size of a to determine if the bounds check can be eliminated entirely. This elimination occurs in the case of the preceding program. If, after hoisting the bounds check into the caller, there still is not enough information to eliminate the bounds check, it is performed within the caller in hopes that it can still be eliminated along other call paths to the original function. The mechanism used to accomplish this optimization is to treat a bounds check in the called function as a precondition for that function (called a requirement by Plum and Keaton). In this case the precondition is that the memory space pointed to by a is at least 400 bytes long. Then all requirements are checked at their call sites to see whether the bounds checks can be eliminated for that call path or merely hoisted out of the called function. Inlining can accomplish the same thing by effectively hoisting a bounds check into the calling function, where there might be enough information to eliminate the check. Therefore, this mechanism provides a benefit in cases where inlining is not performed, such as when the called function is large. SoftBound is implemented so that it operates on optimized code. First the optimizations are run, then SoftBound is run, and then the optimizations are repeated in an attempt to improve any code added by SoftBound. I found that unrolling loops thwarted some attempts to hoist bounds checks. Fully unrolled loops contained a sequence of memory accesses in straight-line code in place of one access within a loop. I therefore disabled loop unrolling. Alternative approaches would have been to disable it only for the first pass of optimizations or to write an additional optimization to combine the adjacent bounds checks that result from unrolling loops. The third change was to test the performance of bounds checks on stores only (to prevent arbitrary code execution), or on strings only (because incorrect string management is a leading cause of vulnerabilities), or only on stores to strings. Limiting the bounds checks in this way can provide some insight into the tradeoff between security and performance. I also measured the performance of SAFECode and SoftBound with checking turned off, to discover the performance effect of the maintenance and propagation of metadata via the object table maintained by SAFECode or the pointer table maintained by SoftBound. To accomplish this, I disabled the portions of SAFECode that emit pointer arithmetic checks and bounds checks, and disabled the portions of SoftBound that emit bounds checks, leaving the bookkeeping code only and thereby establishing a ceiling for the performance benefit of bounds check optimizations. Results Overall, with the optimization of hoisting bounds checks out of loops, the average program ran 4.72 times slower with buffer overflow checking, a rate that was significantly slower than I had hoped. The programs experienced an average slowdown of 5.36 times without the optimization. Next, as is also detailed in the technical note, I charted the slowdown for performing bounds checks only on stores, only on strings, and only on stores to strings, in addition to hoisting bounds checks out of loops and functions. With the optimization plus checking only stores, the average program ran 2.58 times slower than it did without buffer overflow checking. All three cases provided a performance benefit. The three are similar in magnitude, indicting that a useful tradeoff between performance and security may be achieved by checking only stores. Next, I investigated the performance breakdown by examining the metadata propagation performed by SAFECode and SoftBound to gain more insight as to how the time is spent. There are two parts to run-time automatic buffer overflow elimination. One part involves tracking the bounds information that is needed to check for buffer overflows. This metadata must be available for the other part, the actual checking against the bounds to detect buffer overflows. In SAFECode, the actual checking occurs at pointer arithmetic and at loads and stores. In SoftBound, the actual checking occurs only at loads and stores. When I turned off all of the checking code except for what was needed to pass the bounds data around inside the program, I found that the overhead required by metadata propagation by itself yielded an average overhead of 2.07, which is almost the entirety of the overhead. For SoftBound, which is the main codebase that I was working with for buffer overflow elimination, there would be a vast advantage to working on metadata propagation as opposed to the checks that occur at each store. I compared this with SAFECode. SAFECode has much worse overhead overall. The average overhead, without any optimization, was 41.72 times slowdown with the buffer overflow checking, but with no optimization. When I checked the overhead of SAFECode’s metadata propagation only, the average slowdown was only 3.02, which is not much worse than SoftBounds’ metadata propagation overhead, which was 2.07. SAFECode’s slowdown was 41.72, and its metadata slowdown was only 3.02, which clearly shows that in SAFECode the most benefit can be gained by increasing the speed at which checks occur at pointer arithmetic and at loads and stores. The conclusion drawn from the results above is that each pointer overflow checking mechanism needs to be considered separately. Challenges and Adjustments In addition to hoisting bounds checks out of loops, I also tried to hoist them out of functions. I reasoned that if I hoisted a bounds check into the caller, there might be information in the calling function to reveal the size of the objects, eliminating the need for a bounds check. Unfortunately, hoisting bounds checks out of functions did not provide a significant benefit. One reason is that this issue is already addressed by inlining. So, if I have a small function working on an array, it will often get inlined into the larger function and then see the object in the calling function at compile time. Another challenge involved the physical structure of the LLVM compiler, which is divided into many different passes. LLVM will perform a pass through the code that it is compiling, and then it will perform another pass. There are function passes, which are performed once for every function in the program, and there are module passes, which are performed once for every module, which is a file (i.e., a collection of functions). SoftBound, it turns out, is a module pass so that it can operate on multiple functions concurrently. In the way LLVM is structured, however, a module pass cannot use information generated by a function pass, which uses information generated by another module pass. This design decision allows for the parallelization of different passes, but negatively impacts constant folding. As a result, constant folding does not occur as intended. If the code contains the computation, 2+2, it will remain as a 2+2 because constant folding is a function pass that makes use of information from another module pass. To mitigate the issue, I added the constant folding myself, manually, to make it work. Now, the 2+2 comes out as a 4, which makes optimization much easier. Looking Ahead There is hope that automated buffer overflow checking will one day perform fast enough to work in future performance-critical systems. After this study was finished, Intel announced a set of future hardware protections called "MPX" Memory Protection Extensions. Once Intel installs those hardware improvements, it is possible that we will be able to use compiler enforced buffer overflow elimination on performance-critical code as well. I welcome feedback on this research in the comments section below.  Additional Resources To read the technical note, Performance of Compiler-Assisted Memory Safety Checking, by David Keaton and Robert C. Seacord, please visit http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=299175.

It’s a great time to be working at the Department for Work and Pensions. We are changing the way we work to make sure that we build digital services which have users at their heart and in a way that allows continuous improvement and iteration. We are using agile approaches and bringing those skills and that culture into DWP to make sure that we deliver the right services for our claimants and customers. For us Digital means One of the critical enablers for our business transformation is digital. For DWP digital means one of the ways that we interact with our claimants and customers. It’s also the automated and efficient way we want our business to operate, and it’s the working culture, performance measures and tools we use to develop our services. Our Digital Academy Leeds Digital Academy students Our Digital Academy is at the heart of our commitment to improve the way we deliver services. Mixing up theory and practice - with site visits and work placements thrown in too - DWP’s Digital Academy programme provides an intensive burst of digital training to specific colleagues across the Department. Based in either London or Leeds, the initial six-week, face-to-face training programme aims to develop the skills needed for us to create and deliver our own successful digital services. The course involves 4 days’ training each week and is led by a mix of DWP officials, members of the Government Digital Service, and external experts. Refresher sessions, follow-up gatherings and online communities keep learning moving forwards after the initial 6 week course. Civil Service Live It’s exciting to be part of something that’s truly transformational and we are proud to be able to demonstrate some of our progress at Civil Service Live 2014. At the Liverpool, Newcastle & London Civil Service Live 2014 events we will be showcasing the work of our Digital Transformation Group, the Digital Academy and 3 of our digital exemplar services. These exemplars services  are Single Tier Pension , Carers Allowance Online and Universal Credit. We’re keen to engage and share information about how each of our exemplars are developing over time and how we are building digital capability within DWP through the Digital Academy. If you are at any of the events I hope you’ll make time to find our stand and come along to say hello. You can ask about, or suggest, future content for this blog by adding comments below and subscribing to future updates. I look forward to hearing from you. You can follow us on Twitter @DigitalDWP.

  Complaint Procedure (With More "Fixes" to Come)  On June 29 - for the twenty-first straight year - - I will have the pleasure to share my expertise on handbooks at SHRM’s 2015 Annual Conference.  Over the years, approximately 10,000 SHRM members have walked away with a new way of looking at their handbooks: "every word counts." Looking back on my Annual Conference programs, my greatest regret has been echoed in my speaker evaluations:  too much material and too little time.  In seventy-five minutes, attendees were given many "take aways" - - but I barely scratched the surface. Until...

I’m sitting in a near pitch black room with only the glare of two monitors and a window into the adjacent room. In it sits a Government Digital Service (GDS) researcher and a member of the public. As I watch the monitors and occasionally look through the window, my immediate thoughts are "what we’ve delivered is good, but how can it be better?" It’s a user research day in Salford for the Carer’s Allowance Digital Service (CADS) with fellow members of the team that have helped deliver the current beta version of CADS. We’re here to observe users completing a prototype version of CADS that the GDS research team has put together to test potential improvements. The users know they are going to help complete a service but nothing more specific, they have all placed themselves low on the Digital Inclusion scale; a 1 to 9 rating of internet and computer skills. Each user is shown into a room with a computer and recording equipment to capture the onscreen clicks, reactions to prototype design choices and answers to the questions the researcher asks. The improvements that we are testing, observing and analysing today are as a result of previous research days that the team have run. In the room containing the team, each member is busily scribbling observations about what we are witnessing while the GDS researcher offers occasional help in completing CADS and asking pre agreed questions to help the team gain insight. Each observation is taken back to the Preston Office Centre where the CADS team is based. These observations are affinity mapped (Post It notes placed on a work board), these are grouped together into themes which will uncover insights into what we’ve seen on the day and what actions can be taken away to improve the service. Some observations confirmed an insight from a previous testing day; these are then turned into user stories to be delivered into CADS beta by the Digital Service Team and the development partner Valtech. So far roughly 60 hours of user testing has gone into the current CADS system, various prototypes tested with lots of users with different circumstances and I.T abilities to bring together a service that is accessible to all, yet tailored to the individual. The testing has helped reduce completion times for users from 45 minutes to 28 minutes and seen an uptake in digital claims from 25% to 50% in only a few months. The CADS team are currently working towards live accreditation which requires the service to meet the 26 GDS standards, the first of which is "Understand user need", something the CADS team are very passionate about. These days provide a fascinating insight into user needs, observing users struggle to complete certain sections due to their circumstances or lack of confidence in their I.T skills really drives home the message that "what we’ve delivered is good, but how can it be better?".  

By Neil Ernst Member of the Technical Staff Software Solutions Division This post is co-authored by Stephany Bellomo Continuous delivery practices, popularized in Jez Humble’s 2010 book Continuous Delivery, enable rapid and reliable software system deployment by emphasizing the need for automated testing and building, as well as closer cooperation between developers and delivery teams. As part of the Carnegie Mellon University Software Engineering Institute's (SEI) focus on Agile software development, we have been researching ways to incorporate quality attributes into the short iterations common to Agile development. We know from existing SEI work on Attribute-Driven Design, Quality Attribute Workshops, and the Architecture Tradeoff Analysis Method that a focus on quality attributes prevents costly rework. Such a long-term perspective, however, can be hard to maintain in a high-tempo, Agile delivery model, which is why the SEI continues to recommend an architecture-centric engineering approach, regardless of the software methodology chosen. As part of our work in value-driven incremental delivery, we conducted exploratory interviews with teams in these high-tempo environments to characterize how they managed architectural quality attribute requirements (QARs). These requirements—such as performance, security, and availability—have a profound impact on system architecture and design, yet are often hard to divide, or slice, into the iteration-sized user stories common to iterative and incremental development. This difficulty typically exists because some attributes, such as performance, touch multiple parts of the system. This blog post summarizes the results of our research on slicing (refining) performance in two production software systems. We also examined the ratcheting (periodic increase of a specific response measure) of scenario components to allocate QAR work. Slicing and Allocation in Agile Projects QARs are often provided in unstructured and unclear ways. QAR refinement is the process of elaborating and decomposing a QAR into a specifiable, unambiguous form achievable in one release and finding suitable design fragments. This process, also known as slicing or sizing, is typically applied to user stories, short, textual requirements popularized by agile methodologies. The requirements community calls such iterative refinement the Twin Peaks model because you iteratively cross between the ‘peaks’ of requirements (the problem domain) and architecture (the solution domain). QAR refinement should produce a unit of work small enough to test, small enough to fit in an iteration, and useful enough to produce value. It should separate abstract requirements into constituent parts so they and their interrelationship can be studied. "[QAR refinement] is a design activity," a software developer recently posted on Twitter. "It surfaces our ignorance of the problem domain."  There are a number of ways to size requirements. Some methods are based purely in the problem space, some are based on the work involved in satisfying the requirement, and some are a mixture of analyzing the problem and possible solutions. These approaches include And/Or decomposition: Split on conjunctions and and or in the requirement. For example, for the requirement "display user name and account balance," one piece would deliver the user name, the other piece the account balance. Acceptance or test criteria: Satisfy one criterion per slice. User stories (an Agile form of requirement with user-focused textual descriptions) often have a list of reasons  for accepting the requirement (story) as done. For instance, "login function works, password validated." Each criterion is a slice. Spike: Add exploratory spikes to backlog where steps are unknown—investigate versus implement. Spikes are specific work dedicated to learning, such as the impact of a new version of a key framework. Horizontal slices: Slice according to architectural layers (such as database, UI, business logic). Commonly seen as an anti-pattern since it creates false divisions of the work. Operation type: Slice according to database operations. One story for create operations, one for read, etc. Hamburger slicing: Create horizontal slices that map steps in a use case, then extend vertically according to improved quality criteria. For example, a user login use case has steps for validating passwords, displaying user history, etc. These are then expanded ‘vertically’ for different options, such as login options OAuth, social media account, or simple user:password. In the two examples described below, we found the most common slicing approach was ratcheting, popularized by Martin Fowler in his blog post "Threshold Testing." Our Approach  Our research question was How do projects slice quality attribute requirements into iteration-sized pieces, and how are these pieces allocated to a project plan or sprint backlog?  QARs, including performance, security, and modifiability, significantly influence architecture. We conducted case studies of production systems (we omit identifying details to protect confidentiality). For each case, we conducted interviews with team leads and architects to understand the teams’ deployability goals and architectural decisions they made to enable deployability. We then performed semi-structured coding to elicit common aspects across the cases.  Based on our analysis, we described the quality attribute work as a series of increments, representing the current state of the QAR, as the requirement is progressively refined and enhanced. Table 1 below shows our conceptual framework. We used a scenario to define each state, with each scenario consisting of a stimulus, some context or background, and a response to that stimulus. Our approach is analogous to an Agile, "Behavior-Driven Development" (BDD)-style "Given <>, When <>, Then <>" model. The value column reports the outcome of that increment. Based on our interviews, refinement happens not only in the stimulus response, but also the context and the stimulus itself. In other words, one can tighten the response (from 10 to 1 ms, for example); one can loosen the context (for all customers instead of just certain customers); or one can expand the range of stimuli (any order versus special order types). We believe refinement of QARs using scenarios creates a reasonably sized chunk of work for analysis, implementation, and possibly even testing during an iteration. Project A Project A developed financial support software for a mid-size firm. The software supported the buying and selling of financial securities. Performance was a key concern, particularly at the close of the financial day. Customers may have to pay interest if they have to borrow large sums of money to hold sell orders overnight if they were not processed by the close of trading. Development cycles were deliver-on-demand, rather than fixed iterations, while customers provided feedback to the developers that informed the work in the subsequent state. Table 1 shows a summary of the state transitions. Below, we describe states that we identified in the first project: These states were refined in three different dimensions (stimulus, context, response). Stimulus: A-S4 to A-S5 illustrates refinement in the stimulus dimension, moving from a single- to multi-user perspective. A second example is A-S2 to A-S3, which illustrates moving from batch processing to individual transaction processing. Context: The initial requirement focused development on the system behavior (simple baseline case) to test ideas before dealing with complexities and uncertainties of the environment. A-S1 to A-S2 illustrates refinement in the context dimension, moving from manual processing to the autopilot solution, by adjusting the boundary of the system with respect to its environment, including the user’s role. Moving from A-S4 to A-S5 accounts for the complexities of the rotary algorithm in the environment. Response: A-S3 to A-S4 illustrates refinement in the response dimension by ratcheting the response measure. The response measure value was refined to less than 1 second for processing individual transactions. This analysis demonstrates that each refinement we captured reflects a change in the evolving requirements context, such as increasing number of orders to be processed or reducing performance threshold for a single order. The team also must make tradeoffs in the measurement criteria, for example, first optimizing for throughput (A-S2) before dealing with latency (A-S3, A-S5). With three dimensions to adjust (stimulus, context, response), ratcheting in one dimension may require easing up on another to make progress. Project A explained that separating performance-related from feature-related requirements in the backlog or when planning and allocating work to iterations was not useful. Project A followed evolutionary incremental development by doing performance-related analysis work concurrently and loosely coupled from implementation sprint work. Separating feature work from performance work is a common pattern that we observe in industry. As analysis work was completed, the work was allocated to sprints. Well-understood changes refining existing features, such as A-S1 through A-S3, were allocated to implementation sprints with minimal analysis. However, in cases where significant analysis was needed (e.g., A-S4), the team created an exploratory prototype to learn more about the problem and investigate alternative solutions while continuing to mature the system and implement ongoing requirements. For A-S4 the changes were more substantial, so the work was allocated to multiple sprints. Project B Project B, described in Table II, was also a financial system with stringent performance requirements. The system functionality included high-speed, stock order processing. Like Project A, the performance iterations are described as state transitions. This project was in the pre-release phase, focusing on evaluating the design to ensure it could meet requirements. The team used a scenario-driven approach to investigate performance risks. Output of scenario analysis is input to the evolving system design and architecture of the next state, as described below. The analysis of this example also shows changes to the stimulus, context, and response, as summarized below. Stimulus: BS-3 shows variations in the stimulus with the artifact changing to focus on a specific part of the system, the queue. Context: B-S2 shows variations in the context by increasing the concurrently processed orders to 1,000 orders while maintaining response time at 0.1 ms. Response: The response goal remained consistent at 0.1 ms throughout all the state transitions. In interviews, however, we discovered that this target was reached over several rounds of tweaking the design, analyzing the response under increasingly stringent conditions, such as described in B-S2, and making incremental improvements. Project B did not separate feature-related and performance-related requirements in their software development lifecycle either. Like Project A, the team conducted exploratory performance analysis and design work concurrently with maturing other features and continuing implementation. Work was integrated into implementation sprints as it became better defined through analysis of design artifacts, prototyping, or both.  Conclusions Ultimately, the purpose of refining QARs is to decompose a stakeholder need or business goal into iteration-sized pieces. The process of allocation then takes those pieces and determines when to work on them. This activity involves both analysis and design: refinement and allocation are explorations of the problem and solution spaces, and evolutionary, iterative development allows for course changes when new information is acquired. Developers work toward satisfying cross-cutting concerns in the context of the effort and ultimate value. We observed that developers refined performance requirements using a feedback-driven approach, which allowed them to parse the evolving performance requirement to meet increasing user expectations over time (expressed as state transitions). Within each state transition, developers refined cross-cutting concerns into requirements by breaking them into their constituent parts in terms of the scope of the system and response to stimuli in a given context. The system and cross-cutting performance requirements evolve as stimuli, context, and response are ratcheted. We see evidence of projects that are better able to sustain their development cadence with a combination of refinement and allocation techniques guided by measures for requirement satisfaction, value, and development effort. As we retrospectively analyzed these examples, we found that these teams did not follow a formal technique; however, they did have common elements in how they refined the work into smaller chunks, enabling incremental requirements analysis and allocation of work into implementation increments. Martin Fowler describes ratcheting as a performance requirement in terms of increasing a specific response measure. Based on what we learned from our interviews, we suggest that this ratcheting concept can be broadened. For example, changes in the evolving context, such as increasing the number of orders to be processed or reducing the performance threshold for a single order, allow for breaking a cross-cutting concern to a reasonably sized chunk of work for analysis, allocation, or testing. We suggest that these examples, which demonstrate ratcheting in multiple dimensions, could be useful for teams struggling with how to break up and evolve cross-cutting concerns during iterative and incremental development. Additional Resources This blog post is a summarization of a paper that was presented at the International Conference on Software Maintenance and Evolution. 

When considering new job opportunities or career moves, there are lots of factors that come into play. Of course people think about salary, benefits, and potential for growth. Many employees also focus on their "fit" [1] with an organization’s culture. But where does that culture come from? The Attraction-Selection-Attrition (ASA) Model [2] was developed to explain how cultures form, how they are reinforced, and why they sometimes need to be forcibly changed. Attraction: Job seekers are attracted to certain companies more than others. Maybe this is because of the company’s brand recognition, its mission, or...