Software Project Management

UNIT-V

Tailoring the Process: Process discriminates�Future Software Project Management: Modern Project Profiles, Next generation Software�economics, modern process transitions.�Case Study: The command Center Processing and Display system-Replacement(CCPDS)

Tailoring the Process

• Tailoring: In software project management refers to the process of implementing tailored processes, methods, and tools that take into consideration the unique characteristics of the project, such as its complexity, size, duration, and organizational environment.
• Tailoring allows the project team to create processes and methods that fit the project’s specific needs, making the most efficient use of the project team’s time and ensuring that the project is handled in a way that meets the organization’s goals and objectives.
• Tailoring is the process of customizing a project management process to meet the specific needs of a project and its stakeholders.
• This process typically involves breaking down the project into manageable pieces and assigning tasks to team members. A successful tailoring process should ensure that the project meets the defined goals and objectives, is completed within the given timeline and budget, and is able to adapt to changes in scope and resources.

Scale

• The scale of the project is the team size, There are many ways to measure scale, including number of sources lines of code, number of function points, number of use cases and number of dollars. The primary measure of scale is the size of the team. Five people are an optimal size for an engineering team
• A team consisting of 1 member is said to be trivial, a team of 5 is said to be small, a team of 25 is said to be moderate, a team of 125 is said to be large, a team of 625 is said to be huge and so on. As team size grows, a new level of personnel management is introduced at each factor of 5.
• Trivial - sized projects require almost no management overhead. Only little documentation is required. Workflow is single-threaded. Performance is dependent on personnel skills.
• Small projects consisting of 5 people require very little management overhead. Project milestones are easily planned, informally conducted and changed. There are a small number of individual workflows. Performance depends primarily on personnel skills. Process maturity is unimportant.

Scale

• Moderate-sized projects consisting of 25 people require very moderate management overhead. Project milestones are formally planned and conducted. There are a small number of concurrent team workflows, each team consisting of multiple individual workflows. Performance is highly dependent on the skills of key personnel. Process maturity is valuable.
• Large projects consisting of 125 people require substantial management overhead. Project milestones are formally planned and conducted. A large number of concurrent team workflows are necessary, each with multiple individual workflows. Performance is highly dependent on the skills of the key personnel. Process maturity is necessary.
• Huge projects consisting of 625 people require substantial management overhead. Project milestones are very formally planned and conducted. There are a very large number of concurrent team workflows, each with multiple individual workflows. Performance is highly dependent on the skills of the key personnel. Project performance is still dependent on average people.

Scale

Stakeholder Cohesion or Contention:

• The degree of cooperation and coordination among stakeholders (buyers, developers, users, subcontractors and maintainers) significantly drives the specifics of how a process is defined.
• This process parameter ranges from cohesive to adversarial.
• Cohesive teams have common goals, complementary skills and close communications.
• Adversarial teams have conflicting goals, competing and incomplete skills, and less-than-open communication.

Stakeholder Cohesion or Contention:

Process Flexibility

• The implementation of the project's process depends on the degree of rigor, formality and change freedom evolved from projects contract (vision document, business case and development plan).
• For very loose contracts such as building a commercial product within a business unit of a software company, management complexity is minimal. For a very rigorous contract, it could take many months to authorize a change in a release schedule.

3. Process Flexibility or Rigor

Process Maturity:

• The process maturity level of the development organization is the key driver of management complexity.
• Managing a mature process is very simpler than managing an immature process.
• Organization with a mature process have a high level of precedent experience in developing software and a high level of existing process collateral that enables predictable planning and execution of the process.
• This sort of collateral includes well-defined methods, process automation tools, and trained personnel, planning metrics, artifact templates and workflow templates.

Process Maturity:

Architectural Risk:

• The degree of technical feasibility is an important dimension of defining a specific projects process.
• There are many sources of architecture risk. They are (1) system performance which includes resource utilization, response time, throughout and accuracy, (2) robustness to change which includes addition of new features & incorporation of new technology and (3) system reliability which includes predictable behavior and fault tolerance.

​

​

5. Architectural Risk:

Domain Experience

• The development organization's domain experience governs its ability to converge on an acceptable architecture in a minimum no of iterations.

​

6. Domain Experience:

Future Software Project Management

• Modern Project Profiles,
• Next generation Software economics,
• Modern process transitions.�

Modern Project Profiles

• A modern process framework exploits several critical approaches for resolving these issues:
• 1. Protracted integration and late design breakage are resolved by forcing integration into the engineering stage. This is achieved through continuous integration of an architecture baseline supported by executable demonstrations of the primary scenarios.
• 2. Late risk resolution is resolved by emphasizing an architecture-first approach, in which the high-leverage elements of the system are elaborated early in the life cycle.

​

Modern Project Profiles

• 3. The analysis  of a requirements-driven functional decomposition is avoided by organizing lower level specifications along the content of releases rather than along the product decomposition (by subsystem, by component, etc.).
• 4. Adversarial stakeholder relationships are avoided by providing much more tangible and objective results throughout the life cycle.
• 5. The conventional focus on documents and review meetings is replaced by a focus on demonstrable results and well-defined sets of artifacts, with more-rigorous notations and extensive automation supporting a paperless environment.

​

​

​

Modern Project Profiles

CONTINUOUS INTEGRATION:

• In the iterative development process, firstly, the overall architecture of the project is created and then all the integration steps are evaluated to identify and eliminate the design errors.
• This approach eliminates problems such as downstream integration, late patches and shoe-horned software fixes by implementing sequential or continuous integration rather than implementing large-scale integration during the project completion.

​

​

​

Modern Project Profiles

• Moreover, it produces feasible and a manageable design by delaying the ‘design breakage’ to the engineering phase, where they can be efficiently resolved. This can be one by making use of project demonstrations which forces integration into the design phase.
• With the help of this continuous integration incorporated in the iterative development process, the quality tradeoffs are better understood and the system features such as system performance, fault tolerance and maintainability are clearly visible even before the completion of the project.
• In the modern project profile, the distribution of cost among various workflows or project is completely different from that of traditional project profile as shown below:

Modern Project Profiles

Early Risk Resolution:

• To obtain a useful perspective of risk management, the project life cycle has to be applied on the principles of software management. The following are the 80:20 principles.
• ▪ The 80% of Engineering is utilized by 20% of the requirements.
• Before selecting any of the resources, try to completely understand all the requirement because irrelevant resource selection (i.e., resources selected based on prediction) may yield severe problems.
• ▪ 80% of the software cost is utilized by 20% of the components.
• Firstly, the cost-critical components must be elaborated which forces the project to focus more on controlling the cost.
• 80% of the bugs occur because of 20% of the components.
• Firstly, the reliability-critical components must be elaborated which give sufficient time for assessment activities like integration and testing, in order to achieve the desired level of maturity

Early Risk Resolution:

• 80% of the software scrap and rework is due to 20% if the changes.
• The change-critical components elaborated first so that the changes that have more impact occur when the project is matured.
• 80% of the resource consumption is due to 20% of the components.
• Performance critical components are elaborated first so that, the trade-offs with reliability; changeability and cost-consumption can be solved as early as possible.
• 80% of the project progress is carried-out by 20% of the people
• It is important that planning and designing team should consist of best processionals because the entire success of the project depends upon a good plan and architecture.

Early Risk Resolution:

Evolutionary Requirements:

• The traditional methods divide the system requirements into subsystem requirements which in turn gets divided into component requirements. These component requirements are further divided into unit requirements. The reason for this systematic division is to simplify the traceability of the requirements.
• In the project life cycle the requirements and design are given the first and the second preference respectively. The third preference is given to the traceability between the requirement and the design components these preferences are given in order to make the design structure evolve into an organization so it parallels the structure of the requirements organization.

Evolutionary Requirements:

• Modern architecture finds it difficult to trace the requirements because of the following reasons.
• ▪ Usage of Commercial components
• ▪ Usage of legacy components
• ▪ Usage of distributed resources
• ▪ Usage of object oriented methods

Evolutionary Requirements:

Teamwork among stakeholders:

• An iterative process which has a good relationship between the stakeholders mainly focuses on objective understanding by each and every individual stakeholder.

Principles of Software Management:

Software management basically relies on the following principles, they are

• 1. Process must be based on architecture-first approach
• 2. Develop an iterative life-cycle process that identifies the risks at an early stage
• 3. After the design methods in-order to highlight components-based development.
• 4. Create a change management Environment
• 5. Improve change freedom with the help of automated tools that support round-trip engineering.
• 6. Design artifacts must be captured in model based notation.
• 7. Process must be implemented or obtaining objective quality control and estimation of progress.

​

Principles of Software Management:

• 8. Implement a Demonstration-based Approach for Estimation of intermediately Artifacts
• 9. The Points Increments and generations must be made based on the evolving levels of detail.
• 10. Develop a configuration process that should be economically scalable

Best Practices Associated with software Management:

• The following are the best practices of software management:
• 1. Formal Risk Management:
• 2. Interface Settlement:
• 3. Formal Inspections:
• 4. Management and scheduling based on metrics:
• 5. Binary quality Gates at the inch-pebble level:
• 6. Plan versus visibility of progress throughout the progress:
• 7. Identifying defects associated with the desired quality:
• 8. Configuration management:
• 9. Disclose management accountability:

NEXT GENERATION SOFTWARE ECONOMICS

Next generation software cost models :

• In comparison to the current generation software cost modles, the next generation software cost models should perform the architecture engineering and application production separately.
• The cost associated with designing, building, testing and maintaining the architecture is defined in terms of scale, quality, process, technology and the team employed.
• After obtaining the stable architecture, the cost of the production is an exponential function of size, quality and complexity involved.

Next generation software cost models :

• The architecture stage cost model should reflect certain diseconomy of scale (exponent less than 1.0) because it is based on research and development-oriented concerns. Whereas the production stage cost model should reflect economy of scale (exponent less than 1.0) for production of commodities.
• ▪ The next generation software cost models should be designed in a way that, the can assess larger architectures with economy of scale. Thus, the process exponent will be less than 1.0 at the time of production because large systems have more automated proves components and architectures which are easily reusable

Next generation software cost models

The next generation cost model developed on the basis of architecture-first approach is shown below.

• At architectural engineering Stage
• A Plan with less fidelity and risk resolution
• It is technology or schedule-based
• It has contracts with risk sharing
• Team size is small but with experienced professionals
• The architecture team, consists of small number of software engineers
• The application team consists of small number of domain engineers
• The output will be an executable architecture, production and requirements
• The focus of the architectural engineering will be on design and integration of entities as well as host development environment
• It contains two phases they are inspection and elaboration.

Next generation software cost models

• The architecture and applications of next generation cost models have difference scales and sized which represents the solution space.
• The size can be computed inters of SLOC or megabytes of executable code while the scale can be computed in 0-terms of components, classes, processes or nodes.
• The requirement or use cases of solution space are different from that of a problem space. Moreover, there can be more than one solution to a problem. Where cost serves as a key discriminator.
• The cost estimates must be determined to find an optimal solution. If an optional solution is not found then different solution s need to be selected or to change the problem statement.

Next generation software cost models

• A strict notation must be applied for design artifacts so, that the prediction of a design scale can be improved.
• The Next-generation software cost model should automate the process of measuring design scale directly from UML diagrams. There should be two major improvements. There are,
• ▪ Separate architectural engineering stage from application production stage. This will yield greater accuracy and more precision of lifecycle estimate.
• ▪ The use of rigorous design notations. This will enable the automation and standardization of scale measure so that they can be easily traced which helps to determine the total cost associated with production

Next generation software cost models

• The next generation software process has two potential breakthroughs, they are,
• ▪ Certain integrated tools would be available that automates the information transition between the requirements, design, implementation and deployment elements. These tools facilitate round trip engineering between various artifacts of engineering.
• ▪ It will reduce the four sets of fundamental technical artifacts into three sets. This is achieved by automating the activities related to human-generated source code so as to eliminate the need for a separate implementation set.

Modern Software Economics

The transition to a modern process should be made based on the following quotations laid by Boehm.

1. Identifying and solving a software problem in the design phase is almost 100 times cost effective than solving the same problem after delivery.

2. Software Development schedules can be compressed to a Maximum of 25 percent.

3. The maintenance cost will be almost double the development cost.

4. Both the software development cot and the maintenance cost are dependent on the number of lines in the source code

Modern Software Economics

5. Software productivity mainly relies on the type of people employed.
6. The ratio of software to hardware cost is increasing.
7. Only 15% of the overall software development is dedicated process to programming.
8. Software system and products cost three times the cost associated with individual software programs per SLOC software- system products cost 9 times more than the cost of individual software program.
9. 60% of Errors are caught by walkthrough
10. Only 20% of the contributors are responsible for the 80% of the contributions.

Modern Process Transitions

1.Culture Shifts

Several Culture Shifts must be overcome to transition successfully to a modern software management process. For some of these adjustments, it will be difficult to distinguish between objective opposition and stubborn resistance.

• Lower level and mid-level managers are performers.
• Requirements and designs are fluid and tangible.
• Ambitious demonstrations are encouraged.
• Good and bad project performance is much more obvious earlier in the life cycle.
• Early increments will be immature.
• Artifacts are less important early, more important later.
• Real issues are surfaced and resolved systematically.
• Quality assurance is everyone's job, not a separate discipline.
• Performance issues arise early in the life cycle.
• Investments in automation are necessary.
• Good software organizations should be more profitable.

​

Modern Process Transitions

2.Denouement:

In summary, the conventional software process was characterized by the following:

• Sequentially transitioning from requirements to design to code to test

• Achieving 100% completeness of each artifact at each life-cycle stage

• Treating all requirements, artifacts, components, and so forth, as equals

• Achieving high-fidelity traceability among all artifacts at each stage in the life cycle

Modern Process Transitions

Denouement:

A modern iterative development process framework is characterized by the following:

• Continuous round-trip engineering from requirements to test at evolving levels of abstraction

• Achieving high-fidelity understanding of the drivers (the 20%) as early as practical

• Evolving the artifacts in breadth and depth based on risk management priorities

• Postponing completeness and consistency analyses until later in the life cycle