UNIT-2

REDUCING SOFTWARE PRODUCT SIZE

Reducing software size helps save time, cost, and effort. The goal is to achieve
more with less code written by humans.
Key Methods:
1. Component-Based Development – Use ready-made parts (components)
instead of building from scratch.
2. Reuse – Reuse existing code or commercial products to avoid duplicating
work.
3. Object-Oriented Programming (OOP) – Organize code using objects to
make it reusable and smaller.
4. Automatic Code Generators – Use tools like GUI builders and CASE
tools to generate code automatically.
5. Higher-Order Languages – Languages like Java, C++, and Visual Basic
allow developers to write less code for more work.
Benefit:
All these techniques reduce the number of human-written lines of code, which
cuts down development cost and improves productivity.
Function Points:
Used to measure what a system does, independent of the programming
language.
For example:
 Java/Visual Basic require fewer lines per function than Assembly or C.
Object-Oriented and Visual Modeling:
 Makes software design clearer with diagrams.
 Encourages shared understanding between users and developers.
 Allows easy changes without affecting the whole system.
Reuse:
Reuse means using existing software parts—like code, libraries, or modules—in
new projects instead of creating everything from the beginning.
 Saves time and money
 Improves software quality
 Encourages consistency across multiple projects

Examples:
 Reusing login or payment modules in different applications.
 Using open-source libraries like React.js or TensorFlow.
Key Points:
 Reusable components must be well-tested and easy to integrate.
 Creating reusable components takes effort but offers long-term benefits.
 Good reuse practices improve productivity in every step of development
(design, coding, testing).
COMMERCIAL COMPONENTS
These are ready-made software parts or tools created by companies and sold or
licensed for use in other applications. Few Examples are Databases like Oracle,
MySQL and Middleware like Apache Kafka ,UI libraries like DevExpress,
Syncfusion
 When you need fast results, standard features, or reliable support
  Best for non-core functionalities (e.g., login systems, payment gateways)
 Benefits are like Speeds up development, Reduces custom coding, Comes
with professional support and updates
Challenges:
 Might be expensive
 Can limit flexibility if not customizable
 May lead to dependency on the vendor

Improving Software Processes

What is a software process
A software process is the way teams and organizations plan, manage, and build
software. The term “process” has different levels, and each one focuses on
different goals.
1. Metaprocess – The Organization Level
 Focus: Big picture strategy
 It includes company-wide rules, long-term planning, and investment
decisions in software projects.
 Example: Deciding to adopt AI-based software development across all
projects.
2. Macroprocess – The Project Level
 Focus: Managing individual software projects
 It applies the company’s metaprocess to a specific project, making sure
the software is built within time, budget, and quality limits.
 Example: Planning how to build an e-commerce app within 3 months
using a fixed budget.
3. Microprocess – The Team/Task Level
 Focus: Daily work and tasks
 It’s about how a small team or developers produce specific parts of the
software—like writing code or designing a screen.
  Example: A developer writing login functionality with good quality and
on time.
Why Improve Software Processes?
In the real world, software development is messy.
 Problems are not always clear.
 Teams have different skills and ideas.
 Time and money are limited.
So, we improve processes to:
 Avoid waste and rework
 Meet deadlines and customer needs
 Increase quality while saving costs
Bottom line:
Each level (meta, macro, micro) serves a unique purpose. Improving them helps
in building better software—faster, cheaper, and with fewer errors.

Improving Team Effectiveness

Teamwork matters more than just having talented people.
A project can succeed with an average team if managed well, but even the best
engineers can't save a poorly managed or badly designed project.
Key Ideas:
 Good management > Good individuals
 Clear system design > Brilliant team with poor direction
Boehm's 5 Principles for Building a Good Team:
1. Top Talent – Hire fewer but smarter people.
2. Job Matching – Give people tasks that suit their skills and interests.
3. Career Growth – Help team members grow in their careers.
4. Team Balance – Build a team where members complement each other.
5. Phase-out Misfits – Remove people who don’t fit the team or role.
Qualities of a Good Project Manager:
1. Hiring Skill – Choosing the right person for the right job is crucial.
2. Customer Interaction – Work well with clients and avoid conflicts.
3. Decision Making – Make smart and confident decisions, even if it's hard
to explain how.
4. Team Building – Create trust, motivate the team, handle strong
personalities, and guide everyone in the same direction.
5. Selling Skill – Convince team members and clients about plans, goals,
and necessary changes.
A successful software project depends on more than just smart people. It needs a
strong manager who can build the right team, guide them well, and keep
everyone motivated and aligned with the goal.

Improving Automation Through Software Environments

Using the right tools and software environments helps make the software
development process faster, easier, and more efficient.
How tools help:
Tools like:
 Planning software
 Code editors and compilers
 Testing tools
 Debuggers
 Requirement & quality management tools
...help automate tasks that would take longer if done manually.
Benefits of Automation:
 Speeds up development (20–40% effort savings or more)
 Improves software quality
 Reduces team size needed
 Helps with better cost and schedule planning
Round-Trip Engineering:
This means the environment allows:
 Forward Engineering: Automatically generate code from a design (e.g.,
visual model → code)
 Reverse Engineering: Create design or diagrams from existing code (e.g.,
code → visual model)
Economic Impact :
 Analyzing and updating requirements takes up about 40% of the total
project cost.
 Designing the software uses more than 50% of the project's resources.
 Writing code and doing unit testing takes around 50% of the time and
effort in development.
 Testing the software can also use up to 50% of the project's resources.
 Managing changes and version control can take as much as 25% of the
resources, especially in big projects.
 Creating documentation can use more than 30% of the team's time and
effort.
 Handling project management and administration can take up to 30% of
the project budget.

Achieving Required Quality in Software

To build high-quality software, certain best practices must be followed
throughout the development process.
Key Practices for Quality:
1. Start with Clear Requirements:
o Focus early on the most important features (use cases).
o Make sure all requirements are clear and traceable until the end of
the project.
o Keep improving the requirements, design, and plan throughout the
life cycle.
 2. Use Metrics and Indicators:
o Measure how the software architecture is progressing from a rough
model to a complete product.
3. Use Modern Tools and Environments:
o Tools should help with version control, managing changes,
automated testing, document creation, and strong design methods.
4. Use Visual Modeling and High-Level Languages:
o These make it easier to design, reuse components, ensure
reliability, and understand the code.
5. Test Performance Early and Often:
o Run real demos early in the process to catch performance issues
before it's too late.
Problems with Old (Conventional) Approaches:
 In the past, teams often guessed how much system resources (memory,
speed) would be needed.
 At the start, designs looked low-risk, but as development went on:
o Testing showed early estimates were too optimistic.
o Real problems (like performance issues) showed up late.
o Fixing them required big changes to the system’s design.
Main Lesson: Start testing and evaluating quality early—not just at the end—so
you can fix problems before they grow bigger.

Peer Inspections
Peer inspections (like reviews by teammates) are useful for checking software
quality, but they are not the most important factor.
Common Misconception:
People often think peer reviews alone ensure quality. But in reality, they are
secondary to other stronger quality practices.
More Effective Quality Practices:
 1. Transitioning Information – Making sure design and code match and are
understandable, consistent, and practical.
2. Milestone Reviews – Testing work at key stages using real examples and
goals.
3. Tool Support – Using compilers, debuggers, and automated tests to
ensure code is complete and correct.
4. Life-Cycle Testing – Testing the software throughout its development to
make sure it meets the requirements.
5. Change Tracking – Monitoring changes to check whether the project is
improving or facing more issues.
Accountability:
 Peer reviews help keep authors responsible for their work.
 All authors (not just some components) should have their work reviewed.

10 Principles of Modern Software Management

 Start by designing a solid architecture. Make sure the system’s structure,
important features, and plans are well-balanced before starting full
development.
 Follow an iterative process—build the software step by step. This helps in
fixing issues early and managing risks better.
 Use reusable software components instead of writing everything from
scratch. This saves time and reduces the amount of custom coding
needed.
 Set up a proper system to manage changes. When multiple teams work
together, this helps avoid confusion and keeps track of updates.
 Use tools that automatically sync changes across design documents,
source code, and test cases. This makes the process smoother and less
error-prone.
 Create design diagrams using modeling tools like UML to make the
system easier to understand and manage.
  Check the quality of the work and progress regularly throughout the
project, not just at the end.
 Show working parts of the software during development to get feedback
and improve continuously.
 Plan each release with small, usable features based on how the software
will actually be used.
 Make the development process flexible so it can be adjusted based on the
size and needs of the project.

Transitioning to an Iterative Software Process

Old Way: Waterfall Model
 In the Waterfall model, each phase (like planning, designing, coding,
testing) happens one after the other.
 You can’t go back once a phase is complete.
 This is risky, especially if problems are discovered late.
New Way: Iterative Model
 In Iterative development, the software is built step-by-step in small cycles
(iterations).
 Each cycle improves the product by adding features, fixing issues, and
refining plans.
 You can test, adjust, and improve early, reducing major risks.
Why it’s better (Economically)?
 Although the exact savings are hard to measure, iterative methods help
reduce risks, improve quality, and avoid costly mistakes.
 The COCOMO II model (a tool used to estimate software cost) shows
that better processes lead to lower overall effort and cost.
Key Concepts Behind the Iterative Approach:
1. Application Precedentedness
o If you're building something new, early iterations help explore
unknowns and set examples (precedents) to guide the rest of the
work.
2. Process Flexibility
o Software needs can change often. Iterative processes are flexible,
allowing you to adapt plans and designs without starting over.
3. Architecture Risk Resolution
o In this model, architecture (the base structure) is developed first.
o This helps avoid big design mistakes and guides decisions about
tools, components, or systems to build or buy.
4. Team Cohesion
o A united and clear-minded team works better.
o Modern tools (like UML and visual modeling) help teams
understand and communicate ideas clearly.
5. Software Process Maturity
o Mature (well-structured) processes use automated tools to ensure
quality.
o These tools help track progress, manage changes, and improve
decision-making.
Model-Based Software Architecture (MBSA) is an approach that uses formal
models and notations (such as UML) to represent the structure, behaviour, and
deployment of a software system. It acts as a blueprint for both technical and
management aspects of software development.
Importance of Model-Based Architecture
1. Clarity and Abstraction
 Provides a clear and structured representation of system components and
their relationships.
 Helps in managing system complexity by using views like component
view, deployment view, and behaviour view.
2. Communication Tool
 Serves as a common language between developers, architects, testers, and
managers.
 Reduces miscommunication and ensures alignment across stakeholders.
3. Support for Design Decisions
 Facilitates trade-off analysis (e.g., performance vs. scalability).
 Encourages early identification of design flaws or bottlenecks.

Management Perspective of Software Architecture

From a management perspective, software architecture is considered the most
important technical part of a software project. It defines how different
components work together and how teams collaborate efficiently. A good
architecture ensures smooth communication, while a poor one can lead to
project failure.
Three Aspects of Software Architecture
1. Architecture Concept (Blueprint)
o Like a system's master plan or design.
o Contains all needed technical information to build the system (just
like a blueprint in construction).
2. Architecture Baseline (Tangible Output)
 o A real and useful output that shows how the system’s vision can be
achieved within limits like cost, time, and technology.
3. Architecture Description (Human-readable)
o A simplified version of the architecture design.
o Helps people (especially non-technical stakeholders) understand
the system easily.
Why Software Architecture is Important
 It sets key goals and stages of the project (milestones).
 Acts as a bridge between the problem (what’s needed) and the solution
(final product).
 Improves communication between team members and departments.
 Prevents failure by ensuring the system is well-structured.
 Helps in planning, reduces risks, and ensures the project stays on track.
 Needs creativity, and can’t be done fully by automation.

Technical Perspective of Software Architecture

An architecture is made up of different views.
Each view gives a simplified picture of how the system works, instead of
showing every small detail.
There are five main views:
1. Design View
 Shows main structure and functions of the system.
 Explains how the system is organized using class and object diagrams.
2. Process View
 Explains how different parts of the system communicate during
execution.
 Covers topics like multitasking, threads, and communication between
processes.
  Uses deployment and behavioural diagrams (e.g., sequence, state, activity
diagrams).
3. Component View
 Focuses on the source code structure.
 Useful for developers during release and configuration.
 Uses component and behavioural diagrams.
4. Deployment View
 Shows where components run—on which hardware (e.g., servers, cloud).
 Uses deployment diagrams and behavioural diagrams.
5. Use Case View
 Shows how important functions (use cases) are implemented.
 Uses:
o Use case diagrams (static view)
o Behavioural diagrams (dynamic view)
What an Architecture Baseline Should Include
1. Requirement: Critical use cases, system goals, and how features are
prioritized.
2. Design: Details like class names, behaviours, and how components are
related.
3. Implementation: List of all components with details like name, purpose,
and cost (like a bill of materials).
4. Deployment: Working components that show whether key use cases and
quality goals are met.
Engineering Artifacts Sets
PRAGMATIC ARTIFACTS
 Sometimes, people need to review information but can’t understand
technical languages like UML. For example, managers or auditors may
ask: “I don’t know UML. Can you give me something simple like
flowcharts or plain text?”
 Sometimes, people want to review documents but don’t have the special
tools. Most people outside the team don’t have the software to open
technical files, so paper or simple electronic documents must be shared.
Standard formats like UML, spreadsheets, and common programming
languages, along with visualization tools and websites, now make it
easier to share documents online. Documents should use clear, proper
English words. Avoid confusing abbreviations or acronyms unless they
are widely known. This makes documents easier to read and understand,
reduces mistakes, and allows people to review them without paper.
 Good documents are those people actually use.
 Paper documents feel more real. But electronic documents can be
changed quickly, which makes some people worry because they can’t be
sure the document hasn’t been changed since they last saw it.

Management Artifact Set

The management set includes documents that help track, plan, and control the
software development process.
These documents help make sure the project:
 Runs smoothly
 Stays on budget
 Meets its goals
1. Business Case:
 Checks if the project is worth investing in.
 Includes expected revenue, cost, risks, and return on investment (ROI).
 Is updated regularly as new information becomes available.
2. Software Development Plan (SDP):
 Explains how the project will be executed.
  Needs to be regularly updated and shared with all team members.
3. Work Breakdown Structure (WBS):
 Helps track costs and budget.
 Breaks the project into smaller tasks for better management.
4. Software Change Order Database:
 Manages changes in the project.
 Tracks updates efficiently to allow flexibility during development.
5. Release Specifications:
 Defines goals, scope, and evaluation for each software release.
 Adapts as the project grows and needs change.
6. Release Description:
 Summarizes what was achieved in each release.
 Includes performance evaluation compared to original goals.
7. Status Assessment:
 Provides regular updates on progress and risks.
 Includes financial info, staffing, risk assessments, and project milestones.
8. Environment:
 Lists the tools and technologies used for development.
 Includes tools like automation, testing, defect tracking, and programming.
9. Deployment Documents:
 Guides for installing, operating, and transitioning the software.
 Includes user manuals, training materials, and marketing plans.
ARTIFACT SETS
To make building a complete software system easier to manage, different groups
of information are organized into artifact sets. An artifact is a collection of
related information that is usually created and reviewed together as one piece.
During the software life cycle, artifacts are divided into five main sets. Each set
is grouped by the kind of language it uses:
• Management artifacts, which include documents in free-form text, like plans
and reports
• Requirements artifacts, which include organized text and models describing
what the system must do (the problem space)
• Design artifacts, which include models that show how the system will work
(the solution space)
• Implementation artifacts, which include source code files written in
programming languages
• Deployment artifacts, which include files in formats that computers can use
for installation and operation
1. The Management Set
This includes all the documents needed to plan and run a software project.
Examples:
 Work breakdown structure: Lists tasks and tracks money.
 Business case: Shows cost, schedule, and profit.
 Release specs: What features each version will have.
 Development plan: Steps to build the project.
 Change orders & status reports: Track changes and progress.
 Deployment docs: Installation and training materials.
 Environment details: List of tools and platforms used.
These documents are reviewed by team members and stakeholders to make sure
everything is correct and on track.
2. The Engineering Sets
These are grouped into 4 main sets used to build the software:
a. Requirements Set
 Describes what the software must do.
 Checked to make sure it's complete, consistent, and matches the plan.
b. Design Set
 Includes UML diagrams that show how the system works.
 Ensures the design is clear and follows the requirements.
c. Implementation Set
 Includes the actual source code.
 Checked by testing and comparing with the design and requirements.
d. Deployment Set
 Includes the finished product: executable files, installation scripts, etc.
 Tested for real-world use (installation, usage, updates, errors).
Each set is most important at a different project phase:
 Requirements → Inception phase
 Design → Elaboration phase
 Implementation → Construction phase
 Deployment → Transition phase
 Management → Ongoing throughout all phases
3. Modern Tools Used
 Management tools: For planning, tracking, and documentation.
 Requirements tools: To organize what the system should do.
 Design tools: For diagrams and modeling.
 Implementation tools: For coding, testing, debugging.
 Deployment tools: For delivery and system setup.
4. Test Artifacts
These are test files and programs created alongside the software from the start
to end.
Key points:
 Tests are made for each phase (requirements, design, code, deployment).
 Tests are automatic and reusable.
 Testing tools are the same as development tools.
Example (Seismic Data Project):
 Management set: Test plans and issue logs.
 Requirements set: What features need to be tested.
 Design set: Simulators and performance tools.
 Implementation set: Test scripts and test data.
 Deployment set: Final testing tools for the user environment.
UNIT - 5
Project Control & Process Instrumentation
Introduction:
Software metrics are numbers or data used to measure how well software is
being developed and how good the final product is. They help us track quality,
progress, and performance during software development.
Why Do We Need Software Metrics?
 To accurately estimate the cost and time needed for a project.
 To track progress and check if the project is on schedule.
 To measure the quality of the software product.
What Are Indicators?
Indicators are signals or summaries derived from metrics. They give insight into
the status of the software or project.
There are two types:
1. Management Indicators – Show project health like budget, progress, and
staffing.
2. Quality Indicators – Show how good the software is, based on changes
and performance.
Seven Core Metrics in Project Control:

Management Indicators Quality Indicators

Work and Progress Change Traffic & Stability

Budget vs. Expenditures Breakage & Modularity

Staffing & Team

Rework & Adaptability
Dynamics

Mean Time Between Failures (MTBF) &

Maturity
MANAGEMENT INDICATORS
These are metrics used by project managers to track the progress, cost, and team
during software development. There are three main types:
1. Work and Progress
Tracks how much work is done over time compared to the original plan.
How it’s measured:
 Plan the work using clear tasks.
 Track how much work is completed at each stage.
Examples by Team:
 Architecture Team: Check how many use cases are shown.
 Development Team: Count how many lines of code are managed and
changes completed.
 Testing Team: Look at how many test cases are done and issues reported.
 Management Team: Track how many major goals (milestones) are
finished.
2. Budgeted Cost and Expenditures
Monitors how much money is planned to be spent and how much is actually
spent.
Important Terms:
 Expenditure Plan: What you planned to spend over time.
 Actual Cost: What you have actually spent.
 Earned Value: The cost of work actually done so far.
 Cost Variance: Difference between actual cost and earned value (shows
over/under budget).
 Schedule Variance: Difference between planned cost and earned value
(shows delay or ahead).
Example Measures:
 Cost per month
  Staff cost per month
 % of budget used
3. Staffing and Team Dynamics
Tracks how team members join or leave over time.
Key Points:
 Start with a small team at the beginning to reduce risk.
 Add more people as the project becomes stable.
 Too many new people at once can slow down progress.
 Keeping good team members (low attrition) is a sign of success.
Measured As:
 People added per month
 People leaving per month

QUALITY INDICATORS
Quality indicators help track how stable, maintainable, and reliable a software
project is over time. These metrics show how well a software product is
evolving and how much effort is needed to fix or improve it.
1. Change Traffic and Stability
 Change Traffic = Number of software changes (bugs or updates) opened
and closed during the project.
 Stability = How well the team keeps up with solving those changes.
Healthy software has more changes closed than opened over time, meaning it is
becoming more stable.

2. Breakage and Modularity

 Breakage = How much existing code needs to be changed when
something new is added or fixed. Measured in lines of code or number of
components affected.
 Modularity = How well the software is built in parts (modules) that don’t
affect each other when changed.
Less breakage = better modularity and cleaner design.
3. Rework and Adaptability
 Rework = How much time and effort it takes to fix or adjust code after a
change.
 Adaptability = How that rework changes over time (does it get easier or
harder?).
Some changes take 1 hour; others take weeks. Tracking this helps plan better
and improve software flexibility.
4. MTBF and Maturity
 MTBF (Mean Time Between Failures) = How long the software runs
without crashing or breaking.
  Maturity = If MTBF is increasing over time, the software is becoming
more stable.

Types of bugs:
 Bohr-bugs = Clear, repeatable bugs (e.g., coding mistakes).
 Heisen-bugs = Random bugs that are hard to reproduce (e.g., timing or
system design errors).
More test hours and fewer bugs = higher maturity.

Life-Cycle Expectations
In software projects, it's important to track progress using metrics (measurable
values).
 These metrics don’t have a fixed formula but help us see how the project
is going over time.
 Instead of focusing only on the final result, these metrics help track
changes and progress during each phase.
 They also help find waste, like repeated work or errors.
Project Phases and Their Progress:

Stage What Happens

Planning starts, low progress, small team, basic ideas (like a

Inception
prototype).

Elaboration Architecture gets stronger, team grows, work increases.

Construction Most of the product is built, high effort, high cost.

Transition Product is finished, tested, and ready to deliver.

As the project moves ahead:

 The software becomes stable.
 The team gets bigger.
 The quality improves.
 The system becomes usable and strong.
Metrics Automation
To manage a project better, we use tools to automate progress tracking.
What is SPCP?
SPCP = Software Project Control Panel
It’s like a live dashboard that shows:
 How much work is done
 What's delayed
 What needs attention
What it has:
 Charts and graphs (to show progress)
 Data collectors (to get real-time info from the project)
 Roles like:
o Monitor: Team leader or manager who watches progress
o Admin: Sets up the panel
Metrics can show:
 A value at a point in time (e.g., "75% complete today")
 A graph over time (e.g., "how progress increased each week")
We can also set thresholds (e.g., "progress must be at least 80% by week 6").
Basic Types of Metrics in Software Projects
There are 3 main types of metrics used to track project performance:
Trend , Comparison , Progress
The graphs in the image show how a metric (like code progress or cost) changes
with time.
SPCP – Software Project Control Panel
SPCP is a dashboard tool used by project managers to monitor software project
metrics.
How to Use It (Step-by-step):
i. Start the SPCP – Open the dashboard
ii. Choose panel type – Pick how you want the data to appear
iii. Pick metric type – Select whether you want a number (value) or a graph
iv. Add control line – Optionally show target lines or limits for comparison
v. Zoom into trends – Focus on how values are changing over time
vi. Zoom into a date – Look at the metric on a specific day
vii. See deeper info – Go into more details if needed
viii. View detailed indicators – Explore fine-grained data