History of Software Configuration Management (SCM)

Software Configuration Management (SCM), simply put, involves everything related to management of evolving Software Projects’ Code. Software Configuration Management is today a mature software engineering discipline and essential part of every software development team, just like Quality Assurance. Let’s take a quick trip through evolution of SCM to understand why it was needed at first place.

History of Software Configuration Management (SCM)

The need for formalizing and taking SCM seriously, arose when rightly named “Software Crisis” was identified back in late 70s and early 80s. It was realized that mere software programming is not everything in Software Engineering (SE). There were other serious issues that were hindering software development including architecture of the software, source integration from multiple developers, building projects, incorporating ongoing changes and so on.

In late 70s and early 80s, Software development started taking first steps towards programming large software solutions. Thus very first concerns of SCM were versioning of incrementing software, rebuilding and managing composition of complex systems.

The first SCM systems of early 80s were developed in house and their primary focus was on file control. Most of them were built as a set of Unix scripts over RCS (a simple version control tool) and Make (for derived object control).

Some other worth mentioning tools of that period are; DSEE, the only serious commercial product, which introduced the system model concept which was an Architecture Description Language ancestor; NSE, which introduced workspace and cooperative work control; Adele, which introduced a specialized product model with automatic configuration building, and Aides de Camp (now TRUE software) which introduced the change set.

In early 90s, as software and hardware industry matured, software vendors became capable of developing many projects simultaneously. Thus SCM in that era addressed issues around process support for developing multiple projects at a time, and concurrent engineering.

The first real SCM products appeared in the early 90s. These systems were much better. They often used a relational database but still relied on file control, they provided workspace support, but no or built-in process support. This generation included Clear Case (DSEE successor) which introduced the virtual file system and Continues which introduced, with Adele, explicit process support. Continues and Clear Case are currently the market leaders.

In late 90s, with the advent of web, remote programming became viable thus gave rise to issues pertaining to management of code submitted by remote teams. SCM in that period expanded its scope to support programming in the web.

During this period process support was added and most products matured. This period saw the sanctification of SCM, as a mature, reliable and essential technology for successful software development; the SCM market was over $1 billion sales in 1998. Many observers consider SCM as one of the very few Software Engineering successes.

Post 2000 period brought further optimizations and innovations in the working of SCM systems and also brought new SCM solutions like Subversion with improved memory utilization, atomic commits and much more. Another relatively new but innovative entry in SCM domain is Git. Git introduced the innovation of treating every clone as a full-fledged repository with complete history and full revision tracking capabilities.

Securing your Cookies from naughty ones!

When you were a kid, you tried your best to always secure your cookies, if you are a web application developer, you have to do the same today as well.

In web application context, Cookies are another form of information that is being generated by the web application, consumed by the client, and submitted back to the application server. Thus vulnerable to malicious activity and very critical for web application security.

There are two approaches that we should adapt for cookies security. First we should set cookies settings so that they are less vulnerable and secondly we should implement cookies consumption so that they pose no threat to our overall system.

Cookie Settings:

Following guidelines should be followed while setting cookie attributes.

Secure – Whenever a cookie contains sensitive information or is a session token, then it should always be passed using an encrypted tunnel and secure attribute should be set.

HttpOnly – This attribute should always be set so that cookie cannot be accessed via a client side script such as JavaScript, and prevent Cross Site Scripting Attacks.

Domain – Make sure Domain has not been set too loosely.

Path – Make sure cookies path has not been set too loosely.

Expires – If this attribute is set too far in future, then make sure it does not contain any sensitive information. Better yet do not set this attribute so that cookie can be deleted from cookies cache when the current session ends.

Cookies Implementation:

Following guidelines should be followed while implementing cookies in order to secure web application.

    1. The session tokens (Cookie, SessionID or Hidden Field) should be random, unique, resistant to statistical and cryptographic analysis and do not promote information leakage, when large number of cookies are analyzed.

    2. Cookies should be formed so that memory overflow is not allowed.

    3. Cookie operations should not take place over unencrypted transport.

    4. Cookies should not be able to be forced over unencrypted transport, if it is allowed then these cookies should be made secure.

    5. Persistent cookies should be avoided, if not then they should be secure.

    6. Transient cookies should be configured properly.

    7. HTTP/1.1 /1.0 Cache-Control settings should be set properly to protect Cookies.

    8. It is suggested to use multiple cookies to make analysis difficult and avoid Brute Force Attacks.

    9. If somehow we can hide process of creation/modification of cookies (on pages), that would improve security.

    10. Issue a generic value for session id in cookie and reference real data at the server side, this will make analysis of session cookies difficult.

Hope you’ll be able to keep your cookies safe from other naughty kids around.

What is Story Size Estimation for a Sprint?

For software development teams it is a common mistake to over commit or under commit the amount of functionality to be delivered with new iteration. When over committing is dangerous for the development team and their motivation levels, under committing is harmful for the buyer and his bank account.

Agile methodologies provide a way to estimate what amount of work should be committed before every iteration, which is termed as Story Points Estimation. What is Story Point Estimation ? please read on

Agile, Scrum and Sprints
Scrum is one of the widely used Agile Methodologies. In Scrum we do incremental and iterative development and these iterations are termed as Sprints. These Sprints are usually time boxed to 2-4 weeks.

Before each Sprint starts, team decides which functionality or user stories (a software system feature specified by the customer) will be incorporated and developed during this Sprint. For this decision to make, they must estimate size of each story and make sure they will only commit to that number of stories which they can deliver complete at the end of current sprint.

The Problem
However, conventional method of story sizing or estimation, based on detailed functional requirements is not possible in agile software development process. Because with Agile, we do not have detailed requirements when we are at planning stage for a sprint, for this very reason detailed planning is moved back in the process as much as possible.
Also, incorporating change, being the top priority as per Agile definition, our stories remain very high level, and we add functional details in them as we move them from the scrum backlog to development process, where they are divided by a developer into tasks.

Thus sizing these User Stories, without much insight of functional details, requires an specialized sizing and estimation process beyond conventional estimation techniques in which project managers dig deep into requirements and come-up with their near to actual time estimates.

Size vs Duration
Scrum development process inventors have come up with a creative idea of dealing with this problem. They have divided Time estimation of a project in two parts, Size and Context.

Let’s look at it as: Time = Size x Context. Thus for story sizing process in sprints we focus on the Size only (because Context is never completely known), However Context is being discussed only, and Time is calculated by someone who is actually going to do the job later when user stories are assigned to developers.

Let’s take an example to understand the difference more.

Example: Let’s say that one programmer can develop a story in two weeks. Same story can be developed by two programmers in only one week.

Notice that Time of completion of this story is decreased, in Context of how many developers are working on it. However the Size (Complexity) of the story remains the same in both situations.

Sizing this Complexity is called Story Point Estimation.

Story Points
For this story size estimation, we use Story Points. Story points are just numbers attached to individual stories that represent estimate of Size only of a User Story. We do discuss Context while sizing, but we don’t try to come-up with resulting time required.

In other words Story Points are a measurement of complexity and/or size of a requirement as compared to the Duration to complete that requirement.

Agile vs Waterfall Methodology
Understanding Point based system is a paradigm shift, because previously we are trained by development processes like waterfall, to come up with a detailed project plan in number of weeks and days. However we should not forget that in agile project we don’t have detailed requirements at the time of story size estimation stage.

Point-based estimation methodology is a step away from answering “how long will it take” to address the more critical first question of “how big is the job”, because agile story points do not relate to time but only to the absolute size of a user story. Story Points have nothing to do with who is implementing it and how long it’s going to take.

Point Scale
The Scale selected for assigning Points to each story can vary from team to team. Some teams use Fibonacci series as their scale for estimation method, others may come up with relatively simple scale e.g.

0, 1, 3, 5, 8, 13, 21, 40, 75, 100, Infinity

Difference between two points in our scale should be relative (0, 1, 3, 5 .. ) rather than absolute (1, 2, 3, 4, ..). Absolute scales will again force us to go into functional details for the estimation, before choosing between the two consecutive sizes.

Also Scale should have enough points to easily estimate User Stories of varying complexities.

Why Use Story Points
You might be asking yourself, ok Story Estimation is the only way to Size the stories in Agile, but why would I use this technique? What’s in it for me? Actually everything, if you are a project manager or if you are the one to come-up with an insight into how much time is left before project completion.

With Story points you will have a better idea of how many points your team can complete within one sprint, thus simple calculations of remaining Story Points in backlog divided by Points completed in one sprint will give you the number of sprints project will take. From Number of sprints you can comfortably get number of weeks required, by simple multiplication with size of your sprint.

In this post we only looked at what is Story Point Estimation, what a Story Point Scale looks like and potential benefits of Story Points Estimation technique. Assigning Points to User Stories by agile teams is a technique in itself and out of scope of this tutorial.

Hello world!

Hey Everyone,

Just launching this blog to share whatever i believe can be helpful to others in their life.

Thanks to WordPress for enabling me quickly setting it up and migrating my posts from previous site in no time, Great experience indeed.

I would encourage everyone out there to go ahead with WordPress and launch your own platform to share the jewels of experience you have gathered in your life so far.

Salman Awan