SPPM

SOftware process and Project management
(Common to CSE and IT) B.Tech IV-Year I-Sem (Professional Elective) (JNTU-Hyderabad)
Contents
Introduction to the Subject
Syllabus as per R16 Curriculum
List of Important Definitions L.1 - L.6
University Question Papers with Solutions (Latest to Previous) QP.1 - QP.9
Unit-wise Frequently Asked Questions and Important Questions F.1 - F.6
MID - I & II (Objective Type & Essay Questions with Key) M.1 - M.20
Model Question Papers with Solutions (As per the New External Exam Pattern)
Model Paper-I MP.1 - MP.2
Model Paper-II MP.3 - MP.4
Model Paper-III MP.5 - MP.6
Guess Papers with Solutions GP.1 - GP.4
Unit-wise Short & Essay Questions with Solutions

Unit No. Unit Name
Question Nos. Page Nos.
Topic No. Topic Name
Unit - I
Q1 - Q56 1.1 - 1.42
Part-A Short Questions with solutions Q1 - Q11 1.2 - 1.4

Part-B Essay Questions with solutions Q12 - Q56 1.5 - 1.41
1.1 Software Process Maturity 1.5
1.1.1 Software Maturity Framework Q12 - Q14 1.5
1.1.2 Principles of Software Process Change Q15 - Q17 1.8
1.1.3 Software Process Assessment Q18 - Q21 1.10
1.1.4 The Initial Process Q22 - Q23 1.15
1.2 The Repeatable Process Q24 - Q32 1.16
1.3 The Defined Process Q33 - Q42 1.26
1.4 The Manged Process Q43 - Q47 1.33
1.5 The Optimizing Process Q48 - Q52 1.35
1.6 Process Reference Models – Capability Maturity Model (CMM),
CMMI, PCMM, PSP, TSP Q53 - Q56 1.37
Important Questions 1.42
Unit - II Software Project Management Renaissance,

Life-cycle Phases and Process Artifacts Q1 - Q66 2.1 - 2.58

2.1 Software Project Management Renaissance 2.6
2.1.1 Conventional Software Management Q12 - Q21 2.6
2.1.2 Evolution of Software Economics Q22 - Q27 2.16
2.1.3 Improving Software Economics Q28 - Q43 2.22
2.1.4 The Old Way and The New Way Q44 - Q47 2.32
2.2 Life-Cycle Phases and Process Artifacts 2.36
2.2.1 Engineering and Production Stages Q48 2.36
2.2.2 Inception Phase, Elaboration Phase,
Construction Phase, Transition Phase Q49 - Q51 2.38
2.2.3 Artifact Sets Q52 - Q58 2.39
2.2.4 Management Artifacts Q59 - Q60 2.48
2.2.5 Engineering Artifacts and Pragmatic Artifacts Q61 - Q62 2.51
2.2.6 Model-based Software Architectures Q63 - Q66 2.54
Unit - III Workflows and Checkpoints of Process,

Process Planning Q1 - Q32 3.1 - 3.28
3.1 Workflows and Checkpoints of Process 3.5
3.1.1 Software Process Workflows Q11 - Q13 3.5
3.1.2 Iteration Workflows Q14 - Q15 3.8
3.1.3 Major Milestones Q16 - Q20 3.9
3.1.4 Minor Milestones Q21 3.14
3.1.5 Periodic Status Assessments Q22 3.15
3.2 Process Planning 3.16
3.2.1 Work Breakdown Structures Q23 - Q26 3.16
3.2.2 Planning Guidelines Q27 - Q28 3.20
3.2.3 Cost and Schedule Estimating Process Q29 3.22
3.2.4 Iteration Planning Process Q30 - Q31 3.24
3.2.5 Pragmatic Planning Q32 3.27
Unit - IV Project Organization, Project Control

and Process Instrumentation Q1 - Q40 4.1 - 4.36
4.1 Project Organizations 4.5
4.1.1 Line-of-Business Organizations Q11 4.5
4.1.2 Project Organizations Q12 - Q15 4.6
4.1.3 Evolution of Organizations Q16 4.10
4.1.4 Process Automation Q17 - Q26 4.11
4.2 Project Control and Process Instrumentation Q27 4.21
4.2.1 The Seven Core Metrics Q28 - Q30 4.22
4.2.2 Management Indicators Q31 4.25
4.2.3 Quality Indicators Q32 - Q33 4.26
4.2.4 Life-Cycle Expectations Q34 4.27
4.2.5 Pragmatic Software Metrics Q35 - Q38 4.29
4.2.6 Metrics Automation Q39 - Q40 4.31
Unit - V CCPDS-R Case Study and Future Software

Project Management Practices Q1 - Q30 5.1 - 5.30
5.1 CCPDS-R Case Study Q9 - Q21 5.4
5.2 Future Software Project Management Practices 5.20
5.2.1 Modern Project Profiles Q22 - Q25 5.20
5.2.2 Next-Generation Software Economics Q26 - Q27 5.24
5.2.3 Modern Process Transitions Q28 - Q30 5.27
Note to Students
Software Process and Project Management (R16) (IV/I) is approximately similar with
Software Project Management (R13) (IV/I). As per the student convenience, we are
providing Previous Solved University Exam Question Papers with Solutions to prepare
for the final exams. This increases the scope for getting more marks.
Introduction to the subject
Software Process offers a set of activities along with the ordering constraints which specify the proper functioning of
these activities for generating the desired output. In other words, a software process refers to a process that involves
various issues related to technical and management aspects of software development.
Project Management plays an important role in software development i.e., it is an essential aspect of software de-
velopment process. It is a process which involves the coordination among many people throughout the completion of
project. Many activities are carried out during project management which requires effective monitoring and tracking
in order to achieve the cost, quality and schedule objectives defined for a project. It is also used to keep track of the
various resources allocated to the activities of the software development process. It can be specified as a combined
environment where in different types of entities are interconnected. These entities work together so as to develop a
quality software product. Different types of people involved in effective software project management are Senior
manager, Project manager, Programmers, Support staff, Customers, End users, Project sponsors, Competitors and
Suppliers.
The table below gives complete idea about the number of questions that can be asked from each unit in their
examination along with their weightage. This will be helpful for the students to plan and score good marks in
their exams.
Number of
Unit Weightage
Unit Name Questions Description
No. of Marks
Short Essay
This unit includes topics like Software Process

Maturity: Software Maturity Framework,
Principles of Software Process Change, Software
Software Process Maturity, Process Assessment, The Initial Process, The

1. 2 1 15
Process Reference Models Repeatable Process, The Defined Process, The
Managed Process, The Optimizing Process.
Process Reference Models: Capability Maturity
Model (CMM, CMMI), PCMM, PSP, TSP.
This unit includes topics like Software Project

Management Renaissance: Conventional
Software Management, Evolution of Software
Economics, Improving Software Economics,
Software Project Management The Old Way and the New Way. Life-Cycle
2. Renaissance, Life Cycle 2 1 15 Phases and Process Artifacts: Engineering and
Phases and Process Artifacts Production Stages, Inception Phase, Elaboration
Phase, Construction Phase, Transition Phase,
Artifact Sets, Management Artifacts, Engineering
Artifacts and Pragmatic Artifacts, Model-based
Software Architectures.
This unit includes topics like Workflows and
Checkpoints of Process: Software Process
Workflows, Iteration Workflows, Major
Workflows and Checkpoints Milestones, Minor Milestones, Periodic Status

3. 2 1 15
of Process, Process Planning Assessments. Process Planning: Work Breakdown
Structures, Planning Guidelines, Cost and
Schedule Estimating Process, Iteration Planning
Process, Pragmatic Planning.

This unit includes topics like Project
Organizations: Line-of-Business Organizations,
Project Organizations, Evolution of Organizations,

Project Organizations, Process Automation. Project Control and Process
4. Project Control and Process 2 1 15
Instrumentation Instrumentation: The Seven-Core Metrics,
Management Indicators, Quality Indicators, Life-
Cycle Expectations, Pragmatic Software Metrics,
Metrics Automation.
This unit includes topics like CCPDS-R Case
Study and Future Software Project Management

CCPDS-R Case Study and Future
5. Software Project Management 2 1 15 Practices, Modern Project Profiles, Next-
Practices
Generation Software Economics, Modern Process
Transitions.
Syllabus
UNIT-I
Software Process Maturity
Software Maturity Framework, Principles of Software Process Change, Software Process Assessment, The
Initial Process, The Repeatable Process, The Defined Process, The Managed Process, The Optimizing
Process.
Process Reference Models
Capability Maturity Model (CMM), CMMI, PCMM, PSP, TSP.
UNIT-II
Software Project Management Renaissance
Conventional Software Management, Evolution of Software Economics, Improving Software Economics,
The Old Way and the New Way.
Life-Cycle Phases and Process Artifacts
Engineering and Production Stages, Inception Phase, Elaboration Phase, Construction Phase, Transition
Phase, Artifact Sets, Management Artifacts, Engineering Artifacts and Pragmatic Artifacts, Model-based
Software Architectures.
UNIT-III
Workflows and Checkpoints of Process
Software Process Workflows, Iteration Workflows, Major Milestones, Minor Milestones, Periodic Status
Assessments.
Process Planning
Work Breakdown Structures, Planning Guidelines, Cost and Schedule Estimating Process, Iteration
Planning Process, Pragmatic Planning.

UNIT-IV
Project Organizations
Line-of-Business Organizations, Project Organizations, Evolution of Organizations, Process Automation.
Project Control and Process Instrumentation
The Seven-Core Metrics, Management Indicators, Quality Indicators, Life-Cycle Expectations, Pragmatic
Software Metrics, Metrics Automation.
UNIT-V
CCPDS-R Case Study and Future Software Project Management Practices
Modern Project Profiles, Next-Generation Software Economics, Modern Process Transitions.

MID - I & II M.1
MID - I & II
Objective Type &
Essay Questions with Key
M.2 Software Process and Project Management [JNTU-Hyderabad]
Objective Type
Unit - I
I. Fill in the Blanks
1. ________ refers to a process which consists of set of activities along with the constraints.
2. ________ are senior management persons who initializes the change in software process.
3. ________ is a typical review that helps to improve the overall software operations.
4. Initial process level is also referred as ________.
5. ________ technique allows the user to estimate the desired project on time with sufficient resources.
6. ________ calculates the software size directly from the problem specification.
7. ________ provides a framework strategy that helps to improve the management of organizational workforce.
8. ________ refer to the essential characteristics that should exists in all the activities.
9. ________ is a process-based model that helps to improve the workforce capabilities.
10. ________ refers to the implementation of ideas to improve the current software development process.
II. Multiple Choice

1. ________ activity is performed in definition phase. [ ]
(a) Software testing (b) System engineering
(c) Algorithm preparation (d) Architecture design
2. ________ are group of people who are responsible to implement changes in planning and implementation phases.
[ ]
(a) Agents (b) Champions
(c) Sponsors (d) Managers

3. ________ process enables the software practitioners to acquire the required capability using general practice.
[ ]
(a) Moving (b) Element change
(c) Refreezing (d) None of the above
4. ________ tasks must be performed at initial level. [ ]
(a) Planning (b) Project Scheduling
(c) Performance tracking (d) All the above
5. ________ is a method which enables planning, estimating, reviewing and system tracking. [ ]
(a) Refreezing (b) Change control
(c) Commitment discipline (d) Project plan
6. A ________ process is followed in a review system to support open expression and rational resolution. [ ]
(a) Contention (b) Operational plan
(c) Project plan (d) Annual productivity
Warning: Xerox/Photocopying of this book is a criminal act. Anyone found guilty is LIABLE to face LEGAL proceedings.
MID - I & II M.3
7. LOC stands for ________. [ ]
(a) Lines of Content (b) Lines of Code
(c) Line of Commitment (d) Line of Count
8. ________ is a process of gathering and analyzing software data to improve the software engineering activity.
[ ]
(a) Data collection (b) Data gathering
(c) Data prediction (d) Data Evaluation
9. ________ step is conducted during and after completion of design, test and development phases. [ ]
(a) Defect reporting (b) Action plan
(c) Defect prevention (d) Cause analysis
10. ________ refers to a set of tasks to be accomplished to achieve specific goals. [ ]
(a) Specific Goals (b) Specific plan
(c) Specific practices (d) None of the above
III. Match the Following

1. Unfreezing [ ] (a) Assessment agreement
2. Site status [ ] (b) Distinctive Interactive Queries
3. Appendices [ ] (c) Data files, Tapes
4. Inquires [ ] (d) Summary of site manager
5. Interfaces [ ] (e) Understand the software problems
KEY

1. Software process
2. Champions
3. Software process assessment
4. Adhoc process level
5. Project planning
6. Function point metric
7. Capability maturity model
8. Specific goals
9. People CMM
10. Act phrase.
II. Multiple Choice
1. (b) 2. (a) 3. (c) 4. (d) 5. (c)
6. (a) 7. (b) 8. (b) 9. (d) 10. (c)
1. (e) 2. (d) 3. (a) 4. (b) 5. (c)
MID - I & II M.5
Unit - II
1. _____ and _____ are the two essential steps for development of computer programs.
2. The next phase of analysis phase is _____.
3. Conventional software economics provides a benchmark of performance for _____.
4. _____ is a serious issue associated with the waterfall model.
5. _______ metrics are useful estimations for software after a candidate solution is formulated and an implementation
language is known.
6. _______ is the best way to measure softwares inherent maintainability and adaptability.
7. The transition between _____ and _____ is an important event for the stakeholders.
8. Engineering stage is divided into _____ and _____ phases.
9. Obtaining user self-supportability is one of the primary objectives of _____ phase.
10. Implementation set consists of source code and _____.
II. Multiple Choice

1. What is the truth about conventional software process management? [ ]
(a) Theoretically bad but not practically (b) Good both theoretically and practically
(c) Theoretically good but not practically (d) Can be measured only theoretically
2. Which of the following is not a necessary improvement for the waterfall model? [ ]
(a) Involve the developer (b) Plan, control and monitor testing
(c) Involve the customer (d) do the job twice, if necessary
3. One critical problem in software cost estimation is lack of well documented case studies of projects that are used in
development approach. [ ]
(a) Integrated (b) Inverted
(c) Iterative (d) Evaluated
4. _______ is the advantage of commercial components. [ ]

(a) Hardware / software independence (b) Functionality constraints
(c) Frequent updates (d) Run - time efficiency sacrifices
5. Which of the following is a cost model parameter in improving software? [ ]

(a) Process (b) Product
(c) Quantity (d) Length
6. The principle of top talent _______. [ ]

(a) Fits the tasks to the skills and motivation of the people available
(b) Keeping a misfit on the team doesn’t benefit any one
(c) An organization does best in the long run by helping its people to self-actualize
(d) Use better and fewer people
7. _______ are needed to the software project managers to enhance team effectiveness. [ ]
(a) Technical skills (b) Management skills
(c) Communication skills (d) Leadership qualities
8. Production stage is divided into _____ and _____ phases. [ ]
(a) Construction, Transition (b) Construction, Elaboration
(c) Inception, Elaboration (d) Transition, Elaboration
9. The artifacts for a life cycle are organized into _____ sets. [ ]
(a) Two (b) Three
(c) Four (d) Five
10. Artifacts of implementation set can be translated into a subset of _____ set. [ ]
(a) Deployment (b) Design
(c) Implementation (d) Requirements
1. Line -of- business [ ] (a) Objective of microprocess
2. Resource management [ ] (b) The quality of a product needs to be quantifiable
3. Principle of phase out [ ] (c) Objective of metaprocess
4. Make quality principle [ ] (d) Uses control element
5. Change management environment [ ] (e) A misfit on team will not be beneficial in any way
MID - I & II M.7
KEY

1. Analysis, Coding
2. Program design
3. Software management principles
4. Early risk resolution
5. SLOC
6. Quality assessment
7. Engineering, production
8. Inception, elaboration
9. Transition
10. Executables
II. Multiple Choice

1. (c) 2. (a) 3. (c) 4. (a) 5. (a)
6. (d) 7. (d) 8. (a) 9. (d) 10. (a)

1. (c) 2. (a) 3. (e) 4. (b) 5. (d)
Unit - III
1. Programming the components and evolving the implementation and deployment design artifact is ______ workflow.
2. ______ milestone has the high fidelity transition phase plan.
3. ______ are crucial for focusing continuous attention on the evolving health of the project and its dynamic.
4. ______ exaggerate the performance biases and result in an overly pessimistic plan.
5. ______ partitions the estimate for the effort into a top level work breakdown structure.
6. ______ depends on worth and risk.
7. ______ guideline deals with effort and schedule allocation across the life cycle phases.
8. The product flow details can be recorded by using a ______.
9. Construction iterations are divided into ______ and ______ releases.
10. ______ is the planning that is done practically for a successful project.
II. Multiple Choice

1. Which of the following construction belongs to the deployment workflow? [ ]
(a) Plan development (b) Production complete components
(c) Prepare transition material (d) Define user manual
2. ________ artifacts are present in the requirements work flow.
(a) Release specification (b) Requirements set
(c) Vision (d) All of the above
3. Milestones in life cycle must have, [ ]

(a) Well defined expectations and provide tangible result
(b) Synchronization with stakeholders
(c) Trade-offs
(d) Plans and designs
4. _______ are referred as iteration-focused events. [ ]
(a) Major milestones (b) Minor milestones
(c) Minor checkpoints (d) Major checkpoints
5. Mostly the iterations which have 1 to 6 months duration need only the ______ and ______ reviews. [ ]
(a) Iteration readiness review and milestones assessment
(b) Iteration readiness review and iteration design
(c) Iteration design and iteration assessment
(d) Iteration design and iteration close out
6. Growth, total size and acceptance criteria comes under __________. [ ]
(a) Top 10 risks (b) Total product scope
(c) Financial trends (d) Technical progress
MID - I & II M.9
7. ________ is also referred as modern work breakdown structure [ ]
(a) Evolutionary work breakdown (b) Traditional work breakdown
(c) Conventional work breakdown (d) None of the above
8. ______ is used to mean a complete synchronization across the project. [ ]
(a) Inception (b) Elaboration
(c) Construction (d) Iteration
9. _______ iterations are considered as architecture iterations. [ ]
(a) Inception (b) Construction
(c) Elaboration (d) Transition
10. Construction and transition phases occur in ________ planning. [ ]
(a) Production stage (b) Inception stage
(c) Engineering stage (d) None of the above

1. Inception [ ] (a) Baselining the architecture
2. Elaboration [ ] (b) Vision document
3. Construction [ ] (c) Achieving final product baselines
4. Transition [ ] (d) Resource management, control and process optimization
5. Requirement set [ ] (e) Formulating scope
KEY
1. Implementation
2. Initial operational capability
3. Periodic status assessmets
4. Bottom up approach
5. Software project manager
6. Project planning
7. Second
8. Product flow diagram
9. Alpha, Beta
10. Pragmatic planning
II. Multiple Choice

1. (c) 2. (d) 3. (a) 4. (c) 5. (a)
6. (b) 7. (a) 8. (d) 9. (c) 10. (a)

1. (e) 2. (a) 3. (d) 4. (c) 5. (b)
MID - I & II M.11
Unit - IV
1. ______ reviews both the project’s conformance to contractual obligations and the project’s organizational policy
obligations.
2. ______ are motivated by the cost schedule and quality of specific deliverables.
3. In modern process, the system requirements are captured in ______.
4. The automatic unit of software work that is authorized to create, modify or obsolescence components within a
configuration baseline is called ______.
5. The primary support required for the design workflow is the ______.
6. ______ provide an important perspective for managing the process.
7. ______ is a sign of success.
8. The MTBF trend over time is known as ______.
9. ______ defines the code properties appropriate to the quality and security.
10. ______ graph is used to compare one metric value with another relative to time.
II. Multiple Choice

1. ______ are motivated by return on investment, new business discriminators, market diversification and profitability.
[ ]
(a) Project review authority
(b) Software lines of business
(c) Software engineering environmental authority
(d) Software engineering process authority
2. ______ focuses the over flow of a project level environment, the infrastructure context of the project’s parent
organization and tool building. [ ]
(a) Automating organization (b) Automating documents
(c) Process automation (d) Meta process
3. ______ provides the change management instrumentation necessary to automate metrics and control release
baselines. [ ]
(a) Vision statement (b) Meta process
(c) Defect tracking (d) Testing
4. Which includes the name of the organization, date of organization? [ ]
(a) Metrics (b) Title
(c) Description (d) Resolution
5. An organization’s policies, procedures and practices for managing a software intensive line of business is called
[ ]
(a) Meta process (b) Complicated process
(c) Simple process (d) Complex process
6. Which is not in the seven core metrics? [ ]
(a) Work and process (b) Work breakdown structure
(c) Rework and adaptability (d) Breakage and modularity
7. The planned cost of the actual progress is represented by [ ]
(a) Cost variance (b) Schedule variance
(c) Actual cost (d) Earned value
8. The user points to graphical object displaying a point in time and drill down to view the trend for the metric using
[ ]
(a) Drill down to trend (b) Drill down to point in time
(c) Drill down to lower levels of information (d) Drill down to lower levels of indicators
9. Organizations with a mature process have, [ ]
(a) Low level of precedent experience (b) High level of precedent experience
(c) Medium level of precedent experience (d) Does not depend
10. Plays a greater role for small commercial product. [ ]
(a) Design (b) Management
(c) Prototype (d) Deployment
1. Status assessments [ ] (a) Appears at the end of in inception phase
2. Life cycle objective milestone [ ] (b) Project environment
3. Bottom-up approach [ ] (c) Microprocess tool
4. Prototyping [ ] (d) Periodic events
5. Change management [ ] (e) Backward-looking
MID - I & II M.13
KEY

1. Project review authority
2. Project teams
3. Vision statement
4. Software Change Order (SCO)
5. Visual modeling
6. Metric value
7. Low attrition
8. Maturity
9. Quality Indicator
10. Comparison
II. Multiple Choice

1. (b) 2. (c) 3. (c) 4. (c) 5. (a)
6. (b) 7. (d) 8. (a) 9. (b) 10. (d)

1. (d) 2. (a) 3. (e) 4. (b) 5. (c)
Unit - V
1. CCPDS-R involves ________ and ________ phase.
2. User interface control is provided by ________.
3. PDW stands for ________.
4. ________ metric is used to determine the non-adversarial relationships among the stakeholders.
5. ________ metric is used to determine the total breakage as a ration of the software subsystem.
6. Iterative process deliver a product with only about ______ of the total budget consumed by these activities.
7. 80% errors are caused by ________ of the components.
8. An _______ helps to identify the risks at an early stage.
9. The architecture team consists of _______ and _______ engineers.
10. In ________ step, modern techniques and technologies are analyzed.
II. Multiple Choice

1. _______ team is responsible to define and generate top-level architecture. [ ]
(a) Concept definition (b) FSD team
(c) Development team (d) None of the above
2. ________ is responsible to develop a software tool. [ ]
(a) Chief engineer (b) Administration
(c) Software engineer (d) Test engineer
3. CCO consists of ________. [ ]
(a) External interfaces (b) Output and protocol management
(c) Message input (d) All of the above
4. ________ is also referred as smoke test. [ ]
(a) Reliability test (b) Build integration test
(c) Stand-alone test (d) Final qualification test
5. Reusable components for network management are provided by. [ ]
(a) NAS (b) SSV
(c) DCO (d) TAS
6. ______% of the engineering is consumed by % of the requirement. [ ]
(a) 20% & 80% (b) 80% & 20%
(c) 40% & 80% (d) 80% & 40%
7. Which kind of requirements are captured in evaluation criteria? [ ]
(a) Top level (b) Middle level
(c) Major level (d) Lower level
MID - I & II M.15
8. Walk through catches ______ % of errors. [ ]
(a) 20 (b) 40
(c) 60 (d) 80
9. Which of the following is not a characteristic of modern development process? [ ]
(a) Round trip engineering
(b) Postponement of completeness
(c) High fidelity understanding of the drivers
(d) 100% completeness of each artifact at each stage.
10. In ______ step, a critical project is selected. [ ]
(a) Ready (b) Objective
(c) Trigger (d) None of the above
1. Administration [ ] (a) Provide software specifications
2. Software engineer [ ] (b) Quality assurance
3. Chief engineer [ ] (c) Develop a software tool
4. Software development [ ] (d) Conduct reliability testing
5. Software test [ ] (e) Testing stand-along components

KEY

1. CD, FSD
2. DCO
3. Preliminary Design Walk through
4. Development progress
5. Modularity
6. 25%
7. 20%
8. Iterative process
9. Software, Domain
10. Ready.
II. Multiple Choice
1. (a) 2. (c) 3. (d) 4. (b) 5. (a)
6. (b) 7. (d) 8. (d) 9. (b) 10. (b)

1. (b) 2. (c) 3. (a) 4. (e) 5. (d)
MID - I & II M.17
Essay questions with key

Unit - I
1. Define software process and software process model. (Refer Unit-I, Q1)
2. What are the key risks and actions of a software process? (Refer Unit-I, Q3)
3. Differentiate between white box testing and black box testing. (Refer Unit-I, Q6)
4. Write short notes on criteria for software contracting to be successful. (Refer Unit-I, Q8)
5. Explain in detail about process maturity levels. (Refer Unit-I, Q13)
6. Give a detailed note on the six basic principles of software process change. (Refer Unit-I, Q15)
7. List and explain the project planning principles. (Refer Unit-I, Q26)
8. Explain about scheduling and project tracking. (Refer Unit-I, Q30)
9. List the objectives and principles of inspection. (Refer Unit-I, Q35)
10. Write about various types of software testing strategies. (Refer Unit-I, Q36)
11. What is data gathering and analysis? List the principles and objectives of
data gathering. (Refer Unit-I, Q43)
12. Write about Defect Prevention. Discuss the principles of software defect prevention. (Refer Unit-I, Q48)
Unit - II
1. What is meant by late risk resolution? (Refer Unit-II, Q1)
2. What are the parameters of cost models? (Refer Unit-II, Q4)
3. Discuss the advantages of commercial components. (Refer Unit-II, Q6)
4. What are the top five principles of a modern process? (Refer Unit-II, Q8)
5. What the phases of the life-cycle process? Explain. (Refer Unit-II, Q9)
6. What is configurable process? (Refer Unit-II, Q11)
7. Explain the waterfall model in large-scale system approach. Discuss five necessary
improvements for this. (Refer Unit-II, Q14)
8. Explain the progress profile of conventional software project. (Refer Unit-II, Q17)
9. List and explain the ten reasons of why conventional software management does
not perform satisfactorily. (Refer Unit-II, Q21)
10. Describe the three generations of software economics. (Refer Unit-II, Q23)
11. Briefly explain pragmatic software cost estimation. (Refer Unit-II, Q27)
12. Explain the important trends to improve the software economics. (Refer Unit-II, Q28)
13. What are the key practices that improve over all software quality? Explain them. (Refer Unit-II, Q42)
14. Write and explain any ten principles of conventional software engineering. (Refer Unit-II, Q44)
15. What is the significance of iterative process? Explain transitioning to iterative process
for project management. (Refer Unit-II, Q47)
16. Briefly discuss about engineering stages. (Refer Unit-II, Q48)
17. What is meant by artifact sets? Discuss about the engineering sets. (Refer Unit-II, Q53)
18. Explain about the management artifacts. (Refer Unit-II, Q59)
Unit - III
1. Define iteration. What are the functions of iteration? (Refer Unit-III, Q1)
2. List the functions of major checkpoints. (Refer Unit-III, Q2)
3. Who are stakeholders? List them. (Refer Unit-III, Q4)
4. Write brief notes on major milestones. (Refer Unit-III, Q6)
5. What is WBS? (Refer Unit-III, Q7)
6. Discuss about initial operational capability milestone. (Refer Unit-III, Q10)
7. Illustrate the relative activity levels across the life cycle phase. (Refer Unit-III, Q12)
8. Define an iteration. Discuss the sequence of activities in an iteration workflow. (Refer Unit-III, Q14)
9. Define checkpoints. Describe the categories of checkpoints or milestones. (Refer Unit-III, Q16)
10. What are the major milestones of software project? (Refer Unit-III, Q18)
11. Explain about the minor milestones in the life cycle of an iteration. (Refer Unit-III, Q21)
12. Discuss about periodic status assessments. (Refer Unit-III, Q22)
13. Conventional WBS’s are prematurely structured around the product design.
Discuss. (Refer Unit-III, Q24)
14. Discuss about evolutionary work breakdown structures. (Refer Unit-III, Q25)
15. Describe the conventional WBS issues and planning guidelines. (Refer Unit-III, Q27)
16. Discuss about the cost and schedule estimating process. (Refer Unit-III, Q29)
17. Discuss about iteration planning process. (Refer Unit-III, Q30)
Unit - IV
1. Write about line-of-business organization. (Refer Unit-IV, Q1)
2. Write about evolution of organizations. (Refer Unit-IV, Q2)
3. What are the basic parameters of an earned value system? (Refer Unit-IV, Q4)
4. What is roundtrip engineering? (Refer Unit-IV, Q6)
5. List the seven core metrics. (Refer Unit-IV, Q7)
MID - I & II M.19
6. Write brief notes on metrics automation. (Refer Unit-IV, Q8)
7. With a neat diagram explain the default roles in a software line of business organization. (Refer Unit-IV, Q11)
8. What are the activities of software assessment team? Explain. (Refer Unit-IV, Q12)
9. Explain about the software project team evolution over the life-cycle. (Refer Unit-IV, Q16)
10. Discuss the three levels of process along with their automation support. (Refer Unit-IV, Q17)
11. Discuss about automation building blocks. (Refer Unit-IV, Q18)
12. Explain in detail about software change orders. (Refer Unit-IV, Q22)
13. What are the central management issues of complex software? Explain. (Refer Unit-IV, Q27)
14. Explain about seven core metrics. (Refer Unit-IV, Q29)
15. What are the software project quality indicators? Explain them. (Refer Unit-IV, Q32)
16. Discuss in detail about life cycle expectations. (Refer Unit-IV, Q34)
17. What are the basic characteristics of good metric? Explain. (Refer Unit-IV, Q35)
18. Define metric automation. Explain with an example. (Refer Unit-IV, Q39)
Unit - V
1. What are the best practices in software management? (Refer Unit-V, Q1)
2. What is meant by early risk resolution? (Refer Unit-V, Q3)
3. Explain about evolutionary requirements. (Refer Unit-V, Q4)
4. Describe the 3-step process that is used as an alternative way of performing transition. (Refer Unit-V, Q5)
5. What are objectives of metric program? (Refer Unit-V, Q7)
6. What are the two major improvements in next generation software cost estimation
models? (Refer Unit-V, Q8)
7. What was the purpose of the Concept Definition (CD) and Full Scale Development (FSD)
in the project CCPDS-R? (Refer Unit-V, Q9)
8. Explain Computer Software Configuration Item (CSCI). (Refer Unit-V, Q11)
9. Describe Software Architecture Skeleton (SAS) in CCPDS-R case study. (Refer Unit-V, Q12)
10. Elaborate on CCPDs-R process along with macro process, milestones and schedule. (Refer Unit-V, Q13)
11. What were the core metrics collected by CCPDS-R? What is the purpose of each metric?
12. Discuss briefly about the incremental design and test processes. (Refer Unit-V, Q16)
13. Explain in brief about the Demonstration-based Assessment. (Refer Unit-V, Q18)
14. Write short notes on,
(a) Continuous integration
(b) Early risk resolution. (Refer Unit-V, Q22)
15. What are the software management best practices? Explain them. (Refer Unit-V, Q25)
16. Discuss about next generation software economics. (Refer Unit-V, Q26)
17. Explain culture shifts for modern process transitions. (Refer Unit-V, Q28)
FAQ’s and IQ’s F.1
Unit-wise Frequently Asked Questions and Important Questions
UNIT - I : Software Process Maturity, Process Reference Models
Short Questions
Q1. What is a Process Group?
Answer : Important Question
For answer refer Unit-I, Q2.

Q2. List any four basic inspection principles.

Q3. List the objectives of data gathering.

Q4. What are the different situations of software requirements development in terms of skills and experience
of participants?

Essay Questions
REPEATED
Q5. Describe the principles of software process change and TSP. 2
Answer : (Oct./Nov.-20(R16), Q6(a) | Dec.-19(R16), Q2) TIMES

Q6. Discuss in brief about various considerations to implement assessments.

Q7. List and explain the basic configuration management functions.

Q8. What is data gathering and analysis? List the principles and objectives of data gathering.

Q9. Write about Defect Prevention. Discuss the principles of software defect prevention.

Q10. Explain the Capability Maturity Models in detail.
Answer : (Important Question | Oct./Nov.-20(R16), Q1)

Q11. Discuss about software process assessment. And also discuss about CMM.
Answer : (Important Question | Dec.-19(R16), Q3)

F.2 SOftware Process and Project Management [JNTU-Hyderabad]
UNIT - II : Software Project Management Renaissance, Life-Cycle Phases and Process Artifacts
Short Questions
REPEATED
Q1. What the phases of the life-cycle process? Explain. 4
Answer : (Nov./Dec.-17(R13), Q1(e) | Nov./Dec.-17(R13), Q1(f) | March-17(R13), Q1(e) | Nov./Dec.-16(R13), Q1(e)) TIMES
For answer refer Unit-II, Q9.
Q2. What is meant by late risk resolution?
REPEATED
Answer : (Nov./Dec.-17(R13), Q1(a) | March-17(R13), Q1(a)) 2
TIMES
Q3. What are the major components of software cost? Why?
REPEATED
Answer : (March-17(R13), Q1(j) | Nov./Dec.-16(R13), Q1(b))
2
TIMES
Q4. Define late design breakage.
Answer : (Important Question | Nov./Dec.-16(R13), Q1(a))
Q5. What are the top five principles of a modern process?
Answer : (Important Question | March-17(R13), Q1(d))
Essay Questions
REPEATED
Q6. Briefly discuss about engineering stages.
4
Answer : (Dec.-19(R16), Q5(b) | Nov./Dec.-17(R13), Q6 | March-17(R13), Q7(a) | Nov./Dec.-16(R13), Q6(a)) TIMES
Q7. Describe transitioning to an iterative process.

REPEATED
Answer : (Oct./Nov.-20(R16), Q2 | March-17(R13), Q5(b))

2
TIMES
Q8. What are the principles of modern software management?

REPEATED
Answer : (Nov./Dec.-17(R13), Q5 | March-17(R13), Q4(b))

2
TIMES
Q9. Explain the principles of conventional software engineering.

REPEATED
Answer : (Dec.-19(R16), Q5(a) | Nov./Dec.-16(R13), Q5(b))

2
TIMES
Q10. What are the key practices that improve overall software quality? Explain them.
REPEATED
Answer : (Nov./Dec.-17(R13), Q4 | Nov./Dec.-16(R13), Q5(a))

2
TIMES
Q11. Explain about improving software process and improving term effectiveness.
REPEATED
Answer : (Dec.-19(R16), Q4 | March-17(R13), Q4(a))
2
TIMES
Q12. What are the three levels of software process and their attributes? Explain.

Q13. Explain in detail about test artifacts.
Answer : (Important Question | Nov./Dec.-16(R13), Q6(b)

Q14. Explain pragmatic artifacts of software project management.
UNIT - III : Workflows and Checkpoints of Process, Process Planning
Short Questions
Q1. Write brief notes on major milestones in software process.
REPEATED
Answer : (Dec.-19(R16), Q1(f) | Nov./Dec.-17(R13), Q1(h))
2
TIMES
For answer refer Unit-III, Q6.
Q2. Define product release milestone.
Answer : (Important Question | March-17(R13), Q1(g))
Q3. Who are stakeholders? List them.
Answer : ((Important Question | March-17(R13), Q1(h))
Q4. What is WBS?
Answer : (Important Question | Nov./Dec.-16(R13), Q1(f))
Q5. Discuss about initial operational capability milestone.
Answer : (Important Question | Nov./Dec.-17(R13), Q1(g))
ESSAY Questions
REPEATED
Q6. Discuss life cycle planning balance.

2
Answer : (Oct./Nov.-20(R16), Q8(a) | March-17(R13), Q8(b)) TIMES

Q7. Describe the conventional WBS issues and planning guidelines.
REPEATED
Answer : (Dec.-19(R16), Q6 | Nov./Dec.-16(R13), Q9(a)) 2
TIMES
Q8. “An evolutionary work breakdown structure should organize the planning
elements around the process framework rather than product framework”.
REPEATED
Substantiate this statement.
2
Answer : (Oct./Nov.-20(R16), Q3 | Nov./Dec.-16(R13), Q8(a)) TIMES
Q9. What are default agendas for the life-cycle architecture milestone?
Answer : (Important Question | March-17(R13), Q8(a))
Q10. Explain the conventional WBS issues and evolution of planning fidelity in the WBS over the life cycle.
Answer : (Important Question | Nov./Dec.-17(R13), Q8)
Q11. A typical project would have six-iteration profiles. Discuss them.
Answer : (Important Question | Oct./Nov.-20(R16), Q8(b))
Q12. Summarize the differences in emphasis between engineering and production stages.
Q13. Explain about the iteration planning process and pragmatic planning.
UNIT - IV : Project Organization, Project Control and Process Instrumentation
Short Questions
Q1. Write brief notes on metrics automation.

REPEATED
Answer : (Dec.-19(R16), Q1(h) | Nov./Dec.-17(R13), Q1(j))

2
TIMES
For answer refer Unit-IV, Q8.
Q2. What is roundtrip engineering?

REPEATED
Answer : (Nov./Dec.-17(R13), Q1(d) | March-17(R13), Q1(c)) 2

TIMES
Q3. Write about evolution of organizations.

Answer : (Important Question | Dec.-19(R16), Q1(g))

Q4. What are the basic parameters of an earned value system?
Answer : (Important Question | Nov./Dec.-17(R13), Q1(i))

Q5. Define rework and adaptability.
Answer : (Important Question | March-17(R13), Q1(i))

ESSAY Questions
REPEATED
Q6. What are the seven core metrics? Explain. 4
Answer : (Oct./Nov.-20(R16), Q4(b) | Nov./Dec.-17(R13), Q10 | March-17(R13), Q10(a) | Nov./Dec.-16(R13), Q11(a)) TIMES

Q7. What are the four component teams in a default project organization and their
REPEATED
responsibility?
Answer : (Nov./Dec.-16(R13), Q8(b) | March-17(R13), Q9(a))
2
TIMES

Q8. How does the phases in the four teams evolve over the course of the entire project?

Q9. What are the software project quality indicators? Explain them.

Q10. What is a seven core metrics? Discuss about pragmatic software metrics.

Q11. Explain the significance of Software Project Control Panel (SPCP) in metrics automation.
UNIT - V : CCPDS-R Case Study and Future Software Project Management Practices
Short Questions
Q1. Write a brief note on 80 : 20 principles.
For answer refer Unit-V, Q1.

Q2. What is meant by early risk resolution?
Answer : (Important Question | Dec.-19(R16), Q1(i))

Q3. Explain about evolutionary requirements.
Answer : (Important Question | Dec.-19(R16), Q1(j))
Q4. List CSCIS.
ESSAY Questions
Q5. How was the project organized in CCPDS-R project?
Q6. Elaborate on CCPDS-R process along with macro process, milestones and schedule.
Q7. ‘There are two approaches to manage people in CCPDS-R’. Discuss them briefly.
Q8. What are the software management best practices? Explain them.
Q9. Discuss about next generation software economics.
Q10. Explain culture shifts for modern process transitions.
Answer : (Important Question | Nov./Dec.-16(R13), Q10(b))
Guess Papers with Solutions GP.1
D
r s & is t r i b u
R16 he
li s
to r
s
SIA Pu b
es
-1
s
Gu
r
B.Tech. IV Year I Semester Examination pe
pa
Software Process and Project Management t
d
P v t. L
( Common to CSE and IT )
Time: 3 Hours Max. Marks: 75

Note: This question paper contains two Parts A and B
Part A is compulsory which carries 25 marks. Answer all questions in Part A.
Part B consists of 5 Units. Answer any one full question from each unit.
Each question carries 10 marks and may have a, b, c as sub questions.
Part-A ( 25 Marks )
1. (a) Define software process and software process model. Refer Unit-I, Q1
(b) List the objectives of data gathering. Refer Unit-I, Q7
(c) What is meant by late risk resolution? Refer Unit-II, Q1
(d) What are the major components of software cost? Why? Refer Unit-II, Q4
(e) Define product release milestone. Refer Unit-III, Q3
(f) Write brief notes on major milestones in software process. Refer Unit-III, Q6
(g) Write about evolution of organizations. Refer Unit-IV, Q2
(h) Write brief notes on metrics automation. Refer Unit-IV, Q8
(i) What are the best practices in software management? Refer Unit-V, Q2
(j) Explain about evolutionary requirements. Refer Unit-V, Q4
PArt-B ( 50 Marks )
2. (a) Explain in detail about process maturity levels. Refer Unit-I, Q13
(b) What are the tasks involved in initial process? Refer Unit-I, Q22
OR
3. (a) Discuss in detail about establishing software standards. Refer Unit-I, Q34
(b) Write about Defect Prevention. Discuss the principles of software defect prevention. Refer Unit-I, Q48
4. (a) Explain waterfall model. Refer Unit-II, Q13
(b) List out 10 COCOMO II principles of a modern process. Refer Unit-II, Q45
OR
5. (a) What are the primary objectives of the four phases of software life-cycle? Refer Unit-II, Q49
(b) What are engineering artifacts? Explain. Refer Unit-II, Q61

GP.2 Software Process and Project Management [JNTU-Hyderabad]
6. (a) Define workflow. Explain about software process workflow. Refer Unit-III, Q11
(b) What are default agendas for the life-cycle architecture milestone? Refer Unit-III, Q19
OR
7. (a) “An evolutionary work breakdown structure should organize the planning elements around the process
framework rather than product framework”. Substantiate this statement. Refer Unit-III, Q25
(b) Define Project Planning. What are two perspectives of project plans? Write the planning sequence of each.
Refer Unit-III, Q29
8. (a) With a neat diagram explain the default roles in a software line of business organization. Refer Unit-IV, Q11
(b) What are the seven core metrics? Explain. Refer Unit-IV, Q29
OR
9. (a) Give the reasons for selecting the seven core metrics in the software life cycle. Also discuss the evolutionary
pattern of life cycle metrics. Refer Unit-IV, Q34
(b) Explain about the software project team evolution over the life-cycle. Refer Unit-IV, Q16
10. (a) Discuss about the command center processing and display system replacement. Refer Unit-V, Q9
(b) Discuss briefly about the incremental design and test processes. Refer Unit-V, Q16
OR
11. (a) Discuss about next generation software economics. Refer Unit-V, Q26
(b) Explain modern software economics. Refer Unit-V, Q27
Guess Papers with Solutions GP.3
R16
D
r s & is t r i b u
he
li s
to r
B.Tech. IV Year I Semester Examination s
SIA Pu b
es
-2
s
Gu
r
pe
Software Process and Project Management pa
t
d
P v t. L

Part-A ( 25 Marks )
1. (a) What are the key risks and actions of a software process? Refer Unit-I, Q3
(b) Write short notes on criteria for software contracting to be successful. Refer Unit-I, Q8
(c) What are the top five principles of a modern process? Refer Unit-II, Q8
(d) What the phases of the life-cycle process? Explain. Refer Unit-II, Q9
(e) Who are stakeholders? List them. Refer Unit-III, Q4
(f) What is WBS? Refer Unit-III, Q7
(g) What is meant by round trip engineering? Refer Unit-IV, Q6
(h) Define rework and adaptability. Refer Unit-IV, Q10
(i) What is meant by early risk resolution? Refer Unit-V, Q3
(j) What are the two major improvements in next generation software cost estimation models? Refer Unit-V, Q8
PArt-B ( 50 Marks )
2. (a) Discuss the principles of software process change. Refer Unit-I, Q15
(b) List and explain the project planning principles. Refer Unit-I, Q26
OR
3. (a) What is data gathering and analysis? List the principles and objectives of data gathering. Refer Unit-I, Q43
(b) What is CMM? Explain about Capability Maturity Model Integration (CMMI). Refer Unit-I, Q53
4. (a) Explain the principles of conventional software engineering. Refer Unit-II, Q44
(b) Describe the two stages of the life cycle to achieve economics of scale and higher returns on
investment. Refer Unit-II, Q48
OR
5. (a) Define artifact sets. Explain various types of artifact sets. Refer Unit-II, Q52
(b) Define software architecture. Mention two perspectives of architecture and explain them. Refer Unit-II, Q63
GP.4 Software Process and Project Management [JNTU-Hyderabad]
6. (a) Define an iteration. Discuss the sequence of activities in an iteration workflow. Refer Unit-III, Q14
(b) Discuss about work breakdown structures. Refer Unit-III, Q23
OR
7. (a) Describe the conventional WBS issues and planning guidelines. Refer Unit-III, Q27
(b) Explain about the iteration planning process and pragmatic planning. Refer Unit-III, Q32
8. (a) What are the tools available to automate the software development process? Refer Unit-IV, Q18
(b) Define quality indicator. Explain different types of quality indicators. Refer Unit-IV, Q32
OR
9. (a) What are the basic characteristics of good metric? Explain. Refer Unit-IV, Q35
(b) Define metric automation. Explain with an example. Refer Unit-IV, Q39
10. (a) Elaborate on CCPDS-R process along with macro process, milestones and schedule. Refer Unit-V, Q13
(b) (i) What were the core metrics collected by CCPDS-R? What is the purpose of each metric?
(ii) How were they analyzed? Refer Unit-V, Q19
OR
11. (a) Discuss the indications of a successful project transition to a modern culture. Refer Unit-V, Q28
(b) Explain about next generation project performance. Refer Unit-V, Q30
Model Question Papers with Solutions MP.1
R16 B.Tech. IV Year I Semester Examination

Model
Pa p e r 1
Software Process and Project Management
Part-A ( 25 Marks )
- - - Solutions
1. (a) What are the key risks and actions of a software process? ( Unit-I / Q3)
(b) Write short notes on criteria for software contracting to be successful. ( Unit-I / Q8)
(c) What is meant by late risk resolution? ( Unit-II / Q1)
(d) What the phases of the life-cycle process? Explain. ( Unit-II / Q9)
(e) Who are stakeholders? List them. ( Unit-III / Q4)
(f) Discuss about initial operational capability milestone. ( Unit-III / Q10)
(g) What are the basic parameters of an earned value system? ( Unit-IV / Q4)
(h) What is roundtrip engineering? ( Unit-IV / Q6)
(i) What are the best practices in software management? ( Unit-V / Q1)
(j) Explain about evolutionary requirements. ( Unit-V / Q4)
PArt-B ( 50 Marks )
2. (a) Explain in detail about process maturity levels. ( Unit-I / Q13)
(b) List and explain the project planning principles. ( Unit-I / Q26)
OR
3. (a) List the objectives and principles of inspection. ( Unit-I / Q35)
(b) What is data gathering and analysis? List the principles and objectives of
data gathering. ( Unit-I / Q43)
4. (a) Explain the waterfall model in large-scale system approach. Discuss five necessary
improvements for this. ( Unit-II / Q14)
(b) Describe the three generations of software economics. ( Unit-II / Q23)
OR
5. (a) What are the key practices that improve overall software quality? Explain them. ( Unit-II / Q42)
(b) Briefly discuss about engineering stages. ( Unit-II / Q48)

MP.2 Software Process and Project Management [JNTU-Hyderabad]
6. (a) Illustrate the relative activity levels across the life cycle phase. ( Unit-III / Q12)
(b) What are the major milestones of software project? ( Unit-III / Q18)
OR
7. (a) Conventional WBS’s are prematurely structured around the product design. Discuss. ( Unit-III / Q24)
(b) Discuss about the cost and schedule estimating process. ( Unit-III / Q29)
8. (a) With a neat diagram explain the default roles in a software line of business organization. ( Unit-IV / Q11)
(b) Discuss the three levels of process along with their automation support. ( Unit-IV / Q17)
OR
9. (a) What are the central management issues of complex software? Explain. ( Unit-IV / Q27)
(b) Discuss in detail about life cycle expectations. ( Unit-IV / Q34)
10. (a) What was the purpose of the Concept Definition (CD) and Full Scale Development (FSD)
in the project CCPDS-R? ( Unit-V / Q9)
(b) Elaborate on CCPDS-R process along with macro process, milestones and schedule. ( Unit-V / Q13)
OR
11. (a) What were the core metrics collected by CCPDS-R? What is the purpose of each metric?
(b) How were they analyzed? ( Unit-V / Q19)

Model
Pa p e r 2
Part-A ( 25 Marks )
- - -
Solutions
1. (a) Define software process and software process model. ( Unit-I / Q1)
(b) Differentiate between white box testing and black box testing. ( Unit-I / Q6)
(c) What are the parameters of cost models? ( Unit-II / Q4)
(d) What is configurable process? ( Unit-II / Q11)
(e) List the functions of major checkpoints. ( Unit-III / Q2)
(f) Write brief notes on major milestones. ( Unit-III / Q6)
(g) Write about evolution of organizations. ( Unit-IV / Q2)
(h) List the seven core metrics. ( Unit-IV / Q7)
(i) Describe the 3-step process that is used as an alternative way of performing transition. ( Unit-V / Q5)
(j) What are objectives of metric program? ( Unit-V / Q7)
PArt-B ( 50 Marks )
2. (a) Give a detailed note on the six basic principles of software process change. ( Unit-I / Q15)
(b) Explain about scheduling and project tracking. ( Unit-I / Q30)
OR
3. (a) Write about various types of software testing strategies. ( Unit-I / Q36)
(b) Write about Defect Prevention. Discuss the principles of software defect prevention. ( Unit-I / Q48)
4. (a) Explain the progress profile of conventional software project. ( Unit-II / Q17)
(b) Briefly explain pragmatic software cost estimation. ( Unit-II / Q27)
OR
5. (a) Write and explain any ten principles of conventional software engineering. ( Unit-II / Q44)
(b) What is meant by artifact sets? Discuss about the engineering sets. ( Unit-II / Q53)
6. (a) Define an iteration. Discuss the sequence of activities in an iteration workflow. ( Unit-III / Q14)
(b) Explain about the minor milestones in the life cycle of an iteration. ( Unit-III / Q21)
OR
7. Discuss about evolutionary work breakdown structures. ( Unit-III / Q25)
8. (a) What are the activities of software assessment team? Explain. ( Unit-IV / Q12)
(b) Discuss about automation building blocks. ( Unit-IV / Q18)
OR
9. (a) Explain about seven core metrics. ( Unit-IV / Q29)
(b) What are the basic characteristics of good metric? Explain. ( Unit-IV / Q35)
10. (a) Explain Computer Software Configuration Item (CSCI). ( Unit-V / Q11)
(b) Discuss briefly about the incremental design and test processes. ( Unit-V / Q16)
OR
11. (a) Write short notes on,

(i) Continuous integration
(ii) Early risk resolution. ( Unit-V / Q22)
(b) Discuss about next generation software economics. ( Unit-V / Q26)

Model
Pa p e r 3
Part-A ( 25 Marks ) Solutions

1. (a) List the objectives of data gathering. ( Unit-I / Q7)
(b) What are the different situations of software requirements development in terms of skills
and experience of participants? ( Unit-I / Q11)
(c) What are the top five principles of a modern process? ( Unit-II / Q8)
(d) Discuss the advantages of commercial components. ( Unit-II / Q6)
(e) Define iteration. What are the functions of iteration? ( Unit-III / Q1)
(f) What is WBS? ( Unit-III / Q7)
(g) Write about line-of-business organization. ( Unit-IV / Q1)
(h) Write brief notes on metrics automation. ( Unit-IV / Q8)
(i) What is meant by early risk resolution? ( Unit-V / Q3)
(j) What are the two major improvements in next generation software cost estimation models? ( Unit-V / Q8)
PArt-B ( 50 Marks )
2. (a) What are the tasks involved in initial process? ( Unit-I / Q22)
(b) List the reasons, benefits and examples of software standards. ( Unit-I / Q33)
OR
3. (a) Explain in detail about three models on which software process models are defined. ( Unit-I / Q40)
(b) Explain about Personal Software Process (PSP) and Team Software Process (TSP). ( Unit-I / Q55)
4. (a) List and explain the ten reasons of why conventional software management does
not perform satisfactorily. ( Unit-II / Q21)
(b) Explain the important trends to improve the software economics. ( Unit-II / Q28)
OR
5. (a) What is the significance of iterative process? Explain transitioning to iterative process
for project management. ( Unit-II / Q47)
(b) Explain about the management artifacts. ( Unit-II / Q59)

6. (a) Define checkpoints. Describe the categories of checkpoints or milestones. ( Unit-III / Q16)
(b) Discuss about periodic status assessments. ( Unit-III / Q22)
OR
7. (a) Describe the conventional WBS issues and planning guidelines. ( Unit-III / Q27)
(b) Discuss about iteration planning process. ( Unit-III / Q30)
8. (a) Explain about the software project team evolution over the life-cycle. ( Unit-IV / Q16)
(b) Explain in detail about software change orders. ( Unit-IV / Q22)
OR
9. (a) What are the software project quality indicators? Explain them. ( Unit-IV / Q32)
(b) Define metric automation. Explain with an example. ( Unit-IV / Q39)
10. (a) Describe Software Architecture Skeleton (SAS) in CCPDS-R case study. ( Unit-V / Q12)
(b) Explain in brief about the Demonstration-based Assessment. ( Unit-V / Q18)
OR
11. (a) What are the software management best practices? Explain them. ( Unit-V / Q25)
(b) Explain culture shifts for modern process transitions. ( Unit-V / Q28)
Question Papers with Solutions QP.1
R16
Code No: 137HB
Jawaharlal Nehru Technological University Hyderabad
B.Tech IV Year I Semester Examinations, Solutions

October/November - 2020
( Common to CSE, IT )
Note: Answer any Five Questions
All Questions Carry Equal Marks.

---
Solutions
1. Explain the Capability Maturity Models in detail. [15] (Unit-I, Q53)
2. What is the significance of iterative process? Explain transitioning to iterative process
for project management. [15] (Unit-II, Q47)
3. “An Evolutionary work breakdown structure should organize the planning elements around the process
framework rather than product framework”. Substantiate this statement. [15] (Unit-III, Q25)
4. (a) Discuss the significance of round trip engineering. [7] (Unit-IV, Q20)
(b) Discuss the four quality indicators in managing a modern process. [8] (Unit-IV, Q29)
5. Elaborate on CCPDS-R Process along with macro process, milestones and schedule. [15] (Unit-V, Q13)
6. (a) Discuss the principles of software process change. [8] (Unit-I, Q15)
(b) When the process is repeatable? Why? [7] (Unit-I, Q24)
7. Summarize the differences in emphasis between engineering and production stages. [15] (Unit-III, Q31)
8. (a) Discuss life cycle planning balance. [7] (Unit-III, Q29)
(b) A typical project would have six iteration profiles. Discuss them. [8] (Unit-III, Q30)
QP.2 Software Process and Project Management [JNTU-Hyderabad]
R16
Code No : 137HB

Solutions
B.Tech IV Year I Semester Examinations,
December - 2019
Note: This question paper contains two Parts A and B.
Each question carries 10 marks and may have a, b as sub questions.
PART- A (25 Marks)

Solutions
1. (a) Define initial process. (Unit-I, Q2)
(b) Write brief notes on PSP. (Unit-I, Q5)
(c) What is meant by software economics? (Unit-II, Q3)
(d) Define the term artifact set. (Unit-I, Q11)
(e) Explain cost estimation process. (Unit-III, Q8)
(f) Write brief notes on major milestones in software process. (Unit-III, Q6)
(g) Write about evolution of organizations. (Unit-IV, Q2)
(h) Write brief notes on metrics automation. (Unit-IV, Q8)
(i) What is meant by early risk resolution? (Unit-V, Q3)
(j) Explain about evolutionary requirements. (Unit-V, Q4)
PART - B (50 Marks)
2. Describe the principles of software process change and TSP. (Unit-I, Q15)
OR
3. Discuss about software process assessment. And also discuss about CMM. (Unit-I, Q56)
4. Explain about improving software process and improving term effectiveness. (Unit-I, Q38)
OR
5. (a) Explain the principles of conventional software engineering. (Unit-II, Q44)
(b) Describe the phase of software project elaboration. (Unit-II, Q48)
6. Describe the conventional WBS issues and planning guidelines. (Unit-III, Q27)
OR
7. Explain about the iteration planning process and pragmatic planning. (Unit-III, Q32)
8. What are the software project quality indicators? Explain them. (Unit-IV, Q32)
OR
9. What is a seven core metrics? Discuss about pragmatic software metrics. (Unit-IV, Q36)
10. What are the software management best practices? Explain them. (Unit-V, Q25)
OR
11. Discuss about next generation software economics. (Unit-V, Q26)
R13
Code No : 117HP

Solutions
B.Tech IV Year I Semester Examinations
November/December - 2017
Software Project Management
PART- A (25 Marks)

Solutions
1. (a) What is meant by late risk resolution? (Unit-II, Q1)
(b) Explain about requirements driven functional decomposition. (Unit-II, Q2)
(c) Discuss the advantages of commercial components. (Unit-II, Q6)
(d) What is meant by round trip engineering? (Unit-IV, Q6)
(e) What the phases of the life-cycle process? Explain. (Unit-II, Q9)
(f) Write brief notes on construction phase. (Unit-II, Q9)
(g) Discuss about initial operational capability milestone. (Unit-III, Q10)
(h) Write brief notes on major milestones. (Unit-III, Q6)
(i) What are the basic parameters of an earned value system? (Unit-IV, Q4)
(j) Write brief notes on metrics automation. (Unit-IV, Q8)
PART - B (50 Marks)
2. Explain the waterfall model in large-scale system approach. Discuss five necessary
improvements for this. (Unit-II, Q14)
OR
3. Explain the progress profile of conventional software project. (Unit-II, Q17)
4. What are the key practices that improve over all software quality? Explain them. (Unit-II, Q42)
OR
5. Explain the top five principles of modern process. (Unit-II, Q45)
6. Describe the primary objectives, essential activities and primary evaluation criteria of
elaboration phase. (Unit-II, Q48)
OR
7. What is meant by artifact sets? Discuss about the engineering sets. (Unit-II, Q53)
8. Explain the conventional WBS issues and evolution of planning fidelity in the WBS
over the life cycle. (Unit-III, Q26)
OR
9. With a neat diagram explain the default roles in a software line of business organization. (Unit-IV, Q11)
10. Explain about seven core metrics. (Unit-IV, Q29)
OR
11. Discuss in detail about life cycle expectations. (Unit-IV, Q34)

Code No : 117HP

R13
Solutions
B.Tech IV Year I Semester Examinations,
March - 2017
PART- A (25 Marks)

Solutions
1. (a) What is late risk resolution? (Unit-II, Q1)
(b) What are various cost estimation models? (Unit-II, Q5)
(c) What is roundtrip engineering? (Unit-IV, Q6)
(d) What are the top five principles of a modern process? (Unit-II, Q8)
(e) Define transition phase. (Unit-II, Q9)
(f) Write the typical release description outline. (Unit-II, Q10)
(g) Define product release milestone. (Unit-III, Q3)
(h) Who are stakeholders? List them. (Unit-III, Q4)
(i) Define rework and adaptability. (Unit-IV, Q10)
(j) What are the major components of software cost? Why? (Unit-II, Q4)
PART - B (50 Marks)
2. (a) What are five necessary improvements in waterfall model? (Unit-II, Q15)
(b) Describe return on investments in different domains. (Unit-II, Q26)
OR
3. (a) Give industrial software metrics top 10 list. (Unit-II, Q21)
(b) Briefly explain pragmatic software cost estimation. (Unit-II, Q27)
4. (a) How to improve software processes? (Unit-II, Q38)
(b) What are the principles of modern software management? (Unit-II, Q45)
OR
5. (a) Discuss about reuse with a neat diagram. (Unit-II, Q31)
(b) Describe transitioning to an iterative process. (Unit-II, Q47)
6. Explain about model-based architecture in a management perspective. (Unit-II, Q63)
OR
7. (a) Explain about construction phase. (Unit-II, Q48)
(b) Distinguish between implementation set and deployment set. (Unit-II, Q58)
8. (a) What are default agendas for the life-cycle architecture milestone? (Unit-III, Q19)
(b) Discuss about the cost and schedule estimating process. (Unit-III, Q29)
OR
9. (a) What are the activities of software architecture team? (Unit-IV, Q12)
(b) Explain in detail about software change orders. (Unit-IV, Q22)
10. (a) What are the seven core metrics? Explain. (Unit-IV, Q29)
(b) Give an example to distinguish small scale project and large scale project. (Out of Syllabus)
OR
11. (a) What are the basic characteristics of a good metric? Explain. (Unit-IV, Q35)
(b) Give a common subsystem overview of CCPDS-R. (Unit-V, Q14)

Code No : 117HP
Jawaharlal Nehru Technological University Hyderabad R13
B.Tech IV Year I Semester Examinations, Solutions
November/December - 2016
( Computer Science and Engineering )
PART- A (25 Marks)
Solutions
1. (a) Define late design breakage. (Unit-II, Q3)
(b) What are the parameters of cost models? (Unit-II, Q4)
(c) What is configurable process? (Unit-II, Q11)
(d) What are five staffing principles? (Unit-II, Q7)
(e) Define elaboration phase. (Unit-II, Q9)
(f) What is WBS? (Unit-III, Q7)
(g) What are the responsibilities of SEEA? (Unit-III, Q9)
(h) Explain about configuration baseline. (Unit-IV, Q3)
(i) What are the sources of architectural risks? (Out of Syllabus)
(j) Define MTBF and maturity. (Unit-IV, Q9)
PART - B (50 Marks)

2. (a) Explain waterfall model. (Unit-II, Q13)
(b) Describe the three generations of software economics. (Unit-II, Q23)
OR
3. Explain the following,
(a) Adversarial stakeholder relationships.
(b) Requirements driven functional decomposition. (Unit-II, Q16)
4. (a) Explain about object-oriented methods and visual modeling. (Unit-II, Q30)
(b) What are the modern process approaches for solving conventional problems? (Unit-II, Q46)
OR
5. (a) How to achieve require software quality? Explain. (Unit-II, Q42)
(b) Write and explain any ten principles of conventional software engineering. (Unit-II, Q44)
6. (a) Briefly discuss about engineering stages. (Unit-II, Q48)
(b) Explain in detail about test artifacts. (Unit-II, Q57)
OR
7. (a) Write the primary objectives of construction and transition phases. (Unit-II, Q49)
(b) What are engineering artifacts? Explain. (Unit-II, Q61)
8. (a) Discuss about evolutionary work breakdown structures. (Unit-III, Q25)
(b) What are the activities of software assessment team? Explain. (Unit-IV, Q12)
OR
9. (a) Explain in detail about planning guidelines. (Unit-III, Q27)
(b) Discuss about automation building blocks. (Unit-IV, Q18)
10. (a) What are process discriminants? Briefly explain. (Out of Syllabus)
(b) Explain culture shifts for modern process transitions. (Unit-V, Q28)
OR
11. (a) What are management indicators? Explain. (Unit-IV, Q29)
(b) Explain top ten software management principles. (Unit-V, Q24)

Unit-1 Software Process Maturity, Process Reference Models 1.1
Unit
Software Process Maturity, Process
1
Reference Models
SI
A GROUP
Syllabus
Software Process Maturity: Software Maturity Framework, Principles of Software Process Change, Software Process
Assessment, The Initial Process, The Repeatable Process, The Defined Process, The Managed Process, The Optimizing
Process.
Process Reference Models: Capability Maturity Model (CMM), CMMI, PCMM, PSP, TSP.
Learning Objectives
 Software Process and Software Process Models
 The Various Process Maturity Levels in Maturity Framework
 Software Process Assessment and its Principles
 The Initial Process and Repeatable Processes
 The Management and Optimizing Processes
 Introduction to Process Reference Models
 Capability Maturity Model (CMM), CMMI, PCMM, PSP, TSP.
Introduction
A software process consists of a set of activities along with the ordering constraints which specifies the
proper functioning of these activities for generating the desired output. It refers to a process that involves
various issues related to technical and management aspects of software development. Process model in
general are idealization of process which are difficult to implement on real-time basis.
Capability Maturity Model (CMM) is a maturity framework strategy that focuses on continuously improving
the management and development of the organizational workforce. It provides the organization with the
basic requirements for building the software process. The various process reference models include CMM,
CMMI, PCMM, PSP and TSP.
1.2 Software Process and Project Management [JNTU-Hyderabad]
Part-A Short Questions with Solutions
Q1. Define software process and software process model.
Answer : Model Paper-II, Q1(a)
Software Process
A software process consists of a set of activities along with the ordering constraints, which specifies the proper functioning
of these activities for generating the desired output (or) a software process refers to a process that involves various issues related
to technical and management aspects of software development.
Software Process Model
Process model in general are idealization of process which are difficult to implement on real time basis. But idealization of
process model will act as a model for other software being developed resulting into reduction of chaos while developing software.
Software process are abstract in nature and emphasizes on limited issues. There are some specific process model which are
very much useful in one context and less in the other. A software process model refers to the generic view of software process.
Q2. Define initial process.
Answer : Dec.-19(R16), Q1(a)
Initial process level is also called as adhoc process level. At this level, the requirements of software process is defined,
planned, managed and developed. This phase does not deals with predicting cost, quality assurance and scheduling of project. In
this phase, the software professionals focuses on identifying the unplanned priorities as well as the unmanaged change. As such
identification cannot be identified easily. However, as the software progress the unplanned priorities and unmanaged change can
be easily identified.
Q3. What are the key risks and actions of a software process?
Answer : Model Paper-I, Q1(a)
The key risks and actions of software process are,
1. Schedule Conflicts
Schedule conflicts is a process that helps in conducting one third of assessment. It is an approach that enables the executive
to discuss about the underlying issues with the site manager.
2. Inadequate Support
Inadequate management support is a assessment commitment performed at low management level. Senior executive can
take long term view to avoid subsequent issues. Moreover, high level manager are responsible for managing software as they
cannot provide sufficient organization priority.
3. Lack of Follow Through
If management changes and high priority issues are encountered then the site manager must focus on reducing an action
plan. Site manager can even create a final assessment report and complete action plan. If action priorities is not assigned then
improvements cannot be done efficiently. Here, success can be achieved if the manager can change efforts, have process improvement
capability and proper improvement goal.
Q4. List any four basic inspection principles.
Answer :
The basic inspection principles are as follows,
1. Inspections are considered as a structured process that includes system checklists and specified roles of participants.
It also defines means to implement a standard software engineering process within an organization.
2. Inspection is done to develop at generic checklist and standards based on each inspection type desired project needs.
The generic checklist must include inspection plan, preparation, conduct, as well as exist report.
3. Inspection is performed to prepare a list of reviewers (in advance). So as to identity the concerns and questions prior to
begging of inspections.
4. Inspection helps in determining the problem, ensuring the inspections conducted with minimum time.
Q5. Write brief notes on PSP.
Answer : Dec.-19(R16), Q1(b)
Every team member possesses his own personal software process. If this personal process remains ineffective, then he/she is
advised to go through the four phases of software development, each time being trained thoroughly. This ensures that he remain in
a position to analyze the project development, at the same time focusing the quality of it. But, this session does not end here. Rather,
PSP makes an individual involved in the project planning and also in maintaining the quality of all the software products. In order
to achieve this, PSP adheres to the following five major framework activities,
(a) Planning
(b) High Level Design
(c) High Level Design Review
(d) Development
(e) Postmortem.
Q6. Differentiate between white box testing and black box testing.
Answer : Model Paper-II, Q1(b)
White-box Testing Black-box Testing

1. It is based on the internal structure, code and 1. It is based on the requirement and functionality.
database design.
2. It is performed by developer and designer. 2. It is performed by tester and customer.
3. It is mainly suitable for unit testing and module 3. It is mainly suitable for system testing and user
testing. acceptance testing.
4. It requires the in depth knowledge of programming 4. It requires no knowledge of software and internal paths.
languages.
5. It performs code reviews, eliminates bad code 5. It checks the complete functionality of the application
practices.
6. It is performed in the early stages of testing. 6. It is performed in the later stages of testing.
7. It focuses on control structure. 7. It focuses on information domain.
Q7. List the objectives of data gathering.

Answer : Model Paper-III, Q1(a)
Data gathering ensures efficiency of software process. The basic objectives of software process are as follows,
1. Understanding
Data gathering is done to learn or understand specific item/process. This is considered as a part of research and development.
2. Evaluation
Data gathering is done inorder to study a product or activity of a product based on acceptance criteria of the product.
3. Control
Data gathering ensures control of any particular activity.
4. Prediction
Data gathering is done to develop rate/trend indicator.
Q8. Write short notes on criteria for software contracting to be successful.
Answer : Model Paper-I, Q1(b)
The criteria for a successful software contracting are,

1. The vendor should be technically competent as well as trust worthy and buyer should be able to find them.
2. Quality assurance and audit teams should ensure that the project is completed in disciplined and trustworthy environment.
3. The end product results and requirements of project should be discussed and prioritized clearly in prior.
4. The teams should be adaptive to the changes during the process as the contract is based on trust.
Q9. How development of software requirements is done?
Answer :
The developing of software requirements is done with involvement of,
(a) Developers
(b) Users
(c) Contracting Agency
The developers are involved in the discussion as they are aware of the technical issues and can estimate the development time
and cost. The users are involved as they tend to see the product from different perspectives and demand for changes. The contract-
ing agency is involved, as they are aware of costs and time taken for changes demanded. This discussion is made to gather more
information about the project and reduce the costs by the adopting stated alternatives.
Q10. List the considerations of project tracking.
Answer :
The key considerations of project tracking are,
1. The actual results of development phase should be considered and tracked.
2. The tasks performed during tracking should differ from reviewing.
3. Tracking of few sets depends on planning and process maturity.
4. Tracking should be done on the required items as per the plan.
Q11. What are the different situations of software requirements development in terms of skills and experience
of participants?
Answer : Model Paper-III, Q1(b)
The possible situations that are arise with respect to the experience of participants are as follows,
1. Experienced Users and Developers
In this case, only one team upgrade is performed by the team which developed the system. So, production and documentation,
estimations and implementation of plans and operational system produced by the core team becomes easy.
2. Inexperienced Designers
In this case, the installation and operational procedures should be continuously produced and reviewed. Many changes might
take place in implementation and agreement.
3. Inexperienced Users
In this case, repetitive operational tests are conducted.
Part-B ESSAY Questions with Solutions
1.1 Software Process Maturity

1.1.1 Software Maturity Framework
Q12. Define software process and software process models. Discuss in brief about software process
improvement.
Answer :
Software Process
A software process consists of a set of activities along with the ordering constraints, which specifies the proper functioning
of these activities for generating the desired output (or) a software process refers to a process that involves various issues related
to technical and management aspects of software development.
Software Process Model
Process model in general are idealization of process which are difficult to implement on real time basis. But idealization of
process model will act as a model for other software being developed resulting into reduction of chaos while developing software.
Software process are abstract in nature and emphasizes on limited issues. There are some specific process model which are
very much useful in one context and less in the other. A software process model refers to the generic view of software process.
Generic view of
software model
Definition Development Implementation

phase phase phase
Generic view of process model
Umbrella activities
Figure
There are three generic phases of software engineering. They are as follows,
1. Definition phase
2. Development phase
3. Implementation phase
1. Definition Phase
This phase emphasizes on problem understanding and planning of a software process model. The various activities performed
in this phase are as follows,
(i) Analyzing the problem
(ii) Formulating the problem
(iii) System engineering
(iv) Planning for the project.
2. Development Phase
This phase emphasizes on providing solution to the issues that arise in the development by using umbrella activities. The
major tasks which are carried out are as follows,
(i) Designing the architecture
(ii) Preparing algorithm of system
(iii) Writing code for the software program
(iv) Testing the software.
3. Implementation Phase (i) Project Management

This phase emphasizes on performing the activities Project management is a technique that focuses on
such as defect removal maintenance activities, deployment, ensuring the commitments made by this technique
change management. Reengineer activity may be performed requires lager preparations, clear responsibilities and
because of the changes occur in business and technology. performance declaration.
Umbrella activities makes sures that definition, development
and implementation phases are executed properly. Some of (ii) Management Oversight
the umbrella activities are quality assurance, configuration Management oversight is a technique that helps the
management, risk management, project management, work software manager to review the developed plan and
products preparation and development process improvement. approve it.
Software Process Improvement (iii) Quality Assurance
Software process improvement is the initial step to
Quality assurance is a process of managing the software
address software problems. It is a technique that considers
quality assurance can be done by nominating the
the complete software task as a process and try to improve,
performance of each software activity like planning,
control and measure it. Thus, software process improvement
implementation and verification and creating an
can be defined as a process that defines set of task that properly
independent report of the same.
performs its task inorder to achieve the desired output. Hence,
it can be said that an effective software process can be achieved (iv) Change Control
by considering the relationships, tools, methods, skills, training, Change control is a basic technique for business, financial
people of required tasks. and technical stability control. This technique enables
The basic steps taken by organizations inorder to achieve a user to create an efficient software by predicting
the required software capabilities are as follows, schedule term, establishing sufficient requirement
1. The current status of development process/ processes and by maintaining stable development cycle. As
must be understood. the requirement gets changed the designer must try
to incorporate those changes as an when required.
2. The vision of desired process must be developed.
Besides this, they must also focus on coding correcting
3. The set of desired process improvement actions must be the problems that are encountered in design and code
established based on priority. which gets encountered at development and test phase.
4. The desired actions must be accomplished inorder to If changes are not properly controlled, then designing,
produce a specific plan. testing and implementation cannot be done properly
thereby effecting the quality plan.
5. The plan must be executed based on the committed
resources. Level 2: The Repeatable Process
6. Repeat step-1. This level provides support to initial process by enabling
Q13. Explain in detail about process maturity levels. the organization to create plans and commitments. This level
provide improvement to initial process level by mastering the
software problems at earlier state. At repeatable process level
Process Maturity Level a degree of statistical control can be achieved by meeting the
Project maturity level specifies maturity level transactions desired estimates and plans. The risks faced by the organizations
inorder to manage the software process. The primary objective at this process levels are discussed below,
of this process is to measure and control the software
1. A defined process framework must be capable of
process inorder to improve it. The process maturity structure
addressing the risk at an early stage of software
enables a user to define assessment method using which an
development process. This is because, without this, an
organization can gather maturity status. Beside this, it also
even technology can harm, affect the process and can
defines management system that enables in creation of maturity
destroy the historic (or) base on which organization
structure so as to prioritizing the improvement action. This
relies.
structure specify the position of the process based on which
the organization can move to next level. The various levels of 2. Development of new type product can lead to creation
process maturity levels are as follows, of new issues and risks. That is, a software team who
Level 1 : Initial have experience developing compiler may encounter
problems in schedule and estimation. Similarly another
This level is called as the adhoc level or initial process group who have created a self-contained programs may
level. This level focuses on defining formal procedures to plan experience interface and integration issues. This can lead
their work. Beside this, it also enables organization to define to destruction of intuitive history of organization process.
procedures for coding and testing. Moreover, this level also
emphasizes on the improving the performance objective of this 3. Changes within organization can make the process highly
level are, disruptive.
Beside this, the basic purpose of repeatable software 2. Resource data base can be managed and maintained
process is to, by developing a process database. This database must
include the cost and yield data to safeguard against loss.
1. Develop a Process Group
This helps in making data available for other projects to
A process group is a group that focuses on specifying ensure process quality etc.
technical resource inorder to improve the software
process. At early stage of maturity, software organizations 3. Process data can be maintained by developing sufficient
mainly focuses on developing a work product rather than process resources. Skilled professional must be assigned
improvement. Hence organizations must develop or to monitor the data quality before maintaining in the
establish a process group that is responsible for providing database, providing guidance on interpretations etc.
improvements within the software process. Thus, the 4. A quality assurance group must be responsible for
responsibility of process group will be, assessing the quality of the product and informing it to
(i) Defining of development process the management if the desired quality is not met.
(ii) Determining new technologies and needed Level 4: Managed

opportunities Managed process also focuses on making considerable/
(iii) Advising on projects essential software quality improvements. The drawback of
managed process level is, it incurs high data gathering cost.
(iv) Performing quarterly management reviews. Eventhough they are many potential measures together the
2. Developing a Software Development Process data, they are very expensive to gather and maintain. The major
Architecture or Cycle problems that are encountered by managed level are,
A software development process architecture or cycle (i) Data gathering must be done carefully by defining each
must be created inorder to represent technical and single of data in advance.
management activities that are needed to execute a
(ii) Non comment, non blank lines and executable
development process. This architecture should fulfil all
instructions are treated equally by assemblers. This lead
the desired organizational needs irrespective of the size
to confusion among developers.
and nature of the project. Beside this, the development
structure describe the structural decomposition of the (iii) Management, test, documentation incurs more costs.
development cycle into multiple task. Where each task
(iv) Process data cannot be used for performing comparisons
specifies functional descriptions, verification procedures
among project and individuals.
and task specifications.
3. Establish New Software Engineering Methods and Thus, the advancements that should be made by managed
Technologies process to move to next level are,
A set of software engineering methods and technologies (i) Gather the processed data automatically. Userpective of
must be developed for creation of software process. This the error and omission.
method must describes about, (ii) Make use of process data so as to analyze the process,
(i) Design and code inspection to modify it and also to improve it.
(ii) Formal design methods Level 5: Optimize

(iii) Library control system In optimize process level, the data is made available for
processing. Process optimization is done at each level of process
(iv) Testing methods and
maturity. It is done inorder to ensure the process quality and
(v) Prototyping. productivity. At this maturity level, the software development
manager are responsible for gathering, analyzing data that leads
Level 3: Defined
to product improvement optimized level,
Defined process level enables the organization to achieve
1. Errors are identified and corrected.
major and continuous progress. That is, a software team can
used to the defined process when they are in need or if they 2. Code and design inspections are performed.
have encountered any issue. This basic purpose is to verify the
software process and improve it. The steps taken by defined 3. Testing is done to cover the errors that are uncovered.
process level to move to next level are as follows, 4. Weak entities of the process are identified and replaced.
1. The cost and quality parameters must be identified of 5. Identification is done to ensure whether the needed
process measurements. This is done to identify the costs technology is used or not.
and benefits of all the activities major process, error
detection cost and correction method cost. 6. Effectiveness of process is measured.
Q14. What is the need for process optimization? Besides this, the software managers must emphasize on
Discuss the people involved in optimizing setting priorities, supply of resources and providing of
process. continuous support to the users. Hence for this reason,
Answer : the changes involved in a software process must begin
Need of Optimizing a Software Process from the top of the software cycle.
A software process must be optimized due to the 2. Involve Every Software Professionals
following reasons, This principle of software process suggest that, software
1. It improves the quality of large and complex code. engineering is a process that involve team work. Thus,
2. It enhances the productivity of the system being people who gets involved in software process must have
developed. sufficient knowledge of software engineering. This helps
3. It reduces the size of current system being developed. in creating a mature structured efficient and reinforce
software process. Moreover, each team member must
4. It makes the process of testing easy.
support each other inorder to improve and execute the
5. It provides significant advancement in software quality. software process. Hence, the people who are involved
6. It also improves the quality of system being developed. in improvement process can gain huge benefits and may
7. It produces large volume of new code. even achieve progress.
8. It enables software manager to understand how to assist 3. Changes can be Done Efficiently Based on Goals and
people/customers in need. Knowledge of the Existing Process
9. It provides people with required support. This principle suggest that effective changes can be done
10. It allows software organization to improve the maturity by analyzing the goals and knowledge of the current
process. process. The software engineer must constantly keep
People Involved in the Optimizing Process track of the process when required.
An optimized software process is mostly dependent 4. Changes Must be Continuous
on quality of people implementing it. An effective optimizing This principle suggest that, management team must
process assist people in the following three ways. recognize that changes are static. Changes pertaining to a
1. It enables software managers to understand the people software process must be constant and their adjustments
needs and assist people/customers in needs. must be done periodically depending on the task and
2. It provides people with required support. relationship. This enables a software team to learn new
3. It enables software professionals to communicate with skills and solve multiple problems. Software process
small, competitive and numerical terms. change can be done based on the following.
4. It defines software framework that enables software (i) Changes which are reactive makes the software
professionals to emphasize the work performance and process difficult.
improve it. (ii) Defects can be improved at every stage of software
1.1.2 Principles of Software Process Change process.
Q15. Describe the principles of software process (iii) Prevention of crisis is much better than its recovery.
change and TSP. Dec.-19(R16), Q2 5. Changes about Software Process can be Retained
OR with Continuous Effort and Periodic Reinforcement
Discuss the principles of software process This principle suggest that, changes in software process
change. Oct./Nov.-20(R16), Q6(a) can be made by performing continuous changes. This
(Refer Only Topic: Basic Principles of Software Process.) require continuous effort of software team and with
Answer : Model Paper-II, Q2(a) periodic reinforcement.
Basic Principles of Software Process 6. Improvement in Software Process Needs Huge
The six basic principles of software process change are Investment
as follows, This principle suggest that, a software process can be
1. Changes Pertaining to Software Process Must be improved by,
Developed from Top (i) Performing continuous planning
This principle suggest that, changes pertaining to (ii) Involving dedicated people
software process can be done based on the leadership
of senior management. That is, management team must (iii) Managing time
focus on providing long term improvement by, (iv) Capital investment.
(i) Understanding challenging goals. TSP
(ii) Monitoring progress. For answer refer Unit-I, Q55, Topic: Team Software
(iii) Analyzing the performance. Process (TSP).
Q16. Discuss the common misconceptions about (iii) A defect free process must be establish to limit the
software process. complex high reliable program.
Answer : (iv) Software testing must be done on the program.
Common Misconceptions of Software Process (v) Recognize and develop a large defect-free program so
as to manage and improve the software process.
The following are the misconceptions of software
process. 3. Quality of Software can’t be Measured
1. Begin with Analyzing the Firm Requirement Software quality measure the effort of quality of
a process being developed. However, there is no specific
Software process basically focuses on gathering the measure that specify the programming quality. Quality
software requirement. Thus, gathering of essential software improvement depends on the amount of effort made in
requirements is the essential and basic step of software improving the software quality. Software quality improvement
engineering. The requirements that are gathered must be must be done inorder to avoid social and economic damage
changed not only based on the demand of firm but also on that arises due to huge error with in the code. Besides this,
customers viewpoint. Besides this, the change in software software quality improvement also enables users to prevent and
requirements can be done depending on the progress of remove errors. This initial step here is to define the purpose of
software. The process of change begins as soon as the software quality improvement. This enables a user to find the
requirements are gathered. This process continues until the errors which resides with in the system and set the ultimate
implementation phase gets processed. This scenario is goals.
basically followed by organization following small scale
programs. However, requirement cannot be stated easily by 4. Software Problems are Technical
large scale programs. Technical software problems are not high priority
problems. Since most of the software problems will be at
Software development is a incremental process that
maturity level 1/level 2. Their focus must be to create an
requires small incremental steps. At each step of development,
orderly process and allow people to efficiently operate it.
details of requirement and implementation are completely
Besides this, low-maturity organizations focuses on controlling
refined. Here, the misconception is that, software developers
the changes, recovering the defects and performing later
basically thinks that gathering of requirement is a customers
enhancements. Such organizations produce products with
job and the development process does not begin until they are
unpredictable cost and marginal quality. However, most
defined explicitly. The misconception about the above concept
of the common software problems gets solved before time
can be summarized as follows,
by constantly reinventing the solutions for disordered and
(i) Customers does not generally have idea of what unmanaged process. Here, the misconception is that inspite
requirements are needed or required. of using improved languages, environment and tools, some of
the technical software problems like cost, schedule and quality
(ii) Initial requirements are often wrongly collected and remain unchanged.
can change.
5. Involve Better People
(iii) A link must be established until the application and
work gets processed (or) until the current job gets Software engineering is a important software
completed. development process. Hence most organizations must try
to involve senior executives in the development of software
2. If Test is Performed then it is OK process. This is because highly experience programmer have
the capability of providing accurate information error free
Testing of large and complex programs requires software code, adequate facilities, well defined methods and
complex operating environments. This is because, testing is a procedures. However, the misconception here is that since
reliable system indicator that ensures software quality. Testing errors are made by software professionals they must be
is mainly done inorder to identify the designing and coding responsible for the loss.
errors that leads to program failure. Software testing makes the
program error free independent of type of testing being done. 6. Managing Software is a Different Process
However, if large program contains errors then testing cannot
Software engineering is considered as different from
be done completely thus, it leads to an unreliable system. To
other engineering fields due to the following reasons.
avoid such situations the following must be done.
(i) It is difficult than other engineering processes.
(i) A high quality software process must be developed.
(ii) It sometimes does not involves senior managers and
(ii) An error free program must be developed based on professionals with sufficient experience thereby making
complex system. the software process ineffective.
(iii) It incurs high cost thereby forcing the software solutions Agents should be selected based on the below
to discover the systems problems very late. considerations.
(iv) It does not follow any stable physical principles. (i) They must be responsible for carrying out change
(v) It does not involve software management discipline. process.
(vi) It is a system element that provides software (ii) They must be capable of understanding the
functionalities to end users by hiding the implementation technical and political software problems.
and design details. This leads to change in requirements (iii) They must respect the people with whom they deal.
based on view point of customers.
(iv) They must gain the confidence of management and
(vii) It integrates various system elements together. must assure that they will act with cooperation and
(viii) It is considered as a black-art by most of the non- acceptance.
software practitioners. This is because, it does not allow (c) Sponsors
software managers to solve any problem on their own.
Sponsoring is a process where senior management
Q17. Describe a strategy for implementing software
recognize the value of work and sponsor it. The process
process.
of sponsoring is done with the help of resources and
Answer : official backing mechanisms. After sporing, the task of
Strategy for Implementing Software Process champions are done based on which the change process
can be initiated.
To implement software process change, software takes
two forms. 2. Change of Elements
1. Software professionals initially considers the changes In software engineering planning, implementation and
as immutable, incapable and technically insoluble. communication are considered as key elements of effective
However to solve such problems they include detail change. Planning phase focuses on including knowledgeable
procedures, standards, rules etc. representative from each group that is affected. These
2. The management does not understand the real software representative are responsible for developing a competent
problems. plan and ensuring its acceptance. After this, the start of
implementation phase can be discussed. Here, some initial trial
However, an effective change in software process em- efforts must be applied to minimize the risk at the earlier stage.
ploys the following three phases. At the end, proper communication must be carried out inorder
1. Unfreezing to maintain the project progress.
2. Moving and 3. Refreezing
3. Freezing. Refreezing is a process that enables the software
In software process, unfreezing is considered as the best practitioners to acquire the required capability using general
effort to understand the software problems. The implementation practice.
of software change can be done based on the following, (i) Maintain a management team that can start the change.
1. Champions, Agents and Sponsors (ii) Alter the procedures of organization.
(a) Champion (iii) Build the measurement and incentives.
Champions are senior management persons who initialise
(iv) Establish dedicated staff so as to monitor the performance
the change in software process. They are responsible for
and support it.
the following,
(v) Set training and education program.
(i) Draw attention of manager to a particular subject.
(ii) Take the blessings of sponsors. 1.1.3 Software Process Assessment
(iii) Launches the change program. Q18. What is software process assessment? Discuss
(iv) Maintains focus on achieving the desired goals. the five assessment principles.
Champions have less chance for success. Answer :
(b) Agents Software Process Assessment
Agents are group of people who are responsible for Software process assessment is a typical review per-
carrying out changes in planning and implementation formed by software organization. This review is done by team
phase. They are responsible for, of software professionals who has high training and assess-
(i) Specifying the resources. ment experience. It is conducted inorder to guide the software
professional and management about the process of improving
(ii) Assigning the task. the overall software operations. Besides this, local and outside
(iii) Making calls to senior management etc. reviewers can examine the complete software process.
Software process assessments main purpose is to deter- 3. Involve Highly Experience Senior Manager
mine the high priority area for improvement and also specifies Senior manager must be involved in assessment process
guidance to perform those improvements. The basic principle of as they are capable of assigning priorities to the organization. In
assessment enables a local software manager and professionals process assessment, local manager are responsible for provid-
to improve their operations by providing guidance to them on ing approvals to software commitments. Besides this, they are
what and how improvements must be done. also responsible for acknowledging the corporate management.
Assessment Principles Where as, the responsibility of senior manager is to handle mul-
The basic assessment principles enables competent team, tiple projects from different locations. This helps in eliminating
sound leadership as well as the cooperative organization to project disruption, simplify assessment arrangements and to
review the software process. The various software assessment promote consecutive action plan and implement them. Here, the
principles are discussed below. senior manager is referred to as site manager. The site manager
1. Identify the process model needed for performing as- is responsible for performing assessments based on the follow-
sessment. up action plans. This plan includes the work that must be done
with priority. Moreover, the site manager must participate in
2. Recognize the requirement with strict confidentiality.
3. Involve highly experienced senior manager. (i) Performing reviews periodically
4. Respect the view of people working in an organization (ii) Assigning qualified people for work
with open mind. (iii) Analyze the progress of the action plans.
5. Concentrate on actions. 4. Respect the Views of People Working in Organization
1. Identify the Process Model Needed for Performing with Open Mind
Assessment Software assessment is process carried out by group of
Software process assessment defines a standard process remote experts. That is, in large and complex organization it
model which enables an organization to review a process based is considered as a review that is done to improve the overall
on the vision specified by the users. This enables a user to com- software process. The local customer who are involved in the
pare assessment processes with the organizational process. The software process work hard to complete the improvement pro-
process maturity model provides a framework to perform the cess successfully. Thus, the senior management must focus on
comparison among various processes. taking local views of the customers. The assessment team must
However, the team that perform assessment must have take the ideas suggestions of local people and evaluate it based
extensive software experience. This is because, assessment pro- on local conditions. They should recognize the ideas and must
cess gets easily degenerated into loosely directed exploration. adjust them with open-mind, professionalism and positively.
As the team member of assessment mostly focuses on specific 5. Concentrate on Action
considerations rather than complete assessments. Moreover, if
The main purpose of software assessment must be
the assessment team gets divided into small individual groups
improvement of software process. Its main action must be to
then there are huge chances of considering all the key topics.
provide solutions to current problems and handle priority issues
But, this may result in creating multiple views of software
and also to implement the recommendation procedures. Prior to
operations which in turn leads to reduction in likelihood of a
software assessment the software team must try to explore the
result. Thus, to avoid such problems assessment must be done
general problems, understand the issues and try to solve them.
by keeping common view of the designed software process.
Since this is very tedious task, software process assessment is
Hence, software assessment process model act as a basic to
considered as an accurate procedure to improve the software
explore the software process. In addition to this, it also act as a
process. In this, the concerns and suggestions are discussed to
framework to setup problem priorities using which the complete
and reported to site manager. Later, based on the approval of
assessment team can work in collaboration with each other and
manager the improvements are done.
can address on the key issues and recommendations.
Q19. Describe the assessment process.
2. Recognize the Requirement with Strict Confidentiality
This assessment principle suggest that, assessment must Answer :
be done inorder to improve the software process based on Assessment Process
organizations viewpoint. This type of review must be done by Assessment process can be carried out based on the fol-
hiding the problems from higher management. Even though it lowing steps,
is very difficult to maintain strict confidentiality particular if the
Step-1: Identify an Assessment Team and the Organization
higher executive wants to see the results but also assessment
team must try to maintain strict confidentiality. This is because, In this step, assessment team is formed based on the view-
(i) Confidentiality allows assessors to discuss the levels of point of team manager. Initially, an assessment team manager
organization. who have huge software experience is selected. The assessment
manager must have posses the following capabilities,
(ii) Confidentiality is needed at organizational level so as to
specify the professionals that their comments would not (i) They must handle small groups and
be attributed. (ii) They must have sufficient assessment experience.
After this, the assessment team member who is a promi- Rule-1: The assessment team members must keep the result
nent software developer, have experience in modeling the soft- of assessment confidential.
ware process is selected. An assessment team must have atleast
Rule-2: The opening and closing of assessment meetings must
a minimum of six software professionals. The assessment team
be conducted by team members.
must be selected based on the below guidelines.
Rule-3: The site member must involve atleast two local
(i) An assessment team should include a software profes-
professionals besides regular member to handle the
sional who have eight to ten years of software experience.
assessment arrangements and execute the work of
(ii) They must have respect in organization. follow-up action plan.
(iii) They must deal informal people efficiently. Rule-4: The development and implementation of follow-up
action plan must be done by site manager based on
(iv) They must be a team player.
the assessment recommendations.
(v) They must attend the assessment training with team.
Rule-5: A local member of assessment must also be made
An efficient assessment team must be selected from responsible for creating a action plan.
group who are involved in assessment process rather than group
Besides external assessment, the organization can even
who are selected for review such team members can also be
conduct in-house assessments based on the above ground rules.
selected from assurance or support group. However, the people
who are involved in the process of reviewing, managing and Step-4: Train the Assessment Team
supporting the assessed project must not be considered as an
The assessment team must completely participate in
assessment team. Even the members involved in parallel proj-
training period, onsite review as well as wrap-up meetings. The
ects, local test, Software Quality Assurance (SQA) can also be
team should attend each session by
a part of assessment team. Besides this, atleast a single software
professional who belongs to the organization must participate (i) Keeping the unrelated calls on hold.
as full time assessment team member. They must focus on
(ii) Rescheduling the meetings and
(i) Planning process
(iii) Rescheduling the commitments.
(ii) Provide background knowledge about organization
Moreover, the role of team leader is to conduct atleast a
(iii) Set up focal point to logical assessment and follow up three day training program to describe the process of assessment
action plan. to entire software team. This program creates a familiarism
about the assessment process among the assessment team.
Step-2: Considering Self Assessment
This enables them to establish a cohesive work group. The
Self assessment is a process where in the organization assessment training to new team can be conducted either by
assess the software process by themselves. It is basically done the senior management or by the member who are previously
in order to identify the potential problems that are present within trained about the assessment process. This training program is
the software process. This assessment initially carried out by carried out inorder to make the new team understand about.
assessment staff in most of the organizations. In this, a temporary
(i) How organization is assessed?
team of members usually gets involved in the assessment process
and try to assess the software project before the site manager (ii) How to contribute on assessment plan?
gets involved. Moreover, if the site managers wants to conduct
(iii) Participate equally in assessment process.
the self assessment by themselves they can sign an agreement
along with the line manager and must make a commitment to The training program is conducted in the following
support it. The considerations that must be made to perform self manner,
assessment are as follows,
1. Initially, outline the schedule and objectives of
(i) Assign work to people when needed. assessment.
(ii) Attend the essential meetings. 2. Review, the assessment principles in accordance to
software process model which is considered as an
(iii) Develop an action plan to describe the recommendations.
assessment framework.
Step-3: Defining Assessment Ground Rules
3. A brief outline of organizations mission must be created
An organization must define set of assessment ground by the assessment team based on the management
rules for assessed organization and assessment team members structure and its history.
to carry out the assessment process successfully. An external
4. Discuss the assessment guidelines with the team member
assessment is basically carried out by site manager and
and ask them to sign/authenticate the written agreement.
assessment team leader. To do this, they must sign a written
agreement including the ground rules. These rules are tested 5. Conduct a team building exercise that helps in establishing
below. an effective and mutual supportive operational mode.
6. A detailed assessment plan must include the following Assessment conduct is a free discussion done by
professionals to provide suggestions on many key problems.
(i) Topics of all the sessions.
The representatives who participate in this assessment must
(ii) Discuss about the leader assignments. possess the following capabilities.
(iii) Identify the errors and how to eliminate it. (i) They must be a opinion leader in a desired area.
(iv) When team conclusion must be reached and how. (ii) They should work on project instead of staff.
(v) How to prepare and present the report, when to (iii) They should be technical professional instead of
prepare it and who will present it. manager.
7. Rehearse the portion of process until the team members (iv) They should understand the assessment process with
gets comfortable with its role. confidentiality.
8. Final training task must includes the details of on site To conduct assessment below steps must be followed.
period/planning. An on site planning is a process where Step-1: Exploring the Questions
a team member can make a note of key active projects.
They can also discuss the way in which the desired Assessment cannot be conducted efficiently as it is
project can be assessed. This planning process also difficult to get accurate information. The reason for such
focus on identifying the different back-up projects if inefficiency is listed below,
certain projects becomes unavailable. To cover the entire (i) Misunderstanding of questions by the respondent.
projects, a review of three or six projects must be done.
A software is basically developed in an English language.
Based on project selection final details of on-site period
Since English is an indefinite language even a small
should be fixed depending on which meeting can be
question may some time leads to huge explanation.
conducted, participants can be selected, maintain daily
schedule and provide administrative support. (ii) Different understanding of few common terms by the
respondents
Q20. Discuss in detail about conducting assessment.
The respondents must have understanding on common
Answer : terms like high-level language, review and reusability.
Assessment Conduct Thus, assessment team must discuss on the required
terms.
Assessment conduct is a method used for implementing
the complete project. This type of implementation focuses on (iii) Respondents are unaware of work going on in their
specifying answers to the following. organization
(i) The purpose of the developing project. Many software professionals narrowly focus on special
areas of software process. However, they are some
(ii) The details of how the project works. times uninformed/misinformed about the type of work
(iii) The various problems encountered. going on in organization by the managers. This is done
inorder to check their experience and to fitter the current
(iv) The desired result that can be obtained.
knowledge of people.
The answers to above set of questions must be prepared
(iv) People cannot accept the truth
before the actual assessment period gets started. The project
manager is responsible for reviewing these questions and also The respondent will not willing to accept the truth about
for providing the overview about status of the project and fur- misused favorable terms, unusual events etc.
ther suggestions. Assessment is generally conducted to ensure As it is difficult to obtain the accurate information for
that the software process is developed on time with sufficient above reasons the assessment team must examine and check
materials. each phase of assessment.
The assessment are basically conducted by a meeting Step-2: Assessment Conclusions
with a group of software professionals or representative who
have detailed knowledge on the below facts of software process. Assessment conclusion is a method wherein an
assessment team creates a conclusion report on preliminary
(i) Software quality assurance and release. outcomes. This report includes the following.
(ii) Software testing. (i) Detail description of site status and
(iii) Software integration. (ii) Summary about preliminary key areas.
(iv) Software coding. Initially this report is reviewed by the project manager
followed by the site or project managers. This review is done
(v) Unit testing.
in order to identify the problems or topics that are overlooked,
(vi) Designing and requirement gathering. misrepresented and overemphasized.
The guidelines to create assessment conclusion report An assessment report must only be in written format
based on initial outcomes are, because,
(i) Review the major issues of the projects. (i) A written recommendation enables the assessment to
understand what is to be recommended.
(ii) Identifying the key issues of next maturity level.
(ii) It eliminates ambigious records of what is recommended.
(iii) Display the supported assessment.
(iii) It act as a ideal tool that helps the software professionals
(iv) Action recommendations that are addressable. to clearly describe about the action plan and
(v) Extensive generalization. implementations.
Step-4: Action Plan
Similarly, the guidelines to create assessment conclusion
based on presentation are, An action plan is a follow up plan prepared by the
local organizations under the supervision of knowledgeable
(i) Agenda
assessment team member. It specifies how the assessment should
(ii) Scope of assessed project be carried out here,
(iii) Conducting assessment based on schedule (i) The software professionals must prepare an action plan
for better result and acceptance.
(iv) Summary of composite status etc.
(ii) The key manager must be responsible for tracking the
Step-3: Assessment Report outcome of the actions taken.
Assessment report is a final written report and (iii) The site manager must periodically review the staffing
recommendations created by the assessment staff and site and progress of project.
manager. It includes recommendations of atleast four items
Step-5: Reassessments
which are of high priority. As organizations cannot handle
multiple tasks on time, the task that requires special attention Follow-up assessments must be conducted by
must be reduced to ten. Such recommendations must be organization after the development and approval of initial action
explained clearly and must be implemented based on priority. plans because,
The outline of report will be, (i) It helps in tracking the progress of the project.
(i) Summary and Conclusions (ii) It specifies the future milestone that is needed to complete
an action prior to assessment.
It includes the detail summary of outcomes and
recommendations. (iii) It helps in assigning new priorities for continuous
improvement.
(ii) Assessment Background
Q21. Discuss in brief about various considerations
It specifies detail description of assessment background to implement assessments.
and assessment process.
Answer :
(iii) Site Status
Considerations to Implement Assessment
It describes summary of site manager. The considerations that must be taken to implement
(iv) Key Outcomes software assessment must be interms of,
It includes brief explanation about each outcome. 1. Risks and
(v) Recommendations 2. Staffing.

In this, assessment of risk will not provide any significant
It defines description of recommendations based on
improvement. Hence, a catalyst is required to inorder to keep
priority.
track of improvement priority like management reviews and
(vi) Appendices goals. Here, long term goals are completely established later
sub goals are specified. Here, the senior manager is responsible
It specifies assessment agreement.
for maintaining high level check points, specifying the plans
The guidelines that must be followed while creating and establishing the periodic issues.
assessment report or recommendation are as follows,
1. Risks
(i) Wording and formatting must be done carefully. The key risks and actions of software process are,
(ii) Start the recommendations with a single or two sentences. (a) Schedule Conflicts
(iii) State what is recommended. Schedule conflicts is a process that helps in conduct-
ing one third of assessment. It is an approach that enables the
(iv) Specify the purpose of recommendation and
executive to discuss about the underlying issues with the site
(v) Specify the process of carring out the recommendations. manager.
(b) Inadequate Support (ii) Senior Management
Inadequate management support is a assessment com- Senior manager is responsible to develop an operating
mitment performed at low management level. Senior executive plan if the commitments are not fulfilled by the
can take long term view to avoid subsequent issues. Moreover, competent people. This increases the frustration among
high level manager are responsible for managing software as the management.
they cannot provide sufficient organization priority.
(iii) Software Manager
(c) Lack of Follow Through
Software manager are responsible for managing the
If management changes and high priority issues are software. But, they are frequently replace by new
encountered then the site manager must focus on reducing an manager as an when required.
action plan. Site manager can even create a final assessment
report and complete action plan. If action priorities is not The basic tasks that must be performed at initial level are,
assigned then improvements cannot be done efficiently. Here, 1. Planning
success can be achieved if the manager can change efforts, have
process improvement capability and proper improvement goal. 2. Cost estimation
2. Staffing 3. Project Scheduling
Staffing is also an severe implementation problem. It is 4. Performance tracking
a assessment technique that generally include,
5. Change control
(i) A small group of people/staff who works full-time
inorder to provide improved efforts, software engineering 6. Commitment management and
process group. 7. Quality assurance.
(ii) Participation in part-time project within action plan
Q23. Discuss the common problems of chaotic
working group.
software behavior and general solutions for the
(iii) Implementation and review of project based on resulting initial process chaos.
actions.
Answer :
1.1.4 The Initial Process Problems
Q22. What are the tasks involved in initial process? 1. Software manager most oftenly make guesses instead
Answer : Model Paper-III, Q2(a) of plan. If the guess fails, it leads to chaos (problems).
Eventhough commitments are considered as accurate but
Task Involved in Initial Process some-times the project scale and functions are based on
Initial process level is also called as adhoc process level. previous experience of guesser.
At this level, the requirements of software process is defined, 2. When the creation of software gets rough, then people
planned, managed and developed. This phase does not deals with strongly believes in magic. At certain instances a “savor”
predicting cost, quality assurance and scheduling of project. In can be encountered or new technology can work. This
this phase, the software professionals focuses on identifying occur due to improper planning.
the unplanned priorities as well as the unmanaged change. As
such identification cannot be identified easily. However, as 3. To scale a software project following cycle must be fol-
the software progress the unplanned priorities and unmanaged lowed
change can be easily identified. The members who belong to
(i) A program is written with multiple lines of code
this group must plan about,
than expected.
(i) Delivery of project on schedule time.
(ii) New technical and management issues occur as
(ii) Efforts that should be made by individual on a specific the programs become big.
project and
(iii) As this is a completely new experience, it is a
(iii) Strengths of the organization. surprise.
The staff that are included in this group are, (iv) If there is an increase in scale, then the cost in-
(i) Well Intentioned and Competent People creases.
Such people do their job effectively on committed time. 4. Higher maturity level is achieved by an organization (or)
But, due to lack of efficient planning and management, new management due to increased competition and new
resources, poor coordination they fail in performing the technical challenges. The maturity basically increased,
required services. due to lack of training.
The general solutions for the initial process chaos are, Commitment is defined by Salancik as follows,
1. Systematic project management must be applied by It is a primary foundation to perform large-scale work.
estimating, planning and managing the process. If multiple professionals work with coordination then mutual
2. Change management must be included by controlling commitments are essential required. For example, if more
changes gathering requirement, designing, implementa- than one programmers work on a single project then in such
tion and test. cases work must be partitioned among the team. This partition
3. Software assurance must be performed using independent includes the following distributions.
technical process inorder to ensure that essential project
activity are performed properly. (i) Function distribution
The basic principles that must be followed by a software (ii) Common interfaces
organization to control the chaos are as follows,
(iii) Standard formats
1. Work must be planned.
2. Maintain the track of the plan. (iv) Naming conventions
3. Partition the work into multiple independent tasks. (v) Test plans
4. Specify the requirements based on each part.
(vi) Data design
5. Manage the relationship each part.
6. Consider software development as a learning process. (vii) Program version and
7. Fix the gap between the knowledge and tasks. (viii) Test cases.
8. Identify what is unknown.
The programmers can work effectively, if they work
9. Work must be managed, audited and reviewed inorder
in mutual coordination with each other and can achieve the
to ensure that work is properly planned.
commitment process. In large software projects, cooperative
10. Complete the assigned work to meet the commitments. efforts of individual is required. This is because, large project
11. Define the plan to improve the knowledge. involve many people and detailed coordination of both. An
1.2 The Repeatable Process effective commitment can be achieved based on following
elements.
Q24. Write short notes on commitment discipline.
(i) The person who do commitment must willingly do
OR
the committed task.
When the process is repeatable? Why?
Answer : Oct./Nov.-20(R16), Q6(b) (ii) The commitment discipline must include work,
Repeatable Process resources and schedule.
A software process is said to be repeatable if it allows a (iii) Prepare an agreement specifying what work should
set of actions to be performed for making the software efficient be done, who will perform it and when it should
while minimizing the variations in development and limiting be done.
unwanted resource utilization. For a successful and efficient
software management, commitment discipline plays a key role. (iv) State the commitments openly and publicly.
Commitment Discipline (v) Meet the commitment as an when needed.
Software project management is a technique that focuses (vi) Prepare a advance notice of new commitment date
on managing the software. Its basic purpose is to ensure successful the committed date is not reached.
completion of a project. To ensure this, system considers commitment
discipline as its basic foundation. Commitment discipline is a method 2. Commitment Hierarchy
that enables planning, estimating, reviewing and system tracking.
This method ensures that the organization meets its specified Commitment hierarchy is a technique opted by
commitments. Commitment discipline is achieved by, management team inorder to make commitments and meet them
on time. It specifies the process based on which work should
1. Make commitment be done to complete the desired commitment on time. Since
2. Commitment hierarchy and commitments are visible to users, strong management support
3. Software commitment process. is needed including the change in requirements by customers.
1. Make Commitment This helps in developing and meeting the desired estimations
and plans. Besides this, the other management commitment are,
Commitment is a type of agreement done by single
person to perform a task on time. It mostly specifies, (i) Supporting the required facilities
(i) Plan of completion date
(ii) Conducting meetings and
(ii) Considerations that are to be made and
(iii) Payment. (iii) Scheduling the meetings.
3. Software Commitment Process The conflicts that effects the efficient management sys-
Software commitment process is a management principle tem are discussed below,
that are opted by top organization so as to achieve the following, Plans of Product and Period
v The senior executive of the organization should make
commitments for software delivery. Annual operating plans creates an operational framework
between line and staff. This plan includes the task that must be
v Commitments must be done after the formal review and performed, assigning of resources as well as responsibilities to
concurrence process is completed successfully. complete the project. Here, allocation of resources to project
v Reviews and concurrence must be properly conducted and staff are considered as an initial step in project planning.
by enabling enforcement mechanism.
The various types of plans that are defined by manage-
The responsibility of senior manager to perform the ment system are,
committed work on time are discussed below,
(i) Define work among customers and developers. 1. Operating Plan
(ii) Produce a document plan containing resource It deals with business and technical issues of organiza-
estimate, cost estimate and schedule. tional and annual terms. Due to this, it is possible to develop
(iii) Involve parties who agree upon a written the following based on each organizational entity.
agreement. (i) Capital requirement
(iv) Develop a business and technical preparation to
ensure commitment irrespective of risk. (ii) Expenses
(v) Enabling the participating group to make use the (iii) Specifying product delivery
resources as an when required.
(iv) Defining annual productivity
(vi) Conduct independent review to ensure that work
is done in accordance to organization standards. (v) Stating annual profitability and
Q25. D e s c r i b e t h e m a n a g e m e n t s y s t e m o f
(vi) Specifying management strategies.
commitments.
Answer : 2. Project Plan
Management System Project plan describes objectives and responsibilities
The general objectives of management system is based of each project. The issues pertaining to project plan are cost,
on the following components. schedule, function, quality, resources and checkpoints. Since
each project has their own set of resources, some of them are
1. Defining a technical and business strategy inorder to
required for common purpose on periodic basis.
achieve long-term goals based on growth rate and market
position. Eventhough, the purpose of product and period are
2. Develop a high quality product that helps in meeting the clearly stated there are few distinctions between the two. That is,
customers requirement in an efficient and timely way. a project act as a fundamental business view of an organization
where as period specify the needed information. Besides this, it
3. Completing the assigned mission competitively and
is impossible to measure project based on annual basis as it is
economically.
difficult to collect annual data on cost, quality and productiv-
4. Improve the ability of organization by handling chal- ity. However, it is possible to measure data on periodic basic
lenges. by translating the project data into periodic terms like annual
The above objectives are followed by most of the orga- budget, plans and reports.
nizations to achieve the desired commitments. These objectives
3. Management Overview
are common to all the software groups since they have equal
contribution for defining resources, assigning priorities, generat- A management system makes use of review and conten-
ing short term responses, identifying long term performance, tion system inorder to resolve the conflicts that arises between
improving productive capability and delivering of products. product and period. It develops a balance between line and
In management system, senior management is respon- staff. As both organization line and staff enables preparation
sible for of annual reviews and plans of all the involved parties. If the
conflicts between product and period then it is possible to
1. Creating annual revenue report.
prepare a consolidated project plan which can be incorporated
2. Identifying profits. in later subsequent plans of next organizational level. Here, a
3. Measuring productivity unique individual plan is created by each project prior to project
initiation, periodic reviews and update.
4. Producing quarterly and annual work report by corporation.
4. Contention Process
A contention system is followed in a review system to support open expression and rational resolution. The basic principle
followed by contention system is to understand the relevant issues of the project and take best decision to solve it. Thus, it can
be said that contention system helps in finding best decision. The following are the principles of contention system,
(i) Review the major decision with all involved parties in advance, discuss the possibilities of agreement and the resolving
of issues before proceeding.
(ii) All the dissenting parties must gather to state view and take decisions.
(iii) The senior member should identify knowledgeable agreement if there exists any disagreement between the parties or if
more preparation is required.
Contention system does not ensure disagreement. Here, “Delegation” is term used to assign responsibility for sub sets of
mission.
5. Quarterly Review
Management system must focus on performing quarterly review on the software process. Quarterly review is done by
group of people to resolve product and period conflicts and to monitor their progress. This review is done to monitor assessment
of project and organization performance with respect to plan and goal.
In quarterly review, site manager act as a senior executive to manage operation like projects, technical support as well
as finance. The technical support of organization includes Software Configuration Management (SCM), Software Quality As-
surance (SQA) and Software Engineering Process Group (SEPG). This review is done inorder to verify the status of the project
based on its plan and objectives. Besides this, while performing quarterly review progress of the product focuses on organization
improvement. This deals with management control system, introducing and developing standardized software process, providing
improvised methods and technologies.
Q26. List and explain the project planning principles.
Project Planning Principles

Project planning is a technique that enables a user to estimate the desired project on time with sufficient resource. It is
a framework for managing reviews and controls. It is a process for analyzing the actual performance of the system. The basic
project planning principles are as follows,
1. If requirements are unclear and incomplete, then a quality program must be developed with accurate and correct under-
standing of users. The project plan begins by mapping the unclear and incomplete requirement to accurate and precise
requirement.
2. Develop a conceptual design based on planning. This design is a initial structure that defines breakdowns of unit prod-
ucts, allocation of functional units, as well as relationships between units. This initial structure also acts an organizational
framework to plan and implement the work. It is impossible to cover error from conceptual design.
3. Refine the requirements, resource projection, size estimation and schedule.
4. Develop a detailed design and implementation strategy if requirements are clear and include them in project plan.
5. Establish implementation details and document it later after future refinement.
6. Project plan acts as a framework for arranging the time and resources throughout the cycle.
Besides this, the various planning considerations and planning cycles that should be defined are discussed below,
Planning Considerations
Software planning is a way of estimating and scheduling resources. Similarly, new product functions must be specified to
develop a software on time. Besides this, software manager must also focuses on resource estimation and scheduling. Software
planning must also specify the duration of project, ensure quality of product. Software planning is a critical test of software man-
agement team. The team considers plan as an initial point to reduce schedule or cost.
Planning Cycle
An iterative planning cycle is as follows,
1. Initial requirements must be gathered as the starting of cycle.
2. The requirements must be understood to create a plan, however commitments cannot be made without a plan.
3. Create a plan by breaking the work into multiple elements known as Work Breakdown Structure (WBS).
4. Estimate the size of product.
5. Gather the resources.
6. Create a schedule.
The planning cycle is as shown below,
Initial Requirement
Negotiating
Commitment
Requirement No
Decomposition
Estimating Estimating Project

Product Size Resources
Developing
WBS
Schedule
IS Schedule
SLOC
Met or Not
Programmer Developing Product

Months and Software Delivery
Machine Time
Compass
Actuals (Database)
Figure: Planning Cycle of Software Development

Q27. Discuss in detail about various elements of a software plan.
Answer :
The elements of project plan are as follows,
1. Goals and objectives
2. Work Breakdown Structure (WBS)
3. Estimates of Product Size
4. Estimates of Resources
5. Scheduling projects.
1. Goals and Objectives
The goals and objectives of project are developed during requirement phase. It is a negotiation period existing among
software engineers and users on how,
(i) Work is to be done
(ii) To measure success
(iii) Needed time and resources are obtained.
As user requirement changes it will invariably changes The main idea behind function point metric is that size of
the work progress, design and implementation effort, defining a software is directly based on the distinct functions or features.
stable requirements etc. Change in requirements are considered Software product which possess several features would be of
as one of the continuous problem of software engineering. The larger size, while the product which possess less features would
goals of project plan are, be of smaller size. When the function is invoked it reads the
1. The product must be implemented in small increments. input data and converts it into output data. For instance, consider
a book feature of library system. When this book feature is
2. Each single increment must be selected inorder to support invoked, it reads it as input and provides its location along with
next subsequent increments or to enhance requirements the number of copies available as output.
knowledge.
3. Maintain the requirements at each increment prior to Thus calculation of number of input and output data
designing. shows the number of function which supports the system.
Function point metric also helps in estimating the size of a
4. If changes in requirements occur as a part of implemen- software product. The size is presented in function point in
tation then perform those changes in next succeeding terms of the weighted sum of the five problem characteristics.
increments. Function point is calculated in two ways,
5. If changes are not encountered, then stop working,
perform requirement modification, revise the plan and In the first step, the unadjusted function point is estimated,
start the designing process. while in the second step technical complexity factor is estimated.
2. Work Breakdown Structure (WBS) Unadjusted Function Point (UFP)

For answer refer Unit-III, Q23. Unadjusted function point is expressed in the following
3. Estimates of Product Size manner.
The product size estimate is considered as an quantitative UFP = (NI) * 4 + (NO) * 5 + (Na) * 4 + (NF) * 10 + (NT) * 10.
code assessment needed for product elements like subsystems,
components and modules. The concept of contingency is applied Different Parameters
to these estimates depending on the previous project experience. The different parameters of UFP are as follows,
4. Estimates of Resources
(i) Number of Inputs (NI)
The required resource estimates for each WBS element
are specified based on prior experience or unknown productivity Data item input is provided by each user data. It is
factors. different from user inquiries. Programmers do not count
individual data items but only consider set of related
5. Project Schedule inputs as a single input. For instance, entering the details
A schedule for key tasks and deliverable item can be of an employee in pay roll software such as Name, Age,
specified depending on project staffing and resource estimates. Phone numbers, Address, Sex is considered as a set of
Q28. Write short notes on LOC and function points. related single input.
Answer : (ii) Number of Outputs (NO)
Lines of Code (LOC) Outputs denotes the screen outputs, error messages
LOC is one of the simplified metric present among all the produced, reports printed. When number of outputs are
other metrics to assess project size. It estimates the project size calculated only set of related data items is counted but
by taking into account number of source instructions present. individual data items present within the report are not
But it will not consider the header lines and commenting code considered.
lines during the process of counting. It is difficult to determine
(iii) Number of Files (NF)
LOC count at the beginning of a project, while quite an easier
job to count LOC at the end of a project. Thus project manager Files refers to logical file and physical file. Logical file
adopted a technique of dividing the problem into module. Again denotes a set of logically related data. Therefore they
the modules are divided into submodules till it figures out that can also be physical files or data structures.
the leaf node module size. Total size estimation is achieved only
after gaining the estimation of lowest level modules. (iv) Number of Inquiries (NQ)
Function Point Metric Number of inquiries refers to the distinctive interactive
In the year 1983, Albrecht developed Function Point queries which are inquired by user. These are nothing but
Metric. It overcomed several drawbacks of LOC metric. The the user commands which needs action to be performed.
biggest advantage of function point metric is that it computes (v) Number of Interfaces (NT)
the size of a software directly from the problem specification.
Whereas incase of LOC, the size can be estimated only after Interfaces refers to things used for exchanging details
the product has been completely developed. with other systems. For example, data files, tapes, disks.
Technical Complexity Factor (TCF) (b) Estimating Bias
Technical Complexity factor enhances the unadjusted It is a type of error that occurs at stage when estimates
function point measure by taking into account some factors are made. If the estimate is done early, there are less
such as throughput, high transaction rates, response time chances of inaccuracy. The greater the chance there are
requirements. more chances of inaccuracy.
These factors are allotted values from 0 to 6. 0 where 0 (ii) Estimating Contingencies
represents not present or not influenced while 6 represents strong Contingency is a technique wherein the programmer
influence. TCF is expressed as (0.65 + 0.01 * DI). can estimate the desired code inorder to implement a function.
DI represents 0 to 70. Thus, TCF value varies from 0.65 It deals with resource estimate scheduling and increased cost.
to 1.35. In the end the total estimation of function point metric To estimate contingency prior knowledge of programmer about
can be obtained using the expression. new product must be made and its range should be selected.
Each software size should include the concept of estimating
FunctionPoint = UFP + TCF contingencies with product code.
Q30. Explain about scheduling and project tracking.
Q29. Discuss the Wideband Delphi estimation
technique. Answer : Model Paper-II, Q2(b)
Answer : Scheduling
The Delphi estimation technique helps in estimating Project scheduling is determined based on the resources
the size of the software product that is being developed. It is that are encountered over planned product development phase.
considered as one of the better estimation technique than other
This estimation is done by analyzing the data depending
estimator. It focuses on improving the estimates. The procedure
on the historical experience organization. If such data is not
for this is as follows,
available then factors like resource and time that are publicity
1. Specify the program specification and estimation form available are used for determination. The conditions that should
to group of experts. be consider for scheduling are,
2. Group of experts must gather to discuss on estimation 1. Various project phase definitions
issue. 2. Various resource categories included
3. They must fill the estimation form anonymously. 3. Different software methods used
4. Estimate coordinator takes the estimates, tabulates the 4. Various product types being developed
result and send it back to the experts.
5. Various levels of programmes skills
5. Next, the identity of each expert personal estimate is
specified and the rest are kept anonymous. 6. Degrees of project.
The conditions can vary among organization and
6. The experts conduct a meeting to discuss the result, to
projects. As the organization must focus on gathering the
revise the estimates etc.
resource distribution data. After this, the overall project schedule
7. Repeat the cycle unless the estimate converge is accept- is followed. This is as follows,
able.
1. Develop a staffing plan.
This estimation technique deals with following two is- 2. Establish/create a preliminary schedule by performing
sues, comparison among cumulative resource needs and
(i) Estimating inaccuracies expected needs.
(ii) Estimating contingencies 3. Review the preliminary plan so as to ensure that there is
a consistent assignments of staffing based on schedule
(i) Estimating Inaccuracies and resource profile.
When software estimates are inaccurate, it results in poor The process of scheduling is done based on work
size estimation, inappropriate resource plan and due to under- breakdown structure which is dependent on the current project
staffed project. This results in late delivery and poor quality of phase as well as previous experience.
product. Estimating inaccuracies are of two types.
Project Tracking
(a) Normal Statical Variation
Project tracking is a project process that focuses on
It is a type of variation technique that is handled by mul- schedule and checkpoints. This process is referred to as earned-
tiple estimator. It generates multiple estimation results. value project scheduling that focuses on following,
1. Determine checkpoints for each project phase to perform tasks like,
(i) Creation of module based on specification that are completed and approved
(ii) Creation of module that has complete design, inspected and corrected
(iii) Creation of unit plan module that is complete, reviewed and approved
(iv) Creation of module that is complete and clean
(v) Creation of code module that is inspected completely and corrected
(vi) Creation of module that is unit tested, delivered to SCM with baseline integration.
2. Determine the resources that are needed to complete each checkpoint based on total project.
3. Plot the plan as shown below,
90
n
80 Pla
70 tual
60 Ac
Complete 50
percentage 40
30
20
10
0 2 4 6 8 10 12 14 16 18 20 22
Weeks
4. Actual performance of the project is tracked as the project progress. This is shown in the dotted line.
As scheduling is applied to complete project, the overall status of the project is specified to users. Project tracking for large
projects can be done based on the following key points,
1. Each checkpoint must be measurable and specific.
2. A detailed plan must be created that allows the checkpoints to
(i) Complete 50% of the module design, conduct reviews make corrections
(ii) Complete 25% of test cases without errors.
(iii) Complete 15% of test program without error.
3. The project plan helps in determining the percentage of that is complete.
Q31. List and explain the basic configuration management functions.
Answer :
Basic Configuration Management Functions
In basic configuration management system initially a baseline is developed, after the initial product gets stabilized on each
successive set of increase (of a baseline) a new baseline in developed.
v Each baseline is then maintained within a database, at one place with all the changes that produced it.
v Thus, it can be said that a baseline is the official repository of the product and it holds the most current version.
v A baseline includes the approved changes and the tested code which is fully protected.
v A baseline act as a source that helps the programmers to ensure that/their task is performed consistently.
v The main SCM tasks are,
(i) Configuration control
(ii) Change management
(iii) Revisions
(iv) Versions
(v) Deltas
(vi) Conditional code.
Configuration Control
The task of configuration can revolves throughout an official copy of code.
v The eariest way to protect each system revision is to keep a separate official copy at ever revision level.
Initial Establishing Baseline
development baseline update validation
Requirement/ Authorize
design use change
Baseline
Changes
Change
implementation
Approve Change
change validation
Figure (i): Overview of Change Management

v This would take a let of storage space, one of the issue is with code division.
v When more than one group work on different copies of the same or similar versions of common code, sometimes different
changes are made to correct the same problems.
v The final cost of this can be understood by considering system drivers.
v Example, one programmer may require a copy of the system control program for unit test.
v Although the control program may not completed, the functions this programmers required may be unstable.
v Hence, it is helpful to provide a control program copy with this function rather than write the developers time.
Revisions
v Revisions is one of the significant task of configuration management.
v In this large systems, some program such as control system, provides essential function for all others.
v If the component's module have been combined into a testable unit, then it can be tested with the latest control program
level.
v These previous tests can be re-run to find the problem source, if further problem are found.
v If an early driver is produced again, using the latest versions of the control program modules, some of these module will
likely be changed, so the previous tests are not exactly produced.
v One of the key feature is to keep track of all the changes that have been made to module and test cases.
v Always there is only one latest official version and all previous versions are identified and maintained, such that these
copies can be used in tracing problem.
v Continuous process of revision, integration and test is nothing but the development.
Derivations
One of the powerful software testing feature can be used to find what has changed.
v Example: If a program works on day the and not in the next day, then the first step is to find what are the changes.
201 Level 226
Control
Module Test A
program
201 Level 227
Control
Module Rerun test A
program
Figure (ii): Derivations

v Derivation data would show that test a was run on control program level 116 and the rerun was attempted on level 117.
v Changes x and y can be identified.
v Data then might be maintained in such derivation record is,
1. Revision level of every module.
2. Revision level of the tools used to assemble compile link, load and execute the program and tests.
3. The test cases used and the test information employed.
4. The files used.
5. Software and hardware system configuration along with peripherals, features, options, allocations, assignment and hardware
change levels
6. The operational steps.
7. A record of job streams being executed when there is no stand along test.
Versions
If a module changes then there can be other potential issues. More different tasks can be implements by the same module
with few small coding differences.
Example
The following figure shows that, the standard memory management would be used below 512 K and the other using a
mode switch would hold the larger memory size.
v The different programs would have the different designation, like MEMS and MEML for the standard and large memory
management modules.
MEM
> 512
Large MEM MEM Standard

memory memory
Figure (iii): Versions

Deltas
v Execution of deltas is another test of configuration management.
v On one hand, the versions solves the problem of different functional requirement for the same module but on the other
hand creates multiple copies of the same code.
v To overcome this problem of multiple copies of same code use case deltas.
> 512 MEM
> 512
MEM MEM
Large memory Standard memory

Figure (iv): Deltas
Example: The above figure illustrates that saving the base module like MEM, along with the changes required to make it into MEML.
v When the changes are required on MEM then the changes can be made directly, with interface will the delta code.
v The changes are only made to the MEML code and the MEM code is left unchanged.
Conditional Code
Conditional program construction is used to handle the small changes between modules.
v Consider an example,
Billing
NY CT PA
program
Billing Billing Billing

program program program
NY CT PA
Newyork Connecticut Pennsylvania
Figure (v): Conditional Code Scenario

v The above example shows the billing program which include different functions depending on the requirement of a state
on sales tax.
v The program includes different sales tan versions, but they would not be included in final system unless called for a system
installation.
v This requirement of conditional code is fulfilled by using system generation options.
v Based on the conditional code, one of the many available optional modules is selected depending on the specific state
where the program was used.
v One usage of conditions, case the code control as there is only one official copy if every module.
v Another advantage of the conditional code is that providing one complete copy of the complete program.
v All the code would be available, and users have to select the specific combination required for installation.
v Once conditional code is ready, this requires that all the program options and features be provided to the end users, but it
is difficult to control unauthorized distribution and use.
Q32. Explain in detail about SQA. 1. Error-based Testing
Answer : This type of testing searches a specific method in a class
for determining hints of their interest. Then these hints are tested.
Software Quality Assurance (SQA) For example, to test salary payment method of a company class
Quality is used to determine if the software meets all the different values of number of hours have to be tested i.e. 40 hrs,
25 hrs, – 10 hers, 90 hrs, etc. The test must check whether the
requirements that were specified during design phase. Software
program code handles these values. If the values are not handled
quality assurance is used to monitor the software processes and
then the error must be reported.
methods for ensuring its quality. By using audits of quality
management system, SQA improves the software quality. Error-based technique can be used for integration testing
by performing test on the objects that process messages.
SQA is very much related to quality assurance in product
manufacturing. There are some noticeable differences between 2. Scenario-based Testing
a software product and a manufactured product. A manufactured This type of testing is also known as usage based testing.
product is something that is physical entity which can be seen, It aims at the tasks performed by the user by identifying the use
whereas software product is invisible and temporary. Because cases and user tasks. Then the tasks are performed and different
of this nature functions, benefits and costs of software are not forms of tasks are tested. This type of testing may also detect
measured easily. When a manufactured product is ready for interaction bugs. Only a single-form of test is performed on
shipping. It is said to be a complete, finished product. Whereas different subsystems. It does not detect all forms of errors.
However, it detects high visibility system interaction errors.
software product is intangible and can never be finished. Testing
the quality of a software is expensive because it include cost of 1.3 The Defined Process
detecting and correcting bugs, cost of developing and executing Q33. List the reasons, benefits and examples of
test cases. software standards.
Software quality assurance is required because the Answer : Model Paper-III, Q2(b)
computers fail to work as per users commands. Hence there Software Standard
is a need to develop a bug free code. This process is known A standard define rules to assess the size, content, quality,
as debugging where bugs are found and corrected. Some object/act and value. A software standard specifies the way in
bugs can be easily found whereas other need special testing which software is developed and maintained. Software standards
methods. Debugging provides tools that detect the errors and are defined based on languages, coding conventions, comments,
corrects them. Following are some types of errors that may be error reporting etc, software standards are defined based on
encountered during debugging. people product and tools. It is essential for developing common
supportive environment, enabling integration or performing
1. Logic Error system testing.
This type of error occurs when the code, does not function Reasons for Defining Software Standards
accordingly inspite of being syntactically correct. The The reasons for defining software standards are as
code can execute without performing any irrelevant follows,
operation but produces irrelevant results. This type of
(i) They enables large software organization to determining
error can be detected by testing the code and analysing single set of uniform procedures that provides
the out come. significant amount of training and procedure that
2. Run-time Error provides significance amount of training and procedure
development.
This type of error arises during the program execution. (ii) They allows professionals to move between projects
It is detected when a program performs out of its desired
(iii) It reduces the need of training
functionality. For instance, accessing an object which
has not been declared. (iv) It defines uniform method to review the work and its
respective status
3. Syntax Error
(v) It specifies the usage of better tools and methods
This type of error arises if the code is incorrectly written. (vi) It describes common coding conventions and commenting
For instance, misspelled keyword or missed punctuation. guidelines to review the project data
These errors can be detected easily without the need of (vii) It facilitates inspection of designing and coding
any debugging tool.
(viii) It improves the maintain ability of developed product
These errors can be eliminated by performing Quality (ix) It makes programming efficient
assurance testing. There are two types of Quality assurance
(x) It provides standards for error reporting, test plans and
testing error-based testing and scenario-based testing.
estimations.
Benefits of Standards (i) Priority needs with in an organization
Software standards enables a software manager to (ii) Projects status
create a successful software product and process. It specifies (iii) Standard enforcement mean.
rules based on which the desired software can be created. The
The standards are established by examining the standards
standard assembler language of IBM i.e., IBM's OS/360 allows
and procedural needs of the organization. Software are defined
co-operative development of 13 laboratories and 6 counted.
based on the following three categories,
Moreover the use of standard high-level language like PSL
provides project/product development and support. Beside this, 1. Managing and planning procedures and standards.
standard also assist the software managers. To analyze the key v Management configuration
software problems and find their effective solutions depend on
v Costing and estimating
standard and procedures. it also helps in analyzing the success
and failure of a project. v Software quality assurance.
Example of Some Most Commonly Used Standards 2. Developing process standards and methods
v Specifying requirements
The software standards which are defined by IBM's
Federal system Division (FSD) are listed below, v Design
Systematic Design Practices v Documentation
1. Logical Expression v Coding

v Testing and integration
It describes a mathematical-based technique based on
reasoning and expression. It can be applied in all phase v Review, walkthrough and unspection.
of software development. 3. Tools and Process Standard
2. Program Expression v Naming the product
It specifies data, program structure and control to record v cost and size measures
the program design. v Counting and recording defects
3. Program Design v Editing and code entry tools
If describes the stepwise refinement process to record v Documentation system
the structure of program design. v Languages
4. Program Design Verification v Library system.
It defines function theoretic technique to prove Standard Development Process
correctness of a structured program. The steps to develop a standard are as follows,
System Design Practices (i) A standard strategy must be developed with priorities
It describes the process depending on state machines. It and prior work recognization.
allows creation of specification and documentation of software (ii) Review, distributed and maintain the standard strategy
system. (iii) Top-priority standard can be created by choosing a n
Real-time Design individual/small working group.
It specifies stage-wise designing of asynchronous (iv) The defined standard must be developed based on
software process inorder to identify concurrent operations. (a) Prior work that is available
Besides this, various code management standards are (b) Areas that are applicable
described by IBM FSP inorder to cover programming languages, (c) Defining introduction strategy and
coding standard and conventions, software support, hierarchical
(d) Purpose of enforcement plane.
program control library and high order programming language.
Some of the standard and conventions of IBM are coding (v) Distribute and review the drafts standards
standard, operating system software, program support library. (vi) Revise the standards by incorporating the comments of
Q34. Discuss in detail about establishing software review and re-view it if changes are encountered
standards. (vii) Implement the standard based on test environment
Answer : (viii) Review and revise the standards after the test
Establishing Software Standard (ix) Implement the standard across specified area and enforce
it
To establish software standards an organization must
consider the following, (x) Standards are to be evaluated based on actual price.
A standards are be established by individual/small group It also defines means to implement a standard software
of technical experts. New standards can be established by engineering process within an organization.
adopting it from another organization, (or) by identifying the
2. Inspection is done to develop at generic checklist and
needs of users (or) by enforcing standards that fulfil the criteria.
standards based on each inspection type desired project
As software standards are used for management and technical
needs. The generic checklist must include inspection
purpose. It specifies formal review process that enables reviews
plan, preparation, conduct, as well as exist report.
to create a plan, design implementation approach and adopt
enforcement provisions. 3. Inspection is performed to prepare a list of reviewers (in
advance). So as to identity the concerns and questions
2. Maintaining Standards
prior to begging of inspections.
Standards can be maintained by either individual or
4. Inspection helps in determining the problem, ensuring
group. The responsibilities of individual/group to maintain
the inspections conducted with minimum time.
standards are as follows,
5. Inspection is basically handled by group of technical
(i) Standard implementation problem should not be
people for people who does technical work. This is done
considered
to identify the technical problems.
(ii) Guidance and advises on standards must be considered 6. Inspection process and its data is maintained within
(iii) Standard baseline and control change must be maintained database to monitor its effectiveness and to mange the
quality of product.
(iv) Review the standards periodically inorder to ensure
effectiveness. Software inspections are done so as to improve the
quality of software process as well as its productivity. It is a
Q35. List the objectives and principles of inspection.
type of review done by the software programmer inorder to
Answer : Model Paper-I, Q3(a) improve the software quality fixing the encountered errors prior
to software development.
Inspection
Q36. Write about various types of software testing
Inspection is a process of verifying the work/product /
strategies.
process technically and provides assessment of the product and
specify the desired improvements. It is basically done prior to Answer : Model Paper-II, Q3(a)
high level designing, implementation and test.
Testing Strategy
Inspection Objectives Testing strategy is used to detect bugs in a product/
The inspection objectives are listed below, system by considering all the constraints. There are many testing
strategies in object oriented approach. Following are the most
1. It focuses on identifying error at early stage of
important strategies.
development cycle.
1. White Box Testing
2. It ensures that the technical parties to agree of work on
time. 2. Black Box Testing
3. It verifies that checks whether the predefined criteria is 3. Top-Down Testing
met or not. 4. Bottom-up Testing.
4. It focuses on completing the technical task on time. 1. White Box Testing
5. It specifies the product data and inspection process. White box testing deals with the internal logic and
Besides this, it provides the below benefits, structure of the program code. It is also known as glass-box,
structural or open-box testing. In glass-box testing, test cases
(i) It ensures that the related working team are familiar with are derived based on the knowledge of software structure and its
the product implementation. The tester can analyze the code and make use
(ii) It allows development of effective technical team of the knowledge about the structure to derive test data. White
box tests can analyze data flow, control flow, information flow,
(iii) It assists utilization of best talent in organization
exception and error handling techniques. These techniques are
(iv) It enables the developing participants to become a reviewer. used to test the behavior of software.
Basic Inspection Principles A tester should have explicit knowledge about the
internal working of the system being tested. Branch testing
The basic inspection principles are as follows,
and path testing are the techniques used in white box testing.
1. Inspections are considered as a structured process If the implementation details are changed, the tests should also
that includes system checklists and specified roles of be modified. The different methods used to perform white-box
participants. testing are as follows,
(i) Statement Coverage (iii) How system operation is effected by specific combination
Test values are provided to check whether each statement of data?
in the module is executed at least once. Statement testing (iv) How are system performance and behavior tested?
executes statements when, (v) How are the limitations of data class be destroyed?
(i) Optional arguments are available (vi) Whether all the input parameter are accessible by the
(ii) User-provided parameters or procedures are system?
available 3. Top-Down Testing
(iii) Planned user-actions are available Top-down testing is a method is which the testing begins
(iv) Defined error codes are available. from top or main control module of main program and moves
down in the control hierarchy. It assumes that the primary logic
(ii) Branch/Decision Coverage of the application or object interactions and systems require
Tests are performed to check whether each branch of a severe testing. It detects critical bugs in the early stages of
decision is executed atleast once. Decisions require two implementations thereby providing a quality product because
values in standard Boolean decision testing. But in case of iterative testing. It supports user interface and event-driven
of compound or nested decisions, the number of Boolean systems.
decision values can be greater than two. Top down testing for user interface tests the interface
(iii) Condition Coverage navigation through screens. It checks whether they satisfy the
requirements. It has an advantage that users will be able to
Tests are performed to check whether each condition in
see the look and feel of the application in the early stages of
a decision accepts all the necessary outputs at least once.
implementation. In addition to the above, top down testing is
It also checks whether the entry points to the procedure
also useful for testing subsystems and system integration.
or flow is invoked at least once. In case of compound
and nested loops, condition testing is provided with 4. Bottom-Up Testing
multiple test values. The other exceptional routines and Bottom-Up Testing is an alternative to top-down testing.
error handlers are also invoked while testing the entry This technique initially begins by considering the units at the
points. lowest level and proceed upwards till the main unit is reached.
2. Black Box Testing In this testing, individual objects of system are tested integrated
and tested for their interaction.
Black box testing is also known as Functional testing
or Behavioural testing. It is an effective and efficient approach Bottom-up testing tests the class and methods that
used to concentrate on the inputs, outputs and principle function call other methods. Then the classes and methods of the next
of a software system module. In a block-box testing, the test upper level that call the lower level classes are tested. Then
of a software is based on system specifications rather than on the integration of two bottom layers are tested. This process
code. Thus, the system is assumed to be ‘black box’ whose continues until the complete program has been tested.
behavior can only be determined by studying its inputs, outputs Q37. Explain the Booch Methodology is detail.
and functional requirements of the software. The tests can be
Answer :
observed from the program codes or component specifications.
Booch Methodology
Black box testing is helpful to software engineers in
order to understand the set of input conditions, which define Booch methodology is used to design systems using
overall functional requirements of a program. Black-box testing object-oriented method. It uses the Analysis and Design phases
is useful to identify errors such as, of OO method. It defines many symbols to describe the design
decision. However, many symbols will be left unused. The class
(i) Inaccurate functions and object diagrams are used in the Analysis phase. After this
(ii) Interface errors the code is generated by using design symbols.
(iii) Performance errors Booch Methodology contains many diagrams like class
diagrams, object diagrams, state transition diagrams, module
(iv) Data structure errors
diagrams, Process diagrams and interaction diagrams. It
(v) Initialization and termination errors. describes two methods-macro development process and micro
Black Box testing is performed after studying the white development process.
box testing that prints to the control of the system. Macro Development Process
The following are the questions that black box testing This process manages the technological areas in a system.
answers, It takes place from weeks to months. It maintains the traditional
(i) What will be the capacity and the speed of system data? Analysis and Design phases and acts as a framework for micro
process for controlling its activities Macro development process
(ii) What are the classes that results in good test cases? is carried out in the following steps,
1. Conceptualization The Unified Approach (UA) proposed the concept
of repository because it provides several benefits to the
In this step, the major requirements for the system are
organizations. That is, suppose an organization takes an initiative
discovered. Then a prototype and goals to achieve the
to develop a new application or a software whose requirements
project is developed.
are almost similar to the requirements of the projects that were
2. Analysis and Development of Model designed earlier. Then the developer can easily select only those
requirements from the repository that are useful.
In this step, class and object diagrams are used. Class
diagrams describe the behavior of objects by means of The reason behind promoting the idea of repository
roles and responsibilities. Object diagrams describe the is that, if an application is designed and developed based on
behavior of system by means of scenarios. It also uses the previous design experiences, then it helps in increasing
interaction diagrams to describe the behavior of system the quality of the product and it also reduces the cost and
by means of scenarios. development time of the product. The most frequently used
repositories are microsoft repository, power Builder, Delphi,
3. Design the System Architecture visual Age and Visual C++. All these repositories has the
In this step, class, object, module and process diagrams capability of storing the previously defined objects and can be
are used. Class diagrams are used to identify the classes reused in the future when there is a need of developing a new
and their relationships. Object diagram is used to identify software or an application.
the methods that demonstrate the way of collaborating The authority of accessing the repository should not be
objects. Module diagram is used to locate the place of restricted to some group of people. The search for the object or
classes and objects. Process diagram is used to allocate classes in the repository based on their attributes, characteristics
processes to processors. It also identifies the schedules should be made easy. So that the application developers can
for processes on similar processor. select the required components or objects that matches with their
4. Implementation business needs and can gather all those required components
and produce a new application whenever required.
In this step, the system is refined by performing many
iterations. It generates software such that each software Q39. Explain in detail about patterns and pattern
is an enhancement of the previous software. templates.
5. Maintenance Answer :
In this step, changes must be done on location basis for Patterns

adding additional requirements and removing the bugs. Patterns are used in software development to provide
Micro Development Process documentation which assists designers to classify and discuss
about recurring problems.
This process manages all the micro processes involved
in the development of a system. A micro process gives the The process of developing a system can be developed
description of all the activities by means of an individual or efficiently when developers have a clear knowledge of how to
group of developers. Every macro development process has its analyze, design, and produce that system from scratch and refine
micro development processes. its components. A software engineer's most important feature is
to have a brief grasp on vocabulary of a system to express how
The steps involved in carrying out a micro development its domains or concepts are related to each other.
process are as follows,
So it is required to have a subject of vocabulary that
1. Finding the classes and objects. serves engineers to address typically encountered complicated
2. Finding the semantics of class and object. problems. Patterns serve this purpose. In this way, developers
can exchange ideas and experiences on these problems to
3. Finding the relationships between classes and object. identify similar patterns to produce better solutions. These
4. Finding the interfaces and implementation for classes patterns are now generally applied in software architecture,
and objects. design, specification models, software development process.
Q38. Discuss about the UA Proposed Repository. If certain pattern of problem has occurred once and it is
not sure whether it occurs again in future at this stage then that
Answer : pattern is called as proto-pattern. But it is also not considered
completely as pattern. Until it is reviewed good pattern has
Repository is a place where the previously defined data
following characteristics.
such as objects, patterns, frameworks and user interfaces are
stored. This data comprises of the best practices of already (i) They identify solutions to problems.
completed projects. Sharing of best practices minimizes
(ii) They are proven concepts and keep track of problems
duplication and ensured good quality and productivity with less
that were experimentally solved.
efforts.
(iii) A good pattern produces solution to a problem indirectly. 7. Resulting Context
(iv) They describe relationships between various system This section describes the configuration of the system
modules involving in the problem. after the application of pattern. It also describes the
(v) A good pattern explicitly has a good appeal to it in terms results problems and new patterns that arise as a result
of its usage to its users. of applying pattern. It is also known as resolution of
forces because it specifies about the forces that were both
(vi) A good pattern begins with an abstract to facilitate an
resolved and unresolved and also specifies the patterns
overview of the pattern.
that can be further applicable.
Pattern Templates
8. Rationale
Pattern templates are several attributes of a pattern
which describe about the whole aspect of the existence of a This section describes the guidelines or method of
pattern. Every pattern must contain these templates as a form pattern specifying how and why the system works in a
of constraints. These essential templates or components of a specific way and the way it accomplishes the solution
pattern are given below, to a problem. It gives reasons to why a pattern is best in
solving the problem. In general, the solution describes
1. Name
the explicit description on how pattern works but
This section describes a meaningful single word or short rationale describes about the deep structure and key
phrase for the pattern that serves as its name. This name internal mechanism involved in the pattern.
serves as a vocabulary which can be used is conceptual
abstractions. The name usually reflects the kind of action 9. Related Pattern
associated with that pattern. This section describes patterns with similar static and
2. Problem dynamic behaviour. These patterns may share similar
forces. They may posses initial or resulting context
This section describes the problem specifications to
compatible with the initial and resulting context of other
which pattern needs to be applied. It also describes the
pattern. These patterns may be of the following types,
aims and objectives that must be achieved within the
context. 1. Predecessor patterns whose application results to
3. Initial Context the underlying pattern.
This section describes the actual configuration of the 2. Successor patterns whose application is followed
system before the application of pattern to it. It specifies from the underlying pattern.
the preconditions under which the problems and their 3. Alterative patterns that provide different solution to
solutions recur. same problem with different forces and constraints.
4. Forces 4. Code-dependent patterns that must be used with
Forces means the motivation for generating the resulting the underlying pattern.
pattern. They specify the complications and trade-offs
10. Known Uses
that must be considered at critical times. The description
of a good pattern must encapsulate all the forces that are This section describes the existing occurrences of the
likely to have impact on it. pattern and its applicability in the existing patterns. This
is done to verify that the resultant pattern to ensure that
5. Solution
it is a proven solution for the recurring problem known
A brief description of static and dynamic behaviour of uses of a pattern sometimes can be used as instructional
the pattern's solution is described in this section. This examples.
helps as a guidelines and avoids the risk of disastrous
mistakes when implementing the solution. This solution Q40. Explain in detail about three models on which
can be explained with the help of pictures, diagrams software process models are defined.
provides pattern structure. Other information which must Answer : Model Paper-III, Q3(a)
be included are participants, collaborations involved in
The three models based on which software process are
the process of the solution and sometimes alternative
defined are listed below,
solutions can also be included.
6. Examples 1. U-process model (spiral model)
In this section, some of the applications where pattern 2. A process model
is used are provided. It also describes the way patterns 3. W-process model.
are applied and their transformation. This helps the
user understand the applicability of the pattern. The 1. U-process Model
use of examples from the commonly known systems U-process model is also called as spiral model. This
with graphical diagrams is preferred for a better mode is a software process model that enables development of
understanding. efficient software process.
2. A-Process Model 3. Instability of Requirement
Atomic level process model or A-process model is an It is one of the major issue of software process for
in detailed software process model. It is an automatic process many organizations. This is because, software process must be
model that automate (or make use of) the de... process activity, developed, designed and tested depending on the factor like
or standardized methods and procedures to execute a specific interfaces, functions and stable environment. If these factors
task. This models explicitly defines data defunctions, algorithm, are changed during development, and design process then such
information flows, procedures at each level. This level is changes can either be convected or preserved and development
basically designed to specify definition standard task and tool and design phase can be proceed. However, if these changes are
usage. not collected then the development process becomes unstable.
Besides this, requirements changes also one the factor that
3. W-Process Model effects the quality and productivity of system. The requirement
Worldly process model or W process model defines change occur due to following reasons,
sequence of tasks, prerequisites and results. This creates an (i) If Requirements are Unknown
interest among software engineer as the work gets to complete
on time. This model as a procedures in operational form as it The software users usually thinks that they are aware
specifies. of all the requirement needed in the overall software
process date, they discover such requirements does not
(i) Who will perform the task fulfil their needs. Thus, a automatic manual process is
(ii) When to perform the task encountered either by installing prototype system or by
decomposing the system into multiple increments known
(iii) How to perform the task as phases.
(iv) What task should be done. These increments are then evaluated and enhanced.
W-process models is designed to describe results, (ii) Unstable Requirements
measures and key checkpoints.
Unstable requirements are requirements wherein change
Q41. List the critical software process issues. in hardware may effect the software requirement. That
is if the hardware requirements gets changed during
Answer : development process then is could effect the software
Critical Software Process Issues process.
The critical software process issues related to quality, (iii) Misunderstood Requirements
requirements, product technology, instability and complexity If requirements are stable and known then they are often
are as follows, misunderstood by the implementers. This could effect
1. Quality the interface prototype, user documentation and test.
4. Complexity
Software quality is considered as a major issue of
software process gets effected when huge amount of errors are It is easy to develop a complex system using application
encountered within a software process. However, if there are programming on a stable environment. However, for example,
multiple errors with in a process then to correct and change the such developments are very challenging to develop a operating
process following is required, system, the developer must have complete knowledge about
basic control program, computer, data management system,
(i) Design inspection
computer architecture etc which is a complex task.
(ii) Code inspection Q42. What are the roles of software engineering
(iii) Development of quality plans and measurement process group.
(iv) Improve testing Answer :
(v) Software quality assurance. Software Engineering Process Group (SEPG)
2. Product Technology Software engineering process group is a software

organization that focuses on improving the software process.
A software process is basically developed based on new Here, individuals focus on performing assessment on
technologies that are usually unclear. The management team organizational capability, developing an assessment plan,
are unaware of the algorithm implementation performance implementing it, measuring the effectiveness of project. The
goals, configurations etc. Hence to learn such technologies is tasks of SEPG are as follows,
a time-consuming and disruptive process. However, once the
1. Initiating process change and sustaining it.
software team gets familiar with the underlying technology they
can develops the product in an orderly and effective way. 2. Providing normal operation.
SEPG is also responsible for producing various other 2. The type of data gathering depends on model/hypothesis
factors like technology support, estimating cost, specifying of the examined process.
standards and performing SQA. In large software organizations,
3. Data gathering affects the data gathered from entire orga-
provides guidance for establishing many software functions. As
nization.
software process are sustainable to change, excessive amount
of change can make the process disruptive. Software process 4. Data gathering provides management support.
can be considered as a continuous learning process. This is
because, it includes new learning methods based on changing Objectives of Data Gathering
nature of the software as well as the problem scaled. As many Data gathering ensures efficiency of software process.
of the software projects are developed without any experiences The basic objectives of software process are as follows,
and technique, it can be said that a newly developed software
process can act as a framework for developing the future 1. Understanding
software processes. Data gathering is done to learn or understand specific
Process change is also done inorder to ensure that existing item/process. This is considered as a part of research and
software is developed based on current knowledge. However, development.
most software issues occur due to inefficiency in understanding 2. Evaluation
methods, inability to handle huge process and product
details rather than lack of software knowledge. Moreover, by Data gathering is done inorder to study a product or activity
developing a software discipline for each the software task an of a product based on acceptance criteria of the product.
efficient software can be improved and corrected. Since process
3. Control
change is an continuous task of software management, here the
key role of SEPG is to effective implementation of such changes. Data gathering ensures control of any particular activity.
Besides this, it also specifies that changes are not disruptive and
4. Prediction
are done based on the available technology and resources. Here,
resources must be made available on permanent basis. SPEG Data gathering is done to develop rate/trend indicator.
must also act as an integrated constrain to adapt new changes
and also to support the methods, standards and technologies of Besides this, data is gathered to measure the software
new projects. This enables a software organization to acquire process successfully. That is, measuring the conceptual model
new software practices and also to facilitate their retention. based on the key events, process and relationships.
Thus, the continuing role of SPEG is categorized as Q44. Give an overview of data gathering problems.
follows, Answer :
1. Developing process standards
The various data gathering problems are discussed below,
2. Maintaining process database
1. Inaccurate data
3. Performing technological insertions
2. Delay in data
4. Enabling process education
3. Improper measuring of data or data not indexed
5. Supporting project consultation
properly
6. Preparing periodic assessment
4. Huge amount of data is needed
7. Preparing status report.
5. Unavailability of required data.
1.4 The Managed Process
1. Inaccurate Data
Q43. What is data gathering and analysis? List the
principles and objectives of data gathering. Raw data become inaccurate or incorrect if it is not
properly entered or maintained with in a database. To avoid data
Answer : Model Paper-I, Q3(b) inaccuracy, a systematic procedure must be introduced inorder to
Data Gathering and Analysis ensure accuracy. One of the another reason for data inaccuracy
is due to careless generation of data. To avoid this, data must be
Data gathering is a process of gathering and analyzing
carefully monitored and gathered.
software data so as to improve the software engineering activity.
That is, data gathering ensure effectiveness of software process. 2. Delay in Data
Principles of Data Gathering The another problem for data gathering is delay in data.
Data gathering principles are as follows, This typical cause for this problem is if methods to gather the
data is incorrect or not rapid. The solution that must be taken to
1. Data gathering is done based on desired objectives and avoid this problem is system modification must be done inorder
plans. to generate the data.
3. Improper Measuring of Data (or) Data not Indexed 7. Quality measure must act as an indicator to measure the
Properly overall performance of the software process.
Improper measuring or dat indexing problem occur if In the above software quality principles, quality plan
raw data gathering is done inconsistently with the purpose of gets created at the start of project plan cycle. This plan is
later analysis. The possible solution to avoid such problem is to documented, reviewed, tracked and compared before the
establish a system that ensure proper rescaling or integrating of actual quality program begins. This leads to the following
improper data. three situations.
4. Huge Amount of Data is Needed (i) The actual or optimum result is tracked based on
plan if it meets the desired management goals.
The cause of such problems is due to,
(ii) The optimum results will be worst than quality plan.
(i) Huge or large amount of data is required inorder to cal-
culate the coefficients occurring in detailed model. (iii) The obtained result will be better than quality plan.
Q46. Discuss in detail about estimating software
(ii) Since there are multiple coefficients the development
quality and software quality models.
model cannot be maintained and developed.
Answer :
The possible solutions to be above problems are,
Estimating Software Quality
(i) Create an efficient procedure to extract the data and inte-
grate it. Software quality estimation is done based on previous
records. As each and every product is different from one another,
(ii) Create a simple model that is highly aggregated. quality estimator needs sufficient knowledge about the product
5. Unavailability of Required Data which includes the following,
(i) The rate of customer installation.
The typical cause of data unavailability is,
(ii) The track of new releases which solve the bugs in older
(i) The required data is not properly maintained or retained.
versions.
(ii) The required data does not or never exist. (iii) The distribution plan i.e., the time period within which
The possible solutions to avoid such problems are, the product reaches the real customer.
(i) Store the data for future use. (iv) The feedback and service system to acknowledge the
defects.
(ii) Reevaluate the data generated.
The steps involved in making a software quality estimate
Q45. Give a note on software quality principles. are,
Answer : (i) Firstly, a review of the recent programs developed or
implemented by organization is performed. This review
The various software quality principles are listed below,
reveals the programs matching with the product under
1. Explicit numerical quality goals or measures must be development.
established by senior management inorder to ensure the
(ii) The data associated with the quality of matching product
software quality.
is analyzed to obtain a quality estimate.
2. Software quality should be measured based on the speci- (iii) A note of differences between the product and process is
fied quality measure irrespective of human judgement. obtained.
3. Define and document the software quality measures so that (iv) A projection of expected quality for new product is evalu-
it can be easy to write the computer program by gathering ated with respect to the goals and required improvements
and processing it. based on previous records.
4. Design a quality plan for each project. A quality plan (v) Based on the generated quality profile the areas that need
must include numerical target commitments, updates of improvement are identified and a development plan is
commits on each significant project change and milestone. produced.
5. Review of quality plan to verify whether the desired Software Quality Models
management quality goals are met or not. If management Software quality model is required for obtaining accurate
quality goals are not precisely defined with in the quality quality estimation. Such a model should be capable of determin-
plan then replanning or exception approval is done. ing the basic assumptions where, the mathematical models fail
6. Track the quality performance of quality plan and publicize because of constrained assumptions. The assumptions obtained
it. If the quality plan fails to meet the overall performance are helpful in dealing the problems mathematically but the as-
then accurate actions must be taken to ensure quality sumptions can involve certain issues include failure rate, testing,
performance. repairing, number of failures and debugging issues.
The characteristics that keep track on software engineering The defects found in development phase can be minimized
process are, by analyzing the data and performing time-to-time inspections.
(i) Variations in quality of program carrying modules with The inspections should be done with better test cases during
huge error count. testing. The ignorance of developers in property reporting data
and the mistakes from supply-chain management during defect
(ii) Elimination of errors from the rest of the modules having corrections also leads to defects.
lesser defects.
When the errors are life-threatening, each and every mem-
(iii) Monitoring changes in the program as they can lead to ber of the team is responsible for the error. So, team members
defects. are trained properly before assigning the project. The other teams
The design and implementation characteristics are also like audit team keeps on monitoring the project. During this, even
included in differentiating the components and modules of new minute errors are reported to senior management to prevent the
product to previous data. Based on the quality profiles review, consequences and respective actions are taken to solve the issue.
decision on choosing the elements and efficiency rates of the Software Defect Prevention Principles
products the software quality can be estimated.
Following are the principles of software defect prevention,
Q47. List the critical elements of software quality
management. (i) Self evaluation of errors should be done by programmers
Answer : (ii) Continuous feedback should be obtained from users.
The following are the critical elements that play a major (iii) Problems should be eliminated in a step by step manner
role in software quality management system with respect to as it is a time consuming process.
tracking and controlling, (iv) Improvements in the process should be considered as a
1. In development and maintenance phase, the quality per- crucial part and the understanding/study of process im-
formance is monitored and reported to authority which is provement must be done steadily.
responsible for generating data associated with quality. The steps involved in software defects prevention are as
2. Resources are gathered according to the reports. follows,
3. The product and performance data is evaluated time- 1. Defect Reporting
to-time by responsible line management. Based on the In this step, large amount of information associated with
results, a new plan is developed for resolving issues. the defect is obtained. This information is usually reported by a
4. The prepared plan is then forwarded to senior management different person but the defects will be fixed by other person. This
for reviewing purpose. can lead to confusions if detailed information is not available. for
The quality plan is prepared for improving the perfor- this reason, a detailed report should be prepared regarding each
mance and fulfilling the targets effectively. defect.
2. Cause Analysis
1.5 The Optimizing Process
In this step, cause analysis (root cause of common defects)
Q48. Write about Defect Prevention. Discuss the is conducted during and after completion of design, test and
principles of software defect prevention. development phases. It is sometimes conducted after the release
Answer : Model Paper-II, Q3(b) of product. The cause analysis is conducted to identify causes
Defect Prevention of all defects captured along with the ways in which they can
be prevented. Cause analysis meetings are held in a way similar
The success of software engineering process depends on to inspections, which include meeting time, preparation time,
defect prevention which requires certain techniques derived from recommended actions count and defects. Programmers need to
the past experience involving the following logics, intimate the team members about the points discussed and the
1. Huge and complex programs are required to satisfy the leader notes the reported defects. The final action is reported to
user requirements which might effect the society. action team.
2. As humans make mistakes, the designed programs will 3. Action Plan Development and Implementation
have a lot of bugs. In this step, scrutinization of effects and related actions
For these reasons defect prevention is the required which is done. These actions are taken by the action team which
is cost efficient if done earlier. It is always crucial to the software includes manager, education manager, QA team, configuration
process because of its cost effectiveness. It is been observed that management and specialists. The key responsibilities of action
cost of fixing the defects is double the cost of software develop- team include assigning priorities to action items based on
ment. Generally, mis-understanding and ignorance of interface historical data, preparing an implementation plan, assigning
requirements increases the number of defects. However, such responsibilities, monitoring the progress and reporting. The main
defects can be minimized by using crucial prototyping and design contributors of actions are identified for their efforts to boost the
review program. spirit.
The action team meetings are conducted to review the actions suggested,track the implementation progress of cause analysis
and refer higher-level teams based on action items time period. Following-up reports and tracking the progress of process helps in
prevention of additional defects. Moreover, prevention feedback is also obtained the kick-off meeting conducted during the initial
stages provided a good platform for identifying possible issues and solutions. This meeting includes setting up goals for each phase,
solutions for key or input issues and error prevention strategies.
Q49. Why is it important to build trust in software contract? What is the role of auditing in software contracting?
Answer :
Importance of Building Trust in Software Contract
Trust is considered as an important factor of effective software contract. Building trust is difficult and time consuming because
it is based on the historical perspective, mutual understanding and awareness among the individuals (vendors, buyers, managers and
team members). Organizations feel insecure to trust an individual as the projects get deviated even with minor mistakes.
Lack of trust among buyers and vendors can incur huge losses. As a result, buyers demand and pose different questions,
firm commitment, time-to-time reporting, documentation and agenda. Trust is crucial in a successful contract but the individuals/
management should keep a track on work progress and performance. This is because anyone from the organization can cheat with
the plan at anytime.
Role of Auditing in Software Contracting
Auditing is useful to track performance of the team. It is done to confirm whether the work being done according to the plan
or not. It is safe to trust team members until the auditors are strict and maintain transparency.
The factors that effect the performance of team and require auditing include strict deadlines, environmental changes and
others.
Q50. List the principles of software contract management and discuss the possible cases of buyer and vendor
competence.
Answer :
Principles of Software Contract Management
The principles of software contract management are,
1. Firstly, the general goals and objectives associated different aspects of the system are noted.
2. The known functional requirements are noted excluding the requirements which are explained clearly without complete
knowledge to avoid issues.
3. The document of requirements (generated from previous step) is checked to validate the objectives and a plan is produced.
4. The design phase is started with the defined requirements.
5. The objectives are re-checked stated clearly to drive the process in the right path.
6. The performance of contract is judged based on development and process indicators.
7. Finally, the implementation, tracking, auditing and quality assurance of project are done.
Four Possible Cases of Buyer, Vendor Competence
The four possible cases of buyer, vendor competence are as follows,
1. Technically, Both Buyer and Vendor are Competent
In this case, a supportive relationship can be built where both buyer and vendor can focus on duties of defining needs and
implementing those needs respectively.
2. Technically, only Vendor is Competent
In this case, the incompetent buyers trust blindly on vendors as they focus on their own requirements. However, the vendor
only provide support to define the requirements of buyers before starting the design process.
3. Technically Only Buyer is Competent
In this case, vendor is replaced immediately or buyer should approach the management for reporting.
4. Technically, Neither Buyer nor Vendor is Competent
In this case, the only solution is to replace vendor or get assistance from professionals.
Q51. Write short notes on technical and quantitative process tracking.
Answer :
Technical Reviews
Technical reviews measures the effectiveness of work done. Planning of reviews is done to check if the followed process
matches the requirements and operational criteria. Moreover, high-level designs are also reviewed properly. Examples of technical
reviews include inspections and audit reviews.
Quantitative Process Tracking
The quantitative process tracking is done by dividing the whole project into number of small phases. For better tracking within
each phase, the following measures are used.
1. Code Size
The LOC measure can be used to obtain the weight of individual modules. These weights can be combined to obtain the
overall weight.
2. Planned Resources and Schedule
The time period (months) assigned to a programmer for completing task is used as a measure to represent the fraction of work.
3. Number of Modules and Tests Completed
LOC can be used for measuring number of modules as they possess different sizes and are based on the way of testing.
4. Number of Defects Found
As the defects cannot be evaluated till the end, this measure is not preferable.
Q52. Explain in brief about process certification.
Answer :
Process certification makes the software process to go through different stages of maturity. As the maturity level increases,
the development organization can be trusted accordingly. The managing of different levels of maturity is as follows,
1. Managing the Low Maturity (Level 1) Process
At this stage, senior management is involved to check the planning, approval, cost estimation, resources and tracking. Here,
SCM is used to control the process of operations and its completion. SQA teams are also used for reviewing. Finally rate
charts are used to track the plan.
2. Managing the Level 2 Maturity Process
At this stage, the management process encourages the organization to upgrade its maturity level. In addition to the steps
followed at level-1, SQA reviews should be done to manage the workload. And, SCM teams are used for development. The
standards of code, design and testing are set up with proper inspections. Finally, SEPG team monitors the work.
3. Managing the Level 3 and above Maturity Process
At this stage, the management will be working in an effective way but requires a program that measures and analyzes the
data to track the quality, defects and support.
1.6 Process Reference Models – Capability Maturity Model (CMM), CMMI,

PCMM, PSP,TSP
Q53. What is CMM? Explain about Capability Maturity Model Integration (CMMI).
OR
Explain the Capability Maturity Models in detail.
Answer : Oct./Nov.-20(R16), Q1
Capability Maturity Model (CMM)

Capability Maturity Model (CMM) is a maturity framework strategy that focuses on continuously improving the management
and development of the organizational workforce. CMM provides the organization with the basic requirements for building
the software process. It provides an evolutionary path from an inconsistent organizational practices, to a highly disciplined
developmental practice. This helps to improve the knowledge, skills and development of the software process.
Capability Maturity Model Integration (CMMI)

The software development organizations can be ranked depending on the quality of products they develop using a meta-
model. This meta data is governed by certain set of systems and software engineering capabilities. These are needed to be satisfied
by the organizations, as they attain various levels of capability as well as maturity. Hence, to remain on this track, each organization
is required to develop a process model, based the guidelines of capability maturity model integration, The model is given below,
4
Capability level
0 Project Requirements Measurements Configuration Process and

planning management and analysis management product QA
Process Area
Figure: Graph Depicting the Process Area Capability Scenario
The above figure is also referred as a continuous model. Here, the process area is plotted against the standard levels, ranging
from 1 to 5. However level ‘0’ is also considered to represent the lowest of all. Each level and their equivalent values is expressed
below. As a customer, it is preferable that an organization belongs to CMMI level 5 which indicates that it is successful in terms
of providing services and satisfying customers.
Level 0 : Incomplete
At this level, there are two possibilities.
(i) The process area (along x-axis) is not performed.
(ii) The process area has not achieved the targets set by CMMI for level 1’s capability.
Level 1 : Performed
(i) The tasks specified by the CMMI at process level have been achieved.
(ii) The work tasks required in developing a given work product are set.
Level 2 : Managed
(i) All the criteria defined at CMMI level 1 are met.
(ii) The work related to the process area is up-to-date with the expectations of organization.
(iii) The developers involved in the production have access to all the available resources for completing their tasks.
(iv) All the specimens are subjected to the process of project development whenever necessary.
(v) The tasks as well as products (under development) are regularly being monitored, controlled and reviewed.
(vi) The product is executed to ascertain that, it is functioning as per the expectation.
Level 3 : Defined
Entire conditions of level 2 are met. Apart from this, the process is customized according to the organization’s set of
standard processes based on the guidelines of the organization. This helps the process assets in terms of work products, measures
and other process improvement information.
Level 4 : Quantitatively Managed

Entire consequences of level 3 are met. Also, by means of a quantitative assessment the process area is improved and
controlled. Moreover, the establishment of the quantitative objectives for quality and process performance is also done and used
as a criteria in process management.
Level 5 : Optimized
All level 4, targets are met. Moreover, optimization process area is performed using quantitative means to satisfy the varying
customer requirements. It also to improves the ability of producing desired results for of the process area under consideration.
Here, there are two important facts to be considered. They are,
(a) Specific goals
(b) Specific practices.
(a) Specific Goals
Specific goals refer to the essential characteristics which must exist in all the activities implied by a given process area.
(b) Specific Practices
Specific practices refer to a set of tasks to be accomplished in order to achieve specific goals.
These two terms are important because CMMI expresses the process area using these terms i.e., specific goals and specific
practices. Also there are five generic goals and their equivalent practices associated with these goals. Basically, these generic
goals correspond to one of the five CMMI levels. Hence, any organization claiming one of the levels of CMMI should satisfy
these generic goals.
Q54. Write a note on People CMM (PCMM).
Answer :
People CMM (PCMM)
People Capability Maturity Models is a maturity framework that focuses on continuously improving the management and
development of the organizational workforce. It provides an evolutionary path from inconsistent organizational practices, to a
highly developed, disciplined developmental practices that aim at continuously developing the knowledge, skills and motivation
of the workforce. In other words, it provides a road map for changing the current organisational practices to a matured state, that
aim at strategic business performance by continually improving the workforce developmental activities.
People CMM was first published in 1995, and has been used by many companies such as IBM, TCS, Ericsson etc. It provides
an integrated system of workforce practices that mature/develops through a transformation in organisational practices, objectives
and culture as per the changing trends. It consists of five maturity levels that five rise to organizational workforce practices and
processes. After each maturity level, a new set of practices are added to those implemented previously.
People CMM is a process-based model and is being developed from workforce practices and process improvement techniques
that were effective in other organizations. It is a maturity framework for implementing workforce practices that continually improve
the workforce capabilities.
Q55. Explain about Personal Software Process (PSP) and Team Software Process (TSP).
Personal Software Process (PSP)

Every team member possesses his own personal software process. If this personal process remains ineffective, then he/she is
advised to go through the four phases of software development, each time being trained thoroughly. This ensures that he remain in
a position to analyze the project development, at the same time focusing the quality of it. But, this session does not end here. Rather,
PSP makes an individual involved in the project planning and also in maintaining the quality of all the software products. In order
to achieve this, PSP adheres to the following five major framework activities,
(a) Planning
In this activity, the user initially focuses on the requirements of the project. Later, the vision is extended on the defect
estimates. Finally, by estimating the development task and documenting them, this session is concluded.
(b) High Level Design
In this case, user usually addresses the scenario of entire project by developing certain high level designs. If uncertainty
prevails in such diagrams, prototypes are considered. By documenting the whole scenario, current session is concluded.
(c) High Level Design Review
When the designing process completes, the design is to be reviewed, in order to isolate the errors. In this case, several
designing reviewing methods are considered.
(d) Development
This is same as coding phase. The code for each component of the software is developed. Later these components are carefully
integrated. Finally suitable testing methods are implemented to thoroughly test the resultant product.
(e) Postmortem
This is the final step in the entire PSP. In this case, by using several methods, the effectiveness of current process is claimed.
If it is not up-to-date, then several modifications to the current process is made.
Finally, the PSP looks forward for the software engineers to trap the errors in the software process early. They continuously
access the process and implement many process refining steps.
Team Software Process (TSP)
Team Software Process aims in developing self directed project team, which is motivated in organizing effective software
process. At the same time it produces software which are of high quality. Following are certain preliminary guidelines, offered
by TSP for any software engineering team.
v Form a team with self motivated members capable of analyzing their work, setting up their targets and scheduling the
processes. Hence, such teams can be called as integrated product teams, accounting for maximum of 3–20 engineers as
team members.
v Developing strong leadership skills in the project leaders or managers. This makes them capable of bursting and enriching
enthusiasm among team members to attain high degree of performance.
v Take the team on the track of achieving CMM-5 targets.
v Address guidance of improving current process standards of high maturity organizations.
v Bestow industrial grade skills among the technological students, earning their university degrees.
Hence, any team claiming to be self directed will possess the following virtues.
v Clear idea of targets to be achieved.
v Each team member remains self acquainted with his responsibilities in delivering his role.
v Always maintain the entire project information up-to-date.
v Acquiring new team processes which remain adequate for team as a whole as well as gaining mechanisms to implement
them.
v Maintaining a record of probable risks and defining remedies for curing them.
v Maintaining a record, which provides information on the entire project status.
Important activities required to be performed by a given team (addressed by ISP) are as follows,
v Launch
v High level design
v Implementation
v Integration
v Test
v Postmortem respectively.
Hence, while traversing through the above mentioned activities, a given team can successfully resort to systematic
development of the project. At the same time, it remains curious about maintaining high quality standards. ISP also avails several
scripts, standards etc., in continuously guiding the team members in achieving the goals set.
Finally, one can say that, TSP is a standard approach which aims in making current software development process
competent in both productivity as well as quality aspects. Hence, it is always fruitful in perfectly implementing the TSP issues.
Q56. Discuss about software process assessment. And also discuss about CMM.
Answer : Dec.-19(R16), Q3
Software Process Assessment

Application of process patterns to the software project under development does not ensure that the software is going to
satisfy all the essentials (i.e., on-time delivery, customer satisfaction, high quality values etc.) Hence, in order to achieve this, the
software patterns should be collaborated with highly valued software engineering practices. Moreover, the entire process should
be sufficiently assessed as required. Following figure depicts the software process and methods that are useful during process
assessment and improvement.
Figure: Software Process and Methods Applied for Assessment and Improvement
Following are the techniques for software process assessment.
(a) Standard CMMI Assessment Method for Process Improvement (SCAMPI)
Five important steps which form the basis for software process assessment are as follows,
1. Initiating
2. Diagnosing
3. Establishing
4. Acting and
5. Learning.
In this case, SCAMPI usually relies on SEI CMMI for the requirement of software process assessment.
(b) CMM-based Appraisal for Internal Process Improvement (CBA IPI)
In this technique, usually the granularity or maturity of the product organization is assessed using the SEI CMMI.
(c) Spice (ISO/1EC15504)
This standard remains effective in deriving software process assessment techniques.
(d) ISO 9001 : 2000
Any software industry, can adopt the ISO 9001 : 2000 standard to reach quality peaks in terms of its products (being
manufactured), systems as well as services delivered by it.
ISO 9001 : 2000 specifies the quality management requirements for a given organization seeking an overall development
along with the customer’s satisfaction.
To assess the quality of management ISO 9001 : 2000 has derived a special cycle referred to as, “plan-do-check-act”. In
this phrase, each term has got its own significance i.e.,
Plan – Includes the targets, associated activities, objectives with an aim to produce high quality software with complete
customer’s satisfaction.
Do – Refers to the implementation of entire software development process.
Check – Refers to the process of monitoring and assessing the software process. This assures that all mechanisms related to
software quality management are thoroughly implemented to improve the software development process.
Act – Refers to the implementation of ideas of improving the current software development process.
CMM
For answer refer Unit-I, Q53, Topic: Capability Maturity Model (CMM).
Important Questions
Short Questions
1. Define software process and software process model. Refer Q1
2. What are the key risks and actions of a software process? Refer Q3
3. List the objectives of data gathering. Refer Q7
4. How development of software requirements is done? Refer Q9
5. What are the different situations of software requirements development in terms of skills and experience of participants? Refer Q11
ESSAY Questions
6. Define software process and software process models. Discuss in brief about software process improvement. Refer Q12
7. What is the need for process optimization? Discuss the people involved in optimizing process. Refer Q14
8. Describe the principles of software process change and TSP. Refer Q15
9. What is software process assessment? Discuss the five assessment principles. Refer Q18
10. What are the tasks involved in initial process? Refer Q22
11. Write short notes on commitment discipline. Refer Q24
12. List the reasons, benefits and examples of software standards. Refer Q33
13. What is data gathering and analysis? List the principles and objectives of data gathering. Refer Q43
14. What is CMM? Explain about Capability Maturity Model Integration (CCMI). Refer Q53
Unit-2 Software Project Management Renaissance, Life-cycle Phases and Process Artifacts 2.1
Unit Software Project Management
2
Renaissance, Life-cycle Phases and
Process Artifacts SI
A GROUP
Syllabus
Software Project Management Renaissance: Conventional Software Management, Evolution of Software Economics,
Improving Software Economics, The Old Way and the New Way.
Life-Cycle Phases and Process Artifacts: Engineering and Production Stages, Inception Phase, Elaboration Phase,
Construction Phase, Transition Phase, Artifact Sets, Management Artifacts, Engineering Artifacts and Pragmatic Artifacts,
Model-Based Software Architectures.
Learning Objectives
 Conventional Software Management

 Evolution of Software Economics
 Pragmatic Cost Estimation
 Ways of Improving Software Economics and Reducing Product Size
 Principles of Conventional Software Engineering and Modern Software Management
 Various Engineering and Production Phases
 Various Types of Artifact Sets
 Software Architecture Perspectives
Introduction
Software industry is getting advanced day by day due to advancements in technologies. The conventional
software project teams follow waterfall model. The software engineering has been evolving over the
years while solving the problems and simplifying the complexities. Managers usually focus on the quality
improvements without increasing the size and cost of the software. The other important factors of software
projects include team effectiveness, automation and achieving required quality.
Project Life cycle can be categorized into two phases i.e., Engineering phase and Production phase. These
phases can be further divided into inception phase, elaboration phase, production phase, construction phase
and transition phase. Various artifact sets are used to make the software development manageable. These
include, management set, requirement set, design set, implementation set and deployment set.
Q1. What is meant by late risk resolution? (Model Paper-I, Q1(c) | Nov./Dec.-17(R13), Q1(a))
OR
What is late risk resolution?
Answer : March-17(R13), Q1(a)
Late risk resolution is an issue faced by waterfall life cycle model. That is the inability to resolve the risks at easier stages.
This inability exists because, it initially concentrates on paper artifacts where in the actual implementation, design and integration
risks are not clear.
Projects that are developed using the conventional waterfall model are usually associated with four different risk exposure
periods. They are,
1. Risk exploration period
2. Risk elaboration period
3. Focussed risk resolution period
4. Controlled risk management period.
Q2. Explain about requirements driven functional decomposition.
Answer : Nov./Dec.-17(R13), Q1(b)
The software development process is said to be requirements-driven because all the requirements associated with
the project are defined as the first step followed by their implementation. Later on, other activities are performed in the
software development process. It immaturely treats all the requirements equally irrespective of their type and criticality
which makes it difficult because the concept of equally treating the requirements depletes and takes significant engineering
hours specially in capturing traceability, testability, logistics support etc. The basic assumption of the waterfall process is
that, requirements are specified in a functional manner, according to which the requirements are allocated by dividing the
project into various functions.
Q3. Write about software economics and late design breakage.
OR
What is meant by software economics? Dec.-19(R16), Q1(c)
(Refer Only Topic: Software Economics)

OR
Define late design breakage.
(Refer Only Topic: Late Design Breakage)
Answer : Nov./Dec.-16(R13), Q1(a)
Software Economics
Software economics examines the entire idea of software development and uses software cost models to estimate software costs.
The three different generations of software economics are as follows,
1. Conventional
2. Transition
3. Modern practices.
Late Design Breakage
The protracted integration and late design breakage in software development process occurs in unsuccessful projects. A
software project is said to be unsuccessful if it is incomplete, defying and not upto specifications, though it can be compiled and
executed. When the integration and testing activity lasts longer than expected, then it is called protracted integration and testing.
When this is occurred in a project, then the ‘development program Vs time’ graph will show an uneven path during the integration
phase, this is referred to as ‘late design breakage’.
Q4. What are the major components of software Q7. What are five staffing principles?
cost? Why? March-17(R13), Q1(j) Answer : Nov./Dec.-16(R13), Q1(d)
OR Staffing Principles
What are the parameters of cost models? Boehm proposed the following staffing principles for
Answer : (Model Paper-II, Q1(c) | Nov./Dec.-16(R13), Q1(b)) building an effective team,
The five components or parameters of a software cost 1. Top Talent Principle
models are as follows, The principle of top talent states that “Instead of
appointing less skilled and greater number of people, appoint
(i) Size of the End Product
only better and fewer people for the software project”.
(ii) Process Involved in Producing the End Product
2. Job Matching Principle
(iii) Software Engineering Personnel According to the principle of job matching, the tasks are
(iv) Environment assigned to the available individuals based on their skills and
(v) The Required Quality. motivations.
Q5. What are various cost estimation models? 3. Carrier Progression Principle
The principle of carrier progression states that, an
Answer : March-17(R13), Q1(b)
organization can work effectively for a long run by cooperating
The various cost estimation models are as follows, and helping its people to self-actualize.
1. Empirical Estimation Techniques 4. Team Balancing Principle
In these techniques, project parameters are identified According to the principle of team balancing, the
based on the earlier work done on the similar type of projects individuals who can coordinate and complement with one
and experience. another must only be selected.
These techniques generally depends on common sense 5. Phaseout Principle
and accordingly various activities have been formalized which According to the principle of phase out, a misfit on a
can be helpful in estimation team will not be beneficial in any way.
2. Heuristic Techniques Q8. What are the top five principles of a modern
In these techniques, it is considered that relationships process?
can be modelled in the project parameters with the help Answer : (Model Paper-III, Q1(c) | March-17(R13), Q1(d))
of mathematical expressions. As soon as the independent 1. The process should not commit the resources to full-
parameters are determined, all the dependent parameters can scale development till the life cycle plans the driving
be easily found by substituting the values in the independent requirements and the architecturally significant design
parameters (basic parameters) mathematical expression. decisions are adequately balanced. This approach is
called “architecture-first” approach and all processes
3. Analytical Estimation Techniques
must be based on this approach.
These techniques retrieves the output by considering the
2. The process should be an iterative one in order to encounter
basic about project. It makes use of Halstead’s software science and manage risks at an early stage. This is because
in order to attain results by considering basic assumptions. It modern systems fail to perform the following tasks,
is mainly used for estimating software maintenance efforts.
(i) To give the complete problem definition
It performs in a much better manner to predict software
maintenance efforts when compared to empirical and Heuristic (ii) To design the full-fledged solution
techniques. (iii) To create the software
Q6. Discuss the advantages of commercial (iv) Finally to test the resultant product.
components. Now-a-days all software systems are complex and
Answer : (Model Paper-III, Q1(d) | Nov./Dec.-17(R13), Q1(c))
sophisticated. Thus, an iterative approach must be used
to perform all the required activities in the life-cycle
The advantages of commercial components are as follows, whenever it is necessary to do so. By this, the objectives
1. It is possible to predict the license costs associated with of all stakeholders are balanced and the amount of scrap
these commercial components. and rework gets reduced.
2. The mature technology available is primarily used. 3. The amount of custom development and human-generated
source code can be minimized if the component-based
3. They are not dependent on hardware and software which
development approach is followed. In this approach a
enhances the quality of the product.
collection of already existing lines of code either in an
4. The software developed through this approach is perform executable or source format and a well-defined interface
its functionality efficiently. and behavior (called a component) are used.
4. Highly controlled baselines are required when the iterative development involves shared artifacts used by different team
members who are working concurrently. Thus, establishing an environment that supports change management.
5. Tools that support round-trip engineering must be used to encourage free flow modifications. Engineering information
in various formats can be synchronized and automated with the help of round-trip engineering. However, it is necessary
to automate documentation, change management and testing in order to minimize the iteration cycles. For establishing an
integrated environment and supporting an iterative process, change freedom is important.
Q9. What are the phases of the life-cycle process? Explain. (Model Paper-I, Q1(d) | Nov./Dec.-17(R13), Q1(e))
OR
Define transition phase. March-17(R13), Q1(e)
(Refer Only Topic: Transition Phase)

OR
Write brief notes on construction phase. Nov./Dec.-17(R13), Q1(f)
(Refer Only Topic: Construction Phase)

OR
Define elaboration phase.
(Refer Only Topic: Elaboration Phase)
Answer : Nov./Dec.-16(R13), Q1(e)
The phases of life-cycle process are Inception, Elaboration, Construction and Transition.
Inception Phase
Inception phase is used,
(i) To demonstrate the scope of the software and boundary conditions along with the acceptance criteria, operational
concept and the details of things to be included and excluded while developing the software product.
(ii) To determine the cost and schedule for the entire project.
(iii) To evaluate potential risks.
(iv) To verify one or more candidate architecture, dedicated to carryout primary sequence of events (scenarios).
(v) To separate the critical use cases and the primary scenarios of the system’s operation.
Elaboration Phase
Elaboration phase is used,
(i) To create a quick baseline architecture in such a way that all changes can be monitored and maintained.
(ii) To create a baseline vision.
(iii) To describe how the base line architecture can be achieved with the vision created, within the scheduled cost and time.
(iv) To baseline a high-fidelity plan to be used in the construction phase.
Construction Phase
This is usually the coding phase of the software, where each component of the software is coded and is suitably integrated.
Once the coding part is completed, the entire software is thoroughly tested. Hence, the two most important activities performed
during this phase are, Coding and Testing.
The main objectives of construction phase is,
(i) To reduce the cost incurred in the development phase usually by making optimum use of the available resources and
by avoiding the unnecessary rework.
(ii) To quickly obtain the desired quality.
(iii) To quickly obtain the useful versions such as alpha, beta tests etc.
Transition Phase
Transition phase belongs to the production stage of software engineering. Its primary objectives are,
(i) To obtain self-supportability for the user.
(ii) To attain stakeholder concurrence in such a way that, the deployment baselines be complete and consistent with the
vision evaluation criteria.
(iii) To attain fast and cost-effective baselines for the final product.
Q10. Write the typical release description outline.
Answer : March-17(R13), Q1(f)
The results of every release along with performance against the evaluation criteria (that exists in their release specifications)
are explained by the release description documents. Release baselines must be available along with release description document
which defines the evaluation criteria for a specific configuration baseline. It also provides substantiation which specifies that the
evaluation criteria is dealt in an acceptable manner.
The document must contain a metric summary which provides a detail description about its quality measurement. The
quality is measured in relative and absolute terms. The post-mortem review results are documented, which contains the following
outstanding issues: follow-up actions, recommendations for process and product improvement, and trade-offs in addressing
evaluation criteria. Figure below represents the release description outline,
Context
1. Release baseline content
2. Release metrics
Release Notes
1. Release-specific constraints or limitations
Assessment Results
1. Substantiation of passed evaluation criteria
2. Follow-up plans for failed evaluation criteria
3. Recommendations for next release
Outstanding Issues
1. Action items
2. Post-mortem summary of lessons learned
Figure: Release Description

Q11. Write a short notes on artifact set and configurable process.
OR
Define the term artifact set. Dec.-19(R16), Q1(d)
(Refer Only Topic: Artifact Set)

OR
What is configurable process?
(Refer Only Topic: Configuration Process)
Answer : (Model Paper-II, Q1(d) | Nov./Dec.-16(R13), Q1(c))
Artifact Set
The software development can be made manageable by organizing unique sets of information into artifact sets. These sets
consists of the corresponding artifacts which are persistent and are in a standard representation format. Basically, an “artifact”
is a collection of cohesive information which is gathered and examined as a single entity. On the other hand, the representation
for the entire aspect of a system is known as “set”. Some artifacts and sets may not be essential in an organization, project or a
system. Generally, every set must contain some information for satisfying the needs of all stakeholders.
Configurable Set
An economically scalable, configurable process must be established, as each software development needs a specific
process. With such a scalable process, common components and architectural patterns, extensive process automation and common
process spirit can be easily exploited if the process economy of ROI and scale are assured.
2.1 Software Project Management renaissance

2.1.1 Conventional Software Management
Q12. Discuss in detail the three important analyses done on the state of the software engineering industry.
Answer :
Analyses on the State of Software Engineering Industry
The crucial analyses regarding the state of software engineering industry were carried out in mid 90’s. Though, the analyses
were done from different point of views, the results generated from these analyses were similar and complementary. These analyses
can be summarized in the following manner.
(i) The degree of predicting the software development is very low due to which more than 90% of software projects delivered
fail to fulfill the design goals. There may be several reasons for the failure of software project such as additional cost
consumption, additional time consumption, failing to fulfill the customer requirement.
(ii) Management discipline is not considered as a technological advancement but it is treated as software management factor,
which is a primary discriminator for specifying the success and failure of the project.
(iii) The process is said to be immature if it involves rework and generates large scrap associated with software.
All three analyses resulted in the same general conclusion which states that “the success rate associated with software
project is very low”. The result of these analyses are summarized as,
(a) Patterns of software systems failure and success
(b) Chaos
(c) Report of defence science board task force on acquiring defence software commercially.
(a) Patterns of Software Systems Failure and Success
Jones in 1996 made a presentation regarding the state of software industry by considering the results of many projects,
which were compacted into the following six subindustries.
(i) Systems software
(ii) Information systems
(iii) Commercial software
(iv) Outsource software
(v) Military software
(vi) End-user software.
The following are the main reasons for the failure of projects,
1. When there is no information regarding the historical software measurement.
2. When the project fails to use automated estimating tools, automated planning tools, effective architecture, effective
development methods, design review, code inspection.
3. When the project fails to examine or analyze the progress or milestones.
4. When the project employs informal testing methods.
5. When design as well as specification are done manually.
6. When the project does not properly use the fourth generation languages.
7. When the project does not reuse the certified materials.
8. When the project fails to define the database elements.
The following are the reasons which may lead to a (iii) When the organization comprises of competent, hard-
successful project, working and focused staff members.
1. When the project uses appropriate data associated (iv) When the objectives, requirements are clearly defined.
with software measurement.
(v) When there is a high-level of support from the executive
2. When the project utilizes various estimating tools management.
during the early phases of life cycle.
The report even summarizes the reasons which will lead
3. When the project continuously uses planning tools. to the development of unsuccessful (risky) projects,
4. The probability of success is high if the project (i) When very less number of users are included in the
makes use of formal progress reporting, formal development process.
architecture planning, formal development
methods, formal design reviews, formal code (ii) When the objective, requirements are not clearly defined.
inspections, formal testing methods. (iii) When there is usage of unrealistic time slots.
5. When design as well as specification is done (iv) When the staff members make use of new technology,
automatically. which is not known completely.
6. When the project makes use of appropriate (v) When there is less availability of required resources.
languages.
The chaos report basically solves those problems faced
7. When the project reuse the certified materials. by top-level manager of any cooperate information system by
8. When the project defines a formal database employing a highly process oriented approach. The report states
planning. that,
The social factors that might discriminate successful “The rate of success can be increased by minimizing
project from failure were even identified by Jones. Some of time frames and delivering the software component on or before
these social factors are, the estimated schedule time. Inclusion of this fact may lead
to the development of iterative design process. These frames
1. When the projects are scheduled by considering realistic may develop, test and implement smaller component elements.
expectations. Such iterative design process is referred as “Growing software”,
2. When there is good cooperation with clients. which takes into account the following considerations.
3. When the level of communication among the team (i) Each and every individual component carry an owner or
members is good. a group of owners.
4. When the organization comprises of experienced staff (ii) The expectations are set in a realistic manner.
and technical staff.
The chaos report specifies that, the success and failure
5. When the executives of the project have a good of software project depends on the ways in which requirements
understanding of software development estimates. management take place. This implies that, if an organization
(b) Chaos has complete information regarding the requirements as
well as the way these requirements are used, the chances of
In 1995 Standish group prepared chaos report that laid getting success will be increased. Though it seems easy to
to the following conclusions. develop the project using requirement activities, it should be
(i) In 1995, approximately $81 billion were spent by noted that these activities basically use only 10% of life cycle
US companies on the software projects, which were resources. This means that the remaining 90% of the activities
unsuccessful. must also be accomplished successfully. The idea of making
the problem simpler and consistent can be accomplished by
(ii) 31% of the software projects whose research was considering the perspective of modern iterative process during
completed were cancelled prior to their completion. the development of software projects.
(iii) More than 50% of the organization re-executed almost (c) Report of Defense Science Board Task Force Report
53% of the software projects that were already executed. on Acquiring Defence Software Commercially
(iv) 9% of large-scale projects were delivered successfully In 1994, Defence Science Board prepared DOD report
with estimated budget and time. that described the following facts,
The report summarizes the reasons that will lead to the
1. There was certain incompatibilities between existing
development of a successful project.
department of defence practices and commercial
(i) When more number of users are included in the business practices.
development of project.
2. The usage of business practices was not encouraged by
(ii) When the planning is done in an appropriate way. management methods associated with DOD program.
3. Very few experienced and qualified software professionals were present at different levels of DOD.
4. DOD failed to identify the overall benefits and liabilities associated with commercial components.
5. DOD did not give much importance to the architecture.
6. The promotion of technology transfer with commercial business market was not promoted by DOD program.
The following are few reasons that led to the failure of DOD software projects.
1. The requirements were not defined clearly.
2. The usage software process management factors were inadequate.
3. The subcontractor management was ineffective.
4. The software architecture was given least priority.
5. The interfaces were not clearly defined and were controlled inadequately.
6. More attention was given to innovation but not to the cost and risk factors.
Q13. Explain waterfall model.
Waterfall Model
The waterfall model consists of various phases based on the nature and control flow of development activities. These
phases are executed in a sequential order specified by a process model. Initially in a project development, feasibility analysis
must be conducted, which on its successful completion leads to requirement analysis and project planning phases. After the
completion of requirement analysis, the design step is initiated followed by coding phase. Further, the completion of coding
leads to the initiation of testing and integration activities. Finally, the system is installed and maintained after performing
a thorough testing.
The requirement analysis in the development mode is considered as analysis and planning. Here, planning generally
refers to a good plan wherein all the detailed descriptions about the requirements are clearly illustrated. Subsequently,
there is no need of requirements if a proper plan is included before starting the later phases of development such as design,
coding, testing, etc.
Figure: Waterfall Model
The waterfall model involves a sequential ordering of Advantages of Waterfall Model
activities because the output of a phase acts as an input to the
(i) It is very simple and easy to implement.
next phase, and hence they (input and output) should be clearly
identified. This is basically done using V&V so as to ensure that (ii) It provides better understandability to the users.
the inputs provided and the outputs produced are consistent
Disadvantages of Waterfall Model
throughout the development process. The outputs produced
at requirement and design phases should be in the form of Despite of the widely usage of waterfall model, it has
documents, which are often referred to as work products or the following limitations.
intermediate products and the output at coding phase is referred
(i) The requirements of a project can be known by learning
to as the code. Thus, a software project not only produces a final
the previously executed projects. But, the development
output or program but also produces documents or reports in
of new projects is difficult since the user doesn’t have the
various phases of development process.
knowledge about the requirements. Hence, new projects
Phases in Waterfall Model are seemed to be unreal for development.
The activities that are involved in the development of a (ii) A hardware should be chosen for the previously known
software project are, requirements. Usually, large projects take some years for
(i) Requirement analysis completion and, when the hardware technology changes
(ii) Project planning as per years, the previously selected hardware is of no
use. Thus, a useless hardware is not desirable for the
(iii) System design software systems which are costly.
(iv) Detailed design
(iii) Waterfall model demands the specifications of all
(v) Coding and unit testing requirements to be defined in the first phase of
(vi) System integration and testing. development itself, which is however very difficult to
Documents Generated in the Waterfall Model be specified.
The documents (outputs) that are resulted at the end of (iv) Since, waterfall model produces the work products
each phase of a development activity are, at the end of each phase, it is often referred to as a
document-driven process. This process is usually not
(i) Requirements document
suitable for interactive applications where elaboration of
(ii) Project plan document documents is generally not feasible during development
(iii) System design document and if advanced development tools or fourth -generation
(iv) Detailed design document languages are used, then unnecessary specifications gets
elaborated during development.
(v) Test plan and test reports
Q14. Explain the waterfall model in large-scale sys-
(vi) Final code
tem approach. Discuss five necessary improve-
(vii) Software manuals (such as user, installation, etc.) ments for this.
(viii) Review reports. Answer : (Model Paper-I, Q4(a) | Nov./Dec.-17(R13), Q2))
In the waterfall model, the two basic assumptions that Waterfall Model in Theory
explain the nature of linear ordering of phases are,
Waterfall model is the most widely used model for large
(i) When the development process is employed as per
scale projects, as it gives a brief description of the model being
the specified order, then the result produced will be a
successful product for a particular project. developed. There are three important things in waterfall model.
They are,
(ii) When ordering of the phases is not specified, then
the result produced will be a less successful software 1. Analysing the requirements and coding the software
product. design are the two vital phases in developing software
A successful product can be achieved when all the projects.
objectives i.e., time and constraints are successfully fulfilled.
At the end of each phase, the output must be certified by using
a review technique. Particularly, reviews are essential for both
requirements and design phases in order to reveal the defects (a) Insight (1)
present in a product. The outcome of the reviews are generally
referred to as review reports. Figure
2. In order to develop a successful software project, several overhead steps need to be performed. For example, software
requirements, system requirements, designing and testing.
3. The basic design of the waterfall model is very risky and can sometimes lead to failure of the project. In the testing phase
of waterfall model, input is given to the software and output is tested. Failure in testing phase leads to failure in design.
In order to overcome this problem the requirements must be changed, which results in re-building of whole software.
System requirements
step 1. Programs design comes first
2. Document the design
3. Do the job twice, if possible
Software requirements
step 4. Plan, control and monitor testing
5. Involve the customer
Analysis step
(c) Suggested improvements for the
risks mentioned in insight (3)
Program design
step
Coding step
Testing step
Operations step
(b) Insight (2)
Figure: Concept of Waterfall Model for Large-scale Software Systems

Five Necessary Improvements
There are five improvements which can help the waterfall model to overcome the risks. They are as follows,
For remaining answer refer Unit-II, Q15.
Q15. What are five necessary improvements in waterfall model?
The risks can be eliminated by making the following five improvements,

1. Program Design Comes First
To eliminate the risks associated with waterfall model, the program needs to be designed immediately after requirements
specification. This typically ensures that the failure associated with time, storage and data will not occur. The analysis phase must
be started only after successful completion of program design. Moreover, use of this approach can help in identifying the lack of
resources during initial phases itself so that the iteration can be re-performed before generating the end product.
Design Steps
(i) The model must start with design phase by designers instead of programmers (or) analysts.
(ii) In the second step, the following operations must be performed.
v Allocation of functions associated with processing.
v Designing the database.
v Adding time dimensions to estimate total time.
v Defining certain factors associated with operating systems such as modes of processing and interfaces.
v Defining processing functions associated with I/O.
v Defining fundamental procedures for carrying out overall operations.
(iii) Document the design in such a way that it describes the overall aspects of the project.
2. Document the Design Q16. What are the risks in the waterfall model
implemented in the traditional way?
The amount of documentation associated with the
software programs is very large because of the following OR
reasons, Explain the following,
(i) The software designer has to consider overall aspects (a) Adversarial stakeholder relationships.
provided by interface designers, managers and customers.
(b) Requirements driven functional decompo-
(ii) In the earlier phases of the software development, the sition.
design is considered as documentation.
(Refer Only Topics: Competitive Relationship
(iii) The real financial value of the documentation is decided between the Stakeholders, Requirements Driven
in such a way that, it will support future modifications Functional Decomposition)
made by an isolated test team, maintenance team and Answer : Nov./Dec.-16(R13), Q3
operations personnel.
Risks in the Waterfall Model
3. Do the Job Twice, if Possible
The following risks are involved in the waterfall model,
The computer program must be developed twice where (i) Protracted integration and late design breakage.
the second version, which takes into account all the critical
design operations in the form of a miniature and must be (ii) Late resolving of risks.
finally delivered to the customer for operational deployment. (iii) Requirements driven functional decomposition.
The first version of the computer program involves a special (iv) Competitive relationship among the stakeholders.
broad competence team, responsible for capturing problematic
(v) Emphasize on documents and review meetings.
aspects that exist in design, followed by their modeling along
with certain additional functionalities and finally generating (i) Protracted Integration and Late Design Breakage
an error-free program. For quicker development, it avoids the For answer refer Unit-II, Q17.
aspects that are non-critical.
(ii) Late Resolving of Risks
4. Plan, Control and Monitor Testing For answer refer Unit-II, Q18(a).
The test phase is considered as the biggest utilizer (iii) Requirements Driven Functional Decomposition
of project resources such as manpower, computer time and
The software development process is said to be
management assessments. The risk associated with testing is
requirements-driven because all the requirements
usually greater in terms of cost and schedule because it does not
associated with the project are defined as the first step
carry any check point for recovery and backup alternatives are
followed by their implementation. Later on, other
rarely available. Thus, most of the problems need to be solved
activities are performed in the software development
before the test phase, as it has to perform some other important
process. It immaturely treats all the requirements equally
operations such as,
irrespective of their type and criticality which makes
(i) Hire a team of testing professionals who are not involved it difficult because the concept of equally treating the
in the design phase. requirements depletes and takes significant engineering
(ii) Put an eye on the design to capture common errors, such hours specially in capturing traceability, testability,
as incorrect address references, dropping of minus signs logistics support etc. The basic assumption of the
etc. waterfall process is that, requirements are specified in a
functional manner, according to which the requirements
(iii) Conduct a test for each logic path. are allocated by dividing the project into various
(iv) A final inspection is carried on the end product. functions.
(iv) Competitive Relationship between the Stakeholders
5. Involve the Customer
The people who are interested or has stake (share) in
Before committing to the end product, customer must
the project are referred to as stakeholders. They must
be involved so that he can provide suggestions for improving
be identified at the earliest due to the following reasons,
the end product. The customer’s perception, assessment and
commitment can strengthen the development effort. Hence, an v To easily communicate with them throughout the
initial design step followed by a “preliminary software review”, project development life cycle
“critical software design reviews”, during design and a “final v To know the stake holders degree of involvement
software acceptance review” after testing is performed. in the project.
The competitive relationships among the stakeholders results due to the fact that information is recorded only on papers
which involve many difficulties such as requirement, specification and information exchange. This makes the project and
its requirements less accurate.
The sequence of events in contractual software includes,
v A draft contract-deliverable document carrying virtual design of the project is created by the contractor which is
given to the customers to confirm that project is covering all their expectations.
v The customers provide their feedback typically in 15-20 days.
v The feedback provided by customers are then considered in the project and final approved version is generated
typically in 15 to 30 days.
It results in higher levels of sensitivity with respect to the overhead incurred. It also degrades the customer-contractor
relationships. Hence, a balance between requirements, schedule and cost is difficult to achieve.
(v) Emphasize on Documents and Review Meetings
Q17. What is protracted integration and late design breakage? Explain with a suitable example.
OR
Explain the progress profile of conventional software project.
Answer : (Model Paper-II, Q4(a) | Nov./Dec.-17(R13), Q3))
The protracted integration and late design breakage in software development process occurs in unsuccessful projects. A
software project is said to be unsuccessful if it is incomplete, defying and not upto specifications, though it can be compiled and
executed. Every unsuccessful project will experience the following,
1. Success in the initial stages of life cycle itself when design is based on paper designs and detailed descriptions.
2. Agree to code in the later stages of the life cycle.
3. Existence of issues associated with implementation and uncertainties in interfaces makes the project integration difficult.
4. Continue the system to work under heavy budget and schedule pressure.
5. Perform non optimal fixes when there is lack of time to redesign.
6. Delivering the end product after scheduled time which is delicate, unmaintainable and easily broken.
A graph can be drawn to point out the ‘protracted integration and late design breakage’ of a project that used a waterfall
model management process. To do so, mark the development progress and scheduled time of the project on vertical and horizontal
axes respectively.
When the integration and testing activity lasts longer than expected, then it is called ‘protracted integration and testing’.
When this is occurred in a project, then the ‘development program Vs time’ graph will show an uneven path during the integration
phase, which corresponds to ‘late design breakage’.
A conventional software project’s progress view (i.e., the development progress Vs time graph) is shown below,
Activities:Requirements
Activities Program Coding and Protracted integration
analysis design unit testing and testing
100% Starting
point of integration
phase
Development progress
Late design
breakage
Scheduled time of project
Figure: A Conventional Software Projects’s Progress View
When the designing process is introduced with waterfall model then it will surely result in late integration and performance.
The steps that were carried out in a conventional model are,
1. Design the complete system on paper
2. Implement the complete system
3. Integrate the complete system
4. Test the complete system for a relevant fundamental architecture.
When the projects use conventional process, atleast 40% of resources get consumed during the testing phase.
The cost associated with various activities of a project are given below,
List of Activities Cost

Management activities 5%
Requirements activities 5%
Design activities 10%
Code and unit testing 30%
Integration and testing 40%
Deployment 5%
Environment 5%
Total 100%
Example
Blue Infotech is developing a software, Easy Survey requested by International Times (IT). Initially, it collects all the
project requirements from IT and then design the software with prior approval of the client (IT). It is dedicated mainly towards
the integration phase i.e., testing and coding is carried out in a single phase. This integration phase is not effective because the
testing is not performed at the initial stages of the development. Errors occurred during the testing of Easy Survey are,
(i) It is platform dependent.
(ii) It requires high speed processor.
(iii) RAM is not sufficient.
These errors could not have crept in, if the testing performed in the initial stages of the development.
The developers have to rollback all the activities for creating a proper design equipped with testing which consumes
a lot of time and results in an unsuccessful project. This situation is referred to as protracted integration and late design
breakage.
Q18. Discuss briefly about,
(a) Late risk resolution and
(b) Adversarial stakeholder relationships.
Answer :
(a) Late Risk Resolution
One of the drawbacks of the basic waterfall model was that, resolving risks during initial stages of life cycle was not
possible. Here, risk corresponds to failure in achieving any of the goals such as cost, feature, schedule or quality.
Projects that are developed using the conventional waterfall model are usually associated with four different risk exposure
periods. They are,
1. Risk exploration period
2. Risk elaboration period
3. Focused risk resolution period
4. Controlled risk management period.
1. Risk Exploration Period
This period involves requirements specifications. When the ‘Requirement’ phase is carried out in initial stages,it is difficult
to predict the risk exposure.
2. Risk Elaboration Period
This period involves design and coding phases of project life cycle. When the ‘Design’ phase completes, the understanding
of requirements will get balanced. Thus, the risk exposure will also gets stabilized irrespective of the type of design. The
stabilization level of the risk is usually high as there exist very limited number of facts that will help the software manager
in evaluating the objective. The design phase is then followed by the ‘coding’ phase which involves resolving of risks
associated with distinct components.
3. Focused Risk Resolution Period
This period involves integration phase of project life cycle with which the actual level of the quality and the system risks
become definite (tangible). This phase not only resolves the actual design issues that user encountered but also develops
the engineering trade offs. In contrast, this resolving is very high-priced as this phase has a tendency to remain unchanged
and thus prevents any changes to be made to the majority of artifacts.
4. Controlled Risk Management Period
This period involves testing phase of project life cycle. When the project undergoes a protracted integration phase, most
of the critical risks get resolved. However, it will highly effect the quality or maintainability of the end product.
The risk profile of software project that uses the conventional technique is shown below,
Figure: Project Life Cycle
(b) Adversarial Stakeholder Relationship

For answer refer Unit-II, Q16, Topic: Competitive Relationship between the Stakeholders.
Q19. What is the impact of the documentation and review meetings?
Answer :
Documentation
The documentation is one of the most significant step of any software development process. It involves preparation of
documents containing the architectural, general and implementation details about the system under development. Thus, documents
must evolve with respect to the evolution in the project’s releases (i.e., any development made in the system). The reviewers
then perform formal and informal reviews on these documents along with the code generated. The user-specific documents must
also be produced and end-users must be provided with an access to these documents so that, they will be up-to-date regarding
the operations and installations of all the releases (including the latest one). Apart from this, analysis documents must also be
generated which describe the functionality provided by each of the individual system units. The architectural and implementation
documents produced will facilitate the development team with the complete details about the architecture, strategies followed etc.
Thus, they (development team) can easily adapt and evolve this system.
For documentation of a system, the following documents must be included.
(i) High-level architectural documents.
(ii) Documents containing the key abstractions and strategies followed.
(iii) Behavioral documents (i.e., documents describing the behavior of the system).
The traditional systems focused more on producing the documents describing the functionalities of each and every method
within a class instead of focussing on the architectural issues such as collaborations among the various classes and objects etc.
Thus, unnecessary documents are produced consisting of several tons of paper. In object-oriented systems, the contractors focus
more on documenting higher-level structures instead of documenting individual class structures so that, they could spend sufficient
time in maximizing the quality of software simultaneously minimizing the associated risks.
Review Meetings
A review meeting is typically a formal meeting that is carried out in order to evaluate quality of the product produced. This
meeting usually consists of reviewers, producers, review leaders and other personnel who have participated in the development
of the product. A review meeting can be considered as a successful meeting if it is well planned, controlled and attended. Some
of the significant constraints that must be followed by all the review meetings are given below.
(i) A review must incorporate only 3-5 reviewers.
(ii) The review meeting should last for two hours or less.
(iii) The review meeting must be well-planned and the reviewers must be prepared with their reviews.
The primary objective behind any review is to identify all the existing errors in the product, in addition to the problems
that may arise in near future. Thus, review meetings are necessary for any system development process.
Q20. Compare the apparent and actual results of document and design reviews in the conventional process.
Answer :
The apparent and actual results of document and design reviews in the conventional process are tabulated below,
Apparent Results Actual Results

1. A detailed description about the software is provided 1. Most of the audience could not understand the details about
to the diverse audience. the software because resultant documents do not explain
most of the essential assets and risks associated with the
complex software systems.
2. Building a software design that is expected to cover 2. There is no definite proof which demonstrates that the
all the requirements. software is compliant. Though, it is negligible to have
indefinite requirements that are compliant.
3. All the requirements are considered. 3. Very few among all the requirements are design drivers.
When all the requirements are considered, the critical drivers
cannot be aimed.
4. The design is said to be faultless until and unless it 4. The design is always said to be at fault. These faults in the
is proved to be at faulty. design, will be revealed in the later stages of the life cycle.
Q21. Give industrial software metrics top 10 list. March-17(R13), Q3(a)
OR
List and explain the ten reasons of why conventional software management does not perform
satisfactorily.
The top 10 list of software metrics provided by Boehm are as follows,

1. The cost associated with bug determination and correction post delivery is 100 times greater than performing this in the
initial stages.
For example, an automobile company is handling defects associated with the products after delivery, then if the same
defects gets identified during initial stages such as production stage, it can save several orders of magnitude associated
with cost.
2. A development schedule can be compressed not more than 25% because this percentage is directly proportional to the
number of resource. This means that increase in this percentage will make the number of resources to increase gradually.
Moreover if the staff is increased, it involves management overhead.
For example, consider 50-staff month work which can be achieved in 5 months with 10 members. This schedule cannot
be compressed further such as completing in 1 month with 25 members as it leads to management overhead. However,
schedule can be expanded accordingly.
3. This principle is called as iron law of software development. According to this law, the cost associated with maintenance
is doubled value of the cost associated with development. For example, if the development incurs ` 1000 of cost then the
maintenance incur ` 2000 of cost. These figures can be greater in case of successful projects and are typically based on
success rate.
4. The cost associated with development and maintenance can be computed as a function of SLOCs. This computation involves
custom software development along with the shortages that occur with respect to components and their reusability.
5. Diversifications in the software productivity greatly depends on the type of people involved. According to this principle,
it is necessary to involve appropriate people in the project in order to capture the reasons behind success and failure of the
project.
6. The ratio of cost involving hardware associated with software is still in the increasing state as its value in 1985 is recorded
as 85 : 15 which was 15 : 18 in 1955.
This increase is because software describes almost 85% of functionality of the system and hence it is associated with
productivity.
7. Programming is carried out within 15% of the overall effort. Remaining 85% of available resources are required for
planning, testing, controlling, change management and many of such aspects.
8. The cost per SLOC associated with individual software programs is 3 times less than that of cost associated with software
systems and 9 times less than the cost associated with software system products. This relationship is typically referred to
as diseconomy of scale according to which, cost per SLOC increases with increase in software.
9. About 60% of errors gets captured using of walkthroughs. However, the errors captured using this approach do not carry
critical ones and it captures these in the later stages of life cycle. But, it is not suitable for capturing multi-ordered issues
such as performance bottle necks, resource contention, etc.
10. The percentage associated with contributors and contributions in most of the project aspects are 10% and 80% respectively.
An example of this principle is 20% of components utilize 80% of software cost.
2.1.2 Evolution of Software Economics
Q22. Define software economics. What are the five components of software cost models?
Answer :
Software Economics
Software economics examines the entire idea of software development and uses software cost models to estimate software
costs.
Five Components of Software Cost Models
The five components of the software cost models are,
1. Size of the end product
2. Process involved in producing the end product
3. Software engineering personnel
4. Environment
5. Required quality.
1. Size of the End Product
The quantity of function points or source instructions associated with a functionality is used as a metric for measuring size
of the product.
2. Process Involved in Producing the End Product
This component of software cost model uses a process that avoids activities such as, overhead incurred in communication,
rework etc, which act as hurdles for a software to reach its destination.
3. Software Engineering Personnel
This component considers the capabilities and experience of each and every individual person associated with the project
to solve issues associated with systems and applications.
4. Environment
The environment refers to a set of tools and techniques used to automate the software process and to generate an efficient
product.
5. Required Quality
The desirable quality of the product involving its reliability, features, adaptability and performance is one of the most
important component of the software cost models.
Relationship Between the ‘Estimated Cost’ and the Above Components
Using above components i.e., size, process, personnel, environment and the required quality the estimated effort can be
computed as,
Effort = (Size Process ) (Personnel) (Environment) (Quality)
Q23. Describe the three generations of software economics.

Answer : (Model Paper-I, Q4(b) | Nov./Dec.-16(R13), Q2(b))
The three different generations of software economics are as follows,

1. Conventional
2. Transition
3. Modern practices.
1. Conventional
The generation of 1960s and 1970s was termed as conventional generation and was centered around craftsmanship. All the
organizations of this generation basically used the conventional tools and processes. In addition to this, they also involve
the conventional components built over primitive languages. Thus, all the objectives associated with cost, schedule and
quality could not be achieved where, the performance of the project was certain. Eventually, the prediction of having over
budget and over schedule was always true.
2. Transition
The generation of 1980s and 1990s was said to be the transitional generation and was centered around software engineering.
All the organizations of this generation basically used separate off-the-shelf tools along with those processes that were more
frequently used. In addition to that, more than 70% of the conventional components were developed using higher level
languages. Remaining 30% of the components were developed to be used as commercial products. These products included
DBMS (Database Management System), OS (Operating System), GUI (Graphical User Interface), networking etc. Few
organizations in 1980s were capable of coinciding with the economies of scale. But, as the complexity of applications got
increased, the desired performance of the project could not be achieved, because the languages, techniques and technologies
used at that period of time could were not capable of handling such complexities.
3. Modern Practices
The generation starting from 2000 is said to be the Modern practice generation and is centered around software production.
All the organizations of this generation basically used integrated off-the-shelf tools along with the managed and measured
processes. About 70% of the components used by these organizations are off-the-shelf components and 30% of them are
built conventionally. The production of component based systems can be very high, when advanced software technologies
and integrated production environments are considered. The performance of the project is predictable and is expected to
be on-budget and on-schedule which is usually true.
The size of the software (Vs) cost of the software for all the three generations is shown below,
Conventional Transition Modern Practices
COST
SIZE
Figure: A Graph for Size of the Software Versus Cost of the Software
Q24. Why is the effort (in person-months) not a simple product of duration and number of persons needed?
Answer :
‘Effort’ refers to the number of persons involved in a project for some specified duration (in months). It is expressed in
terms of ‘person-months’.
When the development time and the average number of persons involved in a particular project are known, then the effort
(in person-months) can be calculated as,
Effort (in person-months) = Average staff size (persons) × Development time (months)
Effort
Average staff size = Duration/Development time
Once, the effort and the project size are known, the productivity level (i.e., the rate of output or the production per unit of
the effort) can be calculated as,
Project size KLOC
Productivity, P = Effort = PM
After estimating the project size, the cost and development time can be determined.
The relationship between the number of persons working on a project, the effort required and the development time is not
linear i.e., the effort required, increases with increase in the number of persons working on a project. This is because people spend
more time communicating and defining interfaces between the system parts generated by other people. Increasing the number of
persons to twice does not imply the decrease in the project duration to a half.
According to COCOMO model, the completion time for a project is a function of total effort required, but is independent
of the number of software engineers working on the project. This means that decrease in the development time causes the effort
to increase exponentially.
Q25. Explain the method of COCOMO estimation with the following example. Give the advantages and
disadvantages of this method. A project manager estimates the number of adjusted function points for
a project as 1000. The language chosen for implementation maps to about 33.2 LOC per function point.
What is the duration of the project and how many persons will it take? What will be the team structure
you choose if this is a project involving latest technology with complex functionality? Take minimum
time in months, tmin= 8.14[Loc/P]0.43 in months, where B = 0.16 for 5-15 KLOC projects and B = 0.28 for
>30 KLOC. Effort in person months E = 180 Bt3(where t is in years). Take P = 12,000.
Answer :
COCOMO Model
COCOMO (Constructive Cost Estimation Model) was developed by Boehm in the year 1981. Boehm estimated that software
development of project can belong to any one of the following class depending on the complexity that exist in the development.
(i) Organic
(ii) Semidetached
(iii) Embedded.
Boehm wants every developer not only to ponder over the characteristics but also on the development environment and team.
Practically, if considered all the above three categories relates to application utility and system programs. Compilers and linkers
are considered to be utility programs, while data processing programs are application programs. System programs communicates
directly with the hardware. It embraces meeting, timing constraints and concurrent processing. For example, real time systems,
operating systems.
(i) Organic
In organic type category, a well understood application program is developed. The development team is assumed to be
small but they possess experience as they worked on similar type of projects.
(ii) Semi-detached
In semidetached type category, both experienced and non experienced staff accompanies. The team members may have
inadequate experience about projects or related systems or may not be familiar with the elements of the software being
developed.
(iii) Embedded
In embedded type category, the software which is being developed is strongly connected to complex hardware. It may also
contain rigid procedures or regulations which are to be followed while the development is ongoing.
Effort Estimation Advantages
The formulae for estimating the effort based on code 1. It is the most thoroughly documented model based on
size for the three classes of software products are, the previous experience.
(i) Organic Type 2. It is very easy to use.
Eff = 3.4 EAF (SIZE) 1.05
3. The cost drivers involved in this model provides detailed
(ii) Semi-detached Type information about the productivity to the software
manager.
Eff = 3.0 EAF (SIZE)1.12
4. The actual data collected from the previous projects helps
(iii) Embedded Type
in identifying the values of the constants associated with
Eff = 2.8 EAF (SIZE)1.2 this model.
Time Estimation Disadvantages
The formulae for estimating development time 1. Choice of the mode sometimes presents difficulties.
depending on effort for the three classes of software products
are, 2. Safety and security issues are neglected.
(i) Organic Type 3. Many hardware and customer-related issues are ignored
when the model is used.
Time-dev = 2.5 (Eff)0.38 months
4. The importance of the software requirements and
(ii) Semi-detached Type
specification phase is neglected which is the most
Time-dev = 2.5 (Eff)0.35 months sensitive phase in the software development life cycle.
(iii) Embedded Type Problem
Time-dev = 2.5 (Eff) 0.32
months. Given that,
Note: ‘Effort’ in all the three modes represents the number of (i) Number of adjusted function points = 1000
staff-months.
(ii) The language maps to 33.2 LOC per function point
EAF (Effort Adjustment Factor) is the product of 15 0.43
effort adjustment factors and ‘SIZE’ represents the number of (iii) tmin = 8.14 < LOC
p
F in months
source instructions delivered.
Description of the COCOMO Life Cycle (iv) B = 0.16 for 5-15 KLOC projects
The COCOMO life cycle involves five fundamental = 0.28 for > 30 KLOC
phases. (v) Effort (person-months) = 180 Bt3 (where ‘t’ is in years)
(i) Plans and requirements (vi) P = 12,000
(ii) Product design Required to Find
(iii) Detailed design (i) The duration of the project (tmin)
(iv) Code and unit testing 0.43
tmin = 8.14 < LOC F
(v) Integration and testing. p
Software Work Breakdown Structure LOC = Number of function points × Language map
to LOCs
The standard activities of the work breakdown
structure are, = 1000 × 33.2
(i) Requirements analysis LOC = 33200

0.43
tmin = 8.14 < 12000 F
(ii) Product design 33200
\
(iii) Programming (detailed design, coding, unit-testing and
integration) = 8.14 × 1.549
(iv) Test planning (ii) Number of person it will take [E]
(v) Verification and validation tmin = 12.6 months or 1.05 years
(vi) Project management and administration Effort (person-months) = 180 Bt3
(vii) Configuration management and quality assurance = 180 × 0.28 × (1.05)3
(viii) Manuals. Effort = 58 person-months
Team Structure 1. Achieving ROI Across a Line of Business
Customer/
Strategic
Strategi Business When investment is done in common architecture,
Functional/
Technical Group
Business Unit Manager process and environment for all line-of-business systems, then
the software ROI is achieved at the first system among the
successive ones as shown in the figure (a).
Software
Pr ect Manager
Project Quality At this stage, ROI remains constant till the end of the
Advisor
first system and then gradually decreases from the initial stage
of second system to the last stage of the Nth system.
Developers Configuration Database

Controller Administrator
Software
ROI
Figure: Hierarchial Team Structure
As shown in the figure, a project manager, who is
the head of a development team reports to the business or Cost per unit
accounts manager. The developers, database administrator and
the configuration controller reports to the project manager. In
addition to these members, a large project may also involve
the module leaders and the defect prevention team (responsible First Second Nth
Investment
for defect prevention). A Software Quality Advisor (SQA) is system system System
also involved in each project, which interacts with the project Line-of-Business Life cycle: Successive Systems
manager and with the configuration controller but instead of
Figure (a): ROI Across a Line of Business
reporting to the project manager, it reports to an independent
channel. 2. Achieving ROI Across a Project with Multiple
Iterations
Q26. How a return on investment profile can be
When investment is done in robust architecture, mature
achieved efforts across lifecycles of various
domains? iterative process and process automation then the software ROI
is achieved at the first iteration among the successive ones as
OR shown in figure (b).
Describe return on investments in different At this stage, ROI remains constant till the end of first
domains. iteration and then gradually decreases from the initial stage of
Answer : March-17(R13), Q2(b) second iteration to the last stage of the Nth iteration.
Return On Investment (ROI) is defined as the amount
of money returned or gained after an investment is made.
Software
Mathematically, ROI is defined in terms of benefit and cost as, ROI
ROI = Benefit – cost × 100%

Cost
Most of the organizations treat ROI as the softside Cost per unit
benefit, which is not correct. It is strictly defined in terms of
rupees and paise. More over, it is tangible and measurable, as
it gives a clear picture of the status of an organization. Few
times, its value may be negative, which does not states that the Investment First Second Nth
iteration iteration iteration
organization is facing loss. Organizations specially, business
organizations focus on long-term benefits and profits. They- Project life cycle: Successive iterations
keenly focus on ROI so that the fruits of ROI can be enjoyed Figure (b): ROI Across a Project with Multiple Iterations
maximally. The short term losses or negative values are ignored 3. Achieving ROI Across a Life Cycle of Product Release
and continuous measures are taken to reach the correct figure. When investment is done in product architecture, life-
Very large projects (systems of systems), long lined products cycle release process and process automation then the software
and lines of business (consisting of multiple similar projects) ROI can be achieved at the first release among the successive
are the areas where organizations can achieve better economics release as shown in figure (c). At this stage, ROI remains
of scale. A Return On Investment (ROI) profile can be achieved constant till the end of first release and then gradually decreases
in subsequent efforts across life cycles of various domains. from the initial stage of second release to the last stage of the
This achievement across each domain is illustrated below, Nth release.
The main idea behind function point metric is that size of
a software is directly based on the distinct functions or features.
Software product which possess several features would be of
Software
ROI larger size, while the product which possess less features would
be of smaller size. When the function is invoked it reads the
input data and converts it into output data. For instance, consider
Cost per unit
a book feature of library system. When this book feature is
invoked, it reads it as input and provides its location along with
the number of copies available as output.
Thus calculation of number of input and output data
Investment First Second N th shows the number of function which supports the system.
release release release Function point metric also helps in estimating the size of a
Product Life Cycle: Successive Systems software product. The size is presented in function point in
terms of the weighted sum of the five problem characteristics.
Figure (c): ROI Across a Life Cylce of Product Release Function point is calculated in two ways,
Q27. Briefly explain pragmatic software cost In the first step, the unadjusted function point is estimated,
estimation. while the second step technical complexity factor is estimated
Answer : (Model Paper-II, Q4(b) | March-17(R13), Q3(b))
Unadjusted Function Point (UFP)
Software Cost Estimation
Unadjusted function point is expressed in the following
The projects that use iterative development approach manner.
suffers from a problem in software cost estimation. The problem
is that, there will not be an adequate amount of documented case UFP = (NI) * 4 + (NO) * 5 + (Na) * 4 + (NF) * 10 + (NT) * 10.
studies at hand. Most of the cost model vendors do insist that Different Parameters
their tools appropriately estimate the software cost for those
projects that use iterative development approach. Some of these The different parameters of UFP are as follows,
tools are set up on empirical project databases. It is also very (i) Number of Inputs (NI)
difficult to compare the data of different projects or find their
consistency as there exist no consistent measuring unit. Data item input is provided by each user data. It is
different from user inquiries. Programmers do not count
The three most important points that are considered by
individual data items but only consider set of related
both the developers and vendors in dealing with the software
inputs as a single input. For instance, entering the details
cost estimation models and tools are as follows,
of an employee in pay roll software such as Name, Age,
1. Selection of a Cost Estimation Model to be Used Phone numbers, Address, Sex is considered as a set of
Among different cost estimation models, COCOMO is related single input.
said to be one of the most well-documented model.
(ii) Number of Outputs (NO)
2. Selection of a Measuring Unit to Measure the Size of
the Software Outputs denotes the screen outputs, error messages
produced, reports printed. When number of outputs are
The different measuring units that can be used to measure
calculated only set of related data items is counted but
the size of the software are,
individual data items present within the report are not
(i) Source Lines of Code (SLOC) considered.
(ii) Function points
(iii) Number of Files (NF)
(iii) Subjective or ad hoc.
Files refers to logical file and physical file. Logical file
Out of these, only the first two measuring units are useful. denotes a set of logically related data. Therefore they
(i) Source Lines of Code (SLOC/LOC) can also be physical files or data structures.
For answer refer Unit-I, Q28. (iv) Number of Inquiries (NQ)
(ii) Function Points Number of inquiries refers to the distinctive interactive
In the year 1983 Albrecht developed Function Point queries which are inquired by user. These are nothing but
Metric. It overcomes several drawbacks of LOC metric. The the user commands which needs action to be performed.
biggest advantage of function point metric is that it computes
(v) Number of Interfaces (NI)
the size of a software direct from the problem specification.
Whereas in case of LOC the size can be estimated only after Interfaces refers to things used for exchanging details
the product has been completely developed. with other systems. For example, data files, tapes, disks.
(vi) Technical Complexity Factor It is basically considered as a basis for estimating and
analyzing the overall cost of the software.
Technical Complexity factor enhances the unadjusted
function point measure by taking into account some Risks
Software manager,
Software architecture Options
factors such as throughput, high transaction rates, manager. Trade offs
response time requirements. Software assessment Other alternation
manager
These factors are allotted values from 0 to 6. 0 represents
not present or not influenced while 6 represents strong influence. Analyze
TCF is expressed as (0.65 + 0.01 * DI).
DI represents 0 to 70. Thus, TCF value varies form 0.65 Estimate
to 1.35. In the end the total estimation of function point metric Cost modelers
Target cost
can be obtained using the expression.
FunctionPoint = UFP + TCF
Figure: Predominant Process
3. Selection of a Tool or Metric that will set up a Good The following are the steps performed in predominant
Estimate process,
v Initially the members of software development
Following are the attributes that help in finding out a
process (software manager, software architecture,
good estimate. software assessment manager) analyze the risks
(i) The project manager, architecture team, development that might occur while achieving target cost of the
team and test team who are responsible for carrying software.
out the project work must design and support a good v After analyzing, the software project manager
estimate. discuss the risks with other stakeholders of the
project.
(ii) All the stakeholders accept a good estimate as unrealistic,
which can however be achieved. v The project manager then estimate the actual
cost required for developing the software. This
(iii) A good estimate always depends on the software cost is done by modifying the parameters until the
model which is well-defined and has a credible basis. target cost is justified taking into account all the
risks, trade-offs.
(iv) A good estimate also depends on the database of a
previous project that made use of identical processes, The result generated after performing the predominant
technologies, environments, quality requirements and process leads to many modifications in plan, design or scope
people. of the project that is being developed.
(v) Complete details of estimation are also provided so that 2.1.3 Improving Software Economics
the most important risk areas are not neglected and the Q28. Explain the important trends to improve the
probability of success can be determined. software economics.
Instead of deriving just a good estimate, an ideal estimate Answer : Model Paper-III, Q4(b)
can also be derived. An ideal estimate depends on the mature The economics of a software development process can be
cost model’s experience that can be considered as a base for improved, but there are multiple obstacles in doing so. Among
several identical projects with the same tools and processes and these obstacles units of measurement, unending hyperbole
the same team. However, when a new project is started by a agreement between experts are more challenging. Different
project team, then deriving an ideal estimate is not possible for organizations behave differently in improving the economy of
them, though they can derive a good estimate which can also a software development process. However, software economics
be achieved in the later phases of the life cycle. can be enhanced by using the five parameters of the software
cost model.
Example: Predominant Cost Estimation Process
(i) Maintain quality thresholds
Predominant process is a satisfactory process which is (ii) Use good environments such as automation tools
performed so as to, and technologies.
(i) Estimate the risks associated with the cost (iii) Improve the process of developing the end product.
(iv) Minimize the complexity and size of the product.
(ii) Understand the crucial function points and trade
offs in accordance to the objective. (v) Use good teams and highly skilled personnel.
The priority order of these parameters in most of the 3. Analysis of human factors and operations analysis can
software domains is 4, 3, 5, 2 and 1 (the numbering given above). be done in a better way through the building blocks and
Based on these parameters, the trends observed in improving primitives provided by GUI.
software economics are listed below.
4. The duration of feedback and engineering cycles can be
Trends to Improve Software Economics reduced from months to days or weeks.
1. Cost Model Parameter: Environment 5. Building user interfaces that involve continuous user
Trend : Automation of testing, feedback and a balanced understanding of the issues in
Coding analysis and documents design and requirements phases.
Open systems In addition to these cost model parameters, the
Hardware platform performance, improvements in hardware performance is another factor
contributing to the improvement of software economics. Due
Integrated tools.
to this, the sources of complexity associated with software
2. Cost Model Parameter : Personnel implementation can be eliminated with the availability of more
Trend : Teamwork bandwidth, more memory and more cycles. The simple brute-
Win-win cultures force solutions is also a major factor that contributes to the
improvement of software economics.
Training and personnel skill development
Q29. How to reduce software product size? Explain.
3. Cost Model Parameter : Quality
Trend : Statistical Quality Control Answer :
Demonstration-based assessment There are several approaches to reduce the size of the
software product. The main aim of these approaches is to
Hardware platform performance achieve a software with fewer lines of human-generated source
4. Cost Model Parameter : Size statements. Some of these approaches are as follows,
Trend : Reuse (i) Good programming language and object-oriented
Higher order languages methodology
Commercial components (ii) Reusable and commercial components.
Object-oriented analysis, design, (i) Good Programming Language and Object-oriented

Methodology
programming
5. Cost Model Parameter : Process
(ii) Reusable and Commercial Components
Trend :Acquisition reform
Architecture-first development
Q30. Explain how the use of good languages and
Interactive development
object-oriented modeling can reduce the SLOC
Process maturity models. in software.
These trends are highly dependent on each other. For OR
example, the size of the product is effected by the use of tools,
Explain about object-oriented methods and
whereas the process can be improved with the availability of
visual modeling.
tools, etc. These interdependencies among the trends can be
clearly understood by considering an example domain of user (Refer Only Topic: Object-oriented Methods and Visual
interface software. To develop a user interface, the developers Modeling)
would spend most of the time on analyzing screen dynamics, Answer : Nov./Dec.-16(R13), Q4(a)
human factors, operation and screen layout. Such analysis Good Programming Languages
were completely paper-based because creating designs was
very expensive. Thus, the techniques for improving software The life cycle estimates that are language-independent
economics must be focused on minimizing such paper-based can be estimated using UFPs (Universal Function Points). The
analysis. One such technique is the usage of GUI (Graphical external inquiries, external output, external data interfaces, user
User Interface) technology. With this technology, inputs and internal logical data groups are the major units of
function points. If the implementation language and its candidate
1. A quick and inexpensive user interface can be created.
solution is available for a software, SLOC metrics acts as one of
2. The requirement for paper descriptions gets eliminated the best estimators for such software. SLOC per UFP for some
completely. popular programming languages is given below,
the size of the program becomes huge. Whereas, when a high-
SLOC/UFPs Languages
level language is used, the consumption of memory, processor
35 Visual Basic cycles, communication bandwidth and other resources increase
55 Java, Ada 95 rapidly. However, improvements and optimizations in hardware
56 C++ performance can overcome these drawbacks, but is ineffective
71 Ada 83 on embedded platforms.
91 COBOL 85 Object-oriented Methods and Visual Modeling
105 FORTRAN 77 Another way of reducing the SLOC is through the usage
128 C of object-oriented methods and visual modeling. The advantages
320 Assembly of object-oriented methods include improvements in software
quality and productivity. However, the major advantage is, the
The value for SLOC/UFP (SLOC per UFP) for a language software abstractions can be captured and visualized by using
clearly indicates about the expressibility of a language. The lesser highly formalized notations. An additional advantage of using an
the value, the more expressive is the language. However, the OO technology is that, it creates an impact that the technology
languages with more SLOC per UFP value, does not mean that focuses on the size of the application.
they are not useful. Each language has its own boundary within The three reasons for OO technology projects being
which it shows how attractive it is. Some of these languages are, successful, as described by Booch are,
1. VB or Visual Basic, can built applications that are simple 1. The languages and environments that implements
and interactive. However, the real time and embedded the architectures of object-oriented technology are
programs that are used in aviation, cannot be easily built supported in an excellent manner by a feature in OO
using VB. technology. “According to this feature boundaries need
2. Ada 95 may not give its best output for programs like a to be defined typically using firewalls which separates
highly parallel number crunching program. However, an various elements. Thus, preventing a change in one part
application that controls a nuclear power plant, “ cost of of system to affect the entire architecture”.
failure” system, can be efficiently built using Ada 95. 2. The life cycle activity called “integration” in OO
The difference in the values for SLOC per UFP for technology makes the development to prioritize the
Ada 83 and Ada 95 is the added object-oriented programming architecture. This activity is continuous and helps
features to Ada 95. Not only this, Ada 95 provide support for in the early determination of risks consecutively
various advanced Ada programming concepts. Some of these performing appropriate corrections, without effecting the
are encapsulation, separation of interface and implementation, development process. The use of continuous integration
software engineering technology advances, concurrency helps in capturing the risk early and making incremental
support, architectural control primitives, etc. Among these, the corrections with stabilizing the total development effort.
object-oriented flavour of Ada i.e., Ada 95 makes the size of 3. The focus on improving interpersonal communications
the program to be 30% less than the original program size. and teamwork indicates that the OO technology also
Similarly when C and C++ are compared, the differences concentrates on the clarity and better understanding
are more prominent. C does not support encapsulation, whereas between its users . According to Booch, it provides a
it is one of the main reasons for the development of C++. In common set of vocabulary for an object oriented model
addition, C++ also supports some of the advances in Ada. On of a problem and its solution so that the end users and
the contrary, C++ includes the language ‘C’ which means, developers can share without any difficulty.
all C programs can be written in C++. Thus, helping the ‘C’ According to Booch, an object-oriented project becomes
programmers to easily transit to C++ language but the drawback successful if it has the following five characteristics.
associated with this facility is that the ‘C’ programmers trip to
(i) When it carries a strong architectural vision.
use most of the ‘C’ concepts in C++ and do not explore the
additional features of C++. (ii) When it utilizes the features of object oriented modeling
in an effective way.
The lines of code for a program in different languages
not only vary with the language in which it is written, but also (iii) Major point of concern should be given to develop a
with the usage of the automatic code generators, commercial system with only critical characteristics that can be easily
GUI builders, commercial DBMS and middleware. For example, understood.
a program in C++ or Ada 95 having a program size of 175,000 (iv) Iterative and incremental development life cycle needs
lines can be reduced to 75,000 lines, by using such tools. to be applied in a way that can be effectively managed.
Hence, the decision of using an appropriate language and (v) A system that focuses on the objectives where the risk
appropriate commercial components, largely affect the cost of of failure does not exist and provides an effective way
the software life cycle. If low-level languages are used, then of communication.
Q31. What are the issues in obtaining reusable The organizations that meet the above criteria face many
components? What kind of organizations challenges as developing reusable components can incur huge
should be chosen for buying COTS? costs, if they cannot be used across multiple software projects.
OR However, there may be 1% or 2% of organizations that develop
software products and yet do not sell them as their primary
Discuss about reuse with a neat diagram. business purpose. This does not mean that the developing cost
Answer : March-17(R13), Q5(a) of the reusable components is less. The economic trade-offs
Improvements in programming languages include between cost and schedule investments for developing reusable
activities like building reusable components and reusing the components are depicted below,
available components. Components reusability, retains the
components quality feature set, and performance attributes as
well as reduces the development cost of the component. The
importance given to reusability is not that much high rather, it
and schedule Resources

is used for experiencing existing architectures or as a part of
Development cost
ROI (Return On Investment). On the other hand, the Microsoft’s
PC platform has achieved huge success through reusability.
However, there existed many hurdles while achieving its success
such as fragmentation of machine architectures, languages,
tools, notations, operating systems and standards.
Organizations developing reusable components aim N
at getting huge profits from the developed products. There Figure: Cost and Schedule Investments for Developing Reusable
exist very few organizations that do not aim at this goal. The Components
issues result from developing reusable components by any
organization include lack of, Where ‘N’ is the number of projects using the reusable
components. The organizations can retain their position in the
1. Trust worthiness market, if they possess,
2. Economic motivation (i) A support infrastructure
3. Improvement (ii) A development team
4. Usability (iii) A sales and marketing infrastructure that is solely

product-oriented.
5. Support
Nevertheless, the success of reusability is only in
6. Accountability for quality. commercial products like office applications, GUI builders,
middleware, operating systems and networking but not in
The organizations that lack above features are considered software components. But, reusability still plays an important
to be nonprofitable organizations which usually provide “open” role in the success of software components.
reuse libraries.
Q32. Write the advantages and disadvantages of
COTS stands for Commercial Off-The-Shelf, custom software development and commercial
hardware/software products that can be used by anyone who components.
needs it. These products are designed in such a way that,
Answer :
customization is not required when they are implemented
into the existing systems. Microsoft office is an example of Custom Software Development
COTS used in business software solutions. In addition to the Advantages
above ready-made products, other products include GOTS
1. In contrast to conventional model, custom development
(Government Off-The-Shelf), NOTS (NATO Off-The-Shelf)
employs smaller and simpler implementations.
and MOTS (Modifiable Off-The-Shelf). Reusable products
must only be used when the organization, 2. It mainly provides better performance.
(i) Support new features to be added and can be easily 3. It has control over end enhancement.
transformed to new technologies, while improving Disadvantages
quality. 1. Besides being expensive, its development is unpredictable.
(ii) Is ready to support in future only for economic reasons. 2. The maintenance of this model cannot be defined.
(iii) Has huge number of customers. 3. It has a problem of single platform dependency.
(iv) Is profit based. 4. This process may drain on expert resources.
Commercial Components 2. Macroprocess
Advantages The practices, policies and procedures of a software
1. It is possible to predict the license costs associated with project used to produce a full-fledged product within the
these commercial components. given time budget and quality constraints. The main objective
of the macroprocess is to generate an agreeable instance of
2. The mature technology available is primarily used.
metaprocess under some specific constraints.
3. They are not dependent on hardware and software which
Atttributes of Macroprocess
enhances the quality of the product.
The attributes associated with a macroprocess are as
4. The software developed through this approach performs
follows,
its functionality efficiently.
(i) Subject and Concerns
Disadvantages
1. It is required to be upgraded frequently. The subject of a macroprocess is project itself whereas
the major concern of this process is to achieve required
2. The product through this approach lacks in providing quality without affecting its financial performance.
run-time efficiency.
(ii) Objectives
3. The integration in this process is not always trivial.
The objectives of a macroprocess include handling of
4. Upgrades and maintenance cannot be controlled. risks involved in the project, achieving desired profit and
5. This process possess irrelevant features that utilize to complete the project within time, cost and achieving
additional resources. required quality.
Q33. What are the three levels of software process (iii) Metrics
and their attributes? Explain.
Macroprocess is measured in terms of cost, time, success
Answer : rate and scrap/rework generated.
Process and their Attributes (iv) Audience and Timescales
Improvement in software processes means improvement This process is typically monitored by software engineers
in its processes and subprocesses. The organizations that are and project managers. It can take a minimum of 1 month
software-oriented consists of three levels of processes. and a maximum of many years to complete.
1. Microprocess 3. Metaprocess
The practices, policies and procedures of a software project The practices, policies and procedures of an organization
team which are used to achieve the end product are collectively used to achieve a line of business which is based on software. All
known as the microprocess. The main objective of microprocess is long-term strategies, organizational economics and a software
to obtain an intermediate product baseline with acceptable quality ROI are the major concerns in metaprocess.
and functionality both in terms of cost and time. These three levels can be easily compared by comparing
Attributes of Microprocess their attributes objectives, concern, metrics, time scales,
audience etc.
The attributes associated with a microprocess are as
follows, Attributes of Metaprocess
(i) Subject and Concern The attributes of a metaprocess are as follows,
The subject of a microprocess is handling iteration (i) Subject and Concerns
whereas the major concern of microprocess is to compare The subject of a metaprocess is line of business whereas
the content and schedule of the process. its major concern is to handle bureaucracy with respect
(ii) Objectives to standardization.
The objectives of microprocess include handling of (ii) Objectives
resources, resolving risks and to complete the process The objectives of a metaprocess include profitability
within the specified time, cost and to achieve required associated with line-of-business along with handling
quality. competitiveness.
(iii) Metrics (iii) Metrics
Micro-process is measured interms of cost, time, current Metaprocess is measured in terms of profitability,
status of the process and scrap/ rework generated during revenue and market share.
iteration. (iv) Audience and Time Scales
(iv) Audience and Time Scales This process is typically monitored by learning
This process is typically monitored by software engineers authorities, end users and management associated with
and junior project managers. It can take a minimum of 1 organization. It can take a minimum of 6 months to a
month and a maximum of 6 months for its completion. maximum of 12 months to complete.
Q34. What are the major activities in the processes 1. The efficiency of the process can be improved by first
of a project? taking an N-step process. The efficiency of each step is
then worked out individually.
Answer :
2. Few steps of an N-step process can be removed resulting
Activities in Project Processes in an M-step process.
Any software project would include sequential and 3. Allocating resources and performing activities can be
parallel steps that are huge in number and are complex. The made more concurrent in an N-step process.
complexity of these steps increases with the scale of the project. The first dimension is often used in most of the
To handle such complexities, the number of overhead steps to be organizations as time-to-market improvement strategies.
added, need to be grow up exponentially. There are two major However, there are other improvement strategies that focuses
activities in the processes of a project, on dimensions 2 and 3. It should be clear that, regardless of
1. Productive Activities the dimension used, the improvement strategy must be able
to obtain a solution that reduces rework, downstream scrap
By carrying out productive activities, the end product
and the number of iterations as much as possible. Among
is obtained directly. The result of these activities are tangible
these obstacles, rework is considered as more challenging and
i.e., the progress towards the end product can become visible.
troubling. The reason being, one rework includes redo of a set
In context of software efforts, the productive activities consists
of tasks. As an example, consider an inevitable situation of
of user documentation, coding, modeling, debugging and
encountering an error in testing after finishing analysis, design,
prototyping.
coding and testing phases. It needs that redo of design, coding
2. Overhead Activities and testing must be performed. Thus, the amount of schedule,
compression can be reduced.
The activities that have many value added efforts, but
are not tangible are known as overhead activities. The tasks that Nevertheless, it is not possible to have rework and scrap
involve such activities are progress monitoring, plan preparation, to be executed in a single iteration in the software development
financial assessment, quality assessment, progress monitoring, process. This can be made possible if the following conditions
documentation, testing, configuration control, management, holds good.
business administration, personnel training and late scrap and (i) The problem description is clear and flawless.
rework. (Late scrap and rework are different from the scrap and (ii) Appropriate solution space is available.
rework of prototyping efforts).
(iii) Sufficient resources are assigned.
The effort that can be devoted to these activities (iv) Skilled and experienced development team is employed.
(productive and overhead) is not equal. The reason being,
(v) Common goals are aimed by all the stakeholders.
most of the tasks like process improvement, try to reduce the
effort in overhead activities and increases it in the productive Q36. How should the team be balanced in different
activities. Resources like computers, personnel and schedules dimensions of human skills?
are allocated largely to the productive activities and less to Answer :
overhead activities, for the process improvement. The personnel skill and experience produces a significant
Training personnels is not considered as an activity in impact on productivity Moreover, the effectiveness of a team is
context of a project. The project manager with a trained team can also decided based on these factors. The two important features
manage his/her work easier than team managed by the untrained of the best team are,
personnel. In the later case, the manager is burdened with training 1. Team balancing
his/her project members. 2. Team coverage.
Q35. Describe the various dimensions of scheduling. As team work is important, a project manager must
How dimensions are helpful in improving maintain a balance between the talented and the skilled people
software economics? that expertise on various aspects of the project. The team
management is based on the following dictums,
Answer :
(i) A project that is carefully managed may eventually
The effort needed to produce a software product is succeed even with a nominal engineering team.
effected by the quality of the software process and in turn by
(ii) A project that is improperly managed can never achieve
the schedule. The cost estimated for a bad process can be 50%
success even with an expert engineering team.
to 100% better than the good one. The reason being, the time
taken by the project members to understand the requirements (iii) A system with a well-defined architecture can be created
of a good process is relatively less than the bad one, which in by a nominal software building team.
turn effects the overall schedule. The three dimensions that any (iv) A system with improper architecture can be ruined even
schedule improvement may have are, when it is created by an expert software building team.
Staffing Principles Q37. What are the skills required for a project
Boehm proposed the following staffing principles for manager? Explain with examples.
building an effective team, Answer :
1. Top Talent Principle Skills Required by a Software Project Manager
The principle of top talent states that “Instead of Software project manager requires leadership qualities
appointing less skilled and greater number of people, appoint for efficient team functioning.
only better and fewer people for the software project”.
The following skills are needed by a successful project
This principle is rarely applied, as the team size is fixed manager,
for most of the projects and any changes made to the team
1. Hiring Skills
size imposes either a very high or a very low pressure on the
individuals. A project manager must have strong hiring skills
2. Job Matching Principle i.e., he must be able to appoint the right person in
the appropriate position. This decision making is a
According to the principle of job matching, the tasks are difficult task.
assigned to the available individuals based on their skills and
motivations. Consider a recruitment process in an organization.
A right candidate is selected from among a list of
With software engineers, it is difficult to differentiate eligible candidates based on his performance in the
the personnel skills and it may sometimes happen that many selection criteria, years of experience, technical skills
individuals are promoted to the positions for which they’re (which can be determined through the aptitude tests
not suitable i.e., they may not possess the required skills, and interviews) etc.
qualifications and motivation.
2. Customer-interface Skills
3. Carrier Progression Principle
A project manager must be able to avoid oppositions
The principle of carrier progression states that, an and rivalries between the stakeholders in order to
organization can work effectively for a long run by cooperating achieve success i.e., he must coordinate and supervise
and helping its people to self-actualize. Organization can the activities of the stakeholders and must also reduce
self-actualize its people by conducting various organizational the conflicts if any, that arise among the stakeholders.
training and project training programs. 3. Decision-making Skills
4. Team Balancing Principle A software project manager must possess a strong
According to the principle of team balancing, the decision making skills i.e., he must be able to take
individuals who can coordinate and complement with one appropriate decisions in critical situations for successful
another must only be selected. completion of the project. For example, the decision
Software team balancing has many dimensions where regarding the team size, role assignment, individual
in balance in any one of them makes a project risky. The recruitment etc., must be carefully taken.
dimensions are, He can also be given with the responsibility to take the
(a) Raw Skills decisions regarding design and testing of the software.
These dimensions include the intelligence, creativity, 4. Team-building Skills
analytical thinking, objectivity and organization. A project manager requires the team-building skill to
(b) Objectives establish trust among the team members, to motivate
The objectives refer to the financial, quality, feature set progress, to eliminate any misfits in the team and to
and time lines. strengthen the diverse opinions into a team direction.
(c) Psychological Makeup Note
This includes leaders and their followers, pessimists, The growth of individual team member is a benefit to
optimists, visionaries and perfectionist, risk takers and the project and organization as the improvement in his
conservatives. skills is effective later in the project.
5. Phaseout Principle 5. Selling Skills
According to the principle of phase out, a misfit on a A successful project manager must sell all the
team will not be beneficial in any way. stakeholders (buyers, developers, users, etc.) based
A misfit in a team enables you to find a better person in on the priorities and decisions taken. He can also
a team and demotivates other team members thereby causing sell the candidates in a particular job position and
an imbalance within the team. achievements against objectives.
Q38. Explain about improving software process and When all these are included in the environment the system
improving team effectiveness. Dec.-19(R16), Q4 will become capable of achieving required quality, estimate cost,
OR time and improve productivity without increasing the team.
The ability of an environment to support recursive
How to improve software processes?
iterative development is referred to as “Round trip engineering”.
(Refer Only Topic: Improving Team Effectiveness) It helps in maintaining automatic consistency in implementation,
Answer : March-17(R13), Q4(a) design and requirements, merely by changing an artifact in
the artifacts set. The remaining artifacts get automatically
Improving Software Processes
modified by moving data efficiently and flawlessly from one
For answer refer Unit-II, Q33, Q34 and Q35. artifact to another which is required when various information
Improving Team Effectiveness repositories are maintained for engineering artifacts. This
process is described by the term called “forward engineering”.
For answer refer Unit-II, Q36, Q37.
Compilers and linkers which accept source code and transits it
Q39. Write short notes on ‘Improving automation into executable code, are the example of software products that
through software environments’. provide such automatic transitions.
Answer : An existing artifact can be used to generate a
The productivity of a software process is linearly effected representation that is more abstract. Such an ability of the
by its environment and tools. Software products are produced by environment, plus the ability to modify the generated artifact
using automation tools like debuggers, editors, planning tools, is referred to as “reverse engineering”. For example, the source
compilers, user interfaces, requirements, management tools, code representation can be used to create a visual design through
quality assurance, analysis tools and visual modeling tools. reverse engineering.
With the help of automation tools an improvement of 20% to Automation of build management and configuration
40% in effort can be achieved. However, the software process control generated new concepts to be included when building,
can be efficiently instrumented and executed by setting support controlling and maintaining large scale components. This need
from configuration management environments. Thus, tools has arisen due to the usage of different languages, platforms and
and environments can be considered as the basics for process components. However, the support from current environments
improvement and automation. is not that much strong.
The important contributions to the environment may be The claims relating to tools in the context of their
either minimizing iterations or number of steps or improving economic improvements enforces that each life cycle activity is
efficiency of some critical steps. Moreover, the selection of a individually assessed by the tool vendors. These claims include,
specific environment is also important. The management control
1. A maximum of 50 % of project resources utilized by the
of the process can be enforced and facilitated by employing
activities associated with testing.
highly integrated environments. To improve the quality,
productivity and speed up the upgrading facilities, tools for 2. A minimum of 30 % of project engineering resources
making the process automatic along with semantic integration utilized by the activities associated with documentation.
are included in the environment. Additionally, flexibility with 3. A minimum of 50 % of the resources gets affected by
respect to iteration and quick turnaround can be included in the activities associated with designing.
systems that have the following abilities, 4. Upto 50 % of the effort associated with software
(i) Automated system building development and schedule are utilized by the unit testing
(ii) Incremental compiling and coding activities.
(iii) Integrated regression testing. 5. In a large scale project, upto 25 % of resources utilized
by the critical activities like change management and
The environment must also include a development and configuration control.
maintenance support among which, the major focus is given to
the development process. Automation in this process include 6. A maximum of 30% of project budgets can be consumed
the following, by progress assessment, project management and
business administration.
v Regression testing
With the above claims, most of projects completion
v Programming tools would utilize 275% of schedule and budget resources. These
v Bug detection claims can also be combined or put together, leading to huge
misconceptions. Such a virtual claim of 275% is highly impossible
v Change management
as the productivity of a project cannot be improved by more
v Documentation than 5% by any individual tool. At the maximum, the tools can
v Requirements management. combinely offer an approximate improvements of 40%.
Q40. Write short notes on, 3. Development risk
(i) Round-trip engineering 4. Schedules
(ii) Forward engineering 5. Target performance
(iii) Reverse engineering. 6. Change management
Answer : 7. Commercial components
(i) Round-trip Engineering 8. Resource adequacy
Generating models from source code and vice versa 9. Software process rigor
is a capability of a software development tool, called 10. Design errors.
“round-trip” engineering. The existing source code can be 1. Requirements Misunderstanding
transformed into a model, applied to software engineering
The modern iterative processes resolve requirements
methods and finally transformed back. In the UML standards,
misunderstanding in the initial stages. However, in
round-trip is a specific model perspective. The full execution
conventional processes, these misunderstandings are
use case in an implemented system has some conceptual
considered in the later stages.
elements covered by round-trip engineering.
2. Automation
(ii) Forward Engineering
Automated and error free procedures are used to develop
The designs that are highly abstract and logical are
the artifacts in a modern process. Manual and error prone
independent of the implementation but can be transformed into
procedures are used in conventional processes.
the system’s physical implementation, using a conventional
process called “forward engineering”. 3. Development Risk
In forward engineering, a software product which The risks related to the development of a modern
is already available is redesigned using platform and new process are determined and resolved in the initial
architecture. This new product covers features like good stages. However, in conventional processes they are not
performance, reliability, recovery etc, along with added identified in the initial stages.
functionalities and characteristics. However, the delivered 4. Schedules
product has same RDD and SRS. The example of forward The schedules in modern processes are flexible enough
engineering includes improvement of a mainframe system and can be modified according to the technology,
to a client-server system architecture, turning a client-server performance and quality. But, in conventional processes,
architecture into a web-based application. the schedules are over constrained.
An example of forward engineering application is the 5. Target Performance
transformation of a conventional system design into an object
Target performance is calculated and analysed on paper
oriented system design.
or in separate simulation. In modern iterative processes,
(iii) Reverse Engineering performance feedback can be received by executing
Analyzing the structure, operation and function of prototypes in the initial stages.
a system, object or a device to discover their technological 6. Change Management
principles is called reverse engineering. It can be performed on In conventional process, change management is done in
software, mechanical devices, integrated circuits/smart cards, the later stages of the life cycle which creates, choose
military applications etc. and affects other entities. In modern process, change
In reverse engineering, the software is decomposed management is carried out earlier and does not affect
into components for a better understanding of its design, others.
architecture and application from various perspectives. This 7. Commercial Components
decomposition reveals the problems, difficulties and areas
Commercial components are not available in conventional
to be improved. It also suggests the use of new platform,
process. In modern iterative process they still serve as
technology, architecture and tools. The software is analysed
an indicator by the trade off that should be resolved in
and with the suggested improvements, it is redesigned to
the initial stages of the software life cycle.
generate a new software with additional functionalities.
8. Resource Adequacy
Q41. List out general quality improvements with a
modern process. The adequacy of resources is not predictable in
conventional process whereas it can be predicted easily
Answer :
in modern process.
The quality improvements associated with the modern
9. Software Process Rigor
software process are,
In the conventional process, software process rigor is
1. Requirements misunderstanding document based and in modern iterative process, it is
2. Automation well managed, measured and tool supported.
10. Design Errors 4. Major milestone demonstrations, makes assessing of
The flaws or errors related to the design are identified artifacts with tangible criteria imposing the need of using
and resolved during initial stages itself in the modern appropriate usecases.
processes, whereas in conventional processes, error 5. The evolution of engineering information from one
identification itself is too late. artifact set to another, so that constraints ingrained in the
Q42. What are the key practices that improve over engineering artifacts can be accessed. These constraints
all software quality? Explain them. are related to understandability, technology, consistency
and feasibility.
(Model Paper-I, Q5(a) | Nov./Dec.-17(R13), Q4))
However, still most of the organizations focus greatly on
OR
formal inspections and meetings. They want the inspections to be
How to achieve require software quality? Explain. carried out across all engineering products, eventhough it is clear
Answer : Nov./Dec.-16(R13), Q5(a) that not all artifacts need such a focused scrutiny but only 20%
of the technical artifacts need such scrutinization. Scrutinization
The following are the key practices that improve the
across all engineering products is a counterproductive approach
overall software quality,
and hence, a process is said to be cost ineffective if its primary
1. Considering driving requirements and critical use quality assurance focuses on inspections. The importance of
cases in the initial stages whereas concentrating on inspections and their high ROI are the wrongly presented issues
requirements completeness and traceability in the later by the quality assurance professionals. They do so, to declare
stages of the life cycle. However, balance between that their discipline is highly sensitive and must be followed by
the requirements evolution, design evolution and plan all organizations.
evolution is considered during all the stages of the
software development life cycle. The above claim can be supported by the ideas of walker
2. Computing the progress and quality of an architecture Royce, a profound software professional, about the importance
using metrics and indicators when it is transformed into of inspections. According to him, the inspections can not
a fully controllable product. provide proper results unless they are focused on a specific
issue. However, most of the inspections are superficial and
3. Providing a unified lifecycle environment that offers don’t generate any design errors. Inspection processes involving
continuous support to configuration control, change
concurrent execution, large number of complex components,
management, document automation and regression test
distributed resources, etc., would require intelligence of world-
automation.
class chess players. Even though such personnels are employed,
4. Employing high level languages and visual modeling to the results from the inspections performed by them would not
allow a better control over architecture, reuse, abstraction, be able to capture the reasons for architectural weaknesses, real
reliable programming and self-documentation. performance bottlenecks or serious control issues.
5. Continuous understanding of several performance issues
The engineering activities at exposed architectural issues
by using demonstration based evaluations.
include,
Q43. Write short notes on peer inspections.
(i) Experimentation, analysis, or prototyping.
Answer :
(ii) Transforming the learned lessons into the plans,
Most of the organizations treat peer inspections to be one
implementations, use cases and models.
of the primary contributors to the quality of a product. However,
this misconception must be eliminated as peer reviews are not (iii) Construction of design models.
that much important. Rather, the following quality contributors
(iv) The current state of the design model is moved to an
are important,
implementation that can be executed.
1. The metrics associated with change management are
important in analyzing the trend changes, divergence or (v) In the context of use case, scenarios and critical
convergence with respect to progress and quality goals. subsets, the strengths and weaknesses of the current
implementation is described.
2. Environment tools are one of the primary contributors
to quality as these make sure that consistency, change An iterative process that produces artifact sets in
control, completeness, representation rigor are done balance, inherently possess the overall quality. Most critical
properly and efficiently. Analyzers, debuggers, automated issues have various checkpoints like inspections and human
test suites and compilers are examples of environment review. However, these are not considered as non-primary.
tools. The designers, developers, testers or anyone who is a part of
3. Life cycle testing, provides a clear understanding of the product evolution, believes that inspections, documents and
requirements compliance, acceptance criteria and critical meetings are not the discriminators of their success, rather they
trade-offs. act as improvers.
However inspections do have significant returns. 4. Capturing Problems before Requirements
1. In a professional development team, the work performed The conventional requirements specification process
by junior team members can be assessed by senior have some issues related to the parameters of the
team members and vice versa. This helps the new problems. As the solution evolves, the tangibility of
team members to easily acquire knowledge about the the problem also arises. The simultaneous evolution
process and gain experience. Every time when the of problem and solution continues till it is sure enough
senior members review the products of junior members, that the problems are clearly understood and can be
the chances of junior members repeating blunders get transformed into production.
reduced. However, this requires that senior mentors 5. Evaluation of Design Alternatives
provide proper feedback to their mentees.
In the water fall model the requirements phase is
2. In addition to this, the products obtained from software
followed by the architecture phase, and the requirements
and documentation authors must also be reviewed.
specification includes the architecture as well. This
Obviously, senior authors review the products of
feature of the waterfall model is quoted in principle #5.
junior authors and vice versa, as a natural by-product
However, the requirement specification and architecture
of the process. Not only formal inspections, informal
of an artifact is performed concurrently. In any modern
inspections can also be made continuously when,
process the architecture and requirement artifacts
(i) Testing is being performed by independent test notations are explicitly decoupled.
teams
6. Using Appropriate Process Model
(ii) Developers are integrating software with the
software of another author or reading the software. A single process cannot be universally accepted.
However, a class of processes can be accepted and is
3. The components that are most critical must be reviewed usually referred by the term process framework.
by experienced and skilled personnels. The reason being,
experienced personnels have clear understanding about 7. Employing Techniques before Tools
the importance of critical components and their reviews. This principle uses two points in a wrong way.
Assuring quality should not be the goal of only quality (i) Automation is one of the best methods of
assurance specialists, rather, it should be a part of all activities. standardizing, promoting and delivering goods.
However, an engineering team must be employed to evaluate (ii) A disciplined software expert with no tools may
and assess the quality of the evolving artifacts. This team should produce less than a disciplined software engineer
not be dependent either on the development team or on the provided with good tools.
architecture team. The activities carried out by the engineering
team members include trend analysis, testing, inspection and 8. Focus on Generating Appropriate Product Instead
change management. of Speeding Up
Most of the software experts misstate this principle as
2.1.4 The Old Way and The New Way “Early performance problems in a software system are
Q44. Explain the principles of conventional software a sure sign of downstream risk.”
engineering. Dec.-19(R16), Q5(a) 9. Code Inspection
OR
Inspections are always overhyped by most of the
Write and explain any ten principles of organizations. Moreover, inspections are not that
conventional software engineering. much suitable, as most of the global design trade-offs
Answer : (Model Paper-II, Q5(a) | Nov./Dec.-16(R13), Q5(b)) and architectural issues are rarely uncovered by the
The conventional software engineering principles are, undirected inspections.
1. Achieving Quality 10. Good Management over Good Technology
The quality of projects cannot be defined as per the This principle is the most motivating principle for most
project and its outset. In the early stages of life cycle, software professionals. However, they disagree with
the modern process framework tries to know the the use of the word “meager”. The phrases “team with
incompatibilities between cost schedule, features and meager quality” and “good management” are mutually
quality. Thus, quality cannot be achieved till these factors exclusive, as per these professionals.
are clearly understood.
11. People are Key to Success
2. High-quality Software
Most of the software professionals comment that the
This principle is redundant with others in most of the
importance given to this principle is less.
situations.
3. Early Product Generation 12. Follow with Care
It might involve rework multiple times because product Most of the modern technologies are not always
is provided to the customer as early as possible. supported if schedules, costs and features are traded off.
13. Understanding Customer Priorities 20. Use of Capturing and Cohesion
The priorities of customers and stakeholders must There exist no clear definitions of coupling and cohesion.
be considered equally. If customer is given more Not only this, coupling and cohesion are difficult to apply
importance, then this misconception becomes the most and measure. Adaptability and maintainability of any
exaggerating one. software can be measured by the amount of coupling
14. The More Users See, The Better They Understand and cohesion and consequently the amount of scrap and
rework.
This principle focuses on hiding the functionality of the
product from the customers. However, it should be stated 21. Use of McCabe Complexity Measure
as “The more users see, the better they understand”. These metrics are rarely used in project management
The reason being, even stakeholders understand. The that is not automated and are suitable only for the ones
in and out of the product and difficulties in meeting the that are automated.
expectations with constrained developers and limited
resources. 22. Don’t Test your Own Software
15. Plan to Throw One Away The software developed by the software developers can
be tested either by themselves or by a separate testing
Avoid this principle and try to avoid evolving a product
from the scratch. Rather, use an immature prototype to team. Each method has its own pros and con.
build a mature baseline. Most of the successful software 23. Analyzing Causes of Errors
projects, use this advice and has proven to be the leading
Error detection is a good idea when there are chances
projects. There are many existing components like GUI,
network, operating system, middleware and DBMS that that errors will repeat in the construction phase. But in
can be used to create new products. complex software systems, analysis of errors is tedious
job. The reason being in the early stages of the project
16. Design for Change itself, the amount of analysis and design is huge. Thus,
This principle says that it is necessary to forecast and performing such activities results in lower ROI. It is
build a framework with the capability of getting updated recommended to make errors in the engineering stage
with the changes that are not yet known. Indeed, it is a and analyze their causes in the production stage.
difficult task, but giving an attempt to it is a good idea. 24. Different Languages in Different Phases
The reason being risk management and a recurring theme
of the successful software projects usually involve such Instead of employing a single language for all phases,
an exercise. use different languages in different phases of life-cycle.
17. Design without Documentation is not Design 25. Reduce the Intellectual Distance
The design and documentation of software are separate The structure of a software made closely related to the
processes i.e., they are separately written. However, such real-world structure thereby reducing the intellectual
a strategy becomes counter productive specially with distance.
high-level programming languages and visual modeling.
Thus, by writing the documents precisely and properly, a 26. Take the Responsibility
better support can be provided to the next phases. Despite A software engineer must take the responsibility of using
of the advantages of documentation, the members of the the best methods for producing the design, ensuring the
engineering team use source code, test baselines, and correct production of software.
design notations, as their primary artifacts.
27. Avoid using the Tricks
This principle is restated by walker Royce as “software
artifacts should be mostly self-documenting.” Avoid using the tricks in program code as it obscure the
required functionality.
18. Use Tools but be Realistic
28. Increase in the Software’s Entropy
According to walker Royce, this principle does not
deserve to be in the list of top 30 principles. The reasons The complexity of the software increases when the
being, complex coding techniques should not be used system is subjected to continuous modifications.
unless there exist equally valid reasons for using them. 29. People and Time are not Substituents
Projects that are nontrivial usually have such compelling
reasons. It is better to use a single metric i.e., person-months
throughout the life cycle.
19. Encapsulation
30. High Expectations
This principle should be given more importance as the
mainstream practice in programming notations, object- The employees must excel their performance in order to
oriented component-based and modern designs . fulfill the expectations of the software manager.
Q45. List out 10 COCOMO II principles of a modern process.

OR
What are the principles of modern software management? March-17(R13), Q4(b)
OR
Explain the top five principles of modern process.
(Refer any Five Principles)
Answer : Nov./Dec.-17(R13), Q5
Principles of Modern Software Process

The top 10 principles of modern software management are based on the principles stated by Davis. These principles are
listed in the decreasing order of their priorities.
1. The process should not commit the resources to full-scale development till the life cycle plans the driving requirements
and the architecturally significant design decisions are adequately balanced. This approach is called “architecture-first”
approach and all processes must be based on this approach.
2. The process should be an iterative one in order to encounter and manage risks at an early stage. This is because modern
systems fail to perform the following tasks,
(i) To give the complete problem definition
(ii) To design the full-fledged solution
(iii) To create the software
(iv) Finally to test the resultant product.
Now-a-days all software systems are complex and sophisticated. Thus, an iterative approach must be used to perform all
the required activities in the life-cycle whenever it is necessary to do so. By this, the objectives of all stakeholders are
balanced and the amount of scrap and rework gets reduced.
3. The amount of custom development and human-generated source code can be minimized if the component-based
development approach is followed. In this approach a collection of already existing lines of code either in an executable
or source format and a well-defined interface and behavior (called a component) are used.
4. Highly controlled baselines are required when the iterative development involves shared artifacts used by different team
members who are working concurrently. Thus, establishing an environment that supports change management.
5. Tools that support round-trip engineering must be used to encourage free flow modifications. Engineering information
in various formats can be synchronized and automated with the help of round-trip engineering. However, it is necessary
to automate documentation, change management and testing in order to minimize the iteration cycles. For establishing an
integrated environment and supporting an iterative process, change freedom is important.
6. Use model-based notations to capture design artifacts. The evolution of semantically strong textual and graphical design
notations is possible through the usage of model-based notations as in UML. Another example is the visual modeling
approach that supports a formal machine-processable language and notations that are far clear and better than design
notations provided by human designers.
7. The process must be instrumented in such a way that progress assessment and objective quality control can be carried
out throughout the life-cycle. Integrating the measures from the evolving engineering artifacts into all teams and activities
are considered as good assessment methods.
8. Assess intermediate artifacts by using a demonstration-based approch. Elimination of architectural defects and integration
convergence at an early stage and a clear and depictable understanding of trade-offs associated with the design, can be
done if the present state of the product is transformed to a demonstration that has relevant scenarios and is executable.
9. The intermediate releases must be grouped into a set of usage scenarios such that with the evolution in each group, the
levels of detail also evolves. Thus, the evolution in project must go with the level of understanding of the architecture and
requirements. The primary method for examining implementations, defining iteration content, and organizing acceptance
testing and requirements, are the cohesive usage scenarios.
10. An economically scalable, configurable process must be established, as each software development needs a specific
process. With such a scalable process, common components and architectural patterns, extensive process automation and
common process spirit can be easily exploited if the process economy of ROI and scale are assured.
Q46. What are the modern process approaches for solving conventional problems?
Modern Process Approaches for Solving Conventional Problems

The risks involved in conventional processes can be solved minimized by using the inherent risk resolution features in the
modern processes. The table below depicts this risk resolution approaches and the attributes that gets effected by the conventional
risks. In the table, S represents schedule, Q represents quality and C represents cost.
Risk in conventional Attribute Inherent Risk Resolution Feature

process effected in Modern Process
v Excessive scrap/rework Q, C, S 1. Architecture - first approach
and late breakage 2. Automated change management
3. Iterative development
4. Risk-confronting process
v Attribute of important or Q, C, S 1. Successful, early iterations.
skilled employees 2. Trustworthy management and planning
v Insufficient development C, S 1. Model-based engineering artifacts
resources 2. Environments as first-class artifacts of the
process
3. Round-trip engineering
4. Industrial-strength, integrated environment
v Adversarial stakeholders C, S 1. Use-case-oriented requirements/testing
2. Demonstration-based review
v Necessary technology C 1. Component-based development
insertion 2. Architecture-first approach
v Requirement Creep C, S 1. Use case modeling
2. Iteration development
v Analysis paralysis S 1. Use-case oriented requirements or testing
v Insufficient Performance Q 1. Early architecture performance feedback
2. Demonstration-based performance assessment
v Overemphasis on artifacts S 1. Objective quality control
2. Demonstration-based assessment
v Insufficient function Q 1. Early prototypes, incremental releases
2. Iterative development.
Q47. What are the process exponent parameters of COCOMO II Model? Also, discuss how they are mapped
to the principles of a modern process.
OR
What is the significance of iterative process? Explain transitioning to iterative process for project
management. (Model Paper-III, Q5(a) | Oct./Nov.-20(R16), Q2)
OR
Describe transitioning to an iterative process.
Answer : March-17(R13), Q5(b) 4. Architecture Risk Resolution
The conventional development process has interdependent An iterative development process becomes successful
stages in which, the completion of one stage effects the next if it uses an architecture first development approach. In this
stage. For this reason, modern development processes use an approach, the architecture is first developed and stabilized and
iterative approach to develop the product. Such a transition from then the application components are developed. The development
conventional waterfall model to an iterative model has many approach that is component-based and architecture-first
benefits. However, there benefits are non-quantifiable. The makes early elaboration of control mechanisms, infrastructure,
process exponent parameters of the COCOMO II model, are the and common mechanisms in the life cycle. Moreover make buy
basis for process improvement. Application precedentedness, decisions of all components are driven into the architecture
team cohesion, architecture risk resolution, process flexibility, process.
and software process maturity are the parameters that effect the
This development approach focus on the following,
value of the process exponent. The range for the exponent is
from 1.01 to 1.26. (i) Ensures demonstration-based assessment and early
A mapping between these parameters and the top 10 testing in the life-cycle by forcing an early configuration
principles of a modern process is given below, and exercise of the development environment.
1. Process Flexibility (ii) Initiates the integration activity early in the life-cycle.
The interrelated concerns and the solution space 5. Team Cohesion

are so huge in the modern software process that the need Teams that are cohesive are successful and vice versa.
for incorporating changes in a continuous fashion is very
There is no clear idea about the source and its effect. Rather,
important. The solution space, plans or problem understanding
may inherently have these changes. Change management that it is clear that cohesive and successful teams have priorities
evolves with project requirements, must be efficient enough to and objectives in common. The difficulties resulted from
support the project artifacts. Projects that are very trivial and the synchronization of stakeholders expectations, acts as the
have changing process does not fail, but the process that changes source for project entropy and turbulence. There sources can
hazardously and rigid tends to fail. In order to achieve software be avoided if the team is a cohesive team. Project turbulence
ROI, it is necessary to use a configurable process across various mainly occurs due to miscommunication, especially when
projects. the engineering information is exchanged through paper
2. Application Precedentedness documents. However, with advanced technology, engineering
A software development project can be planned and information can be exchanged with more understandable and
executed efficiently depending on the domain experience. Lack rigorous notations. This technology support made the paper-
of domain experience leads to involve strong defend against based communication in requirements and design artifacts
risks and evaluation of early precedents. The major reason for more understandable and graphical. Thus, supporting round-
the transition from the conventional to an iterative life - cycle trip engineering in a large way.
process is due to the lack of domain experience. However,
precedents can be established in early stages of the life-cycle 2.2 Life-Cycle phases and process
if the iterations in the process takes place during initial stages.
This leads to elaborations with evolving levels of detail of the artifacts
process, the product, and the plans. 2.2.1 Engineering and Production Stages
3. Software Process Maturity
Q48. Describe the two stages of the life cycle to
Most of the Software process assessments are based achieve economics of scale and higher returns
on CMM (Capability Maturity Model) of the Software
on investment.
Engineering Institute. As exploitation of learned lessons
and available domain sets is highly dependent on domain OR
experience,the exploitation of learned lessons and Software Briefly discuss about engineering stages.
assets of an organization is highly dependent on software (Model Paper-I, Q5(b) | Nov./Dec.-16(R13), Q6(a))
process maturity. Not only this, as domain experience is vital
in avoiding the risks in an application, in the same way, the OR
software development risks can be avoided depending on the Describe the phase of software project
software process maturity. Thus, an integrated environment elaboration. Dec.-19(R16), Q5(b)
that makes the process of objective quality control an
automated one, is needed to enable the mature processes (Refer Only Topic: Elaboration Phase)
truly. OR
Describe the primary objectives, essential Elaboration Phase
activities and primary evaluation criteria of
For answer refer Unit-II, Q49, Topic: Elaboration Phase.
elaboration phase. Nov./Dec.-17(R13), Q6
For answer refer Unit-II, Q50, Topic: Essential Activities
(Refer Only Topic: Elaboration Phase)
in Elaboration Phase.
OR
For answer refer Unit-II, Q51, Topic: Elaboration Phase
Explain about construction phase. Primary Evaluation Criteria.
(Refer Only Topic: Construction Phase) 2. Production Stage
Production stage develop versions of capability
The categorization of project life cycle into various within the plans, requirements and architecture developed
stages is done to achieve economics of scale and yield greater in the engineering stage. This stage comprises of larger
ROI. This typically involves improvements in the process of team, which is responsible for testing, constructing and
manufacturing through component based development and deploying activities. Assessment of software system is carried
automating the process. Initially, the life cycle is categorized out by employing different testing methods. In production
into two phases which are further decomposed into two phases stage, bottom-up approach is preferred as it is necessary to
each. have enough experience and exactness in planning level.
Life-cycle stages In contrast to engineering stage (where the final output
product is architecture baseline) in production stage the final
output product is production release baseline. The only risk
Engineering stage Production stage reduction factor used in this stage is cost.
Construction and transition phases occur in production
stage planning.
Inception Elaboration Construction Transition
Construction Phase
Figure: Life-cycle Stages For answer refer Unit-II, Q49, Topic: Construction Phase.
1. Engineering Stage Construction Phase Essential Activities
Engineering stage develops the plan, define the The essential activities of the construction phase are,
requirements, design the architecture of the software system
1. Managing and controlling resources and optimizing the
by solving many development risks. This stage comprises
process.
of smaller team which is responsible for designing and
performing composite activities. Assessment of software 2. Completing component development and component
system is carried out by demonstration, inspection and testing with respect to the evaluation criteria.
analysis. In engineering stage, top-down project-independent 3. Estimating the product releases against the vision
planning guidelines are converted into project-specific or acceptance criteria.
project dependent planning guidelines. So, that they can be
used further as global assessment methods. The purpose of For remaining answer refer Unit-II, Q51, Topic:
Construction Phase Primary Evaluation Criteria.
employing, top-down approach is because of the difficulty
in understanding the software system and the insufficiency Transition Phase
of stability in task sequences. The following are the two risk
For answer refer Unit-II, Q49, Topic: Transition Phase.
reduction factors used in this stage.
(i) Schedule Transition Phase Essential Activities
(ii) Technical feasibility. 1. It performs deployment-specific engineering which deals
Inception and elaboration phase are carried out in with the training of the field personnel, commercial
engineering stage. packaging and production etc.
Inception Phase 2. Synchronizing and combining the concurrent construction

increments into uniform baseline of deployment.
For answer refer Unit-II, Q49, Topic: Inception Phase.
For answer refer Unit-II, Q50, Topic: Essential Activities 3. Evaluating the deployment baselines against the
in Inception Phase. acceptance criteria and the vision.
For answer refer Unit-II, Q51, Topic: Inception Phase For remaining answer refer Unit-II, Q51, Topic:
Primary Evaluation Criteria. Transition Phase Primary Evaluation Criteria.
2.2.2 Inception Phase, Elaboration Phase, Q50. What are the essential activities in inception
Construction Phase,Transition Phase and elaboration phases?
Q49. What are the primary objectives of the four Answer :

phases of software life-cycle? Essential Activities in Inception Phase
OR (i) Developing the Scope of the Project
Write the primary objectives of construction and It refers to the process in which information such as
transition phases. acquiring of the requirements and operational concept
(Refer Only Topics: Construction Phase, Transition is added to the information repository (i.e., it describes
Phase) the requirements according to the user’s view), which is
Answer : Nov./Dec.-16(R13), Q7(a) enough to determine the problem space and acceptance
Primary Objectives of the Software Life Cycle Phases criteria to generate the final product.
1. Inception Phase (ii) Producing the Architecture
(i) To demonstrate the scope of the software and It involves designing and evaluation of trade-offs,
boundary conditions along with the acceptance uncertainties in problem space and solution-space
criteria, operational concept and the details
components. An information repository is built, that
of things to be included and excluded while
determines the feasibility of one or more candidate
developing the software product.
architecture in such a way that the cost, schedule and
(ii) To determine the cost and schedule for the entire
resource estimates can be extracted.
project.
(iii) To evaluate potential risks. (iii) Planning and Creating a Business Case
(iv) To verify one or more candidate architecture, During this activity, other possibilities to carryout tasks
dedicated to carryout primary sequence of events like the risk management, iteration phase, staffing and
(scenarios). trade-offs between cost, schedule and profitability
(v) To separate the critical use cases and the primary are determined. The necessary tools, processes and
scenarios of the system’s operation. automation support for the development task are also
2. Elaboration Phase identified.
(i) To create a quick baseline architecture in such Essential Activities in Elaboration Phase
a way that all changes can be monitored and (i) Vision Elaboration
maintained.
It refers to the process of capturing the critical use cases
(ii) To create a baseline vision. with high precision to handle architectural or planning
(iii) To describe how the base line architecture can decisions.
be achieved with the vision created, within the
(ii) Process and Infrastructure Elaboration
scheduled cost and time.
In this activity, the construction process, tools,
(iv) To baseline a high-fidelity plan to be used in the
automation support, evaluation criteria are established.
construction phase.
(iii) Architecture Elaboration and Component Selection
3. Construction Phase
(i) To reduce the cost incurred in the development phase Potential components are estimated along with the
usually by making optimum use of the available decisions to determine the effective cost and schedule
resources and by avoiding the unnecessary rework. for the construction phase. The selected components
are then combined and evaluated against the primary
(ii) To quickly obtain the desired quality.
scenarios.
(iii) To quickly obtain the useful versions such as alpha,
Q51. How do you evaluate the completion of each of
beta tests etc.
the four phases in software life-cycle?
4. Transition Phase
Answer :
(i) To obtain self-supportability for the user.
1. Inception Phase Primary Evaluation Criteria
(ii) To attain stakeholder concurrence in such a way
that, the deployment baselines be complete and (i) Checking whether all the stakeholders agree on
consistent with the vision evaluation criteria. the scope definition, cost and schedule estimates.
(iii) To attain fast and cost-effective baselines for the (ii) Verifying that the actual resources spent according
final product. to the planned expenditures.
(iii) Determine whether the estimates of cost and schedule, priorities, risks and the development processes are conceivable
or not?
(iv) Determining whether the requirements are captured as confirmed by the dependability of the critical use cases or
not?
(v) Whether the depth and breadth of an architecture prototype evaluates the preceding criteria.
2. Elaboration Phase Primary Evaluation Criteria
(i) Determining whether the architecture and vision are stable or not?
(ii) Verifying that the actual resources spent according to the planned expenditures and determine whether they are
acceptable?
(iii) Whether all the stakeholders concur on the meeting of the current vision, when executing the current plan for
developing the complete system within the scope of the current architecture?
(iv) Does the construction phase plan provides enough reliability and does it backed up with a reasonable basis of estimate?
(v) Does the executable demonstration shows the addressing and reasonable solutions for resolving of the major risk
elements?
3. Construction Phase Primary Evaluation Criteria
(i) Whether the product baseline is fully-developed to be used in the user community or not?
(ii) Whether the product baseline is sufficiently stable to be used in the user community?
(iii) Does the stakeholders agreed to be transformed into the user community?
(iv) Verifying that the actual resources spent according to the planned expenditures and determine whether they are
acceptable?
4. Transition Phase Primary Evaluation Criteria
(i) Verifying that the actual resources spent according to the planned expenditures (or) not and determine whether they
are acceptable?
(ii) Does it achieve user’s satisfaction?
2.2.3 Artifact Sets
Q52. Define artifact sets. Explain various types of artifact sets.
Answer :
Artifact Set
The software development can be made manageable by organizing unique sets of information into artifact sets. These sets
consists of the corresponding artifacts which are persistent and are in a standard representation format. Basically, an “artifact”
is a collection of cohesive information which is gathered and examined as a single entity. On the other hand, the representation
for the entire aspect of a system is known as “set”. Some artifacts and sets may not be essential in an organization, project or a
system. Generally, every set must contain some information for satisfying the needs of all stakeholders.
Types of Artifact Set
The lifecycle software artifacts are arranged in the following five distinct sets. These sets are divided by considering the
basic set language.
(i) Management Set
This set consists of the representation of adhoc textual information.
The process planning and execution related artifacts are typically associated with the management set. These kind of
artifacts use ad hoc notations such as text, graphics or the notation required for capturing the “contracts”. These are used
by stakeholders, project personnel or both.
(ii) Requirement Set
This set consists of text and models associated with the problem space.
(iii) Design Set
It consists of models belonging to the solution space.
(iv) Implementation Set
It consists of human-readable programming language and their related source files.
(v) Deployment Set
It consists of machine processable language and their related files.
Earlier, the engineering notations were evolved as a major technology for the requirements and design artifacts. These
artifacts are the ones that support architecture-first development. Particularly UML has been emerged with a relevant notation
called visual models, using well-defined semantics and syntax for both requirements and design artifacts. The traditional life-cycle
artifacts uses visual modeling along with UML which is considered as a primitive notation.
S.No. Artifact Sets Artifacts
1. Requirements set (i) Vision document
(ii) Requirements model (s)
2. Design set (i) Design model (s)
(ii) Test model
(iii) Software architecture description
3. Implementation set (i) Source code baselines
(ii) Associated compile-time files
(iii) Component executable
4. Deployment set (i) Integrated product executable baselines
(ii) Associated run-time files
(iii) User manual
5. Management set Planning Artifacts
(i) Work breakdown structure (activity breakdown and
financial tracking mechanism)
(ii) Business case (cost, schedule, profit expectations)
(iii) Release specifications (scope, plan, objectives for release
baselines)
(iv) Software development plan (project process instance)
Operational Artifacts
(i) Release descriptions (results of release baseline)
(ii) Status assessments (periodic snapshots of project
progress)
(iii) Software change order database (descriptions of
discrete baseline changes)
(iv) Deployment documents (cutover plan, training course,
sales rollout kit)
(v) Environment (hardware and software tools, process
automation, documentation, etc.)
Q53. What is meant by artifact sets? Discuss about the engineering sets.
Answer : (Model Paper-II, Q5(b) | Nov./Dec.-17(R13), Q7))
Artifact Sets
Engineering Sets
The basic way employed for analyzing the changing quality of every individual artifact set is the transitioning of information
between the sets. Because of this, an understanding stability is maintained among the following artifacts,
1. Requirements set
2. Design set
3. Implementation set
4. Deployment set.
Each of the elements present in the engineering set are (iii) Performing a detailed inspection on variations that exist
described below, among current and previous version of design model.
1. Requirements Set (iv) Estimating the completeness and consistency among
The vision statement is created using structured text. information that exist in various sets by transforming it in
This statement provides project supporting the agreement made terms of implementation, deployment sets and notations.
between the funding authority and the project team. In addition (v) Intuitive examination of other quality dimensions.
to this, adhoc format can also be used for creating descriptions
of supplementary requirements. The requirements are 3. Implementation Set
represented using text and picture models or other prototypes. The implementation set comprises of the following,
The requirements set is considered as the essential engineering
information which is used for analyzing the remaining three (i) Source Code
artifact sets. It is also treated as a fundamental set for test cases. This code signifies the tangible component’s
Requirement artifacts are analyzed, assessed and implementation.
quantified using the following combinations, (ii) Executable
(i) Consistency is analyzed along with the release The executable are required for performing independent
specifications associated with the management set. component testing. These are considered as an essential
(ii) Consistency that exists among vision as well as part while constructing the end product involving
requirements models is analyzed. the custom components, APIs associated with the
(iii) Associating in accordance to the remaining three artifact commercial components.
sets (i.e. design, implementation and deployment) in It is possible to compile and link (i.e. translate) the
order to analyze the consistency, completeness and the implementation set artifacts into the deployment set. Certain
semantic stabilization among the information available
artifacts consists of,
in the different sets.
v Self-documenting product source code baselines and
(iv) The changes taking place among existing versions
associated files.
of requirements artifacts and the current versions are
analyzed. v Self-documenting test source code baselines and
(v) Intuitive examination of other quality dimensions. associated files.
2. Design Set v Independent component executable.
Usually, solution is generated using the design models, v Component test driver executable.
which are represented in terms of UML notations. The design Implementation sets are usually in human understandable
set comprises of different abstraction levels that are of varying format that are analyzed, assessed and quantified by using the
length. These levels of abstraction signifies the solution space following combinations,
component. The solution space consists of the identities,
attributes, static relationships and dynamic interactions of (i) Analyzing how consistent the system performs with the
components. Sufficient amount of structural and behavioral design model.
information is made available in the design model. (ii) Converting the implementation set into deployment
Generating subset from this information is typically set notations in order to analyze the consistency and
a straight forward procedure and can be automated easily. completeness between various artifact sets.
The generated subset associated to artifacts of design set and
(iii) Assessing the executable files or component source in
implementation. Certain design set artifacts comprise of the
accordance to the significant evaluation criteria. This is
following: design model, test model and software architecture
description. done by inspection, analysis, demonstration or testing.
The design set artifact is analyzed, assessed and (iv) Executing the independent component test cases that
quantified by using the following combination, automatically perform the comparison between expected
results and actual results.
(i) Performing a detailed examination on quality and
consistency of design model. (v) Analyzing the variations that arise between the current
(ii) Performing a detailed examination on consistency of version of implementation set and its previous version.
requirements model. (vi) Intuitive examination of the other quality dimensions.
4. Deployment Set (b) Requirement Notations
The deployment set comprises of the following, These are used by the requirement set artifacts so as
to represent the engineering information as well as the
v User deliverable and machine language notations operational concept. The requirements set notations
v Installation scripts include the structured text and the UML models.
(c) Implementation Notations
v Executable target specific data
These are used by the implementation set artifacts so
v Executable software as to represent the building blocks of the solution in
such a way that it is easily understandable by a human.
v Build scripts.
The implementation set notations generally include
The above components are required so as to utilize the the software languages.
product in its corresponding target environment. The machine (d) Deployment Notations
language notations signify the product components available These are used by the deployment set artifacts so as
in the target form for the purpose of performing distribution to represent the solution in such a way that it is easily
to users. Information associated with the deployment set can understandable by a machine. The deployment set
be installed, executed in accordance to the usage scenarios. It notations include the executables as well as the data files.
is also possible to dynamically reconfigure the information in Every individual artifact set represents the primary
order to support the features necessary while developing the development focus associated with the single phase of software
end product. Certain artifacts consists of associated run-time life cycle. The other sets are responsible to verify and stabilize
files, user manual and executable baselines. the roles.
Deployment sets are analyzed, assessed and quantified

by using the following combinations,
(i) Testing in accordance to the scenarios of use and even
according to the quality attributes included in the
requirements set, in order to analyze the consistency,
completeness and the semantic stabilization that exists
among the information available in the two sets.
(ii) Testing the strategies relative to partitioning, replication
and allocation which are used in associating the
components belonging to the implementation set to the
physical resources belonging to the deployment system.
(iii) Testing in accordance to the usage scenarios available Figure: Focus on Artifact Sets During the Project Life Cycle
in the user manual like installation, mainstream usage, In the above figure, every life cycle phase has a primary
user specific dynamic reconfiguration and anomaly focus. The primary focuses of inception phase, elaboration
management. phase, construction phase and transition phase are requirements,
design, implementation and deployment respectively. However,
(iv) Analyzing the variations that arise among the current the management set carry a constant level of focus throughout
versions of deployment set and its previous versions. the life cycle.
(v) Intuitive examination of the other quality dimensions. Many of the modern software development tools relate
closely to one of the following five artifact sets,
The artifacts must be selected in such a way that the 1. Management
presentation of the process activities, artifacts and its objectives This artifact set consists of the following development
are optimized. Every individual artifact set makes use of tools,
different notations so as to represent the applicable artifact. v Workflow
v Defect tracking
(a) Management Set Notations
v Change management
These are used by the managements set artifacts so as v Documentation
to represent the plans, objectives, process and even v Resource management
the acceptance criteria. The management set notations v Presentation tools
include the adhoc text, graphics, and use case notations. v Spreadsheet.
2. Requirements
This artifact set includes the requirements management tools.
3. Design
This artifact set includes the visual modeling tools.
4. Implementation
This artifact set includes the following,
v Compiler/debugging tools
v Code analysis tools
v Test coverage tools
v Test management tools.
5. Deployment
This artifact set includes the following,
v Test coverage and test automation tools
v Network management tools
v Commercial components
v Installation tools.
Q54. Explain the artifacts of the design set.
Answer :
Artifacts of the Design Set
The design set consists of three artifacts. They are,
(a) Design model
(b) Test model
(c) Software architecture description.
(a) Design Model
The artifact named ‘design model’ is an object model that describes the realization of use cases and is capable of serving
as an abstraction of the implementation model along with its source code. The design model can be used in the form of input for
the required activities that are performed in the software development life cycle phases (i.e., implementation and test).
Software architect plays a very crucial role in the development of design model because they ensure the integrity of the
model. The main purpose of this model is to plan as well as document the design process of software system.
Design model is a comprehensive as well as composite artifact that consist of the components including (i) Design classes,
(ii) Subsystems (iii) Packages (iv) Collaborations and (v) Relationships between all these components. Apart from planning the
architecture, it acts as a vehicle for performing analysis during the elaboration phase. This analysis is then refined by detailed
design decisions during the construction phase.
(b) Test Model
The artifact named ‘Test model’ is the basic application of the design model. This model is used for designing and executing
the required artifacts so as to perform software testing. This sort of testing is carried out by developing a model which provides
necessary information about all aspects of the testing data which includes test cases and the test execution environment. Generally,
the test model is developed fully or partially using a model which provides the documentation regarding certain functional aspects
of the system to be developed .
This model of system description provides an abstract and partial presentation of the system which is being tested. A
set of test cases called “Abstract test suite” is developed so that the test cases can be functionally tested at the same abstraction
needs to be level as that of the model. Since, the abstract test suite is present on an incorrect abstraction level, it is not possible to
directly execute it against the system being tested. Due to this drawback, an “executable test suite” needs to be developed from
the abstract test suite which is capable of communicating directly with the system under test. This communication is carried out
by selecting the best suited concrete test cases and mapping them with the abstract test cases.
(c) Software Architecture Description
The artifact named “Software Architecture Description” of a system is the collection of structures which are required to
provide information regarding the systems such as software elements, relationship among the elements and properties of both.
This artifact also provides a detailed documentation covering the architecture overview of the system. This is typically created
during the elaboration phase by considering different architectural views so as to illustrate different aspects of the system.
The architecture enables communication between software architect and other project team members so that, they can
exchange information regarding architecturally significant decisions made about the project.
Q55. Differentiate between management set and engineering set.
Answer :
Management Set Engineering Set

1. The artifacts related to process planning and 1. The remaining life cycle software artifacts other than
execution are present in the management set. execution artifacts are arranged in four distinct sets and are
included in the engineering set.
2. Evaluation is done through stakeholders by analyzing 2. The basic way employed for analyzing the changing quality
the changes between the progress of current and of every individual artifact set is the transitioning of
previous version of artifacts. information between the sets.
3. These artifacts use adhoc notations such as text, graphics 3. These artifacts use notations such as structured text, UML
or the notation required for capturing the “contracts” models, software languages, executables and data files.
among project personnel, among stakeholders and
between project personnel and stakeholders.
4. Artifacts of management set are distributed among 4. Artifacts of engineering set are requirement set, Design set,
planning and operational artifacts. Implementation set and Deployment set.
5. The management set notations are used to represent 5. Requirement notations are used to represent engineering
plans, objectives, process and acceptance criteria. information as well as the operational concept.
Implementation notations are used to represent building
blocks of the solution in the understandable way for human.
Deployment notations are used to represent the solution in
an understandable way for machine.
6. The management set artifacts remains constant 6. The requirement set, design set, implementation set
across the entire software life cycle. and deployment set artifacts are the focus of inception,
elaboration, construction and transition phases of life cycle
respectively.
Q56. Explain about life cycle evolution of the artifact sets.

Answer :
Artifact Evolution Over the Software Life Cycle
Every development state of the system signifies some level of accuracy in the description associated with end product.
During the initial stages, representation and precision are high and low respectively. However, the precision of representation
gradually becomes higher when the process proceeds. All five sets i.e., requirements, design, implementation, deployment and
management will be in distinct states at any phase but they can easily provides information usually regarding their location to
each other. During the initial stages, this information along with consistency typically provides decreased ROI but increases when
the process proceeds towards final stages. The major concerns as the development proceeds are,
(i) Architecture stabilization and
(ii) Maintenance of traceability linkage among various artifact sets.
A specific artifact set is entirely focused by every stage in the development lifecycle. This approach makes the life cycle
development of the entire system state to be completed on all the artifact sets as shown in the below figure.
Requirements Requirements
Design
Management
Management
Design
Implementation Implementation
Deployment Deployment

Figure (a): Life-cycle Evolution of the Figure (b): Life-cycle Evolution of the
Artifact Sets During Inception Phase Artifact Sets During Elaboration Phase
Requirements
Requirements
Design
Management
Design
Management
Implementation Implementation
Deployment Deployment

Figure (c): Life-cycle Evolution of the Figure (d): Life-cycle Evolution of the
Artifacts Sets During Construction Phase Artifacts Sets During Transition Phase
The following are the phases in the artifact evolution.
1. Inception phase
2. Elaboration phase
3. Construction phase
4. Transition phase.
1. Inception Phase
The primary focus of this phase is on requirements which are important. The secondary focus is on the design of deployment
set. Next, implementation set is also focused excluding language choice and commercial components. Also, the architecture of
design set is focused to some extent.
2. Elaboration Phase
In this phase, the requirements and design sets are focused in detail. Also, the implementation set and the issues related
to deployment (such as make/buy analyses and performance trade-offs) are focused. The tasks performed in the elaboration
phase contains the creation of an executable prototype, which include the development subsets present in all the four sets.
The consistency and completeness of the interfaces and collaborations between various components are determined by the
executable prototype. This is done within the context of critical requirements and scenarios of the system. Though the component
interfaces are specified in detail, the implementation set for custom components are not clearly defined. Before generating
the baseline of an architecture, some part of all four sets must be developed up to some extent. This development requires the
design, implementation and deployment sets assessment so that project can be allowed to be developed further.
This phase focuses on only the design and implementation sets. The design artifacts, design analysis in source code and
all the components (that are tested) are specified in detail. In this phase, the requirements, design and implementation sets almost
get completed. By an alpha or beta mechanism, at least one or few programmed system instances can be tested.
4. Transition Phase
This phase focuses only on obtaining deployment set consistency and completeness. This is done within the context of all
the four sets. The residual errors that exists in the transition phase activities get resolved and the alpha, beta and system testing
provides a feedback.
Hence, as the development of the system progresses, every part of it is evolved in detail. When the entire system gets
evolved, there exists consistency and completeness in all the four sets. When compared to the conventional development process
wherein the requirements are not specified, the current development process changes the complete system that may include
decisions regarding the deployment leaving an impact on the Instead of using distinct sequences of test and design
system requirements. Therefore, it is essential to fragment documents, all the four sets notations and techniques are
the conventional mold in such away that one fragmented set used for the engineering artifacts. With the use of some
is preceded by the other set. A state of the complete system adhoc notations, some different formats, some ambiguity and
changes into a more detailed system state which generally higher efficiency, the activities such as stakeholder reviews,
involves evolution in every individual part of the system. interpersonal communications and engineering analyses can
During the evolution of the transition phase, traceability be accomplished.
should exists between the requirements and deployment sets. The assessment workflow has various aspects
The requirements set describes the acceptance criteria of the including testing, analysis, inspection and demonstration.
stakeholders whereas the deployment set describes the actual Testing is considered as a detail evaluation which is
end-user product. Hence, completeness and consistency should performed by executing the deployment set components
exists between these sets. Traceability between the other sets along with the expected and objective outcome. This
needs to considered until it helps in facilitating the engineering evaluation is performed within a controlled scenario. The
or management activities. expected outcome and the objective are compared along with
the well-defined mathematical precision. This comparison
Q57. Explain in detail about test artifacts. helps in the determination of a successful test. Tests are
Answer : Nov./Dec.-16(R13), Q6(b) similar to the assessment automated forms.
Test Artifacts The following example determines how test artifacts

and the other artifacts sets are related to each other. For the
In conventional software testing, document-driven use of oil exploration, seismic data processing is performed
technique was adopted. Before generating source files or by a project. This system consists of the following three
executable files, the requirements documents, top-level design subsystems,
documents and detailed design documents are constructed by
v Sensor subsystem
the development teams. Similarly, before generating test drivers,
stubs or test activities, the system test plan documents, system v Technical operations subsystem
test procedure documents, integration test plan documents, v A display subsystem.
unit test plan documents and unit test procedure documents
are constructed by the test teams. Both test and development The raw seismic data is collected by the sensor subsystem.
activities have similar problems which are caused by the This data is passed to the technical operations subsystem wherein
the raw data is transformed into a database which is arranged
document-driven approach.
in an organized way. For this database, the queries passed from
For a modern process, the sets, notations and artifacts a display subsystem gets handled by a technical operations
that are used for product development activities are also applied subsystem. Now, the seismic data is examined in a human-
to the product test activities. The test process is executed as readable form.
an important part of the end product. This execution is done The following test artifacts are obtained from the above
basically by identifying the test infrastructure. Due to this, the system.
following engineering constraints are used in the process.
1. Management Set
(i) The test artifacts and the product must be originated
simultaneously from the inception phase through An intermediate milestone’s objectives, evaluation
deployment set. Hence, testing refers to a full life-cycle criteria and results are collected by the release descriptions and
release specifications artifacts. These artifacts are referred to
activity instead as a late life-cycle activity.
as test plans and test results which resulted from the internal
(ii) The test artifacts must be engineered, communicated and project teams negotiation. The closure criteria (that exists from
developed in the same way as they developed product. a baseline change) and the test results (such as requirements
These are done within the same artifact sets. ambiguities, enhancements and testability changes) are
collected by the change order database artifacts associated
(iii) The test artifacts must be implemented similar to that of
with the software.
the software programs. This implementation is done in
programmable and repeatable formats. 2. Requirements Set
(iv) The test artifacts must be documented as that of the The operation concept (which is used for the system)
products. and the acceptance test case descriptions (containing the
system’s expected behavior and quality attributes) are captured
(v) The test artifact developers must use the tools, techniques by the system-level use case artifacts. As requirements set is
and training which are similar to those that are used by the primary use for all the assessment activities in the life-
software engineers while developing products. cycle, it is considered as a test artifact.
3. Design Set v The performance of some allocation strategies like
This set captures a test model, which is used for the dynamic load balancing, centralized versus distributed,
nondeliverable components so that the product baselines can hot backup versus checkpoint/ rollback.
be tested. These components consist of the following, v The constraints associated with virtual machines such as
(i) Design set artifacts which are considered as file descriptors, heap size, garbage collection, disk file
a seismic event simulation which is used for rotations.
generating the realistic sensor data. v The issues associated with process-level concurrence.
(ii) A visual operator that provides support to v The difference (in behavior or performance) associated
unattended after-hours test cases. with platform-specific technology.
(iii) A collection of specific instrumentation which is
The above configuration information must exists either
used for the early resource usage demonstration. in the implementation set or in the deployment set. This
(iv) Transaction rates or response times. information is considered as an essential engineering source data
(v) Test drivers such as stand alone test drivers of information. In case of portable components or reconfigurable
components and use case test drivers. systems, the concerns related to source code implementation
must be separated from the concerns related to the target
4. Implementation Set
environment. This separation is because of the performance,
The test drivers and the test components use similar source dynamic adaptability or source code change management
code representations as that of the test scripts and test procedure factors. The separation approach is used to decouple the
files. These kind of source files may consist of human-readable implementation from the actual platform type and from the
data files which are used for the representation of some specified underlying computing infrastructure’s number and topology.
data sets. These sets are explicit test source files. The test drivers This computing infrastructure consists of middleware, networks,
generate certain output files which are similar to that of the test operating systems and DBMSs.
reports. For example, a project consisting of software architecture
5. Deployment Set along with the requirements for data processing performance
This set provides executable versions of test drivers, data and fault tolerance is considered. On this project, a single source
files and test components. set can build the following executable file configurations.
For release description or release specification, similar 1. A version which involves only the primary thread of
baseline version identifier used to maintain all the product processing is included on the development host inorder
artifacts and test artifacts. These two artifacts are changed, to perform some specific scenario tests.
created and obsolesced in the form of a single constituent unit. 2. A version which involves the primary and backup threads
As similar notations, tools and methods are used to capture the of processing is included on the development host
test artifacts. The approach used for testing is also same with inorder to perform some specific logical reconfiguration
the design and development phases. This approach helps in the scenarios.
maintenance of the evolving test artifacts so as to perform the
3. Similar versions of the above two configurations that are
regression testing automatically.
executed on the target processors help in the assessment
Q58. Distinguish between implementation set and of the critical-thread throughput and response time
deployment set. scenarios.
Answer : March-17(R13), Q7(b) 4. A version that includes the following,
As implementation set and deployment set have their (i) A primary thread of servers which is executed on
own concepts, the differentiation of these two sets is essential. a single target processor.
The information framework that is given to the user is entirely
different from the source code information framework. Because (ii) A shadow thread of servers which is executed on
of the engineering decisions, there exists an impact on the a unique backup target processor.
deployment set quality. The engineering decisions that are (iii) A test/exercise thread which is executed on target
difficult to be understood contain the following. processor.
v The parameters such as color palettes, number of servers (iv) A set of thread-independent user interface clients
and simultaneous clients, buffer sizes, data files, etc. that which are executed on user workstations. A wide
are dynamically reconfigurable. range of dynamic reconfigurations are supported
v The effects such as the space optimization versus by a set of thread-independent user interface
the speed optimization associated with compiler/link clients, which were considered as the final target
optimization. configuration.
The test and deployment related configurations are separated by using the deployment of commercial products, which are
provided to the customers. Here, consider an example where the products related to middleware provide the following,
v High performance
v Efficient object request brokers which are delivered on distinct platform implementations along with bare embedded
processors, workstation operating systems, many real-time operating systems and large mainframe operating systems.
The configurations related to product support several compilers, languages and network software implementations. The
separation of different target configuration results are used for the distinct deployment artifacts structure and for the advanced
source code structure.
2.2.4 Management Artifacts

Q59. Explain about the management artifacts.
The management artifacts obtain intermediate results and contain information necessary to document the product/process
legacy, improve the process and product, and maintain the product. The management artifacts are categorized into two classes as
follows,
I. Planning artifacts
II. Operational artifacts.
I. Planning Artifacts
The following are the planning artifacts of a management set,
1. Business case
2. Software development plan (SDP)
3. Work breakdown structure (WBS)
4. Release specifications.
1. Business Case
This artifact provides some information which is used to determine whether investing in the project is beneficial or not.
The business case artifact includes the expected cost, expected revenue, backup data, technical and management plans so that the
risks and realism associated with plans can be demonstrated in detail. In case of large projects, full-scale proposal with lots of
information stored in it is used to implement the business case artifact. Whereas for small projects, only a brief plan along with
the corresponding spreadsheet is required. The basic goal of the business case artifact is to convert the vision into economic terms
so that a correct ROI assessment can be generated by an organization. The financial forecasts are evolutionary and are updated
in the later stages of project life cycle. Figure below represents a business case outline,
Context (domain, market, scope)
Technical Approach
1. Feature set achievement plan
2. Quality achievement plan
3. Engineering trade-offs and technical risks
Management Approach
1. Schedule and schedule risk assessment

2. Objective measures of success
Evolutionary Appendixes
1. Financial forecast
(i) Cost estimate
(ii) Revenue estimate
(iii) Bases of estimate
estimates
Figure: Business Case Outline
2. Software Development Plan (SDP) 3. Work Breakdown Structure (WBS)
This artifact provides a more detailed plan about the This artifact is useful for collecting and budgeting the
process framework. The document used for the process of project costs. The software project manager should have the
the project is defined by SDP. If any contract or organization knowledge about the project costs and their expenditure. The
standards exist then DSP must match with it. All subordinate cost related structure is considered as an important constraint
of project planning. If WBS is structured in an incorrect way,
organizations use a similar SDP for the software development.
then the structures related to design and product might also
It (SDP) evolves along with the evolution of design and
get evolved improperly. A specific level of stability must be
requirements. It is said to be useful if,
obtained in the structure of product. After achieving this, the
(i) It updates periodically project manager should design the lower levels of WBS. The
software entirely depends upon WBS hence, if a functional
(ii) It helps managers and practitioners in understanding
breakdown exists in WBS, then the software also gets effected
and acceptance. thereby generating a functional breakdown in it.
Figure below represents a software development plan 4. Release Specifications
outline,
Each baseline release uses the plan, objective and
Context (scope,objectives) scope evaluation criteria of the project development. These
features are obtained from the vision statement and from
Software Development Process the other sources like risk management concerns, make/buy
analyses, quality thresholds, architectural considerations
1. Project primitives etc. These artifacts are evolved in accordance to the process
(i) Life-cycle phases development, thereby achieving consistency and requirements
(ii) Artifacts understandability throughout the life cycle. Figure below
(iii) Workflows represents the release specification outline,
(iv) Checkpoints
2. Major milestone scope and context
Iteration Content
3. Process improvement procedures
Measurable Objectives
Software Engineering Evironment 1. Evaluation criteria
2. Follow through approach
1. Process automation (hardware and software
resource configuration)
Demonstration Plan
2. Resource allocation procedures (sharing across
organizations, security access) 1. Schedule of activities
2. Team responsibilities
Software Change Management
Operational Scenarios (use cases demonstrated)
1. Configuration control board plan and procedures
2. Software change order definitions and procedures 1. Demonstration procedures
3. Configuration baseline definitions and procedures 2. Traceability to vision and business case
Software Assessment
Figure: Release Specification
1. Metrics collection and reporting prodecures
Requirements consists of the following two basic forms,
2. Risk management procedures (risk identification,
tracking and resolution) (i) Vision Statement
3. Status assessment plan
4. Acceptance test plan There exists a contract between the buyer and the
development team. This contract is captured by the
Standards and Procedures vision statement and the related information must be
1. Standards and procedures for technical artifacts evolving and changing as the life cycle progresses. The
information must be represented in an adhoc (including
Evolutionary Appendixes
use cases, mockups, text, spreadsheets) or in some other
1. Minor milestone scope and context
formats such that it can be easily understandable to
2. Human resources (organization, staffing plan,
training plan) the buyer. The vision statement context contains a use
case model which is used for capturing the operational
Figure: Software Development Plan concept that is understandable to the user/buyer.
(ii) Evaluation Criteria Q60. Explain the operational artifacts of a management
The evaluation criteria present in the release specifications set.
are considered as transient snapshots of objectives Answer :
associated with the specified life-cycle milestone. Operational Artifacts
Instead of defining as the part of the requirements set,
The following are the operational artifacts of a
the evaluation criteria are defined as the management
management set,
artifacts. They are obtained from the vision statement
and also from the other sources like risk management 1. Release descriptions
concerns, make/buy analyses, quality thresholds, 2. Status assessments
architectural considerations etc. These requirements
3. Software change order database
(which are management-oriented) are represented with
the help of uses cases, use cases realizations, annotations 4. Deployment documents
on use cases, etc. 5. Environment.
The vision statement captures the system requirements 1. Release Descriptions
that are related to user/buyer. Instead of using the lower level The results of every release along with performance
component, iteration is used so as to organize the process. against the evaluation criteria (that exists in their release
This process uses the lower levels of requirements, which specifications) are explained by the release description
are represented in the form of evaluation criteria. Hence, the documents. Release baselines must be available along with
following examples (used for a large project) helps in evolving release description document which defines the evaluation
the lower level of requirements. criteria for a specific configuration baseline. It also provides
(a) Inception Iterations substantiation which specifies that the evaluation criteria is dealt
in an acceptable manner.
The driving issues related to some specific use cases are
The document must contain a metric summary which
captured by 10 to 20 evaluation criteria. These use cases
provides a detail description about its quality measurement.
are the ones that effect architecture alternatives and the
The quality is measured in relative and absolute terms.
complete business case.
The post-mortem review results are documented, which
(b) Elaboration Iterations contains the following outstanding issues: follow-up actions,
If 50 or more evaluation criteria are represented against recommendations for process and product improvement, and
the candidate architecture, then a verification is done in trade-offs in addressing evaluation criteria. Figure below
order to check whether some important requirements represents the release description outline,
and use cases are encountered with minimal risk or not.
Context
(c) Construction Iterations
1. Release baseline content
When some hundreds of evaluation criteria (related to 2. Release metrics
a meaningful group of use cases) are passed, the major
(useful) subsets of the product (that can be converted to Release Notes
formal test or alpha or beta releases) can be constituted
in the form of a complete set. 1. Release-specific constraints or limitations
(d) Transition Iterations

Assessment Results
Some thousands of evaluation criteria and the complete
set of use cases are used to constitute the acceptance test 1. Substantiation of passed evaluation criteria
criteria which belongs to the deployment of a version 2. Follow-up plans for failed evaluation criteria
into operation. 3. Recommendations for next release
Basically the above process is evolutionary and is Outstanding Issues

constituted to the actual evolving design and architecture. At the
end of the process, 100% traceability becomes a major factor and 1. Action items
2. Post-mortem summary of lessons learned
the intermediate milestones and activities of life-cycle are not
involved with the completeness and consistency. As iteration’s
evaluation criteria are considered as the transient artifacts, they Figure: Release Description
are removed when the milestone gets completed. Both release 2. Status Assessments
specification artifacts and their associated evolution criteria The status assessments provide the following,
have more attention on resolving the risk issues.
(i) Periodic snapshots related to project health and status
II. Operational Artifacts
(ii) Risk, assessment, quality indicators and management
For answer refer Unit-II, Q60. indicators of software project manager.
The forcing function continues to work even if 4. Deployment Documents
the period may change. The main aim of an efficient A deployment document can have various forms,
management process is to confirm that all the stakeholders
(i) Based upon the project, a deployment document may
expectations are synchronized and consistent. The periodic
consist of various document subsets, which are used to
status assessment documents supply some mechanisms convert the product into operational status.
which are used for the following,
(ii) In case of large contractual projects, the system is delivered
(i) Managing the expectations of all the stakeholders to a unique maintenance organization. Here, the deployment
across the life cycle artifacts may consist of software installation manuals,
computer system operations manuals, plans and procedures
(ii) Communicating, addressing and resolving the issues for cutover etc.
related to management, technical and project (iii) In case of commercial software products, deployment
(iii) Capturing the history of project. artifacts may consist of sales rollout kits, training courses
and marketing plans.
Certain status assessments should contain a review of
5. Environment
the following,
The environment of development and maintenance
(i) Resources phases should be considered as the first-class artifact. The
(ii) Technical progress like metrics snapshots development process automation must be supported by a
development environment which is integrated and robust in
(iii) Financial data such as cost and revenue nature. This type of the development environment must consist
(iv) Action items of the following,
(i) Requirements management
(v) Total project or product scope
(ii) Host and target programming tools
(vi) Major milestone plans and results.
(iii) Visual modeling
The following must be included in a project, (iv) Document automation
(i) Open communications (that are persistent) (v) Automated regression testing
and objective data obtained from the on-going (vi) Feature and defect tracking
activities. (vii) Continuous and integrated change management.
(ii) Evolving product configurations. For successful completion of software projects, it is
necessary for an organization to hire people with excellent
3. Software Change Order Database
skills and provide them with necessary tools using which these
Managing change in software is considered as people can accomplish their respective tasks. The software
the basic primitive of an iterative development process. development automation provides the following,
As greater changes can be done freely in a project, more (i) Payback in quality
iterations can be performed by it. This flexible nature will
(ii) The ability to evaluate costs and schedules
relatively increase the project’s quality, content and number
of iterations. With the help of automation, the change freedom (iii) Complete productivity using a smaller team.
can be acquired and the work load of change management can The integrated tool sets have great impact in both iterative
also be handled by the iterative development environments. and incremental development processes. This is because of the
Certain organizational processes are based upon the change designers who traverse among various development artifacts
management techniques that are performed manually. These and also update them.
processes deal with some major inefficiencies. The change
2.2.5 Engineering Artifacts and Pragmatic
management data have been increased upto a first-class
management artifact. This artifact is represented as a database Artifacts
so that the concept for automation can be introduced. All Q61. What are engineering artifacts? Explain.
changes done in a software should be formally identified and Answer : Nov./Dec.-16(R13), Q7(b)
managed when placed in a controlled baseline. The metrics The following are the three engineering artifacts present
collection, change management bureaucracy and reporting in software project management.
activities can be operated automatically by,
1. Vision document
(i) Maintaining change records on-line and 2. Architecture description
(ii) Automating data entry. 3. Software user manual.
1. Vision Document (i) Better understanding and refinement of scope
This artifact gives a complete vision which is used for (ii) Assessment of design mode integrity and
the software system under the development life-cycle. It also (iii) Evolvement of acceptance test procedures.
supports the contract that exists between the development
organization and the funding authority. Each project needs the The contractual basis is used for the requirements that
sources so that the expectations among various stakeholders can are visible among various stakeholders.
be captured. This does not depend upon the nature of the project 2. Architecture Description
whether it is small or large, internally funded (or) commercial This artifact provides a structured representation of the
product. As knowledge about the requirements, architecture, software architectural view which is done under development.
plans and technology are explained in detail, the project vision is
Usually the architecture description is obtained from the
required to be changed. A vision document that changes slowly
design model. It consists of various views related to design,
is said to be an efficient document. Figure below represents a
implementation and deployment sets. These views help in
vision document outline,
the determination of how the operational concept related to
requirements set will be accomplished. Based on many factors,
Feature Set Description
each project has different breadth of the architecture description
1. Precedence and priority which is done by using any one of the following,
Quality Attributes and Ranges

(i) A subset of design model
(ii) An abstraction of design model along with supplementary
Required constraints content
1. External interfaces (iii) Both (i) and (ii).
Evolutionary Appendixes 3 Software User Manual
1. Use cases This artifact provides a reference documentation to the
(i) Primary scenarios user so that the software which is delivered is supported. Though
(ii) Acceptance criteria and tolerances the content in the manual changes across various application
2. Desired freedoms (potential change scenarios)
domains, the software user manual should contain the following
at minimum: installation procedures, operational constraints,
Figure: Vision Document
usage procedures and guidance and a user interface description.
Depending upon the user’s perspective, the vision When software products along with a user interface are used,
document is created. Two things are focussed while preparing the user manual should be developed at the beginning of the life
the vision statement. cycle because it is considered as an important mechanism for
(i) Basic features of system. both stabilizing and communicating a major requirements subset.
(ii) Acceptance levels of quality. Instead of the development team members, test team members
are used to generate the software user manual. These members
The following must be present in the vision document, are the one who easily understand the user’s points of view.
(i) The first appendix should provide a detail If the user manual is generated by the test team then it can be
description about the operational concept using evolved parallely along with development. Hence, user manual is
the use cases. considered as a real and significant perspective of the evaluation
(ii) The second appendix should provide a detail criteria. It also provides a basic support for the following,
description about the change risks that are present (i) Test plans and test cases and
in the vision statement. It provides guidelines for
(ii) Automated test suites construction.
the defensive design efforts.
Q62. Explain pragmatic artifacts of software project
The vision document must contain a detail specification
management.
of what features are included and also those features that are
considered but not included. The operational capacities (such as Answer :
accuracies, response times, volumes), interoperational interfaces Documents were considered as the major requirement
along with entities present outside the system boundary and user for the process. This is because of the following two reasons.
profiles are specified wherever necessary. The initial operating
v No rigorous engineering methods or languages exist
level does not contain the vision statement. This statement is
for the requirements specification or design because of
an evolution path that should be addressed in such away that
which graphical representations and paper documents
a context is available for the design adaptability assessment.
The operational concept contains the specification of use cases along with adhoc text were treated as the default format.
and scenarios, which are used for both nominal and off-nominal v The conventional languages of implementation and
purposes. The representation of use cases provide a dynamic deployment were highly complex to understand and
context and it is used for the following, structure.
An efficient format that is easily understandable by a online. The paper documents are forced to be exchanged
human was required inorder to submit the software structure and by certain organizations. With the help of some
its behavior details to the reviewers such as managers, testers standardized languages, visualization tools and the web,
and maintainers. The software progress at various stages must all stakeholders can feasibly exchange information. If the
be assessed or judged properly. The documents description is other stakeholders doesn’t accept the above approach,
tangible but adopts an incorrect mechanism for describing the then the efficient software development process can get
software progress. corrupted.
The quality related to the documents is important (iii) People should use rigorous engineering notations
when compared to the quality of the engineering information (which are consistent, complete and used in a self-
the documents represents. The quality evaluation process is documenting way) for reviewing the artifacts. Every
done by reviewing the abstract descriptions of the document. identifier and description must be written using proper
This process is considered as an efficient subjective process. English words acronyms and abbreviations when
However, much effort is needed for the following, needed. The programming or modeling language
(i) The assessment of issues related to single-dimensional source identifiers can be abbreviated and encrypted
surface. without any reason. The artifact author’s job can
be reduced by saving the keystrokes, which is done
(ii) The minimum focus given to the issues related to
through abbreviation. However, this may lead to errors
multi-dimensional surface. These issues drive certain
that may remain throughout the life cycle. If this
architecture qualities like performance and adaptability.
practice is not permitted to be used, then both quality
More visible and formal snapshots of software progress and productivity gets effected. The practice helps for
are introduced into schedule by review cycles, document generating the following,
production cycles and update cycles. This helps in generating
(a) Understandable representations
more synchronization points and schedule dependencies.
For managing schedules and synchronizing large, multiple (b) More rigorous notations
document review cycles, five-year development life cycles are (c) Browseable formats and
required so as to finish these type of projects. The documents
(d) Reduced error rates.
that are represented in detail are identified so as to demonstrate
an increase in progress. But, this would result in the following (iv) The self-documenting engineering artifacts are
issues, developed so that the development organization works in
the engineering notations. Also, the separate documents
(i) Unproductive engineering details
that are used for describing the details of component,
(ii) An increase in scrap and model or test procedure are avoided. If a document
(iii) Rework during the later stages of project life-cycle. that is being generated is not used, then eliminate it
by considering the requirements which are used in its
The above documentation effort is redirected to a better
completion.
understandability of the information source and with the use
of browsing and navigation tools, online review is performed (v) Once the paper documents are delivered, they become
on the native information source. This approach eliminates a static, persistent and tangible. Hence, they are preferable
large, ineffective source of scrap and reworking. Also, every by some stakeholders. Although online and web-based
person related to the evolution of online artifacts, reviews the artifacts have many advantages, they suffer from the
information. However, this will generate the following issues, following limitations,
Culture Issues in Pragmatic Artifacts (a) They are easy subjected to change and
(i) People need to review information but the artifact’s (b) They are volatile in nature. The other artifacts
language might not be understandable. As artifact provide an assurance that tools and environments
is written in the engineering language, most of the are evolved so as to support audit trails, electronic
reviewers try to learn this language. Hence, the reviewers signatures, change management, etc. This will
should have the knowledge about the engineering make the electronic artifacts to replace the existing
notations. But, the learning capability will increase cost paper documents.
and time of the process. The paper on which the information of the document
(ii) People need to review information but do not have the is written, is not essential but the information present in the
capability to access tools. The development organization artifact is essential. Long documents are not useful as short
is not fully tooled and only some of stakeholders have documents. The documentation is certainly a support material
the capability of reviewing the engineering artifacts whereas software is considered as the fundamental product.
(ii) Architecture description communicates in such
2.2.6 Model-based Software Architectures a way that how indefinite concept is achieved in
Q63. Define software architecture. Mention two definite artifacts.
perspectives of architecture and explain them. All of the above aspects are required as architecture varies
OR from one form to another across distinct system domains. For
Explain about model-based architecture in a instance, software architecture for an airtraffic controller is very
management perspective. different from small development tool software architecture.
2. Technical Perspective
(Refer Only Topic: Management Perspective)
The software architecture describes the structure of
Answer : March-17(R13), Q6
software systems. It also represents the behaviour and the
Software Architecture patterns which guide the elements of the system.
It is defined as design of a complex software system. The framework of a software architecture is defined in
Modern complex software systems are embedded with multi- terms of views.
programs with different models and views in order to make View
efficient use of modern technologies.
An architecture view is referred to as abstraction of
Software Architecture Perspectives design model that contains only architectural information.
The two perspectives of a software architecture are, Generally, systems require four views. They are,
1. Management Perspective (a) Design view
2. Technical Perspective. (b) Process view
1. Management Perspective (c) Component view
The three different aspects of software architecture from (d) Deployment view
a management perspective are as follows,
(a) Design View
(a) An architecture
v It describes the architecturally significant elements
(b) An architecture baseline of the design model which include structures and
(c) An architecture description. functions.
(a) An Architecture v It is required to be included in every system
It is an indefinite design of software system which v Design view is modeled in two ways.
includes the following, (i) Statically
(i) All engineering requirements to specify entire It is modeled using class diagrams and object
material bills. diagrams which are called as structural
(ii) Important make/buy decisions are solved. diagrams.
(iii) All custom components are clearly explained so (ii) Dynamically

that the cost of each component and construction/ It is modeled using any of UML behavioural
assembly costs can be determined. diagrams (collaboration, sequence, state
(b) An Architecture Baseline chart, activity diagram).
(b) Process View
It is a definite aspect of software architecture. It is a
subset of information across engineering artifact sets v Process view describes runtime collaboration
so as to satisfy all stakeholders with respect to function issues like logical software network topology (i.e.,
and quality within the business case parameters like cost, process allocation threads of control), interprocess
time, profit, etc. communication and concurrency that arises when
the architecture is executed on a distributed
(c) An Architecture Description deployment model.
It is a representation of software architecture in a v Process view is modeled in two ways,
human-readable form. It acts as a component of an
architecture baseline. It is also considered as a view (i) Statically modeled using deployment
as it is a subset of information from design set models. diagrams (structural diagram)
It includes, (ii) Dynamically modeled using any of the
(i) Supplementary adhoc notations like text and UML behavioural diagrams (collaboration,
graphics required to simplify the process of sequence, statechart, or activity diagrams).
understanding the model information. v This view is necessary in any distributed system.
(c) Component View 1. Realisation of Stable Software Architecture
v It describe those elements of implementation A valuable project in which important make/buy
set that are architecturally significant. This view decisions are solved, leads to the path of achieving stable
addresses the software source code realisation of software architecture. In this, phases are involved through a
system from the view point of project integrators software life cycle. Generally, a software life cycle defines
and developers. This is done in regard to the the stage transitions to understand the basic activities and
releases and configuration management. characteristics of software.
v Component view is modeled in two ways, For instance, human life cycle defines the basic activities
(i) Statically modeled using component diagrams and characteristics of human during their progression.
(structural diagram). So, the change of stages that go through software life
(ii) Dynamically modeled using any of the UML cycle are represented by starting from engineering project stage
behavioural diagrams (collaboration, sequence to production stage.
or activity diagrams). (i) Engineering Project Stage
v For instance, custom and commercial component This stage is defined by detecting and solving many
system requires the component view. unknown problems.
(d) Deployment View (ii) Production Stage
v It describes those elements of the deployment set This stage is defined and planned by management in
that are architecturally significant. order to have expected development in software.
v The elements of deployment set consists of 2. Balancing Trade-offs
executable realisation of system including. Balancing trade-offs are basically provided by software
(i) Logical Software Topology architecture representations and these are done between two
factors.
It deals with allocation of logical processes in
distribution view. (i) Problem space
(ii) Physical System Topology (ii) Solution space.
It deals with physical resources of deployment Problem space includes requirements and constraints,
network. whereas solution space includes the operational product.
Generally problem space carries the definition of solution space.
So, deployment view addresses the allocation of logical
3. Encapsulation of Architecture and Process
software topology to physical system topology.
Most of the important (high-risk) communication
Deployment view is modeled in two ways,
channels among individuals, organizations, teams and
(i) Statically modeled using deployment diagrams stakeholders are encapsulated by the architecture and process.
(structural diagrams). These factors plays a vital role through good communication
(ii) Dynamically modeled using any of the UML in developing a software.
behavioural diagrams (collaboration, sequence or 4. Project Failure Reasons
activity diagrams).
There are two factors which leads to failure of project.
Q64. Explain the significance of software architecture They are,
in modern software development process.
(i) Poor architectures
Answer :
(ii) Immature processes.
Role of Software Architecture in Modern Software
(i) Poor Architecture
Development Process
If the architecture or structure of a software system is
Software architecture plays a crucial role in modern poor in nature, eventually it will have great impact on
software development process. The significance of software total architecture of software.
architecture is as follows,
(ii) Immature Processes
1. Realisation of stable software architecture.
This can also be called poor software proces as it involves
2. Balancing trade-offs (exchange as part of some factors like,
compromise)
(a) Not following the specified software process.
3. Encapsulation of architecture and process.
(b) No objective for judging product quality.
4. Project failure reasons.
Immature processes are unmanageable, uncontrollable,
5. Prerequisites for expected planning. ineffective, inconsistent in nature which leads to poorness of
6. Architecture development and process definition. an organisation’s software process.
5. Prerequisites for Expected Planning Elaboration of design model and test model components
The important prerequisites for expected planning are, is done by developing the baseline architecture and baseline
design set artifacts like names, attributes, structures, behaviors,
(i) A Mature Process
grouping in order to demonstrate against evaluation criteria
This is also called as rich software process. It includes allocated to this iteration.
factors like,
3. Implementation Set
(a) Disciplined process
For answer refer Unit-II, Q57, Topic: Implementation Set.
(b) Consistent process
(c) Expected process New component development and existing component
enhancement is done to demonstrate the evaluation criteria
(d) Optimizing the process.
allocated to this iteration. All new components and modified
These factors lead to richness of an organisation’s components are combined and tested with existing baseline.
software process. This set basically include all the primitive components like
(ii) Understanding Primary Requirements source component inventory and bill of materials.
Primary requirements include functions, performance, 4. Deployment Set
design constraints, quality attributes etc.
For answer refer Unit-II, Q57, Topic: Deployment Set.
(iii) Demonstrable Architecture
Q66. Explain an organized and abstracted view of the
The architecture of a software should be demonstrable architecture into the design models.
in such a way that it can meet the needs of predictable
planning. Answer :
6. Architecture Development and Process Definition Organized and Abstracted View of the Architecture into
(i) Architecture development and process definition are the Design Models
the two improving steps which provides solution to a Software Architecture
problem without breaking the constraints of a software. For answer refer Unit-II, Q63.
(ii) They require manual methods.
Requirement Design Implementation Deploy ment
Hence, software architecture plays a significant role in
modern software development process.
Q65. State the heuristics that describe objectively an
architecture baseline.
Design Compon ent
Answer : model
model
Architecture Baseline
Usecase
For answer refer Unit-II, Q63, Topic: An Architecture model
Baseline.
Process Deploy ment
From iterative development perspective, an architecture model model
baseline is considered as a partial realization associated with the
architecture description. This level of realization is sufficient for
providing tangible evidence, which are used to verify whether
the architecture is valid or not. That is, it is constructed in Design Componen
Component
accordance to the requirement and planning specifications. A view view
state in which a project is said to achieve a stable architecture
baseline is resulted when transition occurs from engineering Usecase
view
stage to production stage. The level of information required in
engineering set is dependent on the situation. The following are Process Deployment
few heuristics which are included while describing objectively view view
an architecture baseline.
1. Requirement Set
For answer refer Unit-II, Q57, Topic: Requirements Set.
In this set, the baseline plan, architecture and requirements Architecture
set artifacts are analyzed. This analysis is done in order to Description
Document
elaborate and evaluate use cases objective associated with
system level quality that are to be demonstrated at the end of
this iteration. Figure: Organized and Abstracted View of the Architecture
2. Design Set The figure summarizes the design set artifacts that consist
For answer refer Unit-II, Q57, Topic: Design Set. of architecture view and architecture description.
Architecture View
An architecture view is referred to as abstraction of design model that contains only architectural information. In addition
to this information, design models even provide the information about the design of the component internal to the architecture
and information about the functional concurrency, implementation and execution structure.
The different design models in a software architecture are,
(i) Usecase model
(ii) Design model
(iii) Process model
(iv) Component model
(v) Deployment model.
The first three models define the logical as well as the behavioral aspect of the design, whereas component and deployment
models defines the implementation and deployment set respectively.
The different architectural views in a software architecture are,
1. Use-case View
It describes the way of performing use-case realization by using the elements of the design models. Use-case view is
modeled in two ways,
(i) Statistically
It is modeled using use-case diagrams.
(ii) Dynamically
It is modeled using UML behavioral diagrams.
2. Design View
For answer refer Unit-II, Q63, Topic: Design View.
3. Process View
For answer refer Unit-II, Q63, Topic: Process View.
4. Component View
For answer refer Unit-II, Q63, Topic: Component View.
5. Deployment View
For answer refer Unit-II, Q63, Topic: Deployment View.
Architecture Description
For answer refer Unit-II, Q63, Topic: An Architecture Description.
Architecture description can be of many forms that ranges from simple description to complex description.
1. Simple Description
Such description represents direct subset of UML diagrams, which is used by small and experience team members while
constructing a development tool.
2. Complex Description
It represent different types of views that captures the requirements of a complex software system. Such description is
generally used while developing large-scale control system.
Important Questions
Short Question
1. What is meant by late risk resolution? Refer Q1

2. What are the major components of software cost? Why? Refer Q4
3. What are five staffing principles? Refer Q7
4. What are the phases of the life-cycle process? Explain. Refer Q9
Essay Question
5. Explain waterfall model. Refer Q13
6. Explain about improving software process and improving team effectiveness. Refer Q38
7. Write short notes on ‘Improving automation through software environments’. Refer Q39
8. List out 10 COCOMO II principles of a modern process. Refer Q45
9. Describe the two stages of the life cycle to achieve economics of scale and higher returns on investment. Refer Q48
10. Define software architecture. Mention two perspectives of architecture and explain them. Refer Q63
Unit-3 Workflows and Checkpoints of Process, Process Planning 3.1
Unit
Workflows and Checkpoints of Process,
3
Process Planning
SI
A GROUP
Syllabus
Workflows and Checkpoints of Process: Software Process Workflows, Iteration Workflows, Major Milestones, Minor
Milestones, Periodic Status Assessments.
Process Planning: Work Breakdown Structures, Planning Guidelines, Cost and Schedule Estimating Process, Iteration
Planning Process, Pragmatic Planning.
Learning Objectives
 The Various Workflows such as Software Process Workflows and Iteration Workflows
 Milestone and its Categories
 Periodic Status Assessment and its Need
 Definitions of Work Breakdown Structure and its Evolution
 The Various Planning Guidelines
 Iteration Planning Process and Pragmatic Planning
Introduction
Workflow can be defined as a sequence of cohesive activities. Workflows are carried out in four phases
which include inception, elaboration, construction and transition phases. A milestone can be defined as
a planned or organized event used to measure the progress of a project. The milestones are sometimes
called as ‘inch-pebbles’.
Work breakdown structure can be defined as a document of scheduled tasks for completing the project
within the given time. The project planning includes missions and objective selection and actions to achieve
these goals and also requires decision making for an effective plan. It can be considered as one of the
management functions. The two different perspectives of project plan include top-down approach and
bottom-up approach.

Q1. Define iteration. What are the functions of iteration?
Answer : Model Paper-III, Q1(e)
Iteration
Iteration is defined as a sequential distribution of activities depending on the position of iteration in development cycle.
Functions of Iteration
v Each iteration is represented as a collection of allocated frameworks (or) structures.
v In order to implement all selected frameworks, the required components are developed and combined with the results of
previous iterations.
Q2. List the functions of major checkpoints.
Answer : Model Paper-II, Q1(e)
The following are the functions of major checkpoints,

(i) Major checkpoints aim at long-term plans of the entire software project globally.
(ii) These are carried out at the end of each development phase.
(iii) Deals with issues related to system.
(iv) Other functions include achieving the synchronization between engineering and management perspective and verifying
the achievement of aims in various life cycle phases.
(v) At the end of each phase, major milestone or major checkpoints use formal, stakeholder approved evaluation criteria and
release descriptions.
Q3. Define product release milestone.
Answer : March-17(R13), Q1(g)
Product release milestone appears at the end of transition phase. The main objective of this milestone is the assessment
of software completion along with its transition in order to support organization. Also, software quality metrics are reviewed to
identify whether the quality is enough for transition. It deals with the similar issues as in initial operational capability milestone
i.e., descriptive versions of software, manuals for user and operator, manuals that support software, installation instructions,
development environment installation at support sites.
Q4. Who are stakeholders? List them.
Answer : (Model Paper-I, Q1(e) | March-17(R13), Q1(h))
Stakeholders
The people who are interested or have stake (share) in the project are referred to as stakeholders. They must be determined
during the initial phases due to the following reasons,
(i) To easily communicate with them throughout the project development life cycle.
(ii) To know the stakeholder’s degree of involvement in the project.
Categories of Stakeholder
Stakeholders can be any one of the following,
(i) Part of a Team (Internal)
Here the stakeholders are directly controlled by the project leader.
(ii) Part of the Organization (Internal to the Organization and External to the Project)
The project leader will consult different departments of an organization to facilitate organizational tasks.
For example,
(a) Project leader will contact the customers or users in order to facilitate system testing.
(b) Project leader can update the database by consulting the information management group.
(iii) Totally External to the Project as well as to the Organization
There are two types of external stakeholders.
(a) Customers
Customers are the beneficiaries of the system that are implemented by the project.
(b) Contractors
Contractors are the stakeholders who hold the responsibility for the development of project.
Q5. Write short notes on integration and installation activities of software project management.
Answer :
Integration
With completion of coding and testing of each software unit, various software components are brought together as a whole
and then tested to check whether they satisfy the software requirements. Integration is done at the software level and at the system
level. During software-level integration, integration of various software components takes place. At the system level, software
components of the system along with other system components like user procedures, hardware platforms etc., are integrated.
Installation Activities of SPM
After performing qualification testing on the new system, it is time to bring the system into action. This involves,
(i) Establishing relevant parameters for the system.
(ii) Software installation into various hardware platforms.
Q6. Write brief notes on major milestones in software process. Dec.-19(R16), Q1(f)
OR
Write brief notes on major milestones.
Answer : (Model Paper-II, Q1(f) | Nov./Dec.-17(R13), Q1(h))
Major Milestones
Major milestones are referred as System Wide Events as they mainly focus on the entire software project issues associated
with the system. Major milestones are considered as one of the sequences of project checkpoints, that are processed in software
life cycle.
Sequence of Major Milestones in Software Life Cycle

Phases of
life cycle Iteration (1) Iteration (2) Iteration (3) Iteration (4) Iteration (5) Iteration (6) Iteration (7)
Four Major
1. Life cycle 2. Life cycle 3. Initial operational capability 4. Product
Mile stones
objectives architecture milestone milestone release
milestone milestone
Figure: Phases of Life Cycle and Major Milestones

(i) In the above sequence, each of the phases i.e., inception, elaboration, construction and transition consist of atleast one
iteration, ending with a major milestone or occurs at transition points between the phases of the project life cycle.
(ii) The event that moves the project from elaboration to construction phase is considered as the important major milestone.
(iii) Major milestones are divided into four categories as mentioned above,
1. Life cycle objectives milestone
2. Life cycle architecture milestone
3. Initial operational capability milestone and
4. Product release milestone.
Q7. What is WBS?
Answer : (Model Paper-III, Q1(f) | Nov./Dec.-16(R13), Q1(f))
The definitions of work breakdown structure are as follows,

1. Work breakdown structure is defined as a document of scheduled tasks for completing the project within time.
(or)
2. A work breakdown structure is a hierarchical representation of the project plan which is divided into separate work tasks.
(or)
3. The subdivision of entire project defined tasks that can consume resources is referred as work breakdown structure.
A good work breakdown structure which is synchronized with the process structure is one of the critical factors for the
success of a project.
4. A work breakdown structure is also defined as breaking down of higher-level tasks into a set of lower-level tasks.
A work breakdown structure provides following information as,
v Description of important work.
v Task breakdown for assigning responsibilities.
v Underlying structure for scheduling, budgeting and expenditure tracking.
Q8. Explain cost estimation process.
Answer : Dec.-19(R16), Q1(e)
Bottom-up approach is one of the cost estimation processes. The planning sequence for the bottom-up approach is as
follows,
(i) WBS element manager estimates the budget and schedule for the detailed lowest level WBS elements. These estimates
are then included in the project specific parameters.
(ii) Next sequence is combining and integrating estimates into higher level budgets and intermediate milestones. The individual
estimators need to have same preferences for a consistent discussion.
(iii) Last sequence is to compare top-down budgets and schedule milestones and if any differences exist then they are orderly
adjusted and estimated to meet the point of convergence (Between topdown and bottomup estimates).
Q9. What are the responsibilities of SEEA?
Answer : Nov./Dec.-16(R13), Q1(g)
Software Engineering Environment Authority (SEEA) is responsible for the organization process automation, keeping the
organizations standard environment, training projects etc. Tools, techniques and training can be implemented effectively, only if
SEEA is responsible for supporting and monitoring the standard environment.
Q10. Discuss about initial operational capability milestone.
Answer : (Model Paper-I, Q1(f) | Nov./Dec.-17(R13), Q1(g))
Initial Operational capability milestone appears at the end of construction phase. It deals with issues like descriptive ver-
sions of software, manuals for user and operator, installation instructions etc.
The main objective of this milestone is the assessment of immediate use of software inorder to move into user/customer
sites and authorization for acceptance testing. These two goals are briefly discussed as follows,
(i) For the sufficient transition quality, software quality metrics are reviewed.
(ii) Acceptance testing is allowed to test the software which can be done incrementally across various iterations or can
be performed, as a whole during the transition phase.
3.1 Workflows and checkpoints of process

3.1.1 Software Process Workflows
Q11. Define workflow. Explain about software process workflow.
Answer :
Definition of Workflow
Workflow is defined as a sequence of cohesive activities. Workflows are categorized into seven top-levels as follows,
1. Functions of Management Workflow
(a) Process control
(b) Ensuring positive condition for all stakeholders.
2. Functions of Environment Workflow
(a) Process automation
(b) Gradual development of maintenance environment.
3. Functions of Requirements Workflow
(a) Problem space analysis
(b) Development of requirements artifacts.
4. Functions of Design Workflow
(a) Solution designing
(b) Development of design artifacts and architecture.
5. Functions of Implementation Workflow
(a) Programming the component
(b) Development of implementation and deployment artifacts.
6. Functions of Assessment Workflow
(a) Assess trends in process
(b) Assess product quality.
7. Function of Deployment Workflow
Ship the end products to the user.
Q12. What levels of activity take place in these workflows during each of the four phases (inception,
elaboration, construction and transition)?
OR
Illustrate the relative activity levels across the life cycle phase.
Workflows are carried out in four phases.

1. Inception
2. Elaboration
3. Construction
4. Transition.
The purpose of these phases refer to the project state (or) position.
Activity Levels
Activity levels represent one of the key signatures of modern process framework. The figure shows the expected activity
levels across the life-cycle phases in each of the top-level workflows,
Figure: Activity Levels Across the Four Life-cycle Phases

The levels of activity in workflows during each of the life-cycle phases are as follows,
1. Management Workflow
Phases Activity Levels
Inception Preparation of business case and vision
Elaboration Development of plan
Construction Controlling and observing development
Transition Controlling and observing deployment
2. Environment Workflow
Inception Development environment and change
management infrastructure are defined.
Elaboration Development environment is installed and
change management database is established.
Construction Maintain development environment.
Transition Transition maintenance environment.
3. Requirements Workflow
Inception Define concept of operation
Elaboration Define goals of architecture
Construction Define goals of iteration
Transition Improve release objectives
4. Design Workflow
Inception Define concept of architecture
Elaboration Get architecture baseline
Construction Component designing
Transition Improve architecture and components
5. Implementation Workflow
Inception Support prototypes of architecture
Elaboration Architecture baseline is produced
Construction Complete components are produced
Transition Maintain components
6. Assessment Workflow
Inception Assessment of prototypes, plans and vision
Elaboration Assessment of architecture
Construction Assessment of temporary releases
Transition Assessment of releases
7. Deployment Workflow
Inception Examine user groups
Elaboration User manual definition
Construction Preparation of transition materials
Transition Ship end products to user
The above figure shows the expected activity levels across the four phases of the software development life-cycle.
1. Architecture-first Approach
In this approach, comprehensive requirements analysis, design, implementation and assessment activities are carried out
before the construction phase, when full-scale implementation is the primary concern. The implementation and architecture
testing occurs prior to the full-scale development and components testing. It must also occur before focusing on completeness
and product quality.
2. Iterative Life-cycle Process
As shown in figure, each life-cycle phase depicts at least two iterations of each of the seven workflows. It is not necessary
to have two iterations of each workflow. Hence, some projects need only one iteration and some others need many iterations
in each phase. It would be advantageous to have more than one pass in each phase for better and adequate results.
3. Round-trip Engineering
In this approach, increase in environmental activities is risky, because environment is the noticeable representation of the
process, methods and notations for creating the artifacts.
4. Demonstration-based Approach
In this approach, the implementation and assessment activities gets started in the initial stages of the life-cycle. Hence, the
focus is on constructing the executable subsets of the architecture.
Documentation results as a by-product of the workflow activities. Quality assurance is not carried out in a separate workflow
as it occurs in almost all the activities.
Q13. What are the artifacts and life cycle phases associated with each workflow?
Answer :
Artifacts Associated with Workflow
The artifacts associated with different workflows are as follows,
1. Management Workflow
The following are the artifacts associated with the management workflow,
(i) Business case
(ii) Software development plan
(iii) Status assessments
(iv) Vision
(v) Work breakdown structure.
2. Environment Workflow
The following are the artifacts associated with the environment workflow,
(i) Environment
(ii) Software change order database.
3. Requirements Workflow Representation of Iteration Workflow
The following are the artifacts associated with the Allocated usage Previous
requirements workflow, structures iteration results
(i) Requirement set
(ii) Release specification Management
(iii) Vision. Environment
Management
4. Design Workflow Requirements
The following are the artifacts associated with the design Design
workflow, Implementation
Assessment
(i) Design set
Deployment
(ii) Architecture description.
5. Implementation Workflow Next Iteration
The following are the artifacts associated with Result
Results
implementation workflow,
Figure: Iteration Workflows
(i) Implementation set
1. Management
(ii) Deployment set.
(a) In order to identify the release content and plan
6. Assessment Workflow development for iteration, iteration planning is
The following are the artifacts associated with the done.
assessment workflow,
(b) Work packages are assigned to the development
(i) Release specifications team.
(ii) Release descriptions 2. Environment
(iii) User manual
(a) Reflection of all new baselines for the gradual
(iv) Deployment set. development of software change order database.
7. Deployment Workflow (b) Alteration of all existing products, test and environ-
Deployment set is the only artifact associated with the ment components baselines.
deployment workflow. 3. Requirements
Life Cycle Phases Associated with each Workflow
(a) The baseline plan, architecture and requirements
For answer refer Unit-III, Q12, Topic: Activity Levels. set artifacts are analyzed. This analysis is done to
elaborate and evaluate usecases to be demonstrated
3.1.2 Iteration Workflows
at the end of this iteration
Q14. Define an iteration. Discuss the sequence of
(b) At the end of this iteration any requirements set
activities in an iteration workflow. artifacts are updated.
4. Design
Iteration (a) Elaboration of design model and test model com-
Iteration is defined as a sequential distribution of ponents is done by developing the baseline archi-
activities depending on the position of iteration in develop- tecture, and baseline design set artifacts in order
ment cycle. to indicate against evaluation criteria allocated to
Functions this iteration.
v Each iteration is represented as a collection of allocated (b) At the end of this iteration design set artifacts are
frameworks (or) structures. updated.
v In order to implement all selected frameworks, the 5. Implementation
required components are developed and combined with (a) New component development and existing com-
the results of previous iterations. ponent enhancement is done to demonstrate the
Iteration Workflows Activities evaluation criteria allocated to this iteration.
The workflow of an iteration includes the top-level (b) All new components and modified components are
workflow in the following sequence (as shown in figure below). combined and tested with existing baselines.
6. Assessment
Management
(a) Iterative result evaluation is done in accordance with Requirements
allocated evaluation criteria and the quality of the
Design
current baselines.
Implementation
(b) Rework identification i.e., to know whether any
rework is required. Assessment
(c) Rework execution is done by deciding whether the Deployment

rework should be performed before deployment of
Figure: Iteration Emphasis in Construction Phase
this release or to be performed in the next release.
(d) At the end of the iteration, its results are assessed 3. Iteration in Transition phase emphasize on the follow-
ing activities,
to improve the plan of the subsequent iteration.
7. Deployment (a) Assessment
An examination is conducted for moving the release (b) Deployment.
either to external organisation like user, independent
verification, validation contractor or to internal one in Management
order to capture and reflect the learned lessons in the Requirements
next iteration. Hence, many activities are done concur- Design
rently as with any sequence of a software development Implementation
workflow.
Assessment
For example, requirement analysis is not carried out as
Deployment
single activity, instead it is carried out concurrently with
other activities also. Figure: Iteration Emphasis in Transition Phase
Q15. Explain about the iteration emphasis across the
life cycle. 3.1.3 Major Milestones
Answer : Q16. Define checkpoints. Describe the categories of
checkpoints or milestones.
Iteration Emphasis Across the Life Cycle
Many of the activities in a life cycle occur concurrently. Answer : Model Paper-III, Q6(a)
An activity can combine with other activities too. There are Checkpoints
four phases of a life cycle. They are inception, elaboration,
construction and transition phases. Iterations in each phases of Checkpoints are also referred as milestones. A milestone
a life cycle do not stress on all the activities. Different phases is defined as a planned or organized event used to measure the
focus on different activities as discussed below, progress of a project.
1. Iteration in Inception and Elaboration phases emphasize In order to achieve the expectations of stakeholders
on the following activities, throughout the software life cycle, project checkpoints (or)
(a) Management milestone events are categorized into the following three
(b) Requirements sequences,
(c) Design. 1. Major checkpoints
Management 2. Minor checkpoints
Requirements
3. Status assessments.
Design
Implementation 1. Major Checkpoints
Assessment Major checkpoints are called system wide events.
Deployment
Functions of Major Checkpoints
Figure: Iteration Emphasis in Inception and Elaboration Phases
(i) Major checkpoints aim at long-term plans of the
2. Iteration in Construction phase emphasize on the fol-
entire software project globally.
lowing activities,
(a) Design (ii) These are carried out at the end of each development
(b) Implementation phase.
(c) Assessment. (iii) Deals with issues related to system.

(iv) Other functions include achieving the synchro- (iii) Deals with issues related to the progress of project
nization between engineering and management status (or) assessment of status. Inorder to assess
perspective and verifying the achievement of aims the status of a project, one must have quantitative
in various life cycle phases. data and historical information. These status
assessments play a vital role aiming at the project
(v) At the end of each phase, major milestone or major
health and its priorities.
checkpoints use formal, stakeholder approved
evaluation criteria and release descriptions. These three events, lead to the path of well defined
expectations, definite results thereby resulting in a successful
Example
project.
Customers or managerial sign-off, specification issuing,
system integration completion and product delivery are Q17. Who are the stakeholders and what are the
some of the major milestones or checkpoints. major areas of their concern in software life
cycle?
2. Minor Checkpoints
Answer :
Minor checkpoints are referred as iteration focused
Definition of Stakeholders
events.
People possessing stake or interest in the project are
Functions of Minor Checkpoints
called stakeholders.
(i) Minor checkpoints aim at short-term plans of the (or)
current iteration.
Stakeholders are the people who acquire gain or loss
(ii) These are carried out at the end of the processes depending on the project outcome.
and subprocessed within the phase and declare the
achievement of a tangible result. Features
(iii) Deals with iteration based issues. Stakeholders act in two ways,
(a) Internal to the Project Team
(iv) These are organized to review the iteration part in a
detailed manner and to continue with the approved Here, stakeholders are under the control of a project
work. leader directly.
(v) At the end of each phase, minor milestones or (b) External to the Project Team within the Same
checkpoints use informal, development team Organization
controlled versions. Here, involvement of the stakeholders is discussed. For
Example instance, project leader needs help from two sources,
Software module baseline, completion of a user manuals (i) From management, to include more data types to
chapter includes the minor milestones. database
Parameters of Milestones (ii) From users, inorder to test the system.
The milestone count and level of ceremony varies (c) External to Both Project Team and Organization
depending on the parameters like scale, stakeholder If external stakeholders are customers or users, then they
count, business context, technical risk etc. will take advantage of the project implementation of the
For complex projects, addition of one or more major system.
milestones is required. If external stakeholders are contractors, then they will
carry out project work.
For simple projects, very few or no minor milestones
are required. Inorder to carry out these features, at the first
outset, project leader needs to identify the stakeholders for
3. Status Assessments
developing a good rapport or communication from the start
Status assessments are referred as periodic events. of the project.
Functions of Status Assessments Major Concerned Areas of Stakeholders
(i) Status assessment aims at periodic occurrence of Project leader needs to be a good communicator and
stakeholder’s expectations. recognizer, as different types of stakeholders have different
types of interests.
(ii) They are carried out by the management in order to
check the development of a project in a periodical Different stakeholders are concerned with different areas
manner. in software life cycle as described below,
1. Customers
They deal with schedule and budget estimation, risk estimation, understanding of requirements, feasibility and product
line compatibility.
2. Users
They deal with system use, requirements, consistency, usage structures and quality attributes etc.
3. Architects and System Engineers
They deal with changes as per the requirements, product line compatibility, analyzation of trade-offs, balance among
quality, risk and usability etc.
4. Developers
Deals with requirements sufficiency, development environment sufficiency, description of usage structures, selection or
development of component structures and solving development risk.
5. Maintainers
They deal with product sufficiency, understandability, interoperability among existing system, maintenance of environment
sufficiency etc.
6. Other Stakeholders
Other possible stakeholders perspectives include regulatory agencies, validation contractors, venture capital investors,
subcontractors, associate contractors marketing and sales teams etc.
Hence, stakeholders plays a vital role in the software project.
Q18. What are the major milestones of software project?
Major Milestones
Major milestones are referred as System Wide Events as they mainly focus on the entire software project issues associated
with the system. Major milestones are considered as one of the sequences of project checkpoints, that are processed in software
life cycle.
Sequence of Major Milestones in Software Life Cycle

Phases of
life cycle Iteration (1) Iteration (2) Iteration (3) Iteration (4) Iteration (5) Iteration (6) Iteration (7)
Four Major
1. Life cycle 2. Life cycle 3. Initial operational capability 4. Product
Mile stones
objectives architecture milestone milestone release
milestone milestone
Figure: Phases of Life Cycle and Major Milestones

(i) In the above sequence, each of the phases i.e., inception, elaboration, construction and transition consist of atleast one
iteration, ending with a major milestone or occurs at transition points between the phases of the project life cycle.
(ii) The event that moves the project from elaboration to construction phase is considered as the important major milestone.
(iii) Major milestones are divided into four categories as mentioned above,
1. Life cycle objectives milestone
2. Life cycle architecture milestone
3. Initial operational capability milestone and
4. Product release milestone.
1. Life Cycle Objectives Milestone
(a) It appears at the end of inception phase.
(b) The main objective of this milestone is to advise or direct the stakeholders in order to continue with the development
of software based on its plan, estimated cost and schedule, cost savings and required benefits.
(c) Critical issues relevant to requirements, vision statement and operational concept are resolved here.
(d) If life cycle objectives milestone is completed successfully then there is a chance of jumping into elaboration phase
through approval of all stakeholders.
2. Life Cycle Architecture Milestone
(a) It appears at the end of elaboration phase.
(b) The main objective of this milestone, is to show all architecture that is carried out by all stakeholders.
(c) Critical issues with respect to requirement and operational concept are resolved here.
(d) If this milestone is successfully completed, then an allowance from all the stakeholders is achieved. So that the project
can proceed with the construction phase. Hence, it is considered as one of the most important major milestones
in which project transition occurs between elaboration and construction phases through which production stage
is initiated by concluding or ending the research and development stage.
Characteristics of this transition are,
(i) Critical use cases are described with stakeholders agreement, thereby organizing into a set of frameworks for evaluating
the architecture.
(ii) A stable architecture is baselined to explain the main architecture qualities like performance, scalability etc., against
the critical usecases. This resolves design and planning risks along with all major requirements.
(iii) Another characteristic is risk profile. Though risks are not solved, stakeholder of outstanding risks should have
common understanding and the lessened plans are fully explained.
(iv) The development plan for the construction and transition phases is defined such that construction iterations can go
with expected results like commitment to fixed price increments by the development organization.
3. Initial Operational Capability Milestone
(a) It appears at the end of construction phase.
(b) The main objective of this milestone is the assessment of immediate use of software inorder to move into user/
customer sites and authorization for acceptance testing. These two goals are briefly discussed as follows,
(i) For the sufficient transition quality, software quality metrics are reviewed.
(ii) Acceptance testing is allowed to test the software which can be done incrementally across various iterations or
can be performed, as a whole during the transition phase.
(c) Deals with issues like descriptive versions of software, manuals for user and operator, installation instructions etc.
4. Product Release Milestone
(a) It appears at the end of transition phase.
(b) The main objective of this milestone is the assessment of software completion along with its transition in order
to support organization. Also, software quality metrics are reviewed to identify whether the quality is enough for
transition.
(c) It deals with the similar issues as in initial operational capability milestone i.e., descriptive versions of software,
manuals for user and operator, manuals that support software, installation instructions, development environment
installation at support sites.
Q19. What are default agendas for the life-cycle architecture milestone?
Life Cycle Architecture Milestones

For answer refer Unit-III, Q18, Topic: Life Cycle Architecture Milestone.
Default Agendas for the Life Cycle Architecture Milestone
Presentation Agenda
I. Scope and objectives

Demonstration overview
II. Requirements Assessment

(i) Project vision and usecases
(ii) Primary scenarios and
evaluation criteria
III. Architecture Assessment

(i) Progress
v Baseline Architecture Metrics
v Development metrics baseline estimate
v Test metrics baseline estimates
(ii) Quality
1. Architectural features
2. Performance
3. Exposed architectural risks and resolution plans
4. Affordability and make/buy/use tradeoffs
IV. Construction phase plan assessment

1. Iteration content and usecase allocation
2. Next iteration(s) detailed plan and evaluation criteria
3. Elaboration phase cost/schedule performance
4. Construction phase resource plan and basic of estimate
5. Risk assessment
Demonstration Agenda
I. Evaluation criteria
II. Architecture subset summary
III. Demonstration Environment summary
IV. Scripted Demonstration scenarios
V. Evaluation criteria results and follow-up items
Figure: Default Agendas for the Life-cycle Architecture Milestone

Q20. Give the general status of plans, requirements and products across the major milestones in software
life cycle.
Answer :
The basic importance of each of the major milestones is based on the following two factors.
1. Assurance of gradual development in balanced levels among the requirements understanding, life cycle plans, products
form, quality and function.
2. Ensuring consistency among different artifacts.
The general status of plans, requirements and software products across the major milestone is as follows,
1. Life Cycle Objectives Milestone
General Status
(a) Plans
It includes the responsibilities of stakeholders, low fidelity life cycle plan and high fidelity elaboration phase plan.
(b) Requirements
Baseline vision includes the requirements like growth vectors, quality attributes, priorities and usecase model for
understanding of problem space.
(c) Software Products
Representation of atleast one architecture that is feasible in nature, make/buy/reuse trade-offs. Initial design model
identifies the progress in solution space.
2. Life Cycle Architecture Milestone Minor Milestones in the Life Cycle of an Iteration
General Status The number of iteration based milestones is dependent
(a) Plans on the iteration length and the content.
It includes high fidelity construction phase plan A one month to six month iterative period requires only
like bill of materials allocation of labour etc., and two minor milestones. They are,
the plan of low fidelity transition phase. 1. Iteration readiness review and
(b) Requirements
2. Iteration assessment review.
Stable vision and usecase model, accept criteria for
construction releases, initial operational capability 1. Iteration Readiness Review
evaluation, draft user manual are the requirements (a) This milestone is carried out at the start of each
for understanding of problem space. iteration for obtaining a detailed review of the
(c) Software Products iteration plan.
Stable design set, make/buy/reuse trade-offs, (b) This is also used for reviewing the evaluation
prototypes regarding critical components identify criteria associated with an iteration.
the progress in solution space. 2. Iteration Assessment Review
3. Initial Operational Capability Milestone
(a) This milestone is carried out at the end of each
General Status iteration to determine the degree of achieving
(a) Plans iterations objectives and satisfaction of its
evaluation criteria.
It includes high fidelity transition phase plan only.
(b) Requirements (b) It also performs other functions like,
Acceptance criteria with respect to product release (i) Reviewing iteration results.
acceptance and releasable user manual are the (ii) Reviewing qualification test results.
requirements for understanding of problem space.
(iii) Reviewing the effect of iteration results on
(c) Software Product the plan of subsequent iterations.
Stable implementation set, critical features and
(iv) Finding out the amount of rework
capabilities of core understanding. The qualities
of product identifies the progress in solution space. Some of the different milestones in the life cycle of an
4. Product Release Milestone iteration are represented as,
General Status
Management
(a) Plans
Requirements
Design

It includes only next generation product plan.
Implementation
(b) Requirements
Assessment
Final user manual is the only requirement for

Deployment
understanding of problem space.

(c) Software Products
Stable deployment set, full features, accepting
the quality which is compliant in nature helps in Iteration N − 1
determining the solution space progress. Iteration N
3.1.4 Minor Milestones Iteration N + 1
Q21. Explain about the minor milestones in the life

cycle of an iteration. Iteration N Iteration Iteration Iteration Iteration N
Initiation Readines Design Assessment Closeout
Answer : Model Paper-II, Q6(b) Review walkthrough Review
Minor Milestones
v The format of these minor milestones depends
Minor milestones are sometimes called as ‘inch-pebbles’.
highly on the project and the organizational culture.
v Minor milestones mainly focus on local concerns of
current iteration. v During the project plan, the iteration ‘N’ of the
project initiation is considered first.
v These iterative focused events are used to review iterative
content in a detailed manner and authorizes the continued v Second is the iteration readiness review which is
work. used for shorter iterations.
For instance, a test readiness review is carried out for Periodic status assessments are considered as one of the
the approval and review of test plans, on the projects containing critical project checkpoints as it provides special consideration
formal test procedures that are viewed by other stakeholders. to the gradual development of the project priorities.
v Third is the iteration design walk through which Need of Status Assessments in Software Life Cycle
is used for large scale projects that were never The purpose of status assessments in software life cycle
done before. This type of milestone acts as forcing includes the following,
functions for the progress of a project in a wide
manner. Intermediate review points are also used 1. The main goal is to fulfill the stakeholder expectations
for longer iterations. in a synchronized and consistent manner.
v Fourth is the iteration assessment review which has 2. Status assessments serve as periodic snapshots of a
the same purpose as of iteration readiness review healthy project which includes assessment of risks,
i.e., it is also used for shorter iterations. management indicators and quality indicators.
v At last, the fifth milestone is closing out of the 3. Status assessment documents provide the mechanism for
project. satisfying everyone's expectations, for communicating
and solving the management, technical issues and project
v An iteration has its own different forms and risks.
priorities depending on the project location in the
4. They provide the objective data from on-going activities
life cycle.
for developing product configurations.
v So, all the iterations are not created equally.
5. They also provides a mechanism for the wide spread
v Earlier iterations are aimed at, use of a process, progress, quality trends, practices and
v Analysis and design of project with considerable experience information to all the stakeholders in a to and
elements like discovery, experimentation and fro manner.
risk assessment. 6. Status assessments force the project manager to conduct
v Later iterations aim on, periodic review and to collect the necessary data in order
to have a good health of the project.
v Completeness of the project
7. Typical status assessments include resources review,
v Consistency personnel staffing, financial data i.e., cost and revenue,
v Usability top 10 risks, plans related to major milestones, scope
v Change management. of product, consequences and technical progress like
metrics, snapshots etc.
Basically, the iteration milestones along with their
There are repeated themes which include status
evaluation criteria should focus on engineering activities such
assessments derived from successful and unsuccessful projects.
as prioritizing the overall software development plan, business
They are as follows,
case and vision.
(i) From unsuccessful projects, status assessments are,
3.1.5 Periodic Status Assessments (a) High overhead activities due to the separation of
Q22. Discuss about periodic status assessments. status generation work and daily work.
Answer : Model Paper-III, Q6(b) (b) Frequently, cancelled due to the recollection factor
Periodic Status Assessment associated with high priority issues.
The interacting activities of a software development (ii) From successful projects, status assessments are,
requires continuous attention inorder to manage risks and to (a) Low-overhead activities due to the existence of
assess the project status. material data as everyday management data.
Definitions (b) Purely cancelled due to the crucial considerations.
Periodic status assessments are defined as the Inorder to spread the best practices efficiently and to
management reviews carried out at regular intervals i.e., enable project to project differentiation, an organization needs
(monthly, quarterly) so as to indicate the progress and quality to format in a systematic way for reviewing the metrics.
indicators, paying continuous attention to project dynamics and Default Content of Periodic Status Assessments
maintaining communication among all stakeholders.
To assess the top 10 risks, the software project manager
(or) is responsible for generating each review from the beginning,
Periodic status assessments are the periodic events in which will be an update of previous assessment.
which management reviews the progress of a project in regular A good rule, here is a project manager can produce status
manner so as to achieve stakeholder’s expectations. assessment charts within one day if and only if the data exists
(or) in an automated environment.
The default content or part of periodic status assessments 4. A work breakdown structure is also defined as breaking
includes the following topics, down of higher-level tasks into a set of lower-level
tasks.
1. Personnel
A work breakdown structure provides following
The content of this topic includes staffing plan vs actual
information as,
additions and subtraction or attributions.
v Description of important work.
2. Financial Trends
v Task breakdown for assigning responsibilities.
Expenditure plan vs actual for the previous, current and
subsequent major milestones and revenue forecasts are v Underlying structure for scheduling, budgeting and
the contents of financial trends. expenditure tracking.
3. Top 10 Risks Decomposition of work is forced by several parameters

for the discretion of tasks i.e., products subsystems, functions,
Critical resolution plans and issues and exposure of cost, life cycle phases, components etc.
time and quality comes under top 10 risks.
Types of WBS
4. Technical Progress
Work breakdown structures are categorized into two
The content of technical progress includes software types. They are as follows,
management metrics and indicators, major milestone (i) Conventional or traditional work breakdown
configuration baseline schedules, changed current trends structures.
and test quality assessments.
(ii) Evolutionary or modern work breakdown
5. Major Milestone Plans and Results structures.
Schedules, risks and plans for the next major milestone, (i) Conventional or Traditional WBS
pass/fail results for all acceptance criteria are the contents
of this topic.
(ii) Evolutionary or Modern WBS
6. Total Product Scope
Growth, total size and unsettled acceptance criteria are
the contents included in the total product scope. Q24. Conventional WBS’s are prematurely structured
around the product design. Discuss.
Hence, periodic status assessments play a vital role in
the development of project life cycle. Answer : Model Paper-I, Q7(a)
Conventional WBS
3.2 Process Planning Conventional or traditional work breakdown structures
3.2.1 Work Breakdown Structures suffer from the following limitations or shortcomings. They are,
Q23. Discuss about work breakdown structures. (a) Structured prematurely across the product design.
Answer : (b) Prematurely planned, decomposed and budgeted

in fluctuating levels.
Work Breakdown Structure (WBS)
(c) Project-specific and faces difficulties in cross
Definitions project comparisons.
1. Work breakdown structure is defined as a document of (a) Structured Prematurely Across the Product Design
scheduled tasks for completing the project within time.
Conventional or traditional work breakdown structures
(or) are prematurely structured around the product design.
2. A work breakdown structure is a hierarchical These are formed around the product subsystems. Later,
representation of the project plan which is divided into they are disintegrated into components of each subsystem.
separate work tasks. Representation of Conventional Work Breakdown Structure
(or) Management
3. The subdivision of entire project defined tasks that Requirements and Design
can consume resources is referred as work breakdown
Subsystem A
structure.
Component A . . .
A good work breakdown structure which is synchronized
with the process structure is one of the critical factors Requirements
for the success of a project. Design
Code Q25. "An evolutionary work breakdown structure
Test should organize the planning elements around
the process framework rather than product
Documentation framework". Substantiate this statement.
Component A Oct./Nov.-20(R16), Q3
Requirements OR
Design Discuss about evolutionary work breakdown

structures.
Code
Answer : (Model Paper-II, Q7 | Nov./Dec.-16(R13), Q8(a))
Test Evolutionary WBS
Documentation Evolutionary work breakdown structure is one of
the types of WBS. It removes the flows which appear in
Consider another subsystem ‘B’ then same format is
conventional WBS. It performs the organization, planning
followed as above.
of elements is done around the process framework whereas
Once this structure is firmly established with a concrete in a conventional work breakdown structure, organization of
financial plan, by allocating budgets, schedules to the managers, planning elements is around the product framework.
then it is hard to change the plan. So, tight coupling of product v In this approach, loose coupling is carried out as it
structure is not suitable. Hence, in such situations loose coupling allows changes in the gradual development of plan or
is desirable for changing the project plan or architecture. architecture.
(b) Prematurely Planned, Decomposed and Budgeted in v This work breakdown structure is structured in the
Fluctuating Levels following hierarchical manner.
In this, the fluctuating levels in large and small software 1. First level WBS elements
projects is considered (where ill-timed plan is carried out). The 2. Second level WBS elements
overplanning and underplanning of large and small software 3. Third level WBS elements.
projects respectively leads to fluctuating levels.
1. First Level WBS Elements
In large software projects, each element is completely These are defined as workflows (management, environment,
planned through management by creating a baseline budget requirements, design, implementation, assessment and
and schedule for each and every task at same level of details. deployment) in which single team allocation is carried
Whereas in small software project, each element is planned out. The elements comprising of project structure are then
through management with improper tasking, cost and schedule used for planning and comparison.
to single level with no detail. Hence, both these approaches are
2. Second Level WBS Elements
imbalanced in nature.
These elements are described for each life cycle phase
Basically, for a work breakdown structure two to three
(i.e, inception, elaboration, construction and transition)
levels are enough. In case of large software projects, levels may
which allows accuracy of plan that gradually develops
be added in coming phases of life cycle.
with requirements and architecture, understanding level
Too much detailed planning does not develop with along with their existing risks.
accuracy level. For instance, it is difficult to prepare accurate out 3. Third Level WBS Elements
line in month I. (when plan is being baselined) and impossible
before the architecture and test frameworks are engineered as These elements are specified for the activities producing
test activities details are scheduled after 18 months. artifacts in each phase. Hence being the lowest level
in hierarchy, these artifacts collect the cost for a given
(c) Project Specific and Faced Difficulties in Cross phase otherwise they may be disintegrated into several
Project Comparisons lower level activities inorder to produce a single
artifact.
In most organizations, projects are adapted according
to the project manager needs, demands of customer or other Default WBS
project-specific preferences from which project-specific A default Work Breakdown Structure (WBS) is consistent
structure is formed. with the process framework i.e., workflows, phases and artifacts.
If basic work breakdown structure does not exist, then This structure illustrates the integration of the elements of the
it is very difficult to carry out cross project comparisons based process framework into a plan. It allows to estimate the costs and
on the factors like plans, financial data, schedule data, cost, schedules of each element. It also allows to allocate estimation
product and quality trends as each project has its own style of across a project organization and track expenditures. The default
work with varied measurable units. WBS is shown below.
1. MANAGEMENT 3.2 Elaboration Phase Requirement Baseline
1.1 Inception Phase Management 3.2.1 Vision baseline
1.1.1 Business case development 3.2.2 Use case model baseline.
1.1.2 Elaboration phase release specification 3.3 Construction Phase Requirements Maintenance
1.1.3 Elaboration phase WBS baseline 3.4 Transition Phase Requirements Maintenance
1.1.4 Software development plan 4. DESIGN
1.1.5 Inception phase project control and 4.1 Inception Phase Architecture Prototyping
status assessments. 4.2 Elaboration Phase Architecture Baseline
1.2 Elaboration Phase Management 4.2.1 Architecture design modeling
1.2.1 Construction phase release specification 4.2.2 Design demonstration planning and conduct
1.2.2 Construction phase WBS baseline 4.2.3 Software architecture description.
1.2.3 Elaboration phase project control. 4.3 Construction Phase Design Modeling
4.3.1 Architecture design model maintenance
1.3 Construction Phase Management
4.3.2 Component design modeling.
1.3.1 Deployment phase planning
4.4 Transition Phase Design Maintenance
1.3.2 Deployment phase WBS baseline
5. IMPLEMENTATION
1.3.3 Construction phase project control and
5.1 Inception Phase Component Prototyping
status assessment.
5.2 Elaboration Phase Component Implementation
1.4 Transition Phase Management
5.2.1 Critical component coding demonstration
1.4.1 Next generation planning integration.
1.4.2 Transition phase project control and 5.3 Construction Phase Component Implementation
status assessments.
5.3.1 Initial release(s) component coding and
2. ENVIRONMENT stand - alone testing
2.1 Inception Phase Environment Specification 5.3.2 Alpha release component coding and
stand - alone testing
2.2 Elaboration Phase Environment baseline
5.3.3 Beta release component coding and
2.2.1 Development environment installation and stand - alone testing
administration 5.3.4 Component maintenance.
2.2.2 Development environment integration and 5.4 Transition Phase Component Maintenance
custom tool smithing
6. ASSESSMENT
2.2.3 SCO database formulation. 6.1 Inception Phase Assessment Planning
2.3 Construction Phase Environment Maintenance 6.2 Elaboration Phase Assessment
2.3.1 Development environment installation and 6.2.1 Test Modeling
administration
6.2.2 Architecture test scenario implementation
2.3.2 SCO database maintenance. 6.2.3 Demonstration assessment and release
2.4 Transition Phase Environment Maintenance descriptions.
2.4.1 Development environment maintenance and 6.3 Construction Phase Assessment
administration 6.3.1 Initial release assessment and release
2.4.2 SCO database maintenance description
2.4.3 Maintenance environment packaging and 6.3.2 Alpha release assessment and release
description
transition.
6.3.3 Beta release assessment and release
3. REQUIREMENTS
description.
3.1 Inception Phase Requirements Development 6.4 Transition Phase Assessment
3.1.1 Vision specification 6.4.1 Product release assessment and release
3.1.2 Use case modelling. descriptions.
7. DEPLOYMENT
7.1 Inception Phase Deployment Planning
7.2 Elaboration Phase Deployment Planning
7.3 Construction Phase Deployment
7.3.1 User manual base line.
7.4 Transition Phase Deployment
7.4.1 Product transition to user.
This work breakdown structure needs to be fitted or tailored depending on some project specifications.
Scale
Large scale systems have more levels and substructures.
Organizational Structure
Projects having subcontractors or several organizational entities may introduce constraints that require varying allocations
for work breakdown structure.
Degree of Custom Development
Different priorities exist in the workflows (requirements, design and implementation) depending on the project characteristics.
For instance, if the project is a business process re-engineering based, then it may require more depth in the requirements
element and fairly shallow design and implementation elements.
If a project is fully custom development of a technical application, then it may require a deep design and implementation
elements for managing the risks that are associated with custom, first-generation components.
Business Context
Consider the projects in business context then requirements are as follows,
1. For contractual projects more management and assessment elements are required.
2. For projects like delivery of commercial products to a huge customer base, elaborative substructures of deployment elements
are required.
3. For a single site application, a trivial deployment element (i.e., internally developed business application) or an elaborate
one is required (i.e. mission-critical legacy system transition with parallel operation to achieve zero down time).
Precedent Experience
Most of the projects are developed with,
(a) A mature WBS
(b) A preordained expected WBS.
(a) A Mature WBS
In this, projects are developed as new generations of legacy system.
(b) A Preordained Expected WBS
In this, projects are developed from existing organizational standards. These constraints are needed so that new projects
can make good use of the existing experience based projects and project performance standards. Hence, a WBS can be
considered as the most valuable source of project plan as WBS disintegrates the project character with a detailed plan of
the budget, personnel and life cycle.
Q26. Explain the conventional WBS issues and evolution of planning fidelity in the WBS over the life cycle.
Answer : Nov./Dec.-17(R13), Q8
Conventional WBS Issues

Evolution of Planning Fidelity in the Work Breakdown Structure Over the Life Cycle
Planning fidelity is one of the important attribute of a good WBS . It must be in proportion to the life-cycle phase and the
project state. The planning fidelity in various phases of the life-cycle and WBS elements is tabulated below,
Planning Fidelity
WBS Inception Elaboration Construction Transition
Element phase phase phase phase
Management High High High High
Environment Moderate High High High
Requirements High High Low Low
Design Moderate High Moderate Low
Implementa- Low Moderate High Moderate
tion
Assessment Low Moderate High High
Deployment Low Low Moderate High
Figure: Evolution of Planning Fidelity in the WBS Over the Life-cycle Phases
From the above table, the following can be observed,
1. In inception phase, the planning fidelity is high in management and requirements elements, moderate in design element
and low in the remaining elements.
2. In elaboration phase, the planning fidelity is high in management, environment, requirements and design elements, moderate
in implementation and assessment elements and low in deployment.
3. In construction phase, the planning fidelity is high in management, environment, implementation and assessment element,
moderate in design and deployment elements and low in requirements element.
4. In transition phase, the planning fidelity is high in management, environment, assessment and deployment elements,
moderate in implementation element and low in the remaining elements.
3.2.2 Planning Guidelines

Q27. Describe the conventional WBS issues and planning guidelines. (Model Paper-III, Q7(a) | Dec.-19(R16), Q6)
OR
Explain in detail about planning guidelines.
(Refer Only Topic: Planning Guidelines)
Conventional WBS Issues

Planning Guidelines
The guidelines should be planned and carried out in an efficient way for a successful project. Project planning depends on
two factors. They are,
(i) Worth and
(ii) Risk
Hence, planning is valuable but risky also.
1. Project planning is valuable, because by looking at the project structure only, the management people can easily analyze
the project specific details. Since, they know that great skill and experience of other people can be seized by the initial
planning guidelines. So, these guidelines are considered as possible estimate base which establishes or implants confidence
in stakeholders or reaches to confidence level in stakeholders.
2. Project-independent planning is also risky because there is a risk of blind adoption of guidelines instead of being adapted to
a specific project. This leads to incompetency or inefficiency of management team. Another risk of misinterpretation arises
which has a great impact on project due to variation levels in project parameters, project business contexts, organizational
cultures, processes of project etc.
The two simple guidelines that are considered during (ii) Second Guideline
project initiation and assessment are as follows,
This guideline deals with the allocation of effort and
(i) First guideline is default cost allocation among the schedule across the life cycle phases (i.e., inception, elaboration,
first level WBS elements. construction and transition). Here, default allocation is provided
(ii) Second guideline is effort and schedule allocation for second level WBS elements.
across the life cycle phases. Representation of Default Allocation of Effort and Schedule
(i) First Guideline
Domain Effort Schedule
As this guideline is about the default allocation of
Inception 5% 10%
budget among the first level WBS elements, default allocation
is provided for each and every first level WBS elements. Elaboration 20% 30%
Construction 65% 50%
The first level WBS elements include the workflows
(i.e., management, environment, design, requirements, Transition 10% 10%
implementation, assessment and deployment) which are carried
These allocated values can also vary from project to
out for a single team allocation.
project as these variations depend on application constraints.
Representation of Default Allocation of WBS Budgets These values also provide an average expectation across
different application domains. The data in the above two tables
First-level WBS Element Default Budget
is obtained from the past experience with the involvement of
1. Management 10% software cost, estimation efforts that provides scope of software
2. Environment 10% projects, processes, technologies etc.
3. Requirements 10% Hence a top-down development plan is formed as
4. Design 15% a baseline for more elaboration from the tasks like initial
estimation of total project cost and allocation of staff resources
5. Implementation 25%
to teams, development of staff profile, an initial WBS with
6. Assessment 25% budgets and schedules, top-level project schedule etc.
7. Deployment 5% Q28. Give an outline of step-wise planning activities.
Total 100%
Answer :
v These allocated values vary from one project to another.
The step-wise planning activities are as follows,
v By knowing the reasons of guideline deviations, this
Step 0: Choosing a Project
type of allocation provides a good standard for planing
assessment. The first step is to find which type of project is worth
starting. This can be done by performing feasibility study. This
v Inorder to avoid the risk of misinterpretation, two things
step is referred to as step 0 since it is not involved in planning
must be clarified. They are,
of a project.
(a) Labour costs
Step 1: Identifying Scope and Objectives of a Project
(b) Hardware and software costs.
After selecting the project, the next step is identifying the
(a) Labour Costs project scope and objectives and finding appropriate measures
Different labour costs are essential in these allocations. for fulfilling the objectives.
For instance, the elements dealing with management, This step also involves,
requirements, design workflows use the people who are
senior and highly paid when compared to other elements. v Authorizing the project
If requirements and design elements use 1/4th of the v Identifying the project stakeholders
default budget (people employed with average salary
v Modifying the project objectives according to the
of 100$ per hour) then this total represents 1/2 as many
interests of the stakeholders
hours of staff as the consumption of assessment element
which also accounts for 1/4th of the budget (people v Creating an effective communication medium among
employed with an average salary of 50$ per hour). the people involved in the project.
(b) Hardware and Software Costs Step 2: Defining Framework for the Project
Hardware and software costs are included in environment Once the project scope and objectives are defined, the
element by supporting process automation and next step is identifying an appropriate project framework. This
development teams. step includes,
v Establishing a relation between project planning and Step 7: Allocation of Resources

strategic planning. This step involves identifying and allocating resources
v Defining appropriate project installation standards and of each project activity. This helps in reviewing and modifying
methods. the activity plan. Other than this, project completion date can
also be rescheduled.
v Organizing the project team.
Step 8: Reviewing the Project Activity Plan
Step 3: Analyzing the Features of a Project
There is a possibility that particular activity may not be
This step makes sure that the relevant project procedures
carried out properly, which can affect the project. Hence, to
are implemented. This step involves,
overcome this, quality controls are established for every activity.
v Ability to differentiate between a objective project and Prior to the completion of each activity, quality controls must be
a product-driven project. passed. After reviewing the quality aspects of the project plan,
v Analysing quality-based characteristics of the project. it should be documented in such a manner that the concerned
people involved in the project understand their roles and
v Identifying high-level risks associated with a project
responsibilities and abide by them.
v Considering those user requirements that focus on project Step 9 or 10: Execute the Project Plan at a Lower Level
implementation.
Project plan is executed in an iterative manner. Hence,
v Choosing an appropriate life-cycle model for the project. when a particular activity is to be implemented, a detailed
v Reviewing all the resources estimated for project replanning of the activity is required.
implementation.
3.2.3 Cost and Schedule Estimating Process
Step 4: Identifying the Products (Deliverables) of the
Q29. Define Project Planning. What are two pers-
Projects and their Activities
pectives of project plans? Write the planning
This step of project planning includes, sequence of each.
v Identifying and providing a description of the project OR
products.
Discuss life cycle planning balance.
v Recording the product flow details using a Product Flow Oct./Nov.-20(R16), Q8(a)
Diagram (PFD). OR
v Identifying the instances of a particular product. Discuss about the cost and schedule estimating
v Creating an appropriate activity plan or network to process.
determine the type of activities needed for generating Answer : (Model Paper-I, Q7(b) | March-17(R13), Q8(b))
one product from another and how those activities should
Definition of Project Planning
be carried out.
Project planning includes missions and objectives
v Modifying the activity plan by introducing checkpoint
selection and actions to achieve these goals and also requires
activities. These activities ensure compatibility of the
decision making for an effective plan. It can be considered as
preceding activities carried out on products.
one of the managerial functions.
Step 5: Producing Effort Estimates for Every Activity
Perspectives of Project Plan
The fifth step of project planning helps to determine
There are two different perspectives that are to be used
the completion time of the activities by estimating the effort
for deriving project plans. They are,
put in each activity. This helps in controlling the project. If
there are activities that take a lot of time to complete, then (a) Top-down approach
these activities can be broken down into manageable sub- (b) Bottom-up approach.
activities.
(a) Top-down Approach
Step 6: Identifying the Risks Associated with Each Activity This perspective is referred as forward-looking top-
After estimating the effort for every activity, the next step down approach, because this is carried out from higher-level
is identifying and evaluating the activity-based risks. Other than to lower level decomposition or disintegration. This approach
this, appropriate contingency plans are formulated for taking commensurate with an understanding of the requirements and
action on those identified activities which cannot be avoided or constraints deriving a macro-level budget and schedule, then
reduced. Also, if needed to reduce the risks slight adjustments disintegrating these elements into micro-level or lower level
are made on the contingency plans. budgets and intermediate milestones.
Hierarchical Representation
Requirements and Higher level

constraints understanding
Macro-level budget and

schedule
Micro-level budget and Lower level

intermediate milestones
The top-down approach follows the following planning sequence,

1. Software project manager and other personnel produce some of the project elements like overall size, quality, people,
process and environment.
2. Use a software cost estimation model to estimate a macro-level total efforts and develop a schedule.
3. Partitioning of the efforts by using the two simple planning guidelines which are to be considered during project initiation
and assessment.
(i) By using first guideline, the software project manager partitions the efforts estimation into top-level work breakdown
structure.
(ii) By using second guideline, the software project manager partitions the schedule estimation into major milestone dates and
the effort estimation into a staffing profile. Thus, a project level plan is formed.
4. At last, the subproject manager disintegrates each of work breakdown structure elements into lower-levels by considering
the above mentioned constraints (i.e., top-level allocation, staffing profile, and major milestone dates).
(b) Bottom-up Approach
This perspective is referred as backward-looking, bottom-up approach, because the decomposition or disintegration
is carried out from the lower-level to higher level. The elements included in this approach are nasalization of micro-level
budgets and schedules and then summing up these elements into macro level or higher level budgets and intermediate
milestones.
Hierarchical Representation
Analyse micro-level Lower level

budgets and schedules
Sums up the micro

level
Macro level budgets and Higher level
intermediate milestones
The planning sequence for the bottom-up approach is as follows,

1. WBS element manager estimates the budget and schedule for the detailed lowest level WBS elements. These estimates
are then included in the project specific parameters.
2. Next sequence is combining and integrating estimates into higher level budgets and intermediate milestones. The individual
estimators need to have same preferences for a consistent discussion.
3. Last sequence is to compare top-down budgets and schedule milestones and if any differences exist then they are orderly
adjusted and estimated to meet the point of convergence (Between topdown and bottomup estimates).
If the above two approaches are compared, then top down approach amplifies the preferences of project management
resulting in an optimistic plan. Whereas bottom up approach simplifies the preferences of performer resulting in a pessimistic
plan. For the development of plan through multi-versions, iterating is needed for validating results through one method
and results refinement through another method. Throughout the project life cycle, uniformity of these approaches should
be maintained.
The life cycle planning balance is illustrated below,
Bottom-up approach considering

previous iterations
Planning
Top-down approach considering
macroanalysis of previous projects
Figure: Life Cycle Planning Balance
3.2.4 Iteration Planning Process

Q30. Discuss about iteration planning process. Model Paper-III, Q7(b)
OR
A typical project would have six-iteration profiles. Discuss them.
Answer : Oct./Nov.-20(R16), Q8(b)
The concept of iteration planning arises for defining intermediate results sequence. The most definite form of risk man-
agement plan is to plan the content and schedule of major milestones and their intermediate iterations. Basically, iteration can
be defined as synchronized, global assessment of entire project-baseline. The general guidelines of iteration planning depends
on iteration count in each phase of the project life cycle. Micro iterations are also performed to the project-level synchroniza-
tion points.
Various iterations are handled in the phases of life cycle, they are as follows,
1. Inception iterations
2. Elaboration iterations
3. Construction iterations
4. Transition iterations.
Of these, inception and elaboration iterations are carried out in an engineering stage, whereas the construction and transition
iterations are carried out in production stage.
1. Inception Iterations
Inception iterations are considered as the feasibility iterations.
These iterations result in integration of candidate architecture components and executable framework.
This framework operates in two ways,
(a) Candidate architecture demonstration
(b) Establishment of business case, vision and software plan.
(a) Candidate Architecture Demonstration
To demonstrate the candidate architecture, the framework must include the foundation components such as commercial
components, custom prototypes and existing components.
(b) Establishment of Business Case Vision and Software Plan
Requirements understanding are enough to establish a possible business case, vision and software development plan.
Iteration count in this phase is carried out as follows,
(i) Large-scale, custom development projects may require two iterations
(ii) Most of the projects use only one iteration in inception phase.
2. Elaboration Iterations
v Elaboration iterations are considered as the architecture iterations.
v These iterations result in an architecture with a complete framework and execution structure.
v A few critical use cases need to be demonstrated after completing the architecture iteration.
The demonstrable usecases are,
(i) Architecture initialization
(ii) A design for worst case data processing in system (for instance, peak load)
(iii) A design for worst-case control processing in system (for example, fault-tolerance usecases).
v Iteration count in this phase is carried out as follows,
(i) Unprecedented architectures may involve additional iterations
(ii) Well-established architectures requires only one iteration
(iii) Most of the project plans require two iterations for an acceptable architecture.
3. Construction Iterations
v Construction iterations are considered as the usable iterations.
v Construction iterations are divided into two types,
(a) Alpha release
(b) Beta release.
(a) Alpha Release
v It includes the capability of the execution of all the critical use cases.
v It consumes 70% breadth of the total product by performing at the quality (performance, reliability ) levels
lower than the expected levels in a final product.
(b) Beta Release
v Beta release consumes 95% breadth of total product and only some quality attributes are achieved.
v In order to improve the performance, complete features should be provided in an elaborative manner.
(i) Most of the projects require atleast two major construction iterations.
(ii) One or two more iterations to improve the performance of a project, to manage the risks and to minimize the
expenditure are needed.
4. Transition Iterations
v Transition iterations are treated as the final product releases.
v To transition a beta release into a final product, most of the projects use single iteration.
v In order to solve all defects or defect reduction by including beta feedback and performance improvement, many
small scale iterations are needed.
Most of the projects use single iteration between beta release and final product release, because of the elevated type
of full-scale transition to the group of users.
Six Iteration Profiles
By summarizing all these iterative phases, the general criteria is, most projects must have four to nine iterations. But, a
distinct project uses six-iterations as follows,
Phase
Count Iteration
Iteration
Inception 1 An architecture prototype.
Elaboration 2 Architecture prototype and baseline.
Construction 2 Alpha and Beta releases.
Transition 1 Product release.
v In case of highly precedented projects or very small-scale projects, inceptions and elaboration phases requires only
a single iteration which produces an efficient product with four iterations.
v In case of unprecedented or very large scale projects, there is a requirement of one extra inception iteration, two extra
construction iterations. Forming a total of nine iterations. Finally the management overhead is valuable to assure risk
management and synchronization of stakeholders.
Q31. Summarize the differences in emphasis between engineering and production stages.
Answer : Oct./Nov.-20(R16), Q7
Differentiation of Engineering Stage Planning and Production Stage Planning

1. Engineering Stage Planning
Engineering stage develops the plans, requirements and architecture by solving the developmental risks.
2. Production Stage Planning
Production stage develops versions of capability within the plans, requirements and architecture developed in an engineering
stage
Comparison of Engineering Stage and Production Stage
1. Engineering Stage Planning
v It consists of smaller teams to perform design and synthesis activities.
v Schedule, technical feasibility are the risk reduction factors in this stage.
v Architecture base line is the product.
v Assessment is done by demonstration, inspection and analysis.
v In case of economics, diseconomies of scale are resolved.
v During the engineering stage, top-down approach is carried out due to insufficiency of understanding and stability
in task sequences.
v Macro-level task estimation is used for production stage artifacts and micro-level task estimation for engineering
artifacts.
v Stakeholders synchronization occurs.
v Analyzation of actual and planned expenditures are varied in a coarse-grained or rough-grained way.
v In an engineering stage, top-down project independent planning guidelines are converted into project-specific or
project-dependent planning guidelines so that they can be further used as global assessment methods.
v Inception and elaboration phase are carried out in engineering stage.
2. Production Stage Planning
v It consists of larger team for performing test, construction and deployment activities.
v Cost is the only risk reduction factor here.
v Product release baseline is the product.
v Assessment is done by testing method.
v In case of economics, economies of scale are exploited.
v During the production stage bottom-up approach is preferred because enough experience and exactness in planning
level should exist.
v Micro-level task estimation is used for production stage artifacts and macro-level task estimation for engineering
stage artifacts.
v Stakeholder synchronization exists.
v Analyzation of actual and planned expenditures are varied in a fine-grained or smooth-grained manner.
v Construction and transition phases occur in production stage planning.
Representation of Phases in Engineering Stage and Production Stage
Inception E laboration
Iterations
Feasibility Architecture
Figure: Engineering Stage
Construction Transition
Usable or Beta Product release

releases
Figure: Production Stage
v Changes between engineering stage and production stage are very crucial for the stakeholders.
3.2.5 Pragmatic Planning

Q32. Explain about the iteration planning process and pragmatic planning.
Answer : Dec.-19(R16), Q7
Iteration Planning Process

Definition of Pragmatic Planning
The planning which is done practically for a successful project is called as Pragmatic Planning.
Characteristics of Pragmatic Planning
v Pragmatic planning is ruling over the iterative development.
v If planning leads to the path of success, then the gradual progression of a project will be easier by entering into the phases
of life-cycle. At last, this takes to reach the path of exactness or fidelity in planning.
v Good architectures and requirements understanding are the elements of adequate planning or good planning, whereas bad
architectures and misunderstood requirements are the elements of inadequate planning or bad planning which leads to
project failure.
v A successful project is not important, once it is produced and is rarely used by performer on a day-to-day basis which
doesn’t result in interest in the end user. Whereas an unsuccessful project needs to be refined more as they are not produced
instantly, so, they are frequently used by performers.
v Planning document is worthless as an end item, instead the act of planning is very crucial to achieve the project success.
It is the provision of framework and forcing functions for decision making, transforming subjective, generic process into
an objective process.
v Definition of a project plan includes the way in which the project requirements are transferred into a product within the
business constraints.
v The goal of good project management is to compromise between current iteration plan and next iteration plan based on
the result of current iteration and previous iterations. For instance, during the execution of iteration N in any phase, the
software project manager is required to view and control the plan which was started in iteration N – 1 and then the planning
is done for an iteration N + 1.
v Plans are not only certified to the project managers but also to the team members of the project. The good result is obtained
when more open and visible process exists for planning.
v Planning is the managements crux, as a good planning balances the resources available in order to provide optimal win
conditions for all stakeholders.
v Hence, pragmatic planning plays a vital role in project development.
Important Questions
Short Questions
1. Define iteration. What are the functions of iteration? Refer Q1
2. Write short notes on integration and installation activities of software project management. Refer Q5
3. Write brief notes on major milestones in software process. Refer Q6
4. What are the responsibilities of SEEA? Refer Q9
5. Discuss about initial operational capability milestone. Refer Q10
ESSAY Questions
6. What levels of activity take place in these workflows during each of the four phases (inception, elaboration, construction and transition)?
Refer Q12
7. Define an iteration. Discuss the sequence of activities in an iteration workflow. Refer Q14
8. What are the major milestones of software project? Refer Q18
9. Explain about the minor milestones in the life cycle of an iteration. Refer Q21
10. Discuss about work breakdown structures. Refer Q23
11. Describe the conventional WBS issues and planning guidelines. Refer Q27
12. Explain about the iteration planning process and pragmatic planning. Refer Q32
Unit-4 Project Organization, Project Control and Process Instrumentation 4.1
Unit
Project Organization, Project Control and
4
Process Instrumentation
SI
A GROUP
Syllabus
Project Organizations: Line-of-Business Organizations, Project Organizations, Evolution of Organizations, Process
Automation.
Project Control and Process Instrumentation: The Seven-Core Metrics, Management Indicators, Quality Indicators,
Life-Cycle Expectations, Pragmatic Software Metrics, Metrics Automation.
Learning Objectives
 The Project Organizations such as Line-of-Business and Project Organizations.
 Evolution of Organizations.
 Introduction to Software Automation and Software Change Orders (SCO).
 Configuration Baseline and its Levels.
 The Seven Software Metrics and its Need.
 The Management Indicators and Quality Indicators.
 Pragmatic Software Metrics and their Automation.
Introduction
The various project organizations consist of their respective component teams with different responsibilities.
The team management is the most significant aspect of project development because without team effort
the software cannot be developed. Therefore, inorder to achieve productive and high quality software,
team members must be effective and motivated.
The level of process includes three levels such as Metaprocess level, Macroprocess levl and Microprocess
level. The main objective of modern software development process is to handle the central management
issues of complex software.
Software metrics are used for the implementation of the activities and products of the software development
process. It determines the quality of the software products and the achievements in the development
process.

Q1. Write about line-of-business organization.
Answer : Model Paper-III, Q1(g)
Line of Business Organization

The Line of Business Organization consists of four component teams.
1. Software Engineering Process Authority
This team is responsible for exchanging the information and project guidance to or from the project practitioners.
2. Project Review Authority
This team is responsible for reviewing the financial performance, customer commitments, risks and accomplishments,
adherence to organizational policies by the customers, etc.
3. Software Engineering Environment Authority
This team deals with the maintenance or organization’s standard environment, training projects, and process automation.
4. Infrastructure
It includes the project independent research and development, human resources support and capital software engineering
assets, etc.
Q2. Write about evolution of organizations.
Answer : (Model Paper-II, Q1(g) | Dec.-19(R16), Q1(g))
The project organization generally represents the team’s architecture. It is necessary to evolve the organization’s structure
so that it becomes consistent relative to the project plan, which is gathered in the work breakdown architecture.
The following are the set of activities that are focused in every individual phase:
1. Inception Organization
2. Construction Organization
3. Elaboration Organization
4. Transition Organization.
Q3. Explain about configuration baseline.
Answer : Nov./Dec.-16(R13), Q1(h)
A specified collection of software components and its associated documentation, depending on the changed management
and that can be maintained, updated, tested and status as a single unit is called a configuration baseline.
Two types of configuration baselines are,
1. External product releases and
2. Internal testing releases
A configuration baseline is usually controlled and is wrapped and exchanged between the groups of components.
Q4. What are the basic parameters of an earned value system?
Answer : (Model Paper-I, Q1(g) | Nov./Dec.-17(R13), Q1(i))
The basic parameters of an earned value system are,

(i) Expenditure Plan
It specifies the planned expenditure over a planned schedule for a project. This monitors the staffing profile.
(ii) Actual Progress
It is the technical achievement based on the planned progress. It follows the planned progress in a successful project.
(iii) Actual Cost
It is the actual cost expanded over an actual schedule in a project. It closely follows the planned profile in a successful
project.
(iv) Earned Value
It is the value that represents the planned cost of the actual progress.
(v) Cost Variance
It is the difference between the actual cost and the earned value i.e.,
Cost Variance = Actual Cost – Earned Value
If cost variance > 0, then it leads to the over-budgeted situations.
If cost variance < 0, then it leads to under-budgeted situations.
(vi) Schedule Variance
It is the difference between the planned cost and the earned value.
Schedule Variance = Planned Cost – Earned Value
If schedule variance > 0, then it leads to the behind scheduled situations.
If schedule variance < 0, then it leads to the ahead of schedule situations.
Q5. What are the levels of baseline releases?
Answer :
Levels of Baseline Releases
The three levels of baseline releases are,
(i) Major Release
It specifies the new product/project generation. The major release number is denoted by N.
(ii) Minor Release
It specifies the same basic product but with extended features, performance or quality. The minor release number is
denoted by M.
(iii) Interim Release
It is in accordance with the transient developmental configuration. The interim release identifier is represented as X.
Q6. What is meant by round trip engineering? Nov./Dec.-17(R13), Q1(d)
OR
What is roundtrip engineering?
Answer : (Model Paper-I, Q1(h) | March-17(R13), Q1(c))
Generating models from source code and vice versa is a capability of a software development tool, called “round-trip”
engineering. The existing source code can be transformed into a model, applied to software engineering methods and finally
transformed back. In the UML standards, round-trip is a specific model perspective. The full execution use case in an implemented
system has some conceptual elements covered by round-trip engineering.
Q7. List the seven core metrics.
Answer : Model Paper-II, Q1(h)
The seven core metrics are,

(i) Work and progress metrics.
(ii) Budgeted cost and expenditures metrics.
(iii) Staffing and team dynamics metrics.
(iv) Change traffic and stability metrics.
(v) Breakage and modularity metrics.
(vi) Rework and adaptability metrics.
(vii) MTBF (Mean Time Between Failures) and maturity metrics.
Q8. Write brief notes on metrics automation.
Answer : (Model Paper-III, Q1(h) | Dec.-19(R16), Q1(h) | Nov./Dec.-17(R13), Q1(j))
Several techniques are used for the automation of metrics or to operate the tasks of a software project automatically. One
of the commonly used techniques is “SPCP”. SPCP stands for software project control panel. This technique was first brought
into effect by ASC (Airline Software Council) in 1996. The working of SPCP is same as that of a dashboard. This is because just
like a dashboard which is a kind of panel to show all the controls and instruments in a car, similarly, SPCP is also a control panel
that shows the progress of certain attributes of a project to the concerned entities like software project manager, test manager and
development managers by combining information from more than one medium.
Few examples to demonstrate the above process are,
Example 1: By using software project control panel, software project manager can view the complete values of the project.
Example 2: Through SPCP particular metrics based on their forthcoming beta version can be viewed by the manager.
Example 3: With the help of software project control panel, development managers can get the data of those components and
sub-systems which are handled by them.
Q9. Define MTBF and maturity.
Answer : Nov./Dec.-16(R13), Q1(j)
MTBF stands for Mean Time Between Failures. It is an indicator that computes the average time consumed between the
software failures (errors) by dividing the test hours (T.h) with type 0 and type 1 software change orders. It is given by,
T.H
MTBF = Number of type 0 and type 1' s CO's
Maturity metrics specifies how mean time between failures varies over time by comparing project schedule against the
released baselines.
Q10. Define rework and adaptability.
Answer : March-17(R13), Q1(i)
Rework
Rework is the average cost of change i.e., the effort to analyze, rectify and retest the changes made to the software baselines.
Adaptability
Adaptability is the tendency to rework over time. Product maintainability is suspected when the rework trends are increasing
with time.
Purpose
It includes convergence, quality indicator and software rework..
Perspectives
Average hours per change by release, component or subsystem by type.
4.1 Project Organizations

4.1.1 Line-of-Business Organizations
Q11. With a neat diagram explain the default roles in a software line of business organization.
Answer : (Model Paper-I, Q8(a) | Nov./Dec.-17(R13), Q9)
Default Line-of-Business Organization

The four component teams in a default line of business organization are,
1. Software Engineering Process Authority (SEPA)
The SEPA enables the exchange of information and process guidance to and from the project practitioners. It reports to the
general manager of an organization for maintaining the current analysis of the organization’s process maturity and for enhancements
in future. It initiates and evaluates the projects performance periodically.
Responsibilities
The responsibilities includes process definition and maintenance. It can be a single individual (general manager) or a team
of representatives.
2. Project Review Authority (PRA)
It comprises of a single individual whose responsibility is to ensure that a software project meets all the organizational
and business unit software policies, standards and practices. A software project manager is incharge of meeting the requirements
of a project and is answerable to PRA.
Adhering to organizational policies by the customers, financial performance, customer commitments, risks and
accomplishments are reviewed by PRA.
3. Software Engineering Environment Authority (SEEA)
It is responsible for the organization process automation, keeping the organizations standard environment, training projects
etc. Tools, techniques and training can be implemented effectively, only if SEEA is responsible for supporting and monitoring the
standard environment.
4. Infrastructure
It comprises of project-independent research and development, human resources support, capital SE assets, etc. It includes
the following components,
(a) Project Administration
Time accounting system, pricing and contracts conditions and the integration of corporate information systems.
(b) Professional Development
Training camp, personal recruitments, technical publications, maintaining the personal skills database.
(c) Engineering Skill Centers
Maintaining the custom tools repository, independent research and development.
Features of Line-of-Business Organization
The following are the important features of the default line-of-business organization,
1. Responsibility associated with process definition and its maintenance is peculiar to cohesive line-of-business. In this line-
of-business environment, the process commonality is useful.
2. Responsibility associated with process automation is considered as an organization role. This responsibility is equally
important as the process definition role. The process commonality is attained by the projects by considering the environment
support of common tools.
3. Depending on the organization size, the organizational role can be carried out either by a single person or different group
of persons.
The default roles in a software line-of-business organization can be represented diagramatically as follows,
Organization manager
Project review authority Software engineering

process authority
Software engineering
Infrastructure
environment authority
Project 1 Project 2 Project 3 Project N– 1 Project N

Manager Manager Manager Manager Manager
Figure: Default Roles in Line of Business Organization
4.1.2 Project Organizations

Q12. What are the four component teams in a default project organization and their responsibility?
OR
What are the activities of software assessment team? Explain.
(Refer Only Topic: Software Assessment Team) (Model Paper-II, Q8(a) | Nov./Dec.-16(R13), Q8(b))
OR
What are the activities of software architecture team?
(Refer Only Topic: Software Architecture Team)
Component Teams in Default Project Organization
The four component teams in default-project organization are,
1. Software management team
2. Software architecture team
3. Software development team and
4. Software assessment team.
1. Software Management Team
This is active participant in an organization and is incharge of producing as well as managing. As the software attributes
such as casts, schedules, functionality and quality are inter-related to each other, negotiation among the multiple stakeholders is
required and these are carried out by the software management team.
Responsibilities
Software management team is responsible for,
(i) Effort planning
(ii) Conducting the plan
(iii) Adapting the plan according to the changes in requirements and design
(iv) Resource management
(v) Stakeholder satisfaction
(vi) Risk management
(vii) Assignment or personnel
(viii) Project controls and scope definition
(ix) Quality assurance.
2. Software Architecture Team (v) Domain Applications

The architecture team performs the tasks of integrating Specialists expertise in algorithms, application
the components, creating real artifacts etc. The skills possessed processing, business rules, etc.
by the architecture team is of utmost importance as it promotes Responsibilities
team communications, and implements the applications with
a system-wide quality. The success of the development team Software development team is responsible for,
depends on the effectiveness of the architecture team. The (i) Component development, testing and maintenance.
architecture team along with the software management team
controls the inception and elaboration phases of a life-cycle. (ii) Component design and implementation.
(iii) Component documentation.
The architecture team must have:
4. Software Assessment Team
v Domain experience to generate an acceptable design and
use-case view. This team is involved in testing and product evaluation
activities in parallel with the ongoing development. This is an
v Software technology experience to generate an independent team for utilizing the concurrency of activities. The
acceptable process view, component and deployment use-case oriented and capability-based testing of a process is
views. done by using two artifacts.
Responsibilities (i) Release specification which refers to the plan and
evaluation criteria for a release and
Software architecture team is responsible for,
(ii) Release description which deals with the results of a
(i) System-level quality i.e., performance, reliability and
release.
maintainability.
Internal component testing is employed by the
(ii) Requirements and design trade-offs. development team to test many components. Formal testing for
(iii) Component selection. many components will then be done in a higher-level evaluation
criteria. The decision of which form of testing (i.e., formal
(iv) Technical risk resolution. component testing or capability testing) to be employed is made
by the assessment team.
(v) Initial integration.
Responsibilities
3. Software Development Team
The assessment team is responsible for,
The development team is involved in the construction
and maintenance activities. It is the most application-specific 1. The exposure of the quality issues that effect the
team. It consists of several subteams assigned to the groups customer’s expectations.
of components requiring a common skill set. The skill sets 2. Metrics analysis
comprise of,
3. Verifying the requirements
(i) Commercial Component
4. Independent testing
Specialists having the descriptive knowledge of
commercial components in the system’s architecture. 5. Configuration control and user deployment.
6. Building project infrastructure.
(ii) Database
Q13. What are the activities of software management
Specialists having experience in management, storage
team?
and retrieval of data.
Answer :
(iii) GUI (Graphical User Interfaces)
Software Management Team
Specialists with a detailed knowledge of data presentation,
display organization and user interaction. For answer refer Unit-IV, Q12, Topic: Software
Management Team.
(iv) Operating Systems and Networking
Activities of Software Management in Life Cycle Phases
Specialists having the descriptive knowledge of various
control issues arising due to synchronization, resource 1. Inception Phase
sharing, reconfiguration, inter-object communications, In this phase, software management team is responsible
name-space management etc. for performing the following activities,
(i) Creating plan about elaboration phase.
(ii) Selecting team members so as to form a team.
(iii) Defining the terms and conditions for a contract.
(iv) Determining the architecture costs.
2. Elaboration Phase
In this phase, software management is responsible for performing the following activities,
(i) Creating plan about construction phase.
(ii) Recruiting the staff members.
(iii) Resolving the risk.
(iv) Determining the criteria for product acceptance.
(v) Determining the construction costs.
In this phase, software management team is responsible for performing the following activities,
(i) Creating plan for transition phase
(ii) Optimizing the construction plan
(iii) Performing risk management.
4. Transition Phase
In this phase, software management team is responsible for performing the following activities,
(i) Ensuring customer satisfaction.
(ii) Providing sales support.
(iii) Creating next generation plan.
Apart from these activities, software management team is responsible for,
(i) Making commitments for resources.
(ii) Ensuring stakeholder satisfaction.
(iii) Defining the scope for the software product.
(iv) Making plans and priorities.
(v) Handling risks incurred during software development.
(vi) Providing personal assignments.
(vii) Controlling the project.
(viii) Developing the following artifacts,
(a) Planning for software development
(b) Business ease
(c) Work breakdown structures
(d) Vision
(e) Assessing the status
(f) Requirement set.
Q14. How does the phases in the four teams evolve over the course of the entire project?
Answer :
The following table shows how the emphasis in the four teams evolve over the course of the entire project.
Q15. Discuss team management in detail.

Answer :
Team Management
Team management is the most significant aspect of project development because without team effort the software cannot be
developed. Therefore, in order to achieve productive and high quality software, team members must be effective and motivated.
The steps involved in team management are as follows,
1. Determining the team structure
2. Communicating with the team members
3. Formulating a team.
1. Determining the Team Structure
In this step, each member of a team is selected and assigned a role. Usually, a team consists of a project manager, developers,
configuration controller, database administrator etc. A team works under the supervision of a project manager and every member
of a team is accountable to him. Project manager inturn reports to the business manager.
Usually large projects contain one additional member called module leader. This module leader has some developers
under him and is answerable to the project manager. Defect prevention team is formed from the existing team members whose
responsibility is to perform the tasks related to defect prevention.
Each project has SQA (Software Quality Advisor) who is not answerable to the project manager, in fact it has an independent
reporting channel. SQA interacts with the project manager and configuration controller.
The responsibilities of a project manager are,
(i) To select a team that is balanced and self-reliant.
(ii) To assign roles to the team members. A team member can have multiple roles. For doing so, a project manager must take
into consideration certain factors such as,
v Information about each team member such as his skills, qualifications, experience etc.
v Monitoring and developing needs of the people.
It is not mandatory that the team and roles assigned to the team members remains constant throughout the project development
process. In fact, it changes according to the performance, personal aspirations and motivational levels.
2. Communicating with the Team Members
Communication among the members of a team is required because the team works as a single cohesive unit to achieve a
common goal. The team communication can be classified into two categories.
(i) Communication related to the project
(ii) Communication for stress-relieving.
(i) Communication Related to the Project
In this type of communication, the project manager informs all the team members about the status of the project i.e., progress
and problems of a project. This can be done by granting them (team members) the access to formal reports. These formal
reports includes project status, comments from customers and business manager. In addition to formal reports, project
managers can enhance the communication among team members through different methods as follows,
(a) By utilizing project website to publish documents, technical articles, notes and training material.
(b) By conducting training sessions for team members, meetings related to project briefings and issue resolution.
(c) By preparing notices, status reports, project specific bulletin for announcements and project mailing test.
The selection of any one of the above methods is purely dependent on the team size and duration of the project.
(ii) Communication for Stress-relieving
The communication which focuses on stress-relieving play a very important role during the project development because of
the shorter deadlines. The project managers must plan the events such as birthday parties, quizzes, games, project parties,
free-wheeling etc. These events are purely meant for relieving the stress of the team members.
3. Formulating a Team
It is the process of lending the support to the team members to enhance their performances. Many projects include junior
employees in a team. The performance of these employees can be enhanced by providing support from team and project manager.
Both project and organization are benefitted by the growth of each team member. The members will improve with their skills
and becomes more productive, these aspects can be utilized for the future projects. Project managers can use different method
to enhance the performance such as rotating the job, grouping experienced members with junior members, conducting reviews,
appraisals, feedbacks, coaching, training and helping the members facing debugging problems.
4.1.3 Evolution of Organizations

Q16. Explain about the software project team evolution over the life-cycle.
Evolution of Software Project Team

The project organization generally represents the team’s architecture. It is necessary to evolve the organization’s structure
so that it becomes consistent relative to the project plan, which is gathered in the work breakdown architecture.
The following are the set of activities that are focused in every individual phase:
1. Inception Organization
It is an organization where planning is considered important along with the support from other team so that an organization
can know if the plans define a general agreement of every perspective.
2. Construction Organization
It is an organization which is evenly balanced. The activities associated with this organization is present in the software
development team as well as software assessment team.
3. Elaboration Organization
It is an organization that emphasizes on architecture. In this organization, the project during activities is present in the
software architecture. These activities are not only supported by software development team but also by the software assessment
team. This support is required so as to obtain a balanced architecture baseline.
4. Transition Organization
It is an organization that emphasizes on customer. In this organization, the deployment activities are carried out by the
usage feedback.
Inception
Transition
Elaboration
Construction
Figure: Software Project Team Evolution
4.1.4 Process Automation

Q17. Discuss the three levels of process along with their automation support.
Level of Process
The following are three levels of process which requires certain degree of process automation so that every process is
performed efficiently.
1. Metaprocess level
2. Macroprocess level
3. Microprocess level.
1. Metaprocess Level
This level of process includes process policies, procedures and practices associated with an organization. These are present
so that it is possible to manage software oriented line-of-business. Infrastructure is the automation support required for this process
level. An infrastructure is nothing but a repository that consist of the following,
v Preferred tools 2. Environment Workflow
v Artifact templates The prerequisite for performing the iterative development
v Project performance guidelines process is that, both configuration management as well as
version control needs to be available.
v Microprocess guidelines
v Macroprocess guidelines etc. 3. Requirement Workflow
2. Macroprocess Level In traditional methods, system requirements are

decomposed into subsystem requirements, which inturn are
This level of process includes policies, procedures and
decomposed into component requirements. These component
practices associated with project. These are present so that, it
is possible to generate software product that lies within the requirements are further decomposed into unit requirements.
expected cost, quality constraints and schedule. Environment The engineering hours are discarded from the driving
is the automation support required for this process level. An requirements since all the requirements are treated in similar
environment refers to a predefined collection of tools that are fashion. However, this time was considered while carrying out
used to generate a set of artifacts as directed by a project plan. paper work related to the traceability. Later on, this well-defined
3. Microprocess Level traceability was removed, when change took place over the
driving requirement and subsequent design understanding.
This level of process includes policies, procedure and
practices associated with project team. These are present so that In contrast to traditional approaches, the modern
it is possible to achieve software process artifact. Tool is the approach represents the system requirement in the form of
automation support required for producing an artifact. Tools vision statement. Requirement at the lower level are carried
include, out by the process which are organized by iteration. However,
(i) Change management these requirements are not driven by lower-level components.
These components are usually in the form of evaluation
(ii) Metrics automation
criteria that are generally represented by a set of use cases.
(iii) Visual modeling This criteria is generated not only from the vision statement
(iv) Document automation but also from the other sources like architectural consideration,
(v) Metrics automation risk management concerns, make/buy analysis, implementation
constraint etc. The evaluation criteria are represented in the form
(vi) Workflow automation.
of release specification artifacts. These artifacts are nothing
Q18. What are the tools available to automate the but a temporary snapshot of objectives associated with a given
software development process? iteration. The vision statement seizes the agreement that is made
OR between the development group and the buyer. It is necessary to
Discuss about automation building blocks. change the captured information across the software life cycle.
This evolved information should be represented in such a way
Answer : (Model Paper-II, Q8(b) | Nov./Dec.-16(R13), Q9(b)) that it becomes very easy for a buyer to understand it.
Tools for Software Development Automation Process The advantage of iterative models is that the customer
There are many tools available for performing software as well as the developer are allowed to work with changing and
development automation process. These tools are required tangible system’s version.
globally around every software project and also across those
projects that are associated with the process framework. The It is necessary that requirement must change in
following are different process workflows along with their accordance to the architecture and also according to the changing
respective automation tools, application set increments.
1. Management Workflow Because of this, the customer and the developer can
Project planning and control activities associated with have a common understanding about the preferences, schedule/
the management workflow can be automated in numerous performance tradeoffs related to the requirement.
ways. Inorder to generate the planning artifacts, software cost It is necessary for a project to concentrate on proper
estimation tool and WBS (Work Breakdown Structure) tools are project vision specification instead of concentrating on the
employed. On the other hand, for carrying out plan management
consistency, completeness and traceability folder of associated
workflow, management tool and software project control panel
with the specification of undeveloped requirements. Projects
are used. The software project control panel is responsible for
maintaining status report about the assessment result of the must also focus on the low-level specification evolution by
project online. The advantage of this automation support is that, considering the successive evaluation criteria set.
there is a significant improvement in the metrics collection’s The impact of this modern approach on the environment
insight and reporting concepts. support is as follows,
(i) The proposed requirement approach relies on both textual
as well as model-based representation. It is necessary that Process Workflow Environment Tools and Process Automation
the environment needs to provide integrated document
Management Workflow automation, metrics automation
automation and visual modeling technique. These are
required for representing the textual specification and Environment Change management, document automation
usecase models. Changes need to be managed and Requirements Requirements management
monitored so as to format or present those changes in a
format which is easily understood by a human. Design Visual modeling
(ii) The traceability factor which lies between requirement Implementation Editor-compiler-debugge
and other artifact needs to be automated. In order to
test the artifact, a high-level of detailed traceability is Assessment Test automation, defect tracking
required by the requirement set artifact. This is because Deployment Defect tracking
the assessment team is completely responsible for
illustrating the level of compliance associated with the
Process Organization Policy
product along with the requirement. It is not necessary
to have a well-defined tight traceability between the
requirement set artifact and other technical artifacts.
Life cycle Inception Elaboration Construction Transition
For example, the traceability between the problem space
description, solution space description that are captured
in the requirement set artifact and other technical Figure: Tools for Supporting Process Workflow
artifact respectively, is very difficult to be represented. Q19. What are the three discrete states of the project
However, if a strong traceability is required between environment? Also discuss the four environ-
the requirement and design workflow, then there is a ment disciplines that are critical to the manage-
possibility that the architecture may change in such a ment.
way that requirement traceability is optimized but not
the design integrity. Answer :
4. Design Workflow States of Project Environment
All the tools required for supporting the requirement, The three discrete states of project environment evolution
design, implementation as well as assessment workflow are used are,
together. The basic tool that is required for design workflow is
visual modeling. This tool performs the following activities. 1. Prototyping environment state
(i) Captures the design models 2. Development environment state
(ii) Present those models in a human-readable format 3. Maintenance environment state.
(iii) Convert the models into source code.
1. Prototyping Environment State
5. Implementation Workflow
In this environment state, the prototyping of project
The implementation workflow is dependent basically architecture is carried out by using tested architecture available
on the programming environment that include editor, compiler, in this state. This prototyping is done so as to estimate the trade-
debugger, linker, run-time. In addition to this, the workflow off’s taking place during both inception as well as elaboration
should also integrate significantly with the following tools in phases of software life cycle.
order to support productive iteration.
(i) Change management tool The following activities need to be supported by this
informal configuration of tools,
(ii) Visual modeling tool
(i) Analyzing the technical risk and the performance trade-
(iii) Test automation tool.
offs.
6. Assessment and Deployment Workflow
(ii) Conducting feasibility study and determining make/buy
Assessment workflow requires extra capabilities inorder trade off for commercial product.
to support test automation and test management. Testing and
document production needs to be automated so as to increase (iii) Identifying the trade-off’s associated with fault tolerance
the change freedom. or dynamic reconfiguration.
Defect tracking is another essential tool for supporting (iv) Analyzing the risk involved in transitioning a project to
assessment workflow. This tool is responsible for providing its full-scale implementation.
change management instrumentation which is required to
perform metrics and control release baseline’s automation. This (v) Analyzing the requirements suitable for the development
tool is even required in supporting the deployment workflow. of test scenario, tool and instrumentation.
2. Development Environment State
The prerequisite for the development state is that it should consist of complete set of development tools. These tools are
required for supporting,
(i) Different process workflows like requirement, design, implementation and assessment.
(ii) Round-trip engineering.
3. Maintenance Environment State
This environment should occur simultaneously along with a fully-developed version of development environment.
In some situations, maintenance environment can be considered as a part of the development environment which is provided
as a form of resultant end product of project architecture.
The changes taking place in the fully-developed software process produces new issues and opportunities for managing
the control of concurrent activities. It also allows assessing of tangible (manifest) improvement progress as well as quality. The
environment that is integrated to maximum extent is required to assist and apply process management control policies.
The following are the four environment disciplines (rules) that are critical not only to the management but also to the
progress of modern iterative process,
(i) Tools need to be integrated inorder to retain the consistency and traceability requirement. This is achieved by using an
environment support referred to as Round-trip engineering. These requirements are defined by Round-trip engineering for
those environments that support iterative development process.
(ii) Change management needs to be automated and implemented inorder to manage several iteration and to allow change
freedom. Change is considered as the underlying primitive of modern iterative development process. As planning is very
essential factor of iterative process same is the change management. The changes taking place in the technical artifact
makes it very difficult to understand the trends associated with technical improvement and quality which are required so
as to release an end product that is acceptable.
(iii) Organizational infrastructure allows the project architecture environment to be generated from a common base of processes
and tools. This infrastructure assists to,
v Attain interproject consistency
v Reuse training concepts
v Reuse lessons learnt.
(iv) Stakeholder environment facilitate support for performing electronic (paperless) information exchange and to effectively
analyze the engineering artifacts.
Q20. Discuss the significance of round trip engineering.
Answer : Oct./Nov.-20(R16), Q4(a)
Round-trip Engineering
A high level of automation support is required whenever a software organization maintains distinct information set as-
sociated with engineering artifacts. This level of support is required inorder to guarantee efficient and error-free data exchange
between the artifact. To achieve this consistency between the engineering artifacts, Round-trip engineering which is an environ-
ment support is required,
Automated production Traceability link
Automated distribution links

Portability among platforms and networks
Design set
Forward Engineering
Reverse Engineering
Requirement set
UML Models
UML Models
Deployment set
topologies
Executable code
Implementation
set
Source code
Automated build management
Figure: Round-trip Engineering
The above figure shows the essential transitions oc- Fields of Software Changes Order
curring between the information repositories. The technique
The following are the fundamental fields of software
of automated transition is applied to design models inorder to
change order
translate them into respective source codes and process models.
This is a well-established straight-forward phenomena which is 1. Title
made possible through applications like Active -X, and CORBA. 2. Problem description
The automated translation of source code into execut-
able code is made possible using compilers and linkers. The 3. Metrics
development of architecture is initiated by taking into account 4. Resolution
different components, languages. Because of this, complexity
arises while constructing, managing and handling large-scale 5. Assessment
webs. This complexity leads to the establishment of newer 6. Disposition.
requirement for both configuration control and build manage-
ment automation. 1. Title
Round-trip engineering is basically carried out so as to An originator is responsible for deciding the software’s
allow change freedom in data sources belonging to software title which is sent to Configuration Control Board. Upon receiv-
engineering. The configuration control associated with every ing the approval, the title is finalized. A reference to a software
technical artifacts is important inorder to maintain the consist- problem report, which is external should be included only if an
ency and error-free presentation of the changing product. It external person like user initiated the change.
is not mandatory that Round-trip engineering should consist
2. Problem Description
bidirectional translations. For example, the test cases must be
designed for defining logical object set. However in this situ- The following subfields are included in the problem
ation, it is not possible to perform reverse engineering on the description field,
object simply from the test-cases.
(i) Originator’s name
The drawback of automated translation between the
data sources is that 100% completeness (i.e., accuracy) is not (ii) Originator’s date
achieved. For example, the automated translation of design (iii) SCO identifier assigned by CCB.
model into C++ source code may generate just the structural
and declaration information of source code presentation. (iv) Relevant version identifier of associated support
software.
Q21. Discuss about the change management in proj-
ect environment. The problem description should be in a greater detail
Answer : which should also consist of attached code excerpts, error
Change Management messages, display snapshots and other data that assist in prob-
lem identification or assist in describing the changes that are
Change management keeps track of the changes to ac-
required.
cess the progress trends and quality trends towards achieving an
acceptable end product or interim release. Change management 3. Metrics
is crucial to modern development process because it results in
Metrics gathered for every individual SCO’s are essential
iterations and hence needs to keep track of the progress in each
for performing following activities,
iteration.
(i) Software Change Order (i) Planning
For answer refer Unit-IV, Q22. (ii) Scheduling
(ii) Configuration Baseline
(iii) Analyzing quality improvement.
(iii) Configuration Control Board This field consist of different change categories. They are,
For answer refer Unit-IV, Q25(a). Type 0 : This change category represents critical bug.
Q22. Explain in detail about software change orders. Type 1 : This change category represents bug.
Answer : (Model Paper-III, Q8(b) | March-17(R13), Q9(b))
Type 2 : This change category represents enhancement.
Software Change Orders (SCO)
Software change order refers to the atomic component of Type 3 : This change category represents new features.
software work that is allowed to create, alter the component pres- Type 4 : This change category represents other features.
ent inside a configuration baseline. The main purpose of SCO is to
divide, assign and schedule the software work against a software Metrics field comprises of six different items. Out of
baseline which is well-established. Apart from this, SCO is an which, the first two items fall under the category of initial esti-
important approach for analyzing the product improvement as well mate and the remaining under the actual rework and expended
as it’s quality. category. The six items are as follows,
(i) Breakage (i) Proposed
It estimates the amount of changes made and is defined in In this state, the SCO is being written.
unit SLOC, files, component. If SLOC is used for defin-
(ii) Accepted
ing the extent of change, then a simple estimate of break-
age can be quantified by simply comparing the source In this state, the CCB approved the SCO for resolution.
file. This comparison program estimates the amount of (iii) Rejected
difference so as to provide the breakage estimate.
In this state, the SCO is closed along with the following
(ii) Rework reasons that SCO is
It estimates the amount of complexity that arises while v Not a problem
changes are made.
v Is a duplicate
(iii) Analysis
v Is an absolute change
It estimates the staff hours utilized inorder to comprehend
the changes that are required. v Resolved by another SCO.
(iv) Implement (iv) Archived
It estimates the amount of time (i.e., staff hours) required In this state, SCO is accepted but postponed until it’s
for designing and implementing the resolution. later release.
(v) Test (v) In Progress
It estimates the amount of time (i.e., staff hours) utilized In this state, SCO is assigned to the development orga-
in testing the resolution. nization that resolves the SCO actively.
(vi) Document (vi) In Assessment
It determines the amount of effort required for updating In this state the SCO resolved by the development organiza-
other artifacts like user manual or release description. tion is assessed by a test organization.
4. Resolution (vii) Closed
It comprises of following information, person’s name In this state, the SCO is resolved thoroughly with an
who is responsible for implementing the change approval from all the members of CCB.
v The components that are changed Title :
v The actual metric Description

Name: Date:
v Change description.
It is possible to estimate the component fidelity level Project:
using which the change references can be monitored. Despite
of this, the component reference with the lowest level should Metrics Category:
(0/1 error, 2 enhancement,
be maintained at the level approximately equal to the allocation 3 new feature, 4 other)
Initial Estimate Actual Rework Expended
level. Breakage: Analysis: Test:
5. Assessment Rework: Implement: Document:
Assessment technique can be considered as one of the Resolution
following,
Analyst:
v Inspection Software component:
v Analysis
v Demonstration Assessment
(Inspection analysis,
v Test. Method:
Demonstration, test)
Assessment field is not applicable for every SCO. But
when applicable, it is necessary to provide reference not only to Tester: Platforms: Date:
existing test cases but also to the new test cases that are executed.
Disposition
In addition to this, it should be capable of identifying different State: Release: Priority:
test configurations that include platform, compiler, topologies.
Acceptance: Date:
6. Disposition
Closure: Date:
Configuration Control Board assigned the following
states to SCO, Figure: Essential Components of SCO
Q23. What are the sources of change? Why should Levels of Baseline Releases
change be made in a controlled way? The three levels of baseline releases are,
Answer : (i) Major Release
Sources of Change It specifies the new product/project generation. The major
The sources of change are as follows, release number is denoted by N.
(ii) Minor Release
(i) New business or market conditions impose the changes
in business rules and requirements of the product. It specifies the same basic product but with extended
features, performance or quality. The minor release
(ii) The new needs demanded by the customers, causes the
number is denoted by M.
changes to the data generated by the information systems,
products functionality and the system services. (iii) Interim Release
(iii) Reorganization produces any modifications done to the It is in accordance with the transient developmental
team structure and project priorities. configuration. The interim release identifier is represented
as X.
(iv) Constraints in budgeting and scheduling requires a
product or a system to be redefined. Note
Major and minor releases are the persistent external
The changes must be made in a controlled manner be-
product releases for a particular period of time. Once a controlled
cause,
baseline is created for a software, all the changes can be
1. Once SCO (Software Change Order) is in a controlled monitored.
environment, it can’t be altered by anyone without any Categories of Project Changes
prior authorization.
1. Type 0
2. The new version is used by many other members for the
correct software implementation. It refers to the critical failures that are fixed before the
external product releases. It effects the software usability
3. By making the changes in a controlled way, the older in its critical use cases.
version is not destroyed.
2. Type 1
4. The changes in a controlled environment can be rolled
This type of errors don’t produce any negative effects
back, if required.
on the usefulness of the system but corresponds to the
5. A modification log is kept which signifies the start and problems in the critical use cases and causes serious
end of a change. defects in the secondary use cases with a low probability
6. A change in a controlled way reduces the mistakes and of occurrence.
catches the errors encountered in the early stages of the 3. Type 2
project development. It is the change that causes the performance improvement
7. Sometimes the changes in one document causes the rather than responding to a defect. Its sole purpose is to
changes in the other dependable document. So, it must upgrades the performance, usability, testability.
be altered in a controlled way. 4. Type 3
8. The source code which is the exact representation of It is a change that results from updating the requirements
the executable version may not exist any more, if the thereby producing new additional features.
changes are not controlled. 5. Type 4
Q24. Explain in detail about configuration baseline. The changes that don’t fall in any one of the above
Answer : mentioned categories are called type 4 changes.
Configuration Baseline Example
A specified collection of software components and Documentation, version upgradation etc.

its associated documentation, depending on the changed Q25. Write short notes on,
management and that can be maintained, updated, tested and (a) Configuration Control Board (CCB)
status as a single unit is called a configuration baseline.
(b) Organization’s Infrastructure.
Two types of configuration baselines are,
Answer :
1. External product releases and (a) Configuration Control Board (CCB)
2. Internal testing releases CCB consists of group of people that act as a decisions
A configuration baseline is usually controlled and is authority to make decisions associated with the information of
wrapped and exchanged between the groups of components. configuration baselines. It generally consists of following members,
(i) Software manager The resolution process of SCO is completed after entire
solution is achieved by the responsible person. This solution
(ii) Software architecture manager
is then submitted to the independent test team to carryout
(iii) Software development manager assessment.
(iv) Software assessment manager 4. In Assessment
(v) Stakeholders. When the entire solution is received by independent test
All the above members are essential for maintaining team, it is analyzed to determine whether the SCO is resolved
the controlled software delivery system. Every decision that a completely or not. The SCO is submitted to CCB, only if the
CCB makes is done by conducting board meeting, performing test team verifies that the SCO is satisfactorily resolved. Upon
online distribution. The project is considered for use only if the receiving the SCO, the CCB performs final disposition and
CCB’s decision is approved. The prerequisite for carrying out closure.
iterative development process is that, it should contain complete 5. Closed
and accurate change management associated with the changing
software baselines. Inorder to control the software development When the development organization, independent test
process and maintenance activities, the following sequence of organization as well as Configuration Control Board agrees that
states that are traversed by an SCO are considered. the SCO is completely resolved, then it is changed to a closed
state.
1. Proposed
(b) Organization Infrastructure
A proposed change that consists of problem description
as well as resolution effort estimation is designed and submitted The organization infrastructure issues the capital assets
to Configuration Control Board. of organization along with two important artifacts,
2. Accepted, Archived (or) Rejected 1. Organization policy
The proposed change that is designed, is assigned with 2. Organization environment.
a unique identifier. The CCB has the authority to either accept,
archives or reject the proposed change. These two tools are considered as automation building
blocks using which it is efficient as well as economical to
v Acceptance configure the project environment.
It consists of transition (changes) required for resolution 1. Organization Policy
to be used in the next release.
Organization policy consists of standards used for project
v Archiving software development process. It is generally bundled as a form
It accepts the changes but delays it for resolution to be of handwork that describes the project life cycle and also the
used in the future release. process primitives like major milestones, metrics, roles and
responsibilities, intermediate artifacts. Apart from this, it also
v Rejection
provides common structure that gives solution to the following
It performs the following, queries,
(i) Verifies that changes made are without merit. v What is being performed? (activities and artifacts).
(ii) Verifies that changes are redundant with some other v What does activities and artifacts performed? (associate
proposed changes. them with the software life cycle phases and milestones)
Before accepting the SCO, it is the responsibility of CCB v Who is responsible for performing it? (team roles and
to check whether every field of SCO is correct and accurate. responsibilities)
Once the verification is performed, SCO is then assigned to a
responsible person present within the development organization. v How is it possible to know the frequency of activities
and artifacts? (check points, metrics and performance
3. In Progress standards).
The person who is assigned with the SCO is responsible Stabilization is very important factor that needs to be
for analyzing, implementing and testing a solution so as to considered while defining the organizational policy. Mostly,
satisfy the SCO. The following activities are included in this many organizations end up at either of the following two
task, extremes,
v Document updation 1. Institutionalized process is not available.
v Release note
2. The level of standardization and bureaucracy.
v SCO metrics actual
The following are the themes that occur continuously in
v Submitting new SCO’s an effective organization policies.
The themes are short and brief and usually elude those On the other hand, it is very difficult to provide standardization
policy statements that fills in document of thickness 6-inches. support across line-of-business because there is no commonality
among the tools, techniques, methods and stakeholder culture.
The themes restrict the policies to the real and actual
The level of standardization should be balanced i.e., it should
shalls later, then implement the policies.
neither be too high nor too low. If standardization is performed
The usage of the term “should” is avoided. Instead the across the areas that have commonality, then it will lead to
theme uses the option menu (should). It is necessary that process either policy statement which is very much diluted or to a lower
needs to have a concise set of shalls (i.e., mandatory standards). process which is used very oftenly.
The themes consider waivers as the exception, but not Organization policy is considered as the defining document
the rule. for the software policies associated with an organization. While
The correct and appropriate policy is written at the performing process assessment, organization policy is treated
appropriate level. as tangible artifact that helps to know what actually should be
performed. Using this defining document, the reviewer must be
Levels of Organization able to query and review the projects.
There are three different organizational levels in many 2. Organization Environment
software-oriented organization, each of which have their unique
policies. The main purpose of organization environment is to
automate the default process. This environment provide solution
(i) Strategic (Highest) Organization Level to know how things are performed and also provide different
This level of organization consists of standards that tools and methods inorder to perform process automation.
promote, The following are some of the components belonging to the
automation building block organization.
v Improvements related to strategic and long-term process
v Standardized tool solution is a component which
v Education as well as common technology insertion enhances the common workflows as well as a higher
v Compatibility that exists between the project and ROI on training.
performance related to business components. v Standard notation for representing the artifacts like
v Essential quality control. UML for design model, Ada-95 for custom developed
implementation artifacts.
(ii) Tactical Intermediate Line-of-Business Level
v Tools that are necessary like existing artifact template
This level of organization consists of standards that
or customization.
promotes,
v Activity templates that include CCB, major milestone
v Improvements related to tactical and short-term
activities, iteration planning.
processes.
The following are other components used by the
v Domain oriented technology insertion as well as training.
organizations building blocks,
v Components, tools, training, personnel experience reuse.
(i) Reference Library
v Observance of organizational standards.
This library consist of precedent experience inorder
(iii) Operational (Lowest) Project Level to plan, assess and improve the process performance
parameters.
This level of organization consist of standards that
promote, (ii) Existing Case Studies
v Effectiveness while attaining quality, schedule and cost It also consists of objective benchmark associated
targets with the performance for successful completion of
software project. These are the projects that followed
v Project-oriented training the organizational process.
v Observance of customer requirements (iii) Project Artifact Library
v Observance of organizational/business component It includes software development plans, architecture
standards. description.
Standardization must concentrate mostly on the (iv) Mock Audit and Compliance Traceability
intermediate line-of-business level rather than on the
organizational or project level. Standardization support is This component is used for analyzing external process
effective in business level in which the degree of commonality structure like SEL CMM (Software Engineering Institute
as well as reuse among the project tools and processes is high. Capability Maturity Model).
Q26. Illustrate the extension of environments into the stakeholder domains.
Answer :
The changes made to the current iterative development process along with automation support should not be restricted
to the development team. Many large scale contractual projects involve people from external organizations. These are usually the
stakeholders who are involved in the development process.
These organizations comprise of the following stakeholders representatives,
v Procurement agencies, contract monitors
v End-user engineering support personnel
v Third-party maintenance contractors
v Independent verification and validation contractors
v Representation regulatory agencies.
It is necessary for these representatives to access the resources belonging to the development environment. This is because,
it is possible for the representative to contributes value to the entire effort. Paper is preferred as a means for information exchange,
whenever an external stakeholder fails to access the environment resources generally used to accept online products artifacts.
If online environment is accessed by the external stakeholder, then it is possible for these stakeholders to participate in the
development process in the following manner,
1. Acquire and utilize the executable increment so as to carryout manual evaluation.
2. Utilize the online tools, data as well as reports that were used by the software development organization inorder to manage
and keep on the project.
3. Avoid paper interchange delays, paper and shipping loss, excessive trainer cost and other overhead costs.
Reasons for Extending Development Environment Resources Specific Stakeholder Domains
1. Technical artifacts are both non-electronic and electronic artifacts. If electronic artifacts are represented in exact notation
like source code, visual models, then they can be viewed in an efficient manner. Tools along with the smart browsers are
used for this purpose.
2. Independent assessments used for artifact evolution are preferred not only by electronic read only access but also by online
data like configuration baseline and change management database.
The following activities can be performed independently without any involvement of the development team,
v Review and inspection
v Breakage/Rework assessment
v Metrics analysis
v Beta testing.
3. Paper documents need to be delivered electronically so as to decrease the production cost as well as from around time.
The advantage of accessing the environment resource electronically by the stakeholder is that the feedback which is
continuous and expedient becomes more efficient, useful as well as definite. It is very essential for a development team to
construct an environment so as to implement the shared environment. This development team should also provide sufficient
resources so as to support customer’s access. The stakeholder must perform the following activities
(a) Avoid misusing customer’s access
(b) Participate in the access by adding value
(c) Avoid interrupting development
The following are the problems that are encountered while extending environment resources into certain stakeholder
domains,
v Who is responsible for capitalizing the environment and tool investment?
v How safe is the information exchange?
v How is it possible to synchronize the change management?
v How much access freedom is provided?
Stakeholder Environment
Management
Development Environment
Artifact Releases
Management
Ele
Ex ctron
ch
an i c Workflow automaton, metrics automation
ge
Tool Subset Change management, document automation
Requirement management
Visual modeling
Editor-compiler-design
Stakeholder Activities Test automation, defect tracking
• CCB participation Defect tracking
• Test Scenario development
• Risk management analysis Environment Tools and
• Metrics tend analysis Process Automation
• Independent alpha and beta
testing
Figure: Extending Development Environment into Stakeholder Environment

4.2 Project control and process Instrumentation
Q27. What are the central management issues of complex software? Explain.
Central Management Issues of Complex Software

The main objective of modern software development process is to handle the central management issues of a complex
software. The various central management issues are,
1. Difficulty in developing correct design
2. Difficulty in managing and handling risk
3. Difficulty in reducing complexity
4. Difficulty in making software progress and quality tangible
5. Difficulty in automating the overhead and book keeping activities.
1. Difficulty in Developing Correct Design
It was very difficult for an organization to develop an appropriate design of the complex software using conventional
software process. However, modern software development process solved the issue by initially focusing on the architecture i.e.,
by employing architecture first approach.
2. Difficulty in Managing and Handling Risk
The conventional software development process encountered many risks while developing a software project. This process
failed to handle or manage the risks which inturn led to the development of an unsuccessful project. The modern development
process on the other hand was capable of managing the risk by employing iterative development process, where every activity is
sequentially handled depending on the position of iteration in the development cycle.
3. Difficulty in Reducing Complexity Indicators
The level of complexity during the development process An indicator is a metric or a group of metrics that
of software project using conventional software process was provides an interpretation of the software process or software
very high. This process however, did not find any sort of product or a software project. A software engineer assembles
mechanisms that can reduce the level of complexity. Due to measures and produce metrics. The indicators can be derived
this project personnel faced difficulty while developing the from these metrics.
software project. The complexity issue can be reduced in modern
development process by employing different component based There are two types of indicators,
techniques which inturn reduces the complexity of source- (i) Management indicators
language so as to achieve a better software solution.
(ii) Quality indicators.
4. Difficulty in Making Software Progress and Quality
Tangible The management indicators are used to determine
whether a project is on budget or on schedule. The management
In conventional software process all the software metrics indicators that indicate financial status are based on earned value
were computed manually i.e., this process required huge labour system. Example technical progress, financial status and staffing
work. The drawback of employing manual procedure is that the progress
software project developed will have very limited success i.e.,
the progress and quality of software is very low. The quality indicators are based on the measurement of
the modification done to the software.
The modern development process established a change
management environment that made software progress and Q29. What are the seven core metrics? Explain.
quality tangible. Change is considered as the underlying March-17(R13), Q10(a)
primitive of modern iterative process. As planning is very
essential factor of iterative process, same is the change OR
management. Explain about seven core metrics.
5. Difficulty in Automating the Overhead and Book (Model Paper-II, Q9(a) | Nov./Dec.-17(R13), Q10)
Keeping Activities
OR
In conventional software process all the information
regarding the intermediate products were stored in form of paper Discuss the four quality indicators in managing
documents i.e., all the activities of book keeping were done a modern process. Oct./Nov.-20(R16), Q4(b)
manually, due to which only 10% of successful projects were
(Refer Only Topic: Quality Indicators)
delivered within the estimated budget and schedule. The modern
iterative development process solved the issue by automating OR
the overhead and book keeping activities by employing round-
trip engineering that guarantees efficient and error-free software What are management indicators? Explain.
project. (Refer Only Topic: Management Indicators)
4.2.1 The Seven Core Metrics Answer : Nov./Dec.-16(R13), Q11(a)
Q28. What is the need for metrics? What do you mean Conventional software process face problem in making
by indicators? the quality and progress of the software tangible through
instrumented change management. Software metrics perform
Answer :
the instrumentation of the software development activities
Software Metrics and products of the integration process. In modern software
development process, these software metrics are simple. There
Software metrics are used for the implementation of the
are seven core metrics used for managing a process. Out of
activities and products of the software development process.
seven metrics, three are management indicators and four are
It determines the quality of the software products and the
quality indicators.
achievements in the development process.
Core Metrics
Need for Software Metrics
1. Software metrics are required for calculating the cost These metrics are used for managing a process.
and schedule of a software product with much accuracy. 1. Management Indicators
2. They are required for making an accurate estimation of (a) Work and progress
the progress.
(b) Budgeted cost and expenditure
3. They are required for understanding the quality of the
software product. (c) Staffing and team dynamics.
(a) Work and Progress (v) Cost Variance
Determining a planned estimation of the work and then It is the difference between the actual cost and the
monitoring progress against the plan. earned value i.e.,
Purpose Cost Variance = Actual Cost – Earned Value
The purpose of this indicator includes iteration planning, If cost variance >0, then it leads to the over-
plan versus actual and management indicator. budgeted situations.
Perspectives If cost variance <0, then it leads to under-budgeted

situations.
(i) Software Architecture Team
(vi) Schedule Variance
Demonstration of the use-cases.
It is the difference between the planned cost and
(ii) Software Development Team the earned value.
Source line of code under baseline change Schedule Variance = Planned Cost – Earned Value
management and closing the software change If schedule variance >0, then it leads to the behind-
orders. scheduled situations.
(iii) Software Assessment Team If schedule variance <0, then it leads to the ahead
Software change orders are opened followed by the of schedule situations.
execution of test hours, till the evaluation criteria Perspectives
is met.
The perspectives of this core-metric are,
(iv) Software Management Team v Cost per month
Completion of milestone. v Percentage of splendid budget
(b) Budgeted Cost and Expenditure v Full-time staff per month.
Measurement of the cost expenditures is required (c) Staffing and Team Dynamics
throughout the project life cycle for providing
It refers to the changes in project personnel over time.
management control.
The maintenance team is assumed to be smaller than the
Purpose development team for software development.
It includes financial insight, management indicator and Purpose
plan versus actual. Financial progress monitoring can The main purpose of this management metric is resource
be achieved by using the earned value system which planning versus actual resources, rate of hiring the
provides the clear understanding of cost and schedule personnel and deterioration rate.
of a project. The basic parameters of an earned value
system are, Perspectives
(i) Expenditure Plan The main aspects of this metric includes,
It specifies the planned expenditure over a planned v Number of persons added per month.
schedule for a project. This monitors the staffing v Number of persons leaving per month.
profile.
2. Quality Indicators
(ii) Actual Progress (a) Traffic change and stability
It is the technical achievement based on the planned (b) Breakage and modularity
progress. It follows the planned progress in a
successful project. (c) Rework and adaptability
(iii) Actual Cost (d) Mean time between failures and maturity.
(a) Traffic Change and Stability
It is the actual cost expanded over an actual
schedule in a project. It closely follows the planned This is one of the most important quality indicators.
profile in a successful project. It is defined by the number of SCOs opened or closed
during the project life cycle. Along with this the ‘work
(iv) Earned Value
and progress metric’ helps to determine the stability of
It is the value that represents the planned cost of the software. Stability is the measure of opened versus
the actual progress. closed Software Change Orders (SCOs).
Purpose Q30. What are the advantages and attributes of the
The main purpose of this metric is iteration planning and seven core metrics?
the management indicator of schedule convergence. Answer :
Perspectives
Advantages of Seven Core Metrics
Number of SCOs opened versus SCOs closed, by type
(0, 1, 2, 3, 4), by component release or subsystem. The advantages of seven core metrics are as follows,
(b) Breakage and Modularity 1. Abilities of an organization or a project is to predict cost,

schedule and future-work can be improved.
Breakage denotes the average change i.e., the amount
of software baseline that has to be reworked. 2. Management indicators help the management and
Modularity refers to the average breakage tendency over engineering teams in assessing the following,
time. (i) Funds of the project
This quality indicator specifies both the gentle or (ii) Schedule of the project
malignant character of software change.
(iii) Actual progress with greater accuracy.
Purpose
Includes convergence, quality indicator and software 3. Quality indicators are useful for,
scrap. (i) Measuring the software change
Perspectives
(ii) Emphasizing more on the quality of the product
SLOC reworked per change, by release, component or
subsystem and by type (0, 1, 2, 3, 4). (iii) Providing an insight view of the rework
measurement
(c) Rework and Adaptability
4. They are very simple, objective and collected and
Rework is the average cost of change i.e., the effort
interpreted easily.
to analyze, rectify and retest the changes made to the
software baselines. 5. Core metrics can be collected both on automated and on
Adaptability is the tendency to rework over time. Product non-intensive basis.
maintainability is suspected when the rework trends are Attributes of Seven Core Metrics
increasing with time.
The seven core metrics are,
Purpose
It includes convergence, quality indicator and software (i) Work and progress metrics.
rework.. (ii) Budgeted cost and expenditures metrics.
Perspectives (iii) Staffing and team dynamics metrics.
Average hours per change by release, component or
(iv) Change traffic and stability metrics.
subsystem by type.
(d) Mean Time between Failures (MTBF) and Maturity (v) Breakage and modularity metrics.
MTBF refers to the average usage time that occurs (vi) Rework and adaptability metrics.
between the software faults.
(vii) MTBF (Mean Time Between Failures) and maturity
(or) metrics.
It is the result of ratio of test hours by the number of type Out of these, first three metrics are management
0 and type 1 software change orders. indicators (metrics) and last four metrics are quality indicators
Maturity refer to the MTBF tendency over time. (or) metrics.
Purpose The common purpose of all these indicators is the proper
The main purpose includes test coverage, quality management of different projects as well as organizations.
indicator and robustness for the use. Various attributes of the above core metrics are,
Perspective
1. The seven core metrics are uncomplicated in nature.
The main aspects of this metric includes,
2. These metrics are easy to understand. In other words,
v Failure counts there will be no problem of misinterpretation by using
v Test hours till the occurrence of failures the seven core metrics.
v Release, component or a subsystem. 3. Gathering these metrics is not a very difficult task.
4. Each and every metrics is easy to observe. 6. Schedule Variance
5. The seven metrics plays a very important role in It is the difference between the planned cost and the
managing the staff of various organizational departments earned value. Positive values leads to behind schedule
in a consistent manner. situations and negative values to ahead of schedule
6. The metrics are not collected manually so that there is no situations.
effect on the quality or the performance of the project. (iii) Backup Plan
This means the mode of metrics collection is automated.
In other words metrics collection does not interfere with A backup plan provides a detailed information about
the activities of software developers. how the risk will be solved and what are the changes that must
7. Judgements made by the metrics in the entire software be applied to the team organization and the project schedule.
life cycle are not based on someone ideas or opinions A backup plan is also needed even when the risk involves the
but on the emerging needs of the software. factors that are not under the control of the project team.
Goals of the Backup Plan

4.2.2 Management Indicators
Q31. Write short notes on the following, v Determine what are the risks that exists in a software
project and when they can be known.
(i) Management indicators
v Make a plan for the effects and consequences of the risk.
(ii) Earned value analysis
(iii) Backup plan v Inform the team about the potential changes that occurs
in the project due to the risk impact.
(iv) GANTT chart.
Steps for Creating a Backup Plan
Answer :
v Analyze the risks that are included in the software
(i) Management Indicators
development plan.
For answer refer Unit-IV, Q29, Topic: Management
Indicators. v Identify when and how each risks can be recognized.
(ii) Earned Value Analysis v Assign a team for each risk to collect the information
and evaluate it, if it really occurs.
An earned-value system measures the financial
performance of the project life cycle. It provides the detailed v Analyze the effects of the risk and determine the team’s
cost and schedule information. However, it does not evaluate action under each risk impact.
the technical progress accurately. It is good for the production
stage. The basic parameters of an earned value system includes v Designate these actions as one or more backup plans.
the following,
(iv) GANTT Chart
1. Expenditure Plan
The process of creating a schedule for a software project
It is the organized and planned profile of spending for a begins with a set of tasks by taking the work break down as
project over its organized schedule. input, when automated tools are used. The effort, start date and
2. Actual Progress duration are then inputted for each task. A GANTT Chart (also
known as a time line-chart) is then created for the entire project.
It is the technical achievement with respect to the planned Gantt charts can be created for each individual working on a
progress. project or for each project function.
3. Actual Cost
All the tasks are then listed and are placed at the left-
It is the actual profile of spending for a project over its hand column of the Gantt chart. In the Gantt chart, as shown
actual schedule without revealing the spending profile. in the following figure, the horizontal bars represents the task
4. Earned Value duration and the diamond shaped boxes indicates the project
mile stones. Task concurrency occurs when many bars occur at
It is the value which specifies the organized or planned the same time.
cost of the actual progress.
After inputting the necessary information for a Gantt
5. Cost Variance chart, the software project scheduling tools produces the “project
It is the difference between the actual cost and the earned tables” which are the tabular representations of the project tasks
value. Positive values of the cost variance represents the along with the planned and actual start-and end-dates and the
over-budgeted situations whereas negative values leads other information. The Gantt chart along with the project tables
to under-budgeted situations. helps a project manager to keep track of the project progress.
Figure: GANTT/Time-line Chart
4.2.3 Quality Indicators

Q32. Define quality indicator. Explain different types of quality indicators.
OR
What are the software project quality indicators? Explain them.
Answer : (Model Paper-III, Q9(a) | Dec.-19(R16), Q8)
Quality Indicator
A measure that is calculated by assessing the characteristics of a system in order to indicate its quality is known as quality
indicator. Quality indicator is not the actual code, it only defines the code properties appropriate to the quality and security. It
doesn’t effect the software behaviour.
Types of Quality Indicators
For answer refer Unit-IV, Q29, Topic: Quality Indicators.
Q33. How MTBF and maturity are related to each other? Explain.
Answer :
MTBF stands for Mean Time Between Failures. It is an indicator that computes the average time consumed between the
software failures (errors) by dividing the test hours (T.h) with type 0 and type 1 software change orders. It is given by,
T.H
MTBF = Number of type 0 and type 1' s CO's
Maturity metrics specifies how mean time between failures varies over time by comparing project schedule against the
released baselines.
Diagrammatic representation of maturity metrics is given below,
MTBF
Released baseline
Project schedule
To know more about maturity, traditional testing methods were implemented on conventional software systems. The
purpose of doing this was to test each and every line of code. However, there are two types of software errors,
(i) Deterministic software errors (also called Bohr-bugs)
(ii) Non-deterministic software errors (also called Heisen-bugs)
Software errors that occur due to any development in the software are called Bohr-bugs. E.g. Coding errors. Bohr-bugs
are found in traditional software systems.
Software errors that are caused to the probability of any occurrence are known as Heisen-bugs. E.g. Design errors. Detection
and analysis of Heisen-bugs is far more difficult than Bohr-bugs. Similar product can be successfully matured if its use cases are
executed in the early stages of the life cycle.
4.2.4 Life-Cycle Expectations

Q34. Give the reasons for selecting the seven core metrics in the software life cycle. Also discuss the
evolutionary pattern of life cycle metrics.
OR
Discuss in detail about life cycle expectations.
Answer : (Model Paper-I, Q9(b) | Nov./Dec.-17(R13), Q11)
Reasons for Selecting Seven Core Metrics in Life Cycle

There are four reasons for selecting the seven core metrics in the software life cycle. They are as follows,
(i) The derivation of the four quality metrics,
The four quality metrics are,
(a) Change traffic and stability
(b) Breakage or modularity
(c) Adaptability and maintainability.
(d) MTBF (Mean Time Between Failures) and maturity.
These metrics are obtained not on the basis of personal opinions but on the basis of evolving requirements of the software
product.
(ii) Metrics enable the organization to understand the nature of an iterative life cycle process. By using metrics, organization
comes to know that the iterative life cycle process is dynamic in nature. This means that through metrics, organizations
realize that changes that occur in the development process of the project should be given more preference rather than
focusing on the value of the process.
(iii) With help of metrics, organization can get an idea of how much wastage has been created due to the iterative development
of a process. Other than the seven core metrics, two additional metrics are used which gives the indication of the wastage.
These are scrap metrics and rework metrics.
(iv) Using these metrics, it is also easier for the organisation to understand about the present value and trend of the project life
cycle. This understanding helps the organisation to take necessary action.
Evolutionary Pattern of Metrics in the Project Life Cycle
The core metrics varies across the phases of project life cycle. There are four phases,
1. Inception phase
2. Elaboration phase
3. Construction phase
4. Transition phase.
Use of Management Metrics in Various Phases
(i) Usage of Work and Progress Metric in the Phases
(a) In inception phase, chances of usage of this management metric is 5%.
(b) Probability that work and progress metric is used in elaboration phase is 25%.
(c) In construction phase, probability of usage is 90%.
(d) Chances of using work and progress metrics in transition phase is 100%.
(ii) Use of Budgeted Cost and Expenditure Metrics in Four Phases
(a) Usage of this metric in inception phase is low.
(b) In elaboration phase, use of budgeted cost and expenditure metrics is moderate.
(c) Usage of this metric is high in construction phase as well as transition phase.
(iii) Usage of Staffing Metrics in Various Phases
(a) For inception phase, small number of team members are used.
(b) For elaboration phase, more number of members are recruited.
(c) For construction phase, number of team members selected are neither more nor less (steady).
(d) Finally for transition phase, the number of team members can be more or less (variable).
Use of Quality Metrics in Four Phases
(i) Usage of Stability Metrics in Different Phases
(a) Stability metrics are too volatile to be used in inception phase.
(b) Stability metrics are moderately used in elaboration phase and construction phases.
(c) Stability metrics are very stable when used in the transition phase.
(ii) Use of Adaptability Metrics in Four Phases
(a) Its usage can be harmful or favorable in inception and elaboration phases.
(b) Adaptability metrics is favorable for both construction and transition phases.
(iii) Usage of Modularity Metrics in Various Phases
(a) In Inception phase, chances of usage of modularity metrics is in between 50-100%.
(b) Probability of usage of modularity metrics in elaboration phase is between 25-50%.
(c) Chances of using modularity metrics is in between 5-10% in transition phase and less than 25% in construction phase.
(iv) Usage of Maturity Metrics in Various Phases
(a) For Inception phase, maturity metrics is used as a prototype.
(b) Maturity metrics in elaboration phase is too fragile to be used. This means that its usage is a hindrance in the progress
of the project.
(c) Unlike in the above phase, in construction phase, maturity metrics are usable.
(d) Finally, in Transition phase, maturity metrics is robust. This implies that there is an assurance that the usage of metrics
in this phase will not cause any harm to the project development.
The above description can be explained in tabular format given below,
Metrics Phases Usage
Works and Progress (i) Inception phase 5%
metrics (ii) Elaboration phase 25%
(iii) Construction phase 90%
(iv) Transition phase 100%
Budgeted cost and (i) Inception phase Low
Expenditure metrics (ii) Elaboration phase Moderate
(iii) Construction phase High
(iv) Transition phase High
Staffing metrics (i) Inception phase Small number of team members
(ii) Elaboration phase More number of team members
(iii) Construction phase Team members are steady (neither more nor less)
(iv) Transition phase Team members can be more or less
Stability metrics (i) Inception phase Volatile
(ii) Elaboration phase Moderate
(iii) Construction phase Moderate
(iv) Transition phase Stable
Modularity metrics (i) Inception phase 50-100%
(ii) Elaboration phase 25-50%
(iii) Construction phase Less than 25%
(iv) Transition phase 5-10%.
Adaptability metrics (i) Inception phase Harmful or Favorable
(ii) Elaboration phase Harmful or Favorable
(iii) Construction phase Favorable
(iv) Transition phase Favorable
Maturity metrics (i) Inception Prototype
(ii) Elaboration Fagile
(iii) Construction Usable
(iv) Transition Robust
4.2.5 Pragmatic Software Metrics

Q35. What are the basic characteristics of good metric? Explain.
Answer : (Model Paper-II, Q9(b) | March-17(R13), Q11(a))
For a metric to be useful, it must have six basic features,

1. A metric should be understandable to the three main stakeholders of the organisation,
(a) Customers
(b) Managers and
(c) Developers.
If any of the above stakeholders find difficulty in understanding the metrics, then the metrics cannot be applied. Customers
can use the metrics only when the developer of the metrics is able to know them properly.
2. Generally, any organisation has the following goals,
(a) Increase in revenue
(b) Reduction in cost
(c) Increase in margin.
To help organisation in achieving these objectives, metrics must explain properly how changes in software process can
have an effect on the performance of the organisation.
3. The metric should be objective as well as its definition Indirect Measure
must be clear or precise. Objectivity of the metrics
Indirect measures are the factors which can be measured
depends on the format of representation. If it is
indirectly. These are usually associated with an object feature
represented in numeric values like percentages, ratios
that is to be measured.
etc., then observation is easier. On the other hand, if
the metric representation is done in non numeric terms For Instance
(textual representation) like good, fair, excellent etc., the
Quality is based on counting rejection points as follows.
observation will be difficult.
v Indirect measures are more difficult to collect than
A metric definition is precise if the following units of the direct measures.
measurements are used,
v Function-oriented metrics can be considered as
(a) Software lines of code indirect measures of the software.
(b) Staff-month Indirect measures of the software process encompasses
(c) Function point following abilities.
(d) Class 1. Functionality

2. Quality
(e) Requirement and Scenario.
3. Reliability
4. The trends in metrics, value in terms of time, projects
etc must be easy to understand so that it can be easily 4. Flexibility
interpreted by the manager or by the organizational
5. Maintainability
team. Based on the interpretation, necessary action can
be taken. 6. Efficiency
5. A good metric is one which is derived not on the basis 7. Reusability
of subjective artifacts or opinions. It is obtained through 8. Correctness
proper work flow of the personnel of the organisation.
9. Interoperability and
6. The collection and reporting of metrics should not
be done through software tools. This is because the 10. Portability.
requirement for these tools is that processed data All of these measures are common in the software
definitions must always be accurate. Hence, metric metrics.
collection should be done using automated tools which
have no such limitation. McCall’s Quality Factors
Therefore, if the metric posses the above characteristics, Following is a diagram depicting the McCall’s software
then it is guaranteed to be successful. quality factors.
Q36. What is a seven core metrics? Discuss about

pragmatic software metrics. • Maintainability • Interoperability
• Flexibility Product Product • Reusability
Answer : Dec.-19(R16), Q9 Revision Transition
• Testability • Portability
Seven Core Metrics Product
Operation
Pragmatic Software Metrics • Efficiency
• Integrity
• Usability
Q37. What is an indirect measure? Why such • Reliability
measures are common in software metrics
• Correctness
work?
Answer : Figure: Triangular Notation Describing the Software Quality
Factors as Suggested by McCall
Software measurement is carried out using the following
two measures. As shown in the figure, McCall’s has grouped the
software quality factors (i.e., the entity which may have their
1. Direct measure and impact on the software quality) under three main side headings.
2. Indirect measure. They are,
Product Operation Q38. Present an argument against lines of code as
measure for software productivity. Will your
Under this side heading, the factors which may exert their
case hold up when dozens or hundreds of
impact while the product is under operation are group together.
projects are considered?
These factors are listed below,
Answer :
v Efficiency, integrity, usability, reliability and correctness
respectively. Arguments that do not support lines of code as a measure
for software productivity are as follows,
Product Transition
v There are several programming languages which have
Under this side heading, the factors which may exert
the ability to obtain large output values in as few lines
their impact while the product is being transposed are group
of code as possible.
together these factors are listed below,
Eg: C++, Java etc.
v Interoperability, reusability, and portability respectively.
v There are few algorithms which despite of requiring
Product Revision
more lines of code can be easily designed.
Under this side heading, the factors which may exert
v The lines of code count will decrease if the programmer
their impact while the product is switched to new environment.
makes use of various library routines and complex
are group together these factors are listed below,
interfaces. This will lead to reduction in program size.
v Testability, flexibility and maintainability respectively. Now, if the LOC count is used by the managers as an
effort estimation of various programmers, there is a
A brief illustration corresponding to each of these factors possibility that managers will not prefer or recommend
is as follows, to use such a program.
(i) Reliability v Larger lines of code can cause errors. To overcome this,
It refers to the time span during which the software compiler identifies where the errors have occurred and
performs its required functions actively. notify the programmers about them.
(ii) Flexibility The above arguments will also be supported by large

number of projects.
It refers to the amount of efforts applied to make suitable
changes to the existing product (software). 4.2.6 Metrics Automation
(iii) Maintainability Q39. Define metric automation. Explain with an
It refers to the amount of efforts applied in finding and example.
removing errors from a given software. Answer : Model Paper-III, Q9(b)
(iv) Efficiency Several techniques are used for the automation of metrics
It refers to the quantity of resources utilized by a given or to operate the tasks of a software project automatically. One
program to deliver its services. of the commonly used techniques is “SPCP”. SPCP stands for
software project control panel. This technique was first brought
(v) Reusability into effect by ASC (Airline Software Council) in 1996. The
It refers to the ability of the program or modules of working of SPCP is same as that of a dashboard. This is because
the program to be used in developing certain other just like a dashboard which is a kind of panel to show all the
applications. controls and instruments in a car. SPCP is also a control panel
that shows the progress of certain attributes of a project to the
(vi) Correctness concerned entities like software project manager, test manager
and development managers by combining information from
It refers to the ability of the given software satisfying its
more than one medium.
purpose of developing at the same time satisfying the
customer in all aspects. Few examples to demonstrate the above process are,
(vii) Interoperability Example 1
It refers to the amount of efforts applied to attach a system By using software project control panel, software project
to the existing system. manager can view the complete values of the project.
(viii) Portability Example 2
It is the ability of the program being adoptable to any Through SPCP particular metrics based on their
platform (hardware/software). forthcoming beta version can be viewed by the manager.
Example 3 5. Actors
With the help of software project control panel, There are two types of actors,
development managers can get the data of those components
(a) Monitor
and sub-systems which are handled by them.
(b) Administrator.
Few components are needed to be defined or developed
to carry out a complete software project control panel. They are (a) Monitor
as follows,
Generally, a monitor performs the following functions,
1. Primitives of Metrics
(i) Data which is displayed at various abstraction
There are four primitives which are, levels are queried by the monitor.
(i) Indicators (ii) Providing definition of panel from various ways.
(ii) Trend graph v Defining the panel based on certain methods which
(iii) Comparison graph are in use.
(iv) Progression graph. v Defining the panel using graphical objects like bar
charts, dials etc.
(i) Indicators
v Defining the panel for the project information on
By using indicators, data can be displayed in multiple the basis of existing
formats such as,
There are four monitors,
(a) In binary form. Eg: black and white.
(i) Software project manager
(b) In digital form. Eg: float, integer
(ii) Customers
(c) In enumerated form. Eg: Sun, Mon, Tue, Wed, Jan,
Feb, Mar, Apr etc. (iii) Software architects
(ii) Trend Graph (iv) Leader of software development team.
Trend graph is a graph that compares the actual metrics (b) Administrator
value over time with known upper and lower thresholds. The functionalities of an administrator are,
(iii) Comparison Graph (i) System installation
A comparison graph can be defined as a graph used to (ii) Definition of new methods
compare one metric value with another relative to time.
(iii) Definition of various structures like composition
(iv) Progress Graph and decomposition to display more than one
A progress graph is a graph used for comparing expected abstraction level.
metrics value with actual metrics value over time such Other than using trend graph, metrics can also be
that progress is identified from the transition among displayed or compared with or without control values. A value
states and their corresponding earned values. that makes an absolute or relative prediction of a particular
2. GUI (Graphical User Interface) metric and use this prediction for comparing with the actual
values of a metric is called a control value.
This component is important because it enables the SPM
(Software Project Manager) to be more flexible. 6. Metrics Definitions
3. Metrics Collection Agents Definitions of metrics involves presentation of actual

metrics for the progress of the following elements,
The functionality of these agents is to extract the data by
using those environment tools which keeps a record of different (i) Requirements
sets of artifacts represented in engineering notations. (ii) Design
4. Metrics Data Management Server (iii) Implementation
This server has the following responsibilities, (iv) Assessments.
(i) Support for GUI metrics so that they are well The progress in the above elements can be identified
populated. with the help of corresponding artifacts i.e., the progress in
(ii) Storage of data which has been extracted by the requirements set can be obtained through the artifacts available
agents. in requirements sets.
The graphical representation of the three graphs is given below,
(a) Trend Graph
(b) Comparison Graph
(c) Progress Graph

E.V
A.V
Terms
U.T-Upper Threshold
L.T-Lower Threshold
E.V-Expected Value
A.V-Actual Value
M.V-Metric Value
Q40. Explain the significance of Software Project Control Panel (SPCP) in metrics automation.
Answer :
The significance of SPCP depends on the status of,
1. Project activity
2. Technical artifacts
3. Milestones
4. Action item.
The status of these four components are shown using certain graphical objects.
1. Status of Project Activity
Project activity status is based on the following elements,
(a) Management
(b) Environment
(c) Requirements
(d) Design
(e) Implementation
(f) Assessment
(g) Deployment.
These elements are called elements of WBS. WBS stands for Work Breakdown Structure. WBS specifies how to improve
the financial performance of the project.
The graphical object used for status of project activities is a kind of bar chart diagram where each element is represented
in terms of rectangles, which are colored with either white or grey. Other than this, percentage and derivative of every element is
given. The derivatives are nothing but up and down arrows.
The diagrammatic representation of the status of project activity is given below,
S.No Elements Color of Elements Percentage Derivative
1. Management 5%
2. Environment 2%
3. Requirement 7%
4. Design 6%
5. Implementation 26%
6. Assessment 3%
7. Deployment 3%
From the above figure, it can be observed that first, second, fourth, sixth and seventh elements are colored with light
shades of grey and third and fifth elements are colored with white and dark shades of grey respectively. Also, for management,
percentage is –5% and derivative is ¯. This means management of a project has become poor by –5%. Similarly, for environment,
the percentage is 2% and the derivative is - . This shows that environment of a project has improved by 2%. Hence, for other
elements it can be concluded that,
(i) Requirements of a project have increased by 7%.
(ii) Project design is lowered by –6%.
(iii) Implementation of a project has got worse by –26%.
(iv) Project assessment has got better by –3%.
(v) Project deployment has improved by –3%.
2. Status of Technical Artifacts
Progress of technical artifacts is based on the third, fourth, fifth and seventh elements of WBS, which are as follows,
(a) Requirements
(b) Design
(c) Implementation
(d) Deployment.
The graphical object used here is such that each of the above four elements are represented with three circles or lights.
The diagrammatic representation is given below,
Elements
Circles
or lights Requirements Design Implementation Deployment
1st Circle
2nd Circle
3rd Circle
From the above diagram, it can be seen that the last light of requirements is coded with dark shades of grey. This implies
that this requirement circle is used to assess the state of specification of requirements and use case models. Also, the second circle
of design element is colored with light shades of grey. It indicates that this particular light of design shows how design models
are assessed. Similarly, the second and third lights of implementation and deployment are colored with light and dark shades of
grey respectively. Light of implementation signifies that assessment of baseline of source code is done and circle of deployment
denotes that test program is assessed.
3. Status of Milestones
Status of milestones can be shown by comparing actual values versus plan values.The above procedure is represented
diagrammatically as,
Actual values (28)
Plan values (23)
From the above graph, it can be observed that 28 actual values are compared against 23 plan values.
4. Status of Action Item
The status of action item is based on how many times they are opened and closed. This is done with the help of a graph
as shown below,
Open (13)
Closed (13)
The given graph indicates that action item is opened and closed thirteen times.
Important Questions
Short Questions
1. Write about evolution of organizations. Refer Q2
2. What are the basic parameters of an earned value system? Refer Q4
3. What is meant by round trip engineering? Refer Q6
4. Write brief notes on metrics automation. Refer Q8
ESSAY Questions
5. With a neat diagram explain the default roles in a software line of business organization. Refer Q11
6. What are the tools available to automate the software development process? Refer Q18
7. Discuss the significance of round trip engineering. Refer Q20
8. Explain in detail about software change orders. Refer Q22
9. What are the seven core metrics? Explain. Refer Q29
10. Give the reasons for selecting the seven core metrics in the software life cycle. Also discuss the evolutionary pattern of life cycle metrics. Refer Q34
11. What is a seven core metrics? Discuss about pragmatic software metrics. Refer Q36
Unit-5 CCPDS-R Case Study and Future Software Project Management Practices 5.1
Unit
CCPDS-R Case Study and Future Software
5
Project Management Practices
SI
A GROUP
Syllabus
CCPDS-R Case Study and Future Software Project Management Practices.
Modern Project Profiles, Next-Generation Software Economics, Modern Process Transitions.
Learning Objectives
 The Process of Command Center Processing and Display System-Replacement (CCPDS-R)

 Software Architecture Skeleton (SAS) in CCPDS-R Case Study
 Risks and Core Metrics of CCPDS-R
 The Future Software Project Management Practices
 The Next-generation Software Economics and Modern Software Economics
 The Culture Shifts for Modern Process Transitions.
Introduction
The Process of Command Center Processing and Display System-Replacement (CCPDS-R) involved two
phases i.e., Concept Definition (CD) phase and Full Scale Development (FSD) phase. The macro process of
CCPDS-R for large software involved six builds which include Build-0, Build-1, Build-2, Build-3, Build-4,
Build-5.
The main purpose of the Command Center Processing and Display System-Replacement (CCPDS-R) core
metrics is to manage the project and to satisfy the project needs. It is not a perfect approach for measuring
the metrics as it measure some erroneous things in an incorrect manner and employs manual methods where
the automated methods are needed. In comparison to the current generation software cost models, the next
generation software cost models should perform the architecture engineering and application production
separately.
Q1. Write a brief note on 80 : 20 principles.

Answer :
The following all the 80 : 20 principles,
v 80% of engineering is utilized by 20% of the requirements
v 80% of the software cost is utilized by 20% of the components
v 80% of the bugs occur because of 20% of the components
v 80% of the software scrap and rework is due to 20% of the changes
v 80% of the resource consumption is due to 20% of the components
v 80% of the project progress is carried-out by 20% of the people.
Q2. What are the best practices in software management?
Answer : Model Paper-I, Q1(i)
The following are the best practices of software management,

(i) Formal risk management
(ii) Interface settlement
(iii) Formal inspection
(iv) Management and scheduling based on metrics
(v) Binary quality gates at the inch-pebble level
(vi) Plan versus visibility of progress throughout the progress
(vii) Identifying defects associated with the desired quality
(viii) Configuration management
(ix) Disclose management accountability.
Q3. What is meant by early risk resolution?
Answer : (Model Paper-III, Q1(i) | Dec.-19(R16), Q1(i))
In the project development life cycle, the engineering phase focuses on identification and elimination of the risks related
with the resource commitments just before the production stage. The traditional projects involve, 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, usecases, components and risk. Hence, they occasionally have simpler steps.
To obtain a useful perspective of risk management, the project life cycle has to be applied on the principles of software
management.
Q4. Explain about evolutionary requirements.
Answer : (Model Paper-I, Q1(j) | Dec.-19(R16), Q1(j))
The traditional methods divide the system requirements into subsystem requirements which inturn 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 lifecycle, the requirements and design are given the first and the second preferences respectively. The third
preference is given to the traceability between the requirement and the design components. These preferences are given inorder
to make the design structure evolve into an organization so it parallels the structure of the requirements organization.
Q5. Describe the 3-step process that is used as an alternative way of performing transition.
Answer : Model Paper-II, Q1(i)
An alternative way of performing the transition that supports automation technologies as well as modern architecture is
to follow the three step process.
1. Ready Step
(i) The modern techniques and technologies are analyzed
(ii) A new process is defined or existing process is improved
(iii) The process with fully integrated environment tools and components are supported.
(iv) A plan is prepared.
2. Aim (Objective) Step
(i) A critical project is selected
(ii) A team support is provided
(iii) A demand for improved results is made.
3. Trigger (Fire) Step
In this step, the organizational and project level plan is implemented efficiently.
Q6. List CSCIS.
Answer :
There are six Computer Software Configuration Items (CSCIS) present in the common subsystem of CCPDS-R that are
defined and described in DOD-STD-2167A. They are,
(i) Network Architecture Services (NAS)
(ii) System Services (SSV)
(iii) Display Coordination (DCO)
(iv) Test and Simulation (TAS)
(v) Common Mission Processing (CMP)
(vi) Common Communication (CCO).
Q7. What are objectives of metric program?
Answer : Model Paper-II, Q1(j)
The following are the objectives of the metric program,

1. To provide enough data for evaluating the current trends in a project and to determine the significance of management
attention towards some project requirement.
2. To provide data for the planning of upcoming subsystems and builds.
3. To provide data for determining the need for process improvements and verifying the need.
4. To provide data for evaluating the relative complexity of the software product with its quality requirements.
Q8. What are the two major improvements in next generation software cost estimation models?
Answer : Model Paper-III, Q1(j)
The two major improvements in next generation software cost estimation models would be the following,
1. The engineering and production stages of the life cycle will be separated. This will emphasize to differentiate between
architectural scale and implementation size . The result of this improvement will be greater accuracy and more honest
precision in life-cycle estimates.
2. The UML notation will define standard Units of measures that can be automated and tracked. This will allow to trace these
measures easily into the costs of production.
5.1 CCPDS-R Case Study

Q9. Discuss about the command center processing and display system replacement.
OR
What was the purpose of the Concept Definition (CD) and Full Scale Development (FSD) in the project
CCPDS-R?
The process of CCPDS-R (Command Center Processing and Display System-Replacement) acquisition involves two phases.
1. Concept Definition (CD) phase and
2. A Full Scale Development (FSD) phase
The purpose of the CD phase is similar to the inception phase. The fundamental products were,
(i) A system specification which is a planned document.
(ii) A software development plan.
(iii) An FSD phase proposal consisting of business case and the technical aspects of award-fee cost proposal.
(iv) A review of system design.
(v) Contract-deliverable documents and.
(vi) The meetings with the government stakeholders.
Hence, the FSD source selection is based on the FSD proposal and the functioning of the contractor proposed team.
From the software point of view, a software engineering exercise can be used as a criteria for the FSD source selection.
This is an effective method and can be used in software development.
CCPDS-R was among the first projects that uses the Ada programming language. In Ada environment, the contractor
processes and the training programs were not fully developed. Hence, the software engineering exercise was used whose intent
was to show the Ada environment, software team and the contractors proposed software process to be deterministic and fully
developed. This step occurred immediately after the submission of the FSD proposal. Both the bidders were allocated with a
simple two-page specification of a “missile warning simulator”.
This simulator consists of the following requirements.
(i) A distributed software architecture.
(ii) A flexible user interface.
(iii) Proposed software team with the development tools and techniques.
(iv) Proposed FSD software development plan.
(v) A mock design review was to be conducted on the 23rd day after receiving the specifications by the customer.
It produced impressive results as the team was competent prepared and flexible. A detailed plan was then developed which
produced the following results.
(i) A skeleton for the software architecture was designed and documented. It comprises of five simultaneous tasks, 8
components with 72 component-to-component interfaces and 2 distributed and executable processes.
(ii) 4 Primary use-cases were developed and determined.
(iii) 4163 source lines were developed and processed. Source lines of reusable components were also added to the
demonstration.
(iv) 11 documents were generated to determine the automation is the documentation tools.
(v) 30 or more action items were resolved by conducting three mile stones.
(vi) The custom-developed tools which as DEC VAX/VMS tools, Rational R1000 environment were used.
(vii) The modifications and enhancements in the process and tools were determined. The requirements, design and planning
processes are considered to be risky but still can be implemented with change management.
Q10. How was the project organized in CCPDS-R project?
Answer :
The CCPDS-R project organization focuses on the evolution of the phase right team, the concept definition (CD) team
symbolizes the essence of the architecture team involved in the engineering stage.
Responsibilities of Concept Definition (CD) Team
1. To specify and examine the requirements for a project.
2. To define and generate the top-level architecture.
3. Formulate the software development activities of the Full-Scale Development (FSD) phase.
4. Organize the process and development environment.
5. Setup the win-win and trust relationships between the stake holders.
The CD phase team consists of only a few expert members and there exists a little competition between the team members.
The Full-Scale Development (FSD) phase team was configured by transforming the CD phase team members to the
leadership positions and by increasing the team size for the full-scale development.
The CCPDS-R software project organization is shown in the following figure.
Personnel
100 Common Subsystem
Staffing Profile
O Schedule
Figure
Inception Elaboration Construction

Phase Phase Phase
CD Phase : Start of FSD : Peak staffing
20 People 23 People 82 people
3 4
3 3 3 5
7 4 3 8 4 23
Figure: CCPDS-R Software Project Organization

Responsibilities of FSD Team
The project organization of FSD phase is as shown in the below figure,
Project
Management
Chief Software Software Software

Administration
Engineer Engineering Development Test
Figure: FSD Phase Project Organization

1. Responsibilities of Chief Engineer (vi) Developing CMP (Common Mission Process) components
A chief engineer is responsible for, Note
Common Mission Processing (CMP) includes missile
(i) Providing the software specifications
warning algorithms for radars, messages for satellites etc.
(ii) Defining the stake holder interfaces (vii) Developing CCO (Common Communications)
(iii) Providing coordination in system engineering. components
2. Responsibilities of Administration Note
Common Communication (CCO) consists of external
The following tasks comes under the responsibilities of interfaces, message input, output and protocol management.
administration,
(viii) Maintaining CSCI (Computer Software Configuration
(i) Organizing the work breakdown structure Items) specifications
(ii) Quality assuring 5. Responsibilities of Software Test
(iii) Cost and schedule estimations. The responsibilities comprises of,
(i) Building integration testing
3. Responsibilities of Software Engineering
(ii) Designing string testing
A software engineer is responsible for,
(iii) Conduct reliability testing
(i) Defining a software process (iv) Software development testing
(ii) Developing a software tool (v) Verifying requirements.
(iii) Analysis and defining software metrics (vi) Maintaining environment
(vii) Baseline control configuring
(iv) Maintaining the software architecture
(viii) Conventional qualification testing.
(v) Devising a plan and integration
Q11. Explain Computer Software Configuration Item
(vi) Evaluating technical status (CSCI).
(vii) Developing NAS component. Answer : Model Paper-II, Q10(a)
Note Computer Software Configuration Item (CSCI)

CSCI is a government terminology used for collectively
NAS means Network Architecture Services which
configured, managed and documented items. A particular team
includes the components for network management, inter process
is given the responsibility of developing these items.
communications, re-configuration etc. This can be reused for
all the three subsystems of CCPDS-R. Common Subsystem of CCPDS-R
There are six computer software configuration items
4. Responsibilities of Software Development
(CSCIS) present in the common subsystem of CCPDS-R that
The responsibilities of software development team are are defined and described in DOD-STD-2167A. They are,
comprises of, 1. Network Architecture Services (NAS)
(i) Testing of stand-alone components 2. System Services (SSV)
(ii) Maintaining components 3. Display Coordination (DCO)
4. Test and Simulation (TAS)
(iii) Developing SSV(System Service) components
5. Common Mission Processing (CMP)
Note
6. Common Communication (CCO)
System Services (SSV) consists of real-time data 1. Network Architecture Services (NAS)
distribution, skeleton of software architecture, global
The NAS is designed in such a way that it can be reused
data types and system interfaces. by all the three subsystems of CCPDS-R. It serves as a
(iv) Developing DCO(Display coordination) components foundation middleware and provides a set of reusable
components for network management, anamoly
Note
management, IPCS, initialization, reconfiguration etc.
Display Coordination (DCO) consists of user interfaces Benefits
control, display formats and population.
(i) Highly skilled and experienced team
(v) Developing TAS (Testing and Simulation) components (ii) Second generation product.
Note Challenges
Testing and Simulation (TAS) comprises of injection of (i) Reusability for all subsystems
text messages, data recording and test-scenario creation. (ii) Higher performance and reliability.
2. System Services (SSV)
The SSV CSI constitutes software architecture skeleton (SAS), data distribution (real time), computer system operator
interface and data types (global).
Benefits
(i) Sable network architecture service primitives
(ii) Tool-generated code.
Challenges
Multiple components, types and global interfaces.
3. Display Coordination (DCO)
The DCO CSCI is included in the user interface control, display formats and display population.
Benefits
(i) Display design is flexible
(ii) Tool-generated formats.
Challenges
(i) Continuous change
(ii) Lasting performance requirements.
4. Test and Simulation (TAS)
The test scenario generation, text message injection, data recording and scenario playback constitute TAS CSCI.
Benefits
(i) Application is simple
(ii) Offline processing is possible to some extent.
Challenges
(i) Limited resources
(ii) Needs an offsite team.
5. Common Mission Processing (CMP)
The CMP CSI consists of the missile warning algorithms that is commonly used for radar generating satellite warning
messages and nuclear detonation.
Benefits
(i) Domain experienced
(ii) Processing is straightforward.
Challenges
(i) Needs an offsite team
(ii) Strict performance requirements
(iii) Many stakeholders involved to approve algorithm design.
6. Common Communication (CCO)
This CSCI constitutes the message input, output and protocol management along with the external interfaces.
Benefits
(i) Skilled people
(ii) Precedent domain expertise.
Challenges
(i) External interface is not stable
(ii) Strict performance requirements.
The following table shows the comparison of CSCI.
NAS SSV DCO TAS CMP CCO
Size 20000 SLOC 160,000 SLOC 10,000 SLOC 70,000 SLOC 15, 000 SLOC 80,000 SLOC
Complexity Very HIGH HIGH MODERATE LOW MODERATE HIGH
Table: Comparison of CSCIs

Q12. Describe Software Architecture Skeleton (SAS)
200 500
in CCPDS-R case study.
Processes
150
100 250
SAS (Software Architecture Skeleton) in CCPDS-R
50
The CCPDS-R software process was developed to utilize
the Ada and other reusable middleware components for rapid
Months Months
construction of distributed architecture. These components
were provided by Network Architecture Service (NAS) which Figure: Common Subsystem SAS Evolution
was initially developed based on the funds generated from the The above graphs represent the changes that occurred
independent research and development group. in the projects architecture over a certain period of time. After
Software architecture skeleton (SAS) is a runtime the dominating spike occurs, the SAS process design gets back
to its actual number of process while SAS task-level design
infrastructure made from a collection of NAS generic tasks,
continues with an increased number of tasks. This is because
processes, sockets and circuits. The SAS typically incorporates
SAS architecture examines the design trade-offs like trade-offs
the documental view about the solution. This view contains all
in concurrency, operating system process overhead, paging,
the major control structures, interfaces, and their datatypes. context switching etc.
According to the CCPDS-R definition, this view incorporates,
Modelling and simulation will also be ineffective because
(i) All Ada main programs. of the complexity in these interactions. Architectural team make
(ii) Tasks of Ada along with the task attributes. use of early demonstrations of many distribution configurations
inorder to understand the technical trade-offs required for
(iii) All the sockets and the socket attributes including
selecting an optimal solution.
connections to the other sockets.
Q13. Elaborate on CCPDS-R process along with
(iv) Datatypes for socket objects. macro process, milestones and schedule.
(v) NAS components, IPCs, fault handling,
Answer : (Model Paper-I, Q10(b) | Oct./Nov.-20(R16), Q5)
performance monitor network management etc.
Macroprocess
Most of the scenarios will not be executed by SAS until
The macroprocess of CCPDS-R for a large software
a software that can read, process and write message is integrated
invovles six builds,
into SAS. The motive behind SAS is to generate the structure and
the interface network by making use of individual components For remaining answer refer Unit-V, Q14.
such that they can provide extensive capability SAS verification The three major architectural iterations are required for
and assessment contributes two significant aspects. They are, an effective PDR baseline. These iterations are based on the
milestones for software requirements review (SRR), Interim
(i) Compilator
PDR (IPDR) and PDR.
(ii) Execution. 1. SRR Milestones
SAS consistency and the quality can be assessed by the The SRR focuses on,
construction and compilation of SAS objects altogether. SAS
(i) Foundation components feasibility
should be constructed and made stable as early as possible so
that the changes that occurs in the baseline can be controlled (ii) Initialization and IPC use cases.
and measured in order to obtain feedback about architectural 2. IPDR Milestones
stability. The SAS baseline of CCPDS-R was initially installed IPDR focuses on the architectural feasibility under the
before PDR milestone. Moreover, the configuration control was riskiest usecases such as peak data load missile warning scenario
utilized to perform the subsequent changes which were closely and peak control load scenarios. The former scenario is resultant
examined with respect to the project evolution. of a mass raid from soviet union and the latter-one is the resultant
of system failure and recovery from initial processing to back-up
The SAS dynamics selected an architecture that
processing of threads.
incorporates early substantiation. The common subsystem
architecture as well as software interface volatility can be 3. PDR Milestones
obtained using SAS. The PDR gives more importance to the achievement of,
The software architecture stability perspective is shown (i) Critical thread components
in figure below. (ii) Peak load scenarios of IPDR.
The macroprocess, milestones and schedule of overall CCPDS-R is illustrated below,
Schedule
For answer refer Unit-V, Q19, Topic: Analysis of Core Metrics.
Inception Elaboration Construction
Requirements analysis
Architecture analysis
Architecture synthesis
Critical-thread demonstration
Architecture maintenance
Application construction
Architecture maintenance
Applications maintenance
Build 2 CDR Build 4

Build 0
SRR Build 3-1 Build 5
Build 1 Build 3-2
Contract SRR IPDR PDR CDR FQT
Build 0
Build 1
Build 2
Build 3
Build 4
Build 5
Schedule
0 5 9 14 24 45
in months
Figure: Macroprocess, Milestones and Schedule in CCPDS-R
Q14. Give a common subsystem overview of CCPDS-R.
Answer : March-17(R13), Q11(b)
The representation of significant and consistent risk management plan can be obtained by planning the content of the
Common Subsystem builds and scheduling them. The management team concentrated more on the sound build plan and carried
out in the inception phase of the life cycle because of its significance. As the life cycle evolved, the expectations for the build
content reallocation were also set up by management team along with more detailed evolution of complexity, risks, trade-offs
and personnels.
Build 0
The foundation of software architecture skeleton can be laid down with the help of components provided by Build 0.
These components include generic tasks, Interprocess communications, common error reporting components etc. The research
and development projects of inception phase resulted in the evolution of this build. The architecture framework constitute the
above NAS components that were reusable with the subsystems of CCPDS-R. The NAS components included in the architecture
are very complex, risk oriented, stringent performers etc.
Build 1
The Build 1 can also be termed as a complete architecture because it constitutes a collection of instantiated tasks, processes,
states, interconnections and state transitions which are needed for the generation of CCPDS-R software architecture. In addition
to the above collection, the NAS components that are responsible for initialization, instrumentation and reconfiguration are also
integrated in this build inorder to obtain a cycling architecture. The demonstrations at initial stage can be facilitated by the addition
of trivial user interface and the architecture insertion capability (i.e., insertion of the test scenarios in the architecture). Few critical
use cases such as initializing the architecture, injecting a scenario and orchestrating reconfigurations are demonstrable after the
completion of build 1.
Build 2
The Build 2 consisted of mission critical components that were used for the execution of real mission scenarios. The
mission scenarios are typically associated with three major risks, they are,
(i) Timelines of display database distribution.
(ii) The performance of the missile warning radar algorithmic.
(iii) User interface performance for complex displays.
Multiple mission-oriented usecases such as worst-case data processing and worst-case control processing thread can be
executed after the completion of build 2.
Build 3
The Build 3 contains, the massive code which includes the specifications needed for display formats, global type and external
interface transaction validations. Certain code generators must be utilized in order to automatically generate such a massive code.
Build 3 also include the components like external communications interface protocol handling, user-system interface for mission
operators and for computer support positions etc. This build is divided into two builds 3-1 and 3-2.
Build 4
The Build 4 typically facilitates the installation of,
(i) Missile warning algorithms
(ii) Mission management
(iii) Mission status displays
(iv) External communications interface processing.
Build 5
The Build 5 contains an external interface which was originally planned for Build-4.
Q15. Explain risk management of CCPDS-R.
Answer :
Risk Management in CCPDS-R
The overall risk management plan was accurately represented in a very useful and accurate manner as a result of planning
the contents and scheduling of the common subsystem builds.
The build content was controlled as the life cycle of the project progressed. There were several adjustments in build content
and schedule. Figure below shows the schedule and also the CSCI content of the common subsystem.
CSCI 0 1 2 3 4 5 Total
NAS 8 8 2 2 20
SSV 33 25 102 160
DCO 23 27 20 70
TAS 2 3 5 10
CMP 3 6 6 15
CCO 5 31 37 7 80
Total 8 43 61 173 63 7 355
Figure: Common Subsystem Builds
PDW : Preliminary Design Walkthrough
CDW : Critical Design Walkthrough
TOR : Turn Over Review
8 Build0
PDW CDW TOR Original milestone
43 Build1 Development Stand alone test

PDW CDW TOR
KSLOC
Turnover for configuration control
61 Build2
PDW CDW TOR
173 Build3
PDW CDW TOR1 TOR2
63 Build4
PDW CDW TOR
7 Build5
PDW CDW TOR
SSRI PDRP DR CDR
Months after contract award
Figure: Common Subsystem Builds

For remaining answer refer Unit-V, Q14.
Q16. Discuss briefly about the incremental design and test processes.
Answer : Model Paper-II, Q10(b)
Incremental Design Process
Every build constitutes certain milestones which incudes,
1. PDW (Preliminary Design Walkthrough)
2. CDW (Critical Design Walkthrough)
3. TOR (Turnover Review).
The schedules of the above milestones are derived from the higher level project milestones which include SRR, CDR,
PDR and IPDR
A well-defined collection of design walkthroughs takes place within a build. This design walkthrough collection constituted
informal, detailed and technical peer reviews of intermediate design products. These were attended by different designers, testers
and stakeholders outside the software organization. The main motive behind these review is to focus more on the significant
components, architecture interfaces and dominating issues.
Highly interacting and informal design walkthroughs were made in which the technical aspects were considered to be as
action items and were traced. All the CSCI managers who had participated in PDWs and CDWs presented their views.
1. Preliminary Design Walkthroughs
The PDW along with the basic capability demonstration can be used for carrying-out initial prototyping and design work.
The PDW focuses on the architectural features of the components within the build. Each build has its own individual schedule
and includes the following CSCI related topics.
(i) Overview, interfaces, components and metrics of CSCI.
(ii) Walkthrough each significant component along with its source code interface, SRS, metrics, usage scenarios etc.
(iii) Control interface components within the architecture.
2. Critical Design Walkthroughs
The design work of the build is completed by using a CDW along with a capability demonstration. The CDW gives
more emphasis on the completeness of the components and the operating perspective utilizing allocated requirements. While,
the capability demonstration exploits the significant performance parameters of the build components. Each build has its own
individual schedule and includes the following CSCI related topics.
(i) Interfaces, components, metrics, changes from PWD characteristics of PDW action items and test scenarios of build
integration.
(ii) Walkthrough of each significant component along with its source code interface, SRS, metrics, usage scenarios etc.
(iii) Demonstration of critical performance threads.
Code Walkthroughs 1. Stand-Alone Test (SAT)
The distribution of the experts to various phases in the The SAT test is usually carried-out by the development
life cycle can be done by using a detailed code walkthrough. teams on the components before transforming them into
the formal, configuration controlled test baseline. This test
It also makes sure about the self-documenting source-code
incorporates testing of a single component for its completeness
development. The code walkthroughs are needed for the and satisfaction of boundary conditions. It is done in a stand-
following reasons, alone environment.
(i) Appropriate distribution of self-documenting source code 2. Build Integration Test (BIT)
style. BIT test can also be termed as a smoke test because it
(ii) Determining the coding issues such as object naming, mainly focuses on the operations of previously demonstrated
coding style, commenting style, unnecessary utilization of capabilities. This test can be used for quality evaluation and
serves as a last test carried-out for a turn-over review. The
complicated methods, existence of reusable components,
primary objective of a BIT test is to develop a stable and a
performance issues etc. reliable baseline.
(iii) Minimizing the source code content for reviewing. The following are the characteristics of a BIT test,
(iv) Identification of the employees without relevant (i) It is informal and dynamic.
experience. (ii) It focuses on exploitation of errors and inconsistencies.
The code review is usually done by a single reviewer with (iii) It enables the repetition of previously demonstrated
the help of online source code browsing tool. This review lasts threads.
to a maximum of two hours and contains a one-page description (iv) It resolves the problems and errors associated with
of relevant comments. The result of this review is sent to the previously demonstrated threads.
author, CSCI manger and the software chief engineer which (v) It performs through testing of all the component
processes it to identify any suggested improvements or changes interfaces.
and applies them to the project. (vi) It verifies whether the baseline is stable for carrying-out
requirement verification test or not.
3. Turnover Review
3. Reliability Test
The turnover review lasts to a maximum of one The reliability testing was developed for exposing all
month and comprises of stand-alone testing of component, the potential transient errors and flows of a significant design
configuration control turnover, integration testing of builds and consequence. Moreover, this testing saved most of the valuable
engineering string testing. time and resources by utilizing the idle resources during nights
or weekends.
Incremental Test Process
4. Engineering String Test (EST)
The test programs contained in CCPDS-R structure are
The EST involves the testing of usecase realizations and
manageable and intelligible. For maintaining all the components
demonstrations for the verifications of different requirements
in a compilable format, considerable amount of testing is subsets over multiple CSCIs.
carried-out in the early architectural demonstrations.
5. Final Qualification Test (FQT)
The compilable Ada serves as the primary format for all The FQT is similar to that of EST but represents the
the phases of the life cycle. As a result, the traditional integration collection of requirements that were unable to verify until the
issues are identified and resolved during the compilation itself. complete system was available.
These issues involve data type consistency, program unit Q17. Write short notes on,
obsolescence and unit dependencies within a program. (a) Component evolution
The informal testing contained in the demonstration (b) DOD-STD-2167 A artifacts.
activities was insufficient to verify whether the requirements Answer :
were satisfied or not and whether the reliability expectations (a) Component Evolution
were met. So, a strict test sequence was introduced which In CCPDS-R, Ada was considered to be as a uniform
contains five different test activities. They are, life cycle format for design evolutions. This enables the direct
1. Stand-Alone Test (SAT) extraction of software development progress metrics from the
evolving source files itself. The process of utilizing Ada as a
2. Build Integration Test (BIT)
design language is derived from TBD designed package. This
3. Reliability Test TBD package comprises of TBD objects which inturn consists of
TBD-types, TBD constants, TBD-values and a TBD procedure
4. Engineering String Test (EST)
that is used for determining the SLOC of the comments. The
5. Final Qualification Test (FQT). procedure declaration for TBD is given below,
TBD-Statements (Number of Statements : In Integer)
The SLOCs (Source Lines of Codes) that makes calls to a TBD object are known as ADL lines and the SLOCs which don’t
have TBD references are known as Ada source lines. The basic component evolution is as follows,
(i) During the creation, an interface with Ada source lines and their respective comments is defined. The ‘TBD-statement's
line is used to specify the SLOC count of the component.
(ii) At PDW, the component substructure and declarations along with the estimates of subordinates program units are detailed
by explicitly making a calls to TBD-statements.
(iii) At CDW, there will be no further calls to TBD-statements with values more than 25 because the program unit interfaces
and declarations are already fully detailed in Ada. Almost 70% of the components will be in Ada and only 30% remain in
ADL.
(iv) By the time turnover arrives, there will not be any TBD in the source files, this means that the implementation is completed.
The above guidelines must be strictly followed for the evolution of components. The CCPDS-R uses Ada as a design language
because the evolving source files will always have a uniform representation format. So, Ada source lines and TBD-statements can
easily be derived. These derived Ada source lines are scanned using a tool for obtaining the statistics on the amount of completed
Ada and TBD-statements. This tool along with some CCPDS-R coding standards allow the users to assess the progress of the
project from different perspectives.
(b) DOD-STD-2167 A Artifacts
Influential changes were made to the DOD-STD-2167 A so that it matches the development approach. These changes also
enables the DOD-STD-2167 A to incorporate the Ada in such a way that it can be used as both the design language as well as the
implementation language. The changes involved are,
(i) Considering the evolving Ada source files as a homogenous design format of the life cycle and evolving them in a self-
documenting style. Thus, the additional overhead involved in preparation of separate and detailed design descriptions is
avoided.
(ii) The subsets of use cases derives the test sequences and derivable components around the build content. This is known
as string-based testing and was organized by build software test plan, procedure and report documentation sequence. All
the BIT, EST and FQT were provided with these document sequences. Moreover, each individual test sequence involved
components from various CSCIs because of continuous integration.
(iii) Depending on a separate unit test documentation as a self-documented repeatable software. This software was homogeneously
maintained and updated regularly for facilitating automated regression testing. The result of these changes is shown in the
below table.
Number Software Documentation Recommended Artifiact
1 System specification Vision statement
6 SRS End item release specifications for each CSCI.
1 System Design Document Description about Architecture
42 Software Development File Implementation set artifact for each component.
6 Software Product Specification Final Implementation set artifacts and deployment set artifacts for each
CSCI.
4 Software Test Plan Release specification, design set artifacts and test models.
6 Software Top-level Design Document UML design models for each CSCI.
Table: CCPDS-R Software Artifacts
Even after performing substantial changes to the 2167 A approach it proves to be inefficient and involves numerous amount
of documentation burden. Hence, it is out-of date.
Q18. Explain in brief about the Demonstration-based Assessment.
Demonstration-based Assessment
Traditionally the designed reviews were based on certain standards that resulted in numerous amount of review data about
all the topics irrespective of their significance. CCPDS-R introduced a review process for augmenting the efficiency of the design
evolution, reviews and stakeholders concurrence. This process is based on the following two approaches. They are,
1. Implementing the design walkthrough
2. Focus the major reviews on significant design trade-offs. The design review that focus on executable demonstration gives
more clear picture to most of the stakeholders.
Most of the traditional projects utilize the paper- (d) Major Design Tradeoffs are Exposed using
based design review presentation and design document Demonstration Activities
for representating the design baseline. This paper-based The Integration of the demonstration components is
representation is inefficient because it cannot withstand any typically performed by a team comprising of 10 - 12 designers.
changes CCPDS-R developed a demonstration based software These designers are responsible for the construction of the
design review process which needs an evidence in favour of design architecture they perform integration, debugging,
the architecture and the design being developed. This evidence rebuilding and redesigning of architecture in order to thoroughly
can be provided by demonstrating an executable version of the understand the strengths and weaknesses of the architecture and
architecture from different usage perspective by using design to expose the significant and in significant components.
review demonstration. At any design review all the qualities (e) Earlier Identification of Performance Issues Result
of the current architecture baseline must be highlight. The in an Earlier Architecture Progress
demonstration also describes the integrity of the architecture The extensive functionality present in the first two
and its subordinates, risks associated with the performance, demonstrations allowed them to demonstrate run-time
significant usecases and operational concept of the system. performance. As a result, it caused some anxiety to the
customers and TRW managers. These anxiety was removed
In CCPDS-R projects, the significant design reviews
after watching the direct resolutions and substantial progress
presented both the briefing and the demonstration. The briefing
made by successive demonstrations.
is a meeting held for describing the overall design, demonstration
goals, scenarios, expectations along with the significant results Q19. (a) What were the core metrics collected by
CCPDS-R? What is the purpose of each
of design walkthroughs. The demonstration is the conclusion of
metric?
the design review process initiated by the software development
team. The plan development, evaluation criteria definition, (b) How were they analyzed?
components integration, and the generation of test drivers, Answer : Model Paper-I, Q11
scenarios etc., comes under the demonstration activities. The (a) CCPDS-R Core Metrics
demonstration plans are not detailed but contains the reasons The purpose of the Command Center Processing and
for demonstration, evaluation criteria for computing results, Display System-Replacement (CCPDS-R) core metrics is to
execution scenarios and hardware and software configurations. manage the project and to satisfy the project needs. It is not a
The CCPDS-R demonstration activities describe the perfect approach for measuring the metrics as it measures some
erroneous things in an incorrect manner and employs manual
following key lessons.
methods where the automated methods are needed. These
(a) Earlier Test Scenarios have more Significance metrics activities results in more teamwork, better understanding
Investing for the construction of test scenarios at earlier of risks, better processes and efficient products generation.
stage has two significant benefits. Objectives of the Metrics Program
(i) It enables the important requirements subset to be 1. To provide enough data for evaluating the current
implemented in a realistic manner. It also results in better trends in a project and to determine the significance of
understanding of requirements by the users. management attention towards some project requirement.
2. To provide data for the planning of upcoming subsystems
(ii) The testing team will be in action earlier in the
and builds.
construction phase so, full-fledge testing can be
3. To provide data for determining the need for process
performed.
improvements and verifying the need.
(b) Significant Risks are Exposed via Demonstration Plan 4. To provide data for evaluating the relative complexity
and its Execution of the software product with its quality requirements.
Each of the individual demonstration content and the Core Metrics
evaluation criteria facilitated the architecture team, management The various core metrics are as follows,
team and stakeholders (external) to focus on the critical priorities 1. Development Progress
of the early requirements and architecture activities.
Accurate measurement of the development progress
(c) Infrastructure Needed for Demonstrations have a using various concurrent builds is a complex project for
High ROI the common subsystem management team.
During the project initialization there was a rumour that The two types of metrics that are used in development
most of the investment in the demonstration will be utilized phase are,
on the insignificant components that were needed only for the (i) The Ada/ADL Metrics
stake of demonstration. But most of the cases reported that the These data provide detailed information of the
demonstrated components were reused in SAT, BIT or EST. direct indicators for the technical progress in a
From a total of 72,000 SLOC of IPDR demonstration, only project and accurately determines the true progress
2000 were thrown away. in design and implementation.
(ii) Earned Value Metrics
These data provide detailed information about the financial status and contract deliverables of the project. Technical
progress is poorly reflected by these metrics.
Purpose
The purpose of these metrics is to determine the non-adversarial relationships among the stakeholders. These metrics also
provide objective mechanism and consistent language for describing the small changes in the project plan and architecture,
issues in design and requirements etc. To determine the progress of each subsystem and each build, every month in the
project management reviews.
2. Test Progress
The test organisation was incharge of conducting the build integration tests(BITs) and requirements verification testing.
Purpose
The purpose of BITs is to carryout a set of integration testing methods from the fundamental to off-nominal boundary conditions.
3. Stability
The purpose of this metric is to maintain the equilibrium between the test organisation and the development organisation
and to take corrective actions when breakage rates diverges from repair rates.
4. Modularity
The purpose of this metric is to determine the total breakage as a ratio of the entire software subsystem.
5. Adaptability
The purpose of this metric is to calculate the average cost of change and the total work done in reworking of activities
against software baselines. These values provide a clear understanding of the changes in software baselines.
6. Maturity
Reliability is one of the most important requirement in CCPDS-R project. Hence, an automated test suite is created by an
independent test team which is used to validate credible software MTBF.
7. Cost/Effort Expenditures by Activity
Its purpose is to compare varying levels of productivity in a normalized way i.e., each CSCI costs can be compared with
each other, in addition to have comparison with other metrics. These comparison must be strengthened by management
understanding of the attributes such as team competence, CSCI complexity, requirements volatility etc.
(b) Analysis of Core Metrics
1. Development Progress
The overall evaluation of the progress was piled up into a single chart as shown in the following figure. Figure (a) shows
the overview of the top-level progress for each build and for the common subsystem. The shading length in each build specifies
whether the progress was ahead or behind the schedule.
Time = Month 15
BUILD 0
BUILD 1
BUILD 2
BUILD 3
Common subsystem Design

Common subsystem SAT
Figure (a): Development Progress Overview

The above figure shows the status of month 15 : Build 2 SAT testing in one month behind schedule, Build 3 design is two
months ahead of schedule, the common subsystem design effort is on schedule and common subsystem SAT testing is one month
behind schedule. Monthly collection of metrics specifies detailed management perception of build progress, code growth and other
indicators.
Figure (b) shows the estimation of the progress of common subsystem and each build 30% of the weight-averaging of
SLOC counts is accomplished by Preliminary Design Walkthrough (PDW) and 70% is done by Critical Design Walkthrough
(CDW). The overall performance of the common subsystem is close to its plan. The unexpected positive impact of the source
code generation tools showed the progress achieved at IDPR.
100%
Actual
Subsystem progress (% coded)
Plan
80
60
40
20
IDPR PDR CDR
0 12 34 56 78 91 01 11 21 31 41 5.
Contract month
Figure (b): Common Subsystem Estimation Progress
2. Test Progress
Figure (c) shows the overview of the progress metrics used to plan and keeps track of the CCPDS-R test program. In this
figure, the progress is plotted against the plan for requirements verification tests. The test cases are built from SATs, ESTs and FQTs
by the software organization. The development team is responsible for conducting SATs but, they can be executed in the formal
configuration management environment and reviewed by the test personnel. ESTs consists of functionally related collection of
scenarios that indicates requirements extended to multiple components. FQTs are the tests regarding the requirements compliance
that will not be shown till the existence of the complete system.
100%
Requirements verified
80%
60%
40%
Actual
Plan
20%
30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
Contract month
Figure (c): Common Subsystem Test Progress
3. Stability
Figure (d) shows the overall rate of change in configuration baseline. It indicates the aggregate number of SLOC broken
and repaired.
1,00,000
Repaired
90,000 Broken
80,000
70,000
Cumulative SLOC
60,000
50,000
40,000
30,000
20,000
10,000
5 10 15 20 25 30 35 40 45
Contract month
Figure (d): Common Subsystem Stability
4. Modularity
As shown in figure (e), the total scrap (residue) produced by the common subsystem software development process is 25%
of the entire product which is 40-60% according to industrial average.
Closed Rework
25%
Currently open rework
20%
Cumulative SLOC
15%
10%
5%
5 10 15 20 25 30 35 40 45
Contract month
Figure (e): Common Subsystem Modularity

5. Adaptability
Figure (f) shows a plot between the average cost of change and the common subsystem schedule. The stable cost of
change is obtained as a result of FQT for 1600 + SCOs. The early SCO trends are the changes that affects many people and
many components. The later trends in SCO affects single person and a single component. The final phase of SCOs shows an
uncharacteristic increase in breakage.
50
Design
changes Implementation
40 ance
Average hours/SLOC
changes
nten
Mai anges
30 ch
20
10
PDR CDR FQT
14 24 48
Common Sub system Schedule
Figure (f): Common Subsystem Adaptability
6. Maturity
Figure (g) shows the statistical testing for verifying the maximum coverage and revealing the issues of deadlocks, memory
leakage, races, resource overruns etc.
30000
MTBF (Hours)
10000 50,000 1,00,000

Test (hours)
Figure (g): Common Subsystem Maturity

Q20. ‘There are two approaches to manage people in CCPDS-R’. Discuss them briefly.
Answer :
There are two significant approaches for managing the people in CCPDS-R. They are,
1. Core Team
2. Award Fee Flowdown Plan.
1. Core Team
The CCPDS-R software organization established its core team during the concept definition phase of the project life cycle.
This team usually comprises of very few individuals that focuses on the significant 20% of software engineering activities that
yield good profit margins. The core team of CCPDS-R organization is responsible for,
(i) Developing the influential components that resolve the complicated issues related to real-time scheduling IPCs, error
processing etc. Thus, this team simplifies the complexity of the architecture by reducing the number of mainstream
components.
(ii) Specifying the procedures and standards needed to be followed for design walkthroughs and software artifacts.
Mostly, the initial version artifacts of any project workflow are constructed by the core team.
(iii) Maintaining the common culture throughout the software organization. Initially, the core team will be a single
entity which fully concentrate on inception and elaboration phases. Its members begin to migrate as soon as they
stable process and architecture is achieved. Thus, various members takes the technical leadership roles in different
development and assessment teams. However, some of the team members will remain in touch throughout the project
even if they are disseminated into different teams. Thus, a common culture is maintained.
2. Award Fee Flowdown Plan
Initially, because of the rapid growth in software industry and scarcity of software experts, there was a great demand for
software professionals. The organization were starving to attract the employees with their lucrative offers. At that time, TRW
software integration business introduced an innovative profit sharing approach for retaining their team members. The idea behind
Award-fee flowdown plan of CCPDS-R is to retain the employees by sharing a portion of profit with them. The TRW managers
decided to distribute the award fee (profits) at each major milestone to project employees.
This distribution was made on the basis of individual employees contribution towards the project.
The Award Fee Flowdown approach was implemented 1. System services
to achieve the following objectives, 2. Data logging services
(i) Distributing Awards to the entire team, if the project 3. Test message injection
performed well.
4. System initialization
(ii) Awards are given to the employees depending on
5. System failure, recovery and reconfiguration.
their level of contribution.
1. System Services
(iii) Best performers are nominated separately.
System services are NAS software components
(iv) Reducing the burden of good employees.
which basically act as underlying elements of architecture
The only problem with this plan is that, the initial infrastructure. These services are general utility services that
award fee distributed will be for less than the award fee are reused across all the common subsystems. System services
distributed in later stages. So, the employees working in the
provides the following services,
inception and elaboration phase will receive less award fee
than the employees working in construction and transition (i) Inter process communication services
phases. (ii) Generic application control services
This plan operates in the following fashion. (iii) NAS utilities services
(i) Different peer groups such as system engineering, (iv) Common error reporting and monitoring services.
software engineering, business administration etc 2. Data Logging Services
are defined by the management.
Data logging is the performance related capability service
(ii) The ranking of peers within the group is done every which is required to determine some of the demonstration
six months based on their level of contribution. results.
The result of this ranking is compiled global
3. Test Message Injection
performance ranking of peer group.
This capability allows the messages to be stored within
(iii) The project employees are given almost 50% of
the object internal to the system without considering the type
the award fee that is computed at all significant
of the object. This sort of message injection is done so as to
milesontes.
implement a general test driver capability.
(iv) The distribution of the award fee among various
4. System Initialization
employees was based on a simple algorithm. In
addition to the salaries, the employees get an System initialization capability is used to determine the
additional compensation which can be between availability of,
the range of 2% and 10% per annum. (i) Consistent software architecture skeleton
(a) The distribution of award fee for each individual (ii) Error-free operation associated with a significant
peer group was based on the number of employees set of system services.
within that group and their average salary.
There is a chance that a risk related to the performance
(b) Before distribution, the award fees is divided into may be encountered whenever there is a requirement of
two equal halves. The first half is distributed among initializing a large distributed software architecture within a
all the employees who were involved in the project specified time period.
and the second half is distributed only to the best
5. System Failure, Recovery and Reconfiguration
performers.
System failure and recovery is a usecase, which is
Thus by the implementation of this approach, the
responsible for injecting simulated fault within a primary thread
software experts were retained and also the employees starved
operational object. The purpose of injecting is to perform the
hard to become the best performers in order to obtain more
following events,
award fee. As a result, the overall project performance and the
quality was enhanced. (i) Detecting the fault
Q21. Explain IPDR demonstration scope. (ii) Notifying about the fault
Answer : (iii) Arranging state transition from primary to backup
IPDR Demonstration Scope thread
IPDR demonstration scope was specified in the (iv) Terminating the primary thread.
CCPDS-R work statement which states that the following This usecase is considered as the most riskiest as it
capabilities are to be demonstrated by the contractor at NORAD requires highly developed and complex set of state management
Demo 1. and state transition control interfaces. These interfaces are to
be exercised across different logical networks that connect multiple software objects. It is necessary that state transition from one
network to another network must be carried out without any service interruption. Once a system is restarted after system failure
a new backup thread will be initialized in order to reduce the risk of failures from multiple point to single point.
Before injecting simulated fault, peak messages are injected within the architecture. While the messages are being injected
all the internal messages cascades through the system. The prerequisite for executing the messages is that all the software objects
involved in the execution process needs to have smart but simple message processing stubs that are to be modeled. A software
called prototype message software is responsible for accepting and forwarding the incoming messages via strings of components
that build up SAS.
5.2 Future software project management practices

5.2.1 Modern Project Profiles
Q22. Write short notes on,
(b) Early risk resolution.
(a) Continuous Integration

In the iterative development process firstly, overall architecture of the project is created and then all integration steps are
evaluated to identify and eliminate the design errors. This approach eliminate 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.
100% 100%
Contains Large-scale
integration
Project completion
Project completion
Integration
(In percentage)
(In percentage)
Estimated Estimated
Completion Completion
Time Time
Figure (a): Modern Project Profile Figure (b): Traditional Project Profile
Moreover, it produces feasible and manageable design by delaying the ‘design breakage’ to the engineering phase, and can
be resolved efficiently. This can be done 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 trade-offs are
better understood. Moreover, 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 of project is completely different from that
of traditional project profile as shown below.
PROJECT WORKFLOWS
Management Environment Requirement Design Implementation Assessment Deployment Total
(In percentage)
Cost-distribution
of Modern Project
Profile 10 10 10 15 25 25 5 100
(In Percentage)
Cost-distribution
of Traditional
Project Profile 5 5 5 10 30 40 5 100
(In Percentage)
Table: Comparison of Modern Project Profile and Traditional Project Profile Interms of Cost-Distribution
As shown in the table, the modern projects spend only v 80% of the Project Progress is Carried-out by 20%
25% of their budget for integration and Assessment activities of the People
whereas, traditional projects spend almost 40% of their total
It is important that planning and designing team should
budget for these activities. This is because, the traditional
consist of best professionals because the entire success of
projects involve inefficient large-scale integration and late
identification of design issues. the project depends upon a good plan and an architecture.
(b) Early Risk Resolution The following figure shows the risk management profile
of a modern project.
In the project development lifecycle, the engineering
More Inception Elaboration Construction and
phase focuses on identification and elimination of the risks Transition
related with the resource commitments just before the
production stage. The traditional projects involve, solving of
Exploration of Risks
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,
usecases, components and risk. Hence, they occasionally have Risk Risk Risk
simpler steps. Exploration Resolution Management
Time Time Time
To obtain a useful perspective of risk management, the Less
project life cycle has to be applied on the principles of software Overall Lifecycle of a Project
management. The following are the 80 : 20 principles.
v 80% of Engineering is Utilized by 20% of the
Figure (c): Risk-management Profile of a Modern Project
Requirements
Q23. Discuss briefly about the following,
Before selecting any of the resources, try to completely
understand all the requirement because irrelevant (a) Evolutionary requirements
resource selection (i.e., resources selected based on (b) Teamwork among stakeholders.
prediction) may yield severe problems. Answer :
v 80% of the Software Cost is Utilized by 20% of the (a) Evolutionary Requirements
Components The traditional methods divide the system requirements
Firstly, the cost-critical components must be elaborated into subsystem requirements which inturn gets divided into
component requirements. These component requirements
which forces the project to focus more on controlling
are further divided into unit requirements. The reason for
the cost.
this systematic division is to simplify the traceability of the
v 80% of the Bugs Occur because of 20% of the requirements.
Components In the project life cycle, the requirements and design are
Firstly, the reliability-critical components must be given the first and the second preferences respectively. The third
elaborated which gives sufficient time for assessment preference is given to the traceability between the requirement
activities like integration and testing in order to achieve and the design components. These preferences are given inorder
the desired level of maturity. to make the design structure evolve into an organization so it
parallels the structure of the requirements organization.
v 80% of the Software Scrap and Rework is due to 20%
of the Changes Modern architecture find it difficult to trace the
requirements because of the following reasons,
The change-critical components are elaborated first so
that the changes that have more impact occur when the (i) Usage of commercial components
project is matured. (ii) Usage of legacy components
v 80% of the Resource Consumption is due to 20% of (iii) Usage of distributed resources
the Components (iv) Usage of object oriented methods.
Performance critical components are elaborated first so Moreover, the complex relationships such as one-one,
as to solve the trade-offs with reliability, changeability many-one, one-many, conditional, time-based and state-based
and cost-consumption as soon as possible. exists the requirements statement and the design elements.
Software Architecture
Methods
Capability
Fa Fb Fc
Common Methods
Methods
Capability
Fm Fn Fo
Common Methods
Methods
Capability
Fx Fy Fz
Requirement Set Artifacts
R1 Ra
R2 Rb
USE-CASE
R3 MODEL Rc
RN RN
Software Vision Release

Document Specifications
Figure: Software Component Organization of a Modern Process

As shown in the above figure, the top category system requirements are kept as the vision whereas, the requirements of
the lower category are evaluated and attached to every intermediate release. The motive behind these artifacts is to gain fidelity
with respect to the progress in the project life cycle. This serves as a significant different from the traditional approach because
in traditional approach the fidelity is predicted early in the project life cycle.
(b) Teamwork Among Stakeholders
Most of the characteristics of the classic development process worsen the stakeholder relationships which inturn makes
the balancing of requirements 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 achieve customer satisfaction. The table below shows
the tangible results of major milestones in a modern process.
Obvious Result Actual Result

1. Demonstration at early stage reveals 1. Demonstration, firstly reveals the significant assets and risks associated
the design issues and uncertainty in a with complicated software systems such that they can be worked out
tangible form. at the time of setting the life-cycle goals.
2. Non-compliant design 2. Various perspective like requirements use cases etc are observed in
order to completely understand the compliance.
3. Issues of influential requirements are 3. Both the requirement changes and the design trade-offs are
revealed but without traceability. considerably balanced.
4. The design is considered to be “guilty 4. The engineering issues can be integrated into the succeeding iteration’s
until its innocency is proved. plans.
Table: Major Milestone Results in Modern Process
From the above table, it can be observed that the progress specification, source code, design models test cases and
of the project is not possible unless all the demonstration executable code. The automation of this information
objectives are satisfied. This statement does not present the allows the teams to focus more on engineering rather
renegotiation of objectives, even when the demonstration than dealing with overhead involved.
results allow the further processing of trade offs present in the 6. Design Artifacts must be Captured in Model-based
requirement, design, plans and technology. Notation
A modern iterative process that rely on the results of The design artifacts that are modelled using a model-
the demonstration need all its stakeholders to be well-educated based notation like UML which are rich in graphics and
and with a good analytical ability so as to distinguish between texture. These modelled artifacts facilitate the following
the obviously negative results and the real progress visible. For tasks
example, an early determined design error can be treated as a
positive progress instead of a major issue. (i) Complexity control
(ii) Objective fulfillment
Q24. Explain top ten software management principles.
(iii) Performing automated analysis.
7. Process must be Implemented for obtaining Objective
Principles of Software Management Quality Control and Estimation of Progress
Software management basically relies on the following The progress in the life cycle as well as the quality
principles. They are, of intermediary products must be estimated and
1. Process must be Based on Architecture-first Approach incorporated into the process. This can be done with
If the architecture is focussed at the initial stage, the help of well defined estimation mechanism that
then there will be a good foundation for almost 20% are directly derived from the emerging artifacts. These
of the significant stuff that are responsible for the mechanisms provide a detailed information about trends
overall success of the project. This stuff include the and correlation with requirements.
requirements, components, usecases, risks and errors. 8. Implement a Demonstration-based Approach for
In other words, if the components that are being Estimation of Intermediary Artifacts
involved in the architecture are well known then
This approach involves giving demonstration on
the expenditure caused by scrap and rework will be
different scenarios. It facilitates early integration and
comparatively less.
better understanding of design trade-offs. Moreover, it
2. Develop an Iterative Life-cycle Process that Identifies eliminates architectural defects earlier in the life cycle.
the Risks at an Early Stage The intermediary results of this approach are definitive.
An iterative process supports a dynamic planning 9. The Point Increments and Generations must be made
framework that facilitates the risk management based on the Evolving Levels of Detail
predictable performance. Moreover, if the risks are
Here, the ‘levels of detail’ refers to the level of
resolved earlier, the predictability will be more and the
understanding requirements and architecture. The
scrap and rework expenses will be reduced.
requirements, iteration content, implementations and
3. Alter the Design Methods In-order to Highlight acceptance testing can be organized using cohesive usage
Components-based Development scenarios.
The quantity of the human generated source code 10. Develop a Configuration Process that should be
and the customized development can be reduced by Economically-scalable
concentrating on individual components rather than The process framework applied must be suitable for
individual lines-of -code. The complexity of a software variety of applications. The process must make use
is directly proportional to the number of artifacts it of processing spirit, automation, architectural patterns
contains. If the solution is smaller then the complexity and components such that it is economical and yield
associated with its management is less. investment benefits.
4. Create a Change Management Environment Q25. What are the software management best
Highly-controlled baselines are needed to compensate practices? Explain them.
the changes caused by various teams that concurrently Answer : (Model Paper-III, Q11(a) | Dec.-19(R16), Q10)
work on the shared artifacts. Best Practices Associated with Software Management
5. Improve Change Freedom with the Help of Automated According to Airline software council, there are about
Tools that Support Round-trip Engineering nine best practices associated with software management. These
The roundtrip-engineering is an environment that practices are implemented in order to reduce the complexity
enables the automation and synchronization of of the larger projects and to improve software management
engineering information into various formats. The discipline. The following are the best practices of software
engineering information usually consists of requirement management,
1. Formal Risk Management change management principle of software management
Earlier risk management can be done by making use of and prefers automation of components so as to reduce
iterative life cycle process that identifies the risks at early the probability of errors that occur in the large-scale
stage. projects.
2. Interface Settlement 9. Disclose Management Accountability
The interface settlement is one of the important aspect The entire managerial process is disclosed to all the
of architecture-first approach. This is because, obtaining people dealing with the project.
an architecture involves the selection of various internal
and external interfaces that are incorporated into the 5.2.2 Next-Generation Software Economics
architecture. Q26. Discuss about next generation software
3. Formal Inspections economics.
There are various defect removal strategies available. Answer : (Model Paper-II, Q11(b) | Dec.-19(R16), Q11)
Formal inspection is one of those strategies. However, Next Generation Software Cost Models
this is the least important strategy because the cost
associated with human resources is more and is defect In comparison to the current generation software cost
detection rate for the critical architecture defects is less. models, the next generation software cost models should
perform the architecture engineering and application production
4. Management and Scheduling Based on Metrics separately. The cost associated with designing, building, testing
This principle is related to the model based approach and maintaining the architecture is defined in terms of scale,
and objective quality control principles. It states to use quality, process, technology and the team employed.
common notations for the artifacts so that quality and After obtaining the stable architecture, the cost of its
progress can be easily measured. production is an exponential function of size, quality and
5. Binary Quality Gates at the Inch-pebble Level complexity involved.
The concept behind this practice is quite confusing. Most The architecture stage cost model should reflect certain
of the organizations have misunderstood the concept diseconomy of scale (exponent less than 1.0) because it is based
and have developed an expensive and a detailed plan on research and development-oriented concerns. Whereas the
during the initial phase of the lifecycle. Later, it found production stage cost model should reflect economy of scale
the necessity to change most of their detailed plan due (exponent less than 1.0) for production of commodities.
to the small changes in requirements or architectural.
The next generation software cost models should be
This principle states that, "first start the planning with
designed in a way that, they can assess larger architectures with
an understanding of requirements and the architecture".
economy of scale. Thus, the process exponent will be less than
Milestones must be established during engineering stage
1.0 at the time of production because large systems have more
and inch-pebble must be followed in the production
automated process, components and architectures which are
stage.
easily reusable.
6. Plan Versus Visibility of Progress throughout the
The next generation cost model developed on the basis
Progress
of architecture-first approach as shown below.
This practice involves a direct communication between
At Architectural Engineering Stage
different team members of a project so that they can
discuss the significant issues related to the project as (i) A plan with less fidelity and risk resolution
well as notice the progress of the project in-comparison (ii) It is technology or schedule-based
to their estimated progress.
(iii) It has contracts with risk sharing
7. Identifying defects Associated with the Desired
(iv) Team size is small but with experienced professionals.
Quality
(v) The architecture team consists of small number of
This practice is similar to the architecture-first approach
software engineers
and objective quality control principles of software
management. It involves elimination of architectural (vi) The application team consists of small number of domain
defects early in the life-cycle, thereby maintaining the engineers
architectural quality so as to successfully complete the (vii) The output will be an executable architecture, production
project. and requirements
8. Configuration Management (viii) The focus of the architectural engineering will be
According to Airline software council, configuration on design and integration of entities as well as host
management serves as a crucial element for controlling development environment.
the complexity of the artifacts and for tracing the changes (ix) It contains two phases they are Inspection and
that occur in the artifacts. This practice is similar to the Elaboration.
Architectural
effort
PArch > 1.0
Size and complexity
Figure: N-Month Design Phase

At Application Production Stage
(i) A plan with high fidelity and lower risk
(ii) It is cost-based
(iii) It has fixed-priced contracts
(iv) Team Size is Large and Diverse as needed.
(v) Architecture team consists of a small number of software engineers.
(vi) The application team may have any number of domain engineers.
(vii) The output will be a function which is deliverable and useful, tested baseline and warranted quality.
(viii) The focus of the application production will be on implementing testing and maintaining target technology.
(ix) It contains two phases they are construction and transition.
Application
effort
PApp < 1.0
Size and complexity

Figure: M-Month Production Increments
Total Effort = Func (Technology Arch , Scale Arch , Quality Arch , Process Arch ) +

Func (Technology App , Scale App , Quality App , Process App )

Total Time = Func (Process Arch , Effort Arch ) + Func (Process App , Effort App )
The next generation infrastructure and environment automated various management activities with low effort. It relieves
many of the sources of diseconomy of scale by reusing the common processes that are repetitive in a particular project. It also
reuses the common outcomes of the project. The prior experience and matured processes utilized in these type of models eliminate
the scrap rework sources. Here, the economics of scale will be affected.
The architecture and applications of next generation cost models have different scales and sizes which represents the solution
space. The size can be computed interms of SLOC or megabytes of executable code while the scale can be computed in-terms of
either components, classes, processes or nodes. The requirements or usecases of solution space are different from that of 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 optimal solution is not found then different solutions need to be selected or to change
the problem statement.
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. They are,
(i) Separate architectural engineering stage from application of whether a business organization implements the
production stage. This will yield greater accuracy and engineering phase over multiple projects or whether a
more precision of lifecycle estimates. project implements the engineering phase over multiple
incremental stages.
(ii) The use of rigorous design notations. This will enable
3. The Maintenance Cost will be Almost Double the
the automation and standardization of scale measures so
Development Cost
that they can be easily traced which helps to determine
the total cost associated with production. Most of the experts in the software industry find it
difficult to maintain the software than development.
The next-generation software process has two potential The ratio between development and maintenance can
breakthroughs, they are, be measured by computing productivity cost.
(i) Certain integrated tools would be available that One of the interesting fact of iterative development is
automates the information transition between the that the dividing line between the development and
requirements, design, implementation and deployment maintenance is vanishing. Moreover, a good iterative
elements. These tools facilitate round-trip engineering process and an architecture will cause the reduction in
between various artifacts of engineering. the scrap and rework levels so this ratio (i.e.,) 2:1 can
be reduced to 1:1.
(ii) It will reduce the four sets of fundamental technical artifacts
4. Both the Software Development Cost and the
into three sets. This is achieved by automating the activities Maintenance Cost are Dependent on the Number of
related to human-generated source code so as to eliminate Lines in the source Code
the need for a separate implementation set.
This metric was applicable to the conventional cost
Q27. Explain modern software economics. models which were lacking in-terms of commercial
components, reusing techniques, automated code
OR
generators etc. The implementation of commercial
‘An organizational manager should strive for components, reusing techniques and automated
making the transition to a modern process’. code generators will make this metric inappropriate.
Support your answer. However, the development cost is still dependent on the
Answer : commercial components, reuse techniques and automatic
code generators and their integration.
The transition to a modern process should be made based
The Next-generation cost models should focus more on
on the following quotations laid by Boehm. These describe some
the number of components and their integration efforts
important themes in an economic context. rather than on the number of lines of code.
1. Identifying and Solving a Software Problem in the 5. Software Productivity Mainly Relies on the type of
Design Phase is Almost 100 Times Cost Effective than
People Employed
Solving the Same Problem After Delivery
The personal skills, team work ability and the motivation
This quotation or metric serves as a base for most of employees are the crucial factors responsible for
software processes. Modern processes, component-based the success and the failure of any project. The Next-
development techniques and architectural frameworks generation cost models failure should concentrate more
mainly focuses on enhancing this relationship. The on employing a highly skilled team of professionals at
architectural errors are solved by implementing an engineering stage.
architecture-first approach. Modern processes plays a 6. The Ratio of Software to Hardware Cost is Increasing
crucial role in identification of risks. As the computers are becoming more and more popular,
2. Software Development Schedules can be Compressed the need for software and hardware applications
to a Maximum of 25 Percent is also increasing. The hardware components are
becoming cheaper whereas, the software applications are
If we want a reduction in the scheduled time, then we
becoming more complicated. As a result, highly skilled
must increase the personnel resources which inturn
professionals are needed for development and controlling
increases the management overhead. The management
the software applications, this inturn increases the cost.
overhead, concurrent activities scheduling, sequential
In 1955, the software to hardware cost ratio was 15:85
activities conservation along some resource constraints
and in 1985 this ratio was 85:15. This ratio continuously
will have the flexibility limit of about 25 percent.
increases with respect to the need for variety of software
This metric must be acceptable by the engineering phase applications. Certain software applications have already
which consists of detailed system content. If we have been developed which provides automated configuration
successfully completed the engineering then compression control and analysis of quality assurance. The next-
in the production stage will be automatically flexible. The generation cost models must focus on automation of
concurrent development must be possible irrespective production and testing.
7. Only 15% of the Overall Software Development is will be similar to that of a project manager. Pure
Dedicated Process to Programming managers are needed when personal resources exceed
The automation and reusability of codes have lead to the 25. Firstly, these managers understand the status of the
reduction in programming effort. Earlier in 1960s, the project then, develop the plans and estimate the results.
programming staff were producing about 200 machine The manager should participate in developing the plans.
instructions per month and in 1970s and 1980s, the This transition affects the software project managers.
machine instruction count has raised to about 1000 2. Tangible Design and Requirements
machine instructions. Now a days, programmers are able The traditional processes utilize tons of paper in order to
to produce several thousand instructions without even
generate the documents relevant to the desired project.
writing few hundreds of them.
Even the significant milestones of a project are expressed
8. Software Systems and Products cost three times the via documents. Thus, the traditional process spends most
Cost Associated with Individual Software Programs of their crucial time on document preparation instead of
Per SLOC and Software-system Products Cost 9 performing software development activities.
Times more than the Cost of Individual Software
Program An iterative process involves the construction of systems
that describe the architecture, negotiates the significant
In the software development, the cost of each instruction
requirements, identifies and resolves the risks etc. These
depends upon the complexity of the software. Modern
milestones will be focussed by all the stakeholders
processes and technologies must reduce this diseconomy
of scale. The economy of the scale must be achievable because they show progressive deliveries of important
under the customer specific software systems with functionalities instead of documental descriptions about
a common architecture, common environment and the project. Engineering teams will accept this transition
common process. of environment from to less document-driven while
conventional monitors will refuse this transition.
9. 60% of Errors are Caught by Walkthrough
3. Assertive Demonstrations are Prioritized
The walkthrough and other forms of human inspection
catch only the surface and style issues. However, the The design errors are exposed by carrying-out
critical issues are not caught by the walkthroughs. So, demonstrations in the early stages of the life cycle.
this metric doesn’t prove to be reliable. The stake holders should not over-react to these design
10. Only 20% of the Contributors are Responsible for errors because overemphasis of design errors will
the 80% of the Contributions discourage the development organizations in producing
This metric is applicable to most of the engineering the ambitious future iterating. This does not mean that
concepts such as 80:20 principles of software project stakeholders should bare all these errors. Infact, the
management. The next generation software process stakeholders must follow all the significant steps needed
must facilitate the software organizations in achieving for resolving these issues because these errors will
economic scale. sometimes lead to serious down-fall in the project.
This transition will unmark all the engineering or process
5.2.3 Modern Process Transitions issues so, it is mostly refused by management team and
Q28. Discuss the indications of a successful project widely accepted by users, customers and the engineering
transition to a modern culture. team.
OR 4. The Performance of the Project can be Determined
Explain culture shifts for modern process Earlier in the Life Cycle
transitions. The success and failure of any project depends on
Answer : (Model Paper-III, Q11(b) | Nov./Dec.-16(R13), Q10(b)) the planning and architectural phases of life cycle so,
Indications of a Successful Project Transition to a Modern these phases must employ high-skilled professionals.
Culture However, the remaining phases may work well with an
Several indicators are available that can be observed in average team.
order to distinguish projects that have made a genuine cultural 5. Earlier Increments will be Adolescent
transition from projects that only pretends. The development organizations must ensure that
The following are some rough indicators available, customers and users should not expect to have good
1. The Lower-level Managers and the Middle Level or reliable deliveries at the initial stages. This can be
Managers should Participate in the Project done by demonstration of flexible benefits in successive
Development increments. The demonstration is similar to that of
Any organization which has an employee count less than documentation but involves measuring of changes, fixes
or equal to 25 does not need to have pure managers. The and upgrades based on the objectives so as to highlight
responsibility of the managers in this type of organization the process quality and future environments.
6. Artifacts Tend to be insignificant at the Early Stages Q29. List out the characteristics of conventional and
but Proves to be the most Significant in the Later iterative software development processes.
Stages Answer :
The details of the artifacts should not be considered Characteristics of Conventional Software Development
unless a stable and a useful baseline is obtained. This Process
transition is accepted by the development team while the
conventional contract monitors refuse this transition. The characteristics of the conventional software
development process are listed below,
7. Identifying and Resolving of Real Issues is Done in a
Systematic Order 1. It evolves in the sequential order (Requirement-Design-
Code-Test).
The requirements and designs of any successful project
arguments along with the continuous negotiations and 2. It gives the same preference to all the artifacts,
trade-offs. The difference between real and apparent components, requirements etc.
issues of a successful project can easily be determined. 3. It completes all the artifacts of a stage before moving to
This transition may affect any team of stakeholders. the other stage in the project life cycle.
8. Everyone should Focus on Quality Assurance 4. It achieves traceability with high-fidelity for all the
The software project manager should ensure that quality artifacts present at each life cycle stage.
assurance is integrated in every aspect of project it Characteristics of Iterative Software Development Process
should be integrated into every individuals role, every The characteristics of the modern iterative development
artifact, and every activity performed etc. There are process framework are listed below.
some organizations which maintains a separate group of
individuals known as quality assurance team, this team 1. It continuously performs round-trip engineering for
would perform inspections, meeting and checklist inorder requirements, design, coding and testing at evolving
to measure quality assurance. However, this transition levels of abstraction.
involves replacing of separate quality assurance team 2. It evolves the artifacts depending on the priorities of the
into an organizational teamwork with mature process, risk management.
common objectives and common incentives. So, this 3. It postpones the consistency analysis and completeness
transition is supported by engineering teams and avoided of the artifacts to the later stages in the life cycle.
by quality assurance team and conventional managers.
4. It achieves the significant drives (i.e., 20 percent) with
9. Performance Issues Crop-up Earlier in the Projects high-fidelity during the initial stages of the life cycle.
Life Cycle
Q30. Explain about next generation project
Earlier performance issues are a mature design process performance.
but resembles as an immature design. This transition is
Answer :
accepted by development engineers because it enables
the evaluation of performance tradeoffs in subsequent The purpose of designing next generation software
releases. project is to migrate from modern project architecture to the
10. Automation must be Done with Appropriate target project architecture. This architecture is a component-
Investments based architecture which comprises of modern process.
This process is supported by an advanced, fully integrated
Automation is the key concept of iterative development environment. Organizations that successfully perform the
projects and must be done with sufficient funds. transition must have the ability of managing software products.
Moreover, the stakeholders must select an environment These software products are developed from the existing
that supports iterative development. This transition is components. The advantages encountered while developing
mainly opposed by organizational managers. new software products are,
11. Good Software Organizations should have Good (i) Development time consumed is less
Profit Margins
(ii) Level of resource utilization is low
Most of the contractors for any software contracting firm
focus only on obtaining their profit margins beyond the (iii) Size of the team reduces to 50% of the actual team
acceptable range of 5% and 15%. They don’t look for the required by present software systems.
quality of finished product. As a result, the customers will It is necessary for such organizations to be careful while
be affected. For the success of any software industry, the performing the process because there is high probability of risks
good and honest contractors must be suitably rewarded (that may lead to failure of projects) to emerge. The main reason
whereas, bad contractors must be punished. If a finished for the occurrence of the risk is due to incomplete knowledge
product is of good quality and at a reasonable rate then, regarding the usage of new techniques and technologies. The
customer will not worry about the profit the contractor only way of avoiding the risk occurrence is by maintaining
has made. The bad contractors specially in a government complete information about the status quo and by being
contracting firm will be against this transition. dependent on the existing methods.
Maintaining the information about status quo might create development risk in those organizations where the transition is
done successfully but to a small percentage. The following two guidelines are considered by internal and external change agents
while making a decision about the transition.
(i) Initially, implement new techniques on small-scale project.
(ii) The organization must be prepared for the fact that while developing first software project the amount of resources
utilized, time consumed and money spend may be much more than the expected estimates.
Implementing new techniques on small-scale project may lead to better results, initial momentum or proof of concept. But,
the disadvantage is that these projects can never be used on the critical path of organization. Many organizations that successfully
performs the transition, employs critical project and higher caliber personnel instead of non-critical project with non-critical
personnel. This is because critical project that use new techniques basically have an adverse impact that is generally expected by
the organization.
An alternative way of performing the transition that supports automation technologies as well as modern architecture is
to follow the three step process.
1. Ready Step
(i) The modern techniques and technologies are analyzed
(ii) A new process is defined or existing process is improved
(iii) The process with fully integrated environment tools and components are supported
(iv) A plan is prepared.
2. Aim (Objective) Step
(i) A critical project is selected
(ii) A team support is provided
(iii) A demand for improved results is made.
3. Trigger (Fire) Step
In this step, the organizational and project level plan is implemented efficiently.
Important Questions
Short Questions
1. What are the best practices in software management? Refer Q2

2. Describe the 3-step process that is used as an alternative way of performing transition. Refer Q5
3. What are the two major improvements in next generation software cost estimation models? Refer Q8
Essay Questions
4. Discuss about the command center processing and display system replacement. Refer Q9
5. Give a common subsystem overview of CCPDS-R. Refer Q14
6. ‘There are two approaches to manage people in CCPDS-R’. Discuss them briefly. Refer Q20
7. Write short notes on,
(b) Early risk resolution. Refer Q22
8. Discuss about next generation software economics. Refer Q26
9. Explain culture shifts for modern process transitions. Refer Q28

SPPM

Uploaded by

Copyright:

Available Formats

SPPM

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SPPM

Uploaded by

Copyright:

Available Formats

SOftware process and Project management

Guess Papers with Solutions GP.1 - GP.4

Unit-wise Short & Essay Questions with Solutions

Part-A Short Questions with solutions Q1 - Q11 1.2 - 1.4

Unit - II Software Project Management Renaissance,

Part-A Short Questions with solutions Q1 - Q11 2.2 - 2.5

Unit - III Workflows and Checkpoints of Process,

Unit - IV Project Organization, Project Control

Unit - V CCPDS-R Case Study and Future Software

This unit includes topics like Software Process

Software Process Maturity, Process Assessment, The Initial Process, The

This unit includes topics like Software Project

Checkpoints of Process: Software Process

Workflows, Iteration Workflows, Major

Workflows and Checkpoints Milestones, Minor Milestones, Periodic Status

Structures, Planning Guidelines, Cost and

Schedule Estimating Process, Iteration Planning

Process, Pragmatic Planning.

Organizations: Line-of-Business Organizations,

Project Organizations, Evolution of Organizations,

Management Indicators, Quality Indicators, Life-

Cycle Expectations, Pragmatic Software Metrics,

Study and Future Software Project Management

Software Process Maturity

Process Reference Models

Capability Maturity Model (CMM), CMMI, PCMM, PSP, TSP.

Software Project Management Renaissance

Conventional Software Management, Evolution of Software Economics, Improving Software Economics,

The Old Way and the New Way.

Life-Cycle Phases and Process Artifacts

Planning Process, Pragmatic Planning.

Line-of-Business Organizations, Project Organizations, Evolution of Organizations, Process Automation.

Project Control and Process Instrumentation

Software Metrics, Metrics Automation.

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

II. Multiple Choice

(a) Software testing (b) System engineering

(c) Algorithm preparation (d) Architecture design

(a) Agents (b) Champions

(c) Sponsors (d) Managers

III. Match the Following

I. Fill in the Blanks

II. Multiple Choice

1. (b) 2. (a) 3. (c) 4. (d) 5. (c)

6. (a) 7. (b) 8. (b) 9. (d) 10. (c)

III. Match the Following

1. (e) 2. (d) 3. (a) 4. (b) 5. (c)

II. Multiple Choice

4. _______ is the advantage of commercial components. [ ]

5. Which of the following is a cost model parameter in improving software? [ ]

6. The principle of top talent _______. [ ]

I. Fill in the Blanks

3. Software management principles

4. Early risk resolution

II. Multiple Choice

6. (d) 7. (d) 8. (a) 9. (d) 10. (a)

III. Match the Following

II. Multiple Choice

(a) Plan development (b) Production complete components

(c) Prepare transition material (d) Define user manual