Estimation techniques - estimation using use cases

We have read about estimation techniques like problem and process based estimation techniques. There is another estimation approach that uses use cases which provide insight into software scope and requirements. However, it is somewhat difficult to develop an estimation technique using use cases.

- There is no standard format or style in which use cases can be described because there are many different formats and styles that a use case can use.
- The complexity of the functions are not addressed by the use cases.
- Complex behavior like interactions among many functions and features are not described by the use cases.
- Use cases are used to represent the user's view of the software.

Use case estimation technique for one person can require a lot of effort while use case estimation technique for some other person can be done in a day or two. According to Smith, use cases can be used for estimation but it is only possible and considered within the context of structural hierarchy that the use case describe.

- structural hierarchy can have not more than 10 use cases.
- each use case can have not more than 30 different scenarios.
- before using use case estimation, level within structural hierarchy is established, average length of each use case is computed, type of software is defined, rough architecture is considered.
- empirical data is used to establish lines of code or function point for each level.

The System Engineering Hierarchy - System Modeling

Good system engineering begins with a clear understanding of context - the world view - and then progressively narrows focus until technical details are understood. System engineering encompasses a collection of top-down and bottom-up methods to navigate the hierarchy.
System engineering process begins with a world of view which is refined to focus more fully on a specific domain of interest. Within a specific domain, the need for targeted system elements is analyzed. Finally, the analysis, design, and construction of targeted system element is initiated. Broad context is established at the top of the hierarchy and at the bottom, detailed technical activities are conducted. It is important for a system engineer narrows the focus of work as one moves downward in the hierarchy.

System modeling is an important element of system engineering process. System engineering model accomplishes the following:
- define processes.
- represent behavior of the process.
- define both exogenous and endogenous input to model.
- represent all linkages.

Some restraining factors that are considered to construct a system model are:
- Assumptions that reduce number of possible permutations and variations thus enabling a model to reflect the problem in a reasonable manner.
- Simplifications that enable the model to be created in a timely manner.
- Limitations that help to bound the system.
- Constraints that will guide the manner in which the model is created and the approach taken when the model is implemented.
- Preferences that indicate the preferred architecture for all data, functions , and technology.
The resultant system model may call for a completely automated or semi automated or a non automated solution.

System Modeling - The Hatley Pirbhai Modeling

System models are hierarchical or layered as a system is represented at different levels of abstraction. The top level of hierarchy presents the complete system. The data objects, functions, behaviors are represented. As the hierarchy is refined or layered, component level detail is modeled and finally system models evolve into engineering models.
Hatley-Pirbhay modeling is an extension of the concept that every computer system can be modeled through the usage of an input-processing-output model by including the two additional features of user interface process and maintenance/self testing. These five components are added to a system model template to allow for modeling of the system which allows for proper assignment to the processing regions.

THE HATLEY-PIRBHAI MODELING
- The Hatley-Pirbhai model depicts input processing, and output along with the user interface and maintenance or self-test.
- It includes two more system features: user interface processing and maintenance and self-test processing.
- A system engineer can create a model of system components that sets a foundation for later steps.
- The system engineer allocates system elements to each of five processing regions within the template: user interface, input, system function and control, output, maintenance and self-test.
- A system context diagram(SCD) resides at the top level of hierarchy which defines all external producers of information used by the system,all external consumers of information created by the system and all entities that communicate through interface or perform maintenance and self-test.
- All the major subsystems are defined in a system flow diagram (SFD) which is derived from SCD.
- Information flows across the regions of system context diagram is used to guide the system engineer in developing system flow diagram.
- System flow diagram shows major subsystems and important lines of information.

Interface Analysis - Task Analysis and Modeling

The goals of task analysis :

- what work will the user perform in specific circumstances?
The use case is developed to show how an end-user performs some specific work related task. The use case provides a basic description of one important task for the computer aided design systems. The software engineer extracts tasks, objects and overall flow of interaction.

- what tasks and sub tasks will be performed as the user does the work?
It is a mechanism for refining the tasks that are required for the software to accomplish some desired function. Task elaboration is quite useful, but it can also be dangerous. A human engineer must first define and classify tasks.One approach is stepwise elaboration. Each of these major tasks can be elaborated into subtasks. Design model should accommodate each of the task in a way that is consistent with user model and system perception.

- what specific problem domain objects will the user manipulate as work is performed?
The objects that are extracted from the information obtained from the user can be categorized into classes. Attributes of each class are defined, and an evaluation of the actions applied to each object gives a list of operations to designer. Although object elaboration is useful, it should not be used as a standalone approach.

- what is the sequence of work tasks-the workflow?
Workflow analysis allows a software engineer to understand how a work process is completed when several people and roles are involved. Work flow analysis is applied when a number of users, each playing different roles, makes use of a user interface, it is sometimes necessary to go beyond task analysis and object elaboration.

- what is the hierarchy of tasks?
Process of elaboration occurs once the interface is analyzed. Once workflow has been established, a task hierarchy can be defined for each user type. Hierarchy is derived by a stepwise elaboration of each task identified for the user.