SOFTWARE ENGINEERING AND PROJECT MANAGEMENT

SOFTWARE ENGINEERING AND PROJECT MANAGEMENTUNIT-II1Lecture No: 2Biplab Biswas- 9713156563Software project managementSoftware projects have several properties that make them very different to other kinds of engineering project.3Biplab Biswas- 9713156563Software projects have several properties that make them very different to otherkinds of engineering project. The product is intangible. Its hard to claim a bridge is 90% complete if there is not 90% of the bridge there. It is easy to claim that a software project is 90% complete, even if there are no visible outcomes. We dont have much experience. Software engineering is a new discipline, and so we simply dont have much understanding of how to engineer large scale software projects. Large software projects are often bespoke. Most large software systems are one-off, with experience gained in one project being of little help in another. The technology changes very quickly. Most large software projects employ new technology; for many projects, this is the raison detre

3ACTIVITIES4Biplab Biswas- 9713156563PARAMETERS These are parameters that decide whether a project is successful or not.

Estimated Cost and Expected ProfitOver commitment and MultitaskingInformed DecisionsEfficient use of resources.

5Biplab Biswas- 9713156563Responsibility of project managementProject management is an important part of the business world, and experienced project managers continue to be in very high demand. According to the Bureau of Labor Statistics, job openings in the computer and IT fields are expected to grow 17 percent over the decade from 2008 to 2018. But in order to prepare for the many opportunities in the field, you need to understand just what the job of the software project manager entails

6Biplab Biswas- 9713156563High-level Project Organization ChartExecutive Leadership

Project LeadershipProject Work TeamsSponsorAdvisory or Steering TeamProject LeaderProject ManagerCore TeamFunctional TeamChampion for the project. Provides high-level direction, authority, and resources. Removes roadblocks.Supports the Sponsor & Project Leader. Provides high-level direction and input.Provides subject matter expertise and functional/subject matter expertise, ownership, leadership, and accountability for assigned project results.Provides process expertise, tracking and reporting.Provides day-to-day leadership for planning, implementation, and closing. Resolves issues and escalates when needed.Provides leadership of the day-to-day activities of the project in support of the planning and implementation of the project plan.Change and/or Communications TeamFunctional TeamFunctional TeamConsider the impact on people as a result of the project or project results to determine need for this team.Project ResourcesCritical resources that can be brought in as subject matter experts as needed.7Biplab Biswas- 97131565637Key Roles & ResponsibilitiesProject SponsorHas ultimate authority and responsibility for the project

Provides funding for the project (initial funding, additional funds)Approves changes to scope, as requiredRemoves obstacles that prevent the project from moving forward Approves Project Charter and subsequent documentationProvides updates to executive managementResolves issues escalated by the project manager and/or core teamAdvisory or Steering TeamSupports the Sponsor & Project LeaderProvides high-level direction and inputProvides subject matter inputHelps support the resource needsHelps communicate the project benefits, etc.Project/Functional LeaderProvides subject matter expertise and functional ownership and accountability for project resultsDevelops the Project Charter and any other documentation in collaboration with the project team and resource managers for approval by the sponsor(s)Ensures all given objectives and responsibilities of the team are properly documented and approved on the Roles MatrixLeads core team meetingsProject ManagerResponsible for planning, organizing, managing, controlling and communicating on all phases of a projectFacilitates the development of the Project Charter and any other documentation in collaboration with the project team and resource managers Ensures all given objectives and responsibilities of the team are properly documented and approved on the roles matrixFacilitates the identification of project resource requirements and works with resource managers and the project leader to construct project teamsFacilitates regular core team meetings to review issues, project risks, and monitor project progressCreates regular status reports and distributes to project team8Biplab Biswas- 9713156563Key Roles & ResponsibilitiesCore Team MembersProvides day-to-day leadership for the planning, implementation, and closing of a project

Resolves issues and escalates when requiredManages individual sub teamsMeets regularly to review issues and monitor project progressProvides status updates on open action itemsManages project issues and risksFunctional Team LeaderManages the sub team and pursues the teams given objectives (i.e. project tasks)Serves on the Core TeamProvides regular status updates to the Project Manager/Leader, estimated time to completion, cause of variances, etc., as defined by the project Attends and actively participates in project team meetingsContributes to overall project objectives and specific team deliverablesCoordinates team activities related to project schedule

Team MemberResponsible for contributing to overall project objectives and specific team deliverablesContributes to project schedule development in collaboration with Project Leader/Manager/LeadPerforms assigned activities once the schedule is approvedCommunicates project risks and escalates issues to team lead Attends and actively participates in team meetingsProject ResourceResponsible for providing subject matter expertise as needed

Contributes subject matter expertise and input as needed throughout the projectImplements assigned deliverables/tasks9Biplab Biswas- 971315656310

The basic idea about software project management.Information about the stakeholders of any project along with their responsibilities. Parameters of software project management.

Biplab Biswas- 9713156563Assignment11What do you mean by a software project management?What are the most important aspects of software project management? Biplab Biswas- 9713156563Lecture No: 12Biplab Biswas- 9713156563SOFTWARE MEASUREMENTThere are two types: Direct Measures and Indirect Measures.

Direct Measures of the software engineering process include cost and effort applied. Direct measures of the product include lines of code (LOC) produced, execution speed, memory size, and defects reported over some set period of time.

Indirect measures of the product include functionality, quality, complexity, efficiency, reliability, maintainability, and many other "-abilities". The quality and functionality of software or its efficiency or maintainability are more difficult to assess and can be measured only indirectly.

13Biplab Biswas- 9713156563PRIVATE AND PUBLIC METRICIt is natural that individual software engineers might be sensitive to the use of metrics collected on an individual and serve as an indicator for the individual only. Hence Private metrics are used to measure the efficiency of an individual.

Examples of Private Metrics: -1) Defect rates by Individual 2) Defect rates by Module3) Errors found during development

Public metrics generally assimilate information that originally was private to individuals and teams. Project level defect rates (absolutely not attributed to an individual), effort, calendar times, and related data are collected and evaluated in an attempt to uncover indicators that can improve organizational process performance.

14Biplab Biswas- 9713156563

Metrics Set -Recommended Metrics Set for a Project

Indicator Category Management Insight Indicators Progress Provides information on how well the project is performing with respect to its schedule. Actual vs. planned task completions Actual vs. planned durationsEffort Provides visibility into the contributions of staffing on project costs, schedule adherence, and product quality. Actual vs. planned staffing profilesCost Provides tracking of actual costs against estimated costs and predicts future costs. Actual vs. planned costs Cost and schedule variancesReview Results Provides status of action items from life-cycle review. Status of action itemsTrouble ReportsProvides insight into product and process quality and the effectiveness of the testing. Status of trouble reports Number of trouble reports opened, closed, etc. duringreporting period15Biplab Biswas- 9713156563

Metrics Set -Recommended Metrics Set for a Project

Indicator Category Management Insight Indicators Requirements Stability Provides visibility into the magnitude and impact of requirements changes. Number of requirements changes/clarifications Distribution of requirements over releasesSize Stability Provides insight into the completeness and stability of the requirements and into the ability of the staff to complete the project within the current budget and schedule.Size growth Distribution of size over releasesComputer Resource Utilization Provides information on how well the project is meeting its computer resource utilization goals/requirements.Actual vs. planned profiles of computer resource utilizationTraining Provides information on the training program and staff skills. Actual vs. planned number of personnel attending classes16Biplab Biswas- 9713156563PRODUCT METRICProduct metrics are metrics that can be calculated from the document independent of how it was produced.

Generally, these are concerned with the structure of the source code.

They also provide the software engineer with on-the spot, rather than after the fact insight. This enables the engineer to discover and correct potential problems before they become catastrophic defects.

17Biplab Biswas- 9713156563PRODUCT METRIC LANDSCAPE18Biplab Biswas- 9713156563PRODUCT METRIC LANDSCAPE19Biplab Biswas- 9713156563PRODUCT METRIC LANDSCAPE20Biplab Biswas- 9713156563METRICS FOR THE ANALYSIS MODEL22Biplab Biswas- 9713156563METRICS FOR THE ANALYSIS MODEL. Function points are derived using an empirical relationship based on countable measures of softwares information domain and assessments of software complexity. Information domain values are defined in the following manner.

Weighted factorInformation Domain ValueCountSimpleAverageComplex=Number of External Inputs (EIs). x=Number of External Outputs(E0s)x=Number of External inquiries: (Eqs)x=Number of internal logical files(ILFs)x=Number of external interface files(EIFs)x=23Biplab Biswas- 9713156563METRICS FOR THE ANALYSIS MODEL.To compute the function of FP, the following relationship is used:FP=count total x [0.65 + 0.01 x (Fi)]

Where count total is the sum of all FP entries obtained from table given earlier.

The Fi (i= 1 to 14) are value adjustment factors (VAF) based on responses to the following questions.

24Biplab Biswas- 9713156563METRICS FOR THE ANALYSIS MODEL.Does the system require reliable backup and recovery?Are specialized data communication s required to transfer information to or from the application?Are there distributed processing functions?Is performance critical?Will the system run in an existing, heavily utilized operational environment?Does the system require on-line data entry?Does the on-line data entry require the input transaction to be built over multiple screens or operations?Are the ILFs updated on line?Are the inputs, outputs, files or inquiries complex?Is the internal processing complex?Is the code designed to be reusable?Are conversion and installation included in the design?Is the system designed for multiple installations in different organizations?Is the application designed to facilitate change and for ease of use by the user?Each of these questions is answered using a scale that ranges from 0 to 5.25Biplab Biswas- 9713156563METRICS FOR THE ANALYSIS MODEL.

26Biplab Biswas- 9713156563METRICS FOR THE ANALYSIS MODEL.External Inputs are: Password, Panic Button, Activate /Deactivate.External Inquires: Zone Inquiry, sensor inquiry.Internal Logic file: System Configuration file.External Outputs: Messages, Sensor Status.External Interface Files: Test Sensor, Zone Setting, Activate / Deactivate, Alarm Set.

Weighted factorInformation Domain ValueCountSimpleAverageComplex=Number of External Inputs (EIs). 3x346=9Number of External Outputs(E0s)2x457=8Number of External inquiries: (Eqs)2x346=6Number of internal logical files(ILFs)1x71015=7Number of external interface files(EIFs)4x5710=20Total:5027Biplab Biswas- 9713156563METRICS FOR THE ANALYSIS MODEL.The count total shown in the table must be adjusted using equation.FP=count total x [0.65 + 0.01 x (Fi)]Where count total is the sum of all FP entries obtained from the table. And Fi(i=1 to 14) are the value adjustment factors for purpose we assume Fi=46. Therefore FP=50 x [0.65 + 0.01 x 46)] = 56

Based on the projected FP value derived from the analysis model, the project team can estimate the overall implemented size of the software user interaction function.

Assume that past data indicate that one FP translates into 60 lines of code and that 12 FPs are produced for each person-month of effort.

28Biplab Biswas- 971315656329

What is software measurement and their types.Different types of software metrics.What is product metrics?How to measure a project/ software?

Biplab Biswas- 9713156563Assignment30Why should we measure a software project?Briefly explain the difference between direct and indirect measurement.Biplab Biswas- 9713156563Lecture No: 31Biplab Biswas- 9713156563Process metrics

32Biplab Biswas- 9713156563PROCESS METRICS33Biplab Biswas- 9713156563Process metricsMetrics should not be used to evaluate the performance of individuals.Statistical software process improvement helps an organization to discover its strengths and weaknesses. 34Biplab Biswas- 9713156563Process metrics35Biplab Biswas- 9713156563Process metricsStatistical Process Control36Biplab Biswas- 9713156563Process metricsSoftware process metrics can provide significant benefit as an organization works to improve its overall level of process maturity.Grady [GRA92] suggests a software metrics etiquette that is appropriate for both managers and practitioners as they institute a process metrics program:Use common sense and organizational sensitivity when interpreting metrics data.Provide regular feedback to the individuals and teams who collect measures and metrics.Dont use metrics to appraise individuals.Work with practitioners and teams to set clear goals and metrics that will be used to achieve them.Never use metrics to threaten individuals or teams.Metrics data that indicate a problem area should not be considered negative.These data are merely an indicator for process improvement.Dont obsess on a single metric to the exclusion of other important metrics.37Biplab Biswas- 9713156563Process metricsAs an organization becomes more comfortable with the collection and use of process metrics, the derivation of simple indicators gives way to a more rigorous approach called statistical software process improvement (SSPI). In essence, SSPI uses software failure analysis to collect information about all errors and defects3 encountered as an application, system, or product is developed and used. Failure analysis works in the following manner:

38Biplab Biswas- 9713156563Process metrics39

Biplab Biswas- 9713156563Project metrics40Biplab Biswas- 9713156563Project metrics41Biplab Biswas- 9713156563Project metrics42Biplab Biswas- 971315656343

The concept of project and process metrics.The points should be considered during the measurement.The process of both metrics

Biplab Biswas- 9713156563Assignment44What are differences between project and process metrics?How these kind of measurements can help the software development team?Biplab Biswas- 9713156563Lecture No: 45Biplab Biswas- 9713156563McCalls Quality Factors46Biplab Biswas- 9713156563McCalls Quality FactorsMcCall, Richards, and Walters [MCC77] propose a useful categorization of factors that affect software quality. These software quality factors.

47

Biplab Biswas- 9713156563McCalls Quality Factors48Biplab Biswas- 9713156563McCalls Quality Factors49Biplab Biswas- 9713156563FURPSThe quality factors described by McCall and his colleagues [MCC77] represent one of a number of suggested checklists for software quality. Hewlett-Packard [GRA87] developed a set of software quality factors that has been given the acronym FURPS , functionality, usability, reliability, performance, and supportability. The FURPS quality factors draw liberally from earlier work, defining the following attributes for each of the five major factors:Functionality is assessed by evaluating the feature set and capabilities of the program, the generality of the functions that are delivered, and the security of the overall system.Usability is assessed by considering human factors, overall aesthetics, consistency, and documentation.Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of output results, the mean-time-to-failure (MTTF), the ability to recover from failure, and the predictability of the program.Performance is measured by processing speed, response time, resource consumption, throughput, and efficiency.Supportability combines the ability to extend the program (extensibility), adaptability, serviceabilitythese three attributes represent a more common term, maintainabilityin addition, testability, compatibility, configurability , the ease with which a system can be installed, and the ease with which problems can be localized.50Biplab Biswas- 971315656351

The basic concept of McCalls Quality Factors.The direct and indirect measurement in McCalls Quality Factors.The basic concept of FURPS.

Biplab Biswas- 9713156563Assignment52How McCalls Quality Factors, directly or indirectly effect a software project?Write down short note on FURPS.Biplab Biswas- 9713156563Lecture No: 53Biplab Biswas- 9713156563COCOMOBACKGROUNDCOCOMO (COnstructive COst estimation MOdel) considers the size of the software and several other characteristics of the proposed software. Dr Berry Boehm in 1981 proposed this approach when software engineers started using OOD, automated tools for code generation, testing and so on.A series of mathematical formulae are used to predict effort base on software size and other factors such as maturity of process and capability of development team, risk etc.COCOMO considers the software product attributes, platform attributes, development team attributes and project management attributes and weighs them suitably to improve the estimation.

55Biplab Biswas- 9713156563BACKGROUNDAccording to Boehm any software project can be classified into any of the three categories based upon the development complexity.Organic: If the project is 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 types of projects.Semidetached: A development project can be considered to be of semidetached type, if the development team consists of a mixture of experienced and inexperienced staff. Team members may have limited experience on related systems by may be unfamiliar with some aspects of the system being developed.Embedded: A development project is considered to be of embedded type, if the software being developed is strongly coupled to complex hardware, or if stringent regulations on the operational procedures exist. 56Biplab Biswas- 9713156563STAGESAccording to Boehm, Software cost estimation should be done through three stages:

Basic COCOMOIntermediate COCOMOComplete COCOMO.57Biplab Biswas- 9713156563BASIC COCOMOThe Basic COCOMO model gives an approximate estimate of the project parameters. The basic COCOMO estimation model is given by the following expressions:Effort= a1 X (KLOC)a2PMTdev= b1 X (Effort)b2 MonthsWhere: KLOC is the estimated size of the software product expressed in Kilo Lines of code.a1,a2,b1,b2 are constants for each category of software products.Tdev is the estimated time to develop the software, expressed in months,Effort is the total effort required to develop the software product, expressed in person months.58Biplab Biswas- 9713156563BASIC COCOMO -Estimation of development effort- Estimation of development timeFor the three classes of software products, the formulas for estimating the effort based on the code size are shown below:Organic: Effort: 2.4(KLOC)1.05 PMSemidetachedEffort: 2.4(KLOC)1.12 PMEmbeddedEffort: 2.4(KLOC)1.20 PM

For the three classes of software products, the formulas for estimating the development time based on the effort are given below:Organic: Tdev= 2.5 (Effort)0.38MonthsSemidetached: Tdev= 2.5 (Effort)0.35MonthsEmbedded:Tdev= 2.5 (Effort)0.32Months

59Biplab Biswas- 9713156563BASIC COCOMO ExampleAssume that the size of an organic type software product has been estimated to be 32,000 lines of source code. Assume that the average salary of software developers is 15,000 per month. Determine the effort required to develop the software product, the nominal development time, and the cost to develop the product.

From the basic COCOMO estimation formula for organic software:Effort = 2.4 X (32)1.05PM = 91 Person monthNominal development time = 2.5 X (91) 0.38 = 14 monthsCost required to develop the product = 91 X 15,000 = 1,465,000

60Biplab Biswas- 9713156563INTERMEDIATE COCOMO The basic COCOMO model assumes that effort and development time are functions of the product size alone. But beside size some other project parameters is required to develop the product as well as the development time. In order to obtain an accurate estimation of the effort and project duration, the effect of all relevant parameters must be taken into account. The intermediate COCOMO model recognizes this fact and refines the initial estimate obtained using the basic COCOMO expressions by using a set of 15 cost drivers based on various attributes of software development.

61Biplab Biswas- 9713156563INTERMEDIATE COCOMO Ratings upon the 15 cost drivers are asked from project managers on a scale of one to three. Depending on these ratings, appropriate cost driver values which should be multiplied with the initial estimate obtained using the basic COCOMO. The cost drivers can be classified as being attributes of the following items:

Product: Computer:Personnel:Development environment:

62Biplab Biswas- 9713156563Ratings Cost DriversCost DriversVery lowLowNominalHighVery HighExtra HighPRODUCT ATTRIBUTESRequiredsoftwarereliability0.750.881.001.151.40Sizeofapplicationdatabase0.941.001.081.16Complexityoftheproduct0.700.851.001.151.301.65HARDWARE ATTRIBUTESRun-timeperformanceconstraints1.001.111.301.66Memoryconstraints1.001.061.211.56Volatilityofthevirtualmachineenvironment0.871.001.151.30Requiredturnabouttime0.871.001.071.1563Biplab Biswas- 9713156563Ratings Cost DriversCost DriversVery lowLowNominalHighVery HighExtra HighPERSONNEL ATTRIBUTESAnalyst capability1.461.191.000.860.71Applicationsexperience1.291.131.000.910.82Softwareengineercapability1.421.171.000.860.70Virtualmachineexperience1.211.101.000.90Programminglanguageexperience1.141.071.000.95PROJECT ATTRIBUTESApplicationofsoftwareengineeringmethods1.241.101.000.910.82Useofsoftwaretools1.241.101.000.910.83Requireddevelopmentschedule1.231.081.001.041.1064Biplab Biswas- 9713156563INTERMEDIATE COCOMO The Intermediate COCOMO formula now takes the form:Effort=ai(KLoC)(bi).EAFWhere E is the effort applied in person-months, KLOC is the estimated number of thousands of delivered lines of code for the project, and EAF is the factor calculated above. The value of ai and bi are given in the next table.

The Development time calculation uses Effort in the same way as in the Basic COCOMO.

SoftwareprojectaibiOrganic3.21.05Semi-detached3.01.12Embedded2.81.2065Biplab Biswas- 9713156563COMPLETE COCOMO A major shortcoming of both the basic and the intermediate COCOMO models is that they consider a software product as a single homogeneous entity. Most of the times large systems are made up of several smaller subsystems.The complete COCOMO model considers these differences in characteristics of the subsystems and estimates the effort and development time as the sum of the estimates for the individual subsystems. The cost of each subsystem is estimated separately. This approach reduces the margin of error in the final estimate.

66Biplab Biswas- 9713156563COMPLETE COCOMO In case of a Distributed Management Information System product for an organization having offices at several places across the country can have the following sub components:Database PartGraphical User Interface PartCommunication Part

The communication part can be considered as embedded software. The database part could be semidetached software, and the GUI part can be considered as Organic Software. The costs for these three components can be estimated separately, and summed up to give the overall cost of the system.

67Biplab Biswas- 971315656368

The basic concept COCOMO.Different types of models under COCOMO.The measurement process using COCOMO models.Biplab Biswas- 9713156563Assignment69Write down the importance of 14 cost drivers.What is the difference between intermediate and complete COCOMO?Biplab Biswas- 9713156563Lecture No: 70Biplab Biswas- 9713156563COCOMO - II The latest version of COCOMO model is COCOMO-II, released in 1997. This model has three estimation model to estimate effort and cost. The models are:Application Suite Model/Application Composition Model: This model as the name suggests, can be used to estimate cost for prototyping, e.g. to resolve user interface issues.Early Design Model: This supports estimates of cost at the architectural design stage.Post Architectural Model/ Final Design Architectural Model: This provides cost estimation during detailed design and coding stage. The post architectural model can be considered as an update of the original COCOMO.

71Biplab Biswas- 9713156563Application Suite Model/Application Composition ModelThe Application composition model is based on counting the number of screens, reports and 3GL modules. Each of these components is considered to be an object.Effort is estimated in the application composition model as follows: Estimate the number of screens, reports and 3GL components from an analysis of the SRS document.Determine the complexity level of each screen and report and rate these as either simple, medium or difficult.Screen Complexity table:

Number of viewsTables