UNIT V

CCPDS-R Case Study and Future Software Project Management Practices

Modern Project Profiles, Next-Generation software Economics, Modern Process Transitions.

CCPDS-R Case Study and Future Software Project Management Practices

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.

 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:

Software process and project management Page 75

 Software Engineering Workflows Conventional Process Expenditures Modern process
Ex
Management 5% 10%

Environment 5% 10%

Requirements 5% 10%

Design 10% 15%

Implementation 30% 25%

Assessment 40% 25%

Deployment 5% 5%

As shown in the table, the modern projects spend only 25% of their budget for integration and
Assessment activities whereas; traditional projects spend almost 40% of their total budget for
these activities. This is because, the traditional project involve inefficient large-scale integration
and late identification of design issues.

Early Risk Resolution

 In the project development lifecycle, the engineering phase concentrates on identification

and elimination of the risks associated with the resource commitments just before the
production stage. The traditional projects involve, the solving of the simpler steps first
and then goes to the complicated steps, as a result the progress will be visibly good,
whereas, the modern projects focuses on 20% of the significant requirements, use cases,
components and risk and hence they occasionally have simpler steps.

Software process and project management Page 76

  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.

 80% of the software scrap and rework is due to 20% if the changes.

 The change-critical components r 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.

 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.

Software process and project management Page 77

  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.

 Moreover, the complex relationships such as one-one, many-one, one-many, conditional,

time-based and state based exists the requirements statement and the design elements.

Software process and project management Page 78

 As shown in the above figure, the top category system requirements are kept as the vision
whereas, those with the lower category are evaluated. The motive behind theses artifacts
is to gain fidelity with respect to the progress in the project lifecycle. This serves as a
significant different from the traditional approach because, in traditional approach the
fidelity is predicted early in the project life cycle.

8.1.4 Teamwork among stakeholders

 Most of the characteristics of the classic development process worsen the stakeholder
Software process and project management Page 79
 relationship s which in turn makes the balancing of requirement product attributes and
plans difficult. An iterative process which has a good relationship between the
stakeholders mainly focuses on objective understanding by each and every individual
stakeholder. This process needs highly skilled customers, users and monitors which have
experience in both the application as well as software. Moreover, this process requires an
organization whose focus is on producing a quality product and achieves customer
satisfaction.

 The table below shows the tangible results of major milestones in a modern process.

 From the above table, it can be observed that the progress of the project is not possible
unless all the demonstration objectives are satisfied. This statement does not present
the renegotiation of objectives, even when the demonstration results allow the further
processing of tradeoffs present in the requirement, design, plans and technology.

 Modern iterative process that rely on the results of the demonstration need al its
stakeholders to be well-educated and with a g good analytical ability so as to distinguish
between the obviously negative results and the real progress visible. For example, an
early determined design error can be treated as a positive progress instead to a major
issue.

Principles of Software Management

 Software management basically relies on the following principles, they are,

1. Process must be based on architecture-first approach

If the architecture is focused at the initial stage, then there will be a good foundation
for almost 20% of the significant stuff that are responsible for the overall success of the
project. This stuff include the requirements, components use cases, risks and errors. In
other words, if the components that are being involved in the architecture are well known
then the expenditure causes by scrap and rework will be comparatively less.

2. Develop an iterative life-cycle process that identifies the risks at an early stage

An iterative process supports a dynamic planning framework that facilitates the risk
management predictable performance moreover, if the risks are resolved earlier, the
predictability will be more and the scrap and rework expenses will be reduced.

Software process and project management Page 80

 3. After the design methods in-order to highlight components-based development.

The quantity of the human generated source code and the customized development
can be reduced by concentrating on individual components rather than individual lines-
of-code. The complexity of software is directly proportional to the number of artifacts it
contains that is, if the solution is smaller then the complexity associated with its
management is less.

4. Create a change management Environment

Highly-controlled baselines are needed to compensate the changes caused by various

teams that concurrently work on the shared artifacts.

5. Improve change freedom with the help of automated tools that support round-trip
engineering.
The roundtrip-engineering is an environment that enables the automation and
synchronization of engineering information into various formats. The engineering
information usually consists requirement specification, source code, design models test
cases and executable code. The automation of this information allows the teams to focus
more on engineering rather than dealing with over head involved.

Design artifacts must be captured in model based notation.

The design artifacts that are modeled using a model based notation like UML, are
rich in graphics and texture. These modeled artifacts facilitate the following tasks.

 Complexity control

 Objective fulfillment

 Performing automated analysis

7. Process must be implemented or obtaining objective quality control and estimation

of progress.

The progress in the lifecycle as well as the quality of intermediately products must be
estimated and incorporated into the process. This can be done with the help of well
defined estimation mechanism that are directly derived from the emerging artifacts.
These mechanisms provide detailed information about trends and correlation with
requirements.

8. Implement a Demonstration-based Approach for Estimation of intermediately

Artifacts

Software process and project management Page 81

 This approach involves giving demonstration on different scenarios. It facilitates
earl integration and better understanding of design trade-offs. Moreover, it eliminates
architectural defects earlier in the lifecycle. The intermediately results of this approach
are definitive.

The Points Increments and generations must be made based on the evolving levels of
detail

Here, the ‘levels of detail’ refers to the level of understanding requirements and
architecture. The requirements, iteration content, implementations and acceptance testing
can be organized using cohesive usage scenarios.

10. Develop a configuration process that should be economically scalable

The process framework applied must be suitable for variety of applications. The
process must make use of processing spirit, automation, architectural patterns and
components such that it is economical and yield investment benefits.

NEXT GENERATION SOFTWARE ECONOMICS

Next generation software cost models

 In comparison to the current generation software cost modes, 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.

 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, they 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.

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

Software process and project management Page 82

  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.

• At Application production stage

• A plan with high fidelity and lower risk

• It is cost-based

• It has fixed-priced contracts

• Team size is large and diverse as needed.

• Architecture team consists of a small number of software engineers.

Software process and project management Page 83

 • The Application team may have nay number of domain engineers.

• The output will be a function which is deliverable and useful, tested

baseline and warranted quality.

• The focus of the application production will be on implementing testing

and maintaining target technology.

3. MODERN PROCESS TRANSITIONS

Indications of a successful project transition to a modern culture

Several indicators are available that can be observed in order to distinguish projects that have made a
genuine cultural transition from projects that only pretends. The following are some rough indicators
available.

The lower-level managers and the middle level managers should participate in the project
development

Any organization which has an employee count less than or equal to 25 does not need to have pure
managers. The responsibility of the managers in this type of organization will be similar to that of a
project manager. Pure managers are needed when personal resources exceed 25. Firstly, these
managers understand the status of the project them, develop the plans and estimate the results. The
manager should participate in developing the plans. This transition affects the software project
managers.

Tangible design and requirements

The traditional processes utilize tons of paper in order to generate the documents relevant to the
desired project. Even the significant milestones of a project are expressed via documents. Thus, the
traditional process spends most of their crucial time on document preparation instead of performing
software development activities.

An iterative process involves the construction of systems that describe the architecture, negotiates
the significant requirements, identifies and resolves the

Software process and project management Page 84

risks etc. These milestones will be focused by all the stakeholders because they show progressive
deliveries of important functionalities instead of documental descriptions about the project.
Engineering teams will accept this transition of environment from to less document-driven while
conventional monitors will refuse this transition.

Assertive Demonstrations are prioritized

The design errors are exposed by carrying-out demonstrations in the early stages of the life cycle.
The stake holders should not over-react to these design errors because overemphasis of design errors
will discourage the development organizations in producing the ambitious future iterating. This does
not mean that stakeholders should bare all these errors. Infact, the stakeholders must follow all the
significant steps needed for resolving these issues because these errors will sometimes lead to serious
down-fall in the project.

This transition will unmark all the engineering or process issues so, it is mostly refused by
management team, and widely accepted by users, customers and the engineering team.

The performance of the project can be determined earlier in the life cycle.

The success and failure of any project depends on the planning and architectural phases of life cycle
so, these phases must employ high-skilled professionals. However, the remaining phases may work
well an average team.

Earlier increments will be adolescent

The development organizations must ensure that customers and users should not expect to have good
or reliable deliveries at the initial stages. This can be done by demonstration of flexible benefits in
successive increments. The demonstration is similar to that of documentation but involves measuring
of changes, fixes and upgrades based on the objectives so as to highlight the process quality and
future environments.

Artifacts tend to be insignificant at the early stages but proves to be the most significant in
the later stages

The details of the artifacts should not be considered unless a stable and a useful baseline is obtained.
This transition is accepted by the development team while the conventional contract monitors refuse
this transition.
Identifying and Resolving of real issues is done in a systematic order

The requirements and designs of any successful project arguments along with the continuous
negotiations and trade-offs. The difference between real and apparent issued of a successful project
can easily be determined. This transition may affect any team of stakeholders.

Software process and project management Page 85

Everyone should focus on quality assurance

The software project manager should ensure that quality assurance is integrated in every aspect of
project that is it should be integrated into every individuals role, every artifact, and every activity
performed etc. There are some organizations which maintains a separate group of individuals know
as quality assurance team, this team would perform inspections, meeting and checklist in order to
measure quality assurance. However, this transition involves replacing of separate quality assurance
team into an organizational teamwork with mature process, common objectives and common
incentives. So, this transition is supported by engineering teams and avoided by quality assurance
team and conventional managers.

CASE STUDIES:

COCOMO MODEL

The best known and most transparent cost model COCOMO (Constructive costmodel) was
developed by Boehm, which was derived from the analysis of 63 software projects. Boehm
proposed three levels of the model: basic, intermediate and detailed. COCOMO focuses mainly
upon the intermediate mode.
The COCOMO model is based on the relationships between:
Equation 1:- Development effort is related to system size
MM = a.KDSI.b
Equation 2:- Effort and development time
TDEV = c.MM.d
where MM is the effort in man-months.

KDSI is the number of thousand delivered source instructions.

TDEV is the development time.
The coefficients a, b, c and d are dependent upon the 'mode of development which Boehm
classified into 3 distinct modes:

1. Organic - Projects involve small teams working in familiar and stable environments.
Eg: - Payroll systems.
2. Semi - Detached - Mixture of experience within project teams. This lies in between
organic and embedded modes.
Eg: Interactive banking system.
3. Embedded: - Projects that are developed under tight constraints, innovative, complex and
have volatility of requirements.
Eg: - nuclear reactor control systems.
Development mode A B C D
Organic 3.2 1.05 2.5 0.38
Software process and project management Page 86
 Semi-detached 3.0 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32

In the intermediate mode it is possible to adjust the nominal effort obtained from the model by
the influence of 15 cost drivers. These drivers deviate from the nominal figures, where particular
project differ from the average project. For example, if the reliability of the software is very
high, a factor rating of 1.4 can be assigned to that driver. Once all the factors for each driver have
been chosen they are multiplied to arrive at an Effort Adjustment Factor (EAF).
The actual steps in producing an estimate using the intermediate COCOMO model are:
1. Identify the 'mode' of development for the new project.
2. Estimate the size of the project in KDSI to derive a nominal effort prediction.
3. Adjust the 15 cost drivers to reflect your project, producing an error adjustment factor.
4. Calculate the predicted project effort using equation 1 and the effort adjustment factor.
5. Calculate the project duration using equation 2.

Drawbacks:
1. It is hard to accurately estimate KDSI early on in the project, when most effort estimates are
required.
2. Extremely vulnerable to mis-classification of the development mode.
3. Success depends largely on tuning the model to the needs of the organization, using historical
data which is not always available.

Advantages:
1. COCOMO is transparent. It can be seen how it works.
2. Drivers are particularly helpful to the operator to understand the impact of different factors
that affect project costs.

Software process and project management Page 87

 Phases Phases
Inception and elaboration Construction ad transitionArchitecture and applications have different
units of mass-scale and size. Scale ismeasured in terms of architecturally significant elements
such as classes, components, processes and nodes. Size is measured in SLOC or megabyte of
executable code. Next generation environments and infrastructures are moving to automate and
standardize many of the management activities, thereby requiring a lower percentage of effort for
overhead activities as scale increases. The two major improvements in next-generation cost
estimation models are.

1. Separation of the engineering stage from the production stage to differentiate between
architectural scale and implementation size.
2. Rigorous design notations such as UML to be more standardized. The automation of
the construction process in next-generation environments is shown below.

Software process and project management Page 88

Software process and project management Page 89