SCM ProjectGabriel CristescuGabriel_cristescu@ditech.roDi.Tech Ro, www.ditech.ro

08.05.2010

Di.Tech GroupCONAD ADRIATICO

CONAD PAC 2000ACEDI MARCHE

FINPART

Di.Tech SPA

SBS EUROPE(ROMANIA)

Di.Tech RO(ROMANIA)

60,57% 14,16% 19,14% 4,01% 2,12%

99,00% 100%

CONSOF(ITALIA)

60%

1%

NORDICONAD

The role of the various companies

Ditech Italy, with more than 200 employees, offers since 1989 consultancy services and software products on the Italian retail market.

Ditech ro is an independent software factory founded in 2004 oriented on the European market having about 100 a highly skilled technology resources in .NET and Java

SBS Europe offers help desk and telemarketing services for sofware area for the European market.

CONSOF is SAP Business Partner that offers solutions and consultancy for production companies in Northern Italy.

Di.Tech Ro MissionOur goal is to be an European center of excellence in designing and developing computer software solutions

with well trained professionals, to ensure long-term

high quality standards having in the same time a strong orientation

towards innovative solutions.

Our goal is to be an European center of excellence in designing and developing computer software solutions

with well trained professionals, to ensure long-term

high quality standards having in the same time a strong orientation

towards innovative solutions.

Our Clients

BUSINESS ONE

Agenda Focus on SCM – project for Di.Tech Italy From concept to product

SCM – Fidelity System concepts SCM – overall architecture SCM – project phases SCM – final product

Production – “The ugly truth”

SCM- Fidelity System Concepts

The client purchase the products

Vendor assign a fidelity card

The cost of products is transformed in points

The client spends points for special offers

The client transforms points in cash

SCM – overall architectureSCM – Consumer Operation

DATUM Promo Manager

SCM-CasseOnLine

MORE

MORE - ERP

Client

Hiper1

DATUM Agent

POS

Sales

Client

Hiper2

DATUM Agent

POS

Sales

Oracle DbCasseServer Fidelity Server

DATUMServer

Promo Server

Product Phases

• Phase 1• Concept design

Planning

• Phase 2• Client Interaction

Prototype • Phase 5• Version Beta 2• Testing and bug fixing• Release Candidate 1 (RC1)

Release Testing

30% Developers

50%

Testers

10% Proje

ct Manageme

nt

10% Clien

t Interaction

100%

Success

Phase #1 - Planning Planning Phase

Client expresses product requirements. Senior leadership provide an initial vision. Product team creates a vision statement elaborated on product. Product team creates an overall schedule. Product team begin a detailed planning of what features would

get into the release. Premise:

• Received analysis for project modules and controls• Received initial family look control set

Development:• First version of DiTech Ro Framework, interfaces and base classes • First version of server

Product Team: 8 developersDec 06

Jan 07

Feb 07

SCM – Family Look Contains guide lines for:

Simple components Complex components Modules flow Layout and transitions Color schemes Functional Keys User alerts

Phase #1 - Planning

Di.Tech Framework

Controls Components

Base Classes

InfrastructureMultilanguage

Layout

Validation

OPLib

Instrumentation

Proxy

Factory

Phase #1 - Planningprinciple #1 – active user involvement is imperative Which states that:• Responsibility is shared; the team

is responsible together for delivery of the product

• Requirements can be clarified on a daily basis with the entire project team, rather than resorting to lengthy documents that aren't read or are misunderstood

• Emerging requirements can be factored into the development schedule as appropriate with project decisions clearly understood

Phase #2 - Prototype Prototype

Emulates a few aspects of product features It is used by clients to evaluate the product design The client feedback is crucial in this design phase Allows an appropriate deadlines estimation and proposed

milestones Premises:

• Create an “vertical” prototype• Adjustment with the client of product "family look”

Development:• All infrastructure systems are implemented• First modules of client are implemented• XML web services are implemented

Product Team: 8 developers Prototype

Jun 07

May 07

Mar 07

SCM – Prototype - Family look The “look” of

application

Phase #2 - Prototype principle #2 – agile teams must be empowered Which states that: The project team must be

empowered to make decisions in order to ensure that it is their responsibility to deliver the product and that they have complete ownership.

The team must establish and clarify the requirements together, prioritise them together, agree to the tasks required to deliver them together, and estimate the effort involved together.

Phase #3 – Release 1 Design aspects

The feature-set is driven by Product ManagersOwn the client interaction and making the right thing happenDrive the product unit team during the design processOwn writing a design specification for each feature

Coding C# is the language used. The goal is efficient, clean, and maintainable code.

Code we ship has guaranteed support Team Foundation Server 2005 is used to organize developers activity

Source control system optimized for branching/mergingTasks, Bugs system integratedWeb Collaboration

Premises:• Intensive collaboration with DiTech Italia• Intensive collaboration with client

Development:• 100% of product features implemented

Product Team: 5 developers

SepOctNov Dec

07

Aug 07

Jul 07

Phase #3 - Release1 - client features Multilanguage Validation

Standard validations: required, length, size, interval, regex Custom validations: barcode, valid when IValidable

Layout XML - driven ILayoutConsumer

Instrumentation log4Net Database WMI

Updater Hot-swap client modules – no need for client deploy

Phase #3 – Release1 – server features 5 XML Web Services

CRUD – using Enterprise Library Critical queries – IBatis Mass data insert – ODP.NET

Instrumentation Log4net Database WMI events

Utility Activity trace Quality File generators Security

Phase #3 – Release1 principle #4 – time waits for no man

• requirements emerge and evolve, and that however much analysis and design you do, this will always be the case because you cannot really know for sure what you want until you see and use the software

principle #5 – how do you eat an elephant?• One bite at a time! Likewise, modules are delivered in small bite-

sized pieces, delivering small, incremental *releases* and iterating principle #6 – fast but not so furious

• focus on frequent delivery of products, and regular iterations

Phase #4 – Release2 Producing Daily Builds

A new “build” is built and released every day.Forces engineering discipline, critical in the end-productBuild number indicates build date (80730: Jul. 30 2008)

Build lab produces daily builds for Q&A division Testing

Test team is staffed by Devs Designs test plans, writes tests, and builds infrastructure

Target goal with tests is to reach >70% product code coverage by end of the product cycle

We measure this statistic throughout the product “Test Complete” – Test automation system

Premises:• Obtain a consolidated product

Development:• Bugs triaged by feature leads and assigned priority

• Product Team: 3 Developers

Jan 08

Feb 08

Mar 08

Apr 08

Phase #4 – Release2 We found that we like this

principles: principle #7 – done

means DONE!• The feature may rely on other

features being completed before the product could really be shipped. But the feature on its own merit should be shippable. So if you're ever unsure if a feature is 'done enough', ask one simple question: "Is this feature ready to be shipped?".

principle #8 – enough’s enough• Pareto's law is more commonly

known as the 80/20 rule. This means that *typically* 80% of your results may actually come from only 20% of your efforts!

Phase #5 – Release consolidation BUG Tracking

Bugs & work-items are tracked within TFSEnables rich reporting and change history tracking

Bugs triaged by feature leads and assigned priorityBugs fixed in priority order of range from Critical to Enhancement

Daily status mails sent to developing team tracking bug status Release

Key set of steps along the “release path”Lock feature-set and stop adding/changing designRun a full test pass to find all bugs of the locked design.Push for a zero bug situation on the locked design.Triage all bugs out of the system that are not “must fix”.Enter End-Product mode & start minimizing code re-factor.

Premises:• Needs to be done until Sep 08• Needs an intensive collaboration with headquarter

Development actions:• All modules are closed

• Team: 3 developers

Sep 08

May 08

Jun 08

Jul 08 Aug

08

Phase #5 – Release consolidation principle #9 – agile testing is not optional

• Developers are much more heavily engaged in testing, writing automated repeatable unit tests to validate their code.

• But testing shouldn't only be done by developers throughout the development. There is still a very important role for professional testers.

Phase #6 – Release installation End-Product mode

“Release Team” takes over to the End-Product mode. Made up of most senior team members that meets at least once a day.

Over the span of the final weeks before a release Release team steadily raise the triage bar, and towards the end only

allow critical bugs to be fixed. If product is ready to ship, the number of critical bugs will slowly decline.

Client Connections The Client need to be part of our development.

We have broke the pattern that let us think that “we know what’s best”. Four areas of focus:

Video-conference Client headquarters meetings Product Previews for Client Technical Assistance Department

Complete product

Dec 08

Nov 08

Oct 08

Phase #6 – Release installationprinciple #10 – no place for snipers We are not seeking for guiltiness we want only that the project

team is working towards a shared goal, creating better teamwork, fostering team spirit, and building stronger, more cooperative relationships.

RTM – complete product Hard decisions

The Golden Rule Features + Quality = Time

You can only control two from these three! Which one is winning?

Development focus on Features. Q&A department focus on Quality Management focus on Time

Front Loading Quality Maintain a very high quality standard No feature work items are included until they are completely

passing tests; there is always next release

RTM - installation ClickOnce installation Wix Mage, PSTools, vbscript

Production – the “ugly” truth 1. The management of application in production must be proactive not

reactive. Save time and money invested in preparing the deployment. Do not expect the application to enter the error and to hurry to fix it.

2. Create a structured plan for installation and patch management. Document all the elements to be installed to ensure the repeatability of process and to reproduce problems.

3. Do not ignore the importance of post-installation testing action. Avoid the common practice “test application by opening and performing a 2 -3 clicks”.

4. Check twice the installation parameters! Each organization has its own business process, with its rules, not break them!

5. Do not introduce new technology or new ways of working until you have looked very good at the infrastructure!

6. Avoid fixing a issue and generating other! The client lose their trust. 7. If there is a problem in production you have to solve it first and then

investigate the causes! 8. Continuously monitor, do not let the customer to find any problems. 9. If the client has found a production problem, fix it and then send a detailed

report of the incident and actions to take. 10. Warn customers before any “on the fly” changes however minor it may be.

Remember: Factors that impact any successful project

Technology

Process

People Invest in your future by improving your work methodology so it doesn`t come to:

* perle BAC 2009 – 2010 Citind, se mai dezvolta si omul la creier si acumuleaza materie prima.

Thank you!Questions?