The Assumptions tab is where you view, enter, or edit the inputs to your estimates. It is the first tab shown when you create a new estimation project.
In SLIM-Collaborate, project estimates are based on one or more inputs (or assumptions):
•Size of the functionality to be built and delivered at the end of the project.
•Productivity expected from the team or required to deliver X features given:
o a specified amount of time (schedule) and
o resources (effort,
staff, or budget).
SLIM-Collaborate uses the same Software Equation as the SLIM-Estimate desktop application to calculate the most likely schedule and resources required to construct, test, and deliver the functionality implemented by the system being estimated. The relationships between the major software management metrics – size, time, effort, defects, and productivity (PI) – are built into the SLIM software equation and were derived from research using the data in the QSM database of 14,400+completed projects.
SLIM-Collaborate offers a variety of solution methods, each
of which is useful at different times in the lifecycle and requires different
inputs. As you select each solution method, the fields on the righthand side of
the Assumptions tab display the required inputs for the solution method chosen.
A brief description of each method is displayed in the label field below the
Method selection list:
•Trend Based. The Trend Based solution reflects average schedule and effort performance for projects of the same size from the project’s trend group. The Trend Based method calculates time and effort based on projects of similar size in the project’s associated trend group. PI is not used in this calculation.
•Design to Goal. The Design to Goal solution method creates a solution using your estimated system size and productivity, plus a single duration, effort, staff, or cost goal.
•Feasibility. The Feasibility solution method produces early ROM estimates using high-level size inputs and your desired schedule and staff/cost goals. Because performance (schedule and effort) assumptions are goal-based, these solutions should be validated against industry or your own performance data to ensure they are realistic and achievable. This method is used early in the requirements definition phase when detailed requirements are fuzzy, but schedule and budget targets are known.
•Time Boxed, Fixed Team. The Time Boxed, Fixed Team solution estimates how much functionality (size) can be delivered, given a specified schedule, effort/staff, and productivity. This method is often used for Agile development.