(GSCs). It is a set of 14 GSCs that need to be considered. The procedure for adjusting UFPs is as follows: Degree of Influence (DI) for each of these 14 GSCs is assessed on a scale of 0 to 5. (b) If a particular GSC has no influence, then its weight is taken as 0 and if it has a strong influence then its weight is 5. The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI). Then Value Adjustment Factor (VAF) is computed from TDI by using the formula: VAF = (TDI * 0.01) + 0.65 Remember that the value of VAF lies within 0.65 to 1.35 because a. When TDI = 0, VAF = 0.65 b. When TDI = 70, VAF = 1.35 c. VAF is then multiplied with the UFP to get the final FP count: FP = VAF * UFP Example: Compute the function point, productivity, documentation, cost per function for the following data: 1. Number of user inputs = 24 2. Number of user outputs = 46 3. Number of inquiries = 8 4. Number of files = 4 5. Number of external interfaces = 2 6. Effort = 36.9 p-m 7. Technical documents = 265 pages 8. User documents = 122 pages 9. Cost = $7744/ month Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5. Solution: Count Weighing Measurement Parameter factor 1. Number of external inputs (EI) 24 * 4 = 96 10 2. Number of external outputs (EO) 46 * 4 = 184 49 3. Number of external inquiries (EQ) 8* 6 = 48 4. Number of internal files (ILF) 4* 10 = 40 5. Number of external interfaces (EIF) Count- 2* 5= total → 378 CU IDOL SELF LEARNING MATERIAL (SLM)
So sum of all fi (i ← 1 to 14) = 4 + 1 + 0 + 3 + 5 + 4 + 4 + 3 + 3 + 2 + 2 + 4 + 5 = 43 FP = Count-total * [0.65 + 0.01 *∑(fi)] = 378 * [0.65 + 0.01 * 43] = 378 * [0.65 + 0.43] = 378 * 1.08 = 408 Total pages of documentation = technical document + user document = 265 + 122 = 387pages Documentation = Pages of documentation/FP = 387/408 = 0.94 SUMMARY Let’s revise the basic concepts discussed in the unit as - • Project Estimation is a process to predict the time and the cost that a project requires to be finished appropriately. But in term of software development, it also means of the consideration of the experience of the software development company; the technique they employ; the process they may go through to finish the task. • Crucial steps of Estimation Process: • Determining the goals and commitments- Communicating clearly the goals or the needs of yours with the estimation team would well guide the whole process to the right place it is expected to be. • Comprehending the functional scope of the project - The most essential factor for sizing a project is to determine what you want to develop and what would it reach. • Paying attention to non-functional needs- These functions focus on the “how” the project might work to meet the requirements of the customers. • Setting clear priorities - It is important to clarify the utmost importance of each functional priority in order to focus on the most essential ones. • Considering goals and commitments in agile plans- Agile methodology is a contemporary developing method that allows customers and app development center to continuously communicate and make changes to their product throughout the process of developing, • Choosing estimation strategies- Classic estimation (expert judgment): This is likely the most common way, and it includes of selecting a requirement and allocates it a time value based on the difficulty and how experienced the estimators are in the required field. a) Revising estimations b) Employing estimation tools c) Different methods of estimation – 50 CU IDOL SELF LEARNING MATERIAL (SLM)
• COCOMO Model - COCOMO predicts the efforts and schedule of a software product based on the size of the software. • Delphi technique of software estimation - In software estimation, the project specifications are allotted to the experts and they convey their views/opinions about the same. • Functional Point (FP) Analysis- FPA is used to make estimate of the software project, including its testing in terms of functionality or function size of the software product. KEYWORDS • Project Estimation- is a process to predict the time and the cost that a project requires to be finished appropriately. • Attribute definition is - a quality, character, or characteristic ascribed to someone or something. • Effort is the total effort required to develop the software product, expressed in person months. • Embedded: fixed firmly and deeply in a surrounding mass. • COCOMO model: predicts the efforts and schedule of a software product based on the size of the software. LEARNING ACTIVITY 1. Differentiate between Delphi Technique and Functional Point Analysis. 2. Compare Pros and Cons of COCOMO and Delphi Model. UNIT END QUESTIONS A. Descriptive Type Questions 1. What is Project Estimation? Explain its importance. 2. State different types of risks. 3. Elaborate - The intermediate COCOMO model recognizes these facts and refines the initial estimates obtained through the basic COCOMO model. Also highlights the difference between basic and intermediate COCOMO model. 4. Justify, ‘A useful technique in the absence of experts within the organization, as Delphi allows hiring experts from external sources with required domain knowledge for the project’. 5. Write a note on objectives of FPA. 51 CU IDOL SELF LEARNING MATERIAL (SLM)
B. Multiple Choice Question: 1. Which of the following are parameters involved in computing the total cost of a software development project? a) Hardware and software costs b) Effort costs c) Travel and training costs d) All of the mentioned 2. Which of the following costs is not part of the total effort cost? a) Costs of networking and communications b) Costs of providing heating and lighting office space c) Costs of lunch time food d) Costs of support staff 3. incorporates a range of sub-models that produce increasingly detailed software estimates. a) COCOMO 2 b) Functional Point Analysis c) Delphi Technique d) Standard Model 4. According to Intermediate model, the basic Cocomo model considers that the effort is only a function of the and some constants calculated according to the various software systems. a) Size of project b) Number of lines of code c) Number of people in project d) Number of developer in project 5. A development project can be treated of the type, if the project deals with developing a well-understood application program, the size of the development team is reasonably small, and the team members are experienced in developing similar methods of projects. a) Organic b) Embedded c) Semi-Detached d) Attached Answers: 52 CU IDOL SELF LEARNING MATERIAL (SLM)
1 -d; 2 -c; 3 -a; 4 -b; 5-a REFERENCES • Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide)–Sixth Edition Sixth Edition, Sixth edition, Project Management Institute • Bob Hughes, Mike Cotterell and Rajib Mall, ‘Software Project Management’- Tata McGrawHill. • Bennatan E. (1994).Software Project Management.London: McGraw-Hill. • Greg Horine, Project Management Absolute Beginner's Guide (3rd Edition), Que Publishing. • Robert K. Wysocki, Effective Software Project Management, Wiley • G. L. Rexing, \"Software project management: Moving beyond project plans,\" in AT&T Technical Journal, vol. 70, no. 2, pp. 40-48, March-April 1991. • Marcelo Marinho , Suzana Sampaio , Telma Lima and Hermano de Moura, “A SYSTEMATIC REVIEW OF UNCERTAINTIES IN SOFTWARE PROJECT MANAGEMENT”, in International Journal of Software Engineering & Applications (IJSEA), Vol.5, No.6, November 2014. 53 CU IDOL SELF LEARNING MATERIAL (SLM)
• UNIT 4 - PROJECT MANAGEMENT TOOLS & TECHNIQUES Structure Learning Objectives Introduction PERT Steps to Implementing a PERT Chart How to Calculate PERT Creating a PERT Chart PERT Chart Example Gantt Charts The Use Tools Available Advantages & Disadvantages Creating a Gantt Chart Examples Key Points Introduction to Microsoft Project Project Management Summary Keywords Learning Activity Unit End Questions References LEARNING OBJECTIVES After studying this unit, you should be able to • Explain the concept of PERT and Gantt Charts • Outline the basic working of Microsoft Project INTRODUCTION Before any activity begins related to the work of a project, every project requires an advanced, accurate time estimate. Without an accurate estimate, no project can be completed within the budget and the target completion date. Developing an estimate is a complex task. If the project is large and has many stakeholders, things can be more complex. 54 CU IDOL SELF LEARNING MATERIAL (SLM)
Therefore, there have been many initiatives to come up with different techniques for estimation phase of the project in order to make the estimation more accurate. PERT (Program Evaluation and Review Technique) is one of the successful and proven methods among the many other techniques, such as, CPM, Function Point Counting, Top- Down Estimating, WAVE, etc. PERT was initially created by the US Navy in the late 1950s. The pilot project was for developing Ballistic Missiles and there have been thousands of contractors involved. After PERT methodology was employed for this project, it actually ended two years ahead of its initial schedule. A Gantt chart is a type of bar chart that illustrates a project schedule, named after its inventor, Henry Gantt (1861–1919), who designed such a chart around the years 1910– 1915.Modern Gantt charts also show the dependency relationships between activities and current schedule status. PERT charts, as detailed above, were developed to simplify planning and scheduling larger and complex projects. A Gantt chart, on the other hand, is also a graphical depiction for planning and scheduling a project, which breaks down tasks down into tasks that populate a timeline. A Gantt chart can set task dependencies and shows the duration of each task. PERT PERT is an acronym that stands for Program Evaluation and Review Technique. It’s a statistical method that can be very useful when working on a project, as it analyzes and represents the project’s tasks. A PERT chart is a graphic representation of the data you generate from that method, laid out as a timeline. It’s a critical tool project managers can use when putting together a project schedule, as it allows them to break down each of the project’s tasks for analysis. The purpose of the PERT chart is to find out how much time will be required to finish each task in the project. This leads to figuring out the minimum time needed to complete the whole project. What’s unique about a PERT chart is that you don’t have to start your plan with a beginning and an end. Since it’s focused on events, you can create one without knowing every detail. A PERT chart also gives you the raw data that can be imported into project scheduling software, which helps you manage the whole project, link your schedule to your plan, monitor progress and keep stakeholders in the loop with reports. Steps to Implementing a PERT Chart Use a PERT in the planning phase of your project. Here are the steps in broad strokes: 1. Begin by identifying the project milestones and then break those down into individual tasks. 2. Figure out the sequence of the tasks. 55 CU IDOL SELF LEARNING MATERIAL (SLM)
3. Make the PERT diagram — we’ll show you how in the section below! 4. Do an estimate for each task and the time it will take to complete it. 5. Calculate the critical path and identify any possible slack. 6. You have your PERT chart! Remember, the PERT chart is a living document that must be returned to and revised as needed as the project progresses. How to Calculate PERT Before we create a PERT chart, it’s helpful to know how to calculate PERT itself. PERT relies on the weighted average of three numbers that are based on the most pessimistic (P), the most optimistic (O) and the most likely (M) estimates for the project’s length. 1. Optimistic Time: The least amount of time to accomplish a task or activity. This is a scenario when everything is working and you beat the estimated schedule. 2. Pessimistic Time: The maximum amount of time to accomplish a task or activity. This is the worst-case scenario, anything that can go wrong does. 3. Most Likely Time: The best estimate of how long it will take to accomplish the task or activity, assuming there are no problems. This would be your estimation working out perfectly, as rare as that might occur. 4. Expected Time: The best estimate of how long it will take to accomplish the task or activity, assuming there will be problems. This would be the more realistic duration. Using the figures you come up with for P, O and M, calculate the equation: (O + 4M + P)/6 To determine the volatility of your estimate, subtract the pessimistic number from the optimistic one and divide the results by six. The larger your results, the less confidence you have in your estimate, and vice versa; the smaller the figure, the greater your sense of confidence in the estimation. The result is a weighted average, which is an average from multiplying each element by a factor that reflects its importance. You can think of this as the expected time, though often the calculation will bend towards the pessimistic. That’s because usually the pessimistic figure is larger than that of the optimistic one. This calculation helps you estimate all the tasks in your schedule, but it can also focus solely on activities that are high risk. The latter is helpful as the more risky the task, the wider the margin of error is when making an estimation of how much time it’ll take. Creating a PERT Chart Let’s move these concepts from abstraction to reality. To better understand the power of a PERT chart, let’s make one together. For our PERT chart example, we’ll create a project around building a website. The PERT chart will help us organize our project with milestones, allow us to estimate our tasks and quickly uncover the critical path. Observe the PERT Chart below, and we’ll walk through how we created it. 56 CU IDOL SELF LEARNING MATERIAL (SLM)
PERT Chart Example To begin, we’re going to list the milestones for our website project. Keeping this process simple for the sake of clarity, here are eight project phases. 1. Design 2. Create Copy & Art 3. Build Site 4. Develop Marketing 5. Test Site 6. Edit Copy & Art 7. Marketing Push 8. Deploy First, we’ll transfer these to the PERT chart. Each phase is turned into a node, which is displayed as a circle with numbers in them; these will be our project milestones. Next, we figure out how long all the tasks to get to our deliverables will take. The amount of time you estimate should be added to the chart next to each node. In our example chart, the time estimate is depicted by small green circles in the corner of each node. We used weeks as our time unit, but it could be days or months, depending on your project. Once this is done, we link up the milestones using vectors. Vectors are the lines that have arrows—these arrows represent the flow and sequences of events that will take the project from start to finish. More than one arrow can go to more than one node. As in our example, the creation of copy and art will go towards the software team building the site, but also goes to the content team who will be editing that work. NOTE: A vector that is solid needs to take place concurrently. If the vector is dotted, however, it means that the work must be done in sequence, but doesn’t require resources. With the completed chart, it becomes clear which activities are critical to delivering the project on time. These are represented by the red numbers in the nodes. Once the critical path is determined, you can easily refer to it to keep your project on track! Fig 4.1: PERT chart example 57 CU IDOL SELF LEARNING MATERIAL (SLM)
4. 3 GANTT CHART Gantt chart is a type of a bar chart that is used for illustrating project schedules. Gantt charts can be used in any projects that involve effort, resources, milestones and deliveries. At present, Gantt charts have become the popular choice of project managers in every field. Gantt charts allow project managers to track the progress of the entire project. Through Gantt charts, the project manager can keep a track of the individual tasks as well as of the overall project progression. In addition to tracking the progression of the tasks, Gantt charts can also be used for tracking the utilization of the resources in the project. These resources can be human resources as well as materials used. Gantt chart was invented by a mechanical engineer named Henry Gantt in 1910. Since the invention, Gantt chart has come a long way. By today, it takes different forms from simple paper based charts to sophisticated software packages. The Use As we have already discussed, Gantt charts are used for project management purposes. In order to use Gantt charts in a project, there are a few initial requirements fulfilled by the project. First of all, the project should have a sufficiently detailed Work Breakdown Structure (WBS). Secondly, the project should have identified its milestones and deliveries. In some instances, project managers try to define the work break down structure while creating Gantt chart. This is one of the frequently practiced errors in using Gantt charts. Gantt charts are not designed to assist WBS process; rather Gantt charts are for task progress tracking. Gantt charts can be successfully used in projects of any scale. When using Gantt charts for large projects, there can be an increased complexity when tracking the tasks. This problem of complexity can be successfully overcome by using computer software packages designed for offering Gantt chart functionalities. Tools Available There are dozens of Gantt chart tools that can be used for successful project tracking. These tools usually vary by the feature offered. Fig 4.2: Gantt chart in Microsoft Excel 58 CU IDOL SELF LEARNING MATERIAL (SLM)
The simplest kind of Gantt chart can be created using a software tool such as Microsoft Excel. For that matter, any spreadsheet tool can be used to design a Gantt chart template. If the project is small scale and does not involve many parallel tasks, a spreadsheet based Gantt chart can be the most effective type. Microsoft Project is one of the key Gantt chart tools used today. Especially for software development projects, MS Project based Gantt charts are essential to track the hundreds of parallel tasks involved in the software development life cycle. There are many other Gantt chart tools available for free and for price. The features offered by these tools range from the same features offered by Excel based Gantt charts to MS Project Gantt charts. Advantages & Disadvantages The ability to grasp the overall status of a project and its tasks at once is the key advantage in using a Gantt chart tool. Therefore, upper management or the sponsors of the project can make informed decisions just by looking at the Gantt chart tool. The software-based Gantt charts are able to show the task dependencies in a project schedule. This helps to identify and maintain the critical path of a project schedule. Gantt chart tools can be used as the single entity for managing small projects. For small projects, no other documentation may be required; but for large projects, the Gantt chart tool should be supported by other means of documentation. For large projects, the information displayed in Gantt charts may not be sufficient for decision making. Although Gantt charts accurately represent the cost, time and scope aspects of a project, it does not elaborate on the project size or size of the work elements. Therefore, the magnitude of constraints and issues can be easily misunderstood. Creating a Gantt Chart You can see an example in figure 4.3, below: Figure 4.3 – A Gantt chart 59 CU IDOL SELF LEARNING MATERIAL (SLM)
To create one for your project, follow these steps, using our example as a guide. Step 1: Identify Essential Tasks Gantt charts don't give useful information unless they include all of the activities needed for a project or project phase to be completed. So, to start, list all of these activities. Use a work breakdown structure if you need to establish what the tasks are. Then, for each task, note its earliest start date and its estimated duration. Examples Example: Your organization has won a tender to create a new \"Software as a Service\" product, and you're in charge of the project. You decide to use a Gantt chart to organize all of the necessary tasks, and to calculate the likely overall timescale for delivery. You start by listing all of the activities that have to take place, and you estimate how long each task should take to complete. Your list looks as follows: Table 4.1: List of activities with estimates Task Length A. High level analysis 1 week B. Selection of server hosting 1 day C. Configuration of server 2 weeks D. Detailed analysis of core modules 2 weeks E. Detailed analysis of supporting modules 2 weeks F. Development of core modules 3 weeks G. Development of supporting modules 3 weeks H. Quality assurance of core modules 1 week I. Quality assurance of supporting modules 1 week 60 CU IDOL SELF LEARNING MATERIAL (SLM)
Task Length J. Initial client internal training 1 day K. Development and QA of accounting reporting 1 week L. Development and QA of management reporting 1 week M. Development of management information system 1 week N. Client internal user training 1 week Step 2: Identify Task Relationships The chart shows the relationship between the tasks in a project. Some tasks will need to be completed before you can start the next one, and others can't end until preceding ones have ended. For example, if you're creating a brochure, you need to finish the design before you can send it to print. These dependent activities are called \"sequential\" or \"linear\" tasks. Other tasks will be \"parallel\" – i.e. they can be done at the same time as other tasks. You don't have to do these in sequence, but you may sometimes need other tasks to be finished first. So, for example, the design of your brochure could begin before the text has been edited (although you won't be able to finalize the design until the text is perfect.) Identify which of your project's tasks are parallel, and which are sequential. Where tasks are dependent on others, note down the relationship between them. This will give you a deeper understanding of how to organize your project, and it will help when you start scheduling activities on the chart. Note: In Gantt charts, there are three main relationships between sequential tasks: • Finish to Start (FS) – FS tasks can't start before a previous (and related) task is finished. However, they can start later. • Start to Start (SS) – SS tasks can't start until a preceding task starts. However, they can start later. • Finish to Finish (FF) – FF tasks can't end before a preceding task ends. However, they can end later. A fourth type, Start to Finish (SF), is very rare. Tip 1: Tasks can be sequential and parallel at the same time – for example, two tasks (B and D) may be dependent on another one (A), and may be completed at the same time. Task B is sequential in that it follows on from A, and it is parallel, with respect to D. 61 CU IDOL SELF LEARNING MATERIAL (SLM)
Tip 2: To minimize delivery times, you'll need to do as much work in parallel as you sensibly can. You also need to keep the scope of the project as small as possible. Example Table 4.2: Task and their lengths Task Length Type* Dependent on... A. High level analysis 1 week S B. Selection of server hosting 1 day SA C. Configuration of server 2 weeks SB D. Detailed analysis of core modules 2 weeks S, P to B, C A E. Detailed analysis of supporting modules 2 weeks S, P to F D F. Development of core modules 3 weeks S, P to E D G. Development of supporting modules 3 weeks S, P to H, J E H. Quality assurance of core modules 1 week S, P to G F I. Quality assurance of supporting modules 1 week SG J. Initial client internal training 1 day S, P to G C,H K. Development and QA of accounting 1 week SE reporting L. Development and QA of management 1 week SE reporting M. Development of Management 1 week SL Information System S I, J, K, M N. Client internal user training 1 week * P: Parallel, S: Sequential 62 CU IDOL SELF LEARNING MATERIAL (SLM)
Step 3: Input Activities into Software or a Template You can draw your charts by hand or use specialist software, such as Gantt, Match ware, or Microsoft Project. Some of these tools are cloud-based, meaning that you and your team can access the document simultaneously, from any location. (This helps a lot when you're discussing, optimizing, and reporting on a project.) Several Gantt templates have been created for Microsoft Excel, and you can also find free templates with a quick search online. Figure 4.4 – Example Gantt chart Step 4: Chart Progress As your project moves along, it will evolve. For example, in our scenario, if quality assurance of core modules revealed a problem, then you may need to delay training, and halt development of the management information system until the issue is resolved. Update your chart to reflect changes as soon as they occur. This will help you to keep your plans, your team, and your sponsors up to date. Key Points Gantt charts are useful for planning and scheduling projects. They help you assess how long a project should take, determine the resources needed, and plan the order in which you'll complete tasks. They're also helpful for managing the dependencies between tasks. Gantt charts are useful for monitoring a project's progress once it's underway, too. You can immediately see what should have been achieved by a certain date and, if the project is behind schedule, you can take action to bring it back on course. 63 CU IDOL SELF LEARNING MATERIAL (SLM)
Introduction to Microsoft Project Microsoft Project is a project management software program developed and sold by Microsoft, designed to assist a project manager in developing a schedule, assigning resources to tasks, tracking progress, managing the budget, and analyzing workloads. Project creates budgets based on assignment work and resource rates. As resources are assigned to tasks and assignment work estimated, the program calculates the cost, equal to the work times the rate, which rolls up to the task level and then to any summary task, and finally to the project level. Each resource can have its own calendar, which defines what days and shifts a resource is available. Microsoft Project is not suitable for solving problems of available materials (resources) constrained production. Additional software is necessary to manage a complex facility that produces physical goods. Project Management MS Project is feature rich, but project management techniques are required to drive a project effectively. A lot of project managers get confused between a schedule and a plan. MS Project can help you in creating a Schedule for the project even with the provided constraints. It cannot Plan for you. As a project manager you should be able to answer the following specific questions as part of the planning process to develop a schedule. MS Project cannot answer these for you. • What tasks need to be performed to create the deliverables of the project and in what order? This relates to the scope of the project. • What are the time constraints and deadlines if any, for different tasks and for the project as a whole? This relates to the schedule of the project. • What kind of resources (man/machine/material) are needed to perform each task? • How much will each task cost to accomplish? This would relate to the cost of the project. • What kind of risk do we have associated with a particular schedule for the project? This might affect the scope, cost and time constraints of your project. Strictly speaking, from the perspective of Project Management Methodology, a Plan and Schedule are not the same. A plan is a detailed action-oriented, experience and knowledge-based exercise which considers all elements of strategy, scope, cost, time, resources, quality and risk for the project. Scheduling is the science of using mathematical calculations and logic to generate time effective sequence of task considering any resource and cost constraints. Schedule is part of 64 CU IDOL SELF LEARNING MATERIAL (SLM)
the Plan. In Project Management Methodology, schedule would only mean listing of a project's milestones, tasks/activities, and deliverables, with start and finish dates. Of course the schedule is linked with resources, budgets and dependencies. However, in this tutorial for MS Project (and in all available help for MS Project) the word ‘Plan’ is used as a ‘Schedule’ being created in MS Project. This is because of two reasons. One, MS Project does more than just create a schedule it can establish dependencies among tasks, it can create constraints, it can resolve resource conflicts, and it can also help in reviewing cost and schedule performance over the duration of the project. So it does help in more than just creating a Schedule. This it makes sense for Microsoft to market MS Project as a Plan Creator rather than over-simplifying it as just a schedule creator. Two, it is due to limitation of generally accepted form of English language, where a schedule can be both in a noun as well as verb form. As a noun, a Schedule is like a time table or a series of things to be done or of events to occur at or during a particular time or period. And in the verb form, schedule is to plan for a certain date. Therefore it is much easier to say that, “One can schedule a plan from a start date” but very awkward to say, “One can schedule a schedule from a start date”. The distinction is important for you as a project manager, but as far as MS project is concerned the noun form of Schedule is a Plan. Of course, a project manager should also be able to answer other project-related questions as well. For example − • Why this project needs to be run by the organization? • What’s the best way to communicate project details to the stakeholders? • What is the risk management plan? • How the vendors are going to be managed? • How the project is tracked and monitored? • How the quality is measured and qualified? MS Project can help you − • Visualize your project plan in standard defined formats. • Schedule tasks and resources consistently and effectively. • Track information about the work, duration, and resource requirements for your project. • Generate reports to share in progress meetings. SUMMARY ▪ PERT is an acronym that stands for Program Evaluation and Review Technique. It’s a statistical method that can be very useful when working on a project, as it analyses and represents the project’s tasks. ▪ PERT relies on the weighted average of three numbers that are based on the most pessimistic (P), the most optimistic (O) and the most likely (M) estimates for the project’s length. 65 CU IDOL SELF LEARNING MATERIAL (SLM)
▪ Optimistic Time: The least amount of time to accomplish a task or activity. This is a scenario when everything is working and you beat the estimated schedule. ▪ Pessimistic Time: The maximum amount of time to accomplish a task or activity. This is the worst-case scenario, anything that can go wrong does. ▪ Most Likely Time: The best estimate of how long it will take to accomplish the task or activity, assuming there are no problems. This would be your estimation working out perfectly, as rare as that might occur. ▪ Expected Time: The best estimate of how long it will take to accomplish the task or activity, assuming there will be problems. This would be the more realistic duration. Using the figures you come up with for P, O and M, calculate the equation: (O + 4M + P)/6 ▪ Gantt chart is a type of a bar chart that is used for illustrating project schedules ▪ In order to use Gantt charts in a project, there are a few initial requirements fulfilled by the project. o First of all, the project should have a sufficiently detailed Work Breakdown Structure (WBS). o Secondly, the project should have identified its milestones and deliveries. ▪ Creating a Gantt Chart - Identify Essential Tasks, Identify Task Relationships and Input Activities into Software or a Template. ▪ Microsoft Project is a project management software program developed and sold by Microsoft, designed to assist a project manager in developing a schedule, assigning resources to tasks, tracking progress, managing the budget, and analyzing workloads. Gantt chart tools make project manager's life easy. Therefore, Gantt chart tools are important for successful project execution. Identifying the level of detail required in the project schedule is the key when selecting a suitable Gantt chart tool for the project. PERT is used when activity times are uncertain. MS Project can help visualize your project plan in standard defined formats. KEYWORDS • Nodes: These are the symbols used to visualize milestones and project tasks. They can be represented by circles or triangles. • Vectors: Visual representation of the sequence of a task, diverging arrows indicate tasks that can be completed at the same time. They can be solid or dotted, depending on the nature of the sequence. • PERT Event: The start or end of a task. • Slack: The amount of time a task can be delayed without causing an overall delay to the project or other tasks, also known as float. • Critical Path: Charts the longest path from beginning to the end of a task or event. 66 CU IDOL SELF LEARNING MATERIAL (SLM)
• Critical Path Activity: An activity with no slack. • Lead Time: How much time you should complete a task or activity without impacting the following ones. • Lag Time: The earliest time in which a task can follow another. • Fast Tracking: Working tasks or activities at the same time. • Crashing Critical Path: Shortening the time of a task. This is the longest path from the starting milestone to the finish. If you experience a delay on the critical path, it will impact the entire project. LEARNING ACTIVTTY 1. Compare PERT and Gantt charts. 2. State practical application of Gantt Chart. UNIT END QUESTIONS A. Descriptive Type Questions 1. Assume the situation where you are hired as Project Manager and you have to apply PERT technique. Outline the details the steps to implement a PERT Chart. 2. Consider a small project that involves the following activities. (a) Determine the expected value and the variance of the completion time for each activity. (b) Use the expected times from (a) to find the critical path. (c) Assuming that the normal distribution applies, determine the probability that the critical path will take between 18 and 26 days to complete. (d) How much time must be allowed to achieve a 90% probability of timely completion? (e)By using modified probability of completion method, what is the probability that all paths will take before 18 weeks? 67 CU IDOL SELF LEARNING MATERIAL (SLM)
3. Explain the use of Gantt chart. Also state its advantage and disadvantage. 4. Explain the steps to create a Gantt chart. Assume any class project and draw the Gantt chart for the same. 5. Write a note on MS Project. B. Multiple Choice Questions 1. PERT analysis is based on a) Optimistic time b) Pessimistic time c) Most likely time d) All the above. 2. Which of the following is not a phase of project management? a) Project planning b) Project scheduling c) Project controlling d) Project being 3. Who introduced the bar charts? a) Williams henry b) Henry Gantt c) Jane Gantt d) Joseph henry 4. In bar charts, which colour is used to show the actual progress? a) Red b) Black c) Blue d) Green 5. The shortest possible time in which an activity can be achieved under ideal circumstances is known as a) Pessimistic time estimate b) Optimistic time estimate c) Expected time estimate d) The most likely time estimate Answers: 68 1 - D; 2 -d; 3 -b; 4 - d; 5 - b CU IDOL SELF LEARNING MATERIAL (SLM)
REFERENCES ▪ Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide)–Sixth Edition Sixth Edition, Sixth edition, Project Management Institute. ▪ Bob Hughes, Mike Cotterell and Rajib Mall, ‘Software Project Management’- Tata McGrawHill. ▪ Bennatan E. (1994).Software Project Management.London: McGraw-Hill. ▪ Anna P. Murray, The Complete Software Project Manager: Mastering Technology from Planning to Launch and Beyond, Wiley. ▪ Robert K. Wysocki, Effective Software Project Management, Wiley. ▪ Andrew and Jennifer, Applied Software Project Management, O’Reilly. ▪ G. L. Rexing, \"Software project management: Moving beyond project plans,\" in AT&T Technical Journal, vol. 70, no. 2, pp. 40-48, March-April 1991. ▪ Marcelo Marinho , Suzana Sampaio , Telma Lima and Hermano de Moura, “A SYSTEMATIC REVIEW OF UNCERTAINTIES IN SOFTWARE PROJECT MANAGEMENT”, in International Journal of Software Engineering & Applications (IJSEA), Vol.5, No.6, November 2014. 69 CU IDOL SELF LEARNING MATERIAL (SLM)
UNIT 5- SOFTWARE QUALITY MANAGEMENT Structure: Learning Objectives Introduction Quality Assurance & Standards Quality Planning Quality control Summary Keywords Learning Activity Unit End Questions References LEARNING OBJECTIVES After studying this unit, you should be able to • Describe the Quality Assurance & Standards. • Explain the concept of Quality Planning. • Explain the Quality control. INTRODUCTION The quality of software has improved significantly over the past two decades. One reason for this is that companies have used new technologies in their software development process such as object-oriented development, CASE tools, etc. In addition, a growing importance of software quality management and the adoption of quality management techniques from manufacturing can be observed. However, software quality significantly differs from the concept of quality generally used in manufacturing mainly for the next reasons 1. The software specification should reflect the characteristics of the product that the customer wants. However, the development organization may also have requirements such as maintainability that are not included in the specification. 2. Certain software quality attributes such as maintainability, usability, reliability cannot be exactly specified and measured. 3. At the early stages of software process it is very difficult to define a complete software specification. Therefore, although software may conform to its specification, users don’t meet their quality expectations. Software quality management is split into three main activities: 1. Quality assurance. The development of a framework of organizational procedures and standards that lead to high quality software. 70 CU IDOL SELF LEARNING MATERIAL (SLM)
2. Quality planning. The selection of appropriate procedures and standards from this framework and adapt for a specific software project. 3. Quality control. Definition of processes ensuring that software development follows the quality procedures and standards. Quality management provides an independent check on the software and software development process. It ensures that project deliverables are consistent with organizational standards and goals. Process and product quality It is general, that the quality of the development process directly affects the quality of delivered products. The quality of the product can be measured and the process is improved until the proper quality level is achieved. illustrates the process of quality assessment based on this approach. Fig 5.1: Process based quality Assessment In manufacturing systems there is a clear relationship between production process and product quality. However, quality of software is highly influenced by the experience of software engineers. In addition, it is difficult to measure software quality attributes, such as maintainability, reliability, usability, etc., and to tell how process characteristics influence these attributes. However, experience has shown that process quality has a significant influence on the quality of the software. Process quality management includes the following activities: 1. Defining process standards. 2. Monitoring the development process. 3. Reporting the software. QUALITY ASSURANCE AND STANDARDS Quality Assurance and standards includes ISO (International Organization of Standardization) and Documentation standards. Quality assurance: 71 CU IDOL SELF LEARNING MATERIAL (SLM)
Quality assurance is the process of defining how software quality can be achieved and how the development organization knows that the software has the required level of quality. The main activity of the quality assurance process is the selection and definition of standards that are applied to the software development process or software product. There are two main types of standards. The product standards are applied to the software product, i.e. output of the software process. The process standards define the processes that should be followed during software development. The software standards are based on best practices and they provide a framework for implementing the quality assurance process. The development of software engineering project standards is a difficult and time consuming process. National and international bodies such as ANSI and the IEEE develop standards that can be applied to software development projects. Organizational standards, developed by quality assurance teams, should be based on these national and international standards. Table shows examples of product and process standards. ISO ISO 9000 is an international set of standards that can be used in the development of a quality management system in all industries. ISO 9000 standards can be applied to a range of organizations from manufacturing to service industries. ISO 9001 is the most general of these standards. It can be applied to organizations that design, develop and maintain products and develop their own quality processes. A supporting document (ISO 9000-3) interprets ISO 9001 for software development. The ISO 9001 standard isn’t specific to software development but includes general principles that can be applied to software development projects. The ISO 9001 standard describes various aspects of the quality process and defines the organizational standards and procedures that a company should define and follow during product development. These standards and procedures are documented in an organizational quality manual. The ISO 9001 standard does not define the quality processes that should be used in the development process. Organizations can develop own quality processes and they can still be ISO 9000 compliant companies. The ISO 9000 standard only requires the definition of processes to be used in a company and it is not concerned with ensuring that these processes provide best practices and high quality of products. Therefore, the ISO 9000 certification doesn’t means exactly that the quality of the software produced by an ISO 9000 certified companies will be better than that software from an uncertified company. Documentation standards Documentation standards in a software project are important because documents can represent the software and the software process. Standardized documents have a consistent appearance, structure and quality, and should therefore be easier to read and understand. There are three types of documentation standards: 1. Documentation process standards. These standards define the process that should be followed for document production. 72 CU IDOL SELF LEARNING MATERIAL (SLM)
Safety Understandability Portability Security Testability Usability Reliability Adaptability Reusability Resilience Modularity Efficiency Robustness Complexity Learnability Maintainability 2. Document standards. These standards describe the structure and presentation of documents. 3. Documents interchange standards. These standards ensure that all electronic copies of documents are compatible. QUALITY PLANNING Quality planning is the process of developing a quality plan for a project. The quality plan defines the quality requirements of software and describes how these are to be assessed. The quality plan selects those organizational standards that are appropriate to a particular product and development process. Quality plan has the following parts: 1. Introduction of product. 2. Product plans. 3. Process descriptions. 4. Quality goals. 5. Risks and risk management. The quality plan defines the most important quality attributes for the software and includes a definition of the quality assessment process. how’s generally used software quality attributes that can be considered during the quality planning process. Table:5.1 Software quality attributes QUALITY CONTROL ✓ Quality reviews Quality control provides monitoring the software development process to ensure that quality assurance procedures and standards are being followed. The deliverables from the software development process are checked against the defined project standards in the quality control process. The quality of software project deliverables can be checked by regular quality reviews and/or automated software assessment. Quality reviews are performed by a group of people. They review the software and software process in order to check that the project standards have been followed and that software and documents conform to these standards. 73 CU IDOL SELF LEARNING MATERIAL (SLM)
Review type Principal purpose Design or program To detect detailed errors in the requirements, design or code. inspections Progress reviews To provide information for management about the overall progress of the project. Quality reviews To carry out a technical analysis of product components or documentation to find mismatches between the specification and the component design, code or documentation and to ensure that defined quality standards of the organization have been followed. Automated software assessment processes the software by a program that compares it to the standards applied to the development project. Quality reviews Quality reviews are the most widely used method of validating the quality of a process or product. They involve a group of people examining part or all of a software process, system, or its associated documentation to discover potential problems. The conclusions of the review are formally recorded and passed to the author for correcting the discovered problems describes several types of review, including quality reviews. Table 5.2: Types of review SUMMARY Software Quality Management is a process that ensures the required level of software quality is achieved when it reaches the users, so that they are satisfied by its performance. The process involves quality assurance, quality planning, and quality control. Software Quality Management ensures that the required level of quality is achieved by submitting improvements to the product development process. SQA aims to develop a culture within the team and it is seen as everyone's responsibility. Software Quality management should be independent of project management to ensure independence of cost and schedule adherences. It directly affects the process quality and indirectly affects the product quality. Activities of Software Quality Management: • Quality Assurance - QA aims at developing Organizational procedures and standards for quality at Organizational level. • Quality Planning - Select applicable procedures and standards for a particular project and modify as required to develop a quality plan. 74 CU IDOL SELF LEARNING MATERIAL (SLM)
• Quality Control - Ensure that best practices and standards are followed by the software development team to produce quality products. KEYWORDS • Quality assurance is the process of defining how software quality can be achieved and how the development organization knows that the software has the required level of quality. • ISO 9000 is an international set of standards that can be used in the development of a quality management system in all industries. • Documentation process standards. These standards define the process that should be followed for document production. • Document standards. These standards describe the structure and presentation of documents. • Documents interchange standards. These standards ensure that all electronic copies of documents are compatible. LEARNING ACTIVITY 1. Give examples of product and process standards? 2. What international standards can be used in software quality assessment? UNIT END QUESTIONS A. Descriptive Type Questions 1. Explain Process and product quality. 2. What is Quality Assurance? 3. Discuss that with good SQM (Software Quality Management) in place, product performance will be checked along the way to ensure that all standards are being followed. 4. Why it is important that Quality planning involves the creation of goals and objectives for the software, as well as the creation of a strategic plan that will help to successfully meet the designed objectives. 5. Illustrate the step of SQM (Software Quality Management) where testing finally comes into play. 75 CU IDOL SELF LEARNING MATERIAL (SLM)
B. Multiple Choice Questions 1. Which requirements is the foundation from which quality is measured? a) Hardware b) Software c) Programmers d) None of the mentioned 2. Degree to which design specifications are followed in manufacturing the product is called a) Quality Control b) Quality Assurance c) Quality of conformance d) None of the mentioned 3. Which of the following is not a SQA plan for a project? a) evaluations to be performed b) amount of technical work c) audits and reviews to be performed d) documents to be produced by the SQA group 4. Who identifies, documents, and verifies that corrections have been made to the software? a) Project manager b) Project team c) SQA group d) All of the mentioned 5. What is not included in prevention costs? a) quality planning b) formal technical reviews c) test equipment d) equipment calibration and maintenance Answers: 1 - b; 2 - c; 3 - b; 4 -c; 5 -d REFERENCES ▪ Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide)–Sixth Edition Sixth Edition, Sixth edition, Project Management Institute 76 CU IDOL SELF LEARNING MATERIAL (SLM)
▪ Bob Hughes, Mike Cotterell and Rajib Mall, ‘Software Project Management’- Tata McGrawHill. ▪ Bennatan E. (1994).Software Project Management.London: McGraw-Hill. ▪ Phillip Bruce , Sam M. Pederson The Software Development Project: Planning and Management, Wiley ▪ Mark C. Layton , Agile Project Management For Dummies , John Wiley & Son ▪ Pressman R.S. (2009). Software Engineering - A Practitioner’s Approach. New Delhi: MGH Publications ▪ G. L. Rexing, \"Software project management: Moving beyond project plans,\" in AT&T Technical Journal, vol. 70, no. 2, pp. 40-48, March-April 1991. ▪ Marcelo Marinho , Suzana Sampaio , Telma Lima and Hermano de Moura, “A SYSTEMATIC REVIEW OF UNCERTAINTIES IN SOFTWARE PROJECT MANAGEMENT”, in International Journal of Software Engineering & Applications (IJSEA), Vol.5, No.6, November 2014. 77 CU IDOL SELF LEARNING MATERIAL (SLM)
UNIT 6- SOFTWARE TESTING Structure Learning Objectives Introduction Role of testing in Software development Testing Procedure Defect Management Summary Keywords Learning Activity Unit End Questions References LEARNING OBJECTIVES After studying this unit, you should be able to • Explain the Role of testing in Software development. • Outline the Testing Procedure. • Describe the Defect Management. INTRODUCTION Testing is the process of evaluating a system or its component(s) with the intent to find whether it satisfies the specified requirements or not. In simple words, testing is executing a system in order to identify any gaps, errors, or missing requirements in contrary to the actual requirements. According to ANSI/IEEE 1059 standard, Testing can be defined as - A process of analyzing a software item to detect the differences between existing and required conditions (that is defects/errors/bugs) and to evaluate the features of the software item. Software Testing is important because if there are any bugs or errors in the software, it can be identified early and can be solved before delivery of the software product. Properly tested software product ensures reliability, security and high performance which further results in time saving, cost effectiveness and customer satisfaction. Testing is important because software bugs could be expensive or even dangerous. ROLE OF TESTING IN SOFTWARE DEVELOPMENT Here are the benefits of using software testing: 78 CU IDOL SELF LEARNING MATERIAL (SLM)
• Cost-Effective: It is one of the important advantages of software testing. Testing any IT project on time helps you to save your money for the long term. In case if the bugs caught in the earlier stage of software testing, it costs less to fix. • Security: It is the most vulnerable and sensitive benefit of software testing. People are looking for trusted products. It helps in removing risks and problems earlier. • Product quality: It is an essential requirement of any software product. Testing ensures a quality product is delivered to customers. • Customer Satisfaction: The main aim of any product is to give satisfaction to their customers. UI/UX Testing ensures the best user experience. Software Development Life Cycle Model There are different types of Software Development Life Cycle models and every model is used in testing stage. So, its create testing a very essential element in any SDLC. With the help of different type of testing (e.g. assimilation tests, element testing, user recognition testing system testing and regression tests etc.) coder may produce a consistent and reliable application. Testing also includes some process e.g. test analysis, test plan, test design and test execution. In any system networks, server system is measured as principal terminal and other procedure are known to be minor terminals. So, SDLC includes principal station and minor station for its approach of statement. Minor station has its own address and they are devoted to general port. SDLC is used for end to end communication and also for various isolated connections. There is lots of main equipment linked with SDLC. It is measured as the base of normal data connected model in ISO, esteemed information connection rules. SDLC are very well- organized models and used in well matched network with its own confidential appearance. Most Importance of Testing in SDLC (Software Development Life cycle): In SDLC stage there are some most importance things as described below: • Recognition of Error and Faults Testing step is one step which resolves the errors and faults in the software application. These errors may be in unit level or in system level. After going through so many testing the application will be free of errors that may be disturbing the application. • Statistics to Shareholders and Status of Organization Testing stage helps to know the condition of product and work standards. The stakeholders get better data through testing stage about utility value too. • Enhancement in Product Standards Testing can help to know the real result and the probable result. It also helps to pick up the standards of the software. With proper testing an application can come out of bugs and build up ideal software for the end-users. • Technical Significance 79 CU IDOL SELF LEARNING MATERIAL (SLM)
Testing segment is significant for technical characteristics of any SDLC, as the software then completed with technically satisfied. • To Succeed of any Contentious Programmers Ideal testing functions and tools aid to evolve up the product in business and keep programmers away from the other contestant. Going though all stages of testing, the software application will be more bugs free, protected and technically sound. • Free from any Risk Whenever going to develop any software, testing is an essential part. When develop software without any testing then it may cause lots of risks to the end users. To free everyone from any risk, it is essential that to go under all testing stages. • Enhanced Standards Appropriate tested application provides additional assurance of build up with best software. Moreover, it refines standards of application as incessant and all types of testing stages have prepared a protected and harmless software application that could be worn by the end users. • Confirmation and Corroboration One of the major targets of testing stage in SDLC is for confirmation and corroboration. Testing is greatly used in confirmation and corroboration method. Depending on the result we can compare among standards of several software application. • Credibility Evaluation Testing stage also insist this important issue. If the software application has gone through all the testing types (like unit testing, regression testing etc.), the application will surely be a reliable one. So, testing evaluate credibility of software application. Testing provides the greatest analytical process to give equipped testing on product ensuing in a credible product. • Demonstrate Accessibility and Feasibility One of the most significant targets of testing is to demonstrate the product is both accessible and functional. Accessibility testing is where the application is delivering to a select assembly of users and their functioning with the application is noticed. All type of a user's communication with the application, like easiness of applies and whenever users are getting troubles, are preserved and examined. • Avoid Fault Immigration In the first stage of SDLC, most of the faults have been found. If the faults can be noticed earlier, then these may be prohibited from immigrating to the following progress stage. If the errors could be discover previously then the saving of software development cost will be vast. • Commercial Significance A full tested software application will have excellent business aspects. As all are like to work with reliable and trusted application in commercial. 80 CU IDOL SELF LEARNING MATERIAL (SLM)
TESTING PROCEDURE The general testing process starts with the testing of individual program units such as functions or objects. The aim of the component testing is to discover defects by testing individual program components. Components are usually integrated to form sub-systems and finally to the complete system. System testing focuses on establishing that the sub-system or the complete system meet its functional and non-functional requirements, and does not behave in unexpected ways. Component testing by developers is based on understanding of how the components should operate using test data. However, system testing is rigorously based on written system specifications The software testing process has the following main goals: 1. To demonstrate that the software meets its requirements. This means that there should be at least one test for every user and system requirements. 2. To discover faults or defects in the software. The objective of defect testing is the exploration and elimination of all kinds of undesirable system behaviour, such as system crashes, unwanted interactions with other systems, incorrect computations and data corruption. The first goal is called validation testing. In this case the system is tested by a given set of test cases that reflect the system’s expected use. For validation testing, a test is considered to be successful if the system performs correctly. The second goal leads to defect testing, where the test cases are designed to expose defects. In this case, a successful test is one that exposes a defect that causes the system to perform incorrectly. Fig 6.1: A model of software testing process A general model of the testing process is shown in Figure 6.1. Test cases are specifications of the inputs to the test, the expected output from the system and a statement of what is being tested. Test data are the inputs that have been created to test the system. Testing is based on a subset of possible test cases. 81 CU IDOL SELF LEARNING MATERIAL (SLM)
Unit testing ✓ Interface testing Unit testing tests the individual components in the system. It is a defect testing process so its purpose is to locate faults in these components. In most cases, the developers of components are responsible for component testing. The components may be tested at unit testing are the followings: 1. Object classes, functions or methods within an object. 2. Composite components that are consist of several different objects or functions. The composite components have a defined interface that can be used to access their functionality. Functions or methods are tested by a set of calls to these routines with different input parameters. In the case of testing object classes the tests have to cover all of the features of the object. Object class testing includes the following tests: 1. The testing all operations associated with the object 2. The testing adjustability of all attributes associated with the object 3. The testing all possible states of the object. This means that all events that cause a state change in the object have to be simulated. In the case of inheritance the tests of object classes are more difficult. Where a superclass provides operations that are inherited by a number of subclasses, all of these subclasses should be tested with all inherited operations. Interface testing In a software system many components are not simple functions or objects but they are composite components that consist of several interacting objects. The functionality of these components can be accessed through their defined interface. Testing these composite components is primarily concerned with testing the interface of the composite component created by combining these components. Interface testing is important for object-oriented and component-based development. Objects and components are defined by their interfaces and may be reused in combination with other components in different systems. System testing ✓ Integration testing ✓ Functional testing ✓ Performance testing System testing involves integrating two or more components that implement any system functions or features and then testing this integrated system. In an iterative development process, system testing is concerned with testing an increment to be delivered to the customer. In the case of a waterfall development process, system testing is concerned with testing the entire system. Therefore, system testing may have two distinct phases: 82 CU IDOL SELF LEARNING MATERIAL (SLM)
1. Integration testing. After integrating a new component the integrated system is tested. When a problem is discovered, the developers try to find the source of the problem and identify the components that have to be debugged. 2. Functional testing. The version of the system that could be released to users is tested. Here, the main objective is to validate the system that it meets its requirements and ensure that the system is dependable. Where customers are involved in release testing, this is called acceptance testing. If the release is good enough, the customer may then accept it for use. Fundamentally, the integration testing is considered as the testing of incomplete systems composed of clusters or groupings of system components. Functional testing is concerned with testing the system release that is intended for delivery to customers. Generally, the priority in integration testing is to discover defects in the system and the priority in system testing, is to validate that the system meets its requirements. Integration testing The process of system integration involves building a system from its components and testing the resultant system for problems that arise from component interactions. Integration testing checks how these components work together across their interfaces. System integration integrates clusters of components that deliver some system functionality and integrating these by adding code that makes them work together. Sometimes, the overall skeleton of the system is developed first, and components are added to it. This is called top- down integration. Alternatively, the infrastructure components are integrated first providing common services, such as network and database access, and functional components added after. This is bottom-up integration. In order to locate errors easier an incremental approach to the system integration and testing is suggested. Initially, a minimal system .configuration should be integrated and tested. Then the new components are added to this minimal configuration and tested after each added increment. If any problem arises in these tests, this probably means that they are due to interactions with the new component. Before the process of integration, it is necessary to decide the order of integration of components. Usually, system integration is driven by customer priorities. When the customer is not involved in the developments, the components that have the most frequently used functionality are integrated first. Integrating and testing a new component can change the already tested component interactions. Errors may occur that were not exposed in the tests of the simpler configuration. This means that when a new increment is integrated, it is important to rerun the tests for previous increments as well. Rerunning an existing set of tests is called regression testing. 83 CU IDOL SELF LEARNING MATERIAL (SLM)
Functional testing A release of the software is its final version that will be distributed to customers. The objective of release testing is to show that the software product delivers the specified functionality, performance and dependability, and that it does not fail during normal use. Another name of release testing is functional testing because it is only concerned with the functionality and not the implementation of the software. Release testing is usually a black-box testing process where the tests are derived from the system specification. Figure6.1 shows the model of black-box testing. The testing process presents inputs to the component or the system and examines the corresponding outputs. If the outputs are not those predicted, i.e. if the outputs are in set Oe, then the test has detected a problem with the software. Fig 6.1: Black Box Testing model During release testing, software is often tested by choosing test cases that are in the set Ie in Figure. These inputs have a high probability of generating system failures i.e. outputs in set Oe. To validate that the system meets its requirements, the best approach to use is scenario-based testing, where test cases are developed from scenarios. Usually, the most likely scenarios are tested first, and unusual or exceptional scenarios considered later. If use-cases are used to describe the system requirements, these use-cases and associated sequence diagrams can be a basis for system testing. 84 CU IDOL SELF LEARNING MATERIAL (SLM)
Performance testing The objective of performance tests is to ensure that the system can process its intended load. An effective way to discover defects is the stress testing, i.e. to design tests around the limits of the system. In performance testing, this means stressing the system by making demands that are over the design limits of the software. Stress testing has two functions: 1. It tests the failure behaviour of the system under circumstances where the load placed on the system exceeds the maximum load. 2. It continuously stresses the system and may cause such defects that would not normally be discovered. DEFECT MANAGEMENT Think of a defect as a deviation from expected software behavior. In other words, if a website or app is functioning differently from what users would expect from it, that particular variation would be considered a defect. In software testing circles, the term defect is often used interchangeably with a bug. However, there is a technical difference. A bug is a defect that results from an error or some issue in code. This is not true for all defects. Features of Defect Management • Defect Identification One cannot manage bugs that one cannot see. Testers have to start with identifying every single defect in a website or app. Bear in mind that the only way to detect every defect is to test software in real user conditions. Don’t bother with emulators or simulators because they cannot provide 100% accurate results, and therefore testers and QA managers won’t be able to evaluate the testing process with precision. Testers are bound to miss bugs without testing on real browsers and devices. Testing teams must find as many defects as possible so that they can be acknowledged, categorized, and resolved by developers. In order to identify and categorize defects, it is important to have a singular, accessible system that all testers can have at hand to see. When choosing among defect management tools, look for these features in particular. • Defect Categorization Once defects have been identified, ensure that the right defect data has been captured. Quality of data allows testers and developers to fix exactly what went wrong in the least amount of time. Don’t collect too much data, because developers don’t have the time to comb through mountains of information to figure out what they need to work on. 85 CU IDOL SELF LEARNING MATERIAL (SLM)
The correct information that needs to be recorded with regard to each defect should include 1. Description 2. Bug Severity 3. Cost of fixing 4. Feature in which defect was identified 5. Name of the tester who identified the defect 6. Defect type 7. Revision and release deadlines There are multiple stages in a bug’s lifespan – 1. Active: Bug is being investigated 2. Test: The bug has been fixed and the debugged software is ready to be tested 3. Verified: The bug has been re-tested and approved by QA engineer 4. Closed: Bug has been resolved completely Bugs must be managed according to priority and severity; these levels identify how much of an impact a bug has on a product. Generally speaking, severity levels can be categorized into the following: 1. Low: Bug won’t result in any noticeable breakdown of the system 2. Minor: Results in some unexpected or undesired behavior, but not enough to disrupt system function 3. Major: Bug capable of collapsing large parts of the system 4. Critical: Bug capable of triggering complete system shutdown • Defect Resolution Now that bugs have been identified and relevant information has been recorded, informed decisions can be made about resolving each defect. Naturally, fixing errors early on in the process help save cost and effort because errors tend to magnify as the software becomes more complex. Action in this regard needs the following steps: 1. Allocation: Each bug is allocated to a developer (ideally the one responsible for creating the software). Remember to change bug status so that the entire team knows that a defect is being dealt with. Create a schedule to fix the entire repertoire of defects based on defect priority. 2. Resolution: As devs work on fixing defects, Test Managers track the process in relation to the aforementioned schedule. 3. Reporting: Managers receive reports from developers about resolved bugs and update their status on the database by marking them Closed. Defect Analysis 86 CU IDOL SELF LEARNING MATERIAL (SLM)
Now that defects have been detected, categorized, and resolved, step back and take a look at the big picture. Defect analysis takes into account inputs about singular defects as well as defect priorities, product issues, defect resolution history, developers involved, and the like. Defect analysis plays an important role in preventing the recurrence of similar errors in subsequent projects. Collect the critical error data and the corresponding correction action, and share the learnings with relevant teams. This might help direct future development practices to avoid defects in the first place or help to refine resolution methods so that bugs can be fixed faster. Both self and peer reviews are powerful tools for learning and motivation. If the QA process supports defect analysis, it almost always translates to a better functioning team that aims towards the Holy Grail of zero defects. Put analysis in place as a mandatory part of defect management in software testing. As Elon Musk put it “I think that’s the single best piece of advice: constantly think about how you could be doing things better and questioning yourself.” Defect Metrics A couple of important metrics are helpful when it comes to measuring and gauging the quality of test execution. This, in turn, helps determine the nature and quality of the defect management process in software testing. 1. Defect Rejection Ratio: (Number of defects rejected/Total number of defects detected) X 100 2. Defect Leakage Ratio: (Number of defects missed/Total number of defects detected) X 100 The smaller the value of both metrics is, the better is the quality of test execution. SUMMARY ▪ Here are five the most essential software testing objectives: ▪ Bug Prevention. QA engineers prevent defects in a system at the earliest stage of development. The bug-prevention objective is superior to others and implies not only anticipation but also prevention of defects from recurring in the future. In the long run, bug prevention helps to shorten the product time to market, reduce the cost of software quality maintenance and increase the customer satisfaction and loyalty to your product. ▪ Bug Detection. QA experts detect and root out bugs and malfunctions before customers find them. It’s a short-term objective that requires a scrutinous approach which can be provided by manual software testing. ▪ User Satisfaction. QA team make sure that the product satisfies the user requirements and works as desired. In the process of the software verification & validation, a tester usually writes a set of test cases which help to determine the software compliance with specific business and user requirements under positive and negative conditions. For instance, our 87 CU IDOL SELF LEARNING MATERIAL (SLM)
team establishes the set of tests to ensure the main functions and features cover different scenarios, work properly in a range of countries and locations. ▪ Software quality and reliability. Keeping control of software quality and reliability. Keeping control of software quality means keeping bugs at a low level and making sure software is compatible. Software compatibility is the capability of a software or an app to work well with other hardware, software or network, including web, desktop, mobile platform types, all types of operating systems and web browsers, etc. ▪ Recommendations. QA team provides suggestions for software improvements. A good software testing provider should not only tell the difference between the actual and expected result but also make suggestions on how to improve this or that software element performance from the user perspective. In particular, the team might recommend how to make the app more intuitive for customers as well as provide with simpler ways of software development. ▪ Information for stakeholders. As we’ve already mentioned on this list of objectives of software testing, QA activities provide insights about technical restrictions, risk factors, ambiguous requirements, etc. All these aspects, in their turn, affect promotion and sales strategy. While a QA team has the best understanding of the product, they only document bugs and suggest what areas to improve. Meanwhile, sharing testing reports with stakeholders is what actually allows making changes when they are necessary. ▪ Confidence in the product. As follows from the previous point, decision-makers get sufficient information about the product highlights and areas that require increased attention. Thus, product owners can gain confidence in the product before the launch or decide to release its less stunning but more stable version. In both cases, they operate with facts and don’t indulge in wishful thinking. KEYWORDS • Testing is the process of evaluating a system or its component(s) with the intent to find whether it satisfies the specified requirements or not. • Defective testing: To discover faults or defects in the software. • Inputs: what is put in, taken in, or operated on by any process or system. • Exceptions: a person or thing that is excluded from a general statement or does not follow a rule. • Peer Review: evaluation of scientific, academic, or professional work by others working in the same field. LEARNING ACTIVITY 1. What is the different between integration and functional testing? 88 CU IDOL SELF LEARNING MATERIAL (SLM)
2. What is the different between release and acceptance testing? UNIT END QUESTIONS A. Descriptive Type Questions 1. How Testing is an important aspect of maintaining quality and customer satisfaction? 2. Compare Software Development Life cycle and Software Testing. 3. As a Project Manager you are handling launch of new banking software for your client. But before the launch, the software is getting hanged, so what steps you will take immediately. 4. Illustrate the relation between Software Testing and Software Project Management. 5. Justify the statement - ‘One cannot manage bugs that one cannot see’. B. Multiple Choice Questions 1. Which of the following term describes testing? a) Finding broken code b) Evaluating deliverable to find errors c) A stage of all projects d) None of the mentioned 2. Exhaustive testing is a) always possible b) practically possible c) impractical but possible d) impractical and impossible 3. What are the various Testing Levels? a) Unit Testing b) System Testing c) Integration Testing d) All of the mentioned 4. Boundary value analysis belong to? 89 a) White Box Testing b) Black Box Testing CU IDOL SELF LEARNING MATERIAL (SLM)
c) White Box & Black Box Testing d) None of the mentioned 5. Which of the following is non-functional testing? a) Black box testing b) Performance testing c) Unit testing d) None of the mentioned Answers: 1 -b; 2 - c; 3 -d; 4 - b; 5 -b REFERENCES ▪ Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide)–Sixth Edition Sixth Edition, Sixth edition, Project Management Institute ▪ Bob Hughes, Mike Cotterell and Rajib Mall, ‘Software Project Management’- Tata McGrawHill. ▪ Bennatan E. (1994).Software Project Management.London: McGraw-Hill. ▪ Greg Horine, Project Management Absolute Beginner's Guide (3rd Edition), Que Publishing. ▪ Fairley Richard (2017). Software Engineering Concepts. New Delhi: McGraw-Hill. ▪ KelkarS.A. (2004). Software Project Management: A Concise Study. New Delhi: Prentice Hall India Pvt. Limited. ▪ G. L. Rexing, \"Software project management: Moving beyond project plans,\" in AT&T Technical Journal, vol. 70, no. 2, pp. 40-48, March-April 1991. ▪ Marcelo Marinho , Suzana Sampaio , Telma Lima and Hermano de Moura, “A SYSTEMATIC REVIEW OF UNCERTAINTIES IN SOFTWARE PROJECT MANAGEMENT”, in International Journal of Software Engineering & Applications (IJSEA), Vol.5, No.6, November 2014. 90 CU IDOL SELF LEARNING MATERIAL (SLM)
UNIT 7- CONFIGURATION MANAGEMENT Structure Learning Objectives Introduction CM planning Change Management Release Management Version management Configuration Management Tools Summary Keywords Learning Activity Unit End Questions References LEARNING OBJECTIVES After studying this unit, you should be able to • Explain CM (Configuration Management) planning. • Outline the concept of Change Management. • Distinguish between Version and Release Management. • Identify the Configuration Management Tools. INTRODUCTION When we develop software, the product (software) undergoes many changes in their maintenance phase; we need to handle these changes effectively. Several individuals (programs) works together to achieve these common goals. This individual produces several work product (SC Items) e.g., Intermediate version of modules or test data used during debugging, parts of the final product. The elements that comprise all information produced as a part of the software process are collectively called a software configuration. As software development progresses, the number of Software Configuration elements (SCI's) grow rapidly. These are handled and controlled by SCM. This is where we require software configuration management. A configuration of the product refers not only to the product's constituent but also to a particular version of the component. Therefore, SCM is the discipline which o Identify change o Monitor and control change o Ensure the proper implementation of change made to the item. 91 CU IDOL SELF LEARNING MATERIAL (SLM)
o Auditing and reporting on the change made. Configuration Management (CM) is a technique of identifying, organizing, and controlling modification to software being built by a programming team. The objective is to maximize productivity by minimizing mistakes (errors). CM is used to essential due to the inventory management, library management, and updating management of the items essential for the project. Importance of SCM (Software Configuration Management) It is practical in controlling and managing the access to various SCIs e.g., by preventing the two members of a team for checking out the same component for modification at the same time. It provides the tool to ensure that changes are being properly implemented. It has the capability of describing and storing the various constituent of software. SOFTWARE CONFIGURATION MANAGEMENT PLAN The SCMP (Software Configuration management planning) process planning begins at the early coding phases of a project. The outcome of the planning phase is the SCM plan which might be stretched or revised during the project. • The SCMP can follow a public standard like the IEEE 828 or organization specific standard • It defines the types of documents to be management and a document naming. Example Test_v1 • SCMP defines the person who will be responsible for the entire SCM process and creation of baselines. • Fix policies for version management & change control • Define tools which can be used during the SCM process • Configuration management database for recording configuration information. “The configuration management plan defines those items that are configurable, those items that are require formal change control, & the process for controlling changes to such items.” Configuration Planning tells us the following: • What all project items are configurable (Configurable Items CIs) • Which all items (say Scope Statement, WBS Dictionary) needs, formal change control • And, what would be the process of controlling changes to these items? 92 CU IDOL SELF LEARNING MATERIAL (SLM)
Configuration Management Plan also recommends: • A tool to manage Configurable Items, • A versioning scheme. For example, a Document Version will have two segments like aa, bb, cc, dd. The first segment will represent the product; the second will represent deliverable, etc. In the configuration management plan, we define a clear versioning system. It helps in the identification of baseline CIs. Like, when we have many version of Project Scope Statement, it helps to get a baseline version of Project Scope Statement. Also, a Configuration management plan may go beyond project boundaries. Since the product we are developing may already be in existence before the project commenced. And it may also remain in existence after the project is over. A product life cycle may include many project lives cycles. In some cases, configuration management system is highly influenced by the product level configurations. And, we end up having two views of configuration management – • Product Level configuration – Like product related artefacts e.g. product user manual. These have to be maintained by their subsequent project also. • Project level configuration – Like WBS dictionary, project management plan etc. To summarize, the entire Configuration Management process can be viewed as: • It’s all about ensuring that we do not get into the pile of documents. Where we do not know which one is the right version and which document is compatible with the other • Configuration management manages configurable items. In the typical project configuration; items are made of baseline plans and project documents. The items like operating procure, instruction sheets may also become a part of configurable items • CMS also takes care about how are we going to record changes? Which system are we going to use? For how long we want to maintain history? Like a history of 5 years, six years, etc. • For Project Management Professional (PMP)® Exam, do keep in mind that the configuration management activities (Configuration identification, Configuration status accounting, and Configuration verification and audit) are done in Perform Integrated Change Control Software systems are constantly changing during development and use. Configuration management (CM) is concerned with the policies, processes and tools for managing changing software systems. You need CM because it is easy to lose track of what changes and component versions have been incorporated into each system version. CM is essential for team projects to control changes made by different developers. 93 CU IDOL SELF LEARNING MATERIAL (SLM)
Configuration management activities • Version management: Keeping track of the multiple versions of system components and ensuring that changes made to components by different developers do not interfere with each other. • System building: The process of assembling program components, data and libraries, then compiling these to create an executable system. • Change management: Keeping track of requests for changes to the software from customers and developers, working out the costs and impact of changes, and deciding the changes should be implemented. • Release management: Preparing software for external release and keeping track of the system versions that have been released for customer use. Fig 7.1 : Configuration Management Activities Agile development, where components and systems are changed several times per day, is impossible without using CM tools. The definitive versions of components are held in a shared project repository and developers copy these into their own workspace. They make changes to the code then use system building tools to create a new system on their own computer for testing. Once they are happy with the changes made, they return the modified components to the project repository. A development phase is where the development team is responsible for managing the software configuration and new functionality is being added to the software. A system testing phase is where a version of the system is released internally for testing. No new system functionality is added. Changes made are bug fixes, performance improvements and security vulnerability repairs. A release phase where the software is released to customers for use. New versions of the released system are developed to repair bugs and vulnerabilities and to include new features. 94 CU IDOL SELF LEARNING MATERIAL (SLM)
For large systems, there is never just one 'working' version of a system. There are always several versions of the system at different stages of development. There may be several teams involved in the development of different system versions. Fig 7.2: Development of different system versions CHANGE MANAGEMENT Organizational needs and requirements change during the lifetime of a system, bugs have to be repaired and systems have to adapt to changes in their environment. Change management is intended to ensure that system evolution is a managed process and that priority is given to the most urgent and cost-effective changes. The change management process is concerned with analyzing the costs and benefits of proposed changes, approving those changes that are worthwhile and tracking which components in the system have been changed. Factors in change analysis: • The consequences of not making the change • The benefits of the change • The number of users affected by the change • The costs of making the change • The product release cycle In some agile methods, customers are directly involved in change management. The propose a change to the requirements and work with the team to assess its impact and decide whether the change should take priority over the features planned for the next increment of the system. Changes to improve the software improvement are decided by the programmers working on the system. Refactoring, where the software is continually improved, is not seen as an overhead but as a necessary part of the development process. 95 CU IDOL SELF LEARNING MATERIAL (SLM)
Benefits of configuration and change management for servers • It helps to maintain the consistency of the servers. • It increases efficiency since most of the processes are automated as opposed to manual processes. • It makes it easy to scale infrastructure without having to scale staff since the processes are automated. • It reduces the chances of errors since most of the processes are automated and do not require human interference. • It saves cost for staffing and repair of the server in the case of failure and the need to repair or set up the server again manually. • It ensures that the server can be easily brought back up in case of system downtime since there is a baseline for the server configurations and a record of all changes reports for the server. Difference between configuration and change management The major change between configuration and change management is that configuration management focuses on managing the configurable items and the state of the system while change management focuses on managing the changes that affect the configurable items and the system. Overlaps between change management and configuration management IT admins can only truly understand how a change affects any given system with configuration management. With all the configuration items and their dependencies mapped, it's easier to decipher the systems and components a change has affected. Not all configuration items are systems, either. Documentation can be a form of configuration item. Therefore, track and understand a change to a process -- or process ownership -- to better identify when a change goes wrong and where documentation needs an update. In this way, information within a configuration item directly influences how IT teams implement a change. RELEASE MANAGEMENT A system release is a version of a software system that is distributed to customers. For mass market software, it is usually possible to identify two types of release: major releases which deliver significant new functionality, and minor releases, which repair bugs and fix customer problems that have been reported. For custom software or software product lines, releases of the system may have to be produced for each customer and individual customers may be running several different releases of the system at the same time. As well as the lives executable code of the system, a release may also include: • Configuration files defining how the release should be configured for particular installations; 96 CU IDOL SELF LEARNING MATERIAL (SLM)
• Data files, such as files of error messages, that are needed for successful system operation; • An installation program that is used to help install the system on target hardware; • Electronic and paper documentation describing the system; • Packaging and associated publicity that have been designed for that release. Factors influencing system release planning: • Competition For mass-market software, a new system release may be necessary because a competing product has introduced new features and market share may be lost if these are not provided to existing customers. • Marketing requirements the marketing department of an organization may have made a commitment for releases to be available at a particular date. • Platform changes You may have to create a new release of a software application when a new version of the operating system platform is released. • Technical quality of the system If serious system faults are reported which affect the way in which many customers use the system, it may be necessary to issue a fault repair release. Minor system faults may be repaired by issuing patches (usually distributed over the Internet) that can be applied to the current release of the system. Release creation process: • The executable code of the programs and all associated data files must be identified in the version control system. • Configuration descriptions may have to be written for different hardware and operating systems. • Update instructions may have to be written for customers who need to configure their own systems. • Scripts for the installation program may have to be written. • Web pages have to be created describing the release, with links to system documentation. • When all information is available, an executable master image of the software must be prepared and handed over for distribution to customers or sales outlets. Release tracking In the event of a problem, it may be necessary to reproduce exactly the software that has been delivered to a particular customer. When a system release is produced, it must be documented to ensure that it can be re-created exactly in the future. This is particularly important for customized, long-lifetime embedded systems, such as those that control complex machines. Customers may use a single release of these systems for many years and may require specific changes to a particular software system long after its original release date. 97 CU IDOL SELF LEARNING MATERIAL (SLM)
Release reproduction to document a release, you have to record the specific versions of the source code components that were used to create the executable code. You must keep copies of the source code files, corresponding executables and all data and configuration files. You should also record the versions of the operating system, libraries, compilers and other tools used to build the software. Release planning As well as the technical work involved in creating a release distribution, advertising and publicity material have to be prepared and marketing strategies put in place to convince customers to buy the new release of the system. If releases are too frequent or require hardware upgrades, customers may not move to the new release, especially if they have to pay for it. If system releases are too infrequent, market share may be lost as customers move to alternative systems. Delivering software as a service (SaaS) reduces the problems of release management. It simplifies both release management and system installation for customers. The software developer is responsible for replacing the existing release of a system with a new release and this is made available to all customers at the same time. VERSION MANAGEMENT Version management (VM) is the process of keeping track of different versions of software components or configuration items and the systems in which these components are used. It also involves ensuring that changes made by different developers to these versions do not interfere with each other. Therefore, version management can be thought of as the process of managing code lines and baselines. A code line is a sequence of versions of source code with later versions in the sequence derived from earlier versions. code lines normally apply to components of systems so that there are different versions of each component. A baseline is a definition of a specific system. The baseline therefore specifies the component versions that are included in the system plus a specification of the libraries used, configuration files, etc. Baselines may be specified using a configuration language, which allows you to define what components are included in a version of a particular system. Baselines are important because you often have to recreate a specific version of a complete system. For example, a product line may be instantiated so that there are individual system versions for different customers. You may have to recreate the version delivered to a specific customer if, for example, that customer reports bugs in their system that have to be repaired. Version control (VC) systems identify, store and control access to the different versions of components. There are two types of modern version control system. Centralized systems, where there is a single master repository that maintains all versions of the software components that are being developed. Subversion is a widely used example of a centralized 98 CU IDOL SELF LEARNING MATERIAL (SLM)
Search
Read the Text Version
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
