How mature is your process and how can you make it better?

When developing a software system, every single person or organization must perform the basic steps/stages of software development life cycle. E.g. Requirement Analysis, Requirement specification, Design, Coding... Based on project type, these steps will be followed on any sweet able process model like Waterfall, Iterative, V Model, Spiral, RAD, DSDM, Agile method etc.

Though everyone performing the same high level steps, in root level of these stages, everyone perform in their own way (here the variation happen). For this reason, Performance of process, Quality of product and other software attribute did vary for different person/organization. Like, in Requirement Analysis / Requirement Specification stage, some company collect documents to analyze requirement, some take interview of users and external stakeholders, some do nothing without just talk etc.

Now the question is, the way you are performing these steps, is that good enough for better software? Or if good, how can you make it better (I think in fast growing world, we should not say best)? To improve your process performance, you must measure, where you is now and where you want to go?



To assess your SDLC (Software Development Life Cycle) performance, there are some International standards, frameworks. All these are widely used in all over the world and accepted. Some company apply these standards to prove their quality of work, some company apply these models & frameworks to improve their process performances. Whoever applies for what reason, all they get Return On Investment.

List of some SDLC Standards, Frameworks:

Standards:
· ISO 9001:2000 (Quality Model)

· ISO/IEC 12207 (Standard for Software Life Cycle Process)

· IEEE/EIA 12207 (Standard for Information Technology-Software Life Cycle Processes)

Framework:
· CMMi (Capability Maturity Model Integration) by SEI

· ISO/IEC 15504 also known as SPICE (Software Process Improvement and Capability dEtermination)

Process Model and Missing Functionality

Process Models
During development of Software, we choose any Process Mode or Software Development Life Cycle. More or less, we all know about all common Life cycle models.

For example:

· Waterfall life cycle,

· Incremental Process Model,

· V Model,

· Spiral Model,

· Rapid Application Development (RAD),

· Agile Method etc.


Though they are very differences between all these models, all has some common activities as well. These activities might be presented in different name in different models, but outputs of them are same. Examples of such activity are:
· Requirement Analysis,

· Requirement Specification,

· Design,

· Coding,

· Testing,

· Deployment,

· Maintenance etc.

These all are very important activity in software development. I think I dont need to explain these process models. Because in practical life, there are more process models and you can find a lot of study material to study about these process models.

No mater people do document these phases or not, they go through with these activities. Except these activities, no one can make any software.

Missing Functionality in Process Model
Making something and making something betteris different… Right? To perform on all those phases, there are selected skilled people. But where is the role of Project Manager of Project Management function in the life cycle? YES, he plays his role all over the project, but where is Quality Assurance function? Yes this function also work in everywhere of the function! Like this, Configuration Controller for Configuration Management function, Reviewer for Review Team work all over the project.

List of Missing functions in every Software Development Life Cycle:

· Project Management

· Quality Assurance

· Configuration Management

· Metrics and Measurement Analysis

· Review

Figure: Example of Waterfall with all these functions

All these functions are missing in every process models/ software development life cycle. When these functions will start work actively with traditional SDLC, it’s a guaranty to the better product then before.

This blog's main focus will be on these functions and how to improve the Process Model through several process improvement models e.g. CMMi, ISO 9001.

Software Process and Its Importance in brief

What is Process?
When you work to build a product or system, it’s important to go through a series of predictable steps – a road map that helps you create a timely, high-quality result. The road map that you follow is called a process.

Software Process
The road map or series of predefined steps we use to develop a software system is software process. The Implementation of software process is Software Development Life cycle. E.g. Waterfall, Iterative, V Model, Rapid Application Development (RAD), Dynamic System Development Method (DSDM) etc. This life cycle is called Process Model. [Ref: Chapter 3, SOFTWARE ENGINEERING -A Practitioner’s Approach Sixth Edition by Roger S. Pressman]

No Process followed in the game

Why process in Important
The Quality of a system is highly influenced by the quality of the process used to acquire, develop and maintain it. Software process provides stability, control and organization in development. Otherwise, the development will become chaotic, unmanageable.

Process centric work

Why Focus on Process?
It Complement your focus on Technology:
- Technology, by itself will more likely not be used efficiently
- Technology, in the context of an appropriate process roadmap, can provide the most benefit.

It complements your focus on People:
- The experience and your work force is not always enough
- Working hard is not the answer
- A well defined process can provide the mean to work smarter
- It shifts the “blame” for problem from the people to process.

When you will understand that your process is poor?
Commitment consistently missed
- Late delivery
- Last minute crunches
- Spiraling costs

No management visibility into progress
- You’re always being surprised

Quality Problem
- Too much rework
- Function do not work properly
- Customer complaints after delivery

Poor moral
- People frustrated
- Is anyone in charge?

Software Myths

Software Myths- beliefs about software and the process used to build it - can be traced to the earliest days of computing. Myths have a number of attributes that have made them insidious. For instance, myths appear to be reasonable statements of fact, they have an intuitive feel, and they are often promulgated by experienced practitioners who “know the score”.

Management Myths
Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and improve quality. Like a drowning person who grasps at a straw, a software manager often grasps at belief in a software myth, If the Belief will lessen the pressure.

Myth : We already have a book that’s full of standards and procedures for building software. Won’t that provide my people with everything they need to know?
Reality : The book of standards may very well exist, but is it used?
- Are software practitioners aware of its existence?
- Does it reflect modern software engineering practice?
- Is it complete? Is it adaptable?
- Is it streamlined to improve time to delivery while still maintaining a focus on Quality?
In many cases, the answer to these entire question is no.

Myth : If we get behind schedule, we can add more programmers and catch up (sometimes called the Mongolian horde concept)
Reality : Software development is not a mechanistic process like manufacturing. In the words of Brooks [BRO75]: “Adding people to a late software project makes it later.” At first, this statement may seem counterintuitive. However, as new people are added, people who were working must spend time educating the newcomers, thereby reducing the amount of time spent on productive development effort

Myth : If we decide to outsource the software project to a third party, I can just relax and let that firm build it.
Reality : If an organization does not understand how to manage and control software project internally, it will invariably struggle when it out sources software project.


Customer Myths
A customer who requests computer software may be a person at the next desk, a technical group down the hall, the marketing /sales department, or an outside company that has requested software under contract. In many cases, the customer believes myths about software because software managers and practitioners do little to correct misinformation. Myths led to false expectations and ultimately, dissatisfaction with the developers.

Myth : A general statement of objectives is sufficient to begin writing programs we can fill in details later.
Reality : Although a comprehensive and stable statement of requirements is not always possible, an ambiguous statement of objectives is a recipe for disaster. Unambiguous requirements are developed only through effective and continuous communication between customer and developer.

Myth : Project requirements continually change, but change can be easily accommodated because software is flexible.
Reality : It’s true that software requirement change, but the impact of change varies with the time at which it is introduced. When requirement changes are requested early, cost impact is relatively small. However, as time passes, cost impact grows rapidly – resources have been committed, a design framework has been established, and change can cause upheaval that requires additional resources and major design modification.


Reference
The Artical above is directly taken from the Book "SOFTWARE ENGINEERING - A practitioner's Approach by Rogher S. Pressman" Page: 45-46

Brief Overview of Software Engineering

In this article, we will see a brief overview of Software Engineering; we will try to figure out some misconception related with Software Engineering and Software Engineer e.g. “Who are Software Engineer?”

Let’s First See about Engineering

Engineering is …
The application of scientific principles and methods
To the construction of useful structures & machines

Examples
Mechanical engineering
Civil engineering
Chemical engineering
Electrical engineering
Nuclear engineering
Aeronautical engineering

Software Engineering
The term is 35 years old: NATO Conferences
- Garmisch, Germany, October 7-11, 1968
- Rome, Italy, October 27-31, 1969

The reality is finally beginning to arrive
- Computer science as the scientific basis
- Many aspects have been made systematic
1. Methods/methodologies/techniques
2. Languages
3. Tools
4. Processes

Software Engineering in a Nutshell
Development of software systems, whose size/complexity warrants team(s) of engineers
Multi-person construction of multi-version software [Parnas 1987]

Scope
Study of software process, development principles, techniques, and notations

Goal
Production of quality software, delivered on time, within budget, satisfying customers’ requirements and users’ needs

Software Engineering ≠ (IS NOT) Software Programming

Software programming is
- Single developer
- “Toy” applications
- Short lifespan
- Single or few stakeholders
- Architect = Developer = Manager = Tester = Customer = User
- One-of-a-kind systems
- Built from scratch
- Minimal maintenance

Software Engineering is
- Teams of developers with multiple roles
- Complex systems
- Indefinite lifespan
- Numerous stakeholders
- Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User
- System families
- Reuse to amortize costs
- Maintenance accounts for over 60% of overall development costs