Preparatory Module 0: IT Industry Fundamentals for Business Analysts (Applicable for those who do not belong to IT industry)

Section 1 : Software Development Life Cycle

Software engineering is an engineering branch associated with development of software product using well-defined scientific principles, methods and procedures. The outcome of software engineering is an efficient and reliable software product.

Definitions

IEEE defines software engineering as:

(1) The application of a systematic,disciplined,quantifiable approach to the development,operation and maintenance of software; that is, the application of engineering to software.

(2) The study of approaches as in the above statement.

Fritz Bauer, a German computer scientist, defines software engineering as:

Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and work efficiently on real machines.

Software Evolution

The process of developing a software product using software engineering principles and methods is referred to as software evolution. This includes the initial development of software and its maintenance and updates, till desired software product is developed, which satisfies the expected requirements.

Evolution starts from the requirement gathering process. After which developers create a prototype of the intended software and show it to the users to get their feedback at the early stage of software product development. The users suggest changes, on which several consecutive updates and maintenance keep on changing too. This process changes to the original software, till the desired software is accomplished.

Even after the user has desired software in hand, the advancing technology and the changing requirements force the software product to change accordingly. Re-creating software from scratch and to go one-on-one with requirement is not feasible. The only feasible and economical solution is to update the existing software so that it matches the latest requirements.

Software Evolution Laws

Lehman has given laws for software evolution. He divided the software into three different categories:

• S-type (static-type) - This is a software, which works strictly according to defined specifications and solutions. The solution and the method to achieve it, both are immediately understood before coding. The s-type software is least subjected to changes hence this is the simplest of all. For example, calculator program for mathematical computation.
• P-type (practical-type) - This is a software with a collection of procedures.This is defined by exactly what procedures can do. In this software, the specifications can be described but the solution is not obvious instantly. For example, gaming software.
• E-type (embedded-type) - This software works closely as the requirement of real-world environment. This software has a high degree of evolution as there are various changes in laws, taxes etc. in the real world situations. For example, Online trading software.

E-Type software evolution

Lehman has given eight laws for E-Type software evolution -

• Continuing change - An E-type software system must continue to adapt to the real world changes, else it becomes progressively less useful.
• Increasing complexity - As an E-type software system evolves, its complexity tends to increase unless work is done to maintain or reduce it.
• Conservation of familiarity - The familiarity with the software or the knowledge about how it was developed, why was it developed in that particular manner etc. must be retained at any cost, to implement the changes in the system.
• Continuing growth- In order for an E-type system intended to resolve some business problem, its size of implementing the changes grows according to the lifestyle changes of the business.
• Reducing quality - An E-type software system declines in quality unless rigorously maintained and adapted to a changing operational environment.
• Feedback systems- The E-type software systems constitute multi-loop, multi-level feedback systems and must be treated as such to be successfully modified or improved.
• Self-regulation - E-type system evolution processes are self-regulating with the distribution of product and process measures close to normal.
• Organizational stability - The average effective global activity rate in an evolving E-type system is invariant over the lifetime of the product.

Software Paradigms

Software paradigms refer to the methods and steps, which are taken while designing the software. There are many methods proposed and are in work today, but we need to see where in the software engineering these paradigms stand. These can be combined into various categories, though each of them is contained in one another:

Programming paradigm is a subset of Software design paradigm which is further a subset of Software development paradigm.

Software Development Paradigm

This Paradigm is known as software engineering paradigms where all the engineering concepts pertaining to the development of software are applied. It includes various researches and requirement gathering which helps the software product to build. It consists of –

• Requirement gathering
• Software design
• Programming

Software Design Paradigm

This paradigm is a part of Software Development and includes –

• Design
• Maintenance
• Programming

Programming Paradigm

This paradigm is related closely to programming aspect of software development. This includes –

• Coding
• Testing
• Integration

Need of Software Engineering

The need of software engineering arises because of higher rate of change in user requirements and environment on which the software is working.

• Large software - It is easier to build a wall than to a house or building, likewise, as the size of software become large engineering has to step to give it a scientific process.
• Scalability- If the software process were not based on scientific and engineering concepts, it would be easier to re-create new software than to scale an existing one.
• Cost- As hardware industry has shown its skills and huge manufacturing has lower down he price of computer and electronic hardware. But the cost of software remains high if proper process is not adapted.
• Dynamic Nature- The always growing and adapting nature of software hugely depends upon the environment in which user works. If the nature of software is always changing, new enhancements need to be done in the existing one. This is where software engineering plays a good role.
• Quality Management- Better process of software development provides better and quality software product.

Characteristics of good software

A software product can be judged by what it offers and how well it can be used. This software must satisfy on the following grounds:

• Operational
• Transitional
• Maintenance

Well-engineered and crafted software is expected to have the following characteristics:

Operational

This tells us how well software works in operations. It can be measured on:

• Budget
• Usability
• Efficiency
• Correctness
• Functionality
• Dependability
• Security
• Safety

Transitional

This aspect is important when the software is moved from one platform to another:

• Portability
• Interoperability
• Reusability
• Adaptability

Maintenance

This aspect briefs about how well a software has the capabilities to maintain itself in the ever-changing environment:

• Modularity
• Maintainability
• Flexibility
• Scalability

In short, Software engineering is a branch of computer science, which uses well-defined engineering concepts required to produce efficient, durable, scalable, in-budget and on-time software products.

Software Development Life Cycle

Software Development Life Cycle, SDLC for short, is a well-defined, structured sequence of stages in software engineering to develop the intended software product.

SDLC Activities

SDLC provides a series of steps to be followed to design and develop a software product efficiently. SDLC framework includes the following steps:

Communication

This is the first step where the user initiates the request for a desired software product. He contacts the service provider and tries to negotiate the terms. He submits his request to the service providing organization in writing.

Requirement Gathering

This step onwards the software development team works to carry on the project. The team holds discussions with various stakeholders from problem domain and tries to bring out as much information as possible on their requirements. The requirements are contemplated and segregated into user requirements, system requirements and functional requirements. The requirements are collected using a number of practices as given -

• studying the existing or obsolete system and software,
• conducting interviews of users and developers,
• referring to the database or
• collecting answers from the questionnaires.

Feasibility Study

After requirement gathering, the team comes up with a rough plan of software process. At this step the team analyzes if a software can be made to fulfill all requirements of the user and if there is any possibility of software being no more useful. It is found out, if the project is financially, practically and technologically feasible for the organization to take up. There are many algorithms available, which help the developers to conclude the feasibility of a software project.

System Analysis

At this step the developers decide a roadmap of their plan and try to bring up the best software model suitable for the project. System analysis includes Understanding of software product limitations, learning system related problems or changes to be done in existing systems beforehand, identifying and addressing the impact of project on organization and personnel etc. The project team analyzes the scope of the project and plans the schedule and resources accordingly.

Software Design

Next step is to bring down whole knowledge of requirements and analysis on the desk and design the software product. The inputs from users and information gathered in requirement gathering phase are the inputs of this step. The output of this step comes in the form of two designs; logical design and physical design. Engineers produce meta-data and data dictionaries, logical diagrams, data-flow diagrams and in some cases pseudo codes.

Coding

This step is also known as programming phase. The implementation of software design starts in terms of writing program code in the suitable programming language and developing error-free executable programs efficiently.

Testing

An estimate says that 50% of whole software development process should be tested. Errors may ruin the software from critical level to its own removal. Software testing is done while coding by the developers and thorough testing is conducted by testing experts at various levels of code such as module testing, program testing, product testing, in-house testing and testing the product at user’s end. Early discovery of errors and their remedy is the key to reliable software.

Integration

Software may need to be integrated with the libraries, databases and other program(s). This stage of SDLC is involved in the integration of software with outer world entities.

Implementation

This means installing the software on user machines. At times, software needs post-installation configurations at user end. Software is tested for portability and adaptability and integration related issues are solved during implementation.

Operation and Maintenance

This phase confirms the software operation in terms of more efficiency and less errors. If required, the users are trained on, or aided with the documentation on how to operate the software and how to keep the software operational. The software is maintained timely by updating the code according to the changes taking place in user end environment or technology. This phase may face challenges from hidden bugs and real-world unidentified problems.

Disposition

As time elapses, the software may decline on the performance front. It may go completely obsolete or may need intense upgradation. Hence a pressing need to eliminate a major portion of the system arises. This phase includes archiving data and required software components, closing down the system, planning disposition activity and terminating system at appropriate end-of-system time.

Software Development Paradigm

The software development paradigm helps developer to select a strategy to develop the software. A software development paradigm has its own set of tools, methods and procedures, which are expressed clearly and defines software development life cycle. A few of software development paradigms or process models are defined as follows:

Waterfall Model

Waterfall model is the simplest model of software development paradigm. It says the all the phases of SDLC will function one after another in linear manner. That is, when the first phase is finished then only the second phase will start and so on.

This model assumes that everything is carried out and taken place perfectly as planned in the previous stage and there is no need to think about the past issues that may arise in the next phase. This model does not work smoothly if there are some issues left at the previous step. The sequential nature of model does not allow us go back and undo or redo our actions.

This model is best suited when developers already have designed and developed similar software in the past and are aware of all its domains.

Iterative Model

This model leads the software development process in iterations. It projects the process of development in cyclic manner repeating every step after every cycle of SDLC process.

The software is first developed on very small scale and all the steps are followed which are taken into consideration. Then, on every next iteration, more features and modules are designed, coded, tested and added to the software. Every cycle produces a software, which is complete in itself and has more features and capabilities than that of the previous one.

After each iteration, the management team can do work on risk management and prepare for the next iteration. Because a cycle includes small portion of whole software process, it is easier to manage the development process but it consumes more resources.

Spiral Model

Spiral model is a combination of both, iterative model and one of the SDLC model. It can be seen as if you choose one SDLC model and combine it with cyclic process (iterative model).

This model considers risk, which often goes un-noticed by most other models. The model starts with determining objectives and constraints of the software at the start of one iteration. Next phase is of prototyping the software. This includes risk analysis. Then one standard SDLC model is used to build the software. In the fourth phase of the plan of next iteration is prepared.

V – model

The major drawback of waterfall model is we move to the next stage only when the previous one is finished and there was no chance to go back if something is found wrong in later stages. V-Model provides means of testing of software at each stage in reverse manner.

At every stage, test plans and test cases are created to verify and validate the product according to the requirement of that stage. For example, in requirement gathering stage the test team prepares all the test cases in correspondence to the requirements. Later, when the product is developed and is ready for testing, test cases of this stage verify the software against its validity towards requirements at this stage.

This makes both verification and validation go in parallel. This model is also known as verification and validation model.

Big Bang Model

This model is the simplest model in its form. It requires little planning, lots of programming and lots of funds. This model is conceptualized around the big bang of universe. As scientists say that after big bang lots of galaxies, planets and stars evolved just as an event. Likewise, if we put together lots of programming and funds, you may achieve the best software product.

For this model, very small amount of planning is required. It does not follow any process, or at times the customer is not sure about the requirements and future needs. So the input requirements are arbitrary.

This model is not suitable for large software projects but good one for learning and experimenting.

Software Requirements

The software requirements are description of features and functionalities of the target system. Requirements convey the expectations of users from the software product. The requirements can be obvious or hidden, known or unknown, expected or unexpected from client’s point of view.

Requirement Engineering

The process to gather the software requirements from client, analyze and document them is known as requirement engineering.

The goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ document.

Requirement Engineering Process

It is a four step process, which includes –

• Feasibility Study
• Requirement Gathering
• Software Requirement Specification
• Software Requirement Validation

Let us see the process briefly -

Feasibility study

When the client approaches the organization for getting the desired product developed, it comes up with rough idea about what all functions the software must perform and which all features are expected from the software.

Referencing to this information, the analysts does a detailed study about whether the desired system and its functionality are feasible to develop.

This feasibility study is focused towards goal of the organization. This study analyzes whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. It explores technical aspects of the project and product such as usability, maintainability, productivity and integration ability.

The output of this phase should be a feasibility study report that should contain adequate comments and recommendations for management about whether or not the project should be undertaken.

Requirement Gathering

If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements from the user. Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include.

Software Requirement Specification

SRS is a document created by system analyst after the requirements are collected from various stakeholders.

SRS defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.

The requirements received from client are written in natural language. It is the responsibility of system analyst to document the requirements in technical language so that they can be comprehended and useful by the software development team.

SRS should come up with following features:

• User Requirements are expressed in natural language.
• Technical requirements are expressed in structured language, which is used inside the organization.
• Design description should be written in Pseudo code.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions -

• If they can be practically implemented
• If they are valid and as per functionality and domain of software
• If there are any ambiguities
• If they are complete
• If they can be demonstrated

Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:

• Requirements gathering - The developers discuss with the client and end users and know their expectations from the software.
• Organizing Requirements - The developers prioritize and arrange the requirements in order of importance, urgency and convenience.

·        Negotiation & discussion - If requirements are ambiguous or there are some conflicts in requirements of various stakeholders, if they are, it is then negotiated and discussed with stakeholders. Requirements may then be prioritized and reasonably compromised.

The requirements come from various stakeholders. To remove the ambiguity and conflicts, they are discussed for clarity and correctness. Unrealistic requirements are compromised reasonably.

• Documentation - All formal & informal, functional and non-functional requirements are documented and made available for next phase processing.

Requirement Elicitation Techniques

Requirements Elicitation is the process to find out the requirements for an intended software system by communicating with client, end users, system users and others who have a stake in the software system development.

There are various ways to discover requirements

Interviews

Interviews are strong medium to collect requirements. Organization may conduct several types of interviews such as:

• Structured (closed) interviews, where every single information to gather is decided in advance, they follow pattern and matter of discussion firmly.
• Non-structured (open) interviews, where information to gather is not decided in advance, more flexible and less biased.
• Oral interviews
• Written interviews
• One-to-one interviews which are held between two persons across the table.
• Group interviews which are held between groups of participants. They help to uncover any missing requirement as numerous people are involved.

Surveys

Organization may conduct surveys among various stakeholders by querying about their expectation and requirements from the upcoming system.

Questionnaires

A document with pre-defined set of objective questions and respective options is handed over to all stakeholders to answer, which are collected and compiled.

A shortcoming of this technique is, if an option for some issue is not mentioned in the questionnaire, the issue might be left unattended.

Task analysis

Team of engineers and developers may analyze the operation for which the new system is required. If the client already has some software to perform certain operation, it is studied and requirements of proposed system are collected.

Domain Analysis

Every software falls into some domain category. The expert people in the domain can be a great help to analyze general and specific requirements.

Brainstorming

An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis.

Prototyping

Prototyping is building user interface without adding detail functionality for user to interpret the features of intended software product. It helps giving better idea of requirements. If there is no software installed at client’s end for developer’s reference and the client is not aware of its own requirements, the developer creates a prototype based on initially mentioned requirements. The prototype is shown to the client and the feedback is noted. The client feedback serves as an input for requirement gathering.

Observation

Team of experts visit the client’s organization or workplace. They observe the actual working of the existing installed systems. They observe the workflow at client’s end and how execution problems are dealt. The team itself draws some conclusions which aid to form requirements expected from the software.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

Software Requirements

We should try to understand what sort of requirements may arise in the requirement elicitation phase and what kinds of requirements are expected from the software system.

Broadly software requirements should be categorized in two categories:

Functional Requirements

Requirements, which are related to functional aspect of software fall into this category.

They define functions and functionality within and from the software system.

EXAMPLES -

• Search option given to user to search from various invoices.
• User should be able to mail any report to management.
• Users can be divided into groups and groups can be given separate rights.
• Should comply business rules and administrative functions.
• Software is developed keeping downward compatibility intact.

Non-Functional Requirements

Requirements, which are not related to functional aspect of software, fall into this category. They are implicit or expected characteristics of software, which users make assumption of.

Non-functional requirements include -

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Disaster recovery
• Accessibility

Requirements are categorized logically as

• Must Have : Software cannot be said operational without them.
• Should have : Enhancing the functionality of software.
• Could have : Software can still properly function with these requirements.
• Wish list : These requirements do not map to any objectives of software.

While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of debate with stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for software updates.

User Interface requirements

UI is an important part of any software or hardware or hybrid system. A software is widely accepted if it is -

• easy to operate
• quick in response
• effectively handling operational errors
• providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only way for users to perceive the system. A well performing software system must also be equipped with attractive, clear, consistent and responsive user interface. Otherwise the functionalities of software system can not be used in convenient way. A system is said be good if it provides means to use it efficiently. User interface requirements are briefly mentioned below -

• Content presentation
• Easy Navigation
• Simple interface
• Responsive
• Consistent UI elements
• Feedback mechanism
• Default settings
• Purposeful layout
• Strategical use of color and texture.
• Provide help information
• User centric approach
• Group based view settings.

Software System Analyst

System analyst in an IT organization is a person, who analyzes the requirement of proposed system and ensures that requirements are conceived and documented properly & correctly. Role of an analyst starts during Software Analysis Phase of SDLC. It is the responsibility of analyst to make sure that the developed software meets the requirements of the client.

System Analysts have the following responsibilities:

• Analyzing and understanding requirements of intended software
• Understanding how the project will contribute in the organization objectives
• Identify sources of requirement
• Validation of requirement
• Develop and implement requirement management plan
• Documentation of business, technical, process and product requirements
• Coordination with clients to prioritize requirements and remove and ambiguity
• Finalizing acceptance criteria with client and other stakeholders

Software Metrics and Measures

Software Measures can be understood as a process of quantifying and symbolizing various attributes and aspects of software.

Software Metrics provide measures for various aspects of software process and software product.

Software measures are fundamental requirement of software engineering. They not only help to control the software development process but also aid to keep quality of ultimate product excellent.

According to Tom DeMarco, a (Software Engineer), “You cannot control what you cannot measure.” By his saying, it is very clear how important software measures are.

Let us see some software metrics:

·        Size Metrics - LOC (Lines of Code), mostly calculated in thousands of delivered source code lines, denoted as KLOC.

Function Point Count is measure of the functionality provided by the software. Function Point count defines the size of functional aspect of software.

• Complexity Metrics - McCabe’s Cyclomatic complexity quantifies the upper bound of the number of independent paths in a program, which is perceived as complexity of the program or its modules. It is represented in terms of graph theory concepts by using control flow graph.

·        Quality Metrics - Defects, their types and causes, consequence, intensity of severity and their implications define the quality of product.

The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of product.

• Process Metrics - In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics.
• Resource Metrics - Effort, time and various resources used, represents metrics for resource measurement.

Section 2 : Software Development Methodologies – Water Fall, Iterative, Agile etc.

Types of Software developing life cycles (SDLC)

· Waterfall Model

· V-Shaped Model

· Evolutionary Prototyping Model

· Spiral Method (SDM)

· Iterative and Incremental Method

· Extreme programming (Agile development)

Waterfall Model

Description

The waterfall Model is a linear sequential flow. In which progress is seen as flowing steadily downwards (like a waterfall) through the phases of software implementation. This means that any phase in the development process begins only if the previous phase is complete. The waterfall approach does not define the process to go back to the previous phase to handle changes in requirement. The waterfall approach is the earliest approach that was used for software development.

The usage

Projects which not focus on changing the requirements, for example, projects initiated from request for proposals (RFPs)

Advantages and Disadvantages

Advantages	Disadvantages
· Easy to explain to the user· Structures approach.· Stages and activities are well defined· Helps to plan and schedule the project· Verification at each stage ensures early detection of errors / misunderstanding· Each phase has specific deliverables	· Assumes that the requirements of a system can be frozen· Very difficult to go back to any stage after it finished.· Little flexibility and adjusting scope is difficult and expensive.· Costly and required more time, in addition to detailed plan

V-Shaped Model

Description

It is an extension for waterfall model, Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The major difference between v-shaped model and waterfall model is the early test planning in v-shaped model.

The usage

· Software requirements clearly defined and known

· Software development technologies and tools is well-known

Advantages and Disadvantages

Advantages	Disadvantages
· Simple and easy to use.· Each phase has specific deliverables.· Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.· Works well for where requirements are easily understood. Verification and validation of the product in early stages of product development	· Very inflexible, like the waterfall model.· Little flexibility and adjusting scope is difficult and expensive.· Software is developed during the implementation phase, so no early prototypes of the software are produced.· Model doesn’t provide a clear path for problems found during testing phases.· Costly and required more time, in addition to detailed plan

Prototyping Model

Description

It refers to the activity of creating prototypes of software applications, for example, incomplete versions of the software program being developed. It is an activity that can occur in software development. It used to visualize some component of the software to limit the gap of misunderstanding the customer requirements by the development team. This also will reduce the iterations may occur in waterfall approach and hard to be implemented due to inflexibility of the waterfall approach. So, when the final prototype is developed, the requirement is considered to be frozen.

It has some types, such as:

· Throwaway prototyping: Prototypes that are eventually discarded rather than becoming a part of the finally delivered software

· Evolutionary prototyping: prototypes that evolve into the final system through iterative incorporation of user feedback.

· Incremental prototyping: The final product is built as separate prototypes. At the end the separate prototypes are merged in an overall design.

· Extreme prototyping: used at web applications mainly. Basically, it breaks down web development into three phases, each one based on the preceding one. The first phase is a static prototype that consists mainly of HTML pages. In the second phase, the screens are programmed and fully functional using a simulated services layer. In the third phase the services are implemented

The usage

· This process can be used with any software developing life cycle model. While this shall be focused with systems needs more user interactions. So, the system do not have user interactions, such as, system does some calculations shall not have prototypes.

Advantages and Disadvantages

Advantages	Disadvantages
· Reduced time and costs, but this can be disadvantage if the developer loses time in developing the prototypes· Improved and increased user involvement	· Insufficient analysis· User confusion of prototype and finished system· Developer misunderstanding of user objectives· Excessive development time of the prototype· Expense of implementing prototyping

Spiral Method (SDM)

Description

It is combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects. This model uses many of the same phases as the waterfall model, in essentially the same order, separated by planning, risk assessment, and the building of prototypes and simulations.

The usage

It is used in shrink-wrap large applications and systems which built-in small phases or segments.

Advantages and Disadvantages

Advantages	Disadvantages
· Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier.· Early involvement of developers· Manages risks and develops system into phases	· High cost and time to reach the final product.· Needs special skills to evaluate the risks and assumptions· Highly customized limiting re-usability

Iterative and Incremental Method

Description

It is developed to overcome the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with the cyclic interactions in between. The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system.

It consists of mini waterfalls

The usage

It is used in shrink-wrap application and large system which built-in small phases or segments. Also can be used in system has separated components, for example, ERP system. Which we can start with budget module as first iteration and then we can start with inventory module and so forth.

Advantages and Disadvantages

Advantages	Disadvantages
· Produces business value early in the development life cycle· Better use of scarce resources through proper increment definition· Can accommodate some change requests between increments· More focused on customer value than the linear approaches· Problems can be detected earlier	· Requires heavy documentation· Follows a defined set of processes· Defines increments based on function and feature dependencies· Requires more customer involvement than the linear approaches· Partitioning the functions and features might be problematic· Integration between iteration can be an issue if this is not considered during the development.

Extreme programming (Agile development)

Description

It is based on iterative and incremental development, where requirements and solutions evolve through collaboration between cross-functional teams.

The usage

It can be used with any type of the project, but it needs more involvement from customer and to be interactive. Also, it can be used when the customer needs to have some functional requirement ready in less than three weeks.

Advantages and Disadvantages

Advantages	Disadvantages
· Decrease the time required to avail some system features.· Face to face communication and continuous inputs from customer representative leaves no space for guesswork.· The end result is the high quality software in least possible time duration and satisfied customer	· Scalability· Skill of the software developers· Ability of customer to express user needs· Documentation is done at later stages· Reduce the usability of components.· Needs special skills for the team.

Another Variation of Thinking About

Introduction

Software methodologies are concerned with the process of creating software - not so much the technical side but the organizational aspects. In this, the first of two articles, I will introduce the different types of methodologies. I will describe them from an historical perspective, as one way to understand where we are and where we are going is to know where we have been.

There will also be a subsequent companion article looking at the current state of the art and what I believe the future holds. This second article is given the rather controversial title of "Why Creating Software is not Engineering", which I will, of course, explain. In the 2nd article I will discuss several popular agile methodologies particularly their most important aspects (such as unit testing), which are generally neglected or glossed over.

Before beginning I should warn the reader of my penchant for analogy. Actually this whole article is one big analogy stretched almost to breaking point. I like them because many of the concepts in software development are abstract and hard to grasp, but using a familiar real-world situation, like taking a taxi to the pub, can clarify the ideas. Of course, there is always the caveat that no analogy is perfect. Be careful to understand the similarities and the differences.

Ad-hoc

Historically, the first methodology was basically no methodology at all. This is generally called the "ad hoc" methodology.

We'll start with a simple scenario. You are to meet your friend Jim at the Station Hotel. You have no idea where that is but you jump in a cab and tell the taxi driver where you want to go. A few minutes later you arrive at your destination safely and without wasting any drinking time!

In this analogy you are the "customer" and the taxi driver is the "developer". The above is the ideal case where the customer knows where they want to go and the developer knows how to get there. Unfortunately the real world is never this simple. Consider these variations.

Problems

1. You tell the driver where to go but you end up at the train station not the Station Hotel. Obviously he misheard you and after all many of his passengers go there.

You clarify the situation but the taxi driver is uncommunicative and you end up at the wrong hotel. Eventually, you work out that the driver does not speak English well.

At some point you give up. If you are really persistent you might get to your destination but by then Jim has already left.

2. You ask the taxi driver to take you to the Station Hotel to which the immediate reply is "Which one?". Apparently, there are three within a ten mile radius and you don't know which one Jim went to. You try them all but can't find Jim.

The driver suggests it might be the "Fire Station Hotel" which was actually not far from where you started.

3. The taxi driver kindly informs you that your destination is quite distant and you do not have enough money. He suggests that you take the bus.

Of course, the bus is slow and does not go directly past the pub. You get there eventually.

4. The taxi takes you straight to the hotel but it's closed for business.

5. You are half way there when you realise you need to post a letter. Then Jim calls your mobile and says that he has gone to a different hotel. Then you get stuck in traffic and also need to use the bathroom. The whole trip is much longer and more expensive than expected.

6. The taxi driver seems to know where to go but is inexperienced and after quite a while he realises that he is going completely the wrong direction. Several times he has to backtrack but eventually finds the destination though the trip takes much longer than expected.

I'm sure you can think of many more things that can go wrong.

Summary

The ad-hoc methodology can work provided you have a simple problem. If the customer knows exactly what they want and the developer knows how to give it to them and has the right tools to do so (a reliable vehicle and a street directory if necessary) then there is a good chance of success. However, most of the time you get there late or not at all.

The above scenarios represent several common problems seen in software development, namely miscommunication (1), a customer who doesn't know exactly what they want (2) or thinks they do until they try it (4), changing requirements (5) and inexperienced developers (6). I leave it the reader to work out what scenario 3 means.

Waterfall

OK, you want to avoid all the above problems, but what do you do? Conventional wisdom is to ask an expert for help and there are many willing helpers ready to provide their services, for a fee, of course. You find that you need an "analyst" to work out where you really want to go and a "designer" to provide detailed unambiguous instructions on how to get there.

The analyst works out by deduction and/or educated guesswork exactly which "Station Hotel" you want. Perhaps they even manage to contact Jim to confirm the location. They also find out the exact address and the opening hours.

Now you know exactly where you want to go but how to get there? The designer provides a "specification" or instructions for getting to the hotel - eg proceed 2 miles to the roundabout, take the 3rd exit, etc. To ensure that the driver understands the instructions the essential parts are even translated into his native language. A good designer might also try to anticipate problems and have contingency plans - eg, if the freeway has heavy traffic to take an alternative route.

The essential point of the specification is to have the trip completely and thoroughly planned before starting out. Everybody involved reads the specification and agrees that this should get the customer to the pub on time. Can you see a problem with this approach?

While the analyst/designer is busy at work you (the customer) are getting a bit nervous. It's been some time and you still haven't gone anywhere. You also want feedback that once you start the trip everything will stay on track, since your experience of taxi journeys is that they can be very unpredictable and the driver never gives any indication of whether he is lost or on course.

You need a "plan" so that you can check that everyone is doing there job and that if something is amiss it will be immediately apparent. The plan will also require the driver to regularly report his position so you know if he is going to be late or not get there at all. For a large project you will need a "project manager" to formulate the plan.

Problems

This all sounds very thorough and reassuring but there are many problems with this approach.

1. First the taxi driver has to read and understand the whole specification before starting out - for example, he might have to work out where he can buy fuel if necessary. The specification is complex and detailed and it can take some time before the driver understands it enough to begin.

2. The taxi driver attempts to follow the specifications exactly but there are a few small ambiguities and he makes a wrong assumption. By the time he realises the mistake he has gone for miles in the wrong direction and has to backtrack.

3. There are crucial assumptions in the specification that nobody checked. For example, you can never get a taxi after 8pm on a Friday. The designer had not considered this but his excuse is that it was outside his purview - the customer should know this since he is the one that catches taxis and after all he signed off on the specification.

4. Things happen that were not anticipated. For example, unexpected traffic snarls cause slow progress.

5. There are problems that the designer was not aware of. For example, roadworks that require a lengthy detour. The taxi driver knew about it but nobody asked him.

6. There are problems that nobody was aware of. For example, the planned route goes the wrong way down a one-way street, even though it was not marked as such on any map.

7. There are some things that you (the customer) forgot to mention - eg, you need to stop at the bank to get some cash on the way. It seems like a minor thing to you, but the designer complains that it completely invalidates most of the specifications (though he exaggerates of course).

8. There are unexpected events that nobody could have anticipated such as a major accident that causes traffic chaos.

9. The taxi driver becomes annoyed and frustrated with the process. "Just tell me where you want to go!"

10. The project plan estimates that the journey will take an hour. The passenger immediately starts reading a book or falls asleep in the back seat. The taxi driver thinks it will take half that time, especially as he knows a shortcut. He dawdles for awhile, makes some detours to take care of some personal business, and loses track of the time. The customer wakes up and wonders where he is - the driver assures him that all is going to plan. 

However by now there is only 15 minutes to go and he's hardly made any progress. He finds the road for his shortcut has been closed, then gets booked for speeding. In the end he makes a huge effort and only arrives 20 minutes late. Ironically, he is praised by all for being so dedicated.

11. The designer knows from past experience that taxi drivers vary widely in ability. The specification is written to the lowest common denominator, even though this demeans the average taxi driver. 

12. The designer knows that the taxi driver has a tendency to deviate from his specification. This can be at the behest of his passenger (see 7 above), or he may take the scenic route to make the trip more pleasant (and increase the fare), or take a shortcut that may save time but has many risks involved, or simply take a diversion out of some personal interest.

To counter this, the designer will try to limit the information provided to the driver to only what they need to know. As an extreme example the designer might cover all the windows of the taxi and make the driver navigate entirely using the odometer and a compass. Obviously, this a very dangerous approach as the driver has no feedback at all in order to correct for even the slightest deviation from the course.

13. You start the journey but there are a lot of problems and delays. You manage to contact Jim and arrange to meet him at a nearby hotel which is actually more convenient for both of you. (Unfortunately this completely invalidates the specification which is discarded.)

Summary

The waterfall model can work if everything goes to plan, but in a complex project things rarely do. The crux of the problem is the reliance on getting the specification perfect before attempting to implement it. Unfortunately, even if you get close to getting it right at the start things will change. For most real-world projects this means this approach is doomed to failure, or at best a late and over-budget project and a very frustrating experience.

The above scenarios represent several common problems with the waterfall methodology namely the difficulty of understanding (1) and following the specifications (2) and getting them right in the first place (3, 5, 6, 7). The process does not cope with change (4, 8, 13) and does not make best use of the developers (9, 11, 12).

A major problem is that without hard deliverable milestones most developers will procrastinate at the start (10). However, to be fair this behaviour is reinforced by the fact that the most projects have major changes (or are even cancelled) well after development has started. To the developer there is no point in working hard at the start when in all likelihood the effort will be wasted.

Prototype

The prototype methodology addresses the major problem of the waterfall methodology's "specification", which is that you are never sure it will work until you arrive at your destination. It is difficult or impossible to prove that the specification is correct so we instead create a simple working example of the product, much like an architect would create a scale model of a proposed new building.

To continue our taxi analogy the designer, or a delegate, grabs a motorbike to first check that you can actually get to the Station Hotel and even explore a few alternative routes. When the motorbike driver has found a good way the actual taxi trip can begin.

Problems

1. A motorbike is not a car. It can bypass traffic snarls or pass through narrow lanes that a car cannot. In his eagerness to prove the feasibility of the trip the designer may gloss over the fact that the taxi trip will take a lot longer.

2. To you (the customer) it seems that creating a prototype is a waste of time, since your trip can't begin until the motorbike has arrived. (The taxi could start out before the motorbike arrives but there is always the risk that a better route is found and the taxi has to backtrack.)

3. You decide that if the motorbike can get there so easily why not just jump on the back and avoid taking the more expensive taxi trip altogether. The problem with this is the motorbike trip may be far less pleasant. Moreover, the motorbike is not designed to take a passenger and can become unstable with you and your luggage causing an accident.

Summary

The prototype approach is good if there are a lot of unknowns about how the best approach or even the feasibility of the project. Different routes can be quickly explored and the best decided on. However, if the best route is obvious and well travelled then creating a prototype is unnecessary. In the end completing the project may not be made that much easier by having a prototype.

The above scenarios represent these problems often encountered with prototypes: creating the final product can be a lot more difficult than creating the prototype (1) and the use of a prototype may not be of much benefit anyway (2). A major problem is that once a customer tries a working prototype of the software there can be pressure to simply use the prototype rather than develop the full product even though the prototype may be completely unsuitable in many non-obvious ways (3).

4GL

This is not so much a methodology as an approach that tries to use new technology. The idea, pushed heavily in the 1980's, is that very high level languages could be developed to allow users to create their own applications. These so-called "4th generation languages" were supposedly easy enough for anyone to use.

In our analogy this is like getting rid of the taxi driver altogether. Of course, most people can't drive taxis (in the analogy) so we need a simple system where the user just has simplified controls. Unfortunately, the only way this was possible is to create a huge network of guidance rails to keep the taxis on track.

Problems

1. You get in the taxi, enter the destination, and you get an obscure error message. You go nowhere.

2. The cost of the rail network is enormous so it doesn't go to very many destinations yet.

3. You need to go by a long and circuitous route even though your destination is not that far away.

Summary

The idea is good but in general it is not workable. Perhaps one day, with advances in AI, this approach can work.

The above problems mean: the technology is not good enough (1) and expensive to develop (2). In practice the product is slow and cumbersome (3) and gives generally unsatisfactory results compared to other methods (2).

Iterative

The precursor to today's agile methodologies (see below) can be loosely grouped as "iterative". They are also often described as "cascade" methods as they are really just a series of small waterfalls.

I am not going to discuss these in detail as they were not very widely used (except nominally) or very successful. They were more an attempt to fix the problems of the waterfall methodology rather than to bypass them altogether. As such they had many of the same problems, and even exacerbated some.

Agile

The main problem with the waterfall approach is that it takes a lot of effort up front effort in planning, analysis and design. When it comes to the actual implementation there are so many variables and unknowns that it is very unlikely to go to plan.

The prototype approach meant we could eliminate some of this uncertainty by demonstrating that there is a reasonable chance of success. However, there is still a lot of up front effort to design and build the prototype even before we even start the real development.

What if we could divide the project into a sequence of steps so that at each stage we can demonstrate that we are closer to the final product? After each step we produce a working (but not final) product so that the customer can see that the project is on the right track.

To continue our taxi analogy we can start our journey immediately since we know that to get to any of the possible destinations we have to take the main road into town. When we come to a point where there is uncertainty we stop to assess the position and choose the best path. Further, by continually re-assessing we can adapt to any unforeseen and new developments.

On the surface this looks very much like the "ad hoc" methodology in that you just jump in the taxi and go. Indeed, it does empower the taxi driver with finding the best way again but the feedback mechanism allows more people to see what is happening and to keep things on course.

It also does not preclude the use of extra team members to ensure the trip is smooth and trouble free. A navigator could monitors traffic conditions, looks for trouble spots and try to find the best way to the destination. A mechanic could ensure that the taxi is always in good condition and will not break down.

But there are still pitfalls to watch out for.

Problems

1. You (the passenger) are sure you know where you want to go, the trip proceeds smoothly but when you get there you find that nobody else thinks it is the right place. Jim is not there but at another hotel.

2. The trip is proceeding smoothly but when you are halfway there things change completely - Jim rings to say he has gone in the opposite direction. There is a lot already invested in the trip so there is a reluctance to just abandon it and start again - after all that is the "waterfall" way of doing things.

3. The direct route is straight down the hill and over the old bridge. A much slower path is taken to mitigate the risks and so the customer always has the destination in sight. The quickest way would have been the direct route but was not seen as the "right" way to do it.

4. There are two equally good ways to the destination, via the north or south side of the mountain. However, the driver wants to go one way and the navigator the other. As a compromise they choose the worst possible way - right over the top of the mountain.

Summary

The advantage of the agile methodology is that the development team is happy since they are empowered not just to drive the taxi but to navigate and ensure that everything goes smoothly. The customer is happy because he knows the driver is not lost and, even if he is late, at every stage he knows where he is and still has a good idea when he will get there.

However, there are still potential problems to watch out for. One problem is a customer representative who does not really know what is best for the "real" customer (1). Agile methods are evolutionary but sometimes you can't evolve the existing software into what is really required (2). For a simple, well understood project "ad hoc" may still be better (3). Finally group decisions may not always be the best decisions (4).

Totalitarian

Finally, I introduce a class of methodology that I have experienced but never seen described. In many ways it is like the agile methodology taken to the extreme. The customer is highly involved in the development and releases are not every few weeks but daily or even more often.

This typically occurs when the customer is a former taxi driver and wants complete control of the product and the process; hence I have called this methodology "totalitarian". An alternative name might be "back seat driver".

Problems

1. At every turn you (the passenger) check the roadmap and make suggestions or even tell the driver he is going the wrong way. The taxi driver has to stop and check to make sure but mainly to reassure the passenger.

2. With the constant barrage of instructions the driver becomes confused and even forgets where he is going. The immediate direction is constantly changing.

3. The driver stops thinking about where he is going and just follows your direction. You end up at the end of a dead-end one-way street.

Summary

This approach has no advantage over the agile and has many disadvantages. First, like the waterfall approach it disempowers the developers (2, 3), with consequent effects on their quality of work and hence productivity. There is no clear goal and no sense of accomplishment as there is at the end of each sprint in the agile approach.

It is also difficult to make any sort of significant change to a piece of software and keep it in a consistent state (1, 2). For this reason producing a new "release" should not be attempted more often than weekly. Developers need time to do their own testing and integrate input from different team members. Using this approach you can waste time chasing your own tail, by tracking down non-problems that would eventually "come out in the wash".

Further, the customer needs to do a lot of testing to provide daily feedback. Testing the same thing many times becomes tedious and eventually the customer becomes less diligent and bugs get past them.

Conclusion

Unfortunately when developing software there are many more variables and unknowns than in a simple taxi trip. In this strange world the Station Hotel may not be stationary hotel - it can move or even dispappear or there can be a myriad of hotels all seemingly the same. The roads may be unmapped and always changing.

I should also mention that there are things that can go wrong that are beyond the bounds of any development methodology - the Station Hotel may explode, who knows? There are car accidents and break downs.

I hope this article has given you insight into the different software development methodologies. In my next article I will look at the state of the art, in particular some agile methodologies. I will also emphasize what areas I believe are important and what the future may hold.

Section 3: Types of Software Projects – Greenfield, Migration, Product Customization, Maintenance etc.

Greenfield Software Project:

Greenfield Development happens when you start a brand new project, as in, clean slate development. No legacy code lying around, no old development to maintain. You’re starting afresh, from scratch, from a blank slate, with no restrictions on what you’re doing (other than business rules of course).

In my experience, a true Greenfield projects is quite rare in line of business applications. Almost always you have to interact with some legacy code at some point in time and perform integrations with that legacy code that impose limitations on your development.

Examples of Greenfield Development

• Building a new E-commerce solution from the ground up
• Implementing a new rules engine for your company from the ground up.
• Rewriting an old app in a new language (maybe C++ to C#) but not utilizing any of the old code other than for business rule reference
• A new startup wants application X Built. Application X has never been built before, therefore Application X is a greeenfield endeavor

Migration Software Project:

migration is the process of moving from the use of one operating environment to another operating environment that is, in most cases, is thought to be a better one

Product Customization Software Projects:

custom software is developed for a single customer it can accommodate that customer's particular preferences and expectations. Custom software may be developed in an iterative process, allowing all nuances and possible hidden risks to be taken into account, including issues which were not mentioned in the original requirement specifications (which are, as a rule, never perfect). Especially the first phase in the software development process may involve many departments, including marketing, engineering, research and development and general management.

Maintenance Software Project:

Software maintenance is widely accepted part of SDLC now a days. It stands for all the modifications and updations done after the delivery of software product. There are number of reasons, why modifications are required, some of them are briefly mentioned below:

Market Conditions - Policies, which changes over the time, such as taxation and newly introduced constraints like, how to maintain bookkeeping, may trigger need for modification.

Client Requirements - Over the time, customer may ask for new features or functions in the software.

Host Modifications - If any of the hardware and/or platform (such as operating system) of the target host changes, software changes are needed to keep adaptability.

Organization Changes - If there is any business level change at client end, such as reduction of organization strength, acquiring another company, organization venturing into new business, need to modify in the original software may arise.

Types of maintenance

In a software lifetime, type of maintenance may vary based on its nature. It may be just a routine maintenance tasks as some bug discovered by some user or it may be a large event in itself based on maintenance size or nature. Following are some types of maintenance based on their characteristics:

Corrective Maintenance - This includes modifications and updations done in order to correct or fix problems, which are either discovered by user or concluded by user error reports.

Adaptive Maintenance - This includes modifications and updations applied to keep the software product up-to date and tuned to the ever changing world of technology and business environment.

Perfective Maintenance - This includes modifications and updates done in order to keep the software usable over long period of time. It includes new features, new user requirements for refining the software and improve its reliability and performance.

Preventive Maintenance - This includes modifications and updations to prevent future problems of the software. It aims to attend problems, which are not significant at this moment but may cause serious issues in future.

Cost of Maintenance

Reports suggest that the cost of maintenance is high. A study on estimating software maintenance found that the cost of maintenance is as high as 67% of the cost of entire software process cycle.

On an average, the cost of software maintenance is more than 50% of all SDLC phases. There are various factors, which trigger maintenance cost go high, such as:

Real-world factors affecting Maintenance Cost

The standard age of any software is considered up to 10 to 15 years.

Older softwares, which were meant to work on slow machines with less memory and storage capacity cannot keep themselves challenging against newly coming enhanced softwares on modern hardware.

As technology advances, it becomes costly to maintain old software.

Most maintenance engineers are newbie and use trial and error method to rectify problem.

Often, changes made can easily hurt the original structure of the software, making it hard for any subsequent changes.

Changes are often left undocumented which may cause more conflicts in future.

Software-end factors affecting Maintenance Cost

Structure of Software Program

Programming Language

Dependence on external environment

Staff reliability and availability

Maintenance Activities

IEEE provides a framework for sequential maintenance process activities. It can be used in iterative manner and can be extended so that customized items and processes can be included.

These activities go hand-in-hand with each of the following phase:

Identification & Tracing - It involves activities pertaining to identification of requirement of modification or maintenance. It is generated by user or system may itself report via logs or error messages.Here, the maintenance type is classified also.

Analysis - The modification is analyzed for its impact on the system including safety and security implications. If probable impact is severe, alternative solution is looked for. A set of required modifications is then materialized into requirement specifications. The cost of modification/maintenance is analyzed and estimation is concluded.

Design - New modules, which need to be replaced or modified, are designed against requirement specifications set in the previous stage. Test cases are created for validation and verification.

Implementation - The new modules are coded with the help of structured design created in the design step.Every programmer is expected to do unit testing in parallel.

System Testing - Integration testing is done among newly created modules. Integration testing is also carried out between new modules and the system. Finally the system is tested as a whole, following regressive testing procedures.

Acceptance Testing - After testing the system internally, it is tested for acceptance with the help of users. If at this state, user complaints some issues they are addressed or noted to address in next iteration.

Delivery - After acceptance test, the system is deployed all over the organization either by small update package or fresh installation of the system. The final testing takes place at client end after the software is delivered.

Training facility is provided if required, in addition to the hard copy of user manual.

Maintenance management - Configuration management is an essential part of system maintenance. It is aided with version control tools to control versions, semi-version or patch management.

Software Re-engineering

When we need to update the software to keep it to the current market, without impacting its functionality, it is called software re-engineering. It is a thorough process where the design of software is changed and programs are re-written.

Legacy software cannot keep tuning with the latest technology available in the market. As the hardware become obsolete, updating of software becomes a headache. Even if software grows old with time, its functionality does not.

For example, initially Unix was developed in assembly language. When language C came into existence, Unix was re-engineered in C, because working in assembly language was difficult.

Other than this, sometimes programmers notice that few parts of software need more maintenance than others and they also need re-engineering.

Re-Engineering Process

Decide what to re-engineer. Is it whole software or a part of it?

Perform Reverse Engineering, in order to obtain specifications of existing software.

Restructure Program if required. For example, changing function-oriented programs into object-oriented programs.

Re-structure data as required.

Apply Forward engineering concepts in order to get re-engineered software.

There are few important terms used in Software re-engineering

Reverse Engineering

It is a process to achieve system specification by thoroughly analyzing, understanding the existing system. This process can be seen as reverse SDLC model, i.e. we try to get higher abstraction level by analyzing lower abstraction levels.

An existing system is previously implemented design, about which we know nothing. Designers then do reverse engineering by looking at the code and try to get the design. With design in hand, they try to conclude the specifications. Thus, going in reverse from code to system specification.

Program Restructuring

It is a process to re-structure and re-construct the existing software. It is all about re-arranging the source code, either in same programming language or from one programming language to a different one. Restructuring can have either source code-restructuring and data-restructuring or both.

Re-structuring does not impact the functionality of the software but enhance reliability and maintainability. Program components, which cause errors very frequently can be changed, or updated with re-structuring.

The dependability of software on obsolete hardware platform can be removed via re-structuring.

Forward Engineering

Forward engineering is a process of obtaining desired software from the specifications in hand which were brought down by means of reverse engineering. It assumes that there was some software engineering already done in the past.

Forward engineering is same as software engineering process with only one difference – it is carried out always after reverse engineering.

Component reusability

A component is a part of software program code, which executes an independent task in the system. It can be a small module or sub-system itself.

Example

The login procedures used on the web can be considered as components, printing system in software can be seen as a component of the software.

Components have high cohesion of functionality and lower rate of coupling, i.e. they work independently and can perform tasks without depending on other modules.

In OOP, the objects are designed are very specific to their concern and have fewer chances to be used in some other software.

In modular programming, the modules are coded to perform specific tasks which can be used across number of other software programs.

There is a whole new vertical, which is based on re-use of software component, and is known as Component Based Software Engineering (CBSE).

Re-use can be done at various levels

Application level - Where an entire application is used as sub-system of new software.

Component level - Where sub-system of an application is used.

Modules level - Where functional modules are re-used.

Software components provide interfaces, which can be used to establish communication among different components.

Reuse Process

Two kinds of method can be adopted: either by keeping requirements same and adjusting components or by keeping components same and modifying requirements.

Requirement Specification - The functional and non-functional requirements are specified, which a software product must comply to, with the help of existing system, user input or both.

Design - This is also a standard SDLC process step, where requirements are defined in terms of software parlance. Basic architecture of system as a whole and its sub-systems are created.

Specify Components - By studying the software design, the designers segregate the entire system into smaller components or sub-systems. One complete software design turns into a collection of a huge set of components working together.

Search Suitable Components - The software component repository is referred by designers to search for the matching component, on the basis of functionality and intended software requirements..

Incorporate Components - All matched components are packed together to shape them as complete software.

Section 4: Software Testing, Test Plans, Test Automation, Black Box and White Box Testing

Software Testing:

·         Software testing is a process used to identify the correctness, completeness, and quality of developed computer software. It includes a set of activities conducted with the intent of finding errors in software so that it could be corrected before the product is released to the end users.

·         In simple words, software testing is an activity to check whether the actual results match the expected results and to ensure that the software system is defect free.

Test Plans:

TEST PLAN DEFINITION

A Software Test Plan is a document describing the testing scope and activities. It is the basis for formally testing any software/product in a project.

ISTQB Definition

• test plan: A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice,and any risks requiring contingency planning. It is a record of the test planning process.
• master test plan: A test plan that typically addresses multiple test levels.
• phase test plan: A test plan that typically addresses one test phase.

TEST PLAN TYPES

One can have the following types of test plans:

• Master Test Plan: A single high-level test plan for a project/product that unifies all other test plans.
• Testing Level Specific Test Plans:Plans for each level of testing.
• Unit Test Plan
• Integration Test Plan
• System Test Plan
• Acceptance Test Plan
• Testing Type Specific Test Plans: Plans for major types of testing like Performance Test Plan and Security Test Plan.

Introduction:

• Provide an overview of the test plan.
• Specify the goals/objectives.
• Specify any constraints.

References:

• List the related documents, with links to them if available, including the following:
• Project Plan
• Configuration Management Plan

Test Items:

List the test items (software/products) and their versions.

Features to be Tested:

• List the features of the software/product to be tested.
• Provide references to the Requirements and/or Design specifications of the features to be tested

Features Not to Be Tested:

• List the features of the software/product which will not be tested.
• Specify the reasons these features won’t be tested.

Approach:

• Mention the overall approach to testing.
• Specify the testing levels [if it’s a Master Test Plan], the testing types, and the testing methods [Manual/Automated; White Box/Black Box/Gray Box]

Item Pass/Fail Criteria:

• Specify the criteria that will be used to determine whether each test item (software/product) has passed or failed testing.

Suspension Criteria and Resumption Requirements:

• Specify criteria to be used to suspend the testing activity.
• Specify testing activities which must be redone when testing is resumed.

Test Deliverables:

• List test deliverables, and links to them if available, including the following:
• Test Plan (this document itself)
• Test Cases
• Test Scripts
• Defect/Enhancement Logs
• Test Reports

Test Environment:

• Specify the properties of test environment: hardware, software, network etc.
• List any testing or related tools.

Estimate:

• Provide a summary of test estimates (cost or effort) and/or provide a link to the detailed estimation.

Schedule:

• Provide a summary of the schedule, specifying key test milestones, and/or provide a link to the detailed schedule.

Staffing and Training Needs:

• Specify staffing needs by role and required skills.
• Identify training that is necessary to provide those skills, if not already acquired.

Responsibilities:

• List the responsibilities of each team/role/individual.

Risks:

• List the risks that have been identified.
• Specify the mitigation plan and the contingency plan for each risk.

Assumptions and Dependencies:

• List the assumptions that have been made during the preparation of this plan.
• List the dependencies.

Approvals:

• Specify the names and roles of all persons who must approve the plan.
• Provide space for signatures and dates. (If the document is to be printed.)

TEST PLAN GUIDELINES

• Make the plan concise. Avoid redundancy and superfluousness. If you think you do not need a section that has been mentioned in the template above, go ahead and delete that section in your test plan.
• Be specific. For example, when you specify an operating system as a property of a test environment, mention the OS Edition/Version as well, not just the OS Name.
• Make use of lists and tables wherever possible. Avoid lengthy paragraphs.
• Have the test plan reviewed a number of times prior to baselining it or sending it for approval. The quality of your test plan speaks volumes about the quality of the testing you or your team is going to perform.
• Update the plan as and when necessary. An out-dated and unused document stinks and is worse than not having the document in the first place.

Test Automation:
Manual testing is performed by a human sitting in front of a computer carefully executing the test steps. Automation Testing means using an automation tool to execute your test case suite.   The automation software can also enter test data into the System Under Test, compare  expected and actual  results and generate detailed test  reports.

Test Automation demands considerable investments of money and resources. Successive development cycles will require execution of same test suite repeatedly. Using a test automation tool it's possible to record this test suite  and re-play it  as required. Once the test suite is automated, no human intervention is required. This improved ROI of Test Automation.

Goal of Automation is to reduce number of test cases to be run manually and not eliminate manual testing all together.

Automated testing is important due to following reasons: 

·         Manual Testing of all work flows, all fields , all negative scenarios is time and cost consuming

·         It is difficult to test for multi lingual sites manually

·         Automation does not require Human intervention. You can run automated test unattended (overnight)

·         Automation increases  speed of test execution

·         Automation helps increase  Test Coverage

·         Manual Testing can become boring and hence error prone.

 

Which Test Cases to Automate?

Test cases to be automated can be selected using the following criterion to increase the automation ROI

·         High Risk - Business Critical test cases

·         Test cases that are executed repeatedly

·         Test Cases that are very tedious or difficult to perform manually

·         Test Cases which are time consuming

The following category of test cases are not suitable for automation:

·         Test Cases that are newly designed and not executed manually  atleast once

·         Test Cases for which the requirements are changing frequently

·         Test cases which are executed on ad-hoc basis.

Automation Process

Following steps are followed in an Automation Process

 

Test tool selection

Test Tool selection largely depends on the technology the Application Under Test is built on. For instance QTP does not support Informatica.  So QTP cannot be used for testing Informatica applications. It's a good idea to conduct Proof of Concept of Tool on AUT 

Define the scope of Automation

Scope of automation is the area of your Application Under Test which will be automated. Following points help determine scope:

·         Feature that are important for the business

·         Scenarios which have large amount of data

·         Common functionalities across applications

·         Technical feasibility

·         Extent to which business components are reused

·         Complexity of test cases

·         Ability to use the same test cases for cross browser testing

Planning, Design and Development 

During this phase you create  Automation strategy & plan, which contains following details-

·         Automation tools selected

·         Framework design and its features

·         In-Scope and Out-of-scope items of automation

·         Automation test bed preparation

·         Schedule and Timeline of scripting and execution

·         Deliverables of automation testing

Test Execution

Automation Scripts are executed during this phase. The scripts need input test data before there are set to run. Once executed they provide detailed test reports.  

Execution can be performed using the automation tool directly or through the Test Management tool which will invoke the automation tool.

Example: Quality center is the Test Management tool which in turn it will invoke QTP for execution of automation scripts. Scripts can be executed in a single machine or a group of  machines. The execution can be done during night , to save time.

Maintenance

 As new functionalities are added to the System Under Test with successive cycles, Automation Scripts need to be added, reviewed and maintained for each release cycle. Maintenance becomes necessary to improve effectiveness of Automation Scripts. 

Automation tools

Following are the most popular test tools :

 QTP : HP's  Quick Test Professional ( now known as HP Functional Test) is the market leader in Functional Testing Tool. The tool supports plethora of environments including SAP , Java , Delphi amongst others. QTP can be used  in conjunction with Quality Center which is a comprehensive Test  Management Tool.  know  is light tool which can be recommended for web or client/server applications.

Rational Robot: It  is an IBM tool used to automate regression, functional and configuration tests for client server, e-commerce as well as  ERP applications. It can be used with Rational Test Manager which aided in Test Management Activities 

Selenium: Its an open source Web Automation Tool. It supports all types of web browsers. Despite being open source its actively developed and supported

  How to Choose an Automation Tool? 

Selecting the right tool can be a tricky task. Following criterion will help you select the best tool for your requirement-

·         Environment Support

·         Ease of use

·         Testing of Database

·         Object identification

·         Image Testing

·         Error Recovery Testing

·         Object Mapping

·         Scripting Language Used

·         Support for various types of test - including functional, test management, mobile, etc...

·         Support for multiple testing frameworks

·         Easy to debug the automation software scripts

·         Ability to recognize objects in any environment

·         Extensive test reports and results

·         Minimize training cost of selected tools 

Tool selection is one of biggest challenges to be tackled before going for automation. First, Identify the requirements, explore various tools and its capabilities, set the expectation from the tool and go for a Proof Of Concept.

Framework in Automation 

A framework is  set of automation guidelines  which help in  

·         Maintaining consistency of Testing

·         Improves test structuring

·         Minimum usage of code

·         Less Maintenance of code

·         Improve re-usability

·         Non Technical testers can be involved in code

·         Training period of using the tool can be reduced

·         Involves Data wherever appropriate 

There are four types of framework used in software automation testing:

1.     Data Driven Automation Framework 2.     Keyword Driven Automation Framework 3.     Modular Automation Framework 4.     Hybrid Automation Framework

Automation Best Practices: 

To get maximum ROI of automation, observe the following

·         Scope of Automation needs to be determined in detail before the start of the project. This sets expectations from Automation right.

·         Select the right automation tool: A tool must not be selected based on its popularity but it's fit to the automation requirements.

·         Choose appropriate framework

·         Scripting Standards- Standards have to be followed while writing the scripts for Automation .Some of them are-

o    Create uniform scripts, comments and indentation of the code

o    Adequate Exception handling - How error is handled on system  failure or unexpected behavior of the application.

o    User defined messages should be coded or standardized for Error Logging for testers to understand.

·         Measure metrics- Success of automation cannot be determined by   comparing the manual effort with the automation effort but by also capturing the following metrics.

o    Percent of defects found

o    Time required for automation testing for each and every release cycle

o    Minimal Time taken for release   

o    Customer satisfaction Index

o    Productivity improvement

The above guidelines if observed can greatly help in making your automation successful.

Benefits of automated testing

 Following are benefits of automated testing:

·         70% faster than the manual testing ·         Wider test coverage of application features ·         Reliable in results ·         Ensure Consistency ·         Saves Time and Cost ·         Improves accuracy ·         Human Intervention is not required while execution ·         Increases Efficiency ·         Better speed in executing tests ·         Re-usable test scripts ·         Test Frequently and thoroughly ·         More  cycle of execution can be achieved through automation  ·         Early time to market

 Conclusion

Right selection of automation tool, testing process and team, are important players for automation to be successful. Manual and automation methods go hand-in hand for successful testing.

Black Box and White Box Testing

DEFINITION

Black Box Testing, also known as Behavioral Testing, is a software testing method in which the internal structure/ design/ implementation of the item being tested is not known to the tester. These tests can be functional or non-functional, though usually functional.

This method is named so because the software program, in the eyes of the tester, is like a black box; inside which one cannot see. This method attempts to find errors in the following categories:

• Incorrect or missing functions
• Interface errors
• Errors in data structures or external database access
• Behavior or performance errors
• Initialization and termination errors

Definition by ISTQB

• black box testing: Testing, either functional or non-functional, without reference to the
  internal structure of the component or system.
• black box test design technique: Procedure to derive and/or select test cases based on an
  analysis of the specification, either functional or non-functional, of a component or system
  without reference to its internal structure.

EXAMPLE

A tester, without knowledge of the internal structures of a website, tests the web pages by using a browser; providing inputs (clicks, keystrokes) and verifying the outputs against the expected outcome.

LEVELS APPLICABLE TO

Black Box Testing method is applicable to the following levels of software testing:

• Integration Testing
• System Testing
• Acceptance Testing

The higher the level, and hence the bigger and more complex the box, the more black box testing method comes into use.

BLACK BOX TESTING TECHNIQUES

Following are some techniques that can be used for designing black box tests.

• Equivalence partitioning: It is a software test design technique that involves dividing input values into valid and invalid partitions and selecting representative values from each partition as test data.
• Boundary Value Analysis: It is a software test design technique that involves determination of boundaries for input values and selecting values that are at the boundaries and just inside/ outside of the boundaries as test data.
• Cause Effect Graphing: It is a software test design technique that involves identifying the cases (input conditions) and effects (output conditions), producing a Cause-Effect Graph, and generating test cases accordingly.

BLACK BOX TESTING ADVANTAGES

• Tests are done from a user’s point of view and will help in exposing discrepancies in the specifications.
• Tester need not know programming languages or how the software has been implemented.
• Tests can be conducted by a body independent from the developers, allowing for an objective perspective and the avoidance of developer-bias.
• Test cases can be designed as soon as the specifications are complete.

BLACK BOX TESTING DISADVANTAGES

• Only a small number of possible inputs can be tested and many program paths will be left untested.
• Without clear specifications, which is the situation in many projects, test cases will be difficult to design.
• Tests can be redundant if the software designer/ developer has already run a test case.
• Ever wondered why a soothsayer closes the eyes when foretelling events? So is almost the case in Black Box Testing.

DEFINITION

White Box Testing (also known as Clear Box Testing, Open Box Testing, Glass Box Testing, Transparent Box Testing, Code-Based Testing or Structural Testing) is a software testing method in which the internal structure/ design/ implementation of the item being tested is known to the tester. The tester chooses inputs to exercise paths through the code and determines the appropriate outputs. Programming know-how and the implementation knowledge is essential. White box testing is testing beyond the user interface and into the nitty-gritty of a system.

This method is named so because the software program, in the eyes of the tester, is like a white/ transparent box; inside which one clearly sees.

Definition by ISTQB

• white-box testing: Testing based on an analysis of the internal structure of the component or
  system.
• white-box test design technique: Procedure to derive and/or select test cases based on an
  analysis of the internal structure of a component or system.

EXAMPLE

A tester, usually a developer as well, studies the implementation code of a certain field on a webpage, determines all legal (valid and invalid) AND illegal inputs and verifies the outputs against the expected outcomes, which is also determined by studying the implementation code.

White Box Testing is like the work of a mechanic who examines the engine to see why the car is not moving.

LEVELS APPLICABLE TO

White Box Testing method is applicable to the following levels of software testing:

• Unit Testing: For testing paths within a unit.
• Integration Testing: For testing paths between units.
• System Testing: For testing paths between subsystems.

However, it is mainly applied to Unit Testing.

WHITE BOX TESTING ADVANTAGES

• Testing can be commenced at an earlier stage. One need not wait for the GUI to be available.
• Testing is more thorough, with the possibility of covering most paths.

WHITE BOX TESTING DISADVANTAGES

• Since tests can be very complex, highly skilled resources are required, with thorough knowledge of programming and implementation.
• Test script maintenance can be a burden if the implementation changes too frequently.
• Since this method of testing it closely tied with the application being testing, tools to cater to every kind of implementation/platform may not be readily available.

Section 5: IT Implementation

http://sce.uhcl.edu/helm/rationalunifiedprocess/process/workflow/environm/co_imppr.htm

Section 6 : IT  Deployment Environments – SAAS, On Premise, Client Server etc.

A deployment environment is a collection of configured clusters, servers, and middleware that collaborate to provide an environment to host software modules. For example, a deployment environment might include a host for message destinations, a processor or sorter of business events, and administrative programs.

SAAS:

·         Software as a service (or SaaS) is a way of delivering applications over the Internet—as a service. Instead of installing and maintaining software, you simply access it via the Internet, freeing yourself from complex software and hardware management.

·         SaaS applications are sometimes called Web-based software, on-demand software, or hosted software. Whatever the name, SaaS applications run on a SaaS provider’s servers. The provider manages access to the application, including security, availability, and performance.

On Premise:

·         On-premises software (sometimes abbreviated as "on-prem") is installed and runs on computers on the premises (in the building) of the person or organization using the software, rather than at a remote facility such as a server farm or cloud.

Client Server Deployment:

·         A development system used to create applications for a client/server environment. A comprehensive system generally includes a GUI builder for creating the user interface, a fourth-generation language for writing the business logic as well as an interpreter and/or compiler and debugging tools.

Section 7: Software Licensing, Subscription and Sale Models:

A software license is a legal instrument (usually by way of contract law, with or without printed material) governing the use or redistribution of software. Under United States copyright law all software is copyright protected, in source code as also object code form.

A purchase made by signed order, as for e.g. a periodical for a specified period of time. A subscription is a contract in which a person pays for something in regular intervals, or in which a person pays a fee to receive a product, service, or otherwise in regular intervals.

Section 8: Project Development Vs Product Development 

Product Development

·         Product is developed for generating revenue and profit for some general functionality to serve to a larger audience. But initially this is an investment. End users come into the picture once there is a sale of the product into the market.

·         Product development keeps the SME (specialist) from almost all the fields. Highly paid people will be working on the product.

·         Domain is given high priority. People are supposed to have a good amount of domain understanding.

·         Product Manager/Owner is the key person. He has to keep an eye on the competitor’s product functionality, UI, revenue, deals etc.

·         If there is no end user for the product during the development. Product owner has to collect some information/feedback from early adopter or end user in some forum. One of the examples is to arrange a summit in the market and call all the possible end customers and give them a high level demo of the critical features and functionality. Take their feedback for the product improvement.

·         Quality is the most important thing. There will be large testing team allocated to the product development. Most of the time, automated testing should also be in place. Quality, look and feel, user experience should be superior to the competitors product.

·         Delivery Excellence – continuous improvement on the quality, productivity etc.

·         Product owner collaboration is required all the time. However, in project development they just give the requirements. High collaboration is not required in project development.

·         More freedom in the team member in the product development. There are no rules in the product development. You just have to develop a much better product with highly motivated team. However, in project development team has to stick to the required quality standards and team is supposed to whatever is written in the plan.

·         People are given more priority because this is long term assignment. People stay in the project for longer duration than projects. Projects are created by developing a product. So they have a finite life.

·         How can team give more value to the end customers is the focus all the time. This product will serve at more than one customer. However, project is usually for just one customer.

·         Most of the product development happens in house. Product development usually are not outsourced.

Project Development

·      In project development, project manager has to finish the project based on the given requirements. However, in product development, product manager has to complete the requirements better than the competitor products. Time is also very important in the product development. Sooner you reach the market better will be the revenue and margin. It is all about competition.

·      Project manager wants to finish the project as soon as possible and would like to start the new one. However, product development usually goes for a longer duration.

·   People do not have that much importance, especially from the service oriented company; they deploy the people whoever is available on the bench. Skills do not matter that much. People are not specialist but they are generalist.

·         Project development is outsourced most of the times.

·         Project is developed particularly for one customer only.

·         Project development exist usually because of the some problem that customer is facing at the moment and it is usually for some in house operations

·         Project managers are responsible for successful delivery of the project with limited resources like scope, schedule and money. They just have to complete the project by all permutation and combination.

·         Scope for the project is limited. However, scope for the product development is modified on the real time basis according the market conditions. So the market conditions, competitors are the most important factors in the product development.

Notes: