1.1 Activity-based Approach
An activity-based approach was taken to decompose the tasks; this is where we generated a list of activities to create a Work Breakdown Structure (Refer to Appendix C). The benefits of this is that it allowed us to break the stages into high level activities then further decomposed into lower level activities until the activities are decomposed into a manageable size. An example would be the design stage of TASS; this stage could be further broken down into different areas such as user interface design, report design and SQL design.
Breaking tasks into manageable components is very important as it allows milestones to be created, it lets us check that the system is working before the next task is performed, this would allow developers to identify problems during the early stages of development, where it would be easier to reverse. Diagnosing a problem that occurred during the early stages of development towards the end of project would delay the whole process of the project, as the steps must be reversed and reimplementation which requires money and time.
There are many advantages provided by this approach; including 100% task coverage and prevention of activities overlapping each other. It is important to cover all tasks within the project at the beginning of the project development, as it allows the project team to plan efficiently and helps prevent project failure due to unorganised planning. The prevention of overlapping activities is also vitally important as it allows efficient allocation of resources which could reduce cost and time of development.
1.2 Milestones
Milestones have been created during the decomposition of TASS such as the creation of specification documents at the end of each high level activity such as 2.1.4 Document System Requirements Specification and a review stage at the beginning of the stage as show in 3.1 Review specification of the design process.
Milestones are vitally important within a project, allowing stakeholders outside the project team to examine the output, diagnosing problems and provide feedback to help improve the system and ensure that the system created follows the proposed plan.
Part 2 Estimating
2.1 Introduction
The basic assumption of meeting the targets set for a project successfully is that the targets are reasonable. However, estimating the effort required to implement software is notoriously difficult due to many reasons, such as the inherent nature of software and intensively human activities.
For the TASS, the whole system has been divided into four subsystems. Each subsystem needs to be implemented through the analysis, design, coding or programming and testing stages. In the end the integration of the whole system would largely depend on knowledge and experience. So the complexity and invisibility inherent in the nature of the system make the realistic and estimates more difficult.
Novel application of software, changing technology and lack of homogeneity of project experience also contribute to incorrect and non-realistic initial estimates. The estimates made for the TASS largely depend on the experience and related materials found in books and on the internet. Such objective factors must influence the accuracy of the final results.
2.2 The stages where estimates are carried out
At different stages of a software project, the reasons for the estimate and the methods used will vary as well.
For the strategic planning phase, attention should be focused on the costs of computerizing potential applications and the benefits of doing so in order to help decide the priority of each project. The decision on the numbers of various types of staff recruited might depend on such estimates.
The phase of the feasibility study is carried out to justify the costs of the potential system with the benefits in order to ascertain whether the project should be carried out or not.
The differences between the definition of the users’ requirements and the design that documents how those requirements are to be fulfilled can be identified by most system development methodologies. The estimation of effort needed to implement different design proposals should be paid more attention on in the system specification phase.
In order to support the time duration estimation, the tasks carried out in the project should be classified in the first place. For the TASS, there are five major phases which comprise detailed tasks, Analyze, Design, Development, Testing and User Document Development. (Refer to Appendix A) During the project planning phase, with the planning and implementation of the project carrying out, the estimation of smaller tasks will be more detailed. This would help examine the earlier and more rough estimates as well as allocate staff and other recourses more precisely and reasonably for the next phase.
Actually re-estimating might take place at almost each phase of the project, but the estimates made in this step should be relatively high-level and comprehensive.
2.3 The basis of software estimating
The basis of software estimating comprises need for historical data, measure of work and complexity of the tasks.
The information about the project implementation in the past is quite an important resource needed for most of the estimating methods. However, due to possible differences and deviations in the environment, which include the programming language used, the software tools and experience of the staff, the applicability of the former data should be taken seriously to avoid misleading and confusing.
Since the material found about the project estimating are mostly concept and rationale explanation. The estimates are generally based on speculation with the help of some examples in the material. The experience in the Java programming area is also another essential resource to work out the results.
The measure of work normally concerns the actual cost and time required to implement a project. The time spent on wring a program and implementation times vary according to the competence or experience of the programmer and availability of the software tools respectively. Therefore, a measurement, such as source lines of code (SLOC), is usually taken to indicate the work load of the project to be implemented independently of effort. The complexity of the program also influences the time taken to write it by a developer. Even under the same environment, the time to complete two programs with the same SLOC is not necessarily the same. Although objective measures of complexity are pursued by estimators, the estimation often depends on some experience and subject judgments.
A Function Point analysis performed by Dr Mike Berry has been used as a measure of the functionality of the system. It can also indicate the size of the product being delivered to the client. Then the work effort to deliver that system can be estimated. The hours per function point for Java including the standard deviation is provided to do the analysis. Explanations for results out of the industry norm will be deliverable in the next part. This method provided for TASS estimation aims help us to improve our estimating abilities.
2.4 Discussion the Estimating Hours According to the Industry Norms
From the table generated by the Function Point Analysis method, it can be seen that the phases of Design, Testing and Implementing are within the industry normal range and the total hours needed for the project as well. Only the Build phase estimated is less than the industry normal range. There are several reasons can explain the variation.
The phase of building can be considered to be the most complex and largest part in the whole project. The number of the tasks and duration for this part are relatively larger when compared to other phases. So little variation on the number of the tasks, the duration allocated for each task could all influence the accuracy of the total results for the whole phase.
The Build phase of the project includes many time-costing activities, such as coding, programming and debugging. The time spent on these tasks and the degree of meeting the requirements also largely depend on the competence or the experience of the programmers. Many tasks in this phase should be carried on one after another with the assumption that the former one can be completed on time. The changing requirements of the users and the possibility of re-doing part of the coding when bugs can not be resolved are not taken into consideration at this stage. As the development phase comprises many tasks on the critical path, the slack given for those are also limited. So the estimation could be easily deviated from the industry norm.
The project was firstly divided into component tasks, then analyzed into its components sub-tasks and these in turn, were further analyzed. This process is repeated until that each task can be executed by a single person in about a week or two. Based on the knowledge and experience in terms of the programming we have, there is possibility that the tasks in each component and its sub-tasks were not fully analyzed.
The duration of each task is generally estimated in an ideal environment. The leave and illness of the staff or lack of necessary hardware and software resources were not taken into consideration. The emergence, which would happen in the real workplace and some other outside world factors, can not be speculated within the limited knowledge of ourselves. Limited real historical data about the duration of completing each task is another reason resulted in variation from the industry norm as well.
3. Risks Reporting
Risks are events that may or may not happen; however, if they happen, it would negatively affect the process of system development or the actual system. Therefore it is vitally important to identify all risks that may occur during the development of the system and appoint remedies to prevent or reduce the seriousness of these effects. There are 3 main types of risks, risks that are caused by incorrect estimation, incorrect assumptions or are unforeseen.
3.1 Estimation Error
A major issue with project development is making appropriate estimation, although estimation is difficult to determine, it is vitally important to make close-to-accurate estimations through researching historic data of similar projects. Historic data would allow the project team to estimate the cost and the time required for development.
Unrealistic estimation for TASS development plan would have a large impact on the outcome. Incorrect time and cost establish may lead to project failures due to delay in system delivery or lack of funds for development of the system to continue. A possible risk of the TASS development could be that the actual development does not follow the estimated schedule; an example to convey this could be that integrating the TASS database with the user interface could not be performed if the database or the interface has not been completed.
Therefore the estimation for TASS development must be accurate as possible to prevent undesired outcomes.
3.2 Planning Assumptions and Unforeseen Risks
Assumption is where a person takes a case and views it as true without sufficient evidence. In early stages of planning, assumptions are required due to unforeseen circumstances. Many assumptions had been made for the TASS development such as assuming that all screen design have been created and that all people and resources would be available; however if these assumptions are not valid it would affect the development process. For this example, there may be the risk that the people and resources provided to the developers do not meet their requirements, such as the fact that they might not be able to operate using the provided software as they have not been trained to use it.
It is commonly assumed in development projects that everything would run according to plan; however, project teams tend to fails to consider the fact that any part of the development process could have an error; therefore it is also important to consider the unforeseen problems. Such example for TASS, could be that Lux and Osborne’s machine’s have been infected of a virus causing the development process to stop while the problem is fixed.
Therefore, similar to estimation, assumption of the development must be made carefully and alternative options must be discussed during the planning stage to help mitigate unforeseen risks.
3.3 Risk Analysis
After risks of the project are identified it is important to analyze these risks according to their importance as some risks are not important as they have a smaller impact on the development process if they do occur or are less likely to occur (Refer to Appendix B). In order to prioritize risks, it is important to calculate the importance of the risk which is in proportion to how likely the risk is going to occur and the impact it has on the project.
Conclusion
The assignment aims at giving a good opportunity to understand and experience how to implement a project after receive the requirements specifications and before the resource allocation stage. It is comprised with three major parts: Decomposition and Planning, Estimating and Risk Reporting. They are carried on based on the assumptions given in the assignment specification and generated with the project being caring out.
The project was firstly divided into five components: Analyzing, Design, Development, Testing and Documenting. Then each component was further analyzed into sub-tasks and 75 detailed tasks in total have been worked out to implement the project within the scope required. The dependence network of each task was constructed with the PERT and milestones for each phase were also indicated in the diagram. The whole project can be completed on time under the assumption that the tasks on the critical path can be finished within the time slack and meet the basic requirements. The duration of the whole project can be defined by the critical path through the network, which was indicated as a red line in the PERT diagram. Milestones were identified which can be used to monitor the progress of the project implementation. The tasks finished on time at each milestone can in turn guarantee the whole project being delivered on time. The slack for a specific task can be used to deal with emergencies or events unpredictable encountered in the real implementation process and make the schedule flexible to a certain extent.
The duration and complexity of the tasks have been estimated in terms of the degree of the complexity of the task, the size of the task and the confidence in our estimate of the task. Three levels are given to measure the degree of each item. The measurements are also in compliance with the time duration allocated for each task. The Functional Points Analysis was performed online and the result was compared with the industry norms for each major phase. The Build or Development phase was estimated out of the normal range due to the several reasons, such as complexity and size of the system, the lack of experience of and non-sufficient materials available and lack of foreseeing redundant work in the real work place.
Risks management of the project was carried out by identifying the potential risks in every task, and then they were categorized into Project Factor/Method, Staff Factor, Application Factor, Environment and Safety Factor. Risks estimation consists of assessing the likelihood, impact and exposure of each hazard. Mitigation strategies were made for each specific hazard and indicated on the PERT diagram as well.
Documenting what have been achieved, problems encountered and correspondent resolution at the end of each phase could be helpful to the next task implementation as well as generating the user manual and system specification. Constant checking and re-estimating all elements after a stage comes to the end are also important in order to reduce errors and adjusting the following events according to the real situation. These could guarantee effective resource allocation to be implemented in the next stage and provide good references for monitoring and control the progress of the whole project.
Traceability Table
APPENDIX A
APPENDIX B
Risk Likelihood
Risk Impact
Risk Exposure
Resource: Pankaj J. 2002, Software project management in practice, Addison-Wesley, London
Risk Table
APPENDIX C
