The Cost Estimation Body of Knowledge for Software is in development for a number of years within ICEAA. First as a section of the general CEBoK, but it will be established as a separate CEBoK-S for Software, since software is becoming very prominent within the cost estimation community.
The journey of UNISON Cost Engineering in the field of automotive software cost estimation started in 2018. The expectation is that in 2030 the cost of software will be 50% of the total production cost of a car. To help the OEM get a proper understanding of the software development cost they need to use some form of size measurement to compare, challenge and control the cost of software development by the software vendors.
Resolving Cost Management and Key Pitfalls of Agile Software Development - Da...Nesma
Agile software development does not always live up to the promises. Especially in the field of IT Cost Management. Without proper estimation and tracking the value cannot be made clear.
There are many approaches to reuse in software engineering. Among them, patterns hold a prominent position. "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" (Alexander, 1979). We are interested in the use of patterns for the requirements analysis stage, namely Software Requirement Patterns. The patterns applicability to this context is clear, since requirements that appear over and over in requirements books could be identified as the solution to particular problems in a given context (the classical context-problem-solution scenario of patterns).
Presentation of Software Requirement Patterns in the PABRE framework.
Awareness of design smells - indicators of common design problems - helps developers or software engineers understand mistakes made while designing and apply design principles for creating high-quality designs. This presentation provides insights gained from performing refactoring in real-world projects to improve refactoring and reduce the time and costs of managing software projects.
The journey of UNISON Cost Engineering in the field of automotive software cost estimation started in 2018. The expectation is that in 2030 the cost of software will be 50% of the total production cost of a car. To help the OEM get a proper understanding of the software development cost they need to use some form of size measurement to compare, challenge and control the cost of software development by the software vendors.
Resolving Cost Management and Key Pitfalls of Agile Software Development - Da...Nesma
Agile software development does not always live up to the promises. Especially in the field of IT Cost Management. Without proper estimation and tracking the value cannot be made clear.
There are many approaches to reuse in software engineering. Among them, patterns hold a prominent position. "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" (Alexander, 1979). We are interested in the use of patterns for the requirements analysis stage, namely Software Requirement Patterns. The patterns applicability to this context is clear, since requirements that appear over and over in requirements books could be identified as the solution to particular problems in a given context (the classical context-problem-solution scenario of patterns).
Presentation of Software Requirement Patterns in the PABRE framework.
Awareness of design smells - indicators of common design problems - helps developers or software engineers understand mistakes made while designing and apply design principles for creating high-quality designs. This presentation provides insights gained from performing refactoring in real-world projects to improve refactoring and reduce the time and costs of managing software projects.
Software Testing Techniques: An Overview QA InfoTech
Are you sure you're well versed with the intricate details of the techniques involved in software testing? Via this PPT, get some insight on static and dynamic software testing techniques, white box testing, and black box testing as well stay tuned for more!
How should we estimates agile projects (CAST)Glen Alleman
“Why do so many big projects overspend and
overrun? They’re managed as if they were merely
complicated when in fact they are complex. They’re planned as if everything was known at the start when in fact they involve high levels of uncertainty and risk.” ‒ Architecting Systems: Concepts, Principles and Practice, Hillary Sillitto
Critical steps in Determining Your Value Stream Management SolutionDevOps.com
In order to increase your delivery velocity, you must find, identify and solve the bottlenecks of delivery. Value Stream management solutions capture metrics and processes helping guide your digital transformation journey.
Join Marc Hornbeek, Principal Consultant and Jeff Keyes from Plutora where they will discuss a methodology determining a value stream management solution for your organization. It will consist of critical steps including a Review of VSM Assessments, Future-State Value Stream Mapping, Road-Mapping VSM Transformation, and more. Following these steps provide a logical and comprehensive approach to determine a value stream management solution that fits for your organization’s requirements.
What will be learned:
WHY – is following steps for determining a VSM solution important?
HOW – are VSM solutions determined?
WHAT – is the expected outcome of a Value Stream Management solution recommendation?
Great news! Executive leadership has reviewed and approved the Cjesseniasaddler
Great news! Executive leadership has reviewed and approved the Cloud Adoption Policy Addendum. As the principal cloud architect for BallotOnline, you are now looking forward to the next challenge from the leadership team: creating a design for cloud deployment throughout the organization. The designs for each component in the organization will make up the Cloud Deployment Architecture Plan.
BallotOnline has decided to move forward with the top three workloads identified as "cloud ready": email, software development, and backups and archiving.
You know that those workloads can be very different from one another. You will need to carefully review the workloads in terms of performance, capacity, cost, and availability requirements. You will need to design the deployment architecture plan for each workload. This will require you to research and evaluate the available cloud service offerings as well as the kind of architectures that would be best for BallotOnline. Your cloud deployment architecture plan must meet BallotOnline's cloud adoption policies and the business needs for deploying these workloads in the cloud. It's another layer of responsibility, and you realize that a lot of the company's financial viability rests on your ability to find the best service offerings.
Check the
Project 2 FAQ thread
in the discussion area for any last-minute updates or clarifications about the project.
You will design the deployment architecture plan for each workload over a series of 10 steps, and the project will take about two weeks to complete. Click on Step 1 to get started.
Step 1: Develop User Stories From BallotOnline Employees
BallotOnline has decided to move forward with the migration of the email, software development, and backups and archiving workloads to the cloud. You will need to have a good understanding of what users really need in terms of performance, capacity, availability, etc., in order to design an effective architecture and select the best cloud offerings.
In this step, you will write
user stories
, brief high-level definitions of requirements that describe what the user wants to achieve in simple terms.
Watch the four
user interviews
of current BallotOnline employees describing their IT needs. You can record your user stories in the
user stories template
. Upload them to the submission box below for Sophia’s feedback.
Step 3: Evaluate Available Cloud Service Offering Architectures for Software Development
Similar to the way you evaluated cloud architectures for email, in this step you will focus on the software development environment in
cloud platforms
.
Traditionally, software development efforts follow the
software development life cycle
. In the cloud, the core steps of the SDLC may take advantage of PaaS offerings, which provide development environments for different kinds of software applications.
Examples of Platform as a Service (PaaS) Offerings
AWSMicrosoft AzureGoogle Cloud PlatformThird Party
Ela ...
Boost Your IT Career with IEEE's Software Engineering Certifications Ganesh Samarthyam
Are you a student searching for your first job in the IT industry? Are you a IT professional looking for enhancing your skills, get noticed and get promoted? If so, this presentation is for you: this short presentation provides you with a quick overview of IEEE's Software Engineering certifications. Student or professional - with IEEE's SE certifications are sure to provide the much needed boost to your IT career.
Stepwise Project planning in software developmentProf Ansari
The following activities are:
Identify objectives and practical measures of the effectiveness in meeting those objectives.
Establish a project authority
Stakeholder analysis – identify all stakeholders in the project and their interests
Modify objectives in the light of stakeholder’s analysis
Establish methods of communication with all parties
2.4
Software Testing Techniques: An Overview QA InfoTech
Are you sure you're well versed with the intricate details of the techniques involved in software testing? Via this PPT, get some insight on static and dynamic software testing techniques, white box testing, and black box testing as well stay tuned for more!
How should we estimates agile projects (CAST)Glen Alleman
“Why do so many big projects overspend and
overrun? They’re managed as if they were merely
complicated when in fact they are complex. They’re planned as if everything was known at the start when in fact they involve high levels of uncertainty and risk.” ‒ Architecting Systems: Concepts, Principles and Practice, Hillary Sillitto
Critical steps in Determining Your Value Stream Management SolutionDevOps.com
In order to increase your delivery velocity, you must find, identify and solve the bottlenecks of delivery. Value Stream management solutions capture metrics and processes helping guide your digital transformation journey.
Join Marc Hornbeek, Principal Consultant and Jeff Keyes from Plutora where they will discuss a methodology determining a value stream management solution for your organization. It will consist of critical steps including a Review of VSM Assessments, Future-State Value Stream Mapping, Road-Mapping VSM Transformation, and more. Following these steps provide a logical and comprehensive approach to determine a value stream management solution that fits for your organization’s requirements.
What will be learned:
WHY – is following steps for determining a VSM solution important?
HOW – are VSM solutions determined?
WHAT – is the expected outcome of a Value Stream Management solution recommendation?
Great news! Executive leadership has reviewed and approved the Cjesseniasaddler
Great news! Executive leadership has reviewed and approved the Cloud Adoption Policy Addendum. As the principal cloud architect for BallotOnline, you are now looking forward to the next challenge from the leadership team: creating a design for cloud deployment throughout the organization. The designs for each component in the organization will make up the Cloud Deployment Architecture Plan.
BallotOnline has decided to move forward with the top three workloads identified as "cloud ready": email, software development, and backups and archiving.
You know that those workloads can be very different from one another. You will need to carefully review the workloads in terms of performance, capacity, cost, and availability requirements. You will need to design the deployment architecture plan for each workload. This will require you to research and evaluate the available cloud service offerings as well as the kind of architectures that would be best for BallotOnline. Your cloud deployment architecture plan must meet BallotOnline's cloud adoption policies and the business needs for deploying these workloads in the cloud. It's another layer of responsibility, and you realize that a lot of the company's financial viability rests on your ability to find the best service offerings.
Check the
Project 2 FAQ thread
in the discussion area for any last-minute updates or clarifications about the project.
You will design the deployment architecture plan for each workload over a series of 10 steps, and the project will take about two weeks to complete. Click on Step 1 to get started.
Step 1: Develop User Stories From BallotOnline Employees
BallotOnline has decided to move forward with the migration of the email, software development, and backups and archiving workloads to the cloud. You will need to have a good understanding of what users really need in terms of performance, capacity, availability, etc., in order to design an effective architecture and select the best cloud offerings.
In this step, you will write
user stories
, brief high-level definitions of requirements that describe what the user wants to achieve in simple terms.
Watch the four
user interviews
of current BallotOnline employees describing their IT needs. You can record your user stories in the
user stories template
. Upload them to the submission box below for Sophia’s feedback.
Step 3: Evaluate Available Cloud Service Offering Architectures for Software Development
Similar to the way you evaluated cloud architectures for email, in this step you will focus on the software development environment in
cloud platforms
.
Traditionally, software development efforts follow the
software development life cycle
. In the cloud, the core steps of the SDLC may take advantage of PaaS offerings, which provide development environments for different kinds of software applications.
Examples of Platform as a Service (PaaS) Offerings
AWSMicrosoft AzureGoogle Cloud PlatformThird Party
Ela ...
Boost Your IT Career with IEEE's Software Engineering Certifications Ganesh Samarthyam
Are you a student searching for your first job in the IT industry? Are you a IT professional looking for enhancing your skills, get noticed and get promoted? If so, this presentation is for you: this short presentation provides you with a quick overview of IEEE's Software Engineering certifications. Student or professional - with IEEE's SE certifications are sure to provide the much needed boost to your IT career.
Stepwise Project planning in software developmentProf Ansari
The following activities are:
Identify objectives and practical measures of the effectiveness in meeting those objectives.
Establish a project authority
Stakeholder analysis – identify all stakeholders in the project and their interests
Modify objectives in the light of stakeholder’s analysis
Establish methods of communication with all parties
2.4
Agile development methods increase the Probability of Program Success. Agile can be integrated with the FAR / DFAR and OMB mandates for program performance measures using Earned Value.
The Use of Functional Size in the Industry.pdfNesma
In this webinar, the emphasis is on the use of Functional Size in the Industry, and we focus on several use cases where functional size helps organizations to make impactful decisions based on objective metrics and data.
While traditional performance metrics often measure individual output or adherence to pre-defined plans, measuring performance in agile teams requires a different approach. Agile teams operate in iterative cycles, prioritizing adaptability and learning over rigid goals. So, why do organizations still measure their performance?
By using the right metrics in the right way, organizations can empower their agile teams to thrive and deliver exceptional results.
Software Cost Estimation webinar January 2024.pdfNesma
In this webinar you will learn why Software Cost Estimation is important, what is the Software Cost Estimation Body of Knowledge for Software and the ways you can become a professional certified software cost estimator SCEC!
The COSMIC battle between David and Goliath - Paul HusseinNesma
No more exhaustive and emotional discussions on price and deliverables. Predictable prices for projects and changes. No escalating maintenance costs. This can only be done by specifying exactly what you want and outsource it to the right service providers that have the required platform already in place.
Succesful Estimating - It's how you tell the story - Amritpal Singh AgarNesma
Estimating the Cost of something is a profession. But then you have to tell the story about the estimate to whoever needs to hear that story. The success of how you tell the story is determining the success of the cost estimate.
Agile Development and Agile Cost Estimation - A return to basic principles - ...Nesma
Is there a natural tension between agile development and traditional cost management or do we need to return to basic principles? Even when you are flexible, you still need to make a plan, build an estimate and measure what you have achieved.
Project Succes is a Choice - Joop SchefferlieNesma
Project success is a choice. Don't stop thinking about the best way to do a project, agile or not. Select the best competencies to ensure that the project will be successful.
Deze presentatie beschrijft een praktische implementatie van het gebruik van Nesma functiepunten in Agile deliveries. Deze presentatie is gepresenteerd door Richard Sweer van Infinity tijdens de webinar Afrekenen met functiepunten. Voor meer info: www.nesma.org; conference@nesma.org.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
PHP Frameworks: I want to break free (IPC Berlin 2024)Ralf Eggert
In this presentation, we examine the challenges and limitations of relying too heavily on PHP frameworks in web development. We discuss the history of PHP and its frameworks to understand how this dependence has evolved. The focus will be on providing concrete tips and strategies to reduce reliance on these frameworks, based on real-world examples and practical considerations. The goal is to equip developers with the skills and knowledge to create more flexible and future-proof web applications. We'll explore the importance of maintaining autonomy in a rapidly changing tech landscape and how to make informed decisions in PHP development.
This talk is aimed at encouraging a more independent approach to using PHP frameworks, moving towards a more flexible and future-proof approach to PHP development.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
"Impact of front-end architecture on development cost", Viktor TurskyiFwdays
I have heard many times that architecture is not important for the front-end. Also, many times I have seen how developers implement features on the front-end just following the standard rules for a framework and think that this is enough to successfully launch the project, and then the project fails. How to prevent this and what approach to choose? I have launched dozens of complex projects and during the talk we will analyze which approaches have worked for me and which have not.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
When stars align: studies in data quality, knowledge graphs, and machine lear...
CEBoK for Software Past Present Future - Megan Jones
1. Cost Estimating
Body of Knowledge - Software:
past, present, and future
Megan Jones
Eric van der Vliet
2. Introduction
• ICEAA has maintained a Cost Estimating Body of Knowledge (CEBoK)
for many years – it serves as the foundation for CCEA/PCEA
certification
• While there is a CEBoK module on software cost estimating, ICEAA
recognizes that
• Software is an ever-increasing portion of total systems cost
• There are unique aspects of software cost estimating that merit special attention
• Recognizing these facts, ICEAA decided to develop a Cost Estimating
Body of Knowledge – Software (SCEBoK) and plans to finish the initial
version in late 2022
• This briefing provides an overview of CEBoK-S
3. Why is Software Cost Estimating Important?
Software is increasingly embedded (in
everything)
4. 2016-2018
2015: Established the Software Cost Estimation Training and Certification
Steering Committee with ICEAA, Nesma, and IFPUG
2016: Started the Software Certification Curriculum Working Group in
2016 to identify important topics, structure a table of contents for
a software cost estimating curriculum
2017: First appearance of the content that would become the Software
Cost Estimating Body of Knowledge. Seven software estimation
training sessions featured at the ICEAA Professional Development
& Training Workshop In Portland, Oregon, USA
2018: 14 Software CEBoK Training offerings at the 2018 ICEAA
Workshop
5. 2019
ICEAA and Nesma sign a MOU committing to continue the project
16 Software CEBoK training offerings at the 2019 ICEAA Workshop
The same training is offered October 2019 at the IWSM-Mensura
Conference in Haarlem, Netherlands
ICEAA begins negotiating contracts to accelerate the effort using paid vs.
volunteer contributions
ICEAA has partners with the U.S. Defense Acquisition University (DAU)
to use their existing course materials, known as BCF-250:
Software Cost Estimating, as one of the foundations for SCEBoK
6. 2020
ICEAA partners with the U.S. Defense Acquisition University (DAU) to
use their existing software cost estimating course materials as one
of the foundations for SCEBoK (along with previously-presented
software training slides and other sources)
Establishes the ICEAA SCEBoK Review Group (ISRG) to collaborate and
best develop an industry and globally accepted product
Contracts a project manager to integrate the source material with ISRG
feedback and to create a written, readable SCEBoK body of
knowledge and a series of PowerPoint slides to use when training
SCEBoK content
Re-brands as Cost Estimating Body of Knowledge-Software (CEBoK-S) to
reduce confusion between CEBoK and SCEBoK
7. Expected Rollout: Late 2022
• First edition will be in PowerPoint format
• Will be available for learning and instructing
• ICEAA is preparing a standalone specialty certification
for Software Cost Estimating, due in 2023
• Eventual goal is to offer an online narrative-format
body of knowledge
8. CEBoK-S Target Audiences
Commercial organizations
Original Equipment Manufacturers (OEMs)
Government organizations
Consulting firms
Quasi-government organizations (e.g., Federally Funded Research &
Development Centers)
Academic institutions
9. CEBoK-S Goals
CEBoK-S will be developed to:
Provide users with an understanding of software estimating that will
compliment and enhance cost estimates and analyses
Factually and objectively present all software sizing methods to allow
users to draw their own conclusions about the merits of any given
method
Provide guidance to the essential considerations in software cost
estimating
Ensure content is not biased towards or focused on the the US
Government or US Department of Defense
10. CEBoK-S and CEBoK ®
CEBoK-S will be a supplement to ICEAA’s Cost Estimating
Body of Knowledge (CEBoK®)
Fundamental cost estimating lessons will not be repeated in CEBoK-S
CEBoK-S should be used in conjunction with CEBoK
References and links will cross between core CEBoK lessons and CEBoK-S modules
12. Lessons 1--6
Lesson 0: Setting the Stage for CEBoK-S
Outline and overview of content
Lesson 1: Introduction
Why software cost and schedule estimating is important
Lesson 2: Software Development Paradigms
Explore each software development paradigm with descriptions
and considerations
13. Lessons 1-6
Lesson 3: CEBoK-S Five-step Estimating Process
Step 1: Develop the scope of the estimate
Step 2: Collect and analyze historical data
Step 3: Create the software estimate
Step 4: Adjust the estimate for risk and uncertainty
Step 5: Document and present the estimate
14. Lessons 1-6
Lesson 4: Estimating Custom Software Development
• Creating a Software Development Estimate
• Software Schedule Estimating
Lesson 5: Software Sustainment
• Definition of Software Sustainment
• Importance of Software Sustainmnet
• Cost Estimating Techniques
• Software Obsolescence
15. Lessons 1-6
Lesson 6: Estimating Procured Software Solutions
• Description of COTS software and its importance
• Primary COTS cost drivers
• Best practices in COTS projects
• Description of ERP and its importance
• Primary ERP system cost drivers and estimating techniques
16. Lesson Supplements: X & Y
Lesson X: Software Size
• Dimensions of software size, methods, and units of measure
• Software size consideration
Lesson Y: Productivity
Lesson Z: Commercial Estimating Models
17. Software-intensive program1
Investment:
• Program/project management
• Systems engineering
• BPR/ Change management
• System Development
• System Procurement
• Hardware (make and/or buy)
• Software (buy)
• System level integration & test
• System
deployment/implementation
Operations & support (O&S)2
• Help desk/service desk support
• Technology refresh/upgrade
• System sustainment
SCEBoK
Lessons 2, 4
SCEBoK Lesson 5
SCEBoK
Lesson 6
1. Adapted from Standard IT LCC WBS V5, US Dept of Homeland Security
2. O&S contains continuation of many investment categories + those new
ones listed here… See definitions in notes
SCEBoK Lesson 6
Software life cycle (example)
• Investment
• Plan (sourcing, business case, governance)
• Develop and/or procure
• Custom Software Development
• Requirements implementation
• Software procurement
• System Integration
• Deployment
• Software Sustainment
SW Changes (Maintenance, Enhancements, Cyber)
Recurring Software Licenses
Other components (6)
End of life
A. Review: Drawing the Line between Software
Development, Procurement, and Sustainment
17
18. Estimating the
Investment
Stage of
Software
Custom
software
developmen
t?
Procure or
Lease?
2. SaaS
Lease
Procure 1. COTS
Purchase
Can only do a Rough
Order of Magnitude
(ROM) estimate
Three major
options: COTS
products glued
together,
Enterprise
solution, or
Data
Warehouse??
Multiple COTS
Products “glued”
together
4. ERP
3. SOA
Enterprise Solution
Do you
know
software
architectur
e ?
Refer to Lesson 4:
Custom Software
Development
No
Yes
C. Identify the Type of
Procured Software Solution (1 of 2)
18
No
Yes
5. EDW
Enterprise Data Warehouse (EDW)
Lesson 6: Estimating Procured
Solutions
Standalone
COTS
Package(s)
Yes
No
6. Hybrid – select most
appropriate approaches from
Lessons 6 and/or 4
19. OPTIMISM
Innate bias - Planning Fallacy
Project managers are risk-seeking
1 COST, SCHEDULE,
TECHNICAL MISALIGNMENT
Like a three-legged stool, all need to
be consistent in order for a project to
balance
2 MOORE’S LAW
Exponential growth in technology
Paired with projects that take a decade
or longer to complete means that
either there is a continual requirements
update process, or the product is
obsolete on delivery
3
BLACK SWANS
Unpredictable, rare, unprecedented
events that have a huge impact
Why Cost and Schedule Growth
Occur
Numerous Reasons, Both
Internal and External
“The Non-Secret of Good Cost
[and Schedule] Estimating:
Don’t Drink the Kool-Aid”-Lawrence
Goeller, OSD Cost Analysis
Improvement Group
4 LAKE WOBEGON
Project managers and staff are not like
the children of Garrison Keillor’s
fictional town – they are not all above
average
5
Source: Christian B. Smart, Solving for Risk Management: Understanding the
Critical Role of Uncertainty in Project Management
20. Summary of Development Paradigms and
Methods
20
Paradigm Method Estimating Level/Approach Logically Associated
Associated contract
contract type
Predictive/
Plan-driven
Waterfall While the CES/WBS may contain activity-level and CSCI-level elements, development effort is
usually estimated at the top-level, for the overall software development effort. Any activities not
included in the CER/Analogy used for estimating are estimated separately.
Firm fixed price
(FFP)
Predictive-
with-
modifications
Incremental Each increment is estimated separately, using size (ESLOC or FP) and other relevant cost drivers
for that increment. Upfront requirements and software testing follow traditional waterfall steps,
with incremental portions of software requirements proceeding through mini-waterfall cycles of
analysis, design, and coding. It is easier to estimate the expected size and productivity of each
increment
Time and materials
or Cost-
reimbursable
Predictive-
with-
modifications
Evolutionary Each “pass” is estimated separately, using size (ESLOC or FP) and other relevant cost drivers for
that pass. In this paradigm, the expected size and productivity of each pass or prototype is closely
tied to previous passes, depending on the feedback received for that pass. Therefore, creative
approaches to estimating later passes is needed.
Time and materials
or Cost-
reimbursable
Predictive-
with-
modifications
Spiral Similar to the Evolutionary paradigm in that cost drivers for each spiral will usually be dependent
on results/analysis of the previous spiral. However, in this paradigm the unique development
activities for each spiral need to be considered, as well as the additional risk and opportunity
assessment and planning effort associated with this paradigm. Size is ESLOC or FP.
Time and materials
or Cost-
reimbursable
Agile Iterative /
Scrum
Sprints are time-boxed, fixed-duration, full-development cycles that ideally, result in working
software at the end of each sprint. Size and productivity are fluid compared to other paradigms
and emerge as development progresses, rather than being predictable at the onset. Estimating
cost and schedule are more difficult than for waterfall due to a lack of relevant and comparable
historical data, and scope flexibility. Estimates based on relative average effort per sprint or
average person hours per sprint, but consistency issues abound. Highly flexible, (but difficult to
estimate.) Minimum viable product (MVP) size may be estimated from a statement of objectives
(SOO) or technical baseline, if available.
Time and materials
or Cost-
reimbursable
Part
predictive/
part agile
Hybrid-agile No standard definition of a hybrid-agile method, but typically consists of a variation of:
1. a formal, upfront, waterfall-like requirements phase to fix the high-level scope;
2. a series of partial-scrum-like build iterations (consisting of analysis, design and coding phases);
3. followed by a waterfall-like testing phase. Estimate based on
Once the development in step 2 begins, cost and schedule are fixed and delivered software size
Fixed price with
incentives or time
and materials
21. Agile paradigm:
overview (1 of 2)
• Stresses iterative and incremental development
and evolution of requirements Change-driven
• Agile an umbrella term for a suite of methods
and practices based on values of the Agile
Manifesto1
• Individuals and interactions over processes and
tools
• Working software over comprehensive
documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• Works well with smaller teams, interim products,
highly engaged customers
21
Adapted from www.agilealliance.org
22. Agile versus waterfall: overview1 (1 of 3)
22
1. AGILE ASSESSMENT GUIDE Best Practices for Agile
Adoption and Implementation, September 2020 GAO-20-
23. Differentiator Agile methods Predictive methods
Focus of work Change-driven based on product value:
fixed time and cost, estimated scope
Project plan: fixed scope, estimated cost and
duration
Frequency of
deployment
Iterative, early & frequent (2-3 weeks) One big release (end of project)
Quality Continuous inspection and testing during
every iteration (impact on rework)
Testing phase inspects out poor quality at the
end (impact on rework)
Customer involvement Co-located, daily review via product owner
owner
Interaction with customers at beginning and
end
Risk of changing
requirements
Minimizes risk by engaging customer to
prioritize requirements to be developed
first
Fixed requirements with high risk due to
incomplete or incorrect requirements or change
change
Development teams Self-organized, may split effort between
Development and Operations
Hierarchical or matrix, fully dedicated to
development
Operations and Security
Security Considerations
With DevSecOps, continuous deployment,
deployment, continuous testing during
development. Can reduce integration costs
costs
Little to no consideration of operations or
security during development. Separate teams.
Operations and security concerns handled post-
post-development
Prototypical contract
type(s)
Time and materials (T&M) or cost-
reimbursable
Firm fixed price (FFP) or fixed price with
incentives 23
Agile versus waterfall: overview (2 of 3)
24. Adapted from https://www.process.st/waterfall-vs-
agile/
24
Agile versus waterfall: overview (3 of 3)
Topic Agile Predictive / waterfall Hybrid-agile (Partly predictive/partly agile)
agile)
Fixed Cost & schedule Scope (requirements) Initial high-level scope fixed, but is flexible to
prioritization and change during development
Estimated Scope (features) Cost & schedule Cost & schedule initially estimated, but
becomes fixed during development
Driver Change-driven Plan-driven Hybrid
Development
risks1
Cost & schedule mostly fixed.
Delivered size may fall short
Scope fixed cost & schedule
overruns
Cost & schedule mostly fixed during build.
Delivered scope may fall short
25. Agile paradigm:
Iterative development (2 of 2)
Advantages:
Adaptable and embraces change
Prioritizes customer satisfaction and communication
Focus on business need and business value
Sustainable development pace
Disadvantages:
Not structured enough for architecture design or re-design work
May need to be combined with waterfall model to fit organizational needs
Appropriate when:
Requirements are not well known upfront
Flexibility and responsiveness to changing requirements are important
25
26. The next slides look at 6 modern agile frameworks +
hybrids
Agile concepts and software estimating1 (1
of 2)
26
WORK
LEVEL
AGILE
DELIVERABLE
ESTIMATION
TYPE
LEVEL SOURCE OF
ESTIMATING
DATA
Organiza
tion
TYPE OF
ESTIMATE
???
Epics Solutions Long-term Portfolio Portfolio
backlog
Value
streams
Budget
indication /
Size-based
S/W
Cost
estimato
r
Features /
Capabilitie
s
Solution Long-term Solution Solution
Backlog
Value
stream
Budget
assignment
to value
stream
S/W
Cost
estimato
r
Features Releases Mid-term
(2-3
months)
Product
Manage
ment
Program
Backlog
Release
Train
Story point
based; Size
/ Effort
based
S/W
Cost
estimato
r
User
Stories
Release Short-term
(2-3 weeks)
Team Team Backlog Iteration
s
Story point
based
Dev
Team
1. Table prepared by Eric van Vliet, CGI Netherlands
27. Source: GAO-20-590G GAO Agile Assessment
Guide, 2020 Page 126
• Consistent sizing is
critical for software
cost estimating
• SLOC and Function
Points can be used for
software development
estimates AND life
cycle cost estimates
(LCCE)
C.1 Software sizing considerations (4 of 5)
Agile: Consistent sizing vs Relative Sizing
27
28. • Original size may be based on high-level estimate of product or release
backlog
• If estimate based on past project velocity, uncertainty with size
compounds
• Agile scope evolves:
• Minimum viable product (MVP) size may grow,
• Content of releases may grow
• Relative effort sizing becomes relevant during project
• Basis of effort, cost and schedule estimate changes
• Cannot fix all three sides of iron triangle
28
Step 4:
Conduct
Sensitivity,
Risk, and
Uncertainty
Analysis
Software Development Growth
3. Agile Scope Growth
29. Agile Velocity is NOT Productivity
• While Velocity, as a generic term, sounds like efficiency, it is NOT Productivity
• Velocity = Sum of Completed Relative Efforts / 1
• Completed relative effort is the estimated relative effort in story points, of a user story completed during
the sprint;
• 1 represents a single sprint, however the # of hours is variable across sprints, duration is fixed, effort
hours are not
• From GAO Agile Guide: “Beware of self-reporting: … velocity is a measure of the rate
at which the team delivers a user story. It is not comparable from team to team, and
should not be used to distinguish one team from another. It is very easy to show an
increase in velocity without adding value to the program by inflating story point
estimates. In other words, increasing velocity does not always indicate a change in
productivity.”1
• To mitigate inconsistencies related to Velocity can use Productivity (in standard
sizing units per person hour) for agile projects
29
1. GAO-20-590G GAO Agile Assessment
Guide, page 106