Download The Project Management-Methods Of Software Engineering-Lecture Notes and more Study notes Software Engineering in PDF only on Docsity!
The Product: Defining the Problem
In order to develop an estimate and plan for the project, the scope of the problem must be established. This includes context, information objectives, and function and performance requirements. The estimate and plan is then developed by decomposing the problem and establishing a functional partitioning.
The Process
The next step is to decide which process model to pick. The project manager has to look at the characteristics of the product to be built and the project environment. For examples, for a relatively small project that is similar to past efforts, degree of uncertainty is minimized and hence Waterfall or linear sequential model could be used. For tight timelines, heavily compartmentalized, and known domain, RAD model would be more suitable. Projects with large functionality, quick turn around time are best developed incrementally and for a project in which requirements are uncertain, prototyping model will be more suitable.
Lecture No. 8
The Project Management
As discussed earlier, a project manager must understand what can go wrong and how to do it right. Reel has defined a 5 step process to improve the chances of success. These are:
- Start on the right foot: this is accomplished by putting in the required effort to understand the problem, set realistic objectives, build the right team, and provide the needed infrastructure.
- Maintain momentum: many projects, after starting on the right, loose focus and momentum. The initial momentum must be maintained till the very end.
- Track progress: no planning is useful if the progress is not tracked. Tracking ensures timely delivery and remedial action, if needed, in a suitable manner.
- Make smart decisions
- Conduct a postmortem analysis: in order to learn from the mistakes and improve the process continuously, a project postmortem must be conducted.
W5HH Principle
Barry Boehm has suggested a systematic approach to project management. It is known as the WWWWWHH principle. It comprises of 7 questions. Finding the answers to these 7 questions is essentially all a project manager has to do. These are:
- WHY is the system being developed?
- WHAT will be done?
- By WHEN?
- WHO is responsible for a function?
- WHERE they are organizationally located?
- HOW will the job be done technically and managerially?
- HOW MUCH of each resource (e.g., people, software, tools, database) will be needed?
Boehm‘s W^5 HH principle is applicable, regardless of the size and complexity of the project and provide excellent planning outline.
Critical Practices
The Airlie Council has developed a list of critical success practices that must be present for successful project management. These are:
- Formal risk analysis
- Empirical cost and schedule estimation
- Metrics-based project management
- Earned value tracking
- Defect tracking against quality targets
- People aware project management
Lecture No. 9
Software Size Estimation
The size of the software needs to be estimated to figure out the time needed in terms of calendar and man months as well as the number and type of resources required carrying out the job. The time and resources estimation eventually plays a significant role in determining the cost of the project.
Most organizations use their previous experience to estimate the size and hence the resource and time requirements for the project. If not quantified, this estimate is subjective and is as good as the person who is conducting this exercise. At times this makes it highly contentious. It is therefore imperative for a government organization to adopt an estimation mechanism that is:
- Objective in nature.
- It should be an acceptable standard with wide spread use and acceptance level.
- It should serve as a single yardstick to measure and make comparisons.
- Must be based upon a deliverable that is meaningful to the intended audience.
- It should be independent of the tool and technology used for the developing the software.
A number of techniques and tools can be used in estimating the size of the software. These include:
- Lines of code (LOC)
- Number of objects
- Number of GUIs
- Number of document pages
- Functional points (FP)
Comparison of LOC and FPA
Out of these 5, the two most widely used metrics for the measurement of software size are FP and LOC. LOC metric suffer from the following shortcomings:
- There are a number of questions regarding the definition for lines of code. These include: a. Whether to count physical line or logical lines? b. What type of lines should be counted? For example, should the comments, data definitions, and blank lines be counted or not?
- LOC is heavily dependent upon the individual programming style.
- It is dependent upon the technology and hence it is difficult to compare applications developed in two different languages. This is true for even seemingly very close languages like in C++ and Java.
- If a mixture of languages and tools is used then the comparison is even more difficult. For example, it is not possible to compare a project that delivers a 100,000-line mixture of Assembly, C++, SQL and Visual Basic to one that delivers 100,000 lines of COBOL.
FP measures the size of the functionality provided by the software. The functionally is measured as a function of the data and the operations performed on that data. The measure is independent of the tool and technology used and hence provides a consistent measure for comparison between various organizations and projects.
The biggest advantage of FP over LOC is that LOC can be counted only AFTER the code has been developed while FP can be counted even at the requirement phase and hence can be used for planning and estimation while the LOC cannot be used for this purpose.
Another major distinction between the FP and LOC is that the LOC measures the application from a developer's perspective while the FP is a measure of the size of the functionality from the user's perspective. The user's view, as defined by IFPUG, is as follows:
A user view is a description of the business functions and is approved by the user. It represents a formal description of the user‘s business needs in the user‘s language. It can vary in physical form (e.g., catalog of transactions, proposals, requirements document, external specifications, detailed specifications, user handbook). Developers translate the user information into information technology language in order to provide a solution. Function point counts the application size from the user‘s point of view. It is accomplished using the information in a language that is common to both user(s) and developers.
Therefore, Function Point Analysis measures the size of the functionality delivered and used by the end user as opposed to the volume of the artifacts and code.
The Paradox of Reversed Productivity for High-Level Languages
Consider the following example:
Assembler Version Ada Version Difference Source Code Size 100,000 25,000 -75, Activity - in person months Requirements 10 10 0 Design 25 25 0 Coding 100 20 - Documentation 15 15 0 Integration and Testing 25 15 - Management 25 15 - Total Effort 200 100 - Total Cost $1,000,000 $500,000 -$500, Cost Per Line $10 $20 $ Lines Per Person-Month 500 250 -
Time Efficiency – Function Points per Month Cost – Per Function
Lecture No. 10
Function Point Counting Process
The following diagram depicts the function point counting process.
These steps are elaborated in the following subsections. The terms and definitions are the ones used by IFPUG and have been taken directly from the IFPUG Function Point Counting Practices Manual (CPM) Release 4.1. The following can therefore be treated as an abridged version of the IFPUG CPM Release 4.1.
Determining the type of count
A Function Point count may be divided into the following types:
- Development Count : A development function point count includes all functions impacted (built or customized) by the project activities.
- Enhancement Count : An enhancement function point count includes all the functions being added, changed and deleted. The boundary of the application(s) impacted remains the same. The functionality of the application(s) reflects the impact of the functions being added, changed or deleted.
- Application Count : An application function point count may include, depending on the purpose (e.g., provide a package as the software solution): a) only the functions being used by the user
Determine the type of count Enhancement Development Application
Define the application boundary
Count Transactional
Functions
EI EO EQ
Count Data
Functions
ILF EIF
Calculate Value
Adjustment Factor
(VAF)
Contribution of 14
general system
characteristics
Calculate Unadjusted FP Count (UFP)
Transactional Functions + Data Functions Calculate Adjusted
FP Count
UFP * VAF
Control Information is data that influences an elementary process of the application being counted. It specifies what, when, or how data is to be processed. For example, someone in the payroll department establishes payment cycles to schedule when the employees for each location are to be paid. The payment cycle, or schedule, contains timing information that affects when the elementary process of paying employees occurs.
User Identifiable
The term user identifiable refers to defined requirements for processes and/or groups of data that are agreed upon, and understood by, both the user(s) and software developer(s). For example, users and software developers agree that a Human Resources Application will maintain and store Employee information in the application.
Maintained
The term maintained is the ability to modify data through an elementary process. Examples include, but are not limited to, add, change, delete, populate, revise, update, assign, and create.
Elementary Process
An elementary process is the smallest unit of activity that is meaningful to the user(s). For example, a user requires the ability to add a new employee to the application. The user definition of employee includes salary and dependent information. From the user perspective, the smallest unit of activity is to add a new employee. Adding one of the pieces of information, such as salary or dependent, is not an activity that would qualify as an elementary process. The elementary process must be self-contained and leave the business of the application being counted in a consistent state. For example, the user requirements to add an employee include setting up salary and dependent information. If all the employee information is not added, an employee has not yet been created. Adding some of the information alone leaves the business of adding an employee in an inconsistent state. If both the employee salary and dependent information is added, this unit of activity is completed and the business is left in a consistent state.
ILF/EIF Counting Rules
This section defines the rules that apply when counting internal logical files and external interface files.
Summary of Counting Procedures
The ILF and EIF counting procedures include the following two activities:
- Identify the ILFs and EIFs.
- Determine the ILF or EIF complexity and their contribution to the unadjusted function point count. ILF and EIF counting rules are used for each activity.
There are two types of rules:
