Kuppusamy P, profile picture
Uploaded byKuppusamy P
PDF, PPTX1,903 views

Software management disciplines

The document discusses software management disciplines including iterative process planning, project organizations and responsibilities, and process automation. It focuses on work breakdown structures (WBS) in iterative process planning. It describes how a conventional WBS can have issues but an evolutionary WBS organized around workflows rather than product frameworks can address those issues. It also discusses planning guidelines, cost and schedule estimating processes, iteration planning processes, and pragmatic planning approaches. Finally, it outlines typical project organizations, roles, and responsibilities including for line-of-business organizations and project teams.

Education◦
Related topics:
Process Automation•

Embed presentation

Download as PDF, PPTX
Software Management Disciplines • Iterative Process Planning  Work Breakdown Structures  Planning Guidelines  The Cost and Schedule Estimating Process  The Iteration Planning Process  Pragmatic Planning • Project Organizations and Responsibilities  Line-of-Business organizations  Project Organizations  Evolution Organizations • Process Automation  Tools: Automation Building Blocks  The Project Environment
Work Breakdown Structures in Iterative Process Planning • The development of WBS is dependent on the project management style, organizational culture, customer preference, financial constraints and several other hard-to-define parameters. • A WBS is simply a hierarchy of elements that decomposes the project plan into the discrete work tasks. A WBS provides the following information structure: A delineation of all significant work  A clear task decomposition for assignment of responsibilities  A framework for scheduling, budgeting, and expenditure tracking. CONVENTIONAL WBS ISSUES: 1. They are prematurely structured around the product design. - Allocated to responsible managers with budgets, schedules, and expected deliverables, a concrete planning foundation. 2. They are prematurely decomposed, planned, and budgeted in either too much or too little detail - team plans out each element completely and creates a baseline budget and schedule for every task at the same level of detail. On the other hand, most small-scale or in-house developments elaborate their WBSs to a single level only, without supporting detail. 3. They are project-specific, and cross-project comparisons are usually difficult or impossible - With no standard WBS structure, it is extremely difficult to compare plans, financial data, schedule data, organizational efficiencies, cost trends, productivity trends, or quality trends across multiple projects. Each project organizes the work differently and uses different units of measure
Hierarchy of Conventional WBS
Evolutionary of Work Breakdown Structures An evolutionary WBS should organize the planning elements around the process framework rather than the product framework. • First-level WBS elements are the workflows (management, environment, requirements, design, implementation, assessment, and deployment). These elements are usually allocated to a single team and constitute the anatomy of a project for the purposes of planning and comparison with other projects. • Second-level elements are defined for each phase of the life cycle (inception, elaboration, construction, and transition). These elements allow the fidelity of the plan to evolve more naturally with the level of understanding of the requirements and architecture, and the risks therein. • Third-level elements are defined for the focus of activities that produce the artifacts of each phase. These elements may be the lowest level in the hierarchy that collects the cost of a discrete artifact for a given phase, or they may be decomposed further into several lower level activities that, taken together, produce a single artifact.
Evolutionary of Work Breakdown Structures • Scale - Larger projects will have more levels and substructures. • Organizational structure - Projects that include subcontractors or span multiple organizational entities may introduce constraints that necessitate different WBS allocations. • Degree of custom development - Depending on the character of the project, there can be very different emphases in the requirements, design, and implementation workflows. A business process re-engineering project based primarily on existing components.
Evolutionary of Work Breakdown Structures Situation-Complication-Question (SCQ)
Evolutionary of Work Breakdown Structures
Planning guidelines in iterative process planning • It is valuable because most people in management positions are looking for a starting point, a skeleton they can flesh out with project-specific details. They know that initial planning guidelines capture the expertise and experience of many other people that instill some confidence in the stakeholders. Evolution of planning fidelity in the WBS over the life cycle
Planning guidelines in iterative process planning • Two simple planning guidelines should be considered when a project plan is being initiated or assessed. The first guideline prescribes a default allocation of costs among the first-level WBS elements The second guideline prescribes the allocation of effort and schedule across the life-cycle phases FIRST-LEVEL WBS ELEMENT DEFAULT BUDGET Management 10% Environment 10% Requirements 10% Design 15% Implementation 25% Assessment 25% Deployment 5% Total 100% DOMA IN INCEPT ION ELABORA TION CONSTRUC TION TRANSI TION Effort 5% 20% 65% 10% Sched ule 10% 30% 50% 10%
Planning guidelines in iterative process planning 1. The cost of different labor categories is inherent in these numbers. For example, the management, requirements, and design elements tend to use more personnel who are senior and more highly paid than the other elements use. If requirements and design together consume 25% of the budget (employing people with an average salary of $100/hour), this sum may represent half as many staff hours as the assessment element, which also accounts for 25% of the budget but employs personnel with an average salary of $50/hour. 2. The cost of hardware and software assets that support the process automation and development teams is also included in the environment element.
The Cost and Schedule Estimating Process in Iterative Process Planning • Project plans need to be derived from two perspectives. 1. forward-looking, 2. top-down approach.  Forward-looking: 1. The software project manager develops a characterization of the overall size, process, environment, people, and quality required for the project 2. A macro-level estimate of the total effort and schedule is developed using a software cost estimation model 3. The software project manager partitions the estimate for the effort into a top-level WBS, also partitions the schedule into major milestone dates and partitions the effort into a staffing profile 4. At this point, subproject managers are given the responsibility for decomposing each of the WBS elements into lower levels using their top-level allocation, staffing profile, and major milestone dates as constraints.
The Cost and Schedule Estimating Process in Iterative Process Planning  Backward-looking: 1. The lowest level WBS elements are elaborated into detailed tasks, for which budgets and schedules are estimated by the responsible WBS element manager. 2. Estimates are combined and integrated into higher level budgets and milestones. Comparisons are made with the top-down budgets and schedule milestones. Gross differences are assessed and adjustments are made in order to converge on agreement between the top-down and the bottom-up estimates. • These two planning approaches should be used together, in balance, throughout the life cycle of the project. • During the engineering stage, the top-down perspective will dominate because there is usually not enough depth of understanding nor stability in the detailed task sequences to perform credible bottom-up planning. • During the production stage, there should be enough precedent experience and planning fidelity that the bottom-up planning perspective will dominate. • By then, the top-down approach should be well tuned to the project-specific parameters, so it should be used more as a global assessment technique.
Iteration Planning Process Engineering Stage Production Stage Inception Elaboration Construction Transition Feasibility iterations Architecture iterations Usable iterations Product releases Iteration is used to mean a complete synchronization across the project, with a well- orchestrated global assessment of the entire project baseline. Other micro-iterations, such as monthly, weekly, or daily builds, are performed enroute to these project-level synchronization points.
Iteration Planning Process Engineering stage planning emphasis:  Macro-level task estimation for production-stage artifacts  Micro-level task estimation for engineering artifacts  Stakeholder concurrence  Coarse-grained variance analysis of actual vs. planned expenditures  Tuning the top-down project- independent planning guidelines into project-specific planning guidelines. Production stage planning emphasis:  Micro-level task estimation for production-stage artifacts  Macro-level task estimation for engineering artifacts  Stakeholder concurrence  Fine-grained variance analysis of actual vs. planned expenditures
Iteration Planning Process Inception iterations. Integrate the foundation components of a candidate architecture and provide an executable framework for elaborating phase. It includes existing components, commercial components, and custom prototypes sufficient to demonstrate a candidate architecture and sufficient requirements understanding to establish a credible business case, vision, and software development plan. Elaboration iterations. These iterations result in an architecture, including a complete framework and infrastructure for execution. Upon completion of the architecture iteration, a few critical use cases should be demonstrable: (1) initializing the architecture, (2) injecting a scenario to drive the worst-case data processing flow through the system (3) injecting a scenario to drive the worst-case control flow through the system. Construction iterations. Require at least two major construction iterations: an alpha release and a beta release. An alpha release would include executable capability for all the critical use cases. It usually represents only about 70% of the total product performance and reliability. Beta release provides 95% of the total quality attributes. Transition iterations. Single iteration to transition a beta release into the final product. Small- scale iterations may be necessary to resolve all the defects, incorporate beta feedback, incorporate performance improvements.
PRAGMATIC PLANNING • Good planning is more dynamic. While executing iteration N of any phase, the software project manager must be monitoring and controlling against a plan that was initiated in iteration N - 1 and must be planning iteration N + 1. The art of good project management is to make trade-offs in the current iteration plan and the next iteration plan based on objective results in the current iteration and previous iterations. It overwhelming in early phases or in projects that are pioneering iterative development. • Aside from bad architectures and misunderstood requirements, inadequate planning are most common reasons for project failures. Conversely, the success of every successful project can be attributed in part to good planning. Three essential perspectives are: planning, requirements, and architecture. The end products associated with these perspectives (software development plan, requirements specifications, and architecture description document) are not emphasized. Project's plan defines how the project requirements will be transformed into a product within the business constraints. It must be realistic, current, team product, understood by the stakeholders, and used. • Plans are not just for managers. The more open and visible planning process and results, more ownership among the team members who need to execute it. Good, open plans can shape cultures and encourage teamwork.
Project Organizations and Responsibilities • Software lines of business are motivated by return on investment, new business discriminators, market diversification, and profitability. • Project teams are motivated by the cost, schedule, and quality of specific deliverables. LINE-Of-BUSINESS ORGANIZATIONS Main features of the default organization: • Responsibility for process definition and maintenance is specific to a cohesive line of business, where process commonality makes sense. For example, the process for developing avionics software is different from the process used to develop office applications. • Responsibility for process automation is an organizational role and is equal in importance to the process definition role. Projects achieve process commonality primarily through the environment support of common tools. • Organizational roles may be fulfilled by a single individual or several different teams, depending on the scale of the organization. A 20-person software product company may require only a single person to fulfill all the roles, while a 10,000-person telecommunications company may require 100 people to achieve the work.
Line-of-Business Organizations Default roles in a software line-of-business organizations Project A Manager Project B Manager Project N Manager Organization Manager Software Engineering Process Authority Software Engineering Environment Authority Project Review Authority Infrastructure • Process definition • Process improvement • Process automation • Project compliance • Periodic risk assessment • Project administration • Engineering skill centers • Professional development
Line-of-Business Organizations Roles Software Engineering Process Authority • The Software Engineering Process Authority (SEPA) facilitates the exchange of information and process guidance both to and from project practitioners. The organization general manager for maintaining a current assessment of the organization's process maturity and its plan for future process improvements. • The SEPA must help initiate and periodically assess project processes. Catalyzing the capture and dissemination of software best practices can be accomplished only when the SEPA understands both the desired improvement and the project context. SEPA takes on responsibility and accountability for the process definition and its maintenance (modification, improvement, technology insertion). The SEPA could be a single individual, the general manager, or even a team of representatives. The SEPA must truly be an authority, competent and powerful. Project Review Authority • The Project Review Authority (PRA) is the single individual responsible for ensuring that a organizational and business unit software policies, practices, and standards. • A software project manager is responsible for meeting the requirements of a contract or some other project compliance standards. The PRA reviews both the project's conformance to contractual obligations and the project's organizational policy obligations. • The customer monitors contract requirements, contract milestones, contract deliverables, monthly management reviews, progress, quality, cost, schedule, and risk. • The PRA reviews customer commitments as well as adherence to organizational policies, organizational deliverables, financial performance, and other risks and accomplishments.
Line-of-Business Organizations Roles Software Engineering Environment Authority • The Software Engineering Environment Authority (SEEA) is responsible for automating the organization's process, maintaining the organization's standard environment, training projects to use the environment, and maintaining organization-wide reusable assets. • The SEEA role is necessary to achieve a significant return on investment for a common process. Tools, techniques, and training can be amortized effectively across multiple projects. In many cases, the environment may be augmented, customized, or modified, but the existence of an 80% default solution for each project is critical to achieving institutionalization of the organization's process and a good RoI on capital tool investments. Infrastructure • An organization's infrastructure provides human resources support, project-independent research and development, and other capital software engineering assets. • The typical components of the organizational infrastructure are as follows: • Project administration: time accounting system; contracts, pricing, terms and conditions; corporate information systems integration • Engineering skill centers: custom tools repository and maintenance, bid and proposal support, independent research and development • Professional development: internal training boot camp, personnel recruiting, personnel skills database maintenance, literature and assets library, technical publications
Project Organizations The main features of the default organization are as follows: • The project management team is an active participant, responsible for producing as well as managing. Project management is not a spectator sport. • The architecture team is responsible for real artifacts and for the integration of components, not just for staff functions. • The development team owns the component construction and maintenance activities. • The assessment team is separate from development. This structure fosters an independent quality perspective and focuses a team on testing and product evaluation activities concurrent with on-going development. • Quality is everyone's job, integrated into all activities and checkpoints. Each team takes responsibility for a different quality perspective.
Project Organizations Software Management Team Inception Elaboration Construction Transition Elaboration phase planning Team formulating Contract baselining Architecture costs Construction phase planning Full staff recruitment Risk resolution Product acceptance criteria Construction costs Transition phase planning Construction plan optimization Risk management Customer satisfaction Contract closure Sales support Next-generation planning Artifacts  Business case  Vision  Software development plan  Work breakdown structure  Status assessments  Requirements set  Systems Engineering  Financial Administration  Quality Assurance Responsibilities  Resource commitments  Personnel assignments  Plans, priorities,  Stakeholder satisfaction  Scope definition  Risk management  Project control Life-Cycle Focus
Software Management Team • Most projects are over constrained. Schedules, costs, functionality, and quality expectations are highly interrelated and require continuous negotiation among multiple stakeholders who have differing goals. • The software management team carries the burden of delivering win conditions to all stakeholders. • In this regard, the software project manager spends every day worrying about balance. Figure shows the software management team activities over the project life cycle. • The software management team is responsible for planning the effort, conducting the plan, and adapting the plan to changes in the understanding of the requirements or the design. • Toward this end, the team takes ownership of resource management and project scope, and sets operational priorities across the project life cycle. • At an abstract level, these activities correspond to managing the expectations of all stakeholders throughout the project life cycle. • The software management team takes ownership of all aspects of quality. In particular, it is responsible for attaining and maintaining a balance among these aspects so that the overall solution is adequate for all stakeholders and optimal for as many of them as possible.
Project Organizations Roles Software Architecture Team Inception Elaboration Construction Transition Architecture prototyping Make/buy trade-offs Primary scenario definition Architecture evaluation criteria definition Architecture base lining Primary scenario demonstration Make/buy trade-offs base lining Architecture maintenance Multiple-component issue resolution Performance tuning Quality improvements Architecture maintenance Multiple-component issue resolution Performance tuning Quality improvements Artifacts  Architecture description  Requirements set  Design set  Release specifications  Demonstrations  Use-case modelers  Design modelers  Performance analysts Responsibilities  Requirements trade-offs  Design trade-offs  Component selection  Initial integration  Technical risk solution Life-Cycle Focus
Software Architecture Team • The software architecture team is responsible for the architecture. This responsibility encompasses the engineering necessary to specify a complete bill of materials for the software and the engineering necessary to make significant make/buy trade-offs. • So that all custom components are elaborated to the extent that construction/assembly costs are highly predictable. • For any project, the skill of the software architecture team is crucial. It provides the framework for facilitating team communications, for achieving system-wide qualities, and for implementing the applications. • With a good architecture team, an average development team can succeed. If the architecture is weak, even an expert development team of superstar programmers will probably not succeed. To succeed, the architecture team must includes o Domain experience to produce an acceptable design view and use case view o Software technology experience to produce an acceptable process view, component view and deployment view.
Project Organizations Roles Software Development Team Inception Elaboration Construction Transition Prototyping support Make/buy trade-offs Critical component design Critical component implementation and test Critical component base line Component design Component implementation Component stand-alone test Component maintenance Component maintenance Component documentation Artifacts  Design set  Implementation set  Deployment set  Component teams Responsibilities  Component design  Component implementation  Component stand-alone test  Component maintenance  Component documentation Life-Cycle Focus
Software Development Team Typical skill sets includes: • Commercial component: specialists with detailed knowledge of commercial components central to a system's architecture • Database: specialists with experience in the organization, storage, and retrieval of data • Graphical user interfaces: specialists with experience in the display organization, data presentation, and user interaction necessary to support human input, output, and control needs • Operating systems and networking: specialists with experience in the execution of multiple software objects on a network of hardware resources, including all the typical control issues associated with initialization, synchronization, resource sharing, name space management, reconfiguration, termination, and inter object communications • Domain applications: specialists with experience in the algorithms, application processing, or business rules specific to the system
Project Organizations Roles Software Assessment Team Inception Elaboration Construction Transition Infrastructure planning Primary scenario prototyping Infrastructure base lining Architecture release testing Change management Initial user manual Infrastructure upgrades Release testing Change management User manual base line Requirements verification Infrastructure maintenance Release base lining Change management Deployment to users Requirements verification Artifacts  Deployment set  SCO database  User manual  Environment  Release specifications  Release descriptions  Deployment documents  Release testing  Change management  Deployment  Environment support Responsibilities  Project infrastructure  Independent testing  Requirements verification  Metrics analysis  Configuration control  Change management  User deployment Life-Cycle Focus
Software Assessment Team There are two reasons for using an independent team for software assessment. • The first is ensuring an independent quality perspective. • It has pros such as ensuring that the ownership biases of developers do not pollute the assessment of quality and cons such as relieving the software development team of ownership in quality, to some extent. • A more important reason for using an independent test team is to exploit the concurrency of activities. • Schedules can be accelerated by developing the software and preparing for testing in parallel with development activities. • Change management, test planning, and test scenario development can be performed in parallel with design and development. A modern process should employ use-case-oriented or capability-based testing organized as a sequence of builds and mechanized via two artifacts: 1. Release specification (the plan and evaluation criteria for a release) 2. Release description (the results of a release)
Evolution of Organizations Software management 50% Software assessment 10% Software development 20% Software architecture 20% Software management 10% Software assessment 20% Software development 20% Software architecture 50% Software management 10% Software assessment 50% Software development 35% Software architecture 5% Software management 10% Software assessment 30% Software development 50% Software architecture 10% Inception Elaboration Transition Construction Staff Allotment
Evolution of Organizations • The project organization represents the architecture of the team and needs to evolve consistent with the project plan captured in the work breakdown structure. • The team's center of gravity shifts over the life cycle, with about 50% of the staff assigned to one set of activities in each phase. A different set of activities is emphasized in each phase, as follows: • Inception team: an organization focused on planning, with enough support from the other teams to ensure that the plans represent a consensus of all perspectives. • Elaboration team: an architecture-focused organization in which the driving forces of the project reside in the software architecture team and supported by the software development and software assessment teams as necessary to achieve a stable architecture baseline. • Construction team: a fairly balanced organization in which most of the activity resides in the software development and software assessment teams Transition team: a customer- focused organization in which usage feedback drives the deployment activities • It is equally important to elaborate the details of sub teams, responsibilities, and work packages, but not until the planning details in the WBS are stable. Defining all the details of lower level team structures prematurely can result in serious downstream inefficiencies.
Process Automation • Automation needs to improve the predictability of software management and performance of their software lines of business (in terms of product quality, time to market, return on investment, and productivity). • Most software organizations are confronted with the task of integrating their own environment and infrastructure for software development. • This process typically results in the selection of more or less incompatible tools that have different information repositories, are supplied by different vendors, work on different platforms. • Integrating such an infrastructure has proven to be much more problematic than expected. • To avoid the issues automation is required in software development.
Three levels of process Metaprocess, Macroprocess, and Microprocess Each level requires a certain degree of process automation for efficient process: 1. Metaprocess: An organization's policies, procedures, and practices for managing a software- intensive line of business. The automation support for this level is called an infrastructure that includes tools, artifact templates, microprocess guidelines, macroprocess guidelines, project performance repository, database of organizational skill sets, and library of precedent examples of past project plans and results. 2. Macroprocess: A project's policies, procedures, and practices for producing a complete software product within certain cost, schedule, and quality constraints. The automation support for a project's process is called an environment. An environment is a specific collection of tools to produce a specific set of artifacts as governed by a specific project plan.
Three levels of process 3. Microprocess: A project team's policies, procedures, and practices for achieving an artifact of the software process. The automation support for generating an artifact is generally called a tool. Typical tools include requirements management, visual modeling, compilers, editors, debuggers, change management, metrics automation, document automation, test automation, cost estimation, and workflow automation.
TOOLS: AUTOMATION BUILDING BLOCKS Typical automation and tool components that support the process workflows
TOOLS: AUTOMATION BUILDING BLOCKS • Management • There are many opportunities for automating the project planning and control activities of the management workflow. • Software cost estimation tools and WBS tools are useful for generating the planning artifacts. • It uses on-line version of the status assessment are advantageous. • This automation improves the insight of the metrics collection and reporting. • Environment • Configuration management and version control are essential in a modern iterative development process. • Much of the metrics dependent on measuring changes in software artifact baselines.
TOOLS: AUTOMATION BUILDING BLOCKS • Requirements • Conventional approaches decomposed system requirements into subsystem requirements, subsystem requirements into component requirements, and component requirements into unit requirements. • The equal treatment of all requirements drained away engineering hours from the driving requirements, then wasted that time on paperwork associated with detailed traceability that was inevitably discarded later as the driving requirements and subsequent design understanding evolved. • Lower levels of requirements are driven by the process-organized by iteration rather than by lower level component-in the form of evaluation criteria. • Evaluation criteria are captured in the release specification artifacts, which are transient snapshots of objectives for a given iteration. • Evaluation criteria are derived from the vision statement as well as from many other sources, such as make/buy analyses, risk management concerns, architectural considerations, implementation constraints, quality thresholds, and even shots in the dark.
TOOLS: AUTOMATION BUILDING BLOCKS • Design • The tools that support the requirements, design, implementation, and assessment workflows are usually used together. • The primary support required for the design workflow is visual modeling, which is used for capturing design models, presenting them in human-readable format, and translating them into source code. • An architecture-first and demonstration-based process is enabled by existing architecture components and middleware. • Implementation • It relies primarily on a programming environment (editor, compiler, debugger, linker, run time) with the change management tools, visual modeling tools, and test automation tools to support productive iteration. • Assessment and Deployment • Requires to support test automation and test management. • To increase change freedom, testing and document production must be mostly automated. • Defect tracking is a tool that supports assessment. It provides the change management instrumentation necessary to automate metrics and control release baselines. It is also needed to support the deployment workflow throughout the life cycle.
PROJECT ENVIRONMENT The project environment artifacts evolve through three discrete states: 1. Prototyping environment, 2. Development environment, and 3. Maintenance environment. 1. The prototyping environment • Includes an architecture testbed for prototyping project architectures to evaluate trade-offs during the inception and elaboration phases. • This informal configuration of tools should be capable of supporting the following activities: • Performance trade-offs and technical risk analyses • Make/buy trade-offs and feasibility studies for commercial products • Fault tolerance/dynamic reconfiguration trade-offs • Analysis of the risks associated with transitioning to full-scale implementation • Development of test scenarios, tools, and instrumentation suitable for analyzing the requirements 2. The development environment • It should include a full suite of development tools needed to support the various process workflows and to support round-trip engineering to the maximum extent possible.
PROJECT ENVIRONMENT • 3. The maintenance environment • It should typically coincide with a mature version of the development environment. In some cases, the maintenance environment may be a subset of the development environment delivered as one of the project's end products. Four important environment disciplines to the success of a modern iterative development process: 1. Tools must be integrated to maintain consistency and traceability. Roundtrip engineering is the term used to describe this key requirement for environments that support iterative development. 2. Change management must be automated and enforced to manage multiple iterations and to enable change freedom. 3. Organizational infrastructures enable project environments to be derived from a common base of processes and tools. A common infrastructure promotes inter- project consistency, reuse of training, reuse of lessons learned, and other strategic improvements to the organization's meta-process. 4. Extending automation support for stakeholder environments enables further support for paperless exchange of information and more effective review of engineering artifacts.
Roundtrip engineering in project environment It maintains consistency among the engineering artifacts. • The automated translation of design models to source code (both forward and reverse engineering) is fairly well established. • Distributed ActiveX and the Common Object Request Broker Architecture (CORBA) used. Compilers and linkers have long provided automation of source code into executable code.
Change management in project environment Tracking changes in the technical artifacts to understand technical progress and quality trends toward delivering an acceptable end product or interim release. In a modern process, requirements, design, and implementation set artifacts are captured early in the life cycle and evolved through multiple generations. Software Change Orders (SCO) The atomic unit of software work to create, modify, or obsolesce components within a configuration baseline is called a software change order (SCO). SCO is a key mechanism for partitioning, allocating, and scheduling software work against an established software baseline and for assessing progress and quality. Figure shows a set of change primitives and required metrics. By automating data entry and maintaining change records on-line, the change management bureaucracy associated with metrics reporting activities can also be automated. • Title. The title is suggested by the originator and is finalized upon acceptance by the configuration control board (CCB). It is reference to an external software problem report if the change was initiated by an external person (such as a user). • Description. The problem description includes the name of the originator, date of origination, CCB-assigned SCO identifier, and relevant version identifiers of related support software. It provides much detail along with code excerpts, display snapshots, error messages, and any other data.
Change management in project environment
Change management in project environment Metrics. The metrics are important for planning, scheduling, and assessing quality improvement. • Change categories are type 0 (critical bug), type 1 (bug), type 2 (enhancement), type 3 (new feature), and type 4 (other). • Initial estimates are made of the amount of breakage and effort required to resolve the problem. The breakage item quantifies the volume of change, and the rework item quantifies the complexity of change. • Upon resolution, the actual breakage is noted, and the actual rework effort is further elaborated. • The analysis item identifies the number of staff hours expended in understanding the required change (re-creating, isolating, and debugging the problem if the change is type a or 1; analysis and proto typing alternative solutions if it is type 2 or 3). • The implement item identifies the staff hours necessary to design and implement the resolution. • The test item identifies the hours expended in testing the resolution, and the document item identifies all effort expended in updating other artifacts such as the user manual or release description. • Breakage quantifies the extent of change and can be defined in units of SLOC, function points, files, components, or classes
Change management in project environment Resolution. This field includes the name of the person responsible for implementing the change, the components changed, the actual metrics, and a description of the change. Assessment. This field describes the assessment technique as either inspection, analysis, demonstration, or test. It should identify all different test configurations, such as platforms, topologies, and compilers. Disposition. The SCO is assigned one of the following states by the CCB: • Proposed: written, pending CCB review • Accepted: CCB-approved for resolution • Rejected: closed, with rationale, such as not a problem, duplicate, obsolete change, resolved by another SCO • Archived: accepted but postponed until a later release • In progress: assigned and actively being resolved by the development organization • In assessment: resolved by the development organization; being assessed by a test organization • Closed: completely resolved, with the concurrence of all CCB members
Infrastructures in project environment Infrastructure provides the organization‘s capital assets, including two key artifacts: 1. a policy that captures the standards for project software development processes, and 2. an environment that captures an inventory of tools. Organization Policy It is usually packaged as a handbook that defines the life cycle and the process primitives (major milestones, intermediate artifacts, engineering repositories, metrics, roles and responsibilities). The handbook provides a general framework for answering the following questions: • What gets done? (activities and artifacts) • When does it get done? (mapping to the life-cycle phases and milestones) • Who does it? (team roles and responsibilities) • How do we know that it is adequate? (checkpoints, metrics, and standards of performance)
Infrastructures in project environment Organization Environment The organization environment defines how things get done as well as the tools and techniques to automate the process as much as practical. Some of the typical components of an organization's automation building blocks are as follows: • Standardized tool selections (through investment by the organization in a site license or negotiation of a favorable discount with a tool vendor so that project teams are motivated economically to use that tool), which promote common workflows and a higher ROI on training • Standard notations for artifacts, such as UML for all design models, or Ada 95 for all custom-developed, reliability-critical implementation artifacts. • Tool adjuncts such as existing artifact templates (architecture description, evaluation criteria, release descriptions, status assessments] or customizations • Activity templates (iteration planning, major milestone activities, configuration control boards)
Stakeholder environments in project environment Many large-scale contractual projects include people in external organizations that represent other stakeholders such as procurement agency contract monitors, end-user engineering support personnel, third-party maintenance contractors, independent verification and validation contractors, representatives of regulatory agencies, and others. These stakeholder representatives also need access to development environment resources to contribute overall effort. An on-line environment accessible by the external stakeholders allows them to participate in the process as follows: • Accept and use executable increments for hands-on evaluation • Use the same on-line tools, data, and reports that the software development organization uses to manage and monitor the project • Avoid excessive travel, paper interchange delays, format translations, paper and shipping costs, and other overhead costs
Infrastructures in project environment Extending environments into stakeholder domains
• Technical artifacts are not just paper. Electronic artifacts in rigorous notations such as visual models and source code are viewed far more efficiently by using tools with smart browsers. • Independent assessments of the evolving artifacts are encouraged by electronic read- only access to on-line data such as configuration baseline libraries and the change management database. Reviews and inspections, breakage/rework assessments, metrics analyses, and even beta testing can be performed independently of the development team. • Even paper documents should be delivered electronically to reduce production costs and turnaround time. Infrastructures in project environment Extending environments into stakeholder domains
Reference • Software Project Management, Walker Rayce, PEA.

More Related Content

PDF
Spm life cycle phase
bygollasaidulu1
 
PPT
Software Project Management
byRamesh Babu
 
PPTX
Lect4 software economics
bymeena466141
 
PPT
Improving software economics
bydeep sharma
 
PPTX
Software project management introduction
byKanchana Devi
 
PPTX
SPM_UNIT-1(1).pptx
bySushant895574
 
PPTX
Software project estimation
byinayat khan
 
PPTX
Model Based Software Architectures
byMunazza-Mah-Jabeen
 
Spm life cycle phase
bygollasaidulu1
 
Software Project Management
byRamesh Babu
 
Lect4 software economics
bymeena466141
 
Improving software economics
bydeep sharma
 
Software project management introduction
byKanchana Devi
 
SPM_UNIT-1(1).pptx
bySushant895574
 
Software project estimation
byinayat khan
 
Model Based Software Architectures
byMunazza-Mah-Jabeen
 

What's hot

PDF
Project control and process instrumentation
byKuppusamy P
 
PPTX
Checkpoints of the Process
byMunazza-Mah-Jabeen
 
PPTX
WORKFLOW OF THE PROCESS IN SPM
bygarishma bhatia
 
PDF
Command center processing and display system replacement (ccpds-r) - Case Study
byKuppusamy P
 
PPTX
SRS(software requirement specification)
byAkash Kumar Dhameja
 
PDF
Software engineering lecture notes
bySiva Ayyakutti
 
PDF
2- THE CHANGING NATURE OF SOFTWARE.pdf
bybcanawakadalcollege
 
PDF
Spm project planning
byKanchana Devi
 
PPTX
Software requirement specification
byshiprashakya2
 
PPTX
Software myths | Software Engineering Notes
byNavjyotsinh Jadeja
 
PPTX
Software Process Models
byHassan A-j
 
PPTX
Managment spectrum
bySophia Girls' College(Autonomous), Ajmer
 
PPTX
EFFECTIVE MODULAR DESIGN.pptx
byDrTThendralCompSci
 
PPTX
Software Project Management
byNoorHameed6
 
PPTX
Software maintenance
byRajeev Sharan
 
PPTX
Software Project Management (monitoring and control)
byIsrarDewan
 
PPTX
Defining the Problem - Goals and requirements
byStephennancy
 
PPTX
Software quality
bySara Mehmood
 
PPT
Software Engineering (Project Scheduling)
byShudipPal
 
PPTX
Software engineering project management
byjhudyne
 
Project control and process instrumentation
byKuppusamy P
 
Checkpoints of the Process
byMunazza-Mah-Jabeen
 
WORKFLOW OF THE PROCESS IN SPM
bygarishma bhatia
 
Command center processing and display system replacement (ccpds-r) - Case Study
byKuppusamy P
 
SRS(software requirement specification)
byAkash Kumar Dhameja
 
Software engineering lecture notes
bySiva Ayyakutti
 
2- THE CHANGING NATURE OF SOFTWARE.pdf
bybcanawakadalcollege
 
Spm project planning
byKanchana Devi
 
Software requirement specification
byshiprashakya2
 
Software myths | Software Engineering Notes
byNavjyotsinh Jadeja
 
Software Process Models
byHassan A-j
 
Managment spectrum
bySophia Girls' College(Autonomous), Ajmer
 
EFFECTIVE MODULAR DESIGN.pptx
byDrTThendralCompSci
 
Software Project Management
byNoorHameed6
 
Software maintenance
byRajeev Sharan
 
Software Project Management (monitoring and control)
byIsrarDewan
 
Defining the Problem - Goals and requirements
byStephennancy
 
Software quality
bySara Mehmood
 
Software Engineering (Project Scheduling)
byShudipPal
 
Software engineering project management
byjhudyne
 

Similar to Software management disciplines

PPT
unit-vpart-2.ppt
byTejaTeja57
 
PPTX
UNIT_III_SPsdfghksdfghdfghjsdfghsdPM.pptx
byhodeee73
 
PPT
project on software industry
byAamir chouhan
 
PPT
Software Project Management (lecture 4)
bySyed Muhammad Hammad
 
PPT
Unified modeling language basics and slides
byvenkatasubramanianSr5
 
PPTX
Life Cycle Pases
byMunazza-Mah-Jabeen
 
PDF
Software management framework
byKuppusamy P
 
PPTX
Workflows of the Process
byMunazza-Mah-Jabeen
 
PPTX
Planning document
bySt Peter Claver College
 
PPT
Wbs
bySulman Ahmed
 
PPT
Wbs, estimation and scheduling
bySulman Ahmed
 
PPT
Software process life cycles
bysathish sak
 
PPTX
SPM_UNIT-2.pptx
bySushant895574
 
PDF
Unit 2. Project Planning and Investment Decisions
byShumank Srivastava
 
PPSX
Process model rup
byAryan Ajmer
 
PPTX
Life Cycle Phases
byMunazza-Mah-Jabeen
 
PPT
01lifecycles
byAbdihakim Dalmar
 
PPTX
MIS Project management
byJosephine Claire
 
PPT
Kelis king - software engineering and best practices
byKelisKing
 
PPTX
Rational unified process
bynaveed428
 
unit-vpart-2.ppt
byTejaTeja57
 
UNIT_III_SPsdfghksdfghdfghjsdfghsdPM.pptx
byhodeee73
 
project on software industry
byAamir chouhan
 
Software Project Management (lecture 4)
bySyed Muhammad Hammad
 
Unified modeling language basics and slides
byvenkatasubramanianSr5
 
Life Cycle Pases
byMunazza-Mah-Jabeen
 
Software management framework
byKuppusamy P
 
Workflows of the Process
byMunazza-Mah-Jabeen
 
Planning document
bySt Peter Claver College
 
Wbs
bySulman Ahmed
 
Wbs, estimation and scheduling
bySulman Ahmed
 
Software process life cycles
bysathish sak
 
SPM_UNIT-2.pptx
bySushant895574
 
Unit 2. Project Planning and Investment Decisions
byShumank Srivastava
 
Process model rup
byAryan Ajmer
 
Life Cycle Phases
byMunazza-Mah-Jabeen
 
01lifecycles
byAbdihakim Dalmar
 
MIS Project management
byJosephine Claire
 
Kelis king - software engineering and best practices
byKelisKing
 
Rational unified process
bynaveed428
 

More from Kuppusamy P

PDF
Recurrent neural networks rnn
byKuppusamy P
 
PDF
Deep learning
byKuppusamy P
 
PDF
Image segmentation
byKuppusamy P
 
PDF
Image enhancement
byKuppusamy P
 
PDF
Feature detection and matching
byKuppusamy P
 
PDF
Image processing, Noise, Noise Removal filters
byKuppusamy P
 
PDF
Flowchart design for algorithms
byKuppusamy P
 
PDF
Algorithm basics
byKuppusamy P
 
PDF
Problem solving using Programming
byKuppusamy P
 
PDF
Parts of Computer, Hardware and Software
byKuppusamy P
 
PDF
Strings in java
byKuppusamy P
 
PDF
Java methods or Subroutines or Functions
byKuppusamy P
 
PDF
Java arrays
byKuppusamy P
 
PDF
Java iterative statements
byKuppusamy P
 
PDF
Java conditional statements
byKuppusamy P
 
PDF
Java data types
byKuppusamy P
 
PDF
Java introduction
byKuppusamy P
 
PDF
Logistic regression in Machine Learning
byKuppusamy P
 
PDF
Anomaly detection (Unsupervised Learning) in Machine Learning
byKuppusamy P
 
PDF
Machine Learning Performance metrics for classification
byKuppusamy P
 
Recurrent neural networks rnn
byKuppusamy P
 
Deep learning
byKuppusamy P
 
Image segmentation
byKuppusamy P
 
Image enhancement
byKuppusamy P
 
Feature detection and matching
byKuppusamy P
 
Image processing, Noise, Noise Removal filters
byKuppusamy P
 
Flowchart design for algorithms
byKuppusamy P
 
Algorithm basics
byKuppusamy P
 
Problem solving using Programming
byKuppusamy P
 
Parts of Computer, Hardware and Software
byKuppusamy P
 
Strings in java
byKuppusamy P
 
Java methods or Subroutines or Functions
byKuppusamy P
 
Java arrays
byKuppusamy P
 
Java iterative statements
byKuppusamy P
 
Java conditional statements
byKuppusamy P
 
Java data types
byKuppusamy P
 
Java introduction
byKuppusamy P
 
Logistic regression in Machine Learning
byKuppusamy P
 
Anomaly detection (Unsupervised Learning) in Machine Learning
byKuppusamy P
 
Machine Learning Performance metrics for classification
byKuppusamy P
 

Recently uploaded

PPTX
CHAPTER NO. 05 DIURETICS PHARMACOGNOSY.pptx
byGanu Gavade
 
PPTX
How to use filtered() method in Odoo 18
byCeline George
 
PPTX
Structure Editorial Grade 8 Lesson (Opinion Editorial)
byJessaMaeCabangon1
 
PDF
Application of Information and Communication Technology Content.pdf
byKhalil Khan Marwat
 
PPTX
CHAPTER NO. 09 HCP BY GG LABORATORY CLINICAL TEST
byGanu Gavade
 
PPTX
Mixing Pharmaceutical Engineering .pptxx
byShraddha Bandgar
 
PPTX
What is Epiphany? A Visual introduction to this amazing liturgical season
bySteve Thomason
 
PPTX
How to Create a Search Panel in Odoo 18
byCeline George
 
PPTX
How to Manage Credit Limits in Odoo 18 Accounting
byCeline George
 
PDF
30 Ways Teachers Use AI in 2026 – Practical Classroom Workflows with Monsha f...
byMonsha.AI
 
PPTX
How to Configure Discount Code in Odoo 18 Sales
byCeline George
 
PPTX
No Storage Needed! Odoo Cross-Docking
byCeline George
 
PPTX
Shipping Policies & Picking Policies in Odoo 18 Inventory
byCeline George
 
PPTX
LEARNING PART 1. SHILPA HOTAKAR PSYCHOLOGY NOTES pptx
bySHILPA HOTAKAR
 
PDF
how to write your (written) research instruments
byThelma Villaflores
 
PPTX
Prepositions of Place : English Grammar Presentation
byPintoo Dhillon
 
PPTX
CHAPTER NO.6 PLANT FIBRES USED AS SURGICAL DRESSINGS.pptx
byGanu Gavade
 
PPTX
SPECIAL STSAINS USED IN HISTOPATHOLOGY.pptx
byKISMAT ALI
 
PDF
Application of ICT Lecture 3 ICT in Education.pdf
byKhalil Khan Marwat
 
PPTX
DIGITAL TRANSFORMATION MODULE KEY POINTS
byLisa Harris
 
CHAPTER NO. 05 DIURETICS PHARMACOGNOSY.pptx
byGanu Gavade
 
How to use filtered() method in Odoo 18
byCeline George
 
Structure Editorial Grade 8 Lesson (Opinion Editorial)
byJessaMaeCabangon1
 
Application of Information and Communication Technology Content.pdf
byKhalil Khan Marwat
 
CHAPTER NO. 09 HCP BY GG LABORATORY CLINICAL TEST
byGanu Gavade
 
Mixing Pharmaceutical Engineering .pptxx
byShraddha Bandgar
 
What is Epiphany? A Visual introduction to this amazing liturgical season
bySteve Thomason
 
How to Create a Search Panel in Odoo 18
byCeline George
 
How to Manage Credit Limits in Odoo 18 Accounting
byCeline George
 
30 Ways Teachers Use AI in 2026 – Practical Classroom Workflows with Monsha f...
byMonsha.AI
 
How to Configure Discount Code in Odoo 18 Sales
byCeline George
 
No Storage Needed! Odoo Cross-Docking
byCeline George
 
Shipping Policies & Picking Policies in Odoo 18 Inventory
byCeline George
 
LEARNING PART 1. SHILPA HOTAKAR PSYCHOLOGY NOTES pptx
bySHILPA HOTAKAR
 
how to write your (written) research instruments
byThelma Villaflores
 
Prepositions of Place : English Grammar Presentation
byPintoo Dhillon
 
CHAPTER NO.6 PLANT FIBRES USED AS SURGICAL DRESSINGS.pptx
byGanu Gavade
 
SPECIAL STSAINS USED IN HISTOPATHOLOGY.pptx
byKISMAT ALI
 
Application of ICT Lecture 3 ICT in Education.pdf
byKhalil Khan Marwat
 
DIGITAL TRANSFORMATION MODULE KEY POINTS
byLisa Harris
 

Software management disciplines

  • 1.
    Software Management Disciplines •Iterative Process Planning  Work Breakdown Structures  Planning Guidelines  The Cost and Schedule Estimating Process  The Iteration Planning Process  Pragmatic Planning • Project Organizations and Responsibilities  Line-of-Business organizations  Project Organizations  Evolution Organizations • Process Automation  Tools: Automation Building Blocks  The Project Environment
  • 2.
    Work Breakdown Structuresin Iterative Process Planning • The development of WBS is dependent on the project management style, organizational culture, customer preference, financial constraints and several other hard-to-define parameters. • A WBS is simply a hierarchy of elements that decomposes the project plan into the discrete work tasks. A WBS provides the following information structure: A delineation of all significant work  A clear task decomposition for assignment of responsibilities  A framework for scheduling, budgeting, and expenditure tracking. CONVENTIONAL WBS ISSUES: 1. They are prematurely structured around the product design. - Allocated to responsible managers with budgets, schedules, and expected deliverables, a concrete planning foundation. 2. They are prematurely decomposed, planned, and budgeted in either too much or too little detail - team plans out each element completely and creates a baseline budget and schedule for every task at the same level of detail. On the other hand, most small-scale or in-house developments elaborate their WBSs to a single level only, without supporting detail. 3. They are project-specific, and cross-project comparisons are usually difficult or impossible - With no standard WBS structure, it is extremely difficult to compare plans, financial data, schedule data, organizational efficiencies, cost trends, productivity trends, or quality trends across multiple projects. Each project organizes the work differently and uses different units of measure
  • 3.
  • 4.
    Evolutionary of WorkBreakdown Structures An evolutionary WBS should organize the planning elements around the process framework rather than the product framework. • First-level WBS elements are the workflows (management, environment, requirements, design, implementation, assessment, and deployment). These elements are usually allocated to a single team and constitute the anatomy of a project for the purposes of planning and comparison with other projects. • Second-level elements are defined for each phase of the life cycle (inception, elaboration, construction, and transition). These elements allow the fidelity of the plan to evolve more naturally with the level of understanding of the requirements and architecture, and the risks therein. • Third-level elements are defined for the focus of activities that produce the artifacts of each phase. These elements may be the lowest level in the hierarchy that collects the cost of a discrete artifact for a given phase, or they may be decomposed further into several lower level activities that, taken together, produce a single artifact.
  • 5.
    Evolutionary of WorkBreakdown Structures • Scale - Larger projects will have more levels and substructures. • Organizational structure - Projects that include subcontractors or span multiple organizational entities may introduce constraints that necessitate different WBS allocations. • Degree of custom development - Depending on the character of the project, there can be very different emphases in the requirements, design, and implementation workflows. A business process re-engineering project based primarily on existing components.
  • 6.
    Evolutionary of WorkBreakdown Structures Situation-Complication-Question (SCQ)
  • 7.
    Evolutionary of WorkBreakdown Structures
  • 8.
    Planning guidelines initerative process planning • It is valuable because most people in management positions are looking for a starting point, a skeleton they can flesh out with project-specific details. They know that initial planning guidelines capture the expertise and experience of many other people that instill some confidence in the stakeholders. Evolution of planning fidelity in the WBS over the life cycle
  • 9.
    Planning guidelines initerative process planning • Two simple planning guidelines should be considered when a project plan is being initiated or assessed. The first guideline prescribes a default allocation of costs among the first-level WBS elements The second guideline prescribes the allocation of effort and schedule across the life-cycle phases FIRST-LEVEL WBS ELEMENT DEFAULT BUDGET Management 10% Environment 10% Requirements 10% Design 15% Implementation 25% Assessment 25% Deployment 5% Total 100% DOMA IN INCEPT ION ELABORA TION CONSTRUC TION TRANSI TION Effort 5% 20% 65% 10% Sched ule 10% 30% 50% 10%
  • 10.
    Planning guidelines initerative process planning 1. The cost of different labor categories is inherent in these numbers. For example, the management, requirements, and design elements tend to use more personnel who are senior and more highly paid than the other elements use. If requirements and design together consume 25% of the budget (employing people with an average salary of $100/hour), this sum may represent half as many staff hours as the assessment element, which also accounts for 25% of the budget but employs personnel with an average salary of $50/hour. 2. The cost of hardware and software assets that support the process automation and development teams is also included in the environment element.
  • 11.
    The Cost andSchedule Estimating Process in Iterative Process Planning • Project plans need to be derived from two perspectives. 1. forward-looking, 2. top-down approach.  Forward-looking: 1. The software project manager develops a characterization of the overall size, process, environment, people, and quality required for the project 2. A macro-level estimate of the total effort and schedule is developed using a software cost estimation model 3. The software project manager partitions the estimate for the effort into a top-level WBS, also partitions the schedule into major milestone dates and partitions the effort into a staffing profile 4. At this point, subproject managers are given the responsibility for decomposing each of the WBS elements into lower levels using their top-level allocation, staffing profile, and major milestone dates as constraints.
  • 12.
    The Cost andSchedule Estimating Process in Iterative Process Planning  Backward-looking: 1. The lowest level WBS elements are elaborated into detailed tasks, for which budgets and schedules are estimated by the responsible WBS element manager. 2. Estimates are combined and integrated into higher level budgets and milestones. Comparisons are made with the top-down budgets and schedule milestones. Gross differences are assessed and adjustments are made in order to converge on agreement between the top-down and the bottom-up estimates. • These two planning approaches should be used together, in balance, throughout the life cycle of the project. • During the engineering stage, the top-down perspective will dominate because there is usually not enough depth of understanding nor stability in the detailed task sequences to perform credible bottom-up planning. • During the production stage, there should be enough precedent experience and planning fidelity that the bottom-up planning perspective will dominate. • By then, the top-down approach should be well tuned to the project-specific parameters, so it should be used more as a global assessment technique.
  • 13.
    Iteration Planning Process EngineeringStage Production Stage Inception Elaboration Construction Transition Feasibility iterations Architecture iterations Usable iterations Product releases Iteration is used to mean a complete synchronization across the project, with a well- orchestrated global assessment of the entire project baseline. Other micro-iterations, such as monthly, weekly, or daily builds, are performed enroute to these project-level synchronization points.
  • 14.
    Iteration Planning Process Engineeringstage planning emphasis:  Macro-level task estimation for production-stage artifacts  Micro-level task estimation for engineering artifacts  Stakeholder concurrence  Coarse-grained variance analysis of actual vs. planned expenditures  Tuning the top-down project- independent planning guidelines into project-specific planning guidelines. Production stage planning emphasis:  Micro-level task estimation for production-stage artifacts  Macro-level task estimation for engineering artifacts  Stakeholder concurrence  Fine-grained variance analysis of actual vs. planned expenditures
  • 15.
    Iteration Planning Process Inceptioniterations. Integrate the foundation components of a candidate architecture and provide an executable framework for elaborating phase. It includes existing components, commercial components, and custom prototypes sufficient to demonstrate a candidate architecture and sufficient requirements understanding to establish a credible business case, vision, and software development plan. Elaboration iterations. These iterations result in an architecture, including a complete framework and infrastructure for execution. Upon completion of the architecture iteration, a few critical use cases should be demonstrable: (1) initializing the architecture, (2) injecting a scenario to drive the worst-case data processing flow through the system (3) injecting a scenario to drive the worst-case control flow through the system. Construction iterations. Require at least two major construction iterations: an alpha release and a beta release. An alpha release would include executable capability for all the critical use cases. It usually represents only about 70% of the total product performance and reliability. Beta release provides 95% of the total quality attributes. Transition iterations. Single iteration to transition a beta release into the final product. Small- scale iterations may be necessary to resolve all the defects, incorporate beta feedback, incorporate performance improvements.
  • 16.
    PRAGMATIC PLANNING • Goodplanning is more dynamic. While executing iteration N of any phase, the software project manager must be monitoring and controlling against a plan that was initiated in iteration N - 1 and must be planning iteration N + 1. The art of good project management is to make trade-offs in the current iteration plan and the next iteration plan based on objective results in the current iteration and previous iterations. It overwhelming in early phases or in projects that are pioneering iterative development. • Aside from bad architectures and misunderstood requirements, inadequate planning are most common reasons for project failures. Conversely, the success of every successful project can be attributed in part to good planning. Three essential perspectives are: planning, requirements, and architecture. The end products associated with these perspectives (software development plan, requirements specifications, and architecture description document) are not emphasized. Project's plan defines how the project requirements will be transformed into a product within the business constraints. It must be realistic, current, team product, understood by the stakeholders, and used. • Plans are not just for managers. The more open and visible planning process and results, more ownership among the team members who need to execute it. Good, open plans can shape cultures and encourage teamwork.
  • 17.
    Project Organizations andResponsibilities • Software lines of business are motivated by return on investment, new business discriminators, market diversification, and profitability. • Project teams are motivated by the cost, schedule, and quality of specific deliverables. LINE-Of-BUSINESS ORGANIZATIONS Main features of the default organization: • Responsibility for process definition and maintenance is specific to a cohesive line of business, where process commonality makes sense. For example, the process for developing avionics software is different from the process used to develop office applications. • Responsibility for process automation is an organizational role and is equal in importance to the process definition role. Projects achieve process commonality primarily through the environment support of common tools. • Organizational roles may be fulfilled by a single individual or several different teams, depending on the scale of the organization. A 20-person software product company may require only a single person to fulfill all the roles, while a 10,000-person telecommunications company may require 100 people to achieve the work.
  • 18.
    Line-of-Business Organizations Default rolesin a software line-of-business organizations Project A Manager Project B Manager Project N Manager Organization Manager Software Engineering Process Authority Software Engineering Environment Authority Project Review Authority Infrastructure • Process definition • Process improvement • Process automation • Project compliance • Periodic risk assessment • Project administration • Engineering skill centers • Professional development
  • 19.
    Line-of-Business Organizations Roles SoftwareEngineering Process Authority • The Software Engineering Process Authority (SEPA) facilitates the exchange of information and process guidance both to and from project practitioners. The organization general manager for maintaining a current assessment of the organization's process maturity and its plan for future process improvements. • The SEPA must help initiate and periodically assess project processes. Catalyzing the capture and dissemination of software best practices can be accomplished only when the SEPA understands both the desired improvement and the project context. SEPA takes on responsibility and accountability for the process definition and its maintenance (modification, improvement, technology insertion). The SEPA could be a single individual, the general manager, or even a team of representatives. The SEPA must truly be an authority, competent and powerful. Project Review Authority • The Project Review Authority (PRA) is the single individual responsible for ensuring that a organizational and business unit software policies, practices, and standards. • A software project manager is responsible for meeting the requirements of a contract or some other project compliance standards. The PRA reviews both the project's conformance to contractual obligations and the project's organizational policy obligations. • The customer monitors contract requirements, contract milestones, contract deliverables, monthly management reviews, progress, quality, cost, schedule, and risk. • The PRA reviews customer commitments as well as adherence to organizational policies, organizational deliverables, financial performance, and other risks and accomplishments.
  • 20.
    Line-of-Business Organizations Roles SoftwareEngineering Environment Authority • The Software Engineering Environment Authority (SEEA) is responsible for automating the organization's process, maintaining the organization's standard environment, training projects to use the environment, and maintaining organization-wide reusable assets. • The SEEA role is necessary to achieve a significant return on investment for a common process. Tools, techniques, and training can be amortized effectively across multiple projects. In many cases, the environment may be augmented, customized, or modified, but the existence of an 80% default solution for each project is critical to achieving institutionalization of the organization's process and a good RoI on capital tool investments. Infrastructure • An organization's infrastructure provides human resources support, project-independent research and development, and other capital software engineering assets. • The typical components of the organizational infrastructure are as follows: • Project administration: time accounting system; contracts, pricing, terms and conditions; corporate information systems integration • Engineering skill centers: custom tools repository and maintenance, bid and proposal support, independent research and development • Professional development: internal training boot camp, personnel recruiting, personnel skills database maintenance, literature and assets library, technical publications
  • 21.
    Project Organizations The mainfeatures of the default organization are as follows: • The project management team is an active participant, responsible for producing as well as managing. Project management is not a spectator sport. • The architecture team is responsible for real artifacts and for the integration of components, not just for staff functions. • The development team owns the component construction and maintenance activities. • The assessment team is separate from development. This structure fosters an independent quality perspective and focuses a team on testing and product evaluation activities concurrent with on-going development. • Quality is everyone's job, integrated into all activities and checkpoints. Each team takes responsibility for a different quality perspective.
  • 23.
    Project Organizations Software ManagementTeam Inception Elaboration Construction Transition Elaboration phase planning Team formulating Contract baselining Architecture costs Construction phase planning Full staff recruitment Risk resolution Product acceptance criteria Construction costs Transition phase planning Construction plan optimization Risk management Customer satisfaction Contract closure Sales support Next-generation planning Artifacts  Business case  Vision  Software development plan  Work breakdown structure  Status assessments  Requirements set  Systems Engineering  Financial Administration  Quality Assurance Responsibilities  Resource commitments  Personnel assignments  Plans, priorities,  Stakeholder satisfaction  Scope definition  Risk management  Project control Life-Cycle Focus
  • 24.
    Software Management Team •Most projects are over constrained. Schedules, costs, functionality, and quality expectations are highly interrelated and require continuous negotiation among multiple stakeholders who have differing goals. • The software management team carries the burden of delivering win conditions to all stakeholders. • In this regard, the software project manager spends every day worrying about balance. Figure shows the software management team activities over the project life cycle. • The software management team is responsible for planning the effort, conducting the plan, and adapting the plan to changes in the understanding of the requirements or the design. • Toward this end, the team takes ownership of resource management and project scope, and sets operational priorities across the project life cycle. • At an abstract level, these activities correspond to managing the expectations of all stakeholders throughout the project life cycle. • The software management team takes ownership of all aspects of quality. In particular, it is responsible for attaining and maintaining a balance among these aspects so that the overall solution is adequate for all stakeholders and optimal for as many of them as possible.
  • 25.
    Project Organizations Roles SoftwareArchitecture Team Inception Elaboration Construction Transition Architecture prototyping Make/buy trade-offs Primary scenario definition Architecture evaluation criteria definition Architecture base lining Primary scenario demonstration Make/buy trade-offs base lining Architecture maintenance Multiple-component issue resolution Performance tuning Quality improvements Architecture maintenance Multiple-component issue resolution Performance tuning Quality improvements Artifacts  Architecture description  Requirements set  Design set  Release specifications  Demonstrations  Use-case modelers  Design modelers  Performance analysts Responsibilities  Requirements trade-offs  Design trade-offs  Component selection  Initial integration  Technical risk solution Life-Cycle Focus
  • 26.
    Software Architecture Team •The software architecture team is responsible for the architecture. This responsibility encompasses the engineering necessary to specify a complete bill of materials for the software and the engineering necessary to make significant make/buy trade-offs. • So that all custom components are elaborated to the extent that construction/assembly costs are highly predictable. • For any project, the skill of the software architecture team is crucial. It provides the framework for facilitating team communications, for achieving system-wide qualities, and for implementing the applications. • With a good architecture team, an average development team can succeed. If the architecture is weak, even an expert development team of superstar programmers will probably not succeed. To succeed, the architecture team must includes o Domain experience to produce an acceptable design view and use case view o Software technology experience to produce an acceptable process view, component view and deployment view.
  • 27.
    Project Organizations Roles SoftwareDevelopment Team Inception Elaboration Construction Transition Prototyping support Make/buy trade-offs Critical component design Critical component implementation and test Critical component base line Component design Component implementation Component stand-alone test Component maintenance Component maintenance Component documentation Artifacts  Design set  Implementation set  Deployment set  Component teams Responsibilities  Component design  Component implementation  Component stand-alone test  Component maintenance  Component documentation Life-Cycle Focus
  • 28.
    Software Development Team Typicalskill sets includes: • Commercial component: specialists with detailed knowledge of commercial components central to a system's architecture • Database: specialists with experience in the organization, storage, and retrieval of data • Graphical user interfaces: specialists with experience in the display organization, data presentation, and user interaction necessary to support human input, output, and control needs • Operating systems and networking: specialists with experience in the execution of multiple software objects on a network of hardware resources, including all the typical control issues associated with initialization, synchronization, resource sharing, name space management, reconfiguration, termination, and inter object communications • Domain applications: specialists with experience in the algorithms, application processing, or business rules specific to the system
  • 29.
    Project Organizations Roles SoftwareAssessment Team Inception Elaboration Construction Transition Infrastructure planning Primary scenario prototyping Infrastructure base lining Architecture release testing Change management Initial user manual Infrastructure upgrades Release testing Change management User manual base line Requirements verification Infrastructure maintenance Release base lining Change management Deployment to users Requirements verification Artifacts  Deployment set  SCO database  User manual  Environment  Release specifications  Release descriptions  Deployment documents  Release testing  Change management  Deployment  Environment support Responsibilities  Project infrastructure  Independent testing  Requirements verification  Metrics analysis  Configuration control  Change management  User deployment Life-Cycle Focus
  • 30.
    Software Assessment Team Thereare two reasons for using an independent team for software assessment. • The first is ensuring an independent quality perspective. • It has pros such as ensuring that the ownership biases of developers do not pollute the assessment of quality and cons such as relieving the software development team of ownership in quality, to some extent. • A more important reason for using an independent test team is to exploit the concurrency of activities. • Schedules can be accelerated by developing the software and preparing for testing in parallel with development activities. • Change management, test planning, and test scenario development can be performed in parallel with design and development. A modern process should employ use-case-oriented or capability-based testing organized as a sequence of builds and mechanized via two artifacts: 1. Release specification (the plan and evaluation criteria for a release) 2. Release description (the results of a release)
  • 31.
  • 32.
    Evolution of Organizations •The project organization represents the architecture of the team and needs to evolve consistent with the project plan captured in the work breakdown structure. • The team's center of gravity shifts over the life cycle, with about 50% of the staff assigned to one set of activities in each phase. A different set of activities is emphasized in each phase, as follows: • Inception team: an organization focused on planning, with enough support from the other teams to ensure that the plans represent a consensus of all perspectives. • Elaboration team: an architecture-focused organization in which the driving forces of the project reside in the software architecture team and supported by the software development and software assessment teams as necessary to achieve a stable architecture baseline. • Construction team: a fairly balanced organization in which most of the activity resides in the software development and software assessment teams Transition team: a customer- focused organization in which usage feedback drives the deployment activities • It is equally important to elaborate the details of sub teams, responsibilities, and work packages, but not until the planning details in the WBS are stable. Defining all the details of lower level team structures prematurely can result in serious downstream inefficiencies.
  • 33.
    Process Automation • Automationneeds to improve the predictability of software management and performance of their software lines of business (in terms of product quality, time to market, return on investment, and productivity). • Most software organizations are confronted with the task of integrating their own environment and infrastructure for software development. • This process typically results in the selection of more or less incompatible tools that have different information repositories, are supplied by different vendors, work on different platforms. • Integrating such an infrastructure has proven to be much more problematic than expected. • To avoid the issues automation is required in software development.
  • 34.
    Three levels ofprocess Metaprocess, Macroprocess, and Microprocess Each level requires a certain degree of process automation for efficient process: 1. Metaprocess: An organization's policies, procedures, and practices for managing a software- intensive line of business. The automation support for this level is called an infrastructure that includes tools, artifact templates, microprocess guidelines, macroprocess guidelines, project performance repository, database of organizational skill sets, and library of precedent examples of past project plans and results. 2. Macroprocess: A project's policies, procedures, and practices for producing a complete software product within certain cost, schedule, and quality constraints. The automation support for a project's process is called an environment. An environment is a specific collection of tools to produce a specific set of artifacts as governed by a specific project plan.
  • 35.
    Three levels ofprocess 3. Microprocess: A project team's policies, procedures, and practices for achieving an artifact of the software process. The automation support for generating an artifact is generally called a tool. Typical tools include requirements management, visual modeling, compilers, editors, debuggers, change management, metrics automation, document automation, test automation, cost estimation, and workflow automation.
  • 36.
    TOOLS: AUTOMATION BUILDINGBLOCKS Typical automation and tool components that support the process workflows
  • 37.
    TOOLS: AUTOMATION BUILDINGBLOCKS • Management • There are many opportunities for automating the project planning and control activities of the management workflow. • Software cost estimation tools and WBS tools are useful for generating the planning artifacts. • It uses on-line version of the status assessment are advantageous. • This automation improves the insight of the metrics collection and reporting. • Environment • Configuration management and version control are essential in a modern iterative development process. • Much of the metrics dependent on measuring changes in software artifact baselines.
  • 38.
    TOOLS: AUTOMATION BUILDINGBLOCKS • Requirements • Conventional approaches decomposed system requirements into subsystem requirements, subsystem requirements into component requirements, and component requirements into unit requirements. • The equal treatment of all requirements drained away engineering hours from the driving requirements, then wasted that time on paperwork associated with detailed traceability that was inevitably discarded later as the driving requirements and subsequent design understanding evolved. • Lower levels of requirements are driven by the process-organized by iteration rather than by lower level component-in the form of evaluation criteria. • Evaluation criteria are captured in the release specification artifacts, which are transient snapshots of objectives for a given iteration. • Evaluation criteria are derived from the vision statement as well as from many other sources, such as make/buy analyses, risk management concerns, architectural considerations, implementation constraints, quality thresholds, and even shots in the dark.
  • 39.
    TOOLS: AUTOMATION BUILDINGBLOCKS • Design • The tools that support the requirements, design, implementation, and assessment workflows are usually used together. • The primary support required for the design workflow is visual modeling, which is used for capturing design models, presenting them in human-readable format, and translating them into source code. • An architecture-first and demonstration-based process is enabled by existing architecture components and middleware. • Implementation • It relies primarily on a programming environment (editor, compiler, debugger, linker, run time) with the change management tools, visual modeling tools, and test automation tools to support productive iteration. • Assessment and Deployment • Requires to support test automation and test management. • To increase change freedom, testing and document production must be mostly automated. • Defect tracking is a tool that supports assessment. It provides the change management instrumentation necessary to automate metrics and control release baselines. It is also needed to support the deployment workflow throughout the life cycle.
  • 40.
    PROJECT ENVIRONMENT The projectenvironment artifacts evolve through three discrete states: 1. Prototyping environment, 2. Development environment, and 3. Maintenance environment. 1. The prototyping environment • Includes an architecture testbed for prototyping project architectures to evaluate trade-offs during the inception and elaboration phases. • This informal configuration of tools should be capable of supporting the following activities: • Performance trade-offs and technical risk analyses • Make/buy trade-offs and feasibility studies for commercial products • Fault tolerance/dynamic reconfiguration trade-offs • Analysis of the risks associated with transitioning to full-scale implementation • Development of test scenarios, tools, and instrumentation suitable for analyzing the requirements 2. The development environment • It should include a full suite of development tools needed to support the various process workflows and to support round-trip engineering to the maximum extent possible.
  • 41.
    PROJECT ENVIRONMENT • 3.The maintenance environment • It should typically coincide with a mature version of the development environment. In some cases, the maintenance environment may be a subset of the development environment delivered as one of the project's end products. Four important environment disciplines to the success of a modern iterative development process: 1. Tools must be integrated to maintain consistency and traceability. Roundtrip engineering is the term used to describe this key requirement for environments that support iterative development. 2. Change management must be automated and enforced to manage multiple iterations and to enable change freedom. 3. Organizational infrastructures enable project environments to be derived from a common base of processes and tools. A common infrastructure promotes inter- project consistency, reuse of training, reuse of lessons learned, and other strategic improvements to the organization's meta-process. 4. Extending automation support for stakeholder environments enables further support for paperless exchange of information and more effective review of engineering artifacts.
  • 42.
    Roundtrip engineering inproject environment It maintains consistency among the engineering artifacts. • The automated translation of design models to source code (both forward and reverse engineering) is fairly well established. • Distributed ActiveX and the Common Object Request Broker Architecture (CORBA) used. Compilers and linkers have long provided automation of source code into executable code.
  • 43.
    Change management inproject environment Tracking changes in the technical artifacts to understand technical progress and quality trends toward delivering an acceptable end product or interim release. In a modern process, requirements, design, and implementation set artifacts are captured early in the life cycle and evolved through multiple generations. Software Change Orders (SCO) The atomic unit of software work to create, modify, or obsolesce components within a configuration baseline is called a software change order (SCO). SCO is a key mechanism for partitioning, allocating, and scheduling software work against an established software baseline and for assessing progress and quality. Figure shows a set of change primitives and required metrics. By automating data entry and maintaining change records on-line, the change management bureaucracy associated with metrics reporting activities can also be automated. • Title. The title is suggested by the originator and is finalized upon acceptance by the configuration control board (CCB). It is reference to an external software problem report if the change was initiated by an external person (such as a user). • Description. The problem description includes the name of the originator, date of origination, CCB-assigned SCO identifier, and relevant version identifiers of related support software. It provides much detail along with code excerpts, display snapshots, error messages, and any other data.
  • 44.
    Change management inproject environment
  • 45.
    Change management inproject environment Metrics. The metrics are important for planning, scheduling, and assessing quality improvement. • Change categories are type 0 (critical bug), type 1 (bug), type 2 (enhancement), type 3 (new feature), and type 4 (other). • Initial estimates are made of the amount of breakage and effort required to resolve the problem. The breakage item quantifies the volume of change, and the rework item quantifies the complexity of change. • Upon resolution, the actual breakage is noted, and the actual rework effort is further elaborated. • The analysis item identifies the number of staff hours expended in understanding the required change (re-creating, isolating, and debugging the problem if the change is type a or 1; analysis and proto typing alternative solutions if it is type 2 or 3). • The implement item identifies the staff hours necessary to design and implement the resolution. • The test item identifies the hours expended in testing the resolution, and the document item identifies all effort expended in updating other artifacts such as the user manual or release description. • Breakage quantifies the extent of change and can be defined in units of SLOC, function points, files, components, or classes
  • 46.
    Change management inproject environment Resolution. This field includes the name of the person responsible for implementing the change, the components changed, the actual metrics, and a description of the change. Assessment. This field describes the assessment technique as either inspection, analysis, demonstration, or test. It should identify all different test configurations, such as platforms, topologies, and compilers. Disposition. The SCO is assigned one of the following states by the CCB: • Proposed: written, pending CCB review • Accepted: CCB-approved for resolution • Rejected: closed, with rationale, such as not a problem, duplicate, obsolete change, resolved by another SCO • Archived: accepted but postponed until a later release • In progress: assigned and actively being resolved by the development organization • In assessment: resolved by the development organization; being assessed by a test organization • Closed: completely resolved, with the concurrence of all CCB members
  • 47.
    Infrastructures in projectenvironment Infrastructure provides the organization‘s capital assets, including two key artifacts: 1. a policy that captures the standards for project software development processes, and 2. an environment that captures an inventory of tools. Organization Policy It is usually packaged as a handbook that defines the life cycle and the process primitives (major milestones, intermediate artifacts, engineering repositories, metrics, roles and responsibilities). The handbook provides a general framework for answering the following questions: • What gets done? (activities and artifacts) • When does it get done? (mapping to the life-cycle phases and milestones) • Who does it? (team roles and responsibilities) • How do we know that it is adequate? (checkpoints, metrics, and standards of performance)
  • 48.
    Infrastructures in projectenvironment Organization Environment The organization environment defines how things get done as well as the tools and techniques to automate the process as much as practical. Some of the typical components of an organization's automation building blocks are as follows: • Standardized tool selections (through investment by the organization in a site license or negotiation of a favorable discount with a tool vendor so that project teams are motivated economically to use that tool), which promote common workflows and a higher ROI on training • Standard notations for artifacts, such as UML for all design models, or Ada 95 for all custom-developed, reliability-critical implementation artifacts. • Tool adjuncts such as existing artifact templates (architecture description, evaluation criteria, release descriptions, status assessments] or customizations • Activity templates (iteration planning, major milestone activities, configuration control boards)
  • 49.
    Stakeholder environments inproject environment Many large-scale contractual projects include people in external organizations that represent other stakeholders such as procurement agency contract monitors, end-user engineering support personnel, third-party maintenance contractors, independent verification and validation contractors, representatives of regulatory agencies, and others. These stakeholder representatives also need access to development environment resources to contribute overall effort. An on-line environment accessible by the external stakeholders allows them to participate in the process as follows: • Accept and use executable increments for hands-on evaluation • Use the same on-line tools, data, and reports that the software development organization uses to manage and monitor the project • Avoid excessive travel, paper interchange delays, format translations, paper and shipping costs, and other overhead costs
  • 50.
    Infrastructures in projectenvironment Extending environments into stakeholder domains
  • 51.
    • Technical artifactsare not just paper. Electronic artifacts in rigorous notations such as visual models and source code are viewed far more efficiently by using tools with smart browsers. • Independent assessments of the evolving artifacts are encouraged by electronic read- only access to on-line data such as configuration baseline libraries and the change management database. Reviews and inspections, breakage/rework assessments, metrics analyses, and even beta testing can be performed independently of the development team. • Even paper documents should be delivered electronically to reduce production costs and turnaround time. Infrastructures in project environment Extending environments into stakeholder domains
  • 52.
    Reference • Software ProjectManagement, Walker Rayce, PEA.