CHAPTER 1

Software is: (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to adequately manipulate information and (3) documentation that describes the operation and use of the programs. Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). A project - a temporary endeavor undertaken to create a unique product, service, or result Software project management - Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software. Are needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software. Success criteria - Deliver the software to the customer at the agreed time.Keep overall costs within budget.Deliver software that meets the customers expectations. Maintain a happy and wellfunctioning development team. Software management distinctions The product is intangible. Software cannot be seen or touched. Software project managers cannot see progress by simply looking at the artefact that is being constructed. Many software projects are 'oneoff' projects. Large software projects are usually different in some ways from previous projects. Even managers who have lots of previous experience may find it difficult to anticipate problems. Software processes are variable and organization specific.We still cannot reliably predict when a particular software process is likely to lead to development problems. Management activities Project planning - Project managers are responsible for planning, estimating and scheduling project development and assigning people to tasks. Reporting - Project managers are usually responsible for reporting on the progress of a project to customers and to the managers of the company developing the software. Risk management - Project managers assess the risks that may affect a project, monitor these risks and take action when problems arise. People management - Project managers have to choose people for their team and establish ways of working that leads to effective team performance Proposal writing - The first stage in a software project may involve writing a proposal to win a contract to carry out an item of work. The proposal describes the objectives of the project and how it will be carried out.

The Management Spectrum - The Four Ps People the most important element of a successful project Product the software to be built Process the set of framework activities and software engineering tasks to get the job done Project all work required to make the product a reality PEOPLE Stakeholders - Senior managers who define the business issues that often have significant influence on the project. Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work. Practitioners who deliver the technical skills that are necessary to engineer a product or application. Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. End-users who interact with the software once it is released for production use. PEOPLE- Software Teams - Team Leader The MOI Model Motivation - The ability to encourage (by push or pull) technical people to produce to their best ability. Organization - The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. Ideas or innovation - The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application. Software Teams the difficulty of the problem to be solved the size of the resultant program(s) in lines of code or function points the time that the team will stay together (team lifetime) the degree to which the problem can be modularized the required quality and reliability of the system to be built the rigidity of the delivery date the degree of sociability (communication) required for the project Software Team- Organizational Paradigms closed paradigmstructures a team along a traditional hierarchy of authority (work well when producing software that is quite similar to past efforts)

random paradigmstructures a team loosely and depends on individual initiative of the team members (when innovation is required) open paradigmattempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm (for complex problem- work is performed collaboratively, heavy communication & consensus-based decision making) synchronous paradigmrelies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves Avoid Team Toxicity A frenzied work atmosphere in which team members waste energy and lose focus on the objectives of the work to be performed. High frustration caused by personal, business, or technological factors that cause friction among team members. Fragmented or poorly coordinated procedures or a poorly defined or improperly chosen process model that becomes a roadblock to accomplishment. Unclear definition of roles resulting in a lack of accountability and resultant finger-pointing. Continuous and repeated exposure to failure that leads to a loss of confidence and a lowering of morale. Agile Teams Encourages customer satisfaction and early incremental delivery software, small highly motivated project teams, informal methods, minimal software engineering work products, and overall development simplicity The distribution of skills must be appropriate to the problem. Mavericks may have to be excluded from the team, if team cohesiveness is to be maintained. Team is self-organizing An adaptive team structure Uses elements of Constantines random, open, and synchronous paradigms Significant autonomy Team Coordination & Communication Formal, impersonal approaches include software engineering documents and work products (including source code), technical memos, project milestones, schedules, and project control tools change requests and related documentation, error tracking reports, and repository data Formal, interpersonal procedures focus on quality assurance activities applied to software engineering work products. These include status review meetings and design and code inspections.

Informal, interpersonal procedures include group meetings for information dissemination and problem solving and collocation of requirements and development staff. Electronic communication encompasses electronic mail, electronic bulletin boards, and by extension, video-based conferencing systems. Interpersonal networking includes informal discussions with team members and those outside the project who may have experience or insight that can assist team members. People management factors Consistency Team members should all be treated in a comparable way without favourites or discrimination. Respect Different team members have different skills and these differences should be respected. Inclusion Involve all team members and make sure that peoples views are considered. Honesty You should always be honest about what is going well and what is going badly in a project. Managing people People are an organisations most important assets. The tasks of a manager are essentially people-oriented. Poor people management is an important contributor to project failure. The Product Scope Scope Context. How does the software to be built fit into a larger system, product, or business context and what constraints are imposed as a result of the context? Information objectives. What customer-visible data objects are produced as output from the software? What data objects are required for input? Function and performance. What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed? Software project scope must be unambiguous and understandable at the management and technical levels. Problem Decomposition Sometimes called partitioning or problem elaboration

Once scope is defined It is decomposed into constituent functions It is decomposed into user-visible data objects or It is decomposed into a set of problem classes Decomposition process continues until all functions or problem classes have been defined The Process Once a process framework has been established Consider project characteristics Determine the degree of rigor required Define a task set for each software engineering activity Task set = Software engineering tasks Work products Quality assurance points Milestones Melding the Problem and the Process The Project Projects get into trouble when Software people dont understand their customers needs. The product scope is poorly defined. Changes are managed poorly. The chosen technology changes. Business needs change [or are ill-defined]. Deadlines are unrealistic. Users are resistant. Sponsorship is lost [or was never properly obtained]. The project team lacks people with appropriate skills. Managers [and practitioners] avoid best practices and lessons learned.

Common-Sense Approach to Projects Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objectives and expectations. Maintain momentum. The project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the teams way. Track progress. For a software project, progress is tracked as work products (e.g., models, source code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity. Make smart decisions. In essence, the decisions of the project manager and the software team should be to keep it simple. Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project. To Get to the Essence of a Project Why is the system being developed? What will be done? When will it be accomplished? Who is responsible? Where are they 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? Key points Good project management is essential if software engineering projects are to be developed on schedule and within budget. Software management is distinct from other engineering management. Software is intangible. Projects may be novel or innovative with no body of experience to guide their management. Software processes are not as mature as traditional engineering processes. Effective software project management focuses on the 4 Ps: People, Product, Process and Project. Software project manager plays a major role in software project management activities

Chapter 2

Scheduling and Project planning

Project planning involves breaking down the work into parts and assign these to project team members, anticipate problems that might arise and prepare tentative solutions to those problems. The project plan, which is created at the start of a project, is used to communicate how the work will be done to the project team and customers, and to help assess progress on the project. Planning stages At the proposal stage, when you are bidding for a contract to develop or provide a software system. During the project startup phase, when you have to plan who will work on the project, how the project will be broken down into increments, how resources will be allocated across your company, etc. Periodically throughout the project, when you modify your plan in the light of experience gained and information from monitoring the progress of the work. Proposal planning Planning may be necessary with only outline software requirements. The aim of planning at this stage is to provide information that will be used in setting a price for the system to customers. Software pricing Estimates are made to discover the cost, to the developer, of producing a software system. You take into account, hardware, software, travel, training and effort costs.

There is not a simple relationship between the development cost and the price charged to the customer. Broader organisational, economic, political and business considerations influence the price charged. Factors affecting software pricing Factors affecting software pricing Plan-driven development Plan-driven or plan-based development is an approach to software engineering where the development process is planned in detail. Plan-driven development is based on engineering project management techniques and is the traditional way of managing large software development projects.

A project plan is created that records the work to be done, who will do it, the development schedule and the work products.

 Managers use the plan to support project decision making and as a way of measuring progress. Plan-driven development pros and cons The arguments in favor of a plan-driven approach are that early planning allows organizational issues (availability of staff, other projects, etc.) to be closely taken into account, and that potential problems and dependencies are discovered before the project starts, rather than once the project is underway. The principal argument against plan-driven development is that many early decisions have to be revised because of changes to the environment in which the software is to be developed and used. Project plans In a plan-driven development project, a project plan sets out the resources available to the project, the work breakdown and a schedule for carrying out the work. Plan sections Introduction Project organization Risk analysis Hardware and software resource requirements Work breakdown Project schedule Monitoring and reporting mechanisms

Project plan supplements The planning process Project planning is an iterative process that starts when you create an initial project plan during the project startup phase. Plan changes are inevitable. As more information about the system and the project team becomes available during the project, you should regularly revise the plan to reflect requirements, schedule and risk changes. Changing business goals also leads to changes in project plans. As business goals change, this could affect all projects, which may then have to be re-planned.

The project planning process Project scheduling

 Project scheduling is the process of deciding how the work in a project will be organized as separate tasks, and when and how these tasks will be executed. You estimate the calendar time needed to complete each task, the effort required and who will work on the tasks that have been identified. You also have to estimate the resources needed to complete each task, such as the disk space required on a server, the time required on specialized hardware, such as a simulator, and what the travel budget will be. Project scheduling activities Split project into tasks and estimate time and resources required to complete each task. Organize tasks concurrently to make optimal use of workforce. Minimize task dependencies to avoid delays caused by one task waiting for another to complete. Dependent on project managers intuition and experience. Milestones and deliverables Activities in a project should be organised to produce tangible outputs for management to judge progress. Milestones are the end-point of a process activity in the schedule against which you can assess progress, for example, the handover of the system for testing. Deliverables are project results/work products that are delivered to the customer, e.g. a requirements document for the system. Milestones in the RE process The project scheduling process Scheduling problems Estimating the difficulty of problems and hence the cost of developing a solution is hard. Productivity is not proportional to the number of people working on a task. Adding people to a late project makes it later because of communication overheads. The unexpected always happens. Always allow contingency in planning. Schedule representation Graphical notations are normally used to illustrate the project schedule. These show the project breakdown into tasks. Tasks should not be too small. They should take about a week or two.

 Activity charts show task dependencies and the critical path. Bar charts are the most commonly used representation for project schedules. They show the schedule as activities or resources against calendar time. Tasks, durations, and dependencies Activity network Critical Path path any route along the network from start to finish Critical Path path with the longest total duration This is the shortest time in which the project can be completed. Critical Activity an activity on the critical path *If a critical activity is delayed, the entire project will be delayed. Close attention must be given to critical activities to prevent project delay. There may be more than one critical path. Critical Path Brute force approach to finding critical path: 1. identify all possible paths from start to finish 2. sum up durations for each path 3. largest total indicates critical path (This approach is inefficient, but is instructive) Activity bar chart Staff allocation chart Agile planning Agile methods of software development are iterative approaches where the software is developed and delivered to customers in increments. Unlike plan-driven approaches, the functionality of these increments is not planned in advance but is decided during the development. The decision on what to include in an increment depends on progress and on the customers priorities.

The customers priorities and requirements change so it makes sense to have a flexible plan that can accommodate these changes. Agile planning stages

 Release planning, which looks ahead for several months and decides on the features that should be included in a release of a system. Iteration planning, which has a shorter term outlook, and focuses on planning the next increment of a system. This is typically 2-4 weeks of work for the team. Planning in XP Requirements scenarios In XP, a customer or user is part of the XP team and is responsible for making decisions on requirements. User requirements are expressed as scenarios or user stories. These are written on cards and the development team break them down into implementation tasks. These tasks are the basis of schedule and cost estimates. The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates. Story-based planning The system specification in XP is based on user stories that reflect the features that should be included in the system. The project team read and discuss the stories and rank them in order of the amount of time they think it will take to implement the story. Release planning involves selecting and refining the stories that will reflect the features to be implemented in a release of a system and the order in which the stories should be implemented. Stories to be implemented in each iteration are chosen, with the number of stories reflecting the time to deliver an iteration (usually 2 or 3 weeks). A prescribing medication story Examples of task cards for prescribing medication Key points The price charged for a system does not just depend on its estimated development costs; it may be adjusted depending on the market and organizational priorities. Plan-driven development is organized around a complete project plan that defines the project activities, the planned effort, the activity schedule and who is responsible for each activity. Project scheduling involves the creation of graphical representations the project plan. Bar charts show the activity duration and staffing timelines, are the most commonly used schedule representations.

 The XP planning game involves the whole team in project planning. The plan is developed incrementally and, if problems arise, is adjusted. Software functionality is reduced instead of delaying delivery of an increment. Example: Work breakdown structure (WBS) References Sommerville, I. (2011). Software Engineering,9th edition, Pearson Education Inc. Pressman, R.S. (2009).Software Engineering: A Practitioners Approach, 7th edition, McGrawHill.

Chapter 3:
Software Cost Estimation Topics covered Cost estimation techniques Non-algorithmic approach Algorithmic approach COCOMO 2 Introduction

Software cost estimation = process of predicting the effort required to develop a software system Various estimation models Models can be classified into 2 categories: Algorithmic Non-algorithmic

Accurate software cost estimates are critical to both developers and customers Introduction Introduction Software cost estimation involves the determination of one or more of the following estimates: Effort (usually in person-months) Project duration (in calendar time)

Cost (in RM/dollar)

Estimation Estimation of resources, cost, and schedule for a software engineering effort requires experience access to good historical information (metrics) the courage to commit to quantitative predictions when qualitative information is all that exists

Estimation carries inherent risk and this risk leads to uncertainty Project Estimation Project scope must be understood Elaboration (decomposition) is necessary Historical metrics are very helpful At least two different techniques should be used Uncertainty is inherent in the process Cost Estimation Techniques Past (similar) project experience Conventional estimation techniques task breakdown and effort estimates size (e.g., FP) estimates

Empirical models Automated tools Cost Estimation Techniques Estimation Accuracy Predicated on the degree to which the planner has properly estimated the size of the product to be built the ability to translate the size estimate into human effort, calendar time, and dollars (a function of the availability of reliable software metrics from past projects) the degree to which the project plan reflects the abilities of the software team

the stability of product requirements and the environment that supports the software engineering effort.

Conventional Methods: LOC/FP Approach compute LOC/FP using estimates of information domain values use historical data to build estimates for the project Example: LOC Approach Example: FP Approach Process-Based Estimation Process-Based Estimation Example Tool-Based Estimation Estimation with Use-Cases Algorithmic cost modelling/ Empirical model Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers: Effort = A SizeB M A is an organisation-dependent constant, B reflects the disproportionate effort for large projects and M is a multiplier reflecting product, process and people attributes.

The most commonly used product attribute for cost estimation is code size. Most models are similar but they use different values for A, B and M. Estimation accuracy The size of a software system can only be known accurately when it is finished. Several factors influence the final size Use of COTS and components; Programming language; Distribution of system.

As the development process progresses then the size estimate becomes more accurate. The estimates of the factors contributing to B and M are subjective and vary according to the judgment of the estimator. Estimate uncertainty

 COCOMO 2 COCOMO 2 is actually a hierarchy of estimation models that address the following areas: Application composition model. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity are paramount. Early design stage model. Used once requirements have been stabilized and basic software architecture has been established. Post-architecture-stage model. Used during the construction of the software. The COCOMO 2 model An empirical model based on project experience. Well-documented, independent model which is not tied to a specific software vendor. Long history from initial version published in 1981 (COCOMO-81) through various instantiations to COCOMO 2. COCOMO 2 takes into account different approaches to software development, reuse, etc. COCOMO 2 models COCOMO 2 incorporates a range of sub-models that produce increasingly detailed software estimates. The sub-models in COCOMO 2 are: Application composition model. Used when software is composed from existing parts. Early design model. Used when requirements are available but design has not yet started. Reuse model. Used to compute the effort of integrating reusable components. Post-architecture model. Used once the system architecture has been designed and more information about the system is available.

COCOMO 2 estimation models Application composition model Supports prototyping projects and projects where there is extensive reuse. Based on standard estimates of developer productivity in application (object) points/month. Takes CASE tool use into account. Formula is PM = ( NAP (1 - %reuse/100 ) ) / PROD

PM is the effort in person-months, NAP is the number of application points and PROD is the productivity.

Application-point productivity Early design model Estimates can be made after the requirements have been agreed. Based on a standard formula for algorithmic models PM = A SizeB M where M = PERS RCPX RUSE PDIF PREX FCIL SCED; A = 2.94 in initial calibration, Size in KLOC, B varies from 1.1 to 1.24 depending on novelty of the project, development flexibility, risk management approaches and the process maturity.

Multipliers Multipliers reflect the capability of the developers, the non-functional requirements, the familiarity with the development platform, etc. RCPX - product reliability and complexity; RUSE - the reuse required; PDIF - platform difficulty; PREX - personnel experience; PERS - personnel capability; SCED - required schedule; FCIL - the team support facilities.

The reuse model Takes into account black-box code that is reused without change and code that has to be adapted to integrate it with new code. There are two versions: Black-box reuse where code is not modified. An effort estimate (PM) is computed. White-box reuse where code is modified. A size estimate equivalent to the number of lines of new source code is computed. This then adjusts the size estimate for new code.

Reuse model estimates 1 For generated code:

PM = (ASLOC * AT/100)/ATPROD ASLOC is the number of lines of generated code AT is the percentage of code automatically generated. ATPROD is the productivity of engineers in integrating this code.

Reuse model estimates 2 When code has to be understood and integrated: ESLOC = ASLOC * (1-AT/100) * AAM. ASLOC and AT as before. AAM is the adaptation adjustment multiplier computed from the costs of changing the reused code, the costs of understanding how to integrate the code and the costs of reuse decision making.

Post-architecture level Uses the same formula as the early design model but with 17 rather than 7 associated multipliers. The code size is estimated as: Number of lines of new code to be developed; Estimate of equivalent number of lines of new code computed using the reuse model; An estimate of the number of lines of code that have to be modified according to requirements changes.

The exponent term This depends on 5 scale factors (see next slide). Their sum/100 is added to 1.01 A company takes on a project in a new domain. The client has not defined the process to be used and has not allowed time for risk analysis. The company has a CMM level 2 rating. Precedenteness - new project (4) Development flexibility - no client involvement - Very high (1) Architecture/risk resolution - No risk analysis - V. Low .(5) Team cohesion - new team - nominal (3) Process maturity - some control - nominal (3)

Scale factor is therefore 1.17. Scale factors used in the exponent computation in the post-architecture model

 Multipliers Product attributes Concerned with required characteristics of the software product being developed.

Computer attributes Constraints imposed on the software by the hardware platform.

Personnel attributes Multipliers that take the experience and capabilities of the people working on the project into account.

Project attributes Concerned with the particular characteristics of the software development project.

The effect of cost drivers on effort estimates The effect of cost drivers on effort estimates Project duration and staffing As well as effort estimation, managers must estimate the calendar time required to complete a project and when staff will be required. Calendar time can be estimated using a COCOMO 2 formula TDEV = 3 (PM)(0.33+0.2*(B-1.01)) PM is the effort computation and B is the exponent computed as discussed above (B is 1 for the early prototyping model). This computation predicts the nominal schedule for the project.

The time required is independent of the number of people working on the project. Staffing requirements Staff required cant be computed by diving the development time by the required schedule. The number of people working on a project varies depending on the phase of the project. The more people who work on the project, the more total effort is usually required. A very rapid build-up of people often correlates with schedule slippage. Estimation for OO Projects-I Develop estimates using effort decomposition, FP analysis, and any other method that is applicable for conventional applications. Using object-oriented requirements modeling), develop use-cases and determine a count.

 From the analysis model, determine the number of key classes Categorize the type of interface for the application and develop a multiplier for support classes: Interface type No GUI Text-based user interface GUI Complex GUI 2.5 3.0 Multiplier 2.0 2.25

Estimation for OO Projects-II Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support classes. Multiply the total number of classes (key + support) by the average number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days per class. Cross check the class-based estimate by multiplying the average number of work-units per use-case Estimation for Agile Projects Each user scenario (a mini-use-case) is considered separately for estimation purposes. The scenario is decomposed into the set of software engineering tasks that will be required to develop it. Each task is estimated separately. Note: estimation can be based on historical data, an empirical model, or experience. Alternatively, the volume of the scenario can be estimated in LOC, FP or some other volume-oriented measure (e.g., use-case count).

Estimates for each task are summed to create an estimate for the scenario. Alternatively, the volume estimate for the scenario is translated into effort using historical data.

The effort estimates for all scenarios that are to be implemented for a given software increment are summed to develop the effort estimate for the increment. The Make-Buy Decision Computing Expected Cost Key points

 Estimation techniques for software may be experience-based, where managers judge the effort required, or algorithmic, where the effort required is computed from other estimated project parameters. The COCOMO 2 costing model is an algorithmic cost model that uses project, product, hardware and personnel attributes as well as product size and complexity attributes to derive a cost estimate. References Sommerville, I. (2011). Software Engineering,9th edition, Pearson Education Inc. Pressman, R.S. (2009).Software Engineering: A Practitioners Approach, 7th edition, McGrawHill.

Chapter 4
Topics covered Risk categories Risk management process Risk identification Risk analysis Risk planning Risk monitoring

Risk Management

Project Risks Risk management Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project. A risk is a probability that some adverse circumstance will occur Project risks affect schedule or resources; Product risks affect the quality or performance of the software being developed; Business risks affect the organisation developing or procuring the software.

Examples of common project, product, and business risks The risk management process Risk identification

Identify project, product and business risks;

Risk analysis Assess the likelihood and consequences of these risks;

Risk planning Draw up plans to avoid or minimise the effects of the risk;

Risk monitoring Monitor the risks throughout the project;

The risk management process Risk identification May be a team activities or based on the individual project managers experience. A checklist of common risks may be used to identify risks in a project Technology risks. People risks. Organisational risks. Requirements risks. Estimation risks.

Examples of different risk types Risk analysis Assess probability and seriousness of each risk. Probability may be very low, low, moderate, high or very high. Risk consequences might be catastrophic, serious, tolerable or insignificant. Risk types and examples Risk types and examples Risk planning Consider each risk and develop a strategy to manage that risk. Avoidance strategies The probability that the risk will arise is reduced;

Minimisation strategies The impact of the risk on the project or product will be reduced;

 Contingency plans If the risk arises, contingency plans are plans to deal with that risk;

Strategies to help manage risk Strategies to help manage risk Risk monitoring Assess each identified risks regularly to decide whether or not it is becoming less or more probable. Also assess whether the effects of the risk have changed. Each key risk should be discussed at management progress meetings. Risk indicators Recording Risk Information Key points Risk management is now recognized as one of the most important project management tasks. Risk management involves identifying and assessing project risks to establish the probability that they will occur and the consequences for the project if that risk does arise. You should make plans to avoid, manage or deal with likely risks if or when they arise.

Chapter 5
Topics covered Managing people Teamwork People-CMM (P-CMM)

Human Resource Management

Team Software Process (TSP) Managing people People are an organisations most important assets. The tasks of a manager are essentially people-oriented. Unless there is some understanding of people, management will be unsuccessful. Poor people management is an important contributor to project failure. People management factors Consistency

Team members should all be treated in a comparable way without favourites or discrimination.

Respect Different team members have different skills and these differences should be respected.

Inclusion Involve all team members and make sure that peoples views are considered.

Honesty You should always be honest about what is going well and what is going badly in a project.

Motivating people An important role of a manager is to motivate the people working on a project. Motivation means organizing the work and the working environment to encourage people to work effectively. If people are not motivated, they will not be interested in the work they are doing. They will work slowly, be more likely to make mistakes and will not contribute to the broader goals of the team or the organization.

Motivation is a complex issue but it appears that their are different types of motivation based on: Basic needs (e.g. food, sleep, etc.); Personal needs (e.g. respect, self-esteem); Social needs (e.g. to be accepted as part of a group).

Human needs hierarchy Need satisfaction In software development groups, basic physiological and safety needs are not an issue. Social Esteem Recognition of achievements; Appropriate rewards. Provide communal facilities; Allow informal communications e.g. via social networking

 Self-realization Training - people want to learn more; Responsibility.

Personality types The needs hierarchy is almost certainly an over-simplification of motivation in practice. Motivation should also take into account different personality types (Bass & Dunteman, 1963): Task-oriented; Self-oriented; Interaction-oriented.

Personality types Task-oriented. The motivation for doing the work is the work itself;

Self-oriented. The work is a means to an end which is the achievement of individual goals - e.g. to get rich, to play tennis, to travel etc.;

Interaction-oriented The principal motivation is the presence and actions of co-workers. People go to work because they like to go to work.

Motivation balance Individual motivations are made up of elements of each class. The balance can change depending on personal circumstances and external events. However, people are not just motivated by personal factors but also by being part of a group and culture. People go to work because they are motivated by the people that they work with. Teamwork Most software engineering is a group activity The development schedule for most non-trivial software projects is such that they cannot be completed by one person working alone.

 A good group is cohesive and has a team spirit. The people involved are motivated by the success of the group as well as by their own personal goals. Group interaction is a key determinant of group performance. Flexibility in group composition is limited Managers must do the best they can with available people.

Group cohesiveness In a cohesive group, members consider the group to be more important than any individual in it. The advantages of a cohesive group are: Group quality standards can be developed by the group members. Team members learn from each other and get to know each others work; Inhibitions caused by ignorance are reduced. Knowledge is shared. Continuity can be maintained if a group member leaves. Refactoring and continual improvement is encouraged. Group members work collectively to deliver high quality results and fix problems, irrespective of the individuals who originally created the design or program.

The effectiveness of a team The people in the group You need a mix of people in a project group as software development involves diverse activities such as negotiating with clients, programming, testing and documentation.

The group organization A group should be organized so that individuals can contribute to the best of their abilities and tasks can be completed as expected.

Technical and managerial communications Good communications between group members, and between the software engineering team and other project stakeholders, is essential.

Selecting group members A manager or team leaders job is to create a cohesive group and organize their group so that they can work together effectively. This involves creating a group with the right balance of technical skills and personalities, and organizing that group so that the members work together effectively. Assembling a team

 May not be possible to appoint the ideal people to work on a project Project budget may not allow for the use of highly-paid staff; Staff with the appropriate experience may not be available; An organisation may wish to develop employee skills on a software project.

Managers have to work within these constraints especially when there are shortages of trained staff. Group composition Group composed of members who share the same motivation can be problematic Task-oriented - everyone wants to do their own thing; Self-oriented - everyone wants to be the boss; Interaction-oriented - too much chatting, not enough work.

An effective group has a balance of all types. This can be difficult to achieve software engineers are often task-oriented. Interaction-oriented people are very important as they can detect and defuse tensions that arise. Group organization The way that a group is organized affects the decisions that are made by that group, the ways that information is exchanged and the interactions between the development group and external project stakeholders. Key questions include: Should the project manager be the technical leader of the group? Who will be involved in making critical technical decisions, and how will these be made? How will interactions with external stakeholders and senior company management be handled? How can groups integrate people who are not co-located? How can knowledge be shared across the group? Group organization Small software engineering groups are usually organised informally without a rigid structure. For large projects, there may be a hierarchical structure where different groups are responsible for different sub-projects.

 Agile development is always based around an informal group on the principle that formal structure inhibits information exchange Informal groups The group acts as a whole and comes to a consensus on decisions affecting the system. The group leader serves as the external interface of the group but does not allocate specific work items. Rather, work is discussed by the group as a whole and tasks are allocated according to ability and experience. This approach is successful for groups where all members are experienced and competent. Group communications Good communications are essential for effective group working. Information must be exchanged on the status of work, design decisions and changes to previous decisions. Good communications also strengthens group cohesion as it promotes understanding. Group communications Group size The larger the group, the harder it is for people to communicate with other group members.

Group structure Communication is better in informally structured groups than in hierarchically structured groups.

Group composition Communication is better when there are different personality types in a group and when groups are mixed rather than single sex.

The physical work environment Good workplace organisation can help encourage communications.

The People-CMM (P-CMM) a roadmap for implementing workforce practices that continuously improve the capability of an organizations workforce. *Bill Curtis+ The P-CMM is a maturity framework, patterned after the structure of the CMM that focuses on continuously improving the management and development of the human assets of a software or information systems organization

 The People-CMM (P-CMM) The motivation for the P-CMM is to radically improve the ability of software organizations to attract, develop, motivate, organize, and retain the talent needed to steadily improve software development capability. The P-CMM, defines capability as the level of knowledge, skills and process abilities available within each workforce competency of the organization to build its products or delivers its services. defines a set of five organizational maturity levels that provide an indication of the relative sophistication of workforce practices and processes. P-CMM Process Areas Team Software Process (TSP) Watts Humphrey developed the TSP to provide an operational process to help engineers consistently do quality work Teams are required for most engineering projects Systems development is a team activity and the effectiveness of the team largely determines the quality of the engineering Introduction to TSP A team is a group of people who share a common goal Teams require common processes; they need agreed upon goals; and they need effective guidance and leadership To be effective, teams must be properly skilled and be able to work as cohesive units TSP provides a defined operational process to guide engineers and managers through the team-building steps With a defined process and a plan that follows that process, engineers can be highly efficient TSP objectives TSP has 5 objectives: To build self-directed teams that plan and track their work, establish goals, and own their processes and plans To show managers how to coach and motivate their teams and how to help them sustain peak performance To accelerate sw process improvement by making CMM level 5-type behavior normal and expected To provide improvement guidance to high-maturity organizations

To facilitate university teaching of industrial-grade team skills

TSP Principles The engineers know the most about the job and can make the best plans When engineers plan their work, they are committed to the plan Precise project tracking requires detailed plans and accurate data Only the people doing the work can collect precise and accurate data To minimize cycle time, the engineers must balance their workload To maximize productivity, focus first on quality An Operational Team Process TSP Principal Elements TSP Life Cycle Key points People are motivated by interaction with other people, the recognition of management and their peers, and by being given opportunities for personal development. Software development groups should be fairly small and cohesive. The key factors that influence the effectiveness of a group are the people in that group, the way that it is organized and the communication between group members. Communications within a group are influenced by factors such as the status of group members, the size of the group, the gender composition of the group, personalities and available communication channels. Key points The P-CMM is a roadmap for organizational growth The P-CMM provides guidance for implementing practices in an organizational improvement program. TSP provides a defined operational process to guide engineers and managers through the team-building steps

Chapter 6
Documentation Objectives Describe different types of documentation

 Present guidelines for producing high-quality documents understand why it is important to produce some system documentation understand the standards that are important for document production Outline Process documentation Product documentation Document quality Document production Introduction managers and software engineers should pay as much attention to documentation and its associated costs as to the development of the software itself. Introduction The documents associated with a software project and the system being developed have a number of associated requirements: 1. They should act as a communication medium between members of the development team. 2. They should be an information repository to be used by maintenance engineers. 3. They should provide information for management to help them plan, budget and schedule the software development process. 4. Some of the documents should tell users how to use and administer the system. 5. They may be essential evidence to be presented to a regulator for system certification. Introduction The set of documents that you have to produce for any system depends on the contract with the client for the system, the type of system being developed and its expected lifetime, the culture and size of the company developing the system and the development schedule that it expected. Introduction Documentation produced during a software project normally falls into two classes: 1.Process documentation - These documents record the process of development and maintenance. Plans, schedules, process quality documents and organizational and project standards are process documentation. 2. Product documentation -This documentation describes the product that is being developed.

- System documentation describes the product from the point of view of the engineers developing and maintaining the system; - user documentation provides a product description that is oriented towards system users. Process Documentation Process documentation falls into a number of categories: 1. Plans, estimates and schedules - These are documents produced by managers which are used to predict and to control the software process. 2. Reports - These are documents which report how resources were used during the process of development. 3. Standards - These are documents which set out how the process is to be implemented. These may be developed from organizational, national or international standards. 4. Working papers -These are often the principal technical communication documents in a project. They record the ideas and thoughts of the engineers working on the project, are interim versions of product documentation, describe implementation strategies and set out problems which have been identified. They often, implicitly, record the rationale for design decisions. 5. E-mail messages, wikis, etc. These record the details of everyday communications between managers and development engineers. Process Documentation When a project is being carried out for an external customer, the amount of process documentation required depends on: 1. The contractual arrangements between the customer and the supplier 2. The attitude of the developers to contractual risk 3. The regulatory requirements Product Documentation Product documentation is concerned with describing the delivered software product Includes: User documentation System documentation Product Documentation User Documentation tells users how to use the software product

 users of a system are not all the same important to distinguish between end-users and system administrators: 1. End-users use the software to assist with some taks 2. System administrators are responsible for managing the software used by end-users Product Documentation Product Documentation User Documentation: -There has been a tendency over the past few years to cut documentation costs by eliminating user manuals and replacing these with on-line help systems. Unfortunately, these systems suffer from a number of problems: 1. They lack browsability in that they assume that users have a specific feature that they are interested in and wish to go immediately to the description of that feature. In many cases, however, users are interested in the set of features that are available and wish to have a general overview of the system. This can be gained from a sequential document such as a user manual but is much more difficult with a system that is implemented as linked, discrete chunks of information. Product Documentation 2. They are feature oriented rather than problem-oriented. Users who have a specific problem to address cannot find out how to do this if they do not understand the system features that they might use to solve the problem. On-line systems are, of course, useful but they are not a substitute for well-written user manuals Product Documentation System documentation includes all of the documents describing the system itself from the requirements specification to the final acceptance test plan. Documents describing the design, implementation and testing of a system are essential if the program is to be understood and maintained. essential that system documentation is structured, with overviews leading the reader into more formal and detailed descriptions of each aspect of the system. Product Documentation System documentation should include: 1. The requirements document and an associated rationale.

 2. A document describing the system architecture. 3. For each program in the system, a description of the architecture of that program. 4. For each component in the system, a description of its functionality and interfaces. 5. Program source code listings, which should be commented where the comments should explain complex sections of code and provide a rationale for the coding method used. 6. Validation documents describing how each program is validated and how the validation information relates to the requirements. 7. A system maintenance guide, which describes known problems with the system, describes which parts of the system are hardware and software dependent and which describes how evolution of the system has been taken into account in its design. Document Quality Document quality is as important as program quality. Achieving document quality requires management commitment to document design, standards, and quality assurance processes. Document Quality Document Structure: the way in which the material in the document is organized into chapters and, within these chapters, into sections and sub-sections. has a major impact on readability and usability and it is important to design this carefully when creating documentation design document structures so that the different parts are as independent as possible. Document Quality Document Structure : some minimal structuring guidelines: 1. All documents, however short, should have a cover page which identifies the project, the document, the author, the date of production, the type of document, configuration management and quality assurance information, the intended recipients of the document, and the confidentiality class of the document. It should also include information for document retrieval (an abstract or keywords) and a copyright notice 2. Documents that are more than a few pages long should be divided into chapters with each chapter structured into sections and sub-sections. A contents page should be produced listing these chapters, sections and subsections. A consistent numbering scheme for chapters, sections and subsections should be defined and chapters should be individually page

numbered (the page number should be chapter-page). This simplifies document change as individual chapters may be replaced without re-printing the whole document. 3. If a document contains a lot of detailed, reference information it should have an index. A comprehensive index allows information to be discovered easily and can make a badly written document usable. Without an index, reference documents are virtually useless. 4. If a document is intended for a wide spectrum of readers who may have differing vocabularies, a glossary should be provided which defines the technical terms and acronyms used in the document. Document Quality Writing Style document quality is fundamentally dependent on the writers ability to construct clear and concise technical prose. (further reading on Pg 11-12) Documentation standards Basis for document quality assurance. 1. Process standards These standards define the process that should be followed for high-quality document production. 2. Product standards These are standards that govern the documents themselves e.g. their organization and structure. 3. Interchange standards Virtually all documents are now stored in electronic formats. However, these may be developed at different times using different systems so interchange standards are required to ensure that all electronic copies of documents are compatible. (Further reading on Pg 13-16) Document Production the process of creating a document and formatting it for publication. three phases of preparation and associated support facilities are: 1. Document creation The initial input of the information in the document. 2. Document polishing This process involves improving the writing and presentation of the document to make to make it more understandable and readable. 3. Document production This is the process of preparing the document for professional printing. On-line Documentation Key Points

 Software documentation is used to describe the system to its users and to software engineers who are responsible for maintaining the system. Documentation at different levels of detail should be developed for different types of user. Agile methods try to eliminate documentation as it is often out of date and little used. However, some user documentation is necessary for almost all systems and documentation on the system requirements and architecture is useful for system maintenance. Document quality is very important if documents are to be useful. Documents should be wellstructured and written using simple and clear language. Documentation standards may be process standards, defining how documents should be produced, product standards, defining document organization or document interchange standards. Document management systems may be used in very large projects to ensure that documentation is maintained and readily accessible.

Chapter 7
Lecture 1 Topics covered Software quality Software standards Reviews and inspections

- Quality Management

Software measurement and metrics Software quality management Concerned with ensuring that the required level of quality is achieved in a software product. Three principal concerns: At the organizational level, quality management is concerned with establishing a framework of organizational processes and standards that will lead to high-quality software. At the project level, quality management involves the application of specific quality processes and checking that these planned processes have been followed. At the project level, quality management is also concerned with establishing a quality plan for a project. The quality plan should set out the quality goals for the project and define what processes and standards are to be used. Quality management activities

 Quality management provides an independent check on the software development process. The quality management process checks the project deliverables to ensure that they are consistent with organizational standards and goals The quality team should be independent from the development team so that they can take an objective view of the software. This allows them to report on software quality without being influenced by software development issues. Quality management and software development Quality planning A quality plan sets out the desired product qualities and how these are assessed and defines the most significant quality attributes. The quality plan should define the quality assessment process. It should set out which organisational standards should be applied and, where necessary, define new standards to be used. Quality plans Quality plan structure Product introduction; Product plans; Process descriptions; Quality goals; Risks and risk management. Quality plans should be short, succinct documents If they are too long, no-one will read them. Scope of quality management Quality management is particularly important for large, complex systems. The quality documentation is a record of progress and supports continuity of development as the development team changes. For smaller systems, quality management needs less documentation and should focus on establishing a quality culture. Software quality Quality, simplistically, means that a product should meet its specification. This is problematical for software systems

 There is a tension between customer quality requirements (efficiency, reliability, etc.) and developer quality requirements (maintainability, reusability, etc.); Some quality requirements are difficult to specify in an unambiguous way; Software specifications are usually incomplete and often inconsistent. The focus may be fitness for purpose rather than specification conformance. Software fitness for purpose Have programming and documentation standards been followed in the development process? Has the software been properly tested? Is the software sufficiently dependable to be put into use? Is the performance of the software acceptable for normal use? Is the software usable? Is the software well-structured and understandable? Software quality attributes Quality conflicts It is not possible for any system to be optimized for all of these attributes for example, improving robustness may lead to loss of performance. The quality plan should therefore define the most important quality attributes for the software that is being developed. The plan should also include a definition of the quality assessment process, an agreed way of assessing whether some quality, such as maintainability or robustness, is present in the product. Process and product quality The quality of a developed product is influenced by the quality of the production process. This is important in software development as some product quality attributes are hard to assess. However, there is a very complex and poorly understood relationship between software processes and product quality. The application of individual skills and experience is particularly important in software development; External factors such as the novelty of an application or the need for an accelerated development schedule may impair product quality. Process-based quality

 Software standards Standards define the required attributes of a product or process. They play an important role in quality management. Standards may be international, national, organizational or project standards. Product standards define characteristics that all software components should exhibit e.g. a common programming style. Process standards define how the software process should be enacted. Importance of standards Encapsulation of best practice- avoids repetition of past mistakes. They are a framework for defining what quality means in a particular setting i.e. that organizations view of quality. They provide continuity - new staff can understand the organisation by understanding the standards that are used. Product and process standards Problems with standards They may not be seen as relevant and up-to-date by software engineers. They often involve too much bureaucratic form filling. If they are unsupported by software tools, tedious form filling work is often involved to maintain the documentation associated with the standards. Standards development Involve practitioners in development. Engineers should understand the rationale underlying a standard. Review standards and their usage regularly. Standards can quickly become outdated and this reduces their credibility amongst practitioners. Detailed standards should have specialized tool support. Excessive clerical work is the most significant complaint against standards. Web-based forms are not good enough. ISO 9001 standards framework An international set of standards that can be used as a basis for developing quality management systems.

 ISO 9001, the most general of these standards, applies to organizations that design, develop and maintain products, including software. The ISO 9001 standard is a framework for developing software standards. It sets out general quality principles, describes quality processes in general and lays out the organizational standards and procedures that should be defined. These should be documented in an organizational quality manual. ISO 9001 core processes ISO 9001 and quality management ISO 9001 certification Quality standards and procedures should be documented in an organisational quality manual. An external body may certify that an organisations quality manual conforms to ISO 9000 standards. Some customers require suppliers to be ISO 9000 certified although the need for flexibility here is increasingly recognised. Key points Software quality management is concerned with ensuring that software has a low number of defects and that it reaches the required standards of maintainability, reliability, portability and so on. SQM includes defining standards for processes and products and establishing processes to check that these standards have been followed. Software standards are important for quality assurance as they represent an identification of best practice. Quality management procedures may be documented in an organizational quality manual, based on the generic model for a quality manual suggested in the ISO 9001 standard. Chapter 24 - Quality Management Lecture 2 Reviews and inspections A group examines part or all of a process or system and its documentation to find potential problems. Software or documents may be 'signed off' at a review which signifies that progress to the next development stage has been approved by management. There are different types of review with different objectives

 Inspections for defect removal (product); Reviews for progress assessment (product and process); Quality reviews (product and standards). Quality reviews A group of people carefully examine part or all of a software system and its associated documentation. Code, designs, specifications, test plans, standards, etc. can all be reviewed. Software or documents may be 'signed off' at a review which signifies that progress to the next development stage has been approved by management. The software review process Reviews and agile methods The review process in agile software development is usually informal. In Scrum, for example, there is a review meeting after each iteration of the software has been completed (a sprint review), where quality issues and problems may be discussed. In extreme programming, pair programming ensures that code is constantly being examined and reviewed by another team member. XP relies on individuals taking the initiative to improve and refactor code. Agile approaches are not usually standards-driven, so issues of standards compliance are not usually considered. Program inspections These are peer reviews where engineers examine the source of a system with the aim of discovering anomalies and defects. Inspections do not require execution of a system so may be used before implementation. They may be applied to any representation of the system (requirements, design,configuration data, test data, etc.). They have been shown to be an effective technique for discovering program errors. Inspection checklists Checklist of common errors should be used to drive the inspection.

 Error checklists are programming language dependent and reflect the characteristic errors that are likely to arise in the language. In general, the 'weaker' the type checking, the larger the checklist. Examples: Initialisation, Constant naming, loop termination, array bounds, etc. An inspection checklist (a) An inspection checklist (b) Agile methods and inspections Agile processes rarely use formal inspection or peer review processes. Rather, they rely on team members cooperating to check each others code, and informal guidelines, such as check before check-in, which suggest that programmers should check their own code. Extreme programming practitioners argue that pair programming is an effective substitute for inspection as this is, in effect, a continual inspection process. Two people look at every line of code and check it before it is accepted. Software measurement and metrics Software measurement is concerned with deriving a numeric value for an attribute of a software product or process. This allows for objective comparisons between techniques and processes. Although some companies have introduced measurement programmes, most organisations still dont make systematic use of software measurement. There are few established standards in this area. Software metric Any type of measurement which relates to a software system, process or related documentation Lines of code in a program, the Fog index, number of person-days required to develop a component. Allow the software and the software process to be quantified. May be used to predict product attributes or to control the software process. Product metrics can be used for general predictions or to identify anomalous components. Predictor and control measurements

 Use of measurements To assign a value to system quality attributes By measuring the characteristics of system components, such as their cyclomatic complexity, and then aggregating these measurements, you can assess system quality attributes, such as maintainability. To identify the system components whose quality is sub-standard Measurements can identify individual components with characteristics that deviate from the norm. For example, you can measure components to discover those with the highest complexity. These are most likely to contain bugs because the complexity makes them harder to understand. Metrics assumptions A software property can be measured. The relationship exists between what we can measure and what we want to know. We can only measure internal attributes but are often more interested in external software attributes. This relationship has been formalised and validated. It may be difficult to relate what can be measured to desirable external quality attributes. Relationships between internal and external software Problems with measurement in industry It is impossible to quantify the return on investment of introducing an organizational metrics program. There are no standards for software metrics or standardized processes for measurement and analysis. In many companies, software processes are not standardized and are poorly defined and controlled. Most work on software measurement has focused on code-based metrics and plan-driven development processes. However, more and more software is now developed by configuring ERP systems or COTS. Introducing measurement adds additional overhead to processes. Product metrics A quality metric should be a predictor of product quality. Classes of product metric

 Dynamic metrics which are collected by measurements made of a program in execution; Static metrics which are collected by measurements made of the system representations; Dynamic metrics help assess efficiency and reliability Static metrics help assess complexity, understandability and maintainability. Dynamic and static metrics Dynamic metrics are closely related to software quality attributes It is relatively easy to measure the response time of a system (performance attribute) or the number of failures (reliability attribute). Static metrics have an indirect relationship with quality attributes You need to try and derive a relationship between these metrics and properties such as complexity, understandability and maintainability. Static software product metrics Static software product metrics The CK object-oriented metrics suite The CK object-oriented metrics suite Software component analysis System component can be analyzed separately using a range of metrics. The values of these metrics may then compared for different components and, perhaps, with historical measurement data collected on previous projects. Anomalous measurements, which deviate significantly from the norm, may imply that there are problems with the quality of these components. The process of product measurement Measurement surprises Reducing the number of faults in a program leads to an increased number of help desk calls The program is now thought of as more reliable and so has a wider more diverse market. The percentage of users who call the help desk may have decreased but the total may increase; A more reliable system is used in a different way from a system where users work around the faults. This leads to more help desk calls. Key points

 Reviews of the software process deliverables involve a team of people who check that quality standards are being followed. In a program inspection or peer review, a small team systematically checks the code. They read the code in detail and look for possible errors and omissions Software measurement can be used to gather data about software and software processes. Product quality metrics are particularly useful for highlighting anomalous components that may have quality problems.

Chapter 8
Topics covered Change management Version management System building Release management Configuration management

Configuration Management

Because software changes frequently, systems, can be thought of as a set of versions, each of which has to be maintained and managed. Versions implement proposals for change, corrections of faults, and adaptations for different hardware and operating systems. 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 activities 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. 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. Release management Preparing software for external release and keeping track of the system versions that have been released for customer use. Configuration management activities CM terminology CM terminology 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. The change management process A partially completed change request form (a) A partially completed change request form (b) 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 Change management and agile methods 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. Derivation history 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 codelines and baselines. Codelines and baselines A codeline is a sequence of versions of source code with later versions in the sequence derived from earlier versions. Codelines 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. Codelines and baselines Baselines 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 management systems Version and release identification Managed versions are assigned identifiers when they are submitted to the system. Storage management

 To reduce the storage space required by multiple versions of components that differ only slightly, version management systems usually provide storage management facilities. Change history recording All of the changes made to the code of a system or component are recorded and listed. Version management systems Independent development The version management system keeps track of components that have been checked out for editing and ensures that changes made to a component by different developers do not interfere. Project support A version management system may support the development of several projects, which share components. Storage management using deltas Check-in and check-out from a version repository Codeline branches Rather than a linear sequence of versions that reflect changes to the component over time, there may be several independent sequences. This is normal in system development, where different developers work independently on different versions of the source code and so change it in different ways. At some stage, it may be necessary to merge codeline branches to create a new version of a component that includes all changes that have been made. If the changes made involve different parts of the code, the component versions may be merged automatically by combining the deltas that apply to the code. Branching and merging Key points Configuration management is the management of an evolving software system. When maintaining a system, a CM team is put in place to ensure that changes are incorporated into the system in a controlled way and that records are maintained with details of the changes that have been implemented. The main configuration management processes are change management, version management, system building and release management.

 Change management involves assessing proposals for changes from system customers and other stakeholders and deciding if it is cost-effective to implement these in a new version of a system. Version management involves keeping track of the different versions of software components as changes are made to them. System building System building is the process of creating a complete, executable system by compiling and linking the system components, external libraries, configuration files, etc. System building tools and version management tools must communicate as the build process involves checking out component versions from the repository managed by the version management system. The configuration description used to identify a baseline is also used by the system building tool. Build platforms The development system, which includes development tools such as compilers, source code editors, etc. Developers check out code from the version management system into a private workspace before making changes to the system. The build server, which is used to build definitive, executable versions of the system. Developers check-in code to the version management system before it is built. The system build may rely on external libraries that are not included in the version management system. The target environment, which is the platform on which the system executes. Development, build, and target platforms System building Build system functionality Build script generation Version management system integration Minimal re-compilation Executable system creation Test automation Reporting Documentation generation

 Agile building Check out the mainline system from the version management system into the developers private workspace. Build the system and run automated tests to ensure that the built system passes all tests. If not, the build is broken and you should inform whoever checked in the last baseline system. They are responsible for repairing the problem. Make the changes to the system components. Build the system in the private workspace and rerun system tests. If the tests fail, continue editing. Agile building Once the system has passed its tests, check it into the build system but do not commit it as a new system baseline. Build the system on the build server and run the tests. You need to do this in case others have modified components since you checked out the system. If this is the case, check out the components that have failed and edit these so that tests pass on your private workspace. If the system passes its tests on the build system, then commit the changes you have made as a new baseline in the system mainline. Continuous integration Daily building The development organization sets a delivery time (say 2 p.m.) for system components. If developers have new versions of the components that they are writing, they must deliver them by that time. A new version of the system is built from these components by compiling and linking them to form a complete system. This system is then delivered to the testing team, which carries out a set of predefined system tests Faults that are discovered during system testing are documented and returned to the system developers. They repair these faults in a subsequent version of the component. 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. 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. 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. Release timing 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. Release components As well as the the executable code of the system, a release may also include: configuration files defining how the release should be configured for particular installations; 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 Factors influencing system release planning Key points System building is the process of assembling system components into an executable program to run on a target computer system. Software should be frequently rebuilt and tested immediately after a new version has been built. This makes it easier to detect bugs and problems that have been introduced since the last build. System releases include executable code, data files, configuration files and documentation. Release management involves making decisions on system release dates, preparing all information for distribution and documenting each system release.

Chapter 9:
Project Communications Management Topics covered Communications Planning Information distribution Performance reporting Administrative closure Introduction Introduction Project Communications Management (PCM) = processes required to ensure timely and appropriate generation, collection, dissemination, storage, and ultimate disposition of project information Provides critical links among people, ideas, and information for success Project Communication Management FOUR major processes: Communications Planning (CP) Information Distribution (ID) Performance Reporting (PR)

 Administratvie Closure (AC) Communications Planning (CP) Determining the information and communications needs of the stakeholders Who needs what information When will they need it How will it be given to them Done as part of the earliest project phases Tightly linked with organizational planning Communications Planning (CP) Inputs to CP: Communications requirements Sum of the information requirements of the project stakeholders Project organization & stakeholder responsibility relationships Disciplines, departments, & specialties involved in the project Logistics External information needs Communications technology Constraints assumptions Communications Planning (CP) Inputs to CP: Communications technology Technologies or methods used to transfer information Factors which may affect the project: Immediacy of the need for information Availability of technology Expected project staffing Length of the project Constraints

 assumptions Communications Planning (CP) Inputs to CP: Constraints Factors that will limit the project management teams options Assumptions Factors that, for planning purposes, will be considered to be true, real or certain Involve a degree of risk Communications Planning (CP) Tools and Techniques for CP: Stakeholder analysis Information needs of various stakeholders should be analyzed to develop a methodical and logical view of their information needs and sources to meet those needs Outputs from CP Communications management plan- a document Maybe formal or informal, highly detailed or broadly framed (based on the needs of the project) Information Distribution (ID) Making needed information available to project stakeholders in a timely manner Implementing the CM plan as well as responding to unexpected requests for information Information Distribution (ID) Inputs to ID Work results Communications management plan Project plan Tools & Techniques for ID Communications skills Information retrieval systems

 Information distribution systems Output from ID Project records (memos, reports, documents, etc.) Performance Reporting(PR) Involves collecting and disseminating performance information in order to provide stakeholders with information about how resources are being used to achieve project objectives Provide information on scope, schedule, cost, and quality Includes Status reporting Progress reporting forecasting Performance Reporting(PR) Inputs to PR Project plan Work results Other project records Tools & techniques for PR Performance reviews Variance analysis Trend analysis Earned value analysis Information Outputs from PR Performance reports Change requests Administrative Closure (AC) Generating, gathering, and disseminating information to formalize phase or project completion

 Verifying and documenting project results to formalize acceptance of the product of the project by the sponsor, client or customer Includes collection of project records ensuring that they reflect final specifications, analysis of project success and effectiveness, and archiving such information for future use Administrative Closure (AC) Inputs to AC Performance measurement documentation Documentation of the product of the project Other project records Tools & techniques for AC Performance reporting tools and techniques Outputs from AC Project archives Formal acceptance Lessons learned Key points Everyone involved in a project must be prepared to send and receive communications in the project language and must understand how the communications they are involved in as individuals affect the project as a whole 4 major processes: Communication planning Information distribution Performance reporting Administrative close