Actual Important Info Flashcards
Project Properties
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.
Resources can be used
efficiently or improperly which will impact the quality of the project Every project needs human and non-human resources.
Software Projects vs Other Projects
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
Manageable components of the system
feasibility study, plan, project execution. If manager doesn’t put in enough effort then the project will take more effort.
Management Responsibilities
Planning
Scheduling
Monitoring
Directing
Controlling
Organizing
Staffing
Innovating
Representing
Project Planning
Scope
Project Estimates
Resource Management
Risk Analysis
Scheduling Issues
Staff Organization
Other Project Plans
Quality
Configuration Management
Staff Development
Exception
Maintenance
Quality Planning
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
Project Planning Techniques
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.
Risk Dissection
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
Software Project Risk Types
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).
Time and Cost Overrun Risks
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
Typical Project Planning Misjudgements
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)
Sources of Software Project Risks
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.
Main Risks to be considered
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
Traditional SE risks
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
Risk Exposure
Risk Impact x Risk Probability
Risk Reduction leverage
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
Risk Control and Mitigation Techniques
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.
Three pillars of Taylorism
- 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.
- 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.
- 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.
The Taylorist Approach
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.
Theory X and Theory Y
X - people dont want to work
Y - people do want to work, want responsibility, dont need to be monitored
Determine the Organizational Culture (Accepted goals, procedures, tools etc.) by asking
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.
Determine the Individual Culture (Background, habits, desires, motivators, expectations) by asking
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).
Emergent Cultural Roles
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.
Typical Software Engineering Project Roles
- Requirements Engineer
- Systems Analyst
- Lead Designer
- Designer
- Coder
- Tools Experts
- Quality Assurance Liaison
Professional Trends
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)
The Recruitment Process
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.
Factors influencing recruitment process
Actual knowledge/skills
Formal qualifications
Impressive CVs
Listed experience
Wide spread of posts held
References
Factors NOT influencing
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)
Structuring Recruitment
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.
Staff can be
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.
