Metrics Estimation Analysis, Product Development Measures - Assignment Example

Name : Tutor : Title : Institution : @2015. ASSIGNMENT PART 1 Project measures must be identified and evaluated keenly because lack of or insufficient analysis can easily lead to incomplete projects. However, many steps for one project are not suitable since they increase the complexity of the program and also make its analysis difficult. Measurements are important because they enable us to know the status of the project and detect any problems or required improvements. Metrics is crucial because they help us to identify and resolve critical errors before they occur. (K. G. Lockyer, 2005). Product Development Measures. Functional Points. Measurement:  The volume of software functionality that exist in an application. Attribute: Inputs, outputs, logic, inquiries, and interfaces. Evaluation object: Size of software. Unit: Lines of code. Counting rules: We must develop, enhance and ensure we support the software functionality. Function points are the primary units used to assess the size of the project, to manage the risks and establish the estimates of the project. For us to count the function points, we must tally the features that are inputs, outputs, logic, interfaces and inquiries and then multiply by the values that get established. The product total is the adjusted by the degree of its complexity, which resembles the domain-specific, and that depends on several factors. Function points have several challenges. Firstly, it is difficult to estimate the function points when the System Development is in initial stages. The complexity factor depends on analyst judgment, and it can vary according to personnel. Effort Hours. Measurement:  The number of hours that are required to complete a software activity. Attribute: training, vacation time, and management. Evaluation object: Project duration. Unit: Hours. Counting rules: Effort hours are used as the measure to monitor the progress and report productivity. It can be well estimated with the help of the organization’s historical data. The collection of this measure must have consistency so that accurate performance analysis has a possibility of achievement. Cost. Measurement:  These are the funds required to deliver software development process. Attribute: cost and hourly rate. Evaluation object: Amount spend. Unit: Currency. Counting rules: The cost analysis is determined by the appropriateness of the costs estimated, monitored and collected. The Constructive Cost Model (COCOMO) is one type of software cost estimation model designed by Barry Boehm. It helps us to estimate the cost, schedule, and effort when planning for a new software product development. Lines of Code. Measurement:  This refers to the codes that need to get the execution for a software to function. Attribute: lines of code. Evaluation object: Size of project. Unit: Number of lines. Counting rules: Line numbers differ with programming languages. For example, lines of C++ are not the same as those of Visual Basic. Line number is therefore not a perfect metric for measuring program performance. Defects. Measurement: These are the errors or the problems that lead to unsatisfactory results. Attribute: bugs, supplemental features or problems. Evaluation object: Size of project. Unit: Number of defects. Counting rules: Defects help in estimating the quality of software and also helps in taking the necessary corrective measures. They can occur anywhere not only in the software but also in the requirements analysis, design or documentation. Collaborating ways are changing as new and better tools are being developed by the time and that assist groups to collect together documents, to chat with each other and quickly plan meetings. Collaboration methods have moved from emails to text chats, video conferencing, scheduling meetings, bulletin boards, and screen sharing. Some new shareware team collaboration tools that have emerged recently and commonly used include Flow, Glip, and Slingshot. (Levine, 2002). Flow: It deals with tasks and the more a person can concentrate on many activities and perform them well, the more productive they will feel. It has versions to suit many platforms like Web, iOS, Mac, and Android. One defines a task, schedules the time it should required to complete and the person who should help to complete it and upload the relevant documents from either your computer or a Dropbox account if connected to one. It is handy because Flow concentrates mainly on tasks. However, some things do not fit. It is very easy to learn and use. The screen layouts are very clean and are consistent with the web and mobile devices. It has many notification settings, and a user can receive an email daily reminding them of their tasks. The information timing can also change to hourly or when necessary. (KENDRICK, 2009). For the people who do not have to schedule meetings or those using other software like Outlook, they can use Flow. Glip: This gets geared around tasks. It defines how to start them, who is working on them and when to plan for completion of a task. It can also include tracking text chats with the people or groups of correspondents. The chats may consist of images, documents or Web links. Glip is helpful to groups of users in two ways: one can create ad hoc groups of upto there, or more users who can share documents quickly and they can also make teams do particular projects. Its integrations are natural, and it can share files from one’s account on Dropbox or Google Docs and synchronize events to their Google Calendar. (K. G. Lockyer, 2005). Slingshot. It is the only service among the three which offers both lightweight video/audio conferencing and screen sharing.It works well for collaborations up to 10 people but not dozen of participants. (Levine, 2002). The primary focus of Slingshot’s is sharing the screen between two or more individuals, mostly for video chat together with support for text chat, meeting notes and document sharing. ASSIGNMENT PART 2 Effort Estimation Techniques. The primary aim of estimating effort is to determine the amount of effort required to complete a given task, using the knowledge of other project characteristics that have a similar effort. Project characteristics include independent variables that are the input, dependent variables that are the effort, and we try to estimate the output. The task of underdetermination can vary from a simple development of a single function such as creating a table in the database to creating large complex applications. Other independent variables such as number of tools employed and developers experience may also influence the effort. Several techniques exist that gets used for effort estimation in software engineering including artificial intelligence, algorithmic models, and expert opinion. (K. G. Lockyer, 2005). Algorithmic techniques are the most popular methods used for effort estimation. They try to formalize the relationship between one or more project characteristics and the energy. It results in an algorithmic model. The main project feature that commonly exist in such an example is the software size described by the lines of code, commands, entities used, user requirements among others. The formalization if mostly translated as an equation where the parameters (a and b) needs estimation. Estimated Effort = a EstSizeNewprob EAF. Where: A, b are the parameters chosen based on some criteria e.g. the type of software project being developed. EstSizeNewpro is the estimated size of the new project. EAF is the Effort Adjustment Factor. The EAF arises or gets calculated from the cost drivers such as tools, experience, and developers. A good example of an algorithmic model uses the above equation represent the Constructive Cost Model (COCOMO) model. In such a case, the parameters a and b depend on the type of project under construction and the EAF found on the basis of 15 cost drivers that emerged from computation and then summed up. (K. G. Lockyer, 2005). Table 2. Using the formula: Estimated Effort = an EstSizeNewprob EAF, the results of the table would be as shown in the table. Effort Commands User Requests User Messages Entities Used Printouts Data Base Accesses Estimated amount of Reuse % 324 22 1 1 22 3 20 10 421 16 12 4 15 5 11 0 516 18 13 3 5 4 16 5 378 54 2 4 1 17 3 8 The reservations made are that when the exponent is less than one, there is the economy of scale meaning that bigger projects utilize less effort compared to smaller projects. ASSIGNMENT PART 3 Any value that lies abnormal distance from other values is called the outlier data. At times, the outlier data represents important information so we must be careful when dealing with it. Any important observation should never be discarded just because it is an outlier. The graph above demonstrates the relationships between the comments and lines of code. It can clearly be seen that there are some outlier point. They do not have a significant effect on the project if it continues. We can look at both with and without it to compare the impact and show the dropping of any such data points and how the results changed. The graph above shows the relationship between the line codes and paths in the project. From the graph there are outlier points that do not have any effect. The analysis can therefore remove this point if he has significant experience. From the graph, the two outliers make an important association, therefore we can drop the outlier and should not demonstrate any implication from the analysis. Irrespective of the approach we use, we should know our data and our research area very well. Some data cannot be removed or modified. The outlier point is a dependent variable and can therefore decrease the effect of a single point if the outlier is an independent variable which is based on the graph. The graph shows a red point which has a very large residual and little leverage. this situation would be significant because they would be the substantial. The graph demonstrates that there are several outlier points that may have effect on the project process. They belong to a group on the same side thus we have to take care during the analysis. It is advisable to leave them if they have no significant effect. Another option is to use a different model. This must be done carefully since a non-linear model may fit better. The exponential curve fits the data with the outlier intact. From the graph, it can be clearly seen that some errors were made which we need to evaluate and recover where necessary. Coding and design errors are the two important components. They should therefore be given more attention. There is a systemtric relationship between test specification and coding error. The graph also shows the oulier point though outliers in this situation have relatively low impact on the regression line. ASSIGNMENT PART 4 Contingency Plan for Risk Management. Risk management is the process of preparing an agency to deal with any potentially harmful happenings that can occur in any technology initiative. Contingency planning does not only deal with major disasters but also smaller scale issues like loss of people, data, suppliers and customers in a business environment. Risk management gets into play so that potential risks can get identified and managed and also draw contingent plans to reduce the negative impact that can result from the risk. (KENDRICK, 2009). In our project, there is a risk that the project will run past the set time due to the unavailability of staff. Since the management has learned of the danger in time, they have a chance to make good plans to ensure that the project does not delay completely. There are several steps that should be taken to come up with a good contingent plan: Identify the Risks. The project managers must investigate what negative occurrences will emerge if the project fails to complete in time. They should study all impacts that will result from a delay in the project completion process. (KENDRICK, 2009). Group and quantify the risks identified. Likelihood: First, the probability of each adverse impact occurring should be examined based on what exists at present. The likelihood of its occurrence gets classified into one of the three categories: Remote – the perceived risk will not occur. Possible – there is a chance the risk will occur. Likely – the perceived risk will occur. (KENDRICK, 2009). The severity of the consequences of the risks is examined based on the total impact that will result from the risk on the initiative. Determine the tolerance level for the risks. Once the risks get known and categorized, the Project Team must first accept that they might occur and then plan a response to deal with them. There are three levels of tolerance: avoid, mitigate and take. According to project, under consideration, it is not possible to avoid since the availability of staff has a confirmation of an existing delay. It has come to a conclusion that, developing ways in which to compensate for the delay that will occur has no solution entirely. (KENDRICK, 2009). References. Read More