Agile Project Management

Transcription

1 CompuwareCorporation Agile Project Management or How to Be on Time and Within Budget! (Really!) Jon Kern Agile / MDA Evangelist Compuware USA jon.kern@compuware.com Newsletter: V Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 1

2 About Me (as if you care) Doing software since 80s, O-O since ~late 80s 10 years DoD consulting, real-time, flight simulation, centrifuge, fighter agility, etc. Formed Lightship Inc in 95, clients like IBM, Ingersoll First published agile method in 97 Co-author Java Design w/ Peter Coad Joined Peter to form/grow TogetherSoft Sep 99 Led OO/Java workshops, mentored hundreds Led development team in St. Petersburg, Russia Co-author Agile Manifesto, 01 Sold TogetherSoft to Borland in late 02 Recruited by OptimalJ Team Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 2

3 Topics Why is building software so hard? Keys to Successful Agile Project Management Laying the Foundation Gathering requirements Domain Modeling Constructing with Architecture & Quality Estimation Techniques Release Planning Managing Risks Constant feedback and re-estimation Time boxing to meet schedules and budget Iterations 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 3

4 What Makes Software Dev So Hard? Ability to meet the demands of the business Shrinking business cycle, need more business agility Clear business vision/goals for the application Ability to meet the demands of development Crazy schedules/death marches Need for application agility Requirements are nebulous, non-prioritized Striving for effective process & productivity Ability to meet the demands of development Deploying a performant system Building the app properly for the expected lifespan Ask yourself questions like: How would you characterize your current development methodology? Waterfall, RUP, XP, FDD, ad hoc, could be better and so on. What kinds of modeling do you practice? Answers may range from very little (napkin designs? Sketches on whiteboards?), to too much (RUP). How do you manage requirements from conception to manifestation in your application? Here we seek to understand how well you are able to meet customer needs in the end product. Do you try to nail requirements down with 100 pounds of documentation? Or, are you more agile/xp like? Are you able to easily go from requirement to design and implementation? Can you understand/determine the impact of a change request through your application architecture? 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 4

5 Ad Hoc Survey For failed projects (that you read about), what went wrong? Poor requirements? [50%] Poorly-managed requirements changes? [30%] Poor software development methodology? [25%] Unrealistic schedule? [25%] Poor project management? [20%] Lack of user/stakeholder involvement? Lack of qualified people? Corporate politics get in the way? Poor or no architecture? Lack of measurements and controls? 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 5

6 Is this How It Should Be? Why does this happen? Would you like your next <item> built like this? Car, home, airplane, bridge, ICU monitoring s/w Engineering and construction firms don t build things in the way most software gets built Yes, the analogy is well-worn and slightly specious Why is software allowed to so often be done without any engineering? Many Reasons Can we do anything about this? Yes! Are there some better ways? Yes!! 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 6

7 Software & Hardware Engineering Primary difference is that it is indeed soft S/W is viewed as being more changeable at less cost But is it really? Users demand much more flexibility in S/W Spectrum: point solution $ generic/flexible $$$$ We haven t reached the level of H/W standards Not many real software Integrated Circuits to allow quick build-up of system functionality Components still not widespread Except for UI components Patterns/models not as widespread as in engineering/arch. No Component Depot yet 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 7

8 What do we Fix? Common Problems Today Requirements unclear, changes cause disruption Poor architecture & quality, maintenance nightmares Late breakage Delaying risk mitigation Performance woes Non-repeatable processes Lack of testing Blown schedules Built the wrong thing Filled an outdated need Outright abrupt cancellation Doesn t deliver expected ROI (if it was known) Staff is a revolving door 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 8

9 Putting Engineering into S/W Dev Applications need to be architected and designed not just built Hardware/construction engineering uses Processes/Process Improvement Tools (but no silver bullets) Standards Highly Skilled, licensed/certified People Employs System Integration concepts Things aren t just built with no planning Take advantage of the soft and apply more agile techniques (that manufacturing could only dream of) 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 9

10 Where We Are Headed Agile Project Management must be discussed in context Discuss Agile concepts Think about Classic Project Management as applied to software projects (estimating and conducting) Describe how to conduct an agile software project Revisit ways to manage Risk Estimation Scope Time Budget The management techniques I use require being in the right state of affairs. That is, there are some synergistic foundational building blocks that make the techniques all more effective than their singular cumulative value Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 10

11 How Is Software Built? People, Process, and Tools! In about that order Good people will trump poor/non-existent process Good people will either create tools or use tools in an effective manner Process and Tools cannot make up for inadequacies of the development staff Gray matter is a pre-requisite It takes good people to build quality software. I would sooner take a team of 10 or 20 high-quality developers and management that gets it over a team of 50 or 100 with an insane stakeholder. To work with a good team is a tremendous pleasure. Good teams: Will form process if none exists. Will create helpful tools and utilities if none exist Will develop communication strategies to ensure minimal rework Will be able to intuit much of the development requirements Conversely, an under-performing team with old hat management and stakeholders will likely fail regardless of process and regardless of shiny new tools Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 11

12 Agile Development A state of mind, not a set of steps! Shrink waterfall cycle into small iterations Ensure working application and feature progress Make it simpler to embrace change Improve communication between business and IT DEPLOY Deliver business value faster and continuously Running Software: TEST Necessary but not sufficient! Quality & -ilities from the start ANALYSIS DESIGN CODE One of the keys to successful software development lies in the straightforward principles of agile development: Prefer people and communication over tools Prefer working software over reams of documentation Prefer working with customers collaboratively versus contentious contracts Prefer embracing change over rigid project plans The bottom line is to demand progress, but ensure it is on top of a good architecture. Put another way, running software is necessary but not sufficient (even poorly designed software can look good on the surface!). By always supporting frequent, tangible, working results, a team is able to demonstrate progress at developing features to the users. Remember, running software is necessary but not sufficient! Don t be fooled by running software alone It must be built on a good architectural foundation It must not incur technical debt It must be treated as an important asset Even poorly architected software can give the appearance of being good at the user interface level Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 12

13 Agile Manifesto Individuals and Interactions Working software Customer collaboration Responding to change over over over over Processes and Tools Comprehensive documentation Contract negotiation Following a plan While we value the things on the right, we value those on the left more You can read more about these principles at: AgileManifesto.org 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 13

14 Is Project Mgt. Orthogonal to Agile? Classic Project Management Loves detailed tasks, durations, serial/parallel, resources Frequently enjoys fine-grained long-term planning Provides (painful and tedious) tracking of task completion Can easily be a full-time job of mediocre activity Agile Development Loves to do short-term planning in just enough detail Strives to provide accurate feedback of true goals Likes to do the simplest things that work Solution? Software projects need both: Tracking completion of prioritized features no 90%s allowed! Traditional tracking and planning of Major milestones (releases, iterations) Non-feature type tasks Intra-project dependencies In mid-1990s, I still clung to my use of Gantt charts from an engineering perspective to attempt to run software projects. As it turns out, it did not make as much sense to drive every activity that the team was doing to build features into the project plan. In most projects, progress is measured through completing a task (is the wall painted yet?). In software, progress is measured through a more complex concept of completing a feature for the client to be able to use. The best solution is to combine traditional project management for classic tasks and for outer loop management with development cycles. However, for details about what is being completed within each development iteration, keep it simple and agile. Just a list of features being worked on, and whether they are complete or not no partial progress reporting allowed. A simple list no dependencies, nothing complicated. Items on the list that don t get done this iteration can slip to the next Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 14

15 Manage the Right Things! Software is very people-intensive Lots of brain activity Should not be treated like assembly line work Schedule and measure real progress Feature Completion Required tasks to support feature completion Don t mistake activity for progress! Empower the team(s) Don t micromanage, tear down barriers Ask for results, listen for an estimate Demand push-back, keep folks engaged and talking It s all about the client getting features! All too often, we can fall into the trap of being mired down in the minutiae of project management software. We can track all sorts of tasks. We can add resource allocations even partial resources! We can figure out that a QA task for Feature X has to follow the completion of Feature X which of course was on the heels of the Estimate Feature X task. This is a waste of time and effort. If you set things up so the team knows what they are doing on a process basis for EVERY feature, you do not need to even see a set of feature-related microtasks on the schedule! There are plenty of larger issues to worry about in Project Management to pull off a successful project. Micromanaging the team s activity is not one of them. Empower the teams to do their own micro managing. You might be surprised or you may need to find a better team! Remember, you do not deliver the project plan to the end user you deliver ONLY features that work and provide value Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 15

16 Laying the Project Foundation A key to managing is to get things set up properly For requirements gathering For estimating For constructing For maintaining version after version Skip this and you are likely inefficient, probably micromanaging, and adding risk Simple Techniques Domain Workshop Technical Architecture Workshop Release Planning Iterative/Time Box development There is this sweet spot term we use in engineering. It means that you have looked at many aspects of the overall goals, the various solutions, and have weighed the pros and cons of each to determine the best approach for the given constraints. Imagine passenger aircraft design if I want to carry more people, I make the plane bigger. If I want to make the plane fly at supersonic speeds, I make the (vertical) cross-section as small as possible. If I want to fly half-way around the world non-stop, I have to be very fuel efficient and carry enough fuel Engineers know the value of doing trade-offs, the same is true of doing software. Therefore, I present some ways in which you can approach doing software projects. The intention is to arm you with just enough of a foundation such that your project is more likely to succeed than not (far be it for me to challenge the ability for some teams to fail regardless of how hard they might try). By describing the foundation, the reasons behind it, and the resultant use of the various artifacts, you will see how my simple project management techniques can come into play Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 16

17 Right-click, choose "Hyperlink To" menu, select the hyperlink watch what happens. Cashier Debit Point of Sale System Scan Product or "Identify" Pro Total Item Product System Take in Payment Update Product Count Please refer to Doug Rosenberg's book on "Use Case Driven Object Modeling with UM for more information on Robustness Diagr Credit Check Cashier makes a sale Price Lookup <<include>> lnksaledm SaleDM <<moment-interval>> (The <<include>> database) Determine Tax Inventory Syste <<ui-component>> Client:PC DBMS:Solid Browser (IE) Legacy Cobol, IMS, etc. Request Response EJBContainer:JBoss EntityEJB:BudgetCente (optional) WebContainer:Tomcat ControllerServle :ControllerServl ttt View(JSP) BusinessInterfac BusinessDelegate SessionEJB ActionServle...ControllerServl If both container are on one server (e.g., WebLogic), better performanc can be achieved. Three Keys to Software Dev Success! #1 User Interface Business/Problem Domain Persistence DB DB DB Legacy/Ext. Systems Separation of Concerns Test Deploy/Run Analysis Agile Synergy Design Code Application Arch. Agile #3 Development POSFrame The std cashier U CashSale The entity #2 Dual Architecture Technical Arch. Construction Guidelines Working App! There are Three simple best-practices that can help you meet your challenges: Separation of Concerns, Dual Architecture/Construction Consistency, Agile Development. These principles, when applied, yield such advantages as: Improved time to market Apps that hit their target the first time Greater business agility Reduced maintenance On time and under budget delivery Quality architecture These are the core principles embraced by and embodied in OptimalJ. Anecdotal Aside: It is rare to find a problem in an existing application/development project that can t be traced back to having not followed one of these three keys Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 17

18 SDLC Development Overview Inception Develop Deploy Maintain Sunset Determine the feature set, domain model, technical approach to make an estimate Create release plan for next version + general roadmap Develop iteratively Continuously visible progress Just to put forth a common look at a typical application s life cycle The point here is that there is usually some sort of Inception phase where folks decide to do a development project and have to think about ballpark estimates, feature sets, driving vision behind the application idea, etc. These efforts can be smushed into the front of the Development phase but it is not the point to manage the macro-process here. Similarly, within development, there are multiple trial deploys to ensure the app is being built properly Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 18

19 Inception Process Upfront Practices Provide the basis for reqts and development Allow for estimations Get you started on the right foot Can also do this as part of initial Development Do to enough depth to get a good enough estimate Do spikes/pocs if needed Domain Workshop Requirements Architecture Release Plan Technical Workshop What you call it is not nearly as important as doing it! The point here is to gather enough requirements to make an appropriate start at the project. This includes being able to estimate, have an idea of what the first release will look like, and to know how you will be building the application. Your major goal: flatten or at least identify the risks in the project. For example, you may identify a technical architecture risk, or a complex business requirement feel free to call for more exploration (a spike or a POC ) such that you can improve the likelihood that your estimates are accurate Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 19

20 Domain Workshop - Purpose It is critical to set the tone and direction for the project from the business/problem domain perspective. Derive a set of features to help paint the picture of what this product has to accomplish Solidify the vocabulary of the project Create classes in the domain model Enable derivation of estimates for scope, cost, and schedule Enable an efficient development phase Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 20

21 Domain Workshop Artifacts Business definition, problem statement, vision document Feature set, roughly prioritized Domain model (initial cut) Technical architecture drivers Addresses non-functional project aspects (e.g., performance, security, availability, maintainability, quality, life expectancy of app) Allows you to understand how development will occur Estimate of development schedule and budget Cost / benefit analysis (by the stakeholders/business) Naturally, the artifacts will vary to suit the nature of the project, the culture of the company, etc Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 21

22 Technical Workshop - Purpose Define and resolve any risks for the non-functional requirements; for example: Performance, security, availability, maintainability, quality, life expectancy Define architecture to enable accurate work estimates Prove architecture meets the needs of the project Discuss/set-up the reference architecture, build process, environments to enable team to begin Development and QA Test/performance benchmarks Production Determine integration/external touchpoints Can be in parallel with Domain Workshop Sometimes the app you are building is just another one of the same genre. In such a case, this step is less about determining a suitable architecture and more about simply ensuring you have everything in place to enable the team to hit the ground running. When you have a very unique and demanding set of non-functional drivers, this workshop/project becomes crucial. You simply cannot begin to allow development to occur without ensuring you have explored an architectural solution and have built a reference implementation to prove it out. Once you have the architecture, the masses can now begin to do iterative development in a consistent manner (for each feature), following your architectural guidelines Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 22

23 Technical Workshop - Artifacts Working application (thin slice) to demonstrate arch. Or, enough small pieces of architecture proven out such that the next step could be to finalize the initial architecture Typically documents like: Architecture vision Things we chose not to do (and why) Object models Sequence diagrams Deployment diagram Performance test results to prove goals are met 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 23

24 Where Are We? We have a domain model We understand the architectural approach We have a rough list of prioritized features We have uncovered risks and accounted for them or dug deeper until we could We have a feel for the effort needed to build the app (not just development, but integration, testing rigor, deployment complexities, database loads, etc.) We are now ready to generate an estimate for the first version of the application! 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 24

25 Release Planning Purpose Discuss/determine project estimates At a high level, define the must haves and high priority items/features to make a release (Re)Prioritize the features Determine a realistic 1 st -pass product roadmap Evaluate the need for a technical spike or a feature exploration spike to reduce risk Consider issues like integration with other systems, deployment, rigor required for quality assurance GOAL: Arrive at a schedule, resource, and cost estimate Given the list of roughly prioritized features from the Domain Workshop, take another pass and determine what will constitute a release. Typically, this should be the minimal set of features needed such that the delivered application can begin to provide the stakeholders/users with some business value Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 25

26 Release Planning An Iterative Process Run through the prioritized list of features Estimate the total cost (time for dev, test, deploy) Indicate confidence level (H/M/L) to act as a multiplier on estimate (1,2,3; 1,3,9) Negotiate on features and priorities based on Cost of the feature based on possible variations Logical groupings based on construction efficiencies [optional] Additional separately-priced explorations into the details of the features For complex, poorly understood high-value features For technically challenging features Determining the schedule estimates is best done on an iterative basis of course, pretty hard if you are creating a fixed bid for an RFP and can t speak with the stakeholders or users. Just because a client asks for a feature doesn t necessarily mean that it has to be blindly answered. Sometimes you need to help the client ask for the right things to solve their true business needs. Also, it is the development team s responsibility to not only give a feel for the price of a feature but to also offer up some alternatives. That is, variations on a theme especially when the feature is costly and there could be some subtle changes to the feature that result in significant reduction in cost and time. If you have a need to do some initial phases of the project aimed at reducing risk and accelerating a good solution, then you can break the project up into phases and separately estimate each. NOTE: you will also reserve the right to refine the subsequent phase estimates this is the whole point. You want to explore, reduce risk, and re-estimate the following phase(s). This is similar to continuous re-estimating as you actually build the product via each iteration Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 26

27 Release Planning - Artifacts Overall Roadmap with Release 1 in enough detail to drive the initial development iterations Release Plan Feature List in the order of highest to lowest priority Rough Iteration plan at least for the first few Integration plan with other systems Rough Acceptance Test Plan if needed Deployment Plan Budget Estimates Schedule/Timeline & Resource Estimates Tailor the plan(s) to address/estimate known efforts Create a project plan as required! The artifacts of the planning process should meet the needs of your culture, stakeholder, and development team. The project plan if you need one should have traditional milestones for releases and iterations, plus non-feature-related development tasks, integration with other projects or teams, and so on Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 27

28 The Iron Triangle of Development Client Can specify any 2 of the 3 Cannot specify all 3 Development team dictates cost of a feature (time and resources) Management cannot at once: Dictate features, Fix the number of resources, and Dictate a completion date Planning is a group effort Goal is to be as honest as possible with the plan Scope Resources Schedule During the planning process, it is critical to note that software development is a team effort. The management cannot dictate how much and when the team will produce the features. Similarly, the team cannot dictate the feature order, or blindly allow the client or manager to not understand trade-offs and costs Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 28

29 Where Are We? Now we have our release plan! We have our domain model Good foundation for coding Reference/working example of architecture Automated build scripts Next we need to start! Iteration #1 is a good place! 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 29

30 The Feature List A simple, linear list, prioritized, controlled by client Work from the top down each iteration 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 30

31 Iteration Purpose Each iteration builds a discrete set of features Defines the when for delivery of features One or two weeks long (malleable) Delivers working features to the build / QA Demonstrates tangible progress Gets early feedback from client / Product Mgt Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 31

32 Development Tasks to Plan & Track Feature Client-valued Can be enhanced, changed, potentially removed Precisely-defined to know when you are done Can be scheduled, assigned and estimated Can be used as Marketing bullets Task Piece of work to be done, usually once Can be scheduled, assigned and estimated Defect Some sort of error Is related to/against a feature Can be scheduled, assigned and estimated 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 32

33 Development Process An Iteration A rough overview Plan an iteration From top of prioritized feature list/bugs Choose only as much as you can build Implement Code & QA Tests Works? Pass tests local, check it in Pass tests on build machine Close the issue! Iteration Planning Select Features & Defects Implement No For Each Feature Pass? Yes Review Reqts & Estimates Write UA Tests Deploy 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 33

34 Risk Management Much of what we do is all about managing risks: Requirements being incorrect Code not working properly Delivering late Deployment / integration issues Agile as a state of mind is also all about managing risk 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 36

35 Always Meet Budget and Schedule! Use a technique known as Time Box Agree to a list of features, more or less, A timeframe A budget Client understands that features lower on the list might get bumped, or they may be able to add features The point is simple: the flexibility is in the feature set, not the date or the cost Slip features, not dates! Need something unforeseen? No problem, add it in. But take something out! 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 37

36 CompuwareCorporation Conclusions 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 38

37 Habits of Successful Projects Embrace and empower quality people Do enough up-front modeling and architecture to create defensible estimate Employ an iterative process with stakeholder involvement Use tools to automate tasks: req ts., codegen, daily builds (continuous integration), gathering metrics, and QA Measure demonstrable features via working code Always use an agile state of mind Recognize what you don t know, mitigate risks, collapse timeframes, continually question and improve! Slip features, not dates 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 39

38 CompuwareCorporation Collaborative Workspace Improve Communication Bandwidth 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 40

39 Project Communications Collaboration is key to success We use the following tools/techniques Project Wiki Jira Issue/Task/Release/Iteration Tracker IRC - Group collaboration Chat Room with a scribe ;=) 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 41

40 Project Wiki One stop shop for the project A home for those things related to the project that you want to preserve Especially non-issue/task/defect items like architectural decisions and other useful artifacts Team adds/deletes/edits web pages and content to suit their needs Low cost way to have everyone on the same page literally ;=) 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 42

41 Project Status Talk Makes it easy for people to document progress Any text, files, references, images Etc 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 43

42 Feature/Task Roadmap Project status at a glance Simplifies release management 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 44

43 Project Issues One stop for issue information Details Comments & Discussion Dependencies Attachments Work log Resolution History 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 45

44 Project Chat Room Allows multiple people to chat at once about development issues, features, etc. Text is recorded for later use as needed IRC log is available on Wiki 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 46

45 CompuwareCorporation Great! So how do we start? What does an agile MDA project look like? 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 47

46 How it Works in Practice Relative Participation By Task Design the technical architecture Create Technical Architecture (Or re-use existing) Model the Business (Appl. Architecture) Work out breadth of application s features Each Iteration/Release Work out N# of features to be delivered. Work out Appl. Details (Coding, UI, Integration) Continuous Integration and Testing Conduct verification of high-risk issues (as often as needed) Development Cycle Duration / Time Steeltrace, OptimalJ, DevPartner, QA Center, Vantage, Typical application life cycle might look like this. Technical Architecture. An application must have a technical architecture upon which features are delivered. This could be in parallel with initial application modeling, or be done prior to the application s start (serial). In general, you might build many applications with the same technical architecture. Or, if you have software as a product, you usually stick with a given architecture for a year or two of releases. OptimalJ provides an initial technical architecture out of the box. Business Model To properly build an application to meet the company s current and (more importantly) future needs, it must be architected around the specific Problem Domain. To ensure the application development is off to a good start, the breadth of the application should be modeled in terms of the business. Sometimes this is based on a set of predefined requirements (features). Other times, the act of modeling is effectively used to elicit the features. This helps to shape the size and direction of the application architecture, plus it generally provides a glimpse into the overall ultimate scope even if you are just implementing a small slice in the current project. OptimalJ provides the required focus on modeling the business aspects of the application. Iterative Development Once the breadth of the application is modeled, and a great features list is available (and prioritized), the top features (and/or riskiest) can be implemented in the first iteration. For each iteration, the domain model may be revisited and more specific details added. Application Details Iteratively Beyond the additions to the business model, the application details might involve some rough user interface design, database modeling, integration with other systems, and other necessities to get to a working application. Often, methods may need to be written, and other dynamic behavior addressed. OptimalJ makes it easy to focus in on specific feature areas of the application via the focus on the domain model. Continuous Integration & Testing To improve the quality of the application, it is critical to be able to always produce running code. Most successful teams have daily build procedures, some even more than one build per day! The idea is to always strive to have running software and automated tests to help find errors early in the process. At the end of each iteration, a complete, working application is the deliverable, with the chosen features implemented. OptimalJ provides such an environment within which to conduct iterative development Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 48

47 Continuous Integrated Testing Test early, Test often Test via Automation, Test With Confidence! Three Components to the Process Collection Analysis Remediation Increased number of test cycles per project Low Resource Overhead Tests are fully automated and can be run unattended, offering minimal distraction to Developers. Test Cases Go Live? Planning Iterative Development Formal QA Production Continuous Integrated Testing Compuware s Continuous Integrated Testing solution brings together two areas of testing into one process that is more efficient and allows more testing to be performed more quickly and more accurately and detect coding mistakes and coding logic much earlier than before. The two areas are line-of-code root cause analysis (extended debugging of code) and automated testing of software components. Line-of-code root cause analysis is where a developer profiles their code with Compuware s developer productivity tools. This enables the code to be assessed for memory leaks, poorly designed code, code coverage, poor performing code, and even security vulnerabilities. Automated testing of software is the ability to capture manual testing efforts into a re-usable and repeatable script that can be executed whenever needed. Pulling these two areas together into one solution allows not only testing to be automated, but if a defect is found the ability to trace that defect to the exact line of code that needs to be modified to correct the defect. Also, Compuware s automated testing solution can uniquely offer the ability to test code components without the need for a GUI front-end to call the component. With application components typically being developed first in a software project, and the application GUI front-end being developed later, this unique technology means that automated 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 49 testing can begin much early than has ever been possible.

48 Wrap-up: 3 Keys to S/W Development Separation of Concerns Construction Consistency/Dual Architecture Agile Development Environment What will you do on your next project? Remember, it s all about the business! Think about how your team gets software built Do you have a notion of the Problem Domain Model, clearly separated from the UI or persistence layers? Do you attempt to lay down some guidelines for how developers should produce code in specific instances? Do you demonstrate progress through running software? There are Three simple best-practices that can help you meet your challenges. We ll cover these in the next slides. These principles, when applied, yield such advantages as: Quality architecture Improved time to market Apps that hit their target Greater business agility Reduced maintenance On time and under budget delivery 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 50

49 Thank You! People and software for business applications sm 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 51