Agile Project Management

Agile Software Project Management Sep 2006

http://www.compuware.com/blogs/jkern/

© 2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 1

CompuwareCorporation

Agile Project Managementor…

How to Be on Time and Within Budget!(Really!)

V1.1

Jon Kern

Agile / MDA Evangelist

Compuware

USA

[email protected]

http://www.compuware.com/blogs/jkern/Newsletter: http://frontline.compuware.com/javacentral/straight-talk/default.asp





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 ‘03





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





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?





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





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)





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.





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.





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

� Deliver business valuefaster and continuously

� Running Software: Necessary – but not sufficient!

� Quality & -ilities from the start

ANALYSIS

DESIGN

CODETEST

DEPLOY

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.





Agile Manifesto

� Individuals and Interactions

� Working software

� Customer collaboration

� Responding to change

� 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

http://agilemanifesto.org

over…

over…

over…

over…

You can read more about these principles at: www.www.www.www.AgileManifestoAgileManifestoAgileManifestoAgileManifesto.org.org.org.org





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 activityevery activityevery activityevery activity that the team was doing (for

example, building features) into the project plan.

In most traditional 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 the power and familiarity of 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, no detailed resource allocation needed, no interdependencies

necessary in Gantt. A simple list… no dependencies, nothing complicated. Items

on the list that don’t get done this iteration can slip to the next. No need to

change the project plan, however.





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 micro-

tasks 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.





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.





Analysis

Test Design

Code Deploy/Run

AgileAgile

Development

#3

Three Keys to Software Dev Success!

#2

Point of Sale System Product System

Cashier

Inventory System

Scan Productor "Identify" Product

Total Items

Take in Payment

Credit

Check

Debit

Price Lookup

Determine Tax

Update Product Count

<<include>>

<<include>>

Right-click, choose "Hyperlink To" menu, select the hyperlink and watch what happens.

<<moment-interval>>CashSaleThe entity

<<ui-component>>POSFrame

The std cashier UICashier

SaleDM(The database)

makes a sale

lnkSaleDM

Please refer to Doug Rosenberg's book on "Use Case Driven Object Modeling with UML"for more information on Robustness Diagrams.

Application Arch. Technical Arch.ActionServlet

...ControllerServlet...ControllerServlet...ControllerServlet...ControllerServlet

EJBContainer:JBoss

EntityEJB:BudgetCenter(optional)

SessionEJB

LegacyCobol,IMS, etc.

Request

Response

Client:PC

Browser(IE)

DBMS:Solid

WebContainer:Tomcat

ControllerServletControllerServletControllerServletControllerServlet:ControllerServle:ControllerServle:ControllerServle:ControllerServletttt

View(JSP)View(JSP)View(JSP)View(JSP)

BusinessInterface

BusinessDelegate If both containersare on one server(e.g., WebLogic),better performancecan be achieved.

Working App!

Dual Architecture

Construction Guidelines

Separation of Concerns

#1

User Interface

Business/Problem DomainBusiness/Problem Domain

PersistencePersistence

DBDB DB

Legacy/Ext. SystemsLegacy/Ext. Systems

SynergySynergy

There are Three simpleThree simpleThree simpleThree 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.





SDLC–Development Overview• Determine the feature set, domain model, technical approach to make an estimate

• Create release plan for next version + general roadmap

Inception

Develop

Deploy

Maintain

Sunset

• 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.





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 geta “good enough” estimate

� Do spikes/POCs if needed

DomainWorkshop

TechnicalWorkshop

• Requirements• Architecture• Release Plan

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.





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 whatthis 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.





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.





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 cannotcannotcannotcannot 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.





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





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!





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 1st-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.





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.





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.





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

Sco

pe

Schedule

Resources

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.





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!





The Feature List

� A simple linear list of requirements

� Prioritized, controlled by client’s needs– Can easily change over time

� Work from the top down each iteration

Rel

ease Ite

ratio

n





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.





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


� Defect– Some sort of error

– Is related to/against a feature






Iteration Planning

Development Process – An Iteration

� A rough overview

� Plan an iteration– From top of prioritized

feature list/bugs

– Choose only as muchas you can build

� Implement– Code & QA Tests

� Works?– Pass tests local, check it in

– Pass tests on build machine…

– Close the issue!

Deploy

ForEach Feature

Write UA Tests

Review Reqts& Estimates

Select Features &Defects

Implement

Pass ?No

Yes





Conclusions





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





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





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!





Great! So how do we start?

What does an agile MDA project look like?





How it Works in PracticeR

elat

ive

Par

tici

pat

ion

By T

ask

Development Cycle Duration / Time

Model the Business (Appl. Architecture)

Create Technical Architecture(Or re-use existing)

Work out Appl. Details (Coding, UI, Integration)

Continuous Integration and Testing

Design the technical

architecture

Each Iteration/ReleaseWork out ‘N#’ of features to be delivered.

Work out breadth of application’s features

Conduct verification of high-risk issues

(as often as needed) OptimalTrace, OptimalJ, DevPartner, QA Center, Vantage,…OptimalTrace, OptimalJ, DevPartner, QA Center, Vantage,…

Typical application life cycle might look like this.

Technical Architecture.Technical Architecture.Technical Architecture.Technical Architecture.

An application must have a technical architecture upon which features are delivered. This could be in parallelparallelparallelparallel 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 ModelBusiness ModelBusiness ModelBusiness 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 pre-

defined 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 DevelopmentIterative DevelopmentIterative DevelopmentIterative 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 Application Details Application Details Application Details –––– IterativelyIterativelyIterativelyIteratively

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 & TestingContinuous Integration & TestingContinuous Integration & TestingContinuous 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.





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.

Planning Iterative Development Formal QA Production

Go Live ?

Continuous Integrated Testing

Test Cases

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

testing can begin much early than has ever been possible.





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 simpleThree simpleThree simpleThree 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





People and software for business applicationssm

Thank [email protected]

Agile Project Management

Documents

Transcript of Agile Project Management