Management of Software Engineering

1. Management of Software Engineering Dr. Mai Fadel

2. Introduction • There are many engineers involved in the development of a software product => • There work must be coordinated and managed • Define a project and have a manager • Tasks of a project manger: • Planning • Acquisition of resources – space, computing resources, materials, and human resources (staffing) • execution • Monitoring • Challenge: making decisions on how best to use limited resources to achieve a set of independent and sometimes conflicting goals Plan the work and work the plan

3. The managers faces many decisions that involve complicated trade-offs. • Develop in-house compared with modifying a commercially available module • Without clear cost model that delineates the economic impact of these decisions, there is no good way to choose among alternatives. • There are a number of quantitative approaches to software cost estimation, cost modeling, and cost analysis have been proposed. • They are far from being accurate (20-80%) • Useful • Managers not only manage a single project but the overall organization’s life cycle • Evaluate the organization be comparing them with other competing organizations • Assess the capabilities of the organization to improve it. Capability Maturity Model (CMM) used to assess the software development organization maturity and to implement an improvement strategy.

4. Management Functions • The creation and maintenance of an internal environment in an enterprise where individually working together in groups, can perform efficiently and effectively toward the attainment of group goals • Management interrelated activities: • Planning, organizing, staffing, directing, and controlling

5. Project Planning • First step of software engineering management project • Step 1:Document assumptions, goals, and constraints of the project. • The need for a clear statement of the goals • Step 2: come up with a plan for how best to meet the requirements within given constraints • What process model • Determine the required resources (raw material is the human brainpower => cost is proportional to the number of engineers) – software cost estimation

6. Project Planning – continued • Forecasting how many engineers is difficult. It requires: • Estimating the difficulty of the problem • Estimating how much of the task each engineer can accomplish • Incomplete and imprecise requirements hinder accurate cost estimation • Best approach is to develop resource requirements incrementally, revising current estimates as more information becomes available • How long it will take an engineer to accomplish a given task is primarily a function of: • Complexity of the problem, engineer’s ability, the design of the software and the tools that are available (e.g. undo, parsing)

7. Planning: 1- Software Productivity • Management requirement: measure the productivity of the people and processes involved in production • Use it in planning to estimate cost, evaluate performance people, tools, processes • We can be sure about improvements only if we can quantitatively measure productivity • productivity metrics: amount of functionality produced per unit of time • Function Points • Size of code • Factors affecting productivity

8. Productivity & Size of Code • Source code is the most tangible part of software engineering • Size of code as a productivity metric • List of questions • Should we count the comment lines? • How many times should we count the lines in a file that is “included” several times? etc. • Delivered Source Instructions (DSI) • NonCommented Source Statements (NCSS) • Generic Unit KLOC • Problems • A programmer who uses libraries or abstractions is penalized • It is important to know what is counted in order to make accurate comparisons

9. Productivity & Size of Code • Consider when comparing the productivity figures reported by different organizations is whether the reported figures include the effect of canceled projects. • Are the canceled projects counted in the overall productivity of the organization? Consistency must be maintained. • When applying the Urban renewal principle the code will shrink? Does this engineer suddenly reduces the productivity of the entire organization? • Lines of code are tied to procedural languages and are inherently incapable of dealing with the visual languages (using diagrams and screen panels rather than statements) • Do not deal with declarative systems wherein programs are generated automatically

10. Productivity – Factors affecting productivity • These factors affects productivity regardless of the metric used • By identifying the major contributors to productivity, organizations can determine quantitatively whether they can afford to change their practices – whether the improvements in productivity are worth the costs associated with the required changes. • New programming language, new development process, hiring an efficiency expert • A study that uses LOC metric: the Factors are: • Capability of the personal • Complexity of the product (half as important) • Required reliability and timing constraints • (least) schedule constraints and previous experience with the language • These factors are used in the cost estimation models

11. Productivity – Factors affecting productivity • Belief that aggressive schedule motivates a better, faster job • Unrealistic aggressive schedules cause engineers to compromise on intangible aspects of quality and schedule delay • Engineers are good achieving one tangible goals (if it is schedule then they achieve it by compromising documentation and structure) • The fear about leaving engineers to work by themselves away from the guidance of headquarters turned out to be ill founded. • Maybe because of the isolation from distractions from the many meetings (tradeoffs that manager should make) • Intangible factors: personnel turnover, canceled projects, reorganizations, and restructuring of systems for better quality.

12. Planning: 2- People & Productivity • People are the source of producing high-quality software efficiently • Engineering capability: • Common misconception held by managers (staffing, planning, and scheduling practices): software engineers are interchangeable • Personalities of the members should be taken • Because of the heavy interactions between teams • Centrally controlled projects and decentralized control. • Personal are not interchangeable due to technical ability and personality • Negative management practice: staffing a project with the best available people, rather than attempting to find the best people to • Training period cost • Solution: schedule the training period as required, hire outside consultants

13. Planning: 3- Cost Estimation • It is part of the planning stage of any engineering activity • Primary cost is for people • Other engineering disciplines – there is the cost of chips, bricks, and other material • Two uses for cost estimation in s/w project management • During the planning stage, deciding how many engineers are needed for the project and develop a schedule accordingly • Monitoring the project’s progress, assessing whether the project is progressing according to schedule, if not what corrective action (ascertain how much work has been accomplished, and how much is left to be done) • Software work accomplishment metric. • Halstead’s metric is applied to an existing piece of software and can be used to compare such things as: • the complexity of two different programs or • the relative benefits of two programming languages • In the planning phase, we don’t have the program => cannot use any code-based metric to measure its inherent complexity • Structure metrics and predictive methods (function points).

14. Predictive models of software cost • If we can predict how large a software system was going to be before developing it, that size could be used as a basis for: • determining how much effort would be required, • how many engineers would be needed, and • how long it would take to develop the software • It would be used to predict development and other stages of the software life cycle • The size estimation derives the entire estimation process (e.g. size->effort) • Computing an initial estimate of code size would be simpler if the organization maintains a database of information about past projects.

15. Predictive models of software cost • The purpose of a software cost model is to predict the total development effort required to produce a given piece of software in terms of the number of engineers and length of time • General formula used to arrive at the nominal development effort is PM initial = c KLOCk • To take into account the many variables that can affect the productivity of the project, cost drivers are used to scale the initial estimate of effort. • e.g. if modern programming languages are used => scale down • Real-time reliability requirement => scale up • Cost drivers • Product: reliability, inherent complexity • Computer: are there execution time or storage constraints? • Personal: personal experience in the application area or the prog. Lang.? • Project: are sophisticated software tools being used? • There are attributes in each class • e.g. some models use object code for the size estimate, others use source code

16. Predictive models of software cost • Basic steps for arriving at the cost of a proposed software system: • Estimate the software’s eventual size, and use it in the model’s formula to arrive at an initial estimate of effort • Revise the estimate by using the cost driver or other scaling factors given by the model • Apply the model’s tools to the estimate derived in step 2 to determine the total effort, activity distribution, etc.

17. COCOMO • Construction Cost Model is a cost estimate model. • Its general steps: • The code size estimate is based on KDSI • Initial development effort based on project’s development ‘mode’: organic/semidetached/embedded • Determining the mode, the corresponding formula is used to compute the initial effort estimate • Table 8.3 and 8.4 can be considered as the quantitative summary of a considerable amount of experimental data collected by Boehm over the years • e.g. flight control system ->embedded class, payroll application-> organic

18. COCOMO 2- the estimator determines the effort multiplier for the particular project based on cost-driver attributes. • COCOMO uses 15 such attributes to scale the nominal development effort, • Attributes listed in Table 8.5 • Multipliers show the impact of the factor & how much control the manager has over it • Product factors are in general fixed and not in the control of the manager • The estimate of total effort = The multiplier of each attribute are multiplied together x nominal effort derived

19. COCOMO 3- COCOMO allows the derivation of other important numbers and analyses. • Table 8.4 the schedule column shows formulas, for deriving the length for the project schedule, on the basis of the estimate of the total effort for the project • The model allows sensitivity analysis based on changing the parameters. • e.g. modeling change in development time, impact of unstable hardware on project schedule • Without such models we rely on judgments, which are hard to trust & justify, cannot know if there is improvement • They can help as validation against organization’s project database • Maintained database should store the progress of its projects • These models are difficult to trust, but can complement the expert judgment and intuition

20. 3- Project Control • The purpose of controlling a project is to monitor the progress of the activities against the plans, in order to ensure that the goals are being approached and eventually achieved • Decomposing work to decide which tasks need to be done • Scheduling the order of tasks to be done is determined (Gantt charts & PERT charts) • Each work item is assigned with an activity to perform the item

21. 4- Organization • The organizing function of management deals with devising roles for individuals and assigning responsibility for accomplishing project goals • Motivated by the need for cooperation when the goals are not achievable by a single individual in a reasonable time • The aim of an organizational structure is to facilitate cooperation towards a common goal • It helps in coordination between vice presidents and organize the interactions among programmers

22. Software development team organizations • Team organization can be categorized according to where decision-making control lies. • Centralized-control team organization several workers report to a supervisor who directly controls their tasks and responsible for their performance. hierarchal organizational structure (-) ve Communication through the supervisor, success depends on his skill and ability

23. Software development team organizations 2. Decentralized-control team organization decisions are made be consensus, and all work is considered group work. Team members review each other’s work and are responsible as a group for what every member produces ringlike management structure shows lack of hierarchy (-) ve communication overhead in large projects, engineers are overwhelmed • Mixed-control team organization combines both modes control is vested in the project manager and senior programmers communication is decentralized among each set of individuals, peers, and their immediate supervisors