Actual Important Info

Question 1

Project Properties

Answer 1

Consists of some non-routine tasks (Can’t be done mechanically)
Involves novel approaches/techniques.
Needs a degree of planning
Work involve is phased
Milestones, deliverables and timescales set throughout
Work is commissioned (money and deliverables involved)
Amalgamates various specialities and cultural backgrounds (At least 2 different skill sets involved)
Work resources are pre-defined (Not unlimited resources)
Work involved is large scale and/or of high sophistication.

Question 2

Resources can be used

Answer 2

efficiently or improperly which will impact the quality of the project Every project needs human and non-human resources.

Question 3

Software Projects vs Other Projects

Answer 3

Progress not always visible (especially in non-tangible algorithms)
Abstraction is central (product of intelligence)
Software costs are more complex than traditional ones
Deals in subjectivity/opinions
Contends with conflicting or ill-formed requirements
Always expected to accommodate physical components of a system

Question 4

Manageable components of the system

Answer 4

feasibility study, plan, project execution. If manager doesn’t put in enough effort then the project will take more effort.

Question 5

Management Responsibilities

Answer 5

Planning
Scheduling
Monitoring
Directing
Controlling
Organizing
Staffing
Innovating
Representing

Question 6

Project Planning

Answer 6

Scope
Project Estimates
Resource Management
Risk Analysis
Scheduling Issues
Staff Organization

Question 7

Other Project Plans

Answer 7

Quality
Configuration Management
Staff Development
Exception
Maintenance

Question 8

Quality Planning

Answer 8

Reference to Industry wide standards such as ISO9000 series.
Management Tasks and responsibilities
Transparency
Staff-Oriented
Communication Framework
Risk Management
Inbuilt Checking Structure
Documentation Issues
Development tools and methods
Testing Issues

Question 9

Project Planning Techniques

Answer 9

Options Analysis (Goal Aspect): Weighing various goals against each other (maybe conflicting)

Risk Management (Problem Probability Aspect): Determining, Analyzing, Planning for, and controlling unwanted events.

Milestone Setting (Product Aspect): Determination and setting of meta-deliverables.

Scheduling (Activity/Timing Aspect): Setting conditions for task activation and termination.

Question 10

Risk Dissection

Answer 10

Risk Identification: Define the risk
Probability of Risk: Subjective but can be based on experience
Severity: Should be clearly discernible and prognostic
Manageable and Mitigatable: To what extent is it controllable

Question 11

Software Project Risk Types

Answer 11

The product (ex. Requirements): such as wrong use of modelling tools
The project (ex. Staff): Changes in management, staff, or hardware resources
The business (Ex. Technology Shifts)
The project and product (Fluctuation of requirements, results in project being longer).

Question 12

Time and Cost Overrun Risks

Answer 12

When a software project overruns planned delivery time and budget, this can be traced back to one of the following reasons:
Estimation Inaccuracies
Planning assumptions
Unforeseen events

Question 13

Typical Project Planning Misjudgements

Answer 13

Over-optimistic schedule: results from expecting more from resources
Stakeholder unavailability
Resource unavailability
Weak monitoring
Taking a ‘for obvious’ stance to expertise
Letting personal views affect objectivity
Staff Augmentation (especially on late projects)

Question 14

Sources of Software Project Risks

Answer 14

Generic: Applicable and common to all types of software projects but might provide different levels of accuracy across projects of different types
Specific: Applicable to specific types of projects, but require closer involvement by project team members.

Question 15

Main Risks to be considered

Answer 15

Nature of the application being built
Staff morale, skills, experience, motivation and availability
Project culture and methods/procedures
Hardware and Platform requirements
Implementation and changeover issues
Third party dependency
Real world requirement shift

Question 16

Traditional SE risks

Answer 16

Personnel Shortfalls
Unrealistic schedules and budgets
Developing the wrong software functions
Developing the wrong UI
Gold Plating
Continuing stream of requirements
Shortfalls in externally furnished components and tasks
Real time performance shortfalls
Straining computer science capabilities

Question 17

Risk Exposure

Answer 17

Risk Impact x Risk Probability

Question 18

Risk Reduction leverage

Answer 18

measure of the balance between perceived benefits of reducing a risk and the cost of doing so, called risk reduction cost, is called the risk reduction leverage.
RRL = (RE before - RE after)/RRC

Question 19

Risk Control and Mitigation Techniques

Answer 19

Hazard Prevention: Removal or rendering to insignificance the possibility of particular hazards arising
Likelihood reduction: Taking every precaution to ensure that the chance of a negative event happening is the least possible
Risk avoidance: Taking measures to ensure that the risk is not encountered in the first place
Risk transfer: The movement of a particular risk factor to other (non-project entities)
Contingency Planning: What to do when the unavoidable happens.

Question 20

Three pillars of Taylorism

Answer 20

1. Find best practice wherever it is: Determining procedures and techniques that yield desirable quality, allows one to identify, draw parallels and apply. Replicate processes which lead to good quality output.
2. Breakdown task into its constituent elements: The basis of any analytic activity is better understanding. Analysis is used to explain what we are trying to build.
3. Remove things that don’t add value to the process or product: keep only justifiable overheads. Streamline process to remove deadweight. Maybe resources need to be upgraded or changed.

Question 21

The Taylorist Approach

Answer 21

Select: Delegate appropriate people to appropriate activities. Wrong selection can be long lasting and devastating

Instruct: Teach people the best methods of going about their activities and keep them happy so they can do their job well.

Motivate: Pay the hardest working people more. Motivation is subjective, understand what motivates each person in the team, time helps you to understand to motivate.

Question 22

Theory X and Theory Y

Answer 22

X - people dont want to work
Y - people do want to work, want responsibility, dont need to be monitored

Question 23

Determine the Organizational Culture (Accepted goals, procedures, tools etc.) by asking

Answer 23

What development procedures and standards are generally used.

What is understood by a successful project.

What levels of confidence exist (towards management/tools/methods/deadlines)

How are projects viewed generally by software engineers.

Question 24

Determine the Individual Culture (Background, habits, desires, motivators, expectations) by asking

Answer 24

What is the person’s formal educational background (long term view on people)

What’s the person’s job (Short term view on people)

What’s the person’s age (younger people may be more creative or suit coding better)

What is their character/habits/expectations (everyone’s character is different, it is their input and output. Habits can be something like needing other’s opinions before finishing code. Everyone has personal expectations or wishes and how they would ideally like to work. If you don’t get this information you could fail to integrate the person by plugging them in wrongly, keep in mind when onboarding. Once you hire you are stuck with the person).

Question 25

Emergent Cultural Roles

Answer 25

Leader; many think they are, not giving orders by motivating, organizing, representing etc. Drive needed to be a good leader. Has to have good ability. Listener; Listens a lot, takes a step back to work, doesn’t announce themselves. Talker; Could say a lot of things but some might be useful Complainer; Plays the role of the difficult customer, drives quality in product Naysayer; Need this person to create a good evaluation of what you’re trying to build, try to find problems where there are no problems. Expert; The person who always has something to contribute. It could even be things unrelated. Good to start discussions, good for creativity. Charger; The person who would keep people going on something (motivator) Plodder; Doesn’t complain, given tasks and sets the pace for the project, might bring others down to reality if they are exploring other things.

Question 26

Typical Software Engineering Project Roles

Answer 26

- Requirements Engineer - Systems Analyst - Lead Designer - Designer - Coder - Tools Experts - Quality Assurance Liaison

Question 27

Professional Trends

Answer 27

Task Oriented (Motivated by work, Technically strong, not motivated with easy work.) Interaction Oriented (Influenced by colleagues, good team player, transparent in work. Support from friends/colleagues adds quality.) Self Oriented (Motivated by personal achievement. More flexible and manageable. Motivated by results)

Question 28

The Recruitment Process

Answer 28

Generally done at organization level not team or project level Can offer sparse choice, so if you can’t find the ideal qualities in a person you may be looking too specific or not offering enough money. Can be of a ‘pre-decided’ nature, meaning the recruitment process is open for everyone but catered to a specific person Can be transitory, hiring someone yourself but for a different project, might not put in enough effort in recruitment Can be deceptive. Especially if the recruiter isn’t careful (applicant lies on CV) Can be unfair. If recruiters aren’t versed in the subject matter, people might not have the competence to ascertain the characteristics of people being recruited.

Question 29

Factors influencing recruitment process

Answer 29

Actual knowledge/skills Formal qualifications Impressive CVs Listed experience Wide spread of posts held References

Question 30

Factors NOT influencing

Answer 30

Race, Gender Social Status Generation issues Personal Prejudices Physical Disability (NOT Mental disabilities) Hearsay or rumors Appearance and Mannerisms (However for some roles this could be an issue)

Question 31

Structuring Recruitment

Answer 31

Create Job Specification (Carry out internal mental tasks and makes sure you know what tasks you’re recruiting for. Does prefiltering for applicants) Create Virtual Profile of ideal candidate (Easier to compare against something) Prepare realistic and descriptive public announcement Get the list of applicants (Shortlists effort, given a picture of what you will face in the selection process. Makes selection easier) Examine applicant’s CVs (Understand nature and capabilities of applicants) Hold interviews (In person to pick up body language) Follow up of references to make sure they are truthful Inform of final decision, or short-list applicants and hold a second interview session. Formulate letter/s of acceptance Meet, introduce and induce the new person. Structure of support. Can range from introducing them to the team to a whole induction program.

Question 32

Staff can be

Answer 32

Good and improvable. Focus on fostering growth and upskilling. Mentor and train in areas they lack or where they want to get better. Provide constant feedback. Already there. Can still be managed, and can share knowledge with the former. Encourage lateral development to deepen expertise.

Question 33

Making Good People Better

Answer 33

Make people think of professional self-betterment as one of the project aims. Helps them to feel accomplished when enhancing their skill. Allow people to set their own improvement goals (SMART Goals - Specific, Measurable, Achievable, Relevant, Time-Bound). Ask people to manage their own time to foster ownership and efficiency. Determine and distinguish between temporary short term and longer-reaching long term staff professional development goals Monitor and assess the process and product not the people. Don’t delve into micromanagement but evaluate outcomes and methods. Measure progress through tools like code reviews. Conduct without interfering Make use of you knowledge not your position Act as a conduit for your people’s effort not as an obstacle or critical filter. Fabricate open channels for ideas without being a bottleneck. Enable team efforts with goals. Forget trapping/managerial authority and concentrate on project and people needs Be there for your people without seeming intrusive.

Question 34

Attributes of a good manager

Answer 34

Confidence in yourself and your people. Based on trust not control. Build an environment where people feel empowered to act. Don’t allow personal relationships to interfere with work relationships. Maintain boundaries to avoid favoritism. Admit that you too can make mistakes and prepare for them to be corrected through people’s scrutiny. Mistakes are learning opportunities. Be punctual and people will follow Set positive examples, Act as a role model and how you expect the team to behave. Know your people and tap up all their talents

Question 35

Managing people in software engineering is

Answer 35

- Managing group effort and individual cultural attributes. Group work drives results, individuals drive innovation. Diversity is good for problem solving. - Careful management of highly motivated, intelligent and responsible people. Challenge team with intellectual work and opportunities to innovate. - Managing your people’s professional development. Offer learning opportunities which are aligned with project or organization goals. - Setting the right examples and standards, and elevating project and team needs above everything else. Benchmarks like adhering to coding standards or effective communication can be used.

Question 36

Aspects of building & managing a group

Answer 36

Individual characteristics of group members. Recognize strengths and weaknesses. Group cohesion. Team building activities foster trust and communication Group communication. Use structured communication methods. Encourage asynchronous updates to accommodate different work styles. Group organization. Choose org model based on preference and standards.

Question 37

Cohesive Groups Advantages

Answer 37

Collective standard can be cultivated Sense of loyalty Foster project/procedure continuity Team members tend to help each other A collective body of experience can be formed Personal egos less likely to surface Communication comes naturally

Question 38

Cohesive Groups Disadvantages

Answer 38

Foster a relatively strong resistance to changes in leadership Allow the buildup of ‘groupthink’ May induce a sense of rejection or resistance to new members

Question 39

Typical Time Allocation for SE dev

Answer 39

Individual Work 20%: Most of the productive effort Non-Productive Effort 20%: Usually meetings and repetitive tasks Interacting 60%: Critical for agile processes, standups, retro etc.

Question 40

Factors influencing Internal Team communication

Answer 40

Procedures and standards currently in place. Clear documented processes enhance clarity and reduce friction. Size of the team. Communication may be better in smaller teams. Structure of the team. Larger teams need hierarchical structure Gender composition of the team. Foster inclusivity Work environment. Comfortable spaces drives interaction Management disposition and attention. Ensures issues are addressed quickly Personal individual characters and habits

Question 41

Types of team structures

Answer 41

Chief Programmer Democratic Matrix Hybrid

Question 42

The Matrix Approach Advantages

Answer 42

Efficient resource utilization Flexibility in team assignments Enhanced skill development Cross-functional collaboration

Question 43

The Matrix Approach Disadvantages

Answer 43

Conflicting priorities Complex communication channels & Decision making challenges Role ambiguity

Question 44

Types of matrix structures

Answer 44

Weak Matrix (Functional Managers have Authority, Project Managers coordinate and may have limited decision making power) Balanced Matrix (Equal power, decisions need collaboration, balance between project and departmental goals) Strong Matrix (Project managers hold more authority, driving project goals, while functional managers provide support. Project-oriented)

Question 45

Matrix approach can work well when

Answer 45

Projects require diverse expertise across different technical areas Teams need to adapt quickly to shifting priorities or new project requirements Organizations operate in a dynamically environment where resource sharing ensures optimal efficiency.

Question 46

Hybrid (Modern) Approach

Answer 46

Team Leader: Responsible for technical aspects Attends all code reviews Acts as a guide rather than an authoritarian figure. Team Manager: Responsible for non-technical aspects (budget, performance..) Does not attend code reviews, but assesses performance periodically Avoids micro-managing technical decisions, empowering team lead and devs.

Question 47

Hybrid (Modern) Approach Advantages

Answer 47

Specialized roles and clear responsibilities. People can focus on their strengths. Efficient collaboration. Leader bridges gap between technical execution and project goals. Managers ensure smooth operation without interfering technically. Adaptability. Can evolve with project.

Question 48

Hybrid (Modern) Approach Disadvantages

Answer 48

Coordination Requirements. Effective collaboration between team leader and manager is crucial. Miscommunication disrupts workflows. Balancing authority. Maintain clarity in hierarchy to prevent conflicts from technical and managerial roles.

Question 49

Six Basic Group Evolution Cycles Life Stages

Answer 49

Formative: people trying to form relationships/ideas. Effort on meeting people, not so productive in this stage. Cohesive group decreases this stage. The more multicultural a group is the longer this lasts. Hectic (aka Storming): Points and views put forward. Team slightly more productive than before. Team becomes a bit more cohesive Normative: Team reaches a stage where they all agree on processes, norms and behaviours. Align on how the work will be done and establish expectations. Productive (aka performing): Group working efficiently towards its goals, roles and responsibilities are clear and everyone is contributing to team. Group achieves highest level of productivity here. Communication flows smoothly and team is focused on delivering the outcomes effectively and efficiently. Introspective: Looking back at effort made, evaluation and review on improvements Wind Up (Adjournment): Dismantling of team or assigning team to another project.

Question 50

Uses of Measurement

Answer 50

Helps us understand: makes the current activity visible, measures established guidelines ex. Finding number of bugs helps us understand code quality Allows us control: Predict outcomes and change processes, this helps with risk estimation and risk management and to keep projects on track. Encourages us to improve: when we hold out product up to some form of measure we can establish quality targets and aim to improve.

Question 51

Levels of Measurement

Answer 51

Nominal Scale; by identifier ex. British, South African Ordinal Scale; Ranking and category ex. 1st, 2nd Interval Scale: Relative position on a scale ex. League table Ratio Scale: Relative to an absolute value on an interval scale ex. Probability of failure.

Question 52

Measure

Answer 52

An appraisal or ascertainment by comparing to a standard ex. Body Temperature

Question 53

Metric

Answer 53

A quantitative measure of the degree to which an element corresponds to a given value (2 errors in 18 months rather than 2 errors)

Question 54

Indicator

Answer 54

A device, variable or metric that can indicate whether a particular state or goal has been achieved. Usually used ot draw someone’s attention to something (Red light)

Question 55

Examples of measurements in SE

Answer 55

LOC Number of reported errors Number of person days required Gunning Fog Index of a manual

Question 56

The Three Ps

Answer 56

Product: Software being delivered, should be high quality Process: methods and workflows used during dev, optimize for efficiency People: Individuals involved in the project, whose productivity and skills should be measured to ensure the team is working effectively.

Question 57

A software project is made up of all 3 Ps, measurement:

Answer 57

Is integral for QA Important aspect of planning Doesn’t take into account other system components Has no fixed SDLC positioning (Can happen in and dev phase) Is a refinable effort (can be recalculated at various levels of abstraction) Mainly but not exclusively targets estimation

Question 58

The relationship between external and internal metrics

Answer 58

F(ex) = m1c1 + m2c2 + … + mncn Where: F(ex) is a meaningful value of an external factor; Mi is a constant representing the relative importance of internal attribute i (the weighting) Ci is the value of internal attribute i.

Question 59

Measureable Internal Quality Factors

Answer 59

Access Audit: ease at which s/w and data can be checked for compliance. Accessibility of datasets we are building software on. Access Control: Provision for control and protection of s/w and data. Make sure unauthorized users are restricted and data is safeguarded. Completeness: degree to which full implementation of required functionality is achieved. Consistency: uniform design and implementation techniques in a project. Generality: breadth of possible applications of the component Operability: ease of operation of software. Good UI, automated backups… Simplicity: Ease with which the software can be understood. Traceability: ability to link software components to requirements. Clear relationship between what’s been built and why it was built. Training: The ease with which new users can be made to use the system.

Question 60

Most common estimation points

Answer 60

Cost: Monetary value required to complete project, including expenses for staff Effort: Time, energy and resources needed to accomplish project task.

Question 61

Cost to Estimate

Answer 61

Software Dev (High Priority): coding, testing, integration, debugging. Usually largest cost. Can include tools/licenses/cloud services… Hardware Usage: Cost of purchasing or leasing hardware needed for dev or deployment. Servers, network equipment, storage… Development Staff: salaries, benefits and costs associated with team Support Staff: Administrative or technical support teams Premises, communication and services: Office spaces, internet, electricity… Training: Cost for upskilling the dev team, training new hires or teaching s/w to users. Travel: In person meetings, stakeholder workshops or training sessions

Question 62

Software Dev Cost Estimation Approaches

Answer 62

Expert Judgement: Relies on experience and intuition. Can be quick but prone to bias, lack of consistency and may not be scalable. Analogy: Use past projects as a baseline Algorithmic Cost Modelling: Empirical formulas relate s/w metrics like size or complexity to cost. Parkinson’s Law Pricing to win (Unethical)

Question 63

Types of estimation techniques

Answer 63

Top down estimates: High level breakdown of costs, starting from overall goals and dividing into components, fast but less detailed. Bottom up estimates: builds estimates by aggregating costs for individual components or tasks, more accurate but time intensive.

Question 64

Function Points

Answer 64

Elaboration on object points. Measure intended to gauge functionality rather than size or components They are more relevant to user needs (Externally visible) Require good insight into the system to be accurate They are quite a popular measurement basis.

Question 65

Basic Concepts of Function Points

Answer 65

FP are an attribute of a system based on its internal functions FP are sometimes preferred to LOC as a base measure Closer to user perspective of system (function size rather than coding size) LOC can be misleading when language generations are crossed

Question 66

5-type categorization each function would fit in

Answer 66

External Inputs - Distinct data used by the system External Outputs - ex. Reports, normal/error messages Enquiries - Interactive inputs, combination of input and output. System requires by force an output for an input. External Files - Files shared with other systems interacting with yours. Internal Files - Files not visible outside the system. Database used within the system or for the system you are building ex. Customer order file.

Question 67

Benefits of FP Analysis

Answer 67

Technological Independence: Calculates system’s functional size independent of underlying technology. Technology-neutral metric to compare projects. Better Accurate Project Estimation: helps improve accuracy by measuring functional needs and user interactions. Improve planning and budgeting with FPA. Improved Interaction: provides common language to communicate between stakeholders for both technical and non technical audiences. Making well-informed decisions: FPA assists in making well informed decisions at every stage of the SDLC. Use FPA to make decision on resources, tech etc. Early recognition of changes in scope: Early detection of changes in scope is made easier with help of FPA. Possible to evaluate additions/changes for effect on project’s overall size.

Question 68

Disadvantages of FP Analysis

Answer 68

Subjective Judgement: Dependent on subjective judgement (personal interpretations) Low Accuracy: Low evaluation accuracy as it’s dependent on subjective judgement Time Consuming: FPA is time consuming, mainly during initial implementation stages Steep Learning Curve: Learning FPA can be challenging due to its complexity. Less Research Data: Compared to LOC based metrics, relatively less research data on FP Costly: Need for thorough analysis and evaluation can result in increased project timelines and associated costs.

Question 69

Statistical Quality Assurance

Answer 69

Quantitative way to qualitative evaluation, Main steps: 1. Collect and categorize data on software defects 2. Define underlying causes of defects ex. Non-conformance to specs, design etc. 3. Use pareto principle to condense the vital defects 4. Implement corrective measures on causes; once identified move to correct problems

Question 70

Causes of Software Defects

Answer 70

Incomplete or Erroneous Specification (IES): Someone hasn’t properly understood the requirements. Misinterpretation of customer communication: Might be a miscommunication in the way the customer explained or the way you understood requirements Intentional Deviation from specifications Violation of programming standards: ex. Breaking naming conventions Error in data representation (EDR): Most systems will handle a lot of info, and will only be as good as the info handled. Inconsistent Module Interface: Inconsistency always linked to misunderstandings or causing things to be missed. Moving between interfaces will be easy if not may be a source of errors. Error in Design Logic (EDL): Wrong modelling, disjointness between plans and models. Incomplete or Erroneous Testing Incomplete or Inaccurate documentation Programming language Translation of design errors (PLT) Ambiguous or inconsistent HCI Miscellaneous (Form catch-all)

Question 71

Prevent Incomplete or Erroneous Specification

Answer 71

Improve specification techniques, new methods, upgrade personnel etc. Mitigate this by improving specification techniques and teaching people how to model from a functional POV. Model functions and how data is processed, and the control aspects of the system.

Question 72

Prevent Error in data representation

Answer 72

Adopt automated design tools, stringent data modelling and reviews. Data should be a representation of real world. Can fix with tools which flags missing info. AI can help in modern tools and approaches. Make sure people share what they build/intend to build to let groups know what is expected from them in terms of data.

Question 73

Prevent Programming language Translation of design errors

Answer 73

More visibility, check design phase output, enforce strict translation techniques. Explain what you code to mitigate this. Cover all design basics. Stick to standards in programming, have an interface with clear indication of parameters.

Question 74

Prevent Error in Design Logic

Answer 74

Reinforce good requirements understanding, ensure personnel quality, adopt widespread design techniques etc.

Question 75

COCOMO 1 Levels

Answer 75

Basic: Depends on project type Intermediate: Introduces refining factors based on 4 project related aspects Detailed: Uses changing refining factors depending on the stage of development as well as system structural modularity.

Question 76

An estimation of crude effort, Boehm’s project class types:

Answer 76

Organic: Familiar, has been done before, ex. Making the same type of software Semi-detached: Contains some novelty, could be familiar but added complexity Embedded: Part of a highly sophisticated system. You can expect systems that would include a degree of trial and error.

Question 77

Intermediate COCOMO-1 Four attributes introduced:

Answer 77

Product attributes: Determined by the type of software in development Computer attributes: Determined by the type of hardware on which the developed software is to run. Personnel attributes: Determined by expertise and skill of developers Project attributes: Determine by project wide tools, techniques and schedules.

Question 78

COCOMO 2 differences:

Answer 78

Higher abstraction (moves away from KDSI) Uses object points and FP instead of KDSI Considers CASE (Computer aided SE) tool usage, reuse practices and iterative dev

Question 79

Stages of COCOMO 2

Answer 79

Early prototyping: Initial development stages when the system is not tied to any particular development paradigm. Early Design: Initial system structuring stages when system starts to assume basic issues about the way it will be written. Includes further refinement using 7 composite cost drivers. Post architecture: Deals with the actual system code using KDSI as in COCOMO 1.

Question 80

Error Index

Answer 80

The error index is an arbitrary value by which to quantify the quality, in terms of eros in code of SD. The EI is determined for a product as a whole and derived from an error index at every phase of development known as Phase Index (PI). See number of errors per dev/team, errors by functionality etc.

Question 81

Defect Amplification

Answer 81

This is when a defect in development is not detected and such amplifies its negative effect on the product in subsequent phases.