Good Coding Style in PHP + Other languages

while ($x < $z) 
{
	if ($a == 1) 
	{
		echo 'A was equal to 1';
	} 
	else 
	{
		if ($b == 2) 
		{
			//do something
		} 
		else 
		{
			//do something else
		}
	}
}

1.2

while ($x < $z) {
	if ($a == 1) {
		echo 'A was equal to 1';
	} else {
		if ($b == 2) {
			//do something
		} else {
			//do something else
		}
	}
}

while ($x < $z) 
{
	if ($a == 1) 
	{
		echo 'A was equal to 1';
	} 
	else 
	{
		if ($b == 2) 
		{
			//do something
		} 
		else 
		{
			//do something else
		}
	}
}

while ($x < $z) {
	if ($a == 1) {
		echo 'A was equal to 1';
	} else {
		if ($b == 2) {
			//do something
		} else {
			//do something else
		}
	}
}

	$var = myFunction($x, $y);

function myFunction($province, $city = '')
{
	//indent all code inside here
	return $result;
}   

/**
 *	short description of function
 *
 *	Optional more detailed description.
 *
 *	@param $paramName - type - brief purpose
 *	@param ...
 *	...
 *	@return type and description
 */

  <?php

  ?>

  <?

  ?>

	$associative_array['name'];
	$var='My String';
	$var2='Very... long... string... ' . $var . ' ...more string... ';
	$sql="INSERT INTO mytable (field) VALUES ('$var')";

• Class name start with uppercase letter. Each word should start with uppercase letter
• Variable and function name may start with lower case letters. Then each word will start with a capital letter
• give meaningful names to variables and functions
• Do not make them too lengthy. I prefer less than 12-15 character names
• Do not abbreviate words in variable or function names. Use $url or $articleUrl as variable names, not $URL or $articleURL as

Some random information regarding commenting your code

Some random information regarding commenting your code

Is commenting required? or suggested?
Simply yes. Always comment your code.
Note: Commenting is always useful only when it is done right. 
Bad commenting is worse than not commenting.

What should you write in the comment?
--------------------------------------
Write why the section of the code is required.
write-What does the code section do.
Write it in plain english. Don't use any language syntax.
If you do not find what to write...then better check did you understand the requirements of the assignment/section? 
Also check, are you sure your design/logic will work? 
Also, why your design/code will work -- did you really understand. 
Do not write how the code works in comments but write why and what it does.

Why commenting is useful?
-------------------------
Commenting will make your code more readable to others.
Commenting will help others to find out the right section of code to edit/modify. Also, understand the purpose 
of the program as well as sequence of the 

logic.
It will also help you to review/(work on) your own code later
In many or most companies, you will hardly write codes from scratch, you have to work on others' code. So commenting is required.


Random:
--------
Use a clear commenting style - easy to edit
Comment as you go/code - do not leave commenting until the end of writing code
If you are worried that commenting will reduce performance...rather comment and use tools to create release codes without comments
comment above the code -- not at the right
variable declaration may have comment at the right
if you use any special trick that is not ovbious from the code -- write it in comments [a trick:we can do a right shift for divide by 2]

Comments and Pseudocode Programming Practice (PPP)
----------------------------------------------------
Comments and Pseudocode Programming Practice (PPP) go hand in hand.
what is Pseudocode Programming Practice (PPP)?
1. Write your logic in plain english may be as a paragraph
2. Decompose it step by step into as fine grained that it can not be decomposed further. (The paragraph will be converted to lines of steps)
3. comment each line/step (use comment sign like //)
4. After each line/comment write the corresponding code.

Overview on .Net Solution Architecture

Just an overview (Will be updated ...).

• Microsoft Solution Framework is a combination/mix of both Waterfall model and Spiral model. It includes waterfall models milestone based planning and resulting predictability with the spiral model's benefits of feedback and creativity
• Roles in the MSF Team Model:
  • Product Management (Deals with customers, collects customer requirements, ensures requirements are met, plans project communications, and performs related duties)
  • Project Management: Develop processes and deliver solutions
  • Development: Develop the solution
  • Testing:
  • Release Management: Responsible for deployment
  • User Experience: Analyzes performance needs, supports issues of the users
  • Project Sponsor:
  • Customer
  • End user
  • Operations
• Gathering Information: Information Categories: Business, Application, Operations, Technology
• Information Gathering Techniques: Shadowing (Observe the operation, ask questions (how do interruptions affect users?) and collect information), Interviewing, Focus Groups, Surveys, User instruction, Prototyping
• Sources of information:Artifacts (like documents), Systems (set of processes performing an action), People (responsible for different project related tasks)
• Analyzing Information Step: Analyze collected information and create use cases and use case diagrams. Use cases and use scenarios will identify the total/complete system clearly, all processes involved in the system, identify gaps in the information collection, establish connections between business needs and user requirements. Collecting information and Analyzing can be iterative processes
• A use case diagram will contain information like: Requirement ID, Requirement description, Priority, Data Source, current functionalities, questions from this item.
• Several other documents may be created such as: Actors Catalog (For each responsibilities in the system list the actor's/responsible employee's name, and source of information), Business Rules Catalog (may include short title, description of the rule, source of the business rule, reference to the corresponding use case diagram, functionalities related to the business rule)
• UML notations may be used to create the diagrams
• Envisioning Phase: The team, the customer, and the sponsor define the high level business requirements and overall goals of a project. Identify what the project involves, what the customers want to achieve with the project, what is the business need, what must be developed to solve/address the business needs. Make all involved people aware of the project goals and requirements clearly. Form project team
• Output from the Envisioning Phase: Vision/Scope document, Project structure document, Risk assessment document, list of testable features, preliminary requirements and architecture, a GUI storyboard.
• Vision/Scope Document: Problem Statement, Vision Statement, User profiles, Scope of the project, Solution concept, Project Goals (both business and design), Critical success factors, Initial schedule
• Project Structure Document: components of the project structure (team and structure, project estimates, project schedules)
• Contents of the project structure document: Team and customer roles and responsibilities, communication decisions, Logistical decisions, Change management decisions, Progress assessment decisions
• Next three steps: Conceptual Design->Logical Design->Physical Design
• Conceptual Design: Define the problem from the perspective of the user and the business/usage scenarios
• Logical Design: Define the problem from the perspective of the project team/cooperative services
• Physical: Define the problem from the perspective of the developers
• Goals of Conceptual Design: Understand the business problem to be solved, requirements of the business, and target future state of the business.
• Steps in Conceptual Design: Research, Analysis, Optimization
• Build Conceptual Design: analyze information, Restate requirements, categorize requirements, refine use case diagrams, select an application architecture (client/server, layered, Stateless, Cache, Layered-client-cache-stateless-cash-server),
• Logical Design: List candidate tools and technologies, identify business objects and services, identify important attributes and key relationships, optimize logical design (refine, validate)
• Outputs of Logical Design: logical object model, high level user interface design, logical data model
• logical object model - identify all the relevant objects/entities [will be pretty similar to identifying entities to create data model and E-R Diagram]
• In logical design, identifying services are also important
• Physical Design: Defines the parts of the solution, how they will be developed, how the interaction will happen.
• Physical Design: Components, User Interfaces, and Physical Database. Scope: Coding, deployment
• At the end of logical design UML diagrams such as Class Diagram, Sequence Diagrams, Activity diagrams, Component diagrams are available. In physical design refinements of these diagrams occur.
• Physical Design: Define programming model, Specify component interfaces and interactions, Design Physical UI Model, Design Physical Database model
• Designing the Presentation Layer: Functions of the User Interface Components: Acquire data from users, capture events from the users, restrict the types of input a user can enter, perform data entry validation, perform simple mapping and transformation of the user provided information, perform formatting of values
• Well designed interface: Intuitive design, Optimum screen space utilization, appearance, easy of navigation, controlled navigation, populating default value, input validation, menus, toolbars and help, efficient event handling
• Designing the Presentation Layer: Create an initial user interface either by hand or using Visual Basic forms, provide user assistance, use tooltips if appropriate, display status, use wizards if appropriate, provide accessibility aids for disabled people
• Types of user interfaces: Windows based, web-based, mobile device based, documentation based
• Design Data Layer: Typically database objects are modeled in an entity-relationship diagram.
• Data Model Types: Flat file, Hierarchical, Relational, Object oriented
• Optimize data access: Minimize roundtrip requests, minimize returned resultset size, reduce concurrency, find the tradeoffs between managing data on the client or on the server
• Optimize the database: Index data (clustered, non-clustered), Partition data (why and how vertical and horizontal partitioning), Normalize data
• Sometimes Denormalization of database tables is also required for better performance.
• Implement data validation: Check for Data Integrity (Domain, Entity, Referential), Validate Data (Range check, Data format, data type check)
• Think about client side/server side data check. Many times both are required for optimum performance and integrity.
• Design Security Specifications: Common Types of Security Vulnerabilities: Weak passwords, Misconfigured software, Social engineering, Internet connections (through unsecured ports, if firewalls are not configured appropriately), Unencrypted data transfer, Buffer overrun, SQL Injection, Secrets in code.
• Principles for creating Security Strategies: Rely on tested and proven security systems than creating your own, use your own only after expert auditing and reviewed by security organizations, never trust external input, Assume that external systems are not secure, use principle of least privilege, reduce components and data availability, default to a secure mode, follow STRIDE (spoofing identity, tampering, repudiation, information disclosure, denial of service, and elevation of privilege) principles
• How to create a security model: Arrange for a brainstorming meeting, list all possible threats, apply the STRIDE security categories, conduct research, rank the risk of each threat
• Security mitigation techniques: Authentication and authorization, Secure communication, Quality of Service, Throttling, Auditing, filtering, least privilege
• STRIDE mitigation techniques: Authentication, protect secrets, audit trails, do not store secrets, privacy protocols, authorization, hashes, digital signatures, time stamps, filtering, throttling, quality of service, run with least privilege
• .Net security features: type safety verification, code signing (Ensure authenticity, ensure integrity) - digital certificates and signatures, code access security, role based security (make use of windows users and permissions) , saving data in isolated storage
• ASP.net authentication: Forms authentication, Passport authentication, Windows authentication
• Web-services security: transport level, application level, message level

Overview of Project Management

Overview of Project Management[Source Internet]
-----------------------------------------------
What is a project?
A project is an activity that using plans and processes creates a product, a service, or a result. A product is a physical product like a TV, a service is like the Internet, a website; result [analytical model, proof of something] is the knowledge based outcome of a research project. Project is a continuous process that takes an idea/concept, targets an outcome, plans how to get the outcome, uses several processes/activities to gain the outcome. Applies monitoring and controlling to get the desired outcome timely.

Difference between projects and operations?
--------------------------------------------
Operation is not a project, operations are done to keep something/an organization going. For a University, taking classes, conducting researches are operations. For a food shop, selling foods is an operation. But the process to create a University or a food shop is a project. Software development process is mostly project oriented.

Project Phases
--------------------------
A project has some definite phases such as:
Initiating
Planning
executing
Monitoring
closing

Initiate: Start a project
Plan: Plan how to achieve the goal. Plan regarding execution and monitoring.
Execute: Execute the plans to achieve the goal.
Monitor: Monitor the progress of the project. Modify plans and also modify execution.
Close: Close with project when goal is achieved

Project Knowledge Area
------------------------------
Each project needs to use some knowledge and skills to attain it's goals. Projects use processes to get the result. Each process may address one aspect of the project. Each process requires raw input, tool and techniques and produces some output. Each of the processes may require knowledge in one area. Common project knowledge areas are:

1. Project scope management
2. Project time management
3. Project cost management
4. Project human resource management
5. Project procurement management
6. Project risk management
7. Project quality management
8. Project integration management
9. Project communication management

How Projects are affected by the style of the organization
---------------------------------------------------------
1. Functional Organization:
----------------------------
Each functional department is a separate entity. Projects are done usually within a functional unit independent of other units. If the help of other units is required, it is done through the hierarchy of the functional managers. Usually an unit has a manager. Based on the size, each unit may have multiple managers with hierarchy. Such organization may not carry out many projects, project managers may not be so important, project managers may be just part-time with little/no authority.

2. Projected Organization:
--------------------------
Organized around projects. They mostly do projects. Most resources are invested for projects. Here, project managers have the supreme authority and usually are full time.

3. Matrix Organization:
-----------------------
Just a mix of the functional and projected organizations. The matrix may be strong in projected area and weak in functional area or vice versa.

Terms you need to know in Project Management
--------------------------------------------
Project
Organization
Project stakeholder
Process
Knowledge Area
Performing organization
Project management
Program
Program Management
Program Management Office

Project Knowledge Area-Sub Areas
--------------------------------
1. Project scope management

Scope Plan
Scope definition
Work breakdown structure
Scope control
Scope verification

2. Project time management

Activity definition
Activity sequencing
Activity resource estimating
Activity duration
Schedule development
Schedule control

3. Project cost management
Cost estimate
Cost budgeting
Cost control

4. Project human resource management

Planning human resources
Acquiring the project team
Developing the project team
Managing the project team

5. Project procurement management

Manage acquiring products

6. Project risk management

Plan the risk management
Identify the risks
Perform risk analysis
Develop a risk resource plan
Monitor and control risks

7. Project quality management

Quality planning
Quality assurance
Quality control

8. Project integration management

Developing the project management plan
Directing and managing project execution
Monitoring and controlling the project work
closing the project

9. Project communication management

Plan communication
Distribute needed information to the stakeholders
Report project performance and status
Communicate to resolve issues among the stakeholders

Initiate a Project

Initiating Projects
-------------------
How a project starts??
----------------------
Projects are done for one of the following three reasons
Business Requirements: Example: The government requires airline companies to implement safety-management systems. A company needs to find out the success of their ecommerce web-site.

Opportunities:To take advantage of an opportunity like technology breakthrough. Example: many projects may be planned targeting iPhone.

Problem: To reduce/eliminate a problem. Airport x faces 2/3 accidents every year, the airport authority may wish to perform a project to identify causes and develop solutions.

How a project is selected?
Project Selection:
A particular project may have different alternative solutions. A company may have multiple project plans and they need to select one of them.
But How?

1. Scoring Model: Identify some matrix to find which project strategy is better or which project will be more profitable. Assign values for these parameters and select which one provides greater value.

2. Benefit contribution: Use cost benefit analysis, short term and long term cost benefit analysis.

3. Economic models:

Benefit Cost Ratio
Cash Flow
Internal Return Rate
Present Value and Net Present Value
Opportunity Cost
Discounted Cash Flow
Return on Investment


Will a project succeed?
-----------------------
There are many mathematical models to justify/predict the success of a project.
Do we need to consider project stakeholders?
--------------------------------------------
Yes. Because the project may benefit some people and may cause dis-advantages to some people. Project managers need to manage and convince both of the groups.

How a project is formalized?
----------------------------
A project charter is developed to present the business needs and the outcome. It is just a document that is reviewed before (or for) project authorization.

Input to Developing the project Charter
---------------------------------------
Contract
Statement of Work
Enterprise environmental factors
Organizational process assets

Tools for Developing the project Charter
----------------------------------------
Project Selection Methods
Project Management Methodology
Project management information systems
Expert Judgement

Output of Developing the project Charter
----------------------------------------
Project Justification
Project description
Project requirements
Assumptions
High level schedule and milestones
Budget
Proposed project manager

Preliminary Project Scope Statement
-----------------------------------
After a project charter is authorized. A Preliminary Project Scope Statement may need to be developed. It may be discussed with the project stakeholders to facilitate project success.

Input to Developing Project Scope Statement
-------------------------------------------

Similar to the inputs to Developing the project Charter
Tools and Techniques
---------------------
Project Management Methodology
Project Management Information System

Preliminary Project Scope Statement lists:
------------------------------------------
Objectives
The product
Requirements of the product
Project boundaries
Initial work breakdown structure
Schedule
Team
Risks
Cost estimate

Some Topics on Project Communication Management

Some Topics on Project Communication Management

• Project communication can be very tricky and political
  
  
• Deals with Compiling, Sending, Storing, distributing and managing project record
  
  
• Handles four areas:What to communicate, to whom, how often, when
  
  

Professional Responsibilities for Project Managers: A Quick Review

Professional Responsibilities for Project Managers
Simply: Handle any issue directly, ethically, and legally. Be open and upfront. Solve issues quickly, openly,fairly. Be direct to solve an issue rather than ignoring it.

Professional Responsibility deals with:
1. Responsibilities to the profession
2. Responsibilities to the customers and the public

Responsibilities to the profession:
1. Compliance with all organizational rules
2. Advancement of the profession

Responsibilities to the customers and the public:
1. Responsibility to provide accurate and truthful information/representation to the public
2. Maintain and satisfy the responsibilities of professional services
3. Maintain and respect the confidentiality and sensitivity of information
4. Conflict of interest should not affect customers badly
5. Do not take bribes

Professional Responsibility can be categorized in five areas such as:
Integrity and professionalism
Contribute to knowledgebase
Improve individual competence
Balance stakeholders interest
Interact with Team and stakeholders

Integrity and professionalism
shortly:Always do the right thing.
Laws:Comply with all rules. Comply with the rules of the city/state/country where the project is taking place. If the project deals with any other country - it may be needed to comply with the rules of that country[before that knowing the legal rules of the other country is important].
Policies:Comply with organizational policies
Integrity:Stick with high moral principles
Professionalism:
--Processes: Maintain and execute the processes required for the project. PMI suggests 44 processes. Following these processes reduces risk and improves time, cost,efficiency. Carry out the processes required accordingly even the customers want a shortcut way.
--Respect:
show respect to others PMI strongly advocates multiculturalism and encourages to be respectful to other cultures Maintaining confidentiality of client information is also important.

Contribute to knowledgebase
--Share the experince with PMI and with other professionals in the field
--PMI encourages to teach, publish, write, disseminate the PMI aspect of Project Management

Improve individual competence
--PMI encourages all professionals(PMPs) in this field to improve them and to gain more knowledge continuously.
--Know your professional weaknesses and try to improve them

Balance Stakeholder Interests
Interests of stakeholders may collide.
Be fair, open, direct, ethical in solving the conflicts
-Resolve the conflict in favor of the customer interest[benefit]

Interact with Team and stakeholders
--Communication should be open
--Cultural differences should be respected
--Laziness and negligence should not be tolerated

Social-Economic-Environmental-Sustainability
-If a project makes the society suffer, creates an environmental problem, the project manager should disclose the information and should try to avoid such situations. If needed the project manager should resign the project.

Project Human Resource Management

Some topics on Project Human Resource Management that Project Managers Should Understand understand.

Maslow's Hierarchy of Needs: Basic theory of motivation. Five levels of motivation:

Lower needs
1. Physiological - food, clothing, shelter
2. Security - freedom from fear, job protection, safety
3. Acceptance - being a part of the team

Higher Needs
4. Esteem - feeling of importance
5.Self actualization - Live and work with full potential

McGregor's Theory X and Theory Y Applies to management approach
X: People are selfish, unmotivated, dislike work, must be forced to work, constant supervision required

Y: People are naturally motivated to work, team members need very little external supervision required.

Assembly line organizations may benefit from X type of managers.

Contingency Theory:
Managers may be task oriented or relationship oriented. In stressful situations task-oriented managers become more successful. While in calm situations relationship-oriented managers perform better.

Herzberg's Motivation-Hygiene Theory Some factors are not directly motivating but their absence will make some people unsatisfied.

Hygiene Factors:
Supervision
Work Condition
Relationship with co-workers
Paycheck
Company Policy

Motivational Factors:
Achievement
Recognition
Work
Responsibility
Growth

Expectancy Theory: Anticipation of a reward or good outcome is a motivation. But the motivation only works if the target is achievable/practical. If a person is told if he can sale 100,000 in 4 weeks, he will get 10000$ as bonus. The person will feel motivated only if he can think it is possible but if he feels it is impossible, no motivation will be there.

Achievement Theory: People need achievement, power, and affiliation.

achievement: Desire to accomplish something
Power: Desire to influence the behavior of others
Affiliation: Desire to belong to a group

Forms of Power
The project manager may enjoy the following forms of power

Reward: reward a team member
Expert: When the manager is an expert, people will listen to him[best form of power]
Legitimate: Power due to the position.
Referent: Example: A manager very close to the CEO may feel/enjoy higher power than he really has.
Punishment: worst type
Best Form: Reward and Expert

Conflict Resolution:
Methods of Conflict Resolution
Problem-solving: Solve the problem (root cause of the problem)
Compromise
Forcing: never good in the long run
Smoothing:not recommended. Does not solve the issue
Withdrawl: ignore the issue. not a resolution

Constructive Team Roles
Initiators
Information seekers
Information givers: not confidential information
Encouragers:
Clarifiers:
Harmonizers:
Summarizers:
Gate Keepers:

Project Time Management: Part-1

[note: My articles are just a note/reminder to me. I keep them here so that I can refresh my memory whenever required. The artcles may be weak as a writing component. Thanks.]

Project Time Management
Project time management process

1. Define Activities Required
2. Sequence Activities
3. Estimate Resources for the Activities
4. Calculate Duration of the Activities
5. Develop Schedule
6. Control Schedule

Process:
Define Activities Required: List all the activities, functionalities, modules, components you want to develop. When the project scope is defined, use it to decompose the work into activity list. Work breakdown structure will be useful at this stage. List what modules, components the project will handle. List all the functionalities/activities that are required for each of the modules/components. For each activity, define properties, assumptions, quality requirements, and output requirements.

Input: Project scope statement, Work breakdown structure
Output: Project activities [activity list], Activity attributes, milestone list, requested changes

Tools:

Decomposition: Decompose work into smaller activities. Project team or the functional manager may be of good use here.
Templates: The Company may have them, other project may have them, and some standards like IEEE may define some templates
Rolling Wave Planning: Many later aspects of the project may not be understood at the beginning. Hence, initially decompose as much as possible and later with the progress, improve the decomposition
Expert Judgment: Take help of other experts in the field. Project team or the functional manager may be of good use here.

Sequence Activities: Find the order/sequence of the activities. Some activities may be dependent on the completion of another activity. Some modules may be dependent on the completion of another module. Sometimes, it may be the case; some activities/modules are not strictly dependent on another activity but may be preferable to start after another activity/module [Best Practice]. Note: module refers to a complete unit/component where each module may have many activities. In this step, you need to find the sequence and then create a project network diagram.

Input: Mostly from the first step.
Project scope statement,
Activity list,
Activity Attributes
Milestone List
Approved change requests

Tools:

Precedence Diagram Method (PDM): Activities are represented by the nodes where arrows represent the dependencies that exist between the activities.
Arrow Diagramming Method (ADM): Activities are represented using arrows where nodes represent the connection points. We can create dummy activities with dotted arrows [not possible in pdm].
Graphical Evaluative Review Technique (GERT): Like the PDM diagrams. Additionally, you can show dependencies among activities. Also, you can represent repeated processes.
Network Templates: Sub networks of another project in the organization may be useful.
Dependency Determination: like mandatory dependencies [you can not break the dependency], discretionary dependencies [best practices, the dependency is not strict], and external dependencies [out of the scope of the project].
Apply leads and lags:


Output: Project schedule network diagram.

3rd: Then you need to identify the resource requirements of each activity.

4th: Estimate duration for each activity. It may be experience based, practical examples based, another completed project based, mathematical analysis based.

5th: Develop the schedule; Project sequencing and time estimating will directly affect this. Several projects may require the same resource. Hence, the schedule should check when the resource is available and schedule accordingly.

6th: Monitor how the schedule is performing.

Project Schedule Development: Part of Project Time Management

Project Schedule Development

In this phase, project duration, project finish date, schedules of the activities are determined.

Input:

Activity List
Activity Attributes
Project Schedule Network Diagrams
Activity Duration
Activity Resource Requirements
Resource Calendars

Tools:

Critical Path Model (CPM)

CPM is extensively used to determine the project duration. CPM method also helps to identify how much individual activities can slip without affecting the total duration of the project.

Crashing and Fast tracking

Crashing tries to add more resources into the project to ensure that the project will be finished on time or early. [Note: Fred's theory: Adding resources to an already delayed project will/may increase the delay]

Fast tracking tries to run multiple activities in parallel to ensure that the project will be finished on time or early.

Resource Leveling:

Apply the resource availability [and quantity] to the project duration. It may increase the project duration when sufficient resource [in quantity or at the right time] is not available.

Critical Chain Method:

It is almost similar to the Critical Path Method. Critical path method uses a concept called float. CPM first calculates the total duration and then calculates float [how much it can slip] for each activity. CPM ensures that no activity exceeds its float. In Critical Chain Method latest possible start and latest possible finish dates are determined for each activity. Afterwards, buffers are added between activities. The goal is never try to exceed the buffer.

Company Calendar

Company Calendars may be used to check the company holidays, or events that may affect the project duration/schedule.

Adjusting leads and lags.

Using CPM Model [steps]

1. CPM uses the arrow diagram method [activities and duration on arrows, nodes as connectors] to represent project activities and duration.
2. After building the diagram find the critical path [the path that takes the longest time from start to finish considering all alternatives].
3. Calculate float: how much an activity can slip without affecting the critical path.
4. Calculate Early start: The earliest date an activity can start considering the dependencies.
5. Calculate Early finish: Early start date + duration - 1
6. Calculate Late Start: What is the last date an activity can start considering the dependencies
7. Calculate Late Finish: Late start date + duration - 1
8. Calculate Free Float: Amount of time an activity can be delayed without affecting the dependent activities' early start date
9. Calculate Negative Float: Occurs when an activity's start date occurs before a preceding activity's finish date

When you have calculated all the values, the values will help greatly in the schedule control.

Project Quality Management

Project Quality Management

Project Cost Management - Part 1

Some Concepts in Project Cost Management

Costing Involves:
1. cost to purchase, develop i.e. to have the system
2. Operation cost
3. Cost to disposal

Value Engineering:
Get the most from a project
--decrease cost
--increase value
--increase quality
--shorten schedule
--keep project scope not reduced

COST ESTIMATING
When cost estimation is done?
After project scope is defined, and work breakdown structure is created. But may be performed again and again over the total life cycle

Tools
Analogous Estimating
Based on the similar actual projects

Bottom up estimating:
Estimate cost for each activity and sum them - time consuming

Parametric Estimating
1 mile road construction needs $400,000$. So 10 miles will require 10*400,000$.

Reserve Analysis
A buffer cost against slippage on the project

Cost of Quality
Costs required in order to get quality

Output
Activity Cost Estimates

COST BUDGETING
Maps costs and dates. How much will be spent on what and when. Also termed Cost Baseline

When cost budgeting is done?
After activities are defined and scheduled. Activity durations and resource requirements are also estimated.

Tools
Cost Aggregation
Activity level costs should be aggregated to the work level where they will be measured, managed, and controlled.

Reserve Analysis
Financial reserve to protect projects against cost overrun

Parametric Estimating
Use simple straight forward formulas

Funding Limit Reconciliation
Comply with the project funding. many times funds are allocated even before the scope is defined.

Output
Cost Baseline
Project Funding requirements

COST CONTROL
Monitoring, controlling, adjusting costs

When it is performed?
Over the whole life cycle. Bi-weekly or monthly analysis may be done

Tools
Cost Change Control System
How the cost baseline may be changed

Performance Measurement Analysis
Calculate Earned Value, Planned Value, Actual Cost, Estimate to complete, Estimate at Completion, Cost Performance Index and similar to measure performance and control costs based on these

Forecasting
Use current and previous cost values to estimate future costs

Variance Management

Output
Cost Estimate Update
Cost Baseline Update

Performance Measurement Analysis will be discussed later

Project Cost Management - Part 2

Project Cost Management - Part 2

Terms:
Earned Value: The value the spent money brought to the project. Just like double entry accounting system: for every debit to an account there is a corresponding credit.

Budgeted at Completion (BAC): How much was originally planned for this project.

Planned Value (PV): Calculates how much of the project should be complete at a certain date according to the plan. Planned Value = Planned%complete*BAC

Earned Value (EV): How much is actually done during a period. EV=Actual%Complete*BAC

Actual Cost: Money spent over the period

Cost Variance (CV): Difference between planned cost and actual cost. CV = EV - AC

Schedule Variance (SV): Difference between the planned schedule and actual schedule (as:Where the project is in the schedule). SV=EV-PV

Cost Performance Index (CPI): The rate at which the project cost is performing regarding cost expectations. CPI is done for a given period of time. CPI = EV/AC

Cumulative CPI: It's the CPI from the project start time to a particular point in time. CCPI = CEV/CAC

Schedule Performance Index (SPI): The rate at which the project is performing in respect of schedule expectations up to a point in time. SPI=EV/PV

Estimate at Completion (EAC): Forecast the total cost at project completion based on the project performance up to a point in time. EAC = BAC/CCPI

Estimate to Completion (ETC): How much more will be spent to complete the project based on past performance.

Variance at Completion (VAC): Difference between what was budgeted and what will actually be spent. VAC = BAC - EAC

Project managers need to calculate these values to get a good understanding of the project cost. He can get answers to questions like: How much is spent? How much more are required? Is the project progress satisfactory in terms of cost? -- these will ultimately help in project cost control.

Project Risk Management

Project Risk Management
What is risk?
According to PMI, Risk refers to an uncertain event that has positive or negative effects on project objectives.

Risk Management Plan includes:
tools and approaches to be used for

Risk Management
Identification and assignment of resources for risk management
Risk categories
Risk Probabilities and impacts
The format of risk reporting and tracking

Processes of Risk Management:
Risk Identification
Risk Analysis
Risk Response Planning
Risk Monitoring and Control

Risk Identification Process:
Output of the Risk Identification Process:
Risk Register - a list of identified risks
A list of the root causes of the risks
An initial list of potential responses

Risk Analysis
Output of the Risk Identification Process is used as the input.
Qualitative Risk Analysis involves: prioritization of risks based on a probability and impact matrix for each objective

Quantitative Risk Analysis involves:
Assessing the probabilities of meeting each project objective
Prioritization of the risks based on their total effect on the overall project objectives.

Risk Response Plan
Based on the priority for each risk:
Take no action
Take action if some events happen
Take action

Principles: Resources: User Interface Design

• User Interface Design : A Software Engineering Perspective: By Soren Lauesen : (Reading)
• ebook:User Interface Design for programmers:It's not arts, it's a set of rules
• Ten Usability euristics
• First Principles of Interaction/Interface Design
• IBM User Interface Design Guide
• Principles: User Interface Design
• User Interface Design Tips, Techniques, and Principles
• Innovative user interface design
• Good User Interface Design Tips : If you want to whiz off your users

Some User Interface Design Rules

From: http://www.joelonsoftware.com/uibook/chapters/fog0000000060.html

• Many times Activity Based Planning - Activity based user interface design helps
• Invent some users - define some users
• Figure out the important activities
• Figure out the user model -- how the user will expect to accomplish those activities
• Sketch out the first draft of the design
• Iterate over your design again and again, making it easier and easier until it's well within the capabilities of your imaginary users
• Watch real humans trying to use your software. Note the areas where people have trouble, which probably demonstrate areas where the program model isn't matching the user model.
• A user interface is well-designed when the program behaves exactly how the user thought it would.
• If your program model is nontrivial, it's probably not the user model
• Every time you provide an option, you're asking the user to make a decision. Provide options only users care about it
• Use the right metaphor
• Over creativity may be dangerous like try to create fancy looking buttons/controls that confuse users about their functionalities. Consistency is more important.
• User's don't read manuals or texts on the dialog boxes, or anything ... keep it in mind
• Users can't control the mouse very well - so think about the areas where there are more use of mouse -- what are the alternatives - how less mouse movement can provide the functionalities
• Users can't remember anything - provide features so that they do not have to remember - like file browsing option than typing file name

What a software architect do?

Software architecture is about translating business strategies into technical strategies [HP Openview].

The TEC in Architect indicates that software architecture is rooted in technical details. A software architect must be expert in the related technologies like the software design technologies, software development technologies, testing and deployment technologies. Even the software architect may be directly involved in coding. As he/she has to take technical decisions on software development, he needs to know development well. He should be able to solve technical development problems, provide implementation strategies, and high level algorithms to solve problems.

The ARCHI in the Architect indicates he should be able to design/understand/analyze the big picture of the total system. He/she needs to understand the interactions among different system components and what are the must required components and why?. Identify the most important components and how to design/develop what.

Remember, design is also architecture, when you use UML/Visio to create component diagram, class diagram, to show what components/classes the software should implement, and to show interations among components and classes these are also architecture but one step lower. All architecture is design but not all design is architecture.

Software Architect

The Bredemeyer Architect Competency Framework (http://www.bredemeyer.com/pdf_files/ArchitectCompetencyFramework.PDF) covers the following domains of comeptency:

- Technology
- Business strategy
- Organizational Politics
- Consulting
- Leadership

Each area of the Bredemeyer Architect Competency Framework summarizes the architects knowledge (what you know), activities (what you do) and characterisitics (what you are) of the software architect. For illustration, here is an example competency area from the Bredemeyer Framework:

Area: Technology
What You Know?
* Domain and pertinent technologies
* Key technical issues
* Development methods and modeling techniques

What you do?

* Modeling
* Tradeoff analysis
* Prototype/experiment/simulate
* Prepare architectural documents and presentations
* Technology trend analysis/roadmaps
* Take a system viewpoint

What you are?

* Creative
* Investigative
* Practical/pragmatic
* Insightful
* Tolerant of ambiguity,
* Willing to backtrack, seek multiple solutions
* Good at working at an abstract level

Each area of the framework is further elborated, and for more information on the Bredemeyer Architect Competency Framework please see: http://www.bredemeyer.com/Architect/ArchitectSkillsLinks.htm

More information on the Role of the Architect is available at: http://www.bredemeyer.com/who.htm

Software Architecture Resources

• A collection of resources that software architects must read. To become a successful architect, you must go through these resources

Random Information Regarding Software Documentation

Some information will be provided from the book "The Mythical Man - Month" by Frederick P. Brooks - one of the most influential books on Software Engineering

• Documentation is required for 1. Users who will depend on the program 2. Who must adapt a program to make changes
• To use a program: purpose, environment, domain and range, functions realized and algorithms used, input-output formats, operating instructions (including abnormal behaviors), options, running time, accuracy and checking
• According to Frederick, most of this document needs to be drafted before writing the program
• Documentation to believe a program: Provide information on how the program is used, information so that one knows the program really works (provide some small test cases, some through test cases)
• Through test cases: Tests for the main functionalities and commonly encountered data, barely encountered but legitimate cases like: show that the largest or the smallest data also work, barely encountered and illegitimate cases - invalid data causes valid diagnostic messages
• Documentation for the modifier: sub-program structure graph, complete description or references to the algorithms used, layout and explanation of all files, pass (data) structure, modification to the original design and why?
• Flow chart may be used to provide one page structure of the program. Using flow charts to describe all logics and flows is discouraged by Fredrick.
• Self Documenting Programs are encouraged(My concern is: these apply only to program documentation: not to design documentation ): Even the flow chart (sub components) included as comment is encouraged.
• Sometimes the usual practice is to maintain two separate documents for programs - machine readable form of a program, human readable documentation. Fredrick suggests to combine both into one. Combining will reduce the inconsistencies that could have occurred between the program and the document, also will reduce overall keystrokes, will reduce total number of characters to be stored.
• provide meaningful names to labels, declaration, symbolic names
• Use space and format as much as possible to improve readability, show subordination and nesting
• Use paragraphs from the human readable document (if you were creating) as comments. Paragraph commenting is usually better than line by line commenting

Microsoft Solution Framework

Microsoft Solution Framework
What is Microsoft Solution Framework(MSF)? It is just a software development methodology that ensures that all elements(Process, People, and Tools ) of a project are successfully managed. Also, it provides guidelines on planning, designing, developing, and deploying of projects.

MSF Process Models It is just a combination of the waterfall model and spiral model. Watrfall model goes step by step until the finish of the project. It uses milestones as an indicator of progress. Spiral model is an iterative model. Where the development proceeds in small cycles and the steps are repeated. Waterfall model is good for projects with clear requirements and goals. Spiral model is good for projects that are not clearly defined and need repeated feedback and modification. MSF uses the milestone approach from waterfall model and iterative approach from spiral model. MSF defines some milestones(steps), go all the way and again come back like the spiral model to improve and modify.

MSF Milestones

Envisioning
Planning
Developing
Stabilizing
Deploying
MSF Team Model

Team Members:
Product Management: Mainly deals with customers and define project requirements, also ensures customer expectations are met.

Project Management: Maintains project development and delivery to the customer

Development: Develops according to the specifications.

Testing: Tests and assures product quality

Release Management: Ensures smooth deployment and operations of the software

User Experience: Supports issues of the users.

One person may be assigned to perform multiple roles. MSF also has suggestion on how to combine responsibities such as the developer should not be assigned to any other role.

MSF Disciplines 1. MSF risk management process
2. MSF readiness management process

MSF project management process:

Integrate planning and conduct change control
Define and manage the scope of the project
Prepare a budget and manage costs
Prepare and track schedules
Ensure that right resources are allocated to the project
Manage contracts and vendors and procure project resources
Facilitate team and external communications
Facilitate the risk management process
Document and monitor the team's quality management process
How to use Iterations in MSF projects

Creating versioned releases
Creating living documents
Creating periodic builds

For details please check:
http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx

UML Resources

Tools to create UML diagrams from PHP Source
Auto Generate class diagrams from php source

http://www.sparxsystems.com/products/ea_downloads.html
http://uml.sourceforge.net/download.php
http://www.excelsoftware.com/php_models.pdf
http://www.codegeneration.net/generator.php?id=220

UML Theory--You can learn and Design by Hand(or visio/MS-Word)
Short, to the point excellent: http://dn.codegear.com/article/31863
Not Bad but lengthy: http://www.jeckle.de/umllinks.htm#tutorials
Just Ok: http://www.sparxsystems.com.au/UML_Tutorial.htm

Personal Character and Programming

If I worked with a programmer who looked busy all the time, I'd  assume that he was not a good programmer 
because he wasn't using his most valuable tool, his brain. -- Steve Mcconnell


Personal Character and Programming
----------------------------------
For a software engineer the only building material is the human intellect and the primary tool is he himself. 

Character is the more decisive factor than intelligence in the make up of a superior programmer.

The best programmers of the world are the most humble. They realize how small their brain is for programming 
and they agree their limitations.

Being humble gives opportunities to learn more about programming


Human brain is really limited to understand an average program fully. So what better programmers do (adopt better habits) are:

1.  Decompose systems into smaller sub-systems. Write short routines. It reduces load from the brain

2. Good programmers review, inspect, and test their codes/designs to compensate for brain limitations

3. Good programmers follow standard and proven conventions to reduce load from their brain


Ways to be a good programmer:

Curiosity is important

Experiment 

Read about problem solving

Read books and periodicals

Read case studies

Network with other programmers

Adopt good programming habits

Avoid laziness


Experince, persistence, and guts are sometimes hurtful to the programmers 

To be a good programmer developing the right programming habits is the most important strategy

Design in construction

Design in construction
When software development does not go through a detailed design phase, developers require to think the design of the part they are working on and how the design fits together with the other components and the interface of the software. It's always better to think about the design and algorithm before coding it. Also, before compiling, it's always better to mentally check your code that the algorithm is right. Also, you can fix/determine/consider some test data and mentally check that the algorithm is generating the expected output. If not, check your design, algorithm, and code.

When the development method goes through a detailed design phase, while coding as a developer you should be clear of the requirements of the part and the design of the part. Then you should also think if your algorithm/implementation will meet the required functionalities and design requirements. Several industry studies show that 16-19% of the developer errors are due to misinterpretation or the misunderstanding of the design and requirements.

Client Focused Software Development: What does client focused mean? Just the Basic

What is it

Client = end user, purchaser of your product/service, for whom you are developing the software. Client Focused Software Development focuses on client's need, client's business, client's business operations. It tries to develop software that reflect clients' need, ambitions, company image, business profit, operational flexibility/improvement, employee satisfaction, operator satisfaction, cost the right/appropriate budget.

. How to achieve?

• Execute a business/system analysis
• In the business analysis phase, try to understand client's business, what they want from the software, how the software will be used, how the software can provide their expected results.
• In the business analysis phase, visiting clients sites, try to see/watch and analyze the related operations, think and get ideas from them how the software will facilitate the target operation/work.
• Find alternate ideas, consult with clients.
• If possible, be part of their meetings [related]
• Make them part of your software design and business/system analysis and design meetings.
• Discuss with clients about your design
• Get their feedback
• In the ongoing phase, time to time meetings for feedback and idea exchanges may help. Presenting the ongoing software, features, progress, activities may help along with getting and implementing their ambitions/expectations.
• In the testing phase, in the system testing and features testing, clients can be an integral part.
• Close interaction must be maintained with the client in all phases of the project
• All key decisions affecting the output of the project must be made in consultation with the client [ref:Keen et al]
• Arrange training sessions whenever required.
• Treat your clients properly/appropriately
• Implement a feedback system through which you can get feedback in different aspects of your software and about your service. Do what you need to earn excellent (ideally) rating and satisfaction.
• The feedback system may collect feedbacks on [ref: A good introduction]
  • Your understanding of the client’s needs
  • Your quality of advice
  • Your ability to manage work
  • Our value for money
  • Your clients’ overall satisfaction
  • Quality of user interface, interactions with the system/software, easy of interactions, steps to complete [clicks/typing] a work
  • Robustness, failures, confusing behavior, error situations
  • Are all features implemented right?
  • Are all features there?
  • What about efficiency? response time?
  • What about prevention of failures?
  • All results are calculated right

• A good introduction
• A research paper

Software Project Failure

In 1994 Standishgroup (http://standishgroup.com/chaos_resources/chronicles.php), documented billions of dollars wastage in failure software development projects and also examined the reasons. Top two reasons are:

1. Incomplete requirements
2. Lack of user involvement

Software Engineering Certification - CSDP 2008 IEEE

Topics:

• Business Practices and Engineering
• Economics
• Software Requirements
• Software Design
• Software Construction
• Software Testing
• Software Maintenance
• Software Configuration Management
• Software Engineering Management
• Software Engineering Process
• Software Engineering Tools and Methods
• Software Quality

• Software Engineering Code of Ethics and Professional Practice
• Certified Software Development Professional Portal
• Queen's University Resources

Software Engineering Code of Ethics and Professional Practice

Software Engineering Code of Ethics and Professional Practice

Very Small Enterprises (Software) : Software Engineering

Very Small Enterprises (VSE) have significant contribution in software products and service industry. In Europe 85% IT sector companies have only 1 - 10 employees, 78% of Montreal, Canada based companies have < 25 employees, 50% have fewer than 10 [2005], 66% of US companies have 1-10 employees [2002].

Current software engineering standards do not address the needs of these organizations. It is also difficult for VSEs to achieve certifications such as ISO and IEEE and VSEs usually lack the capability to be identified as quality software producers. Most VSEs do not have the resources in terms of number of employees, cost, and time - or see a net benefit in establishing software life cycle processes.

In 2005, WG24 was established to define a software engineering standard for VSEs. WG24 is now justifying the following hypotheses regarding VSEs to find an appropriate standard for them.

• VSEs require light-weight and well-focused life cycle
• It will be different for different business profiles
• Standards should be significantly different as VSEs lack resources
• VSEs are limited in both time and resources that lead them to a lack of understanding how to use standards for benefits

Initially, WG24 is analyzing Moprosoft, a Mexican standard based on ISO standard for small and medium enterprises to achieve their objective

Improve your status from "good developer" to "great developer"!

Check this article: Improve your status from "good developer" to "great developer"!

Why things go wrong?

What are the problems?
End user's perspective

• Many projects just not get finished
• The system works but it's dreadful to use
• The system looks pretty but does not do all the work

• Many projects (50% approx., Standishgroup, 1994, 2001) exceed the budget
• Many projects are delivered late -- may be of no use at the time of completion
• The deployment was a mess, caused some major disaster in operation - the staffs do not trust the system
• Some stakeholders may try to prevent the success of a project for some benefit
• The business, the requirements have changed over the period - a completely new system is required now

• Developers feel they built what was wanted; the clients or the end users still are not happy; the clients/end user's may have changed their minds in the meantime or they did not understand the developers' specification; or there were misunderstandings in the beginning about requirements
• Pressure from different sources may limit developers' ability to produce an excellent system. Pressure: Budget, time limit, see the result
• The developers may be inexperienced with the particular techniques they must use - still they are highly skilled and basically talented
• No documentation, explanation on the existing work. Not well written code - developers may have much difficulty to understand them before able to modify.
• The goals may be impossible to implement. Developers may have warned...but nobody listened..so the project failed.
• Many developers may feel -- 'The system is fine .. the users are the problem' - without being prepared to examine critically their own preconceptions

• Poor interface design
• Inappropriate data entry
• Incomprehensible error messages
• Unhelpful help
• Poor response times
• Unreliability in operation

• The wrong problem is addressed - system conflicts with business strategy
• Wider/Long term/future influences/consequences are ignored
• Incorrect analysis, design, and implementation [method/strategy]
• Project was initiated with wrong reason - going online without analyzing the benefit - just to follow the trend

• Users have changed their minds
• External factors like a new legislation have changed the environment
• Implementation infeasible
• Poor project control like having inexperienced project managers

• Illogical screen layout: Wasted time, loss of confidence in the system
• Difficult to read screens: increased frustration, increased sickness
• Unhelpful help messages: increased error rate, increased absenteeism, greater staff turnover
• System response is slow:increased operating costs
• Lost data: extra work, reduced income
• Inaccurate outputs: extra work checking outputs, loss of customer confidence, lost sales

Unified Software Development Process

• Wikipedia: Unified Process
• USDP: Presentation
• IBM Rational Unified Process

Some random information on Software Engineering

• User involvement througout the project may reduce the chance of failure
• DSDM - directly involves users in the development team
• Selecting the right user/person, defining the role of the user, using different individuals rather than a particular person - may increase the chance of success. Some thought is needed to make better use of user involvement.
• Computer Aided Software Engineering (CASE) tools may reduce total duration and increase efficiency.
• CASE can be used in the analysis, design, and automatic code generation
• Principles of Agile approaches: Individuals and Interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan

How to become a Software Architect

It is not a seriously thought article. I just wrote this to a response in a forum to answer a question. Just again providing it in my web-site.

I have put my 2 cents at: http://www.justetc.net/knowledge/displayArticle.php?table=Articles&articleID=695 and http://www.justetc.net/knowledge/displayArticle.php?table=Articles&articleID=692

You should be good in technical aspects, should be able to code excellently, understand code excellently, analyze systems both business systems and computer systems, should be able to identify major architecture frameworks like RUP, MSF, Agile, and be able to use them effectively, under stand business, how business runs, business analysis, project management, software documentation, software design documentation and code documentation, also be expert in software release technologies. Need to have an understanding of different software platforms and what is going on around to utilize the best approach for your software. Organizational skills and time-management skills are definite assets. Should be able to analyze different software solutions also.

Should be excellent in communications: understanding others and be capable to explain your ideas. Be able to motivate, and teach. There are many other qualities that you need to be master at to be an effective software architect. It also depends on your area of interest.

What books should every software developer have?

• Linked in Answers: What books should every software developer have?

Introduction to software version control

Version control software are used to maintain and create different versions of the same software. It allows parallel software development and facilitates collaboration and team based software development. In addition, it provides features so that integration among different people's work can be made. Also, tracking back to an early stage of the software becomes possible.

Why do software companies need it? Let you may develop a software and release it. Then you may still want to keep the same version along with improving it. You want a new improved version for future release. You may want further improvements, hence further versions. Also, in internal development, several programmer may collaborate to work on different/same parts in parallel. Then they can merge them to a merged and stable/workable/reliable stage. They can create a version of the software at this moment. If any crap happens, they can come back to this stable version and continue improving/re-developing.

Among the version control software some popular ones are CVS,Subversion,Visual Source Safe, and Starteam. I personally have some working experience with starteam and subversion. In subversion, there is a repository of codes. Subversion is totally file system and directory based. Repository needs to be well designed. It may contain all projects in one folder or all projects in separate folder. Both has advantages and disadvantages. A good approach may be using them in mix. Keep similar projects in one folder and create separate folders for non-similar projects. As there are some administrative tasks that can be applied to the root folder/a folder thats why grouping may be need as project requirements may be different. It also affects the version number, usually version number is increased by the base/root folder. Still the increase may be because of another project.

A project usually contains two folders. Trunc folder is the main development folder. Branch folder is the new version/working folder.Each programmer usually creates his own copy of the branch and work on the copy. Sometimes, programmers merge their changes and keep it to the branch. While anyone wants to save his work to the branch, it will display the changes made to the same file by other programmers. Then he/she can decide how to integrate all changes into the file. The branch changes may be transferred to the main trunc folder to create a new version of the software.

Quick reference to sub version's repository administration commands

Sub version administration related commands

• svnlook:to examine various revisions and transactions in a repository. No change is made by this command. Just analyze near to commit or committed changes.
• svnadmin:
• ls repos: check sub version repository
• svnadmin create "path to repository"
• svnadmin create --fs-type fsfs /path/to/repos: creates repository that uses FSFS file system
• svnadmin create --fs-type bdb /path/to/repos : creates repository that uses BDB in the backend
• ls repos/hooks/: This displays the hooks for the repository. Hooks are scripts that run in different repository events. You can write or use third party hooks as well
• svnadmin help: provides information on how to use svnadmin command
• svnadmin --version
• Available subcommands of svnadmin: crashtest, create,deltify
• svnlook info /path/to/repos:
• svnlook info /path/to/repos -r 19
• svnlook youngest /path/to/repos: younest revision number
• svnsync: Creates read only mirror of the sub version repository
• svnsync:subcommands:synchronize (sync),copy-revprops,help (?, h)
• svnadmin setlog myrepos newlog.txt -r 388 :
• svnadmin lstxns myrepos:outlisted transactions
• svnadmin rmtxns myrepos `svnadmin lstxns myrepos`
• svnadmin list-unused-dblogs /path/to/repos: display unused log files
• svnadmin list-unused-dblogs /path/to/repos | xargs rm: restore disk space from unused log files
• svnadmin recover /path/to/repos : BDB repository recover
• svnadmin dump myrepos > dumpfile: dump svn repository
• svnadmin load newrepos < dumpfile :effectively replays those dumped revisions into the target repository for that operation
• svnadmin create newrepos
  $ svnadmin dump myrepos | svnadmin load newrepos
• svnadmin hotcopy /path/to/repos /path/to/repos-backup:backup repository
• $ svnadmin hotcopy --clean-logs /path/to/bdb-repos /path/to/bdb-repos-backup

Sub version repository strategies

You may create three folders: trunk, branch, tags. Trunk->main development, bracnch->to create various named brances of the main trunc, tags->collection of free snapshots that are created and destroyed

Subversion repository may make use of backend database like berkeley DB or it can just use a file system like FSFS

Little note on CVS

CVS Version Control System:

• There will be a repository where the files(of different versions) will be saved. Its just like a central storage of files. You will need a software that will provide this facility.
• You also need a client software. The client software can get copies of the repository files. After, modifying clients can update/save to the repository. While saving from clients steps are needed so that version control is maintained [no inconsistency arises].
• Linux has command based clients, also there are CVs servers for linux. Download them from the internet.
• I have some experience of using WinCVS - a windows based CVS client.
• In WinCVS, You can set command line parameters using Admin->commandline parameters option. You have to provide some information like: CVS server, repository path, username, password.
• In WinCVS, you can checkout files from the CVS server using the checkout option from the menu (tools). You need to specify local path to store the files. Also, you need to mention some information like the previous step (or you can copy a string from the previous step and provide here):