DomainChangesAnalysis

Functional Description

Project Tasks need a (total) estimate and a todo estimate, for comparison with the time actually spend on a task. The tasks project members work on are part of quote tasks charged to the costumer. Quote tasks also have an estimate. NiceToHave: relation between quote task and implementation tasks

Options

There are 2 options for including the quote estimates in the report and comparing them to the time taken up by the actual tasks. One involves minimal changes the other a thorough adaptation of the domain model. Some changes are the same for both.

Inevitable changes regardless of domain model changes

Adding estimates to tasks involves at least:

• extending TaskDao to read and write estimates (or adding a new EstimateDao)
• extending the Manager
• adding 2 fields to Task
• change Project Page, add textfields for estimates
• add estimates to report: depending what type of report is requested, the ldap will be queried for task estimates.

Version 1: Minimal

Task gets another extra field for the quote estimate, making the distinction between implementation tasks and quote tasks based on the null values for fields. This is less invasive but it is a) a bit of a hack and b) grouping the implementation tasks that go with a particular quote task still has to be done by hand.

Version 2: Domain Model Rework

Short version: Project HAS Collection<quoteTask> HAS Collection<implementationTask>. Both Tasks have estimates but only the implementationTask has a TODO-estimate and can assigned to members. This solution has large implications for the entire application:

Domain Objects

• new object QuoteTask HAS-A Project, HAS-A Collection<ImplementationTask>, HAS-A estimate, name, description, uid
• Project no longer has Tasks but a collection of QuoteTasks
• Task changes to ImplementationTask, no longer has Project but a QuoteTask. Gets 2 new fields: totalEstimate and todoEstimate.

LDAP

Whichever option is picked, the ldap schema has to changed. The easiest may be to add 4 Optional Attributes to opsProjectTask: 3 for estimates (Or 2 estimates: "estimate" and "todo") and 1 for the QouteTask a ImplementationTasks. The dao differentiates between QouteTasks and ImplementationTasks based on which of these attributes have values. QouteTask? only has 1 estimate. ImplementationTasks have 2 estimates and a QouteTask.

Or we could take this opportunity to create new ObjectsClasses, OpsQouteTask and ImplementationTask, which would follow the structure of domain objects described above and would also have GUIDs.

Managers and Dao

The changes in the domain model result in changes in dao and manager methods:

• ProjectDao.createProject and ProjectDao.updateProject have to be adjusted
• all of TaskDao needs to be adapted, maybe split in ImplementationTaskDao and QuoteTaskDao * ImplementationTask can be moved from one QuoteTask to another

Frontend

• Projectpage reflects new structure with QuoteTasks and ImplementationTasks, and estimates for both.
• ImplementationTasks can be moved between QuoteTasks.

Issues

• Backward compatibility?
  • migrate all previous projects, requires an extra MigrationStory
  • keep Task domain object and all old manager and dao methods. Use both systems simultanously. Is this possible???
• Rollback when moving implementationTasks
• ...

-- IvanaCace - 04 Aug 2008