We have been asked by Professor Penny to deliver a completed program and associated documentation that helps his organization plan releases of their software products.
The current document comprises a business analysis of that part of the release planning domain of Professor Penny’s software company pertinent to the requested work. Its purpose is to capture and represent this domain to ensure that we are not misunderstanding it. We will walk through the results of the analysis with Prof. Penny for his approval before beginning the software design phase. This clear understanding of the problem domain will help ensure that the delivered product fulfills the requirements of Prof. Penny’s organization, and will provide a foundation for future design work.
The majority of the analysis comes from a written problem statement (see asgn1.html) provided by Professor Penny, supplemented by his answers to questions on the CSC407 course newsgroup, in class, and during office hours.
Prof. Penny has raised the possibility that related systems or extended replacement systems may be required in the future. To accommodate this possibility, we will follow the tenets of XP (eXtreme Programming) and not over-analyze or over-design the initial solution. Rather, we will do a good job of capturing the basic problem in our analysis, anticipate the most obvious modification requests in our subsequent design, and write re-usable code. In this manner, extensions, certain changes in architecture, and the extension of the solution to related domains will be relatively straightforward and can reuse most of what we do here.
Prof. Penny’s organization currently uses an XML file that
contains the base data for the requested application. We consider this to be an
architectural constraint placed upon the initial solution. We will analyze,
architect, and design in such a way that this data source can be replaced by
another (such as a relational database) in a straightforward manner in the
future, however we will reflect the current constraints imposed by this XML
file in the analysis that follows.
The above diagram enumerates some of the potential uses cases in the domain. Currently, all uses cases are implemented by manually editing or viewing a raw XML file using a text editor.
External customers or our internal employees request features against a certain software product. They communicate the request to the product manager for the product, who checks to see if a similar feature exists and if so adds the requestor, or records a new feature request. If it’s a customer requesting the feature, a desirability by that customer is added as well.
The product manager may subsequently edit the feature by adding or changing the description, assigning an internal champion for the feature, or prioritizing a feature. Developers come along and size each feature.
At a certain point in time a product manager will want to plan a subsequent release of the software. As a starting point, the product manager will use the proposed system (Release Planning Program) to come up with a suggested starting point. The Product manager will consult the suggested plan (together with a list of features that just missed being in the suggested plan) to produce a tentative plan for a release.
To get a suggested release, the product manager will supply a resource availability. The system will produce a list of the highest priority features that just fit within the resource availability. In cases of priority ties features more favored by customers will win (based on a numeric average of the feature desirability across customers, or 0 if no customer is recorded as desiring the feature). If possible, the system will descend to lower priority and/or less customer desired features in order to fill any remaining gap between the sums of the in-plan feature sizings and the available resourcing.
Further details on the desired output format may be found in
the initial requirements statement provided by Prof. Penny.
The (singleton) company develops multiple software products. A software product is uniquely identified by its name. A software product has potentially many releases. Features (really feature requests at this point in time) apply to a given software product.
A release means a potential release being put together for planning purposes. For this reason, it is possible that a feature be associated with zero to many (alternative) planned releases. Eventually, it is expected that a feature will be put off to a future release, discarded outright, or assigned to one (but no more than one) actual release for implementation. If the implementation of a feature will be staged into multiple releases, we assume that distinct features will be created.
Note the constraint that a feature may only be in-plan for a release of the software product to which it applies.
A feature is commonly referred to within the company by a numerical id. A feature also has a short description, generally a phrase or a short sentence, and a long description approximately a paragraph in length.
In cases where a single features refers to multiple
products, it has been the practice of the organization to specify this as multiple
features with a common short description. For purposes of simplicity, we shall
not model this at this time.
A feature is championed within the company by potentially any employee. The champion is the employee designated to know all about the feature. The champion is the point person the company goes to if they have any questions about the feature. Each feature is championed by some employee, and may have at most one champion.
Developers provide a sizing for each feature in person days. The developer may talk to others in arriving at the sizing, however one developer is designated the point person for the sizing. If any questions arrive over the sizing, the company will ask that developer.
A product manager decides upon a priority for each feature, balancing customer considerations and market considerations. There is one product manager who is the go-to person for questions about the priority.
After a feature is first entered into the system, there may be a period of time during which no sizing is available, no champion has been identified, and no sizing is available, hence the 0..1 multiplicities.
Note that the XML file does not name the developer or
product manager who supplies the sizing and prioritization, but does specify
the name of the champion.
Customers make requests for new features. Note that the requirements statement says that only outside customers are recorded in the XML file as desiring a feature. It is our understanding that in cases where the feature is requested by an employee, no customer is listed (hence the 0 in the 0..* multiplicity) and the requestor is the same as the champion for a feature (see section Employees)
Customers supply a desirability for the feature ranging from 1 (low) to 10 (highly desirable).