Keywords Flashcards
Devil’s/iron triangle/triple constraints
Ensure that software is delivered
- On time
- Within budget
- In accordance with the requirements (scope)
(Quality could be added)
They are connected to each other: More requirements = more time needed = more budget needed
Agile manifesto
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Why is developing IT for government hard? (Elias Committee)
- National government is not ‘in control’ regarding ICT projects
- Politicians do not realize, but ICT is everywhere
o Almost all solutions require ICT, but they don’t plan for it - National government does not fulfill her ICT policy objectives
- The accountability and decision making structure is deficient
o Difficult who made what decision at what timepoint. There should be an additional oversight (ICT chamber), projects are killed by this oversight board - Government has insufficient insight in costs and benefits of ICT
o Very difficult and complex - ICT knowledge of the national government is lacking
o Some specialists, but they are typically rare or hired (consultancy firms). So the governments themselves don’t actually learn - ICT project management is weak
- ICT bid-for-tender procedures contain perverse incentives
o Most of the times the lowest cost wins the tender, which could make it less quality/ambitions. Then it has to be made bigger during the project - Management of contracts in ICT-projects is not professional
o The negotiation and checking of the other party complies to the contract isn’t done very well - National government lacks the necessary learning ability
o Not learning from mistakes. Can be done by installing an expertise center for ICT (the same as you have Rijkswaterstaat who is dedicated to the traffic/infrastructure)
There is no strong dialogue between the government and the (software) outside parties. Agile does try to enhance communication
Recommendations:
- 2. Demonstrate added value of project for end users and for society
o Not always clear (what’s in it for the stakeholders?)
- 3. Create support among all parties involved, including end-users, and test for organizational (does in fit the governance structure?), administrational (does it fit the administry?) and technical (does it connect to existing systems?) feasibility
- 10. Make use of a transparent bid-for-tender strategy in the business justification of a project, Project Initiation Document (PID): provides the foundation for the business project
o Make functional specification compulsory, or explain why not. Specific technical details are left to the provider
What are the characteristics of the Waterfall method?
Analysis - Design - Implement - Test - Adoption - Maintenance and Usage
- Hardly any company uses this anymore. Originated in the military to plan large logistics operations.
- Output of one phase flows in to the next phase.
- Managers like this because it is clear where you can draw the line/where it begins and ends. They can create results/milestones
- It has clear boundaries and deliverables
- Implement: Coding by a programmer
- Adoption: Testing is the last phase a developer will do. Then it will go into the organization who wants the software. Adoption is quite a long stage. Even if the software is good, it could not satisfy the needs of the client
What are the characteristics of the SDLC method?
System Analysis - Conceptual Design - Physical Design - Implementation and Conversion - Operation and Maintenance
- Iterative process
- There are a lot of libraries with software, you can probably pick some parts of those out for your own software, instead of starting from scratch
- Implement: Showing it to end-users, training them and conversion of data from old to new software
- 3 things in the middle (Feasability analysis, decision making, (re)planning): These have to be done in every step in the process
What are the characteristics of the Spiral model? (Boehm, 1998)
Analysis - Design - Implementation - Testing
- Sort of an Agile process. But these steps are normally longer (6 months)
- Iterative: timebox periods
o Set a time limit for a circle. So you will focus on the important things because you have to deliver something after 6 months e.g. Because most of the times the project will keep going on and on until time is up/deadline
- Risk management: drives decision making –> Risk considerations shape the (type of) process/model
- Various cycles: learn and improve
- Importance of validation and testing
- Concept of operation: Has to be validated by experts before being able to get to the next phase
What are the principles of Agile (Agile Manifesto)
Software development is a social process (focus on people)
- Satisfy customer
- Welcome change in requirements
- Deliver frequently
- Business and developers work together
- Facilitate motivated people to do their jobs
- Face-to-face communication
- Working software is the measure for progress
- Attention to technical excellence
• Make sure you can retain (technical) specialists by rewarding, providing interesting projects etc. - Simplicity
• Break things up in small parts that can be solved one by one - Self-organizing teams
• Help each other, no need for external managers, Agile specialist is part of the team - Teams evaluate, learn and adjust
• At the end of every sprint and in larger timeframes
What are the principles of Scrum?
- Split a project into brief manageable ‘sprints’ (2-4 weeks) –> facilitated by scrum master
- Utilize teams better
• They only focus on the sprint, after that they can go back to their department and do some studying for instance - Development and test
- Handle changes in requirements
- Product backlog: Large pool of things to be done, ordered by priority by the user
- Sprint backlog: What you want to do in this sprint. Teams normally know how much work to take into the sprint
- Iteration: Make the previous product better
- Testing: New thing integrated and is tested
- Daily stand-up: Should be very short (10-20 min)
- Potentially Shippable Product Increment: Improvement on the previous product. It is shippable because it is tested after every sprint
What are the principles of Extreme Programming (XP)?
Coding - Testing - Listening (what the customer really wants, but also observing the customer) - Designing
- Embrace Change: describe what the program should do in terms of user stories
- Pair programming: work together in pairs (better quality); no owner of code (If you write code, everyone else is able to finish it. Very clear variable names, comments etc. to make sure everyone understands it
- Test-First programming: first write test (define how the code should be working), then develop code, and then run test
- Continuous integration: code changes are tested when they are added to a larger code base
Work Breakdown Structure (WBS)
- Goal tree: when all leaves fulfilled, goal fulfilled
- For each goal, which activities need to be done.
- For each goal, when is it considered ‘ready’.
What are the principles of PRINCE2?
Generic project management methodolgy with 8 process groups and 45 separate subprocesses
- Starting up a project
- Planning
- Initiating a project
- Directing a project
- Controlling a stage
- Managing product delivery
- Managing stage boundaries
- Closing a project
What are the 6 crucial practices leaders should adopt if they want to capitalize on agile’s potential? (Rigby, Sutherland & Takeuchi, 2016)
- Learn how agile really works
- Understand where agile does or does not work
- Start small and let the word spread
- Allow “master” teams to customize their practices
- Practice agile at the top
- Destroy the barriers to agile behaviors
What is the main message of the article: No silver bullet? (Brooks, 1987)
- “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”
- “But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order- of-magnitude improvement in productivity, in reliability, in simplicity.
Initial sketch
Communication between the developer, commissioner/sponsor and end user
A mock-up that is used as an early agreement
Use Case Diagram (UML)
Can help in the early stages to systematically record the (hidden) system requirements by writing down “use cases”: ways of using the system. It declares what and not how
- Primary actors
- Secondary actors
- Goals
- Context
- Precondition
- Success
- Failure
Purpose:
- Generate new requirements as the design takes shape
- Communicate with stakeholders
- Generate test cases
Functional requirements
Actions the system should perform (if I press this button, this should happen). Can be assigned to individual components of the system
Non-functional requirements
General properties the system should have (performance, security, reliability, usability, scalability, integrity etc.). Applies to the system as a whole
Design as a dialogue
- Principal (customer) and agent (developer)
- Developer knows the domain, but doesn’t know the customer needs
- Customer has needs, but doesn’t know what system they want
- Interpretation, negotiation, rapid prototyping, iterative, trying out real versions of the product, solving problems together
Requirements and design/configuration collaboration
Requirements are satisfied by components; components trigger new requirements; repeat until stable and feasible Requirement: Fast computer Component: Intel Core i7 Requirement: Cooling Component: Fan
Configuration: Problem closed, principles known, parts standard
Design: Problem open, principles unknown, parts to be developed
What are the 4 inherent properties/nature of software problems? (Brooks, 1987)
Complexity:
- Function of number of components/types of components/attributes/relations
- Function points are used for predicting effort, duration and errors
- Essence (inherent to the nature) and accidents (we have created –> bureaucracy etc.)
- Difficulty of communicating, enumerating and unreliability
Conformance:
- No universal standards/laws of nature
- Software has to conform to external expectations and norms, which differ between contexts
Changeability:
- Software can and must be changed, even after production (updates)
- New uses of existing software, software survives beyond the machine for which it is written
- There is always change, software should follow (VAT changes)
Invisibility:
- Software is abstract, not embedded in time and space
- Not one natural representation of structure, but several (data, process)
How can the nature of software problems be addressed? (Brooks, 1987)
- Remove accidental difficulties (make it easier for the developer)
- Address conceptual essence: buy vs build, requirements refinement, great designers
- Agile: remove accidenetal difficulties and address inherent complexity
How to address complexity? (Boehm, 1988)
Little by little
Iterative development
- Early results
- Feedback
- Learn and improve
Loosely coupled architecture
- Less dependencies
- Local decision making in clusters
Centralize
- From O(n2) to O(n) connections (less dependencies)
Standardization
- System of systems
- Interoperability
Re-use
- Buy vs build
- Libraries; task models; domain models
- Organizational learning
Brooks law
Adding manpower to a late software project makes it later
- New members need to learn, as software projects are complex. This takes existing resources away from development
- Draws communication overhead (number and variety of communication channels)
Requirements engineering
Has the task to align the needs and environment with the requirements specification
discipline to “capture, share, represent, analyze, negotiate, and prioritize requirements as a basis for design decisions and interventions” (Jarke et al, 2011)
Verification: Test if the system was built right (according to requirements) –> code walkthrough
Validation: Test if the right system was built (according to stakeholder needs and environment) –> experiments, inverviews, acceptance tests
What are the 4 requirement principles that will underlie successful design and RE in the “brave” new world of requirements? (Jarke et al, 2011)
Intertwine requirements and contexts
- Organizational and business context
Evolve design and ecologies
- See design (processes) as evolving elements in an ecology
Manage through architectures
- Consider them as enablers and constraints in the continuous creation and shaping of design ecologies
Recognize complexity
- It demands new ways to approach design problems and manage requirements
These exhibit a high degree of causality and work in a causal loop
Business case
- Must provide management with the information needed to make an informed decision whether a project should receive funding, or go to the next phase
- Is complete (all benefits, costs and risks), systematic and objective (judge/evaluate all projects the same way)
- Made by cross-functional team (all departments) for credibility, alignment and access to real costs
Measurable Organizational Value (MOV)
Scope, Schedule, Budget, Quality
1. Identify area of impact (which departments is mostly affected by this project?)
2. Identify organizational value (better, faster, cheaper, more)
3. Develop appropriate metric
(money, %change, counts)
4. Set a time frame to achieve MOV
5. Verify and get agreement from stakeholders (on basis of the MOV)
6. Summarize MOV clearly and concisely
Organization Vision and Mission, Organization Strategy and Project’s measurable value should be connected to each other
Payback (period)
Investment/cash flow = amount of month or years.
Cash flow = Benefits - Costs in a period
100.000 / 20.000 = 5 years
Ignores the time value of money and is used as yardstick
Break even point
Investment/net profit margin = number/price amount
Fixed costs: 100.000
Variable costs: 25
Sales price: 30
100.000 / (30-25) = 20.000 units to break even
Return On Investment (ROI)
((expected benefits - expected costs)/expected costs) x 100%
((115.000 - 100.000) / 100.000) x 100% = 15%
Net Present Value (NPV)
Acounts for the time value of money by a discount.
NPV > 0: return from a project exceeds the cost of capital
- initial investment + (for n, t = 1) ((benefits(t) - costs(t))/(1+r)^t)
r = discount rate t = time period
Total cost of ownership
- Direct or up-front costs: purchase price of hardware, software, and telecommunications equipment, all development or installation costs, outside consultant fees, etc.
- Ongoing costs: Support, salaries, training, upgrades, supplies, maintenance, etc.
- Indirect costs: Initial loss of productivity, time lost by users when system is down, cost of auditing, quality assurance, and postimplementation reviews.
Total benefits of ownership
- Increasing high-value work: value-added to the customer (see Lean)
- Improving accuracy: reducing errors, duplication, rework
- Improving efficiency: reducing effort, duration or number of steps
- Improving decision making: providing timely and accurate information.
- Improving customer service: new products or services, faster or more reliable service, …
Intangible benefits
- More long-term and fundamental elements of an organization. You can’t see the direct benefit in dollars profit from it
- Some benefits are hard to estimate, because they are hard to quantify (measure).
- Some benefits are hard to estimate, because they only affect the business indirectly.
Examples: Improved data quality, better decisions, improved customer satisfaction, easier to innovate.
Intangible, but not unmeasurable
You can relate intangibles to tangibles, to make them measurable
Tangible = directly affects the firm’s profitability
Decision theory and scenario planning
Used to compare alternatives (business cases) based on conditions and weights
Feasability (4 types)
- Economic: business case, budget
- Technical: availability of data, interoperability, maintainability, complexity
- Organizational/social: support, expertise, adoption among end users, HR
- Other: legal, logistics, planning, …
Risk
Likelihood (0-1) x impact (monetary value/cost of the risk)
- Identification: what are the risks? (people risk, overrun)
- Assessment: how large is the risk? (often H, M, L or expected monetary value (likelihood x losses x duration)
- Response: avoid (stopping project), accept (prepare by having a financial buffer), transfer (insurance), mitigate (lower likelihood and/or impact, having a plan B), escalate
5 sources of risks in projects
- Market risk: Is the product useful, will it be accepted?
- Financial risk: Will the project meet NPV, ROI and payback estimates?
- Technology risk: Is it technically feasible, will it function properly?
- People risk: Appropriate skills to complete the project, management support?
- Structure/process risk: What degree of change will occur, with many systems does it need to interact?
Considering risk, how do you determine the best project?
Add up the positive and negative Estimated Monetary Value (EMV) (probability x money)
The project with the highest EMV is the best
Hidden costs and why do they remain hidden?
- Known costs, but budgeted too low (bad estimate)
- Unknown costs, not budgeted
Remain hidden because:
- Incentive to boost benefits and hide costs (to gain advantage over other projects)
- Indirect costs are really unknown (complexity, involvement of compliance personnel)
Portfolio management
- Portfolio of projects with varying levels of risk, technology, size and purpose in order to meet organizational objectives
- Prioritize: top projects for which there is funding get selected
Scope grope, creep and leap
- Grope: inability to define the project’s scope
- Creep: tendency to increase features
- Leap: fundamental change in project scope (loss of previous investments)
6 types of Development Cost Estimation
- Guestimating: guessing based on estimates (earlier/similar projects
o estimates often unreliable (underestimate, buffers) - Delphi technique: multiple experts arrive at consensus (G DSS)
- Time boxing: focus on only the most important features (Scrum)
- Top-down estimating: how long it should take, should cost (budgeting)….
- Bottom-up estimating: based on experience of PM and teams
- Planning Poker: reliable estimates; support; collaboration
o Players: people who actually do the work (local expertise)
o Deck of cards (cost estimates): 0, ½, 1, 2, 3, 5, 8, 13 … (fibonacci, subjective judgement)
o Feature list: what needs to be delivered (user stories) –> people talking about requirements, how complex/large is it to build?
o After all questions are answered, each player makes ‘bid’ (story points)
o Motivate scores; discuss; –> new estimate
Software metrics
- Lines of code (LOC) –> time –> developer salary cost.
Doesn’t show how complex the lines are - Function points: amount of functionality (based on requirements)
Difference between complex and complicated
Complicated implies being difficult to understand but with time and effort, ultimately knowable. Complex, on the other hand, describes the interactions between a number of entities (mathematical)
Function points
- Ordinal measure (can be put on a scale, similar to km or hours) of size and complexity of a software product
- Compositionality: break systems into smaller components, so they can be better understood and analyzed. [but: architecture, security ]. You can calculate the total as the sum of the function points of the smaller components
- Provide an objective measure for evaluation, planning, management and control of software production
There are five standard functions:
- Data Functions:
o Internal logical files (ILF)
o External interface files (EIF)
- Transactional Functions:
o External Inputs (EI)
o External Outputs (EO)
o External Inquiries (EQ)
Estimate complexity:
- low, average, high
COCOMO
- Interactive cost estimation software packages (DSS) that models the cost, effort and schedule for a new software development activity
- Can be used on new systems and on upgrades
- Works less for Agile and more modern projects
- Empirical model (no underlying cognitive theory on why software is difficult)
COCOMO-II
Basic model: rough estimates of project cost, performance and schedule
Intermediate model (used most often) - Uses Effort Adjustment Factor (EAF) based on cost drivers (lines of code/FP are multiplied by this EAF)
Detailed model
- Uses different effort multipliers for each phase of project
The more complex the model, and the more factors that influence a software project are accounted for, and the more accurate the cost estimate will be. (You don’t want to spend too much time on a project that you are likely not going to do anyway)
Internal Rate of Return (IRR)
Aims to find the discount rate that would equate the present value of estimated cash outflows with the present value of inflows. If this rate is greater than the required rate of return, the project may be accepted
