SPM 1-5 Unit's Sir Book Final

SRI MITTAPALLI COLLEGE OF ENGINEERING :: CC-U9
NH-16, Tummalapalem, Guntur -522233, AP.
Academic Year : 2023-24 Branch: CSE Year/Semester:III/I

Regulation : R20
Subject Name : Software Project Management
Course Instructor :
===========================================================================
Department Vision
To produce professional, ethical and globally competent graduates by imparting quality
education in the field of Computer Science & Engineering with capabilities to solve a wide
range of complex scientific, technological and societal problems.
Department Mission
M1: To educate students to be effective problem-solvers and life-long learners in
technical, innovative and entrepreneurial skills.
M2: To impart quality and value based education and contribute towards the
advancement of computing, science and technology to raise satisfaction level of all
stakeholders.
M3: To establish a continuous Industry Institute Interaction, participation,
collaboration to contribute skilled IT Engineers.
Program Educational Objectives (PEOs)

After 4 years of graduation, Graduates will be able to
PEO1: Graduates able to solve wide range of computing related problems by applying
the knowledge of Mathematics and innovative algorithms.
PEO2: Graduates pursue advanced degrees with a dedication for lifelong learning and
use their skills in an ethical & professional manner.
PEO3: To be able to adapt to the evolving technical challenges and changing career
opportunities.
Program Specific Outcomes

PSO1: Analyze: Identify the data, Design suitable algorithm by using Latest software for Real
Time Applications.
PSO2: Computing Paradigms: Understand the evolutionary changes in computing possess
knowledge of context aware applicability of paradigms and meet the challenges of the
future.
PROGRAM OUTCOMES (POs) as mentioned in Annexure I
Computer Science and Engineering graduates will be able to:
Engineering knowledge: Apply the knowledge of mathematics, science, engineering

PO1 fundamentals, and an engineering specialization to the solution of complex
engineering problems.
Problem analysis: Identify, formulate, review research literature, and analyze
PO2 complex engineering problems reaching substantiated conclusions using first
principles of Mathematics, Natural Sciences, And Engineering Sciences
Design/development of solutions: Design solutions for complex engineering
problems and design system components or processes that meet the specified needs
PO3
with appropriate consideration for the public health and safety, and the cultural,
societal, and environmental considerations
Conduct investigations of complex problems: Use research-based knowledge and
PO4 research methods including design of experiments, analysis and interpretation of
data, and synthesis of the information to provide valid conclusions.
Modern tool usage: Create, select, and apply appropriate techniques, resources, and
PO5 modern engineering and IT tools including prediction and modeling to complex
engineering activities with an understanding of the limitations.
The engineer and society: Apply reasoning informed by the contextual knowledge to
PO6 assess societal, health, safety, legal and cultural issues and the consequent
responsibilities relevant to the professional engineering practice.
Environment and sustainability: Understand the impact of the professional
PO7 engineering solutions in societal and environmental contexts, and demonstrate
theknowledge of, and need for sustainable development.
Ethics: Apply ethical principles and commit to professional ethics and responsibilities
PO8
and norms of the engineering practice.
Individual and team work: Function effectively as an individual, and as a member or
PO9
leader in diverse teams, and in multidisciplinary settings.
Communication: Communicate effectively on complex engineering activities with the
engineering community and with society at large, such as, being able to comprehend
PO10
and write effective reports and design documentation, make effective presentations,
and give and receive clear instructions.
Project management and finance: Demonstrate knowledge and understanding of the
engineering and management principles and apply these to one‟s own work, as a
PO11
member and leader in a team, to manage projects and in multidisciplinary
environments.
Life-long learning: Recognize the need for, and have the preparation and ability to
PO12 engage in independent and life-long learning in the broadest context of technological
change.
CourseObjectives:
Understand the purpose and importance of project management from the perspectives of
planning, tracking and completion of project and compare and differentiate organization
structures and project structures etc.,
Course outcomes:
BLOOMS
C.ONo. COURSE OUTCOME
TAXANOMY LEVEL
CO1 Build static web pages using HTML 5 elements APPLY (L4)
Apply JavaScript to embed programming interface for web

CO2 pages and also to perform Client side APPLY (L4)
validations
Build a basic web server using Node.js, work with Node
CO3 Package Manager (NPM) and recognize UNDERSTAND (L5)
the need for Express.js.
Develop JavaScript applications using typescript and work
CO4 with document database using REMEMBER (L6)
MongoDB.
Utilize Angular JS to design dynamic and responsive web
CO5 UNDERSTAND (L5)
pages
CO-PO MAPPING:
COURSE PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO10 PO11 PO12
CO1
CO2
CO3
CO4
CO5
CO-PSO MAPPING
COURSE PSO1 PSO2
Subject Code :R203105B

Academic Year : 2023-24 Branch:CSE Year/Semester:III/I

Regulation : R20
Subject Name : SOFTWARE PROJECT MANAGEMENT
Course Instructor :
===========================================================================
Syllabus
Unit # Details
Conventional Software Management: The waterfall model, conventional software
Management performance.
Evolution of Software Economics: Software Economics, pragmatic software cost
estimation.
I Improving Software Economics: Reducing Software product size, improving software
processes,improving team effectiveness, improving automation, Achieving required
quality, peer inspections.
The old way and the new: The principles of conventional software Engineering,
principles of modern software management, transitioning to an iterative process.
Life cycle phases: Engineering and production stages, inception, Elaboration,
construction, transition phases.
II
Artifacts of the process: The artifact sets, Management artifacts, Engineering
artifacts, programmatic artifacts.
Model based software architectures: A Management perspective and technical
perspective.
Work Flows of the process: Software process workflows, Iteration workflows.
III Checkpoints of the process: Major mile stones, Minor Milestones, Periodic status
assessments.
Iterative Process Planning: Work breakdown structures, planning guidelines, cost and
schedule estimating, Iteration planning process, Pragmatic planning.
Project Organizations and Responsibilities: Line-of-Business Organizations, Project
Organizations,evolution of Organizations.
Process Automation: Automation Building blocks, The Project Environment.
IV
Project Control and Process instrumentation: The seven core Metrics, Management
indicators, quality indicators, life cycle expectations, pragmatic Software Metrics,
Metrics automation.
Agile Methodology, Adapting to Scrum, Patterns for Adopting Scrum, Iterating
towards Agility.
Fundamentals of DevOps: Architecture, Deployments, Orchestration, Need, Instance
V
of applications,DevOps delivery pipeline, DevOps eco system. DevOps adoption in
projects: Technology aspects, Agiling capabilities, Tool stack implementation, People
aspect, processes
Text Books:
1) Software Project Management, Walker Royce, PEA, 2005.
2. Succeeding with Agile: Software Development Using Scrum, Mike Cohn, Addison Wesley.
3. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in
Technology Organizations, Gene Kim , John Willis , Patrick Debois , Jez Humb,1st Edition,
O’Reilly publications, 2016.
Reference Books:
1 Software Project Management, Bob Hughes,3/e, Mike Cotterell, TMH
2. Software Project Management, Joel Henry, PEA
3. Software Project Management in practice, Pankaj Jalote, PEA, 2005,
4. Effective Software Project Management, Robert K.Wysocki, Wiley,2006
5. Project Management in IT, Kathy Schwalbe, Cengage
e-Resources:
1. www.wikipedia.org/wiki/software_project_management
2. https://www.javatpoint.com/software-project-management
3. https://www.tutorialspoint.com/software_engineering/software_project_managem
ent.htm
Lesson Plan
Subject Code :R2032052

Academic Year : 2022-23 Branch: CSE

Year/Semester : III/I Regulation: R20
Course Instructor :
===========================================================================
Lesson Plan
Lecture /
Teaching Reference No.of Hours
Tutorial Unit No. Topic Covered
Aid Text Book Required
No.
1 UNIT I Introduction Software Project Managemet GB 1 1
2 UNIT I Conventional Software Management GB 1 1
3 UNIT I Waterfall model GB &PC 1 2
conventional software Management
4 UNIT I GB 1 1
performance
5 UNIT I Evolution of Software Economics GB 1 1
6 UNIT I Pragmatic software cost estimation GB 1 1
7 UNIT I Improving Software Economics GB 1 2
8 UNIT I peer inspections GB 1 1
The principles of conventional software GB &
9 UNIT I 1 2
Engineering PC
Principles of modern GB &
10 UNIT I 1 1
software management PC
11 UNIT I Transitioning to an iterative process GB 1 1
TEST
GB &
13 UNIT II Introduction to Life-Cycle Phases 1 1
PC
14 UNIT II Engineering and Production Stages GB 1 2
15 UNIT II Inception Phase GB 1 1
16 UNIT II Elaboration Phase GB 1 1
GB &
17 UNIT II Construction Phase 1 1
PC
GB &
18 UNIT II Transistion Pahses 1 1
PC
GB &
19 UNIT II Artifacts of the process 1 1
PC
GB &
20 UNIT II The artifact sets 1 2
PC
GB &
21 UNIT II Management artifacts 1 1
PC
GB &
22 UNIT II Engineering artifacts 1 1
PC
Programmatic GB &
23 UNIT II 1 1
artifacts PC
TEST
Introduction to model based software
25 UNIT III GB & PC 1 1
architectures
26 UNIT III Management Perspective GB & PC 1 2
27 UNIT III Technical Perspective GB & PC 1 2
28 UNIT III Software process workflows GB & PC 1 1
29 UNIT III Iteration workflows GB & PC 1 2
30 UNIT III Major mile stones GB & PC 1 2
Minor milestones, Periodic status
assessment
32 UNIT III Work breakdown structures GB & PC 1 2
33 UNIT III planning guidelines GB & PC 1 1
Cost and schedule

estimating
Iteration planning process, Pragmatic
planning
TEST
GB &
36 UNIT IV Introduction to Project organization 1 1
PC
GB &
37 UNIT IV Line-of Business Organization 1 2
PC
GB &
38 UNIT IV Project Organizations 1 2
PC
GB &
39 UNIT IV 1 1
Evaluation of organizations PC
GB &
40 UNIT IV Automation building blocks 1 2
PC
GB &
41 UNIT IV Project Environment 1 1
PC
Seven core metrics, Quality & management GB &
42 UNIT IV 1 2
indicators PC
43 UNIT IV life cycle expectations GB & PC 1 2
44 UNIT IV pragmatic Software Metrics GB & PC 1 1
45 UNIT IV Metrics automation GB & PC 1 1
TEST
GB &
46 UNIT V Introduction to Agile Methodology 1 1
PC
GB &
47 UNIT V ADAPTing to Scrum 1 1
PC
GB &
48 UNIT V Patterns for Adopting Scrum 1 1
PC
GB &
49 UNIT V Iterating towards Agility 1 1
PC
GB &
50 UNIT V Fundamentals of DevOps 1 1
PC
GB &
51 UNIT V Architecture 1 1
PC
GB &
52 UNIT V Deployments, Orchestration 1 1
PC
Need, Instance of applications, GB &
53 UNIT V 1 2
DevOps delivery pipel PC
GB &
54 UNIT V DevOps eco system 1 1
PC
GB &
55 UNIT V DevOps adoption in projects: 1 1
PC
Technology aspects, Agiling GB &
56 UNIT V 1 2
Capabilities PC
GB &
57 UNIT V Tool stack implementation 1 1
PC
GB &
58 UNIT V People aspect, processes 1 1
PC
TEST
Teaching Methodologies:
GB - Glass Board
PC: Personal Computer
PPT - Power Point Presentation
CO-PO
Mapping
Subject Code : R203105B

NH-16, Tummalapalem, Guntur-522233, AP.
I MID EXAMINATION
Academic Year :2022-23 Branch: CSE

Year/Semester: III/I Max. Marks: 30
Subject Name: SOFTWARE PROJECT MANAGEMENT
===========================================================================
Answer ALL Questions. All Questions carry equal marks
Blooms
Q. No. Question Marks CO
Taxonomy Level
a) Explain briefly Waterfall Model? 05M CO1 EVALUATE(BTL5)
1. b) Explain Important trends in Improving of
05M CO1 CREATE(BTL6)
Software Economics?
a) Write about briefly Principles of
05M CO2 CREATE(BTL6)
Conventional Software Engineering?
b) Write a Short notes on Life- Cycle
2.
Process
05M CO2 EVALUATE(BTL5)
a) Inception Phase b) Construction
Phase
a) Explain the overview of artefact set? 05M CO2 EVALUATE(BTL5)
b) Write about Software Process Work
3.
05M C03 CREATE(BTL6)
Flows?

I MID EXAMINATION
Academic Year: 2022-23 Branch: CSE

Year/Semester:III/I Max. Marks: 30
Subject Name: Software Project Management
===========================================================================
SCHEME OF VALUATION
1a) Approach of waterfall model 1M

Explanation of waterfall model 2M
Diagram 2M
1b) List of software trends 1M

Explanation with table 3M
2a) List 30 principles of conventional software 3M

Brief explanation 2M
2b) Functional Diagram 1M

Description of Inception phase 2M
Description Elaboration phase 2M
3a) Defination of artifact 1M

Artifcact set table 2M
Overview of artefact set 2M
3b) Defination & List of software workflows 2M

Diagram and description workflows 3M

I MID EXAMINATION

Year/Semester : III/I Max. Marks: 30
===========================================================================
ANALYSIS OF I MID
Blooms Taxonomy
Q. No. Question Marks CO
Level
a) Explain briefly Waterfall Model? 05M CO1 UNDERSTAND(BTL5)
1. b) Explain Important trends in Improving
05M CO1 UNDERSTAND(BTL6)
of Software Economics?
a) Write about briefly Principles of
05M CO2 REMEMBER (BTL6)
Conventional Software Engineering?
b) Write a Short notes on Life- Cycle
2.
Process
05M CO2 UNDERSTAND(BTL5)
a) Inception Phase b) Construction
Phase
a) Explain the overview of artefact set? 05M CO2 REMEMBER(BTL5)
b) Write about Software Process Work
3.
05M C03 UNDERSTAND(BTL6)
Flows?
CO MARKS %
MARKS %
C01 10 33.3
I.REMEMBER 10 33.3
C02 15 50
II.UNDERSTAND 20 66.7
CO3 05 16.7
CO WISE MARKS REME

DISTRIBUTION Bloom's MBER
CO Taxonomy , 1,
10,…
17% 33%
REME
1
MBER
, 2, 2
50% 33.3…
Subject Code : R2032052

II MID EXAMINATION

Year/Semester : III/II Max. Marks: 30
===========================================================================
Answer ALL Questions. All Questions carry equal marks
BLOOMS TAXONOMY
Q.No. QUESTION MARKS CO
LEVEL
Explain checkpoints of the process
CO3
1. 10 EVALUATE(BTL5)
in software project management?
a) Write about briefly process
CO4
automation in Software project 05 CREATE(BTL6)
development?
2.
b) Write a Short notes on
CO4
a) quality indicators b) 05
EVALUATE(BTL5)
Management indicators
EVALUATE(BTL5)
a) Explain the architecture of
05 CO5
Devops?
3. b) Explain briefly about agile
05 CO5 REMEMBER(BTL6)
methodology?

II MID EXAMINATION

Subject Name : SOFTWARE PROJECT MANAGEMENT
===========================================================================
MID-II SCHEME OF VALUATION
1a) Defination 1M
List the types of checkpoints 2M
Diagram of checkpoints 2M
Explanation of three checkpoints 5M
2a) definition of automation & process automation 2M

Diagram & Brief explanation 3M
2b) List of seven core metrics 1M

Description of management Indicators 2M
Description of Quality indicators 2M
2M
3a) Defination of Devops 1M
Diagram
Overview of architecture 2M
3b) policy of agile methodlogy 1M

Principles of agile 2M
Frames and brief notes 2M

II MID EXAMINATION

===========================================================================
ANALYSIS OF II MID
BLOOMS TAXONOMY
Q.No. QUESTION MARKS CO
LEVEL
Explain checkpoints of the process
CO3
1. 10 REMEMBER(BTL5)
in software project management?
a) Write about briefly process
CO4
automation in Software project 05 UNDERSTAND(BTL6)
development?
2.
b) Write a Short notes on
CO4 REMEMBER(BTL5)
a) quality indicators b) 05
Management indicators
a) Explain the architecture of
05 CO5 UNDERSTAND(BTL5)
Devops?
3. b) Explain briefly about agile
05 CO5 UNDERSTAND(BTL6)
methodology?
% MARKS %
CO MARKS
I.REMEMBER 15 50
C03 10 33.3
C04 10 33.3 II. UNDERSTAND 05 16.6
CO5 10 33.3 III. UNDERSTAND 10 33.3

Unit wise
Important
Questions

Unit Wise Important Questions

Year/Semester : III/II Subject Name :Software Project Management
===========================================================================
S. No. Q. No. Question
UNIT I : Conventional Software Management

a) Explain the theory of the waterfall model
1 1.1 b) Explain the in-practice of the waterfall model
c) Describe the conventional software project performance?
2 1.2 Explain the evolution of the software economics?
a) Explain briefly about the improving software economy?
3 1.3
b) Explain the Peer Inspections.
a) Explain the principles of Conventional software engineering (davis 30)?
4 1.4
b) Explain the principles of modern software engineering?
UNIT II : Life-cycle Phases
6 2.1 a) Explain the life-cycle stages?.
7 2.2 a) Explain the Phases a) inception b) construction?
8 2.3 Explain the Phases a) Elaboration b) Transition?
Define artefact? Explain the artefact set?
9 2.4
Explain the Management artifacts?
10 2.5
11 2.6 Explain the engineering artifacts and Pragmatic?.
UNIT III : Model Based Software Architectures
11 3.1 a) Explain the model based software architecture?
a) Explain the software workflows of the process?
12 3.2
b) Explain the Iteration workflows of the process?
13 3.3 1. a) Explain in detail about the checkpoints of the process?
a) Explain the procedure for WBS?
14 3.4
b) Explain the planning guidelines, cost and schedule estimating?
UNIT IV : Project Organization and Responsibilities
1. a) Explain the Line-of-Business Organization?
15 4.1
b) Discuss the project organization and evolution of organizations?
16 4.2 1. a) Explain the Process automation?
2. a) Explain the seven core metrics of the project control?
17 4.3 3. b) Expain a) Management Indicators b) Quality Indicators?
4. C) Explaint the life-cycle expectations?
UNIT V : Agile Methodology and DevOps
18 5.1 1. a) what is agile methodology? Expalin Patterns for adopting scrum?
a) Explain the architecture of DevOps?
b) Explain the fundamentals of DevOps?
19 5.2 a) Deployments b)Orchestration
c) List the apllications of the DevOps? Explain the DevOps Delivery Pipeline?
d) Explain the DevOps Eco System?
a) Explin the adoption in the Projects?
20 5.3
b) Discuss the tool stack implementation and people aspects?
Objective
Type
Questions

Objective Type Questions

Year/Semester : III/I Subject Name :SOFTWARE PROJECT MANAGEMENT
===========================================================================
1. _______ is not an effective software project management focus.

a) People b) Product c) Process d) Popularity
2. _________ is not a project manager’s activity

a) Project design b) Project management
c) Project planning d) Project Control
3. The __________ is not an approach to software cost estimation?

a) Analytical b) Critical
C) Empirical d) Heuristic
4. Waterfall model is also known as

a) Prototype model b)Linear sequential model
c) Iterative model d)None
5. A Waterfall model is a model of

a)System devoplemt life cycle b) system enhancement
c) System Prototype d) All of the above
6. With reference to waterfall model, each phase must be completed before the ___ can begin
and there is no overlapping in the phases
a) Previous phase b) next phase c) both A and B d) None
7. List of factor to Improving software economics are

a) Reducing size b) improving software process
b) Improving team effectiveness d) All of the above
8. In the basic waterfall model, There are two essential steps common to
the development of computer programs
a) Requirements
b) Design
c) Coding
d) Testing
9. The best thing about software is its?
a) Flexibility b) adoptability
C) Compatability d) All of the above
10. Finding and fixing a software problem after delivery costs ------ times
more than finding and fixing the problem in early design phases
a) 50 b) 10 c) 100 d)20
11. ROI Refers to
a) Requirements on Investment b) Relation on Integration c) Return of

Investment d) Return on Investment
12. SLOC Refers to

a) Software lines of code
b) Source lines on compiler
c) Source lines of code
d) none
13. ------------- refers to an organization 's policies, procedures, and

practices for pursuing a software-intensive line of business
a) Micro Process
b) Meta Process
c) Macro Process
d) None Process
14. The time scale of meta process is -----------

a) 6-12 months c) 3-6 months
b) 3-9 months d) 9-12 moths
15. Walkthroughs catch ---------of the errors

a) 100% b) 50% c) 40% d) 60%
16. ------% of the contribution comes from -----% of the contributors.

a) 60,80 b) 80,20 c) 20,80 d) none
17. Five staffing principles are proposed by -----

a) Boehm b) walker Royce
c) Davis d) none of the above
18. ------------ proposed The Principles of Conventional Software
Engineering
a) Boehm b) Keith Davis c) Royce d) none
19. Design without ------------is not design
a) Analysis b) coding
c) Documentation d) Requirements
20. The COCOMO refers to
a)Cost Construction Modeling
b)Cost Constructive Model
c)Code Constant Model
d)None of the above
21. The overriding goal of the ----------phase is to achieve concurrence
among stakeholders on the life cycle objectives for the project.
a) elaboration b) inception c) construction d) Transistion
22. Achieving useful versions (alpha, beta, and other test releases) as
rapidly as practical is one of the primary objectives of -------- phase.
a) Inception b) elaboration c) construction d)transistion
23 Life-cycle software artifacts are organized into ------distinct sets

a) 4 b) 3 c) 2 d) 5
23. --------- represents cohesive information that typically is developed and
reviewed as a single entity
a) workflow b) Artifact c) Business case d) none of these
24. The entire ------------set is a test artifact because it is the basis of all
assessment activities across the life cycle
a) Design b) Requirement c) deployment d) artifact
25. --------------provideperiodic snapshots of project health and status,

including the software project manager 's risk assessment, quality
indicators, and management indicators.
a) Major milestones b) minor milestones c) status assessment d) none
26. C ------------ is the vehicle for budgeting and collecting costs

a) WBS b) workflows c) artifacts d) none
27. UML refer to

a) Unified Mark ping Language
b) Unified making Location
c) Unified Modeling Language
d) None
28. ------------ view addresses the basic structure and functionality of the
solution.
a) Requirement b) design c)construction d) deployment
29. ---------- view is modelled statically using deployment diagrams

a) Process b) Design c) Requirement d) Deployment
30. An ------------- is the software system design

a) Architecture b) Architecture baseline c) Component design d)none
31. DevOps is Considered as Practice

a) To Co-ordinate the development team
b) To co-ordinate the operation team
c) To bring development and operation teams together
d) To coordinate the customer
32. Which of the tool is supported for automated testing
a) Snyk b) gitLab c)Jenkins d)AWS
33. MTBF means
a) The average time between software faults
b) The minimum time between failures
c) The maximum time between failures
d) The maturity between failures
34. Modulatity refers to
a) Average breakage trend over time
b) Maximum breakage
c) No concerned with time
d) Minimum breakage
35. which of the following is the management indicator?
a)Rework and adoptability
b)Mean time between failures
c)work and progress
d)change traffic and stability
36. Agile address the gap between----------- and -------communications
a) Devloper and user

b) Customer and tester
c) Customer and developer
d) Developers and product owners
36. Which of the agile methodology advocates the use of problem domain
a) Evo b) Scrum c) Extream Programming (XP) d)Feature –Driven development(FDD)
37. -----------characterstic of an Agile Leader
a) Task focused b) Supportive c)Disinterested d)Process Oriented

38. ---------is not an agile method
a) XP b)AUP c)4GT d)none of the above
39. Which of the following is the responsible for Sprint meeting?
a) Scrum team b) Scrum master c)Product owner d)none of the above
40. What is the different types of agile methodologies?
a) Scrum b)DSDM c)FDD d)all of the above
Unit wise
Notes
UNIT-I
UNIT-II
UNIT - II
Life cycle phases: Engineering and production stages, inception, Elaboration, construction,
transition phases.
Artifacts of the process: The artifact sets, Management artifacts, Engineering artifacts,
programmatic artifacts.
I) Life cycle phases:-
Characteristic of a successful software development process is the well-defined
separation between "research and development" activities and "production" activities. When
software projects are un-successful projects (or) project failures to define and execute these 2
stages.
 Engineering Stage
 Production Stage
Engineering stage:- Small teams focus on design and combination activities. It is composed
with inception and elaboration.
Production Stage:- Large teams focus on construction, test, and deployment activities. It is
composed with construction and transition.
Engineering stage is decomposed into two distinct phases, inception and elaboration, and the
production stage into construction and transition. These four phases of the life-cycle process
are loosely mapped to the conceptual framework of the spiral model as shown in below.
Inception Phase:-
By using this phase to achieve concurrence among stakeholders on the life-
cycle objectives for the project. Get agreement from the stack holders on the objective of the
project.
a) Primary Objectives:-
 Establishing the project scope and boundary conditions, including an operational
concept, acceptance criteria, and a clear understanding of what is planned and un
planed in the product.
 To determine the cost schedule of the entire project.
 To verify one candidate architecture against some of the primary sequence of events.
 To separate the critical use cases of the system and the primary sequence of events of
the system operation
 To evaluate potential risks (sources of unpredictability)
b) Essential Activities:-
 Developing the scope of the project:-

It refers to the process of gathering the
requirements and operational concepts in information repository. i.e. describe the
requirements according to the user view. This is enough to determine the problem
space and acceptance criteria for the final product.
 Producing the architecture:-
An information repository is created that is sufficient to
demonstrate the feasibility of at least one candidate architecture and an initial
baseline of make/buy decisions so that the cost, schedule, and resource estimates can
be derived.
 Planning and preparing a business case:-
Alternatives for risk management, staffing,
iteration plans, and cost/schedule/profitability trade-offs are evaluated.
c) Primary Evaluation Criteria:-
 Whether all stakeholders agree on the scope definition and cost and schedule
estimates?
 Are requirements understood, as evidenced by the fidelity of the critical use cases?
 Determine whether the estimation of cost and schedule, priorities, risks, and
development processes conveyable?
 Whether the depth and breadth of an architecture prototype demonstrate the
preceding criteria?
Elaboration phase :-
It is one of the most critical phase among all 4 phases. At the end of this
phase, the "engineering" is considered complete and project faces its estimation: the decision
is made whether or not commit to the production phase.
a) Primary Objectives
 To determine the architecture in such a way that all changes can be monitored and managed
 To Base line the vision.
 To determine the base line architecture will support the vision at a valid cost in a valid time
 The Base line a high- constancy plan for the construction phase
b) Essential Activities
 Elaborating the vision.

 Elaborating the process and infrastructure.
 Elaborating the architecture and selecting components.
 Is the vision stable?

 Is the architecture stable?
 Does the executable demonstration show the addressing and reasonability resolving of
major risk elements?
 Is the construction phase plan provide enough reliability and does it backed up with a
credible basis of estimate?
 Do all stakeholders agree that the current vision can be met if the current plan is executed
to develop the complete system in the context of the current architecture?
Construction Phase :-
This phase represents a production process, in which emphasis is placed
on managing resources and controlling operations to optimize costs, schedules, and quality. All
the components are integrated into the application and tested.
 Minimizing development costs by optimizing resources and avoiding unnecessary

scrap and rework
 Achieving sufficient quality as fast as practical
 Achieving useful versions (alpha, beta, and other test releases) as fast as practical
 Manage and controlling Resource and process optimization

 Complete component development and testing against evaluation criteria
 Estimating the product releases against acceptance criteria of the vision
 Whether the product baseline is fully developed to be used in the user community?
 Whether the product baseline is sufficiently stable to be used in user community?
 Does the stakeholders ready for transition to the user community?
 Are actual resource expenditures v/s planned expenditures acceptable?
Transition Phase:-
The transition phase is entered when a baseline is mature enough to be
deployed in the end-user domain. This phase include any of the following activities:
1. Beta testing to validate the new system against user expectations
2. Beta testing and parallel operation relative to a legacy system it is replacing
3. Conversion of operational databases
4. Training of users and maintainers
The transition phase concludes when the deployment baseline has achieved the complete
vision.
 Achieving user self-supportability
 Achieving stakeholder concurrence that deployment baselines are complete and
consistent with the evaluation criteria of the vision
 Achieving fast and cost-effective baselines for the final product
 Synchronization and integration of concurrent construction increments into consistent
deployment baselines
 Deployment-specific engineering
 Evaluating the deployment baselines against the acceptance criteria and the vision.
c) Evaluation Criteria:-
 Is the user satisfied?
 Are actual resource expenditures versus planned expenditures acceptable?
II) Artifacts of the process
1) The Artifact Sets:-
An artifact is a tangable result of the software process. It may be written documents
(description, specification, design, plan, etc..) software modules (products ,tools,test data) or
process definition.
The artifact sets are set of related artifacts. There are 2 kinds of artifacts. They are
 Management artifacts
 Engineering artifacts
The Management Set:-

The artifacts associated with process planning and execution.
Capture the "contracts" among project personnel, stakeholders and between project personnel
and stakeholders.
These artifacts included in this set. They are
 Work breakdown structure  Status assessments

 Business case  Software change orders database
 Release specifications  Deployment documents
 Software development plan  Environment
 Release descriptions
The Engineering Set:-

The engineering sets consist of the requirements, design, implementation and
deployment set.
a) Requirements Set:- Requirements artifacts are evaluated, assessed, and measured
through a combination of the following:
 Analysis of consistency with the release specifications of the management set
 Analysis of consistency between the vision and the requirements models
 Mapping against the design, implementation, and deployment sets to evaluate the
consistency and completeness and the semantic balance between information in the
different sets
 Analysis of changes between the current version of requirements artifacts and previous
versions (scrap, rework, and defect elimination trends)
b) Design Set:-
UML notation is used to engineer the design models for the solution. The design
set contains various levels of abstraction that represent the components of the solution.
The design set is evaluated, assessed, and measured through a combination of the
following:
 Analysis of the internal consistency and quality of the design model
 Analysis of consistency with the requirements models
 Translation into implementation and deployment sets and notations to evaluate the
consistency and completeness and the semantic balance between information in the sets
 Analysis of changes between the current version of the design model and previous versions
Subjective review of other dimensions of quality
c) Implementation set:-
The implementation set includes source code (programming language notations)
that represents the physical implementation of components. Implementation sets are
human-readable formats that are evaluated, assessed, and measured through a combination
of the following:
 Analysis of consistency with the design models
 Translation into deployment set notations (for example, compilation and linking) to evaluate
the consistency and completeness among artifact sets
 The component source or executable files against relevant evaluation criteria through
inspection, analysis, demonstration, or testing
 Execution of each component test cases that automatically compare expected results with
actual results
 Analysis of changes between the current version of the implementation set and previous
versions
 Subjective review of other dimensions of quality
d) Deployment Set:-
The deployment set includes user deliverables, machine language notations,
executable software, the build scripts, installation scripts, and executable target specific data
necessary to use the product in its target environment.
 Deployment sets are evaluated, assessed, and measured through a combination of the
following:
 Testing against the usage scenarios
 Testing the partitioning, replication, and allocation
 Testing against the defined usage scenarios in the user manual
 Analysis of changes between versions
 review of other dimensions
 Management set:- Ad-hoc textual format
 Requirements set:- organized text and models of the problem space.
 Design set :- Model of solution space.
 Implementation set:- Human-readable programming languages and associated source files.
 Deployment set:- Machine processable language and associated files.

Artifact Evolution Over The Life Cycle:-
Each state of development represents a certain amount of
accuracy in the final system description. Early in the life cycle, accuracy is low and the
representation is generally high. If the accuracy of representation is high and everything is
specified in full detail. Each phase of development focus on particular artifact set. At the end
of each phase, the overall system state will have progressed on all sets.
Inception phase:- It focus on critical requirements usually with a secondary focus on an

initial deployment view.
Elaboration phase: - It is much greater depth in requirements, much more breadth in the
design set, and further work on implementation and deployment issues.
Construction phase: - It is design and implementation.
Transition phase:- we can achieving consistency and completeness of the deployment set in
the context of the other sets.
Management artifacts
Management Artifacts includes over all condition (or) situation to confirm and ensure that
instructional technology project gets done. It contains various activities that capture
intermediate results and supporting information and data that are essential to document the
end-product/process legacy, maintain the end-product, increase quality of product, and also
increases performance of the process. Some types of Management Artifacts. They are
1) Business Case:-
The business case generally provides confirmation for initiating project, task,
and program. This confirmation is simply based on the estimated cost, risks and issues and
evaluated business benefits and savings to be gained.
A business case is good if describes problems and issues, determines all the
possible options to address it, and gives permission to the decision-makers to decide which of
the course of the action will be best for organization. The main goal of business case to
convert vision into economic teams so that organization can develop exact and accurate ROI
(Return on Investment) assessment.
2) Software Development Plan (SDP):-
Software development plan aims to lay out whole plan
which is necessary and required in order to develop, modify, and upgrade software system. It
provides insight and tool for checking processes that have to be followed for development of
software.
It simply indicates two things: Periodic updating and understanding and approval by
managers and practitioners alike.
3) Work Breakdown Structure (WBS):-
Work breakdown structure is deliverable-oriented breakdown
of project into component of small size. WBS is created and developed to establish similar
understanding of scope of project.It is hierarchical tree structure that layout project and
simply breaks it down into smaller and manageable portions or components
4) Software Change Order Database :-
For Iterative development process, primary task to manage change. A project can iterate
(perform repeatedly) more productively with large change freedom. This change of freedom
has been gained due to automation.
5) Release Specification:-
Release specifications generally mean tests and limits against that which
raw material, intermediate and end product are accurately measured just before use or
release.
Two important forms of requirements in release specifications are Vision Statement
(captures contract between development group and buyer) and Evaluation Criteria
(management-oriented requirements that can be showed and represented using use cases,
use cases realizations, etc).
6) Deployment:- –
It is simply application code as it runs on production: build,combined, compiled,
etc. It is process of putting artifact where it is necessary and performing any tasks it needs so
as to achieve its purpose. It can also include computer system operations manuals, software
installations manuals, plans and procedures for cutover, etc.
7) Environment:- –
Automation of development process needs and important to get supported by
robust development environment.
It must include following points:
 Management of requirements.  Tools of host and target programming.

 Visual Modeling.  Tracking of features and defects or
 Automation of document. errors.
 Automated regression testing.
ENGINEERING ARTIFACTS
Most of the engineering artifacts are gathering in various engineering notations such as UML,
programming languages, or executable machine codes. There are three types of engineering
artifacts. They are
 Vision Document
 Architecture Description
 Software User Manual
Vision Document:-
The vision document provides a complete vision for the software system under devel-
opment and supports the contract between the funding authority and the development
organization. A project vision is means changeable as understanding to get the requirements,
architecture, plans, and technology. A good vision document should change slowly. It provides
a default outline for a vision document.
Architecture Description :-
An architecture description is collection of artifacts that document an architecture that
includes an organized view of software architecture under development. It is generally taken
and extracted from design model and also contains views of design, implementation, and
deployment sets. In Architecture description, architecture views are generally key artifacts.
Software User Manual :-
Software user manual provides important documentation that is very

much needed to support software that is delivered. This documentation is generally
provided to user. It should include procedures of installation, usage, guidance, operational
constraints, and an explanation regarding user interface.
Test team members should write this user manual and should be developed at
an early stage in life cycle. This is due to reason that user manual is an essential mechanism
simply used for communicating and maintain an essential requirement subset.
Pragmatic Artifacts
It is the conventional document-driven approach that generally squandered unbelievable

amounts of engineering time simply given on development, smooth, format, review, update,
modify and distribute documents. It is an approach that redirects this effort of documentation
to simply improve accuracy and easily understanding of source of data or information
 People simply want to review data or information but sometimes don’t be able to
understand language of artifacts.
 People want to review the information but don't have access to the tools.
It is not very common for the development organization to be fully derived; it is
extremely rare that the/other stakeholders have any capability to review the engineering
artifacts on-line. Consequently, organizations are forced to exchange paper documents.
Standardized formats (such as UML, spreadsheets, Visual Basic, C++, and Ada 95),
visualization tools, and the Web are rapidly making it economically feasible for all
stakeholders to exchange information electronically.
 Human-readable engineering artifacts should use rigorous notations that are

complete, consistent, and used in a self-documenting manner.
Properly spelled English words should be used for all identifiers and descriptions.
Acronyms and abbreviations should be used only where they are well accepted jargon in
the context of the component's usage. Readability should be emphasized and the use of
proper English words should be required in all engineering artifacts. This practice
enables understandable representations, browse able formats (paperless review), more-
rigorous notations, and reduced error rates.
 Useful documentation is self-defining: It is documentation that gets used.
 Paper is tangible; electronic artifacts are too easy to change. On-line and Web-based
artifacts can be changed easily and are viewed with more skepticism because of their
inherent volatility.
UNIT-III
UNIT- III
Model based software architectures: A Management perspective and technical perspective.
Work Flows of the process: Software process workflows, Iteration workflows.
Checkpoints of the process: Major mile stones, Minor Milestones, Periodic status
assessments.
1) Model Based Software Architectures

These are reusable resources are designed for flexibility. They will not easily fail as
changes occur in functionality, performance or technology.
The objective of model based software engineering (MBSE) is to improve product
cycle time, quality and maintainability through a formal understanding of features and
structure of a product family.
There are 2 model based software architecture views.they are:
a) Technical perspective
b) Management perspective
a) Technical perspective:-
Software architecture includes architecture views with the
following details. They are
 Design:- structures’ and functions of the design model.
 Component:- structure of the implementation set.
 Deployement:- structure of the deployment.
 Process:- concurrency and control among the design, component and deployment
views.
Design view includes basic structure and functionality of solution.process view contains
runtime collaboration.component view includes architecture elements in implementation set
and deployement view is the executable understanding of the architecture.
b) Management perspective:-
To understand management architecture, first we have to
understand three different aspects of architecture. They are
 Architecture :- design of entire software system .

 Architecture baseline:- It is a snapshot of the engineering artifact sets which achieves
stakeholders agreement and approval.
 Architecture description:- Human-readable representation of an architecture.
It provides a basis for balancing trade-off between problem and solution spaces.
Architecture and process encapsulate communication among stakeholders. Poor architecture
and immature process are causing of project failures.
An architecture baseline should include the following:
 Requirements: It includes critical use cases, system-level quality objectives, and priority
relationships among features and qualities
 Design: Names, attributes, structures, behaviors, groupings, and relationships of significant
classes and components
 Implementation: This phase mainly focus on source component inventory and bill of
materials (number, name, purpose, cost) of all primitive components
 Deployment: Executable components sufficient to demonstrate the critical use cases and the
risk associated with achieving the system qualities
Workflows:-
The workflow refers to the series of sequential tasks those are performed to
achieve certain goal. Each workflow step is defined by three parameters i.e input,
transformation, and output. In workflow process a series of actions are performed to achieve a
business outcome.
Process workflows:-
The process workflows lead the software developments in a linear way by
performing series of sequential tasks.
Software development includes 7 types of workflows. They are
1. Management workflow –
Some of the essential steps of controlling process are carried out in
management workflow. The artifacts include Software Development Plan (SDP), business
case, and vision etc.Ensuring win win condition for stake holders in terms of developing,
executing and implementing software project.
2. Environment workflow – Automating the process preparing the maintenance.
3. Requirements workflow – Analyzing the problem space for identifying/understanding the
problems and finding a solution. Elaborate the use case to be understand and developed.
4. Design workflow – develop the architecture and Modeling the solution
5. Implementation workflow – In this workflow we can develop new components,
implementation and deployment artifacts
6. Assessment workflow – Assessing the trends in process, evaluate results of iteration,
identify rework and Product quality
7. Deployment workflow – The process of delivering the end products to the user.
Iterative work flows

UNIT-III
Checkpoints of the process: Major mile stones, Minor Milestones, Periodic status
assessments.
Checkpoints of the process:-

In software development, all system-wide events are held at the
end of every phase of development. It provides visible milestones in the life cycle where
various stakeholders meet, face to face, to discuss progress and plans and also to system-
wide issues and problems. These checkpoints generally provide following things
 It simply integrates management and engineering point of view.

 It also verifies the goal of every phase has been achieved or not.
 It provide basis for analysis and evaluation so as to determine whether or not. project is get
going as planned, and also to make correction and right action as per requirement.
 It also identifies risks, issues, or problems that are required and conditions that are not
manageable.
 For entire life-cycle, it performs global analysis.
Major mile stones:-
 Major milestones are system-wide event that is performed at the end of each phase of
development.
 These milestones can be used in various process models. These are providing visibility to
system-wide issues.
 It helps to integrate management and engineering point of view.
 It helps in verifying that target or goal of each phase has been achieved successfully or not.
 They are used to achieve concurrence among every stakeholder in present state of project.
 It also helps in make sure consistency between different artifacts.
Minor Milestones:-
Minor milestones are also called as micro milestones. They are simply
monitoring points that project manager generally uses to maintain control of activities of each
day. Minor milestones are iteration-focused events that are conducted to review data or
content of iteration in detailed manner. They generally divide elapsed time between major
milestones into short time intervals. This is done to give confidence to us that major
milestones will be achieved.
Status Assessments:-
 Status Assessments generally provides mechanism that is useful for addressing,

communicating, and resolving issues or problems regarding management, technical, and
project risks.
 Its main objective is to ensure that all expectations of all parties are synchronized and
consistent.
 It also maintains communication between all stakeholders.
 It also provides management with frequent and regular insight into progress that is being
made.
1) Major mile stones:-
In an iterative model, the major milestones are used to achieve
concurrence among all stakeholders on the current state of the project. Different stakeholders
have different concerns:
Customers: - schedule and budget estimates, feasibility, risk assessment, requirements
understanding, progress, product line compatibility.
Users: - consistency with requirements and usage scenarios, potential for accommodating
growth, quality attributes.
Architects and systems engineers: - product line compatibility, requirements changes,
tradeoff analyses, completeness and consistency, balance among risk, quality and usability.
Developers: - Sufficiency of requirements detail and usage scenario descriptions, frameworks
for component selection or development, resolution of development risk, product line
compatibility, sufficiency of the development environment.
Maintainers: - Sufficiency of product and documentation artifacts, understandability,
interoperability with existing systems, sufficiency of maintenance environment.
Others:- regulatory agencies, independent verification and validation contractors, venture
capital investors, subcontractors, associate contractors, and sales and marketing teams.
Life-Cycle Objective Milestone: These milestones occur at the end of the inception phase. The
goal is to present to all stakeholders a recommendation on how to proceed with development,
including a plan, estimated cost and schedule, and expected benefits and cost savings.
Life- Cycle Architecture Milestone: These milestones occur at the end of the elaboration
phase. Primary goal is to demonstrate an executable architecture to all stakeholders. A more
detailed plan for the construction phase is presented for approval. Critical issues relative to
requirements and the operational concept are addressed.
Initial Operational Capability Milestone: These milestones occur late in the construction
phase. The goals are to assess the readiness of the software to begin the transition into
customer / user sites and to authorize the start of acceptance testing.
Product Release Milestone: Occur at the end of the transition phase. The goal is to assess the
completion of the software and its transition to the support organization, if any. The results of
acceptance testing are reviewed, and all open issues are addressed and software quality
metrics are reviewed to determine whether quality is sufficient for transition to the support
organization.
MINOR MILESTONES:-
For most iterations, which have a one-month to six-month duration, only
two minor milestones are needed: the iteration readiness review and the iteration assessment
review.
Iteration Readiness Review. This informal milestone is conducted at the start of each iteration
to review the detailed iteration plan and the evaluation criteria that have been allocated to
this iteration.
Iteration Assessment Review. This informal milestone is conducted at the end of each iteration
to assess the degree to which the iteration achieved its objectives and satisfied its evaluation
criteria, to review iteration results, to review qualification test results (if part of the iteration),
to determine the amount of rework to be done, and to review the impact of the iteration
results on the plan for subsequent iterations.
The format and content of these minor milestones tend to be highly dependent on the project
and the organizational culture. Figure 9-4 identifies the various minor milestones to be
considered when a project is being planned.
PERIODIC STATUS ASSESSMENTS
Periodic status assessments are management reviews
conducted at regular intervals (monthly, quarterly) to address progress and quality indicators,
ensure continuous attention to project dynamics, and maintain open communications among
all stakeholders.
Periodic status assessments serve as project snapshots. While the period may vary, the
recurring event forces the project history to be captured and documented. Status assessments
provide the following:
 A mechanism for openly addressing, communicating, and resolving man-agreement

issues, technical issues, and project risks
 Objective data derived directly from on-going activities and evolving product
configurations
 A mechanism for disseminating process, progress, quality trends, practices, and

experience information to and from all stakeholders in an open forum
Periodic status assessments are crucial for focusing continuous attention on the evolving
health of the project and its dynamic priorities. They force the software project manager to
collect and review the data periodically, force outside peer review, and encourage
dissemination of best practices to and from other stakeholders.
Iterative Process Planning:- Work breakdown structures, planning guidelines, cost
and schedule estimating, Iteration planning process, Pragmatic planning.
A good work breakdown structure and its synchronization with the process
framework are critical factors in software project success. Development of a work breakdown
structure dependent on the project management style, organizational culture, customer
preference, financial constraints, and several other hard-to-define, project-specific
parameters.
1 ) Work breakdown structures:-
A WBS is simply a hierarchy of elements that decomposes the project plan into the
discrete work tasks. A WBS provides the following information structure:
 A delineation of all significant work

 A clear task decomposition for assignment of responsibilities
 A framework for scheduling, budgeting, and expenditure tracking
Many parameters can drive the decomposition of work into distinct tasks: product
subsystems, components, functions, organizational units, life-cycle phases, even geographies.
Most systems have first-level decomposition by subsystem. Subsystems are then decomposed
into their components, one of which is typically the software.
CONVENTIONAL WBS ISSUES :

Conventional work breakdown structures frequently suffer from
three fundamental flaws.
1. They are prematurely structured around the product design.
2. They are prematurely decomposed, planned, and budgeted in either too much or too little
detail.
3. They are project-specific, and cross-project comparisons are usually difficult or impossible.
Conventional work breakdown structures are prematurely decomposed, planned, and

budgeted in either too little or too much detail. A WBS is the architecture for the financial
plan. Large software projects tend to be over planned and small projects tend to be under
planned. The basic problem with planning too much detail at the outset is that the detail does
not evolve with the level of fidelity in the plan.
Conventional work breakdown structures are project-specific, and cross-project
comparisons are usually difficult or impossible. With no standard WBS structure, it is
extremely difficult to compare plans, financial data, schedule data, organizational efficiencies,
cost trends, productivity trends, or quality trends across multiple projects.
Figure 1-1 Conventional work breakdown structure, following the product hierarchy
Management
System requirement and design
Subsystem 1
Component 11
Requirements
Design
Code
Test
Documentation
…(similar structures for other components)
Component 1N
Requirements
Design
Code
Test
Documentation
…(similar structures for other subsystems)
Subsystem M
Component M1
Requirements
Design
Code
Test
Documentation
…(similar structures for other components)
Component MN
Requirements
Design
Code
Test
Documentation
Integration and test
Test planning
Test procedure preparation
Testing
Test reports
Other support areas
Configuration control
Quality assurance
System administration
EVOLUTIONARY WORK BREAKDOWN STRUCTURES
An evolutionary WBS should organize the planning elements around the process
framework rather than the product framework. The basic recommendation for the WBS is to
organize the hierarchy as follows:
 First-level WBS elements are the workflows (management, environment, requirements,

design, implementation, assessment, and deployment).
 Second-level elements are defined for each phase of the life cycle (inception, elaboration,
construction, and transition).
 Third-level elements are defined for the focus of activities that produce the artifacts of
each phase.
A default WBS consistent with the process framework (phases, workflows, and artifacts) is
shown in Figure 1-2. This recommended structure provides one example of how the elements
of the process framework can be integrated into a plan. It provides a framework for estimating
the costs and schedules of each element, allocating them across a project organization, and
tracking expenditures.
The structure shown is intended to be merely a starting point. It needs to be tailored to the
specifics of a project in many ways.
 Scale: Larger projects will have more levels and substructures.

 Organizational structure: Projects that include subcontractors or span multiple
organizational entities may introduce constraints that necessitate different WBS
allocations.
 Degree of custom development: Depending on the character of the project, there can be
very different emphases in the requirements, design, and implementation workflows.
 Business context: Projects developing commercial products for delivery to a broad
customer base may require much more elaborate substructures for the deployment
element.
 Precedent experience: Very few projects start with a clean slate. Most of them are
developed as new generations of a legacy system (with a mature WBS) or in the context of
existing organizational standards (with preordained WBS expectations).
The WBS decomposes the character of the project and maps it to the life cycle, the budget,
and the personnel. Reviewing a WBS provides insight into the important attributes, priorities,
and structure of the project plan. Another important attribute of a good WBS is that the
planning fidelity inherent in each element is commensurate with the current life-cycle phase
and project state. Figure 1-3 illustrates this idea.
Figure 1-2 Default work breakdown structure
Management
AA Inception phase management
AAA Business case development
AAB Elaboration phase release specifications
AAC Elaboration phase WBS specifications
AAD Software development plan
AAE Inception phase project control and status assessments
AB Elaboration phase management
ABA Construction phase release specifications
ABB Construction phase WBS baselining
ABC Elaboration phase project control and status assessments
AC Construction phase management
ACA Deployment phase planning
ACB Deployment phase WBS baselining
ACC Construction phase project control and status assessments
AD Transition phase management
ADA Next generation planning
ADB Transition phase project control and status assessments
B Environment
BA Inception phase environment specification
BB Elaboration phase environment baselining
BBA Development environment installation and administration
BBB Development environment integration and custom toolsmithing
BBC SCO database formulation
BC Construction phase environment maintenance
BCA Development environment installation and administration
BCB SCO database maintenance
BD Transition phase environment maintenance
BDA Development environment maintenance and administration
BDB SCO database maintenance
BDC Maintenance environment packaging and transition
C Requirements
CA Inception phase requirements development
CCA Vision specification
CAB Use case modeling
CB Elaboration phase requirements baselining
CB Elaboration phase requirements baselining
CBA Vision baselining
CBB Use case model baselining
CC Construction phase requirements maintenance
CD Transition phase requirements maintenance
D Design
DA Inception phase architecture prototyping
DB Elaboration phase architecture baselining
DBA Architecture design modeling
DBB Design demonstration planning and conduct
DBC Software architecture description
DC Construction phase design modeling
DCA Architecture design model maintenance
DCB Component design modeling
DD Transition phase design maintenance
E Implementation
EA Inception phase component prototyping
EB Elaboration phase component implementation
EBA Critical component coding demonstration integration
EC Construction phase component implementation
ECA Initial release(s) component coding and stand-alone testing
ECB Alpha release component coding and stand-alone testing
ECC Beta release component coding and stand-alone testing
ECD Component maintenance
F Assessment
FA Inception phase assessment
FB Elaboration phase assessment
FBA Test modeling
FBB Architecture test scenario implementation
FBC Demonstration assessment and release descriptions
FC Construction phase assessment
FCA Initial release assessment and release description
FCB Alpha release assessment and release description
FCC Beta release assessment and release description
FD Transition phase assessment
FDA Product release assessment and release description
G Deployment
GA Inception phase deployment planning
GB Elaboration phase deployment planning
GC Construction phase deployment
GCA User manual baselining
GD Transition phase deployment
GDA Product transition to user
CBA Vision base lining Figure 1-3 Evolution of planning fidelity in the WBS over the life cycle
Inception Elaboration
WBS Element Fidelity WBS Element Fidelity

Management High Management High
Environment Moderate Environment High
Requirement High Requirement High
Design Moderate Design High
Implementation Low Implementation Moderate
Assessment Low Assessment Moderate
Deployment Low Deployment Low
WBS Element Fidelity WBS Element Fidelity

Management High Management High
Environment High Environment High
Requirements Low Requirements Low
Design Low Design Moderate
Implementation Moderate Implementation High
Assessment High Assessment High
Deployment High Deployment Moderate
Transition Construction
2) PLANNING GUIDELINES :-
Software projects span a broad range of application domains. It
is valuable but risky to make specific planning recommendations independent of project
context. Project-independent planning advice is also risky. There is the risk that the guidelines
may pe adopted blindly without being adapted to specific project circumstances. Two simple
planning guidelines should be considered when a project plan is being initiated or assessed.
The first guideline, detailed in Table 1-1, prescribes a default allocation of costs among the
first-level WBS elements. The second guideline, detailed in Table 1-2, prescribes the allocation
of effort and schedule across the lifecycle phases.
1-1 Web budgeting defaults
First Level WBS Element Default Budget
Management 10%
Environment 10%
Requirement 10%
Design 15%
Implementation 25%
Assessment 25%
Deployment 5%
Total 100%
Table 10-2 Default distributions of effort and schedule by phase
Domain Inception Elaboration Construction Transition
Effort 5% 20% 65% 10%
Schedule 10% 30% 50% 10%

3) THE COST AND SCHEDULE ESTIMATING PROCESS
Project plans need to be derived from
two perspectives.
a) forward-looking, top-down approach:-
It starts with an understanding of the general
requirements and constraints, derives a macro-level budget and schedule, and then
decomposes these elements into lower level budgets and intermediate milestones. From this
perspective, the following planning sequence would occur:
1. The software project manager (and others) develops a characterization of the overall
size, process, environment, people, and quality required for the project.
2. A macro-level estimate of the total effort and schedule is developed using a software
cost estimation model.
3. The software project manager partitions the estimate for the effort into a top-level
WBS using guidelines such as those in Table 10-1.
4. At this point, subproject managers are given the responsibility for decomposing each
of the WBS elements into lower levels using their top-level allocation, staffing profile,
and major milestone dates as constraints.
b) backward-looking, bottom-up approach:-
We start with the end in mind, analyze the
micro-level budgets and schedules, then sum all these elements into the higher level
budgets and intermediate milestones. This approach tends to define and populate the
WBS from the lowest levels upward. From this perspective, the following planning
sequence would occur:
1. The lowest level WBS elements are elaborated into detailed tasks
2. Estimates are combined and integrated into higher level budgets and milestones.
3. Comparisons are made with the top-down budgets and schedule milestones.
These two planning approaches should be used together, in balance, throughout the life
cycle of the project.
 During the engineering stage, the top-down perspective will dominate because there is
usually not enough depth of understanding nor stability in the detailed task sequences to
perform credible bottom-up planning.
 During the production stage, there should be enough precedent experience and planning
fidelity that the bottom-up planning perspective will dominate.
 Top-down approach should be well tuned to the project-specific parameters, so it should
be used more as a global assessment technique
Figure 1-4 Planning balance throughout the life cycle
Engineering stage planning emphasis Production stage planning emphasis

Macro level task estimation for Micro level task estimation for production
production stage artifacts stage artifacts
Micro level task estimation for Macro level task estimation for
engineering artifacts maintenance of engineering artifacts
Stakeholder concurrence Stakeholder concurrence
Coarse grained variance analysis of actual Fine grained variance analysis of actual vs
vs planned expenditures planned expenditures
Tuning the top down project independent

planning guidelines into project specific
planning guidelines
WBS definition and elaboration
4) THE ITERATION PLANNING PROCESS :-

Planning is concerned with defining the actual
sequence of intermediate results. An evolutionary build plan is important because there are
always adjustments in build content and schedule as early conjecture evolves into well-
understood project circumstances. Iteration is used to mean a complete synchronization
across the project, with a well-orchestrated global assessment of the entire project baseline.
 Inception iterations. The early prototyping activities integrate the foundation
components of a candidate architecture and provide an executable framework for
elaborating the critical use cases of the system. This framework includes existing
components, commercial components, and custom prototypes sufficient to
demonstrate a candidate architecture and sufficient requirements understanding to
establish a credible business case, vision, and software development plan.
 Elaboration iterations. These iterations result in architecture, including a complete
framework and infrastructure for execution. Upon completion of the architecture
iteration, a few critical use cases should be demonstrable: (1) initializing the architecture,
(2) injecting a scenario to drive the worst-case data processing flow through the system
(for example, the peak transaction throughput or peak load scenario), and (3) injecting a
scenario to drive the worst-case control flow through the system (for example,
orchestrating the fault-tolerance use cases).
 Construction iterations. Most projects require at least two major construction iterations:
an alpha release and a beta release.
 Transition iterations. Most projects use a single iteration to transition a beta release into
the final product.
The general guideline is that most projects will use between four and nine iterations. The
typical project would have the following six-iteration profile:
 One iteration in inception: an architecture prototype
 Two iterations in elaboration: architecture prototype and architecture baseline
 Two iterations in construction: alpha and beta releases
 One iteration in transition: product release
A very large or unprecedented project with many stakeholders may require additional
inception iteration and two additional iterations in construction, for a total of nine iterations.
5) PRAGMATIC PLANNING:-
Even though good planning is more dynamic in an iterative process, doing it accurately is
far easier. While executing iteration N of any phase, the software project manager must be
monitoring and controlling against a plan that was initiated in iteration N - 1 and must be
planning iteration N + 1. The art of good project· management is to make trade-offs in the
current iteration plan and the next iteration plan based on objective results in the current
iteration and previous iterations. Aside from bad architectures and misunderstood
requirements, inadequate planning (and subsequent bad management) is one of the most
common reasons for project failures. Conversely, the success of every successful project can
be attributed in part to good planning.
A project's plan is a definition of how the project requirements will be transformed into'
a product within the business constraints. It must be realistic, it must be current, it must be a
team product, it must be understood by the stakeholders, and it must be used. Plans are not
just for managers. The more open and visible the planning process and results, the more
ownership there is among the team members who need to execute it. Bad, closely held plans
cause attrition. Good, open plans can shape cultures and encourage teamwork.
UNIT-IV
UNIT- IV
Project Organizations and Responsibilities: Line-of-Business Organizations, Project
Organizations,evolution of Organizations.
Process Automation: Automation Building blocks, The Project Environment.
Project Control and Process instrumentation: The seven core Metrics, Management
indicators, quality indicators, life cycle expectations, pragmatic Software Metrics, Metrics
automation
Project Organizations and Responsibilities
 Organizations occupied in software Line-of-Business need to support projects with the infrastructure
necessary to use a common process.
 Project organizations need to allocate artifacts & responsibilities across project team to ensure a
balance of global (architecture) & local (component) concerns.
 The organization must evolve with the WBS & Life cycle concerns.
 Software lines of business & product teams have different motivation.
 Software lines of business are motivated by return of investment (ROI), new business identifier,
market change & profitability.
 Project teams are motivated by the cost, Schedule&quality of specific deliverables
1) Line-Of-Business Organizations:-
The main features of default organization are as follows.
 Responsibility for process definition & maintenance is specific to a symmetric line of business.
 Responsibility for process automation is an organizational role & is equal in importance to the
process definition role.
 Organizational role may be fulfilled by a single individual or several different teams.
Software Engineering Process Authority (SEPA):-
 Responsible for exchanging the information and project guidance to or from the project
practitioners.
 Maintain current assessment of organization process maturity.
 Help in initiate and periodically estimate project processes.
 Responsible for process definition and maintainence.
Project Review Authority (PRA):

 Responsible for reviewing the financial performance, customer commitments, risks &
accomplishments, adherence to organizational policies by customer etc.
 Reviews both project’s conformance, customer commitments as well as organizational polices,
deliverables, financial performances and other risks.
Software Engineering Environment Authority (SEEA):

 SEEA deals with the maintenance or organizations standard environment, training projects and
process automation.
 Maintains organization standard environment.
 Training projects to use environment.
 Maintain organization wide resources support . 
Infrastructure:
 An organization infrastructure provides human resources support, project-independent
research and development other capital software engineering assets.
The typical components of the organizational infrastructure are as follows:
 Project Administration:- Time accounting system, contracts, pricing, terms and conditions
corporate information systems integration.
 Engineering Skill Centers:- Custom tools repository and maintenance, bid and proposal
support, independent research and development.
 Professional Development:- Internal training boot camp, personnel recruiting, personnel skills
database maintenance, literature and assets library, technical publications.
2) Project organizations:-
The default project organization and maps project-level roles and
responsibilities. This structure can be tailored to the size and circumstance of the specific project
organization.
The main feature of the default organization is as follows:
 The project management team is an active participant, responsible for producing as well as
managing. Project management is not a spectator sport.
 The architecture team is responsible for real artifacts and for the integration of components,
not just for staff functions.
 The development team owns the component construction and maintenance activities.
 Quality is every one job. Each team takes responsibility for a different quality perspective.
Management Team:-
This is active participant in an organization and is in charge of producing as well
as managing. As the software attributes, such as Schedules, costs, functionality and quality are
interrelated to each other, negotiation among multiple stakeholders is required and these are carried
out by the software management team.
Responsibilities:
 Effort planning
 Conducting the plan
 Adapting the plan according to the changes in requirements and design
 Resource management
 Stakeholders satisfaction
 Risk management
 Assignment or personnel
 Project controls and scope definition
 Quality assurance
Software Architecture Team:
 The software architecture team performs the tasks of integrating the components, creating
real artifacts etc.
 It promotes team communications and implements the applications with a system-wide
quality.
 The success of the development team is depends on the effectiveness of the architecture team
along with the software management team controls the inception and elaboration phases of a life-
cycle.
The architecture team must have:
 Domain experience to generate an acceptable design and use-case view.
 Software technology experience to generate an acceptable process view, component and
development views.
Responsibilities:
 System-level quality i.e., performance, reliability and maintainability.
 Requirements and design trade-offs.
 Component selection
 Technical risk solution
 Initial integration
Software Development Team:
The Development team is involved in the construction and maintenance
activities. It is most application specific team. It consists of several sub teams assigned to the groups
of components requiring a common skill set. The skill set include the following:
Commercial component: specialists with detailed knowledge of commercial components central to a
system's architecture.
Database: specialists with experience in the organization, storage, and retrieval of data.
Graphical user interfaces: specialists with experience in the display organization; data presentation,
and user interaction.
Operating systems and networking: specialists with experience in various control issues arises due to
synchronization, resource sharing, reconfiguration, inter object communications, name space
management etc.
Domain applications: Specialists with experience in the algorithms, application processing, or
business rules specific to the system.
Responsibilities:
 The exposure of the quality issues that affect the customer‟s expectations.
 Metric analysis.
 Verifying the requirements.
 Independent testing.
 Configuration control and user development.
 Building project infrastructure.
Software Assessment Team:
 This team is involved in testing and product activities in parallel with the ongoing development.
 It is an independent team for utilizing the concurrency of activities.
 The use-case oriented and capability-based testing of a process is done by using two artifacts:
 Release specification ( the plan and evaluation criteria for a release)
 Release description (the results of a release)
Responsibilities:
 The exposure of the quality issues that affect the customer‟s expectations.
 Metric analysis.
 Verifying the requirements.
 Independent testing.
 Configuration control and user development.
 Building project infrastructure.
EVOLUTION OF ORGANIZATIONS:-
The project organization represents the architecture of the team

and needs to evolve consistent with the project plan captured in the work breakdown structure. A
different set of activities is emphasized in each phase, as follows:
 Inception team: An organization focused on planning, with enough support from the other
teams to ensure that the plans represent a consensus of all perspectives.
 Elaboration team: An architecture-focused organization in which the driving forces of the
project reside in the software architecture team and are supported, by the software
development and software assessment teams as necessary to achieve a stable architecture
baseline.
 Construction team: A fairly balanced organization in which most of the activity resides in the
software development and software assessment teams.
 Transition team: A customer-focused organization in which usage feedback drives the
deployment activities
The Process Automation:
The environment must be the first-class artifact of the process.

 Process automation& change management is critical to an iterative process. If the change is
expensive then the development organization will resist it.
 Round-trip engineering& integrated environments promote change freedom & effective
evolution of technical artifacts.
 Metric automation is crucial to effective project control.
 External stakeholders need access to environment resources to improve interaction with the
development team & add value to the process.
The three levels of process which requires a certain degree of process automation
for the corresponding process to be carried out efficiently.
Metaprocess (Line of business): The automation support for this level is called an infrastructure.
Macroproces (project): The automation support for a project’s process is called an environment.
Microprocess (iteration): The automation support for generating artifacts is generally called a tool.
Management: Software cost estimation tools and WBS tools are useful for generating the planning
artifacts. For managing against a plan, workflow management tools and a software project control
panel that can maintain an on-line version of the status assessment are advantageous.
Environment: Configuration management and version control are essential in a modern iterative
development process. (change management automation that must be supported by the environment.
Requirements: Conventional approaches decomposed system requirements into subsystem
requirements, subsystem requirements into component requirements, and component requirements
into unit requirements.
The ramifications of this approach on the environment‟s support for requirements management are
twofold:
1. The recommended requirements approach is dependent on both textual and model-based
representations
2. Traceability between requirements and other artifacts needs to be automated.
Design: The primary support required for the design workflow is visual modeling, which is used for
capturing design models, presenting them in human-readable format, and translating them into
source code. Architecture-first and demonstration-based process is enabled by existing architecture
components and middleware.
Implementation: The implementation workflow relies primarily on a programming environment
(editor, compiler, debugger, and linker, run time) but must also include substantial integration with
the change management tools, visual modeling tools, and test automation tools to support
productive iteration.
Assessment and Deployment: To increase change freedom, testing and document production must
be mostly automated. Defect tracking is another important tool that supports assessment: It provides
the change management instrumentation necessary to automate metrics and control release
baselines. It is also needed to support the deployment workflow throughout the life cycle.
THE PROJECT ENVIRONMENT

The project environment artifacts evolve through three discrete states:
1. The proto typing environment includes an architecture tested for prototyping project architectures
to evaluate trade- offs during the inception and elaboration phases of the life cycle. It should be
capable of supporting the following activities:
 Technical risk analyses
 Feasibility studies for commercial products
 Fault tolerance/dynamic reconfiguration trade-offs
 Analysis of the risks associated implementation
 Development of test scenarios, tools, and instrumentation suitable for analyzing the
requirements.
2. The development environment should include a full suite of development tools needed to support
the various process workflows and to support round-trip engineering to the maximum extent
possible.
3. The maintenance environment may be a subset of the development environment delivered as one
of the project's end products.
There are four important environment disciplines that are critical to management context &
the success of a modern iterative development process.
 Round-Trip engineering  Infrastructure

 Change Management  Organization Policy
 Software Change Orders (SCO)  Organization Environment
 Configuration baseline Configuration  Stakeholder Environment.
Control Board
 Round-Trip engineering:-
Round-trip engineering is the environment support necessary to maintain consistency among
the engineering artifacts.
The primary reason for round-trip engineering is to allow freedom in changing software
engineering data sources.
 Change Management
 Change management is as critical to iterative processes as planning.
 Tracking changes in the technical artifacts is crucial to understanding the true technical
progress trends and quality trends toward delivering an acceptable end product or interim release.
 In a modern process-in which requirements, design, and implementation set artifacts are
captured in rigorous notations early in the life cycle and are evolved through multiple generations-
change management has become fundamental to all phases and almost all activities.
 Software Change Orders (SCO)

• The atomic unit of software work that is authorized to create, modify, or obsolesce components
within a configuration baseline is called a software change order (SCO).
• Software change orders are a key mechanism for partitioning, allocating, and scheduling software
work against an established software baseline and for assessing progress and quality.
The basic fields of the SCO are title, description, metrics, resolution, assessment and disposition.
a) Title. The title is suggested by the originator and is finalized upon acceptance by the configuration
control board.
b) Description: The problem description includes the name of the originator, date of origination, CCB-
assigned SCO identifier, and relevant version identifiers of related support software.
c) Metrics: The metrics collected for each sea are important for planning, for scheduling, and for
assessing quality improvement. Change categories are type 0 (critical bug), type 1 (bug), type 2
(enhancement), type 3 (new feature), and type 4 (other)
d) Resolution: This field includes the name of the person responsible for implementing the change,
the components changed, the actual metrics, and a description of the change.
e) Assessment: This field describes the assessment technique as either inspection, analysis,
demonstration, or test. Where applicable, it should also reference all existing test cases and new test
cases executed, and it should identify all different test configurations, such as platforms, topologies,
and compilers.
f) Disposition: The SCO is assigned one of the following states by the CCB:
 Proposed: written, pending CCB review

 Accepted: CCB-approved for resolution
 Rejected: closed, with rationale, such as not a problem, duplicate, obsolete change, resolved By
another SCO
Archived: accepted but postponed until a later release
 In progress: assigned and actively being resolved by the development organization
 In assessment: resolved by the development organization; being assessed by a test organization
 Closed: completely resolved, with the concurrence of all CCB members.
 Configuration Baseline
A configuration baseline is a named collection of software components and supporting
documentation that is subject to change management and is upgraded, maintained, tested, statused
and obsolesced as a unit.
There are general1y two classes of baselines:
1. external product releases and
2. internal testing releases.
A configuration baseline is a named collection of components that is treated as a unit. It is controlled

formally because it is a packaged exchange between groups. A project may release a configuration
baseline to the user community for beta testing. Once software is placed in a controlled baseline, all
changes are tracked. A distinction must be made for the cause of a change. Change categories are as
follows:
– Type 0: Critical failures, which are defects that are nearly always fixed before any external release.
– Type 1: A bug or defect that either does not impair the usefulness of the system or can be worked
around.
– Type 2: A change that is an enhancement rather than a response to a defect.
– Type 3: A change that is necessitated by an update to the requirements.
– Type 4: changes that are not accommodated by the other categories.
 Configuration Control Board (CCB)

A CCB is a team of people that functions as the decision authority on the content of
configuration baselines.
A CCB usually includes the software manager, software architecture manager, software
development manager, software assessment manager and other stakeholders (customer, software
project manager, systems engineer, user) who are integral to the maintenance of a controlled
software delivery system.
The [bracketed] words constitute the state of an SCO transitioning through the process.
[Proposed]: A proposed change is drafted and submitted to the CCB. The proposed change must
include a technical description of the problem and an estimate of the resolution effort.
[Accepted, archived or rejected]: The CCB assigns a unique identifier and accepts, archives, or rejects
each proposed change. Acceptance includes the change for resolution in the next release; archiving
accepts the change but postpones it for resolution in a future release; and rejection judges the
change to be without merit, redundant with other proposed changes, or out of scope.
[In progress]: the responsible person analyzes, implements and tests a solution to satisfy the SCQ.
This task includes updating documentation, release notes and SCO metrics actuals and submitting
new SCOs.
[In assessment]: The independent test assesses whether the SCO is completely resolved. When the
independent test team deems the change to be satisfactorily resolved, the SCO is submitted to the
CCB for final disposition and closure.
[Closed]: when the development organization, independent test organization and CCB concur that
the SCO is resolved, it is transitioned to a closed status. „
 Infrastructures:-
Organization‟s infrastructure provides the organization capital assets, including two key
artifacts:
a) a policy that captures the standards for project software development processes, and
b) an environment that captures an inventory of tools.
Organization Policy
The organization policy is usually packaged as a handbook that defines the life cycle and the
process primitives (major milestones, intermediate artifacts, engineering repositories, metrics, roles
and responsibilities). The handbook provides a general framework for answering the following
questions:
– What gets done? (activities and artifacts)
– When does it get done? (mapping to the life-cycle phases and milestones)
– Who does it? (team roles and responsibilities)
• How do we know that it is adequate? (Checkpoints, metrics and standards of performance).
 Organization Environment
Some of the typical components of an organization‟s automation building blocks are as follows:
• Standardized tool selections, which promote common workflows and a higher ROI on training.
• Standard notations for artifacts, such as UML for all design models, or Ada 95 for all custom-
developed, reliability-critical implementation artifacts.
• Tool adjuncts such as existing artifact templates (architecture description, evaluation criteria,
release descriptions, status assessment) or customizations.
• Activity templates (iteration planning, major milestone activities, configuration control boards).
 Stakeholder Environments
• An on-line environment accessible by the external stakeholders allows them to participate in the
process as follows:
– Accept and use executable increments for hands-on evaluation.
– Use the same on-line tools, data and reports that the software development organization uses to
manage and monitor the project.
– Avoid excessive travel, paper interchange delays, format translations, paper and shipping costs and
other overhead costs.
• There are several important reasons for extending development environment resources into certain
stakeholder domains.
– Technical artifacts are not just paper.
– Reviews and inspections, breakage/rework assessments, metrics analyses and even beta testing can
be performed independently of the development team.
– Even paper documents should be delivered electronically to reduce production costs and turn
around time.
Project Control and Process Instrumention: Seven Core Metrics, Management Indicators, Quality Indicators, Life
Cycle Expectations Pragmatic Software Metrics, Metrics Automation. Tailoring the process: Process Discriminates.
The primary themes of a modern software development process tackle the central management issues of complex
software:
• Getting the design right by focusing on the architecture first
• Managing risk through iterative development
• Reducing the complexity with component based techniques
• Making software progress and quality tangible through instrumented change management
• Automating the overhead and bookkeeping activities through the use of round-trip engineering and integrated
environments
The goals of software metrics are to provide the development team and the management team with the following:
• An accurate assessment of progress to date
• Insight into the quality of the evolving software product
• A basis for estimating the cost and schedule for completing the product with increasing accuracy over time.
THE SEVEN CORE METRICS
Seven core metrics are used in all software projects. Three are management indicators and four are quality indicators.
a) Management Indicators
 Work and progress (work performed over time)
 Budgeted cost and expenditures (cost incurred over time)
 Staffing and team dynamics (personnel changes over time)
b) Quality Indicators
 Change traffic and stability (change traffic over time)
 Breakage and modularity (average breakage per change over time)
 Rework and adaptability (average rework per change overtime)
 Mean time between failures (MTBF) and maturity (defect rate over time)
57
The seven core metrics are based on common sense and field experience with both successful and unsuccessful metrics
programs. Their attributes include the following:
 They are simple, objective, easy to collect, easy to interpret and hard to misinterpret.
 Collection can be automated and non intrusive.
 They provide for consistent assessment throughout the life cycle and are derived from the evolving product
baselines rather than from a subjective assessment.
 They are useful to both management and engineering personnel for communicating progress and quality in a
consistent format.
 They improve fidelity across the life cycle.
MANAGEMENT INDICATORS
There are three fundamental sets of management metrics; technical progress, financial status staffing progress. By
examining these perspectives, management can generally assess whether a project is on budget and on schedule. The
management indicators recommended here include standard financial status based on an earned value system, objective
technical progress metrics tailored to the primary measurement criteria for each major team of the organization and staff
metrics that provide insight into team dynamics.
Work & Progress

The various activities of an iterative development project can be measured by defining a planned estimate of the work in
an objective measure, then tracking progress (work completed over time) against that plan ), the default perspectives of
this metric would be as follows:
 Software architecture team: use cases demonstrated
 Software development team: SLOC under baseline change management, SCOs closed.
 Software assessment team: SCOs opened, test hours executed, evaluation criteria met
 Software management team: milestones completed
Budgeted Cost and Expenditures

To maintain management control, measuring cost expenditures over the project life cycle is always necessary. One
common approach to financial performance measurement is use of an earned value system, which provides highly
detailed cost and schedule insight.
Modern software processes are amenable to financial performance measurement through an earned value approach. The
basic parameters of an earned value system, usually expressed in units of dollars, are as follows:
 Expenditure Plan: the planned spending profile· for a project over its planned schedule. For most software
projects (and other labor-intensive projects), this profile generally tracks the staffing profile.
 Actual Progress: the technical accomplishment relative to the planned progress underlying the spending
profile. In a healthy project, the actual progress tracks planned progress closely.
 Actual Cost: the actual spending profile for a project over its actual schedule. In a healthy project, this profile
tracks the planned profile closely.
 Earned Value: the value that represents the planned cost of the actual progress.
 Cost variance: the difference between the actual cost and the earned value.
 Positive values correspond to over - budget situations; negative values correspond to under budget situations.
 Schedule Variance: the difference between the planned cost and the earned value. Positive values correspond
to behind-schedule situations; negative values correspond to ahead-of-schedule situations.
58
Staffing and Team Dynamics
An iterative development should start with a small team until the risks in the requirements and architecture have been
suitably resolved. Depending on the overlap of iterations and other project specific circumstance, staffing can vary. For
discrete, one of-a-kind development efforts (such as building a corporate information system), the staffing profile would
be typical.
It is reasonable to expect the maintenance team to be smaller than the development team for these sorts of
developments. For a commercial product development, the sizes of the maintenance and development teams may be the
same.
QUALITY INDICATORS
The four quality indicators are based primarily on the measurement of software change across evolving baselines of
engineering data (such as design models and source code).
Change Traffic and Stability
Overall change traffic is one specific indicator of progress and quality.

Change traffic is defined as the number of software change orders opened and closed over the life cycle This metric can
be collected by change type, by release, across all releases, by team, by components, by subsystem, and so forth.
Stability is defined as the relationship between opened versus closed SCOs.
59
Breakage and Modularity
Breakage is defined as the average extent of change, which is the amount of software baseline that needs rework (in
SLOC, function points, components, subsystems, files, etc).
Modularity is the average breakage trend over time. For a healthy project, the trend expectation is decreasing or stable
Rework and Adaptability

Rework is defined as the average cost of change, which is the effort to analyze, resolve and retest all changes to
software baselines.
Adaptability is defined as the rework trend over time. For a health project, the trend expectation is decreasing or stable.
MTBF and Maturity

MTBF is the average usage time between software faults. In rough terms, MTBF is computed by dividing the test hours
by the number of type 0 and type 1 SCOs. MTBF stands for Mean- Time- Between –Failures.
Maturity is defined as the MTBF trend over time
60
LIFE CYCLE EXPECTATIONS
There is no mathematical or formal derivation for using the seven core metrics. However, there were specific reasons for
selecting them:
 The quality indicators are derived form the evolving product rather than from the artifacts.
 They provide insight into the waster generated by the process. Scrap and rework metrics are a standard
measurement perspective of most manufacturing processes.
 They recognize the inherently dynamic nature of an iterative development process. Rather than focus on the
value, they explicitly concentrate on the trends or changes with respect to time.
 The combination of insight from the current value and the current trend provides tangible indicators for
management action.
PRAGMATIC SOFTWARE METRICS
Measuring is useful, but it doesn‟t do any thinking for the decision makers. It only provides data to help them ask the
right questions, understand the context, and make objective decisions.
The basic characteristics of a good metric are as follows:
1. It is considered meaningful by the customer, manager and performer. Customers come to software engineering
providers because the providers are more expert than they are at developing and managing software. Customers will
accept metrics that are demonstrated to be meaningful to the developer.
2. It demonstrates quantifiable correlation between process perturbations and business performance. The only real
organizational goals and objectives are financial: cost reduction, revenue increase and margin increase.
3. It is objective and unambiguously defined: Objectivity should translate into some form of numeric representation
(such as numbers, percentages, ratios) as opposed to textual representations (such as excellent, good, fair, poor).
Ambiguity is minimized through well understood units of measurement (such as staff-month, SLOC, change,
function point, class, scenario, requirement), which are surprisingly hard to define precisely in the software
engineering world.
4. It displays trends: This is an important characteristic. Understanding the change in a metric‟s value with respect to
time, subsequent projects, subsequent releases, and so forth is an extremely important perspective, especially for
today‟s iterative development models. It is very rare that a given metric drives the appropriate action directly.
5. It is a natural by-product of the process: The metric does not introduce new artifacts or overhead activities; it is
derived directly from the mainstream engineering and management workflows.
61
6. It is supported by automation: Experience has demonstrated that the most successful metrics are those that are
collected and reported by automated tools, in part because software tools require rigorous definitions of the data
they process.
METRICS AUTOMATION
There are many opportunities to automate the project control activities of a software project. For managing against a
plan, a software project control panel (SPCP) that maintains an on-line version of the status of evolving artifacts
provides a key advantage.
To implement a complete SPCP, it is necessary to define and develop the following:
 Metrics primitives: indicators, trends, comparisons, and progressions.
 A graphical user interface: GUI support for a software project manager role and flexibility to support other roles
 Metric collection agents: data extraction from the environment tools that maintain the engineering notations .for the
various artifact sets.
 Metrics data management server: data management support for populating the metric displays of the GUI and
storing the data extracted by the agents.
 Metrics definitions: actual metrics presentations for requirements progress (extracted from requirements set
artifacts), design progress (extracted from design set artifacts), implementation progress (extracted from
implementation set artifacts), assessment progress (extracted from deployment set artifacts), and other progress
dimensions (extracted from manual sources, financial management systems, management artifacts, etc.)
 Actors: typically, the monitor and the administrator
Specific monitors (called roles) include software project managers, software development team leads, software
architects, and customers.
 Monitor: defines panel layouts from existing mechanisms, graphical objects, and linkages to project data; queries
data to be displayed at different levels of abstraction
 Administrator: installs the system; defines new mechanisms, graphical objects, and linkages; archiving functions;
defines composition and decomposition structures for displaying multiple levels of abstraction.
62
In this case, the software project manager role has defined a top-level display with four graphical objects.
1. Project activity Status: the graphical object in the upper left provides an overview of the status of the top-level
WBS elements. The seven elements could be coded red, yellow and green to reflect the current earned value status.
(In Figure they are coded with white and shades of gray). For example, green would represent ahead of plan,
yellow would indicate within 10% of plan, and red would identify elements that have a greater than 10% cost or
schedule variance. This graphical object provides several examples of indicators: tertiary colors, the actual
percentage, and the current first derivative (up arrow means getting better, down arrow means getting worse).
2. Technical artifact status: the graphical object in the upper right provides an overview of the status of the evolving
technical artifacts. The Req light would display an assessment of the current state of the use case models and
requirements specifications. The Des light would do the same for the design models, the Imp light for the source
code baseline and the Dep light for the test program.
3. Milestone progress: the graphical object in the lower left provides a progress assessment of the achievement of
milestones against plan and provides indicators of the current values.
4. Action item progress: the graphical object in the lower right provides a different perspective of progress, showing
the current number of open and close issues.
63
The following top-level use case, which describes the basic operational concept of an SPCP, corresponds to a monitor
interacting with the control panel:
 Start the SPCP. The SPCP starts and shows the most current information that was saved when the user last used
the SPCP.
 Select a panel preference. The user selects from a list of previously defined default panel preference. The SPCP
displays the preference selected.
 Select a value or graph metric. The user selects whether the metric should be displayed for a given point in time or
in a graph, as a trend. The default for trends is monthly.
 Select to superimpose controls. The user points to a graphical object and requests that the control values for that
metric and point in time be displayed.
 Drill down to trend. The user points to a graphical object displaying a point in time and drills down to view the
trend for the metric.
 Drill down to point in time. The user points to a graphical object displaying a trend and drills down to view the
values for the metric.
 Drill down to lower levels of information. The user points to a graphical object displaying a point in time and
drills down to view the next level of information.
 Drill down to lower level of indicators. The user points to a graphical object displaying an indicator and drills
down to view the breakdown of the next level of indicators.
PROCESS DISCRIMINATES
In tailoring the management process to a specific domain or project, there are tow dimensions of discriminating factors:
technical complexity and management complexity.
The Figure illustrates discriminating these tow dimensions of process variability and shows some example project
applications. The formality of reviews, the quality control of artifacts, the priorities f concerns and numerous other
process instantiation parameters are governed by the point a project occupies in these two dimensions.
64
Figure summarizes the different priorities along the two dimensions.
Scale
 There are many ways to measure scale, including number of source lines of code, number of function points,
number of use cases, and number of dollars. From a process tailoring perspective, the primary measure of scale
is the size of the team. As the headcount increases, the importance of consistent interpersonal communications
becomes paramount. Otherwise, the diseconomies of scale can have a serious impact on achievement of the
project objectives.
 A team of 1 (trivial), a team of 5 (small), a team of 25 (moderate), a team of 125 (large), a team of 625 (huge),
and so on. As team size grows, a new level of personnel management ins introduced at roughly each factor of 5.
This model can be sued to describe some of the process differences among projects of different sizes.
 Trivial-sized projects require almost no management overhead (planning, communication, coordination,
progress assessment, review, administration).
 Small projects (5 people) require very little management overhead, but team leadership toward a common
objective is crucial. There is some need to communicate the intermediate artifacts among team member.
 Moderate-sized projects (25 people) require moderate management overhead, including a dedicated software
project manager to synchronize team workflows and balance resources.
 Large projects (125 people) require substantial management overhead including a dedicated software project
manager and several subproject managers to synchronize project-level and subproject-level workflows and to
balance resources.Project performance is dependent on average people, for two reasons:
65
a) There are numerous mundane jobs in any large project, especially in the overhead workflows.
b) The probability of recruiting, maintaining and retaining a large umber of exceptional people is small.
 Huge projects (625 people) require substantial management overhead, including multiple software project
managers an many subproject managers to synchronize project-level and subproject-level workflows and to
balance resources.
Stakeholder Cohesion or Contention

The degree of cooperation and coordination among stakeholders (buyers, developers, users, subcontractors and
maintainers, among others) can significantly drive the specifies of how a process is defined. This process parameter can
range from cohesive to adversarial. Cohesive teams have common goals, complementary skills and close
communications. Adversarial teams have conflicting goals, completing or incomplete skills and less-than-open
communications.
Process Flexibility or Rigor

The degree of rigor, formality and change freedom inherent in a specific project‟s “contract” (vision document, business
case and development plan) will have a substantial impact on the implementation of the project‟s process. For very
loose contracts such as building a commercial product within a business unit of a software company (such as a
Microsoft application or a rational software corporation development tool), management complexity is minimal. In these
66
sorts of development processes, feature set, time to market, budget and quality can all be freely traded off and changed
with very little overhead.
Process Maturity
The process maturity level of the development organization, as defined by the software engineering Institute‟s capability
maturity model is another key driver of management complexity. Managing a mature process (level 3 or higher) is far
simpler than managing an immature process (level 1 and 2). Organizations with a mature process typically have a high
level of precedent experience in developing software and a high level of existing process collateral that enables
predictable planning and execution of the process. Tailoring a mature organization‟s process for a specific project is
generally a straight forward task.
Architectural Risk
The degree of technical feasibility demonstrated before commitment to full-scale production is an important dimension
of defining a specific project‟s process. There are many sources of architectural risk. Some of the most important and
recurring sources are system performance (resource utilization, response time, throughput, accuracy), robustness to
change (addition of new features, incorporation of new technology, adaptation to dynamic operational conditions) and
67
system reliability (predictable behavior, fault tolerance). The degree to which these risks can bed eliminated before
construction begins can have dramatic ramifications in the process tailoring.
Domain Experience
The development organization‟s domain experience governs its ability to converge on an acceptable architecture in a
minimum number of iterations. An organization that has built five generations of radar control switches may be able to
converge on adequate baseline architecture for a new radar application in two or three prototype release iterations. A
skilled software organization building its first radar application may require four or five prototype releases before
converging on an adequate baseline.
EXAMPLE: SMALL-SCALE PROJECT VERSUS LARGE-SCALE PROJECT

 An analysis of the differences between the phases, workflows and artifacts of two projects on opposite ends of
the management complexity spectrum shows how different two software project processes can be Table 14-7
illustrates the differences in schedule distribution for large and small project across the life-cycle phases. A
small commercial project (for example, a 50,000 source-line visual basic windows application, built by a team
68
of five) may require only 1 month of inception, 2 months of elaboration, 5 months of construction and 2 months
of transition. A large, complex project (for example, a 300,000 source-line embedded avionics program, built by
a team of 40) could require 8 months of inception, 14 months of elaboration, 20 months of construction, and 8
months of transition. Comparing the ratios of the life cycle spend in each phase highlights the obvious
differences.
 One key aspect of the differences between the two projects is the leverage of the various process components in
the success or failure of the project. This reflects the importance of staffing or the level of associated risk
management.
The following list elaborates some of the key differences in discriminators of success.
 Design is key in both domains. Good design of a commercial product is a key differentiator in the marketplace
and is the foundation for efficient new product releases. Good design of a large, complex project is the
foundation for predictable, cost-efficient construction.
 Management is paramount in large projects, where the consequences of planning errors, resource allocation
errors, inconsistent stakeholder expectations and other out-of-balance factors can have catastrophic
consequences for the overall team dynamics. Management is far less important in a small team, where
opportunities for miscommunications are fewer and their consequences less significant.
 Deployment plays a far greater role for a small commercial product because there is a broad user base of diverse
individuals and environments.
69
UNIT-V
DevOps Architecture:- Unit - V
Development and operations both play essential roles in order to deliver the
applications. The deployment comprises analyzing the requirements, designing,
developing, and testing of the software components or frameworks.
DevOps architecture is used for the applications located on the cloud platform and
large distributed applications. Agile Development is used in the DevOps
architecture so that integration and delivery can be contiguous.
When the development and operations team works separately from each other,
then it is time-consuming to design, test, and deploy. And if the terms are not in
sync with each other, then it may cause a delay in the delivery. So DevOps enables
the teams to change their shortcomings and increases productivity. Below are the
various components that are used in the DevOps architecture:
1) Build:- with DevOps, the usage of cloud, sharing of resources comes into the
picture, and the build is dependent upon the user's need
2) Code:- Git enables the code to be used, which ensures writing the code for
business, helps to track changes, getting notified about the reason behind the
difference in the actual and the expected output, and if necessary reverting to the
original code developed. The code can be appropriately arranged in files, folders,
etc. And they can be reused.
3) Test:- The application will be ready for production after testing. In the case of
manual testing, it consumes more time in testing and moving the code to the
output. The testing can be automated, which decreases the time for testing so
that the time to deploy the code to production can be reduced as automating the
running of the scripts will remove many manual steps.
4) Plan:- DevOps use Agile methodology to plan the development. With the
operations and development team in sync, it helps in organizing the work to plan
accordingly to increase productivity.
5) Monitor:- Continuous monitoring is used to identify any risk of failure. Also, it
helps in tracking the system accurately so that the health of the application can be
checked. The monitoring becomes more comfortable with services where the log
data may get monitored through many third-party tools such as Splunk.[ this tool
is used to searches and indexes log files and helps organizations derive insights
from the data]
6) Deploy:- Many systems can support the scheduler for automated deployment.
The cloud management platform enables users to capture accurate insights and
view the optimization scenario, analytics on trends by the deployment of
dashboards.
7) Operate:- DevOps changes the way traditional approach of developing and
testing separately. The operation team interacts with developers, and they come
up with a monitoring plan which serves the IT and business requirements.
8) Release:- Deployment to an environment can be done by automation. But
when the deployment is made to the production environment, it is done by
manual triggering. Many processes involved in release management commonly
used to do the deployment in the production environment manually to lessen the
impact on the customers.
Orchestration tools
1) Jenkins:-
DevOps are divided into different stages. For

integrating them, you’d need to perform Continous
Integration (CI). Jenkins enables companies to boost
their software development processes. Developers
use Jenkins to test their software projects and add
changes seamlessly.
This tool uses Java with plugins, which help in enhancing Continuous Integration. Jenkins is widely pop
with more 1 million users. So also get access to a thriving and helpful community of developers.
2) Git
It is a version control system, and it lets teams collaborate
on a project at the same time. Developers can track
changes in their files, as well as improve the product
regularly. Git is widely popular among tech companies.
Many companies consider it is a must-have for their tech
professionals.
You can save different versions of your code on Git. You can use GitHub for holding
repositories as well. GitHub allows you to connect Slack with your on-going projects so
your team can easily communicate regarding the project.
3) Bamboo:-
Bamboo is similar to Jenkins as it helps you in automating your delivery
pipeline. The difference is of their prices. Jenkins is free, but Bamboo is not.
4) Kubernetes:-
Kubernetes deserves a place on this
DevOps tools list for obvious reasons. First, it is a
fantastic container orchestration platform. Second, it
has taken the industry by storm.
When you have many containers to take care of,
scaling the tasks becomes immensely challenging.
Kubernetes helps you in solving that problem by
automating the management of your containers.
It is an open-source platform. Kubernetes can let you scale your containers without
increasing your team. As it is an open-source platform, you don’t have to worry about
access problems. You can use public cloud infrastructure or hybrid infrastructure to
your advantage. The tool can also self-heal containers. This means it can restart failed
containers, kills not-responding containers, and replaces containers.
5) Vagrant:-
You can build and manage virtual machine

environments on Vagrant. It lets you do all that in a
single workflow. You can use it on Mac, Windows, as
well as, Linux.
It provides you with an ideal development
environment for better productivity and efficiency. It
can easily integrate with multiple kinds of IDEs and
configuration management tools such as Salt, Chef,
and Ansible.
Because it works on local systems, your team members won’t have to give up their
existing technologies or operating systems. Vagrant’s enhanced development
environments certainly make DevOps easier for your team. That’s why we have kept it
in our DevOps tools list.
6) Splunk:-
Splunk makes machine data more accessible and valuable. It enables your
organization to use the available data in a better fashion. With its help, you can easily
monitor and analyze the available data and act accordingly.
7)Sumologic:-
Sumologic is a popular CI platform for DevSecOps. It enables
organizations to develop and secure their applications on the cloud. It can detect
Indicators of Compromise quickly, which lets you investigate and resolve the threat
faster.
Its real-time analytics platform helps organizations in using data for predictive analysis. For
monitoring and securing your cloud applications, you should choose Sumologic. Because of its
power of the elastic cloud, you can scale it infinitely (in theory).
DevOps Pipeline
A pipeline in software engineering team is a set of automated processes which allows DevOps
professionals and developer to reliably and efficiently compile, build, and deploy their code to
their production compute platforms.The most common components of a pipeline in DevOps are
build automation or continuous integration, test automation, and deployment automation.
A pipeline consists of a set of tools which are classified into the following categories such as:
 Source control
 Build tools
 Containerization
 Configuration management
 Monitoring
Continuous Integration Pipeline
Continuous integration (CI) is a practice in which developers

can check their code into a version-controlled repository several times per day. Automated build
pipelines are triggered by these checks which allows fast and easy to locate error detection.
Some significant benefits of CI are:
 Small changes are easy to integrate into large codebases.

 More comfortable for other team members to see what you have been working.
 Fewer integration issues allowing rapid code delivery.
 Bugs are identified early, making them easier to fix, resulting in less debugging work.
Continuous Delivery Pipeline
Continuous delivery (CD) is the process that allows operation engineers and developers to deliver
bug fixes, features, and configuration change into production reliably, quickly, and sustainably.
Continuous delivery offers the benefits of code delivery pipelines, which are carried out that can
be performed on demand.
Some significant benefits of the CD are:
 Faster bug fixes and features delivery.

 CD allows the team to work on features and bug fixes in small batches, which means user
feedback received much quicker. It reduces the overall time and cost of the project.
DevOps Methodology
We have a demonstrated methodology that takes an approach to cloud adoption. It accounts

for all the factors required for successful approval such as people, process, and technology,
resulting in a focus on the following critical consideration:
o The Teams: Mission or project and cloud management.

o Connectivity: Public, on-premise, and hybrid cloud network access.
o Automation: Infrastructure as code, scripting the orchestration and deployment of
resources.
o On-boarding Process: How the project gets started in the cloud.
o Project Environment: TEST, DEV, PROD (identical deployment, testing, and production).
o Shared Services: Common capabilities provided by the enterprise.
o Naming Conventions: Vital aspect to track resource utilization and billing.
o Defining Standards Role across the Teams: Permissions to access resources by job
function.
Devops eco system

DevOps is a software development methodology that improves the collaboration between
developers and operations teams using various automation tools. These automation tools are
implemented using various stages which are a part of the DevOps Lifecycle.
 Coding – code development and review, source code management tools, code merging
 Building – continuous integration tools (like Jenkins), build status
 Testing – continuous testing tools (like QuerySurge, Selenium, Cucumber, JMeter) that
provide feedback on business risks
 Packaging – artifact repository, application pre-deployment staging
 Releasing – change management, release approvals, release automation
 Configuring – infrastructure configuration and management, infrastructure as
code tools
 Monitoring – applications performance monitoring, end-user experience
1. Continuous Development:
This stage involves committing code to version control tools such as Git or SVN for maintaining
the different versions of the code, and tools like Ant, Maven, Gradle for building/packaging the
code into an executable file that can be forwarded to the QAs for testing.
2. Continuous Integration:
The stage is a critical point in the whole DevOps Lifecycle. It deals with integrating the
different stages of the DevOps lifecycle and is, therefore, the key in automating the whole
DevOps Process.
3. Continuous Deployment:
In this stage the code is built, the environment or the application is containerized and is
pushed onto the desired server. The key processes in this stage are Configuration
Management, Virtualization, and Containerization.
4. Continuous Testing:
The stage deals with automated testing of the application pushed by the developer. If there is
an error, the message is sent back to the integration tool, this tool, in turn, notifies the
developer of the error, If the test was a success, the message is sent to Integration-tool which
pushes the build on the production server.
5. Continuous Monitoring:
The stage continuously monitors the deployed application for bugs or crashes. It can also be
set up to collect user feedback. The collected data is then sent to the developers to improve
the application.
DevOps adoption in projects
Technology aspects
The adoption of technology is an important aspect of many projects, including those related
to DevOps. Some of the key technology aspects to consider when implementing DevOps
practices include:
1. Cloud computing: Cloud computing provides a scalable and flexible infrastructure for
DevOps projects, enabling organizations to quickly provision and manage resources as
needed. It also enables the use of technologies like containers and serverless computing,
which can help to streamline the development and deployment process.
2. Automation tools: DevOps requires the use of automation tools for tasks such as code
builds, testing, and deployment. There are many tools available for DevOps automation,
including Jenkins, GitLab, and Ansible, among others.
3. Containerization: Containers provide a lightweight and portable way to package and
deploy applications. Technologies like Docker and Kubernetes are commonly used in
DevOps projects to enable containerization and orchestration of containers.
4. Infrastructure as code: Infrastructure as code (IaC) is a practice that involves defining
infrastructure using code. This enables DevOps teams to manage infrastructure in a
consistent and repeatable way, and to treat infrastructure as a versioned artifact.
5. Monitoring and observability: DevOps requires continuous monitoring and
observability of applications and infrastructure to detect and resolve issues quickly.
Tools like Prometheus and Grafana can be used for monitoring, while distributed tracing
tools like Jaeger and Zipkin can be used for observability.
6. Security: Security is an important consideration in any DevOps project. Technologies like
security scanning tools, vulnerability management tools, and penetration testing tools
can help to ensure that applications and infrastructure are secure
Agiling capabilities
Agile capabilities refer to an organization's ability to effectively adopt and implement agile
methodologies and practices in their software development process. Agile is a mindset and a
methodology that focuses on delivering value to customers through iterative and incremental
development, with a focus on collaboration, flexibility, and continuous improvement. Agile
capabilities are therefore critical to the success of any DevOps project, as DevOps also relies
on a collaborative and iterative approach to software development. Here are some key
aspects of agile capabilities that organizations need to focus on when adopting DevOps
practices:
1. Agile mindset: The agile mindset is a key aspect of agile capabilities. It involves a
willingness to embrace change, a focus on delivering value to customers, and a
commitment to continuous improvement. The agile mindset is a culture that values
teamwork, collaboration, and open communication. Organizations need to foster an agile
mindset throughout their teams to effectively adopt DevOps practices.
2. Agile methodologies: Agile methodologies like Scrum, Kanban, and XP provide a
framework for agile development. These methodologies help teams to prioritize work, manage
work in progress, and continuously improve the development process. Organizations need
to select the appropriate agile methodology that aligns with their business needs and the
nature of their project.
3.Agile practices
Agile practices like user stories, sprint planning, and retrospectives help teams to
collaborate, communicate, and deliver high-quality software. User stories help to capture
requirements in a customer-centric way, while sprint planning helps to organize work into
manageable chunks. Retrospectives provide an opportunity to reflect on the development
process and make improvements.
4. Agile tools: Agile tools like Jira, Trello, and GitLab can help teams to manage their work and
collaborate effectively. These tools provide a platform for managing work in progress, tracking
progress, and communicating with team members.
5. Continuous delivery: Continuous delivery is an agile practice that involves continuously
integrating and testing code changes, and deploying those changes to production quickly
and frequently. This requires an agile approach to development, where teams work in
small increments and focus on delivering value to customers.
6. Continuous improvement: Continuous improvement is a core tenet of both agile and
DevOps. Teams need to continuously reflect on their work and make improvements to their
processes, tools, and practices. This involves an agile mindset, where teams are willing to
experiment, learn from their mistakes, and make changes to improve the software
delivery process
Tool stack implementation
A tool stack is a collection of software tools that are used together to support a particular
process or workflow. In the context of DevOps, a tool stack is a set of tools that are used to
support the software development and deployment process. Implementing a tool stack is a
critical aspect of DevOps adoption, as it enables teams to automate tasks, streamline
workflows, and improve collaboration. Here are some key considerations when implementing
a DevOps tool stack:
1. Tool selection: The first step in implementing a DevOps tool stack is to select the
appropriate tools. There are many tools available for different aspects of the DevOps
workflow, such as source code management, continuous integration and delivery, testing,
monitoring, and collaboration. It's important to select tools that are compatible with each
other and can integrate seamlessly to support the end-to-end software delivery process.
2. Tool integration: Once the appropriate tools have been selected, they need to be
integrated to create a cohesive tool stack. This involves configuring the tools to work together
and automating the workflow between them. Integration is critical to achieving the benefits
of DevOps, such as faster delivery, higher quality, and improved collaboration.
3. Tool adoption: After the tool stack has been implemented, it's important to encourage
adoption by the development and operations teams. This involves providing training, support,
and documentation to ensure that everyone understands how to use the tools effectively.
Adoption is critical to achieving the benefits of DevOps, as it ensures that the tool stack is used
to its full potential.
4. Tool optimization: Finally, it's important to optimize the tool stack over time. This
involves regularly reviewing the tool stack to identify areas for improvement and making
changes to the tools or processes as necessary. Optimization is critical to ensuring that
the DevOps tool stack continues to support the evolving needs of the development and
operations teams.
The Key Principles of Scrum in Project Management:-
The six principles are: Empirical Process Control, Self-Organization, Time-Boxing, Value-Based
Prioritization, Iterative Development, and Collaboration.
1)Empirical Process Control:-
This principle is the first and most important principle underlying the
“scrum” method, and is actually made up of three sub-principles that should guide you when
implementing it. The three key aspects included in Process Control are:
Transparency – the idea here is that universal visibility of a project, as well as its progress, will
decrease the risk of misunderstandings and mistakes.
Inspection – whatever you’re developing, be it a product or a service, to inspecting it at
different stages of the project cycle. This will ensure that whatever you’re developing remains
closely aligned with your original brief.
Adaption – a good project management methodology will be sensitive to change and scrum
allows team members to make significant changes in between sprints.
2) Self-Organization:-
In the context of scrums, the principle of self-organization is key to
ensuring that team members take responsibility and ownership for the project they’re working
on. The self-organization is that it makes team members care and the bigger a team's
emotional investment, the more likely they are to see success.
This principle also affects assessment – self-organizing teams can be critical of themselves and
the team’s performance without the need for input from leadership.
3) Time-Boxing
Time-boxing is a part of the scrum method in which strict time limits are
enforced in various ways throughout a project. Most of the time, this means running
“sprints” – one to four-week periods of intense focus on a single task or collection of tasks.
Some teams sprint for slightly longer, others for shorter – it really depends on what product or
service you're developing.
But it's not just for sprints – implementing time-boxing wherever you can, including in
meetings, will ensure that your project stays on track for its delivery date.
4) Value-Based Prioritization:-
Prioritizing the completion of the right tasks in the right time
frame is a key part of every working person’s life, whether they’re in the midst of a project or
not.However, teams implementing the scrum method prioritize value overall – specifically, by
trying to create the maximal business value in the shortest amount of time. This is all about
delivering the highest quality product or service as quickly as possible.
5) Iterative Development:-
“Iterative” projects are broken down into smaller chunks, or
iterations, such that one large project becomes a series of smaller subprojects that are easier
to focus on. These are the “sprints” in scrum.
The “development” part of this phrase refers to what teams can learn from each
sprint/iteration, and how those lessons can then be applied to future iterations, creating a
constant cycle of improvement.
6) Collaboration:-
The final core pillar of the scrum approach is collaboration. It’s vital that
all team members working on a project are aware of what others are working on, and have a
close relationship with the project stakeholders, who ultimately need to be satisfied with the
end product.
Collaboration is distinct from other related concepts, like cooperation, in that collaboration
relies on the collective inputs of multiple team members and the mutual development of such
ideas – cooperation simply means working on the same project .
Scrum Process
Scrums have key characteristics that make them what they are – it’s not simply the process of
getting into small teams and performing “sprints.” A typical scrum cycle will include:
Sprint planning – this usually takes place before a project and involves creating a general
strategy for how scrums will function, who will play the role of scrum master, and various
other decisions that have to be made before any work can take place.
The daily scrum – a short, daily meeting that gives scrum masters and project managers the
chance to touch base with team members and make quick adaptions before the workday
commences.
The sprint – a short, one to four-week burst of intense focus on specific tasks within a project,
with the entire team focused on the short-term goal of completing the designated jobs for
that sprint.
The sprint review – a conversation between the scrum team and the project stakeholders
where feedback can be taken and modifications to the product or service can be made.
The sprint retrospective – a “bigger picture” review where changes to the workings or
structure of the scrum can be discussed and debated. Did work run as smoothly as it could
have done? If not, the retrospective is where you can air your concerns.
Key components in Devops life cycle process:-
1) Continuous development:-
The first component of a DevOps lifecycle is continuous development,
during which the team concentrates on planning and programming the software. This
component encourages regular and continuous updates. As a result, the team can deliver code
to customers as soon as they finish writing and testing it. This is possible because, typically,
continuous development simplifies the development process by breaking it down into smaller
development cycles.
2) Continuous integration:-
In software engineering, continuous integration (CI) is the practice that allows
tech organisations to automate the integration of code changes that several contributors
developed. As a result, they can easily create a single software project that's functional and
includes all necessary adjustments. In addition to this, it also enables clients to provide
feedback that contributors can use when they're about to incorporate new features into
applications. In many instances, this is the most intense stage of the DevOps process, as the
most changes can happen throughout its duration.
3) Continuous testing:-
Another key component of DevOps is continuous testing, which is a form of
software testing that contributors and team members perform at every stage of the
development lifecycle. The primary goal for this process is the assessment of the quality of the
software. Typically, development teams do this by identifying any bugs and errors in the code.
A major element of this DevOps stage is quality analysis (QA), which allows the team to test
the software's usability. The QA process also tells them if the software meets the key
specifications and client requirements.
4) Continuous deployment:-
Continuous deployment (CD) is a process that aims to validate if
the contributors implemented the correct changes and if these changes are stable enough for
a software release. Thanks to this component, developers can address any code and software
issues quickly and hassle-free. It also makes their work more accurate, as CD eliminates the
need for scheduling releases. To improve the CD stage, it's important that organisations
maintain high levels of consistency between development, staging and production
environments.
5) Continuous monitoring:-
Continuous monitoring is an operational stage during which developers identify
any grey areas in the software. This phase also gives them enough time and resources to
enhance the overall efficiency of the application. During the monitoring stage, they also
address and eliminate any system errors, ensuring full functionality, availability and security of
the software.
6) Continuous feedback:-
In DevOps, continuous feedback is the process of regularly evaluating
the effects of each software release and creating reports that help the development team
improve their future releases. Effective feedback is almost immediate and entire teams and
departments can receive it at the same time. The way in which an organisation processes
client or expert feedback can impact its corporate image and simply help the development
team improve the way in which they fix code errors and implement adjustments to
applications. Continuous feedback also helps companies improve employee engagement and
productivity.
7) Continuous operations:-
Continuous operations are the last component of the DevOps lifecycle
whose primary goal is to help developers eliminate or at least significantly reduce the need for
planned downtime, including scheduled maintenance. There are various elements that they
can incorporate to make that possible, such as A/B testing and aiming for small and frequent
releases. Thanks to continuous operations, organisations can maintain the same productivity
and efficiency levels, regardless of any events of disruption.
Old Question
Papers
Code No: R203105B R20 SET - 1
!" #$ % ! & '$($) ' (
!"* " !( " #

$$ " ! % $
&&&&&
+(
' () $ $ #* # $$ $ + ,
- $ - #) - # + ,
$ - -
./
0 1$$ # + ,
- $ $ # # ) $ + ,
+(
$ - + ,
# 2# ! $
- * # 34 ! ) $ 3 + ,
./
5 $ $ ) # 1 + ,
$ -
- * ! # $ # + ,
3 $
+(
6 $ # # + ,
)
- * #$ 3 $ $ #$ + ,
./
7 - -8 ) $! + ,
- $
- * $ 3 $ 8 $ + ,
#
+( *
$ $ -$ # # $ $ 9 #9 + ,
- :
- * 3 $ - $ -$ # + ,
./
; 1$$ # 8 ) $ ) $# ! $ + ,
- $ - # " $ ! # + ,
+( *
< * $ $ !3 $ # $ + ,
$ !
- * = ). 3 $ = ). $) ! $ + ,
./
' * /> $3 ? ! $ + ,
- $ $ $ # = ). + ,
' #'
|''|'|''|''|''|||'|| www.manaresults.co.in
Code No: R203105B
R2031011
R2031051
R203105A R20 SET - 2
!" #$ % ! & '$($) ' (
!"* " !( " #

$$ " ! % $
&&&&&
+(
' $ * # $$ $ $ $ # + ,
8
- () # # $ # 8 + ,
./
0 = - # # + ,
$ # $ ) $)
- $ $ # # + ,
+(
) # + ,
# 2# ! $
- * # ) ) $ # + ,
) $ 3
./
5 $ -8 ) $ ) # 1 + ,
$ - @
- () $ # # # $ + ,
#
+(
6 $ # # $ ) + ,
- $ - 1 @$ @ + ,
./
7 * % # ) $ #$ 3 + ,
- $ ! $ $ $# ! $ + ,
+( *
$ $ -$ # # $ $ 9 #9 + ,
- :
- $ - # " $ ! # + ,
./
; $ $ # $ 8 : + ,
-$
- () ) + ,
#
+( *
< * ) # $ $ ! ) $ + ,
$ !3 4 /> $3
- $ $ # = ). + ,
./
' * $ $ !3 $ # $ + ,
$ !
- () # # ) # = ). + ,
!
' #'
Code No: R203105B
R2031011
R2031051
R203105A R20 SET - 3
( , -
!" #$ % ! & '$($) ' (
!"* " !( " #

$$ " ! % $
&&&&&
+(
' $ # $$ $ # # + ,
8
- $ + ,
./
0 = - # # + ,
- $ ) # + ,
+(
$ ) $ #$# ! $ # # + ,
- = - #$# ! $ ) # $ + ,
./
5 $ $ ) # $ - + ,
- () ) ) # + ,
+(
6 A $ # # 8 B + ,
C #!
- $ ! # ) + ,
./
7 * #$ 3 $ $ #$ + ,
- * - 3 4 # + ,
$ 3
+( *
1$$ # 8 ) $ ) $# ! $ + ,
- * / 3 $ + ,
./
; $ -$ # # +'5
$ #- : ,
+( *
< * #) $ # /> 3 $ + ,
- * # ! # = ). 3 $ + ,
./
' * $ $ !3 $ # $ + ,
$ !
- * ## - $ = ). 3() + ,
$ # = ).
' #'
Code No: R2031011
R2031051
R203105A
R203105B R20 SET - 43
!" #$ % ! & '$($) ' (
!"* " !( " #

$$ " ! % $
&&&&&
+(
' () D E A1 $ # ' $ B + ,
- 4 # : 3 $ + ,
./
0 $ #! $ ) $ # - + ,
) #
- = - # ) # + ,
)
+(
$ $ ) # + ,
- () # # $ $ # + ,
./
5 $ ! -8 ) # 1 + ,
$ -
- () # # # $ + ,
+(
6 $ ! # ) + ,
- = - - 1 $ -$ ! $ $ + ,
$ $
./
7 = -$ ! # ) # ) +'5
#$ ,
+( *
= - $ # #$ + ,
- * # + ,
# 8 3 $
./
; 1$$ # 8 ) $ ) $# ! $ + ,
- () ) + ,
#
+( *
< 4 /> ## # $ 3 $ + ,
- 4 $$ ! 8 $ + ,
= ). 3 $
./
' * $ % # = ). + ,
# !3
- # - # # = ). + ,
' #'

SPM 1-5 Unit's Sir Book Final

Uploaded by

Copyright:

Available Formats

SPM 1-5 Unit's Sir Book Final

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

SPM 1-5 Unit's Sir Book Final

Uploaded by

Copyright:

Available Formats

SRI MITTAPALLI COLLEGE OF ENGINEERING :: CC-U9

NH-16, Tummalapalem, Guntur -522233, AP.

Academic Year : 2023-24 Branch: CSE Year/Semester:III/I

Program Educational Objectives (PEOs)

Program Specific Outcomes

Engineering knowledge: Apply the knowledge of mathematics, science, engineering

Apply JavaScript to embed programming interface for web

SRI MITTAPALLI COLLEGE OF ENGINEERING :: CC-U9

Academic Year : 2023-24 Branch:CSE Year/Semester:III/I

SRI MITTAPALLI COLLEGE OF ENGINEERING :: CC-U9

Academic Year : 2022-23 Branch: CSE

Cost and schedule

SRI MITTAPALLI COLLEGE OF ENGINEERING :: CC-U9

Academic Year :2022-23 Branch: CSE

SRI MITTAPALLI COLLEGE OF ENGINEERING :: CC-U9

Academic Year: 2022-23 Branch: CSE

1a) Approach of waterfall model 1M

1b) List of software trends 1M

2a) List 30 principles of conventional software 3M

2b) Functional Diagram 1M

3a) Defination of artifact 1M

3b) Defination & List of software workflows 2M

SRI MITTAPALLI COLLEGE OF ENGINEERING :: CC-U9

Academic Year : 2022-23 Branch: CSE

CO WISE MARKS REME

SRI MITTAPALLI COLLEGE OF ENGINEERING :: CC-U9

Academic Year : 2022-23 Branch: CSE

SRI MITTAPALLI COLLEGE OF ENGINEERING :: CC-U9

Academic Year : 2022-23 Branch: CSE

2a) definition of automation & process automation 2M

2b) List of seven core metrics 1M

3b) policy of agile methodlogy 1M

SRI MITTAPALLI COLLEGE OF ENGINEERING :: CC-U9

Academic Year : 2022-23 Branch: CSE

C04 10 33.3 II. UNDERSTAND 05 16.6

CO5 10 33.3 III. UNDERSTAND 10 33.3

SRI MITTAPALLI COLLEGE OF ENGINEERING :: CC-U9

Unit Wise Important Questions

S. No. Q. No. Question

UNIT I : Conventional Software Management

SRI MITTAPALLI COLLEGE OF ENGINEERING :: CC-U9

Objective Type Questions

1. _______ is not an effective software project management focus.

2. _________ is not a project manager’s activity

3. The __________ is not an approach to software cost estimation?

4. Waterfall model is also known as

5. A Waterfall model is a model of

a) Previous phase b) next phase c) both A and B d) None

7. List of factor to Improving software economics are

11. ROI Refers to

a) Requirements on Investment b) Relation on Integration c) Return of

12. SLOC Refers to

13. ------------- refers to an organization 's policies, procedures, and

14. The time scale of meta process is -----------

15. Walkthroughs catch ---------of the errors

16. ------% of the contribution comes from -----% of the contributors.

17. Five staffing principles are proposed by -----

23 Life-cycle software artifacts are organized into ------distinct sets

25. --------------provideperiodic snapshots of project health and status,

26. C ------------ is the vehicle for budgeting and collecting costs