Skills and competencies

Transcription

1 The proper planning and estimating is required to measure the cost of your application development project Sometimes, software development projects fail. When they do, it's not much fun and in most cases, those involved would just rather sweep the whole thing under the rug and move on. According to objective analysis, 48% of projects fail because of bad planning and estimating. In these cases, the projects would have been successful had they been accurately estimated. If all the issues been factored in, the given schedule and cost would have been accurate. Who should do the estimating? In some organizations, this is the domain of the project manager. In other organizations, estimation is performed by architects or by a collaborative effort between the project manager and the architect. In any case, for software development initiatives, someone who is familiar with software development should be involved in the process! This article is an introduction to what you must consider when forming your estimate, as well as pitfalls to avoid. This article provides the architect's perspective on estimation, and the focus is on practical tips and practices that can help you improve estimation accuracy. Skills and competencies Estimation is often done informally, quite often in a hallway on the way to a meeting, and generally with a dearth of information and a tight deadline. "Hey, what will it cost for us to get that FooBar 8000 up and running in Java?" Sound familiar? It's incredibly tempting to quickly throw out a number, but avoid the temptation and read on! An estimate is incredibly important. It is the crux of the project, forms the development work breakdown structure, and becomes the basis of the project plan that the project manager and the rest of the team are going to be living with for the duration of the project. Developers are going to either praise the estimate as sage wisdom or curse it as folly, but they'll have to live by it. It's also subjective and essentially a highly experienced guess at what it's going to take to meet the objectives. The goal is to reduce the guesswork and provide as solid an estimate as possible. The challenge in estimating In technology projects, what you don't know during the design is often what hurts you the most. At the outset of the project, the details of how the project is going to be completed are typically unknown. Also, many project-delivery methodologies shift the role and phase in which high-level and detailed design is performed. A key activity in architectural estimation is differentiating between what's understood completely and what's ambiguous -- and to clarify the potential complexity of the unknown components. If you are typically an optimist, be a pessimist during this part of estimation. Challenge your assumptions and thinking. Assign anything that's different from what has been done in the past an increased risk factor, and think through the aspects of what might go awry. Build an estimation framework You can perform estimates in several ways. Much has been written about this process, and most experts disagree on everything except that estimating is difficult and that no matter how much science, psychology, or mathematics are applied, there's still a subjective element to the estimate. The key is to pick a method, build an estimation framework, and be consistent with its application. If you're consistent with your framework and you analyze your results, you're in a good position to refine your framework and, in time, improve your estimation ability. Within your framework, include a method of capturing and measuring actual data from projects. Track the effectiveness of your estimates by measuring them against the actual delivery; then, use this actual information when

2 forming new estimates. You can compile and store a fairly simple repository of actual delivery times in a spreadsheet or database for future retrieval. You can perform this task as part of the project wrap-up, and it will be worth the effort. This actual information is relevant when it comes to improving estimate accuracy. You can break down the aspects of the actual data into reusable components and use them to form building blocks for future estimates. For example, any tasks that your group frequently performs (such as server builds, database implementation, and database table development) mean JavaServer Pages (JSP) page-development time, servlet development time, and average time spent in project meetings broken down by team size. Any of this type of data broken down in a way that you can use to make informed assumptions about future activities helps reduce the guesswork in estimates. The importance of estimates If your organization understands the importance of accurate estimation and the unpleasant consequences of bad estimation, it's more likely to take estimation seriously and provide adequate time and resources for doing it effectively. Ideally, if you can establish a culture of disciplined estimation, you can eliminate the requests for off-thecuff estimates. People within your organization should also understand that estimates are guidelines within which to deliver projects and that you must occasionally recast the estimate during the project. Failing to properly estimate your project can result in the effort being held up against an unrealistic measurement. Your project could be progressing smoothly, but appear an abysmal failure because of unrealistic expectations. Guidelines for developing proper estimates should be developed within the organization and formalized as part of your organization's project-delivery methodology. Having a consistent way of conducting estimates includes engaging the right people at the right time in the project's life cycle to perform the estimate. If you find yourself in an organization that fails to take estimating seriously, you need to become the champion of quality estimates. Educate people within your organization on the effects of poor-quality estimates, demonstrate how quality estimates are conducted, and involve them in the process of creating a more accurate estimate. Explain the benefit of actual information, and clearly show the correlation between estimates and the risks associated with project overruns and failure. Show them the Institute of Electrical and Electronics Engineers (IEEE) "Software Hall of Shame" (see Resources), and explain that having a solid estimation framework will help keep your organization off that list. Back to top Tools and techniques This article includes a few methods of estimating that I've worked with. (See the Resources section for links.) Some of these methods will require additional research for you to use. Others are more pragmatic and are based on my experiences with development projects as a developer, project manager, and architect. The primary difference in estimation methodologies is in the units by which you define effort. What is the most relevant unit? That depends on what you're building and how you can best quantify it. Estimation tools There are no magic tools that can perform estimates for you -- expertise and judgement are required. Tools can assist in the design aspect to help you articulate and understand what you're going to build. Tools are also available to assist in the application of estimation methodologies and best practices. Design tools that I've found useful when designing software and forming an estimate include: IBM Rational Software Modeler: This tool is a Unified Modeling Language (UML) V2.0 editor based on Eclipse. It takes a model-driven architectural approach to software development in which you design your class objects and map interactions between them. This approach allows for a high-resolution depiction of the system but requires clear requirements to create the models. Within Rational Software Modeler, you can

3 transform models into other models or export them to code, which can help bridge the gap between architecture and the development team by providing some example code rather than diagrams alone. Cost Xpert: This tool assists with estimates where requirements are not readily available. It leads you through many environmental and other factors and provides worksheets for various estimation approaches (function points, bottom up, and so on). One feature of the tool is that you select the project methodology as part of the process, and the tool takes this choice into account for the estimate -- an important point, because each methodology has its own documentation and "ceremony" that affect the project time lines. Construx Estimator: This tool is provided free of charge (with a limited license), which is quite a value considering the features available. It takes input in the form of lines of code, function points, or other metrics, then applies a statistical probability analysis to determine the range of effort and duration required to complete the project. Actual data can be stored and used with this tool, as well. ISBSG Early Estimate Checker: Use this tool, shown in Figure 1, as a sanity check for your early estimates. Your estimate (in function points) is verified against the International Software Benchmarking Standards Group (ISBSG) repository of actual project results. Figure 1. Validating an early estimate against the ISBSG repository of actual results Many other tools are available, but the tools are of less importance than the fundamental approach you take toward estimating (although the tools can assist with keeping estimates consistent and reduce some of the effort associated with creating them). One approach to estimating requires that you fully understand the objectives of what you're looking to accomplish, then think about each detailed task required from initiation to completion. Typically, I create this kind of estimate as a Gantt chart in Microsoft Office Project or Excel, as shown in Figure 2 to use as a starting point for brainstorming the steps in delivery. At this point, you should have a fairly clear idea of which software development methodology you're going to use, because the phases and steps will change depending on your approach. Figure 2. Sample Gantt chart for a Web application project estimated with function points

4 Figure 3. Different outcomes for different estimation approaches in the same project

5 Often, the average of multiple estimation methods is useful in determining the effort, schedule, and cost. When you have clearly defined your objectives, you can use several methods to estimate your project, including: Team-based, bottom-up estimates: With this method, you give each member of your team a copy of the project plan, then ask each person to provide an independent "bottom-up" estimate for the project tasks. A bottom-up estimate is one formed by compiling an estimate of the detailed tasks in the plan. It's a good idea also to ask team members to add any tasks they believe are missing and remove any that they think are unwarranted. You then bring everyone together and discuss their estimates, assumptions, and tasks. If you're are a team lead or architect and plan to have your team provide bottom-up estimates during the project, this meeting can be a useful way of determining how your team estimates -- important information when facing deadlines. Estimation repository: As mentioned previously, if you can establish a repository of actual units, you can form estimates based on them. Factoring in previous actual data helps increase the accuracy of estimates and can be used to form a "factory" approach to estimating in which after all the components are in the repository, you can form accurate estimates based on them. Lines of code: This approach is probably most useful when applied to traditional (nonvisual or Web-based) development efforts in which a line of code is actually written and productivity assumptions made about development effort decoupled from other factors. The fundamental questions you need to ask are how long will a developer spend writing a line of code and how many lines are going to be required for this project? Function points: Function points are concerned with determining the functionality and functional complexity associated with the target system. Typically, this involves counting the number of inputs, outputs, queries, files, and interfaces, then assigning a complexity coefficient to each of them. Function points are most useful when detailed requirements are available and the functions can be counted. Internet points: Internet points are based on function points, with additional descriptors based on the Webdevelopment paradigm. For example, dynamic screens are differentiated from static screens. UML use-case points: For projects following the IBM Rational Unified Process ; (RUP ) of development or relying on UML models for design, you can use use-case points to estimate based on the number of scenarios and acceptance test cases in the initiative, as shown in Figure 4. Figure 4. Sample use-case in Rational Software Modeler V7

6 Environmental factors If I asked you how long it would take you to write a line of code (in any programming language) that instantiated a variable and wrote output to a terminal, you would probably think that you could perform this simple task relatively easily and quickly and provide an estimate that showed a low level of effort. Now, if I told you that the program will support 3 million simultaneous users, must be written on the summit of Mt. Everest, and will have to support the Nepali language, does your estimate change? Of course. This is an extreme example, but in every case, the environmental factors affect delivery schedule and budget. Some environmental factors to consider when estimating include: Team cohesion: How well does the team work together? If they haven't had much experience together, this will increase the time it takes them to learn how to work seamlessly. Flexibility: Does the client (internal or external) insist that the code be deployed on a specific application server or use a specific third-party product? Any "immovable objects" in the project will add to the risk that an issue is discovered and must be worked around. Precedence: Does your team frequently perform this type of project for this client? If so, this reduces the risk. If not, don't forget to add some time to train the client on the process. This is especially true of clients who are not familiar with software development projects and especially, iterative design methodologies. Environment and location: If the project has its own space that's designed for quiet, uninterrupted work and for group/collaborative work, this is ideal. Anything else decreases productivity and increases the cost and schedule. If many members of the team are commuting great distances or working in an unconventional location (for example, the Mt. Everest summit), you must take this into account, as well. Software development life cycle tools: Any tools your team is using to facilitate software development can increase productivity. If your team is new to the tool set, invest in training and allocate time so that the team becomes productive with it. The client: Over the life of the project, your client will have to make decisions. Understanding how your client makes decisions and their "turnaround time" is important when estimating. If the team is stuck in a holding pattern until a decision is made, this can add days, weeks, or months to the project schedule. Nonfunctional requirements: It is important to fully understand the expectations around availability, scalability, maintainability, quality, usability, reliability, and other "-ilities" when creating your estimate. Many of these elements are qualitative, and your project may need to define them in very specific terms to achieve your objectives. Integration and testing: You may be building one small component, but that component may be connecting to a large labyrinth of other systems. If so, significant time will be required for integration and testing. When considering testing, don't forget about performance-testing efforts and time that you may need to allocate to the remediation of performance defects. Back to top Milestones There is more information about estimation than this article can do justice to, but in the interest of leaving you with practical, usable information, here are some milestones to strive for in achieving more accurate estimates:

7 Establish a consistent denominator of effort: Agree with other estimators within your organization on how effort will be denominated for similar projects. Are all Web applications going to be modeled with usecase diagrams and UML use-case points? Are all C programs that are written in the IBM AIX environment going to be based on source lines of code (SLOC)? Being consistent on this across the organization and tracking the results in the repository will help build reusable organizational knowledge on estimation and delivery. Refine your estimation framework: After you have created your estimation framework and you can track the actuals against estimates, continue to improve the framework and the estimation approach to reach higher accuracy levels. Increased clarity of requirements and objectives: As an architect, I prefer to have minimal layers between me and the users articulating requirements. Having an opportunity to hear about the objectives and probe the requirements can mean the difference in interpreting requirements literally and designing something that elegantly meets the comprehensive needs. Build organizational knowledge: Essentially this involves having enough experience within your organization to not leave anything out when estimating. This sounds simple, but it's an important consideration. Is the application deployment included in the estimate? Has user acceptance testing (UAT) been considered along with potential additional iterations that may come from UAT sessions? Develop an aversion to mandated time lines: Sometimes, estimates are requested where there's a right answer and a wrong answer. These are not called estimates, they're set time lines, and they require a different type of analysis -- an analysis of what a team can accomplish within a set time frame. Be sure to differentiate this type of activity from estimation. When your organization has achieved this, it's a major milestone that demonstrates the importance of estimates as an essential element of a successful project. Leverage industry information: Information may be available about productivity levels for the types of projects that your organization engages in. Also, check the benchmarks available from the ISBSG, which has compiled a cross-organizational repository of more than 4,100 project outcomes.

8 Follow us our social media If you have any kind Thank you quantity-takeoff.com Contactt us Globall Associates 21/1 cannal streett Lake town Kol quantity-takeoff.com of relevant documentation share it with us