SDLC is a software development lifecycle process used to develop, upgrade or replace information systems.

Feasibility Study, Requirement/Analysis Phase, Design phase, Development/Construction/Build phase, Testing phase, Deployment/Production phase, Support or Maintenance

Waterfall, Agile, Spiral, V-Model, RAD, Scrum, JAD, Prototyping. Some uncommonly used are Cleanroom, RUP, Lean and Dual Vee model. Nowadays Agile is used mostly.

Develop- create a new product from scratch

Upgrade-make changes to existing system

Replace- remove the existing system and replace it with another new technology/software

Waterfall Model	Spiral Model
Product methodology	Development methodology
Documentation	Prototyping and waterfall is also combined
The requirements are documented in the beginning of the project	The requirements are finalized and then documented
Written communication for requirements for each step of the project	Prototyping the requirements with changes in each step
The requirements are segregated as functional and non-functional and documented	Requirements are prototyped in the sequence of priority
No risk analysis during documentation	Risk analysis carried out after each prototype

All depends on the type and scope of the project. Also a life cycle model is selected on the basis of organizational culture and various other scenarios to develop the system.

10% – inception

25% – Elaboration

55% – Construction

10% – Transition

Although every project is different and process will be ultimately tailored to the organizational needs to the project.

AGILE	WATERFALL
Large Projects	Smaller projects
Adaptive approach	Predictive approach
Involving lesser team members	Involving larger team members
Parallel method of process implementation	Serial method of process implementation
Fixed time for each iteration	No fixed time for each phase
Minimal rules required	Large number of rules to be                                                                                                      implemented
Uses demo working software	Uses mainly the documentation for software
Continuous customer interaction	Customer involved only initially in the project
Quick responses to change	Goes through change control board                                                                                                      to implement changes

XP – Extreme Programming

Scrum

DSDM – Dynamic Systems Development Methodology

FDD – Feature-Driven Development

ASD – Adaptive Software Development

Crystal

Lean

AUP – Agile Unified Process

Sprint is a fixed time in scrum model for a deliverable during a phase of the project, usually 30days or less. The sprint planning is a meeting at the beginning of each sprint where the scrum team commits to a specific goal. The planning includes the requirements needed to support the goal and the time for the tasks of the individual members of the team to complete each requirement

The product owner:

• Is a facilitator to drive the development of the project?
• Learns to maximize return on investment (ROI)
• Improves the productivity of the development team in any way possible.
• Attends every sprint planning meeting and keeps information about the team’s progress up to date pertaining to customer’s requirement.
• A liaison between the project team and the customer and takes the authority of the project till it goes to the customer
• Should not be a manager of the team and intervene in the issues during the sprint meetings.

Balances the interests of competing stakeholders

Product backlog is a priority list of user requirements, use cases to be done in order to create, maintain and sustain a product. Product owner owns the product backlog.

The sprint backlog is a list of tasks identified by the Scrum team to be completed during the Scrum sprint. During the sprint planning meeting, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story.

An Epic is a large user story. It is depicted in the same form of a user story but has to be broken into smaller user stories which are implementable.

Theme is a collection of related user stories

• Independent: not dependent on any other user story
• Negotiable: can be changed and rewritten as a part of an iteration
• Valuable: should deliver value to the end user
• Estimate-able: to be able to estimate the size of the user story
• Sized appropriately: should be able to prioritize or plan with a certainty to some extent.
• Testable: should be informative for testing to be possible.

• Product backlog refinement also called product backlog grooming is a process of keeping the backlog clean and orderly. This is also a meeting held at the end of one sprint to ensure the backlog is ready for the next sprint.

• Agile development, due to its innate nature, is both iterative and incremental. Owing to this characteristic, all the development aspects (design, quality, requirements) are constantly reviewed and improved progressively with each sprint. Thus, the product could be adapted at any time based on the client’s need and the level of customer satisfaction is very high.

• A sprint burn down chart is a graphic visualization of the rate of progress of the current sprint. This chart is updated daily over the course of a sprint.

• A spike is a time bound activity to conduct analysis or answer question rather than producing shippable product. Spikes are usually planned to take place in between sprints.

• Planning Poker is an agile planning technique aimed at gaining consensus on the estimated time to complete an activity.

• The progress of an agile project is represented by a story board. Usually it is done as blocks with each block indicating the progress of individual development item.

In software development, a prototype is a rudimentary working model of a product or information system. It can be used for demonstration or development processes. Mainly done by the design and development team.

• Risks – when a new product development is involved prototyping reduces the risk and helps in risk management and mitigation
• Funding – prototyping can help demo the new product to potential investors where funding is required for better understanding
• Gaps – it minimizes the gap between users/customer and technology team

Disadvantages of the prototype model are as follows:

• Giving more attention to the prototype can mislead programmers from understanding the original desired system.
• Client or end user may get confused
• Programmers may misunderstand objective of the end users.
• It is very expensive as prototypes requires a lot of effort and time.

• RAD-called Rapid Application Development model is a variation of JAD (Joint Application development) emphasizing on development rather than planning.
• RAD model is a way of complete development process.
• This is a quicker model completed in an efficient manner based on level of priorities in descending order.
• In a RAD model less important design improvements are postponed to the future and software components are reused to save time.
• This model also involves stand-up meetings and review meetings similar to scrum.

Advantages of RAD:

• It reduces time required for development of software.
• RAD helps in increasing reusability of components
• Quick reviews are delivered.
• RAD encourages end user feedback
• Owners of business actively participate

Disadvantages of RAD:

• It is highly dependent on team and individual performances.
• System which can be modularized can only be developed using RAD
• RAD model requires highly skilled programmers/designers.
• RAD model is highly dependent on how skilfully model is created
• Implementation cost is high, so should be only used on large projects.

AUP is Agile Unified Process. This is a simplified version of RUP (Rational Unified Process).

This is similar to waterfall process involving all the phases of a software development lifecycle from feasibility study to development/implementation of the product. The difference in this model is the phases go through in a vertical manner in a ‘V’ fashion. This is a serial process with the teams not getting interchanged.

Briefly describe the phases in the V-Shaped model.

Phases of V-Shaped model are as follows:

In the V-shape model, verification phases are on the left side. V-shape model consists of:

Requirements Analysis: All the requirement is collected and analysed to understand the problem and propose a solution.

System Design: Analysis of the gathered requirements is done by the engineers and they propose different ways the system can be developed.

Architecture design: Systems architecture consists of different modules, showcasing relationship and communication b/w them.

Module design: Module design details about each of the individual modules in a very detailed manner.

Coding: Coding is at the very bottom of the V-shaped model. In coding phase each of the designed modules are implemented using codes by the developers.

In V-shape SDLC model validation phase is at the right side. It consists of:

Unit testing: Independent modules are tested in the unit testing phase.

Integration testing: All the independent modules are tested to validate interface and find errors in them.

System testing: Entire system is tested by keeping in mind the requirement of the client.

User Acceptance testing: This is the final phase, where client/user himself checks the performance of the system

• Disadvantages of V-Shaped model:
  • V-shaped model is inflexible.
  • It is very hard to make changes in requirements
  • Prototype is not available for V-shaped model
  • Its implementation requires skilled resources

• V-shaped model should be used under below mentioned circumstances:
  • It should be used on projects that are small or medium.
  • It should be used for projects that have clear requirements
  • It should be used when you have technical resources

• Incremental SDLC approach suggests construction of a partial system rather than the complete system and then builds more functionality into it. Requirements and features are prioritized and categorized and then implemented in phases, each phase based on the waterfall model. The process continues till the complete system is achieved.

• RUP involves 4 phases:
  • Inception – involves the idea/concept, requirement documenting and prototyping
  • Elaboration – prove the architecture/design of the product, high risk requirement documentation, 3 different tiers of architecture (presentation, logic and data)
  • Construction – using BA’s documents for user manual and requirements this phase focusses on developing the product until ready for deployment.
  • Transition – focusses on delivery of the system into production.

A ‘hump chart’ is a visual mechanism to give a rough overview of how much each discipline in RUP lifecycle is executed in each phase. The ‘humps’ differ for each project. The horizontal ‘humps’ for each discipline give a rough estimate of the relative effort for each discipline throughout the four phases of RUP lifecycle.

• At the end of:
  • Inception phase, LCO (Lifecycle Objectives) milestone review occurs- for stakeholders to assess the state of the project that scope, requirements and the plan of the project is clearly identified.
  • Elaboration phase, LCA (Lifecycle Architecture) milestone review occurs- stakeholders assess that project vision is stable, risks are managed and requirements are documented as much in detail, expenses are realistic.
  • Construction Phase, IOC (Initial Operational Capability) review occurs -stakeholders assess that software and supporting documentation are ready to be deployed, detailed iteration plans are in place for the next phase, risks and expenditures are stable and managed.
  • Transition Phase, PR (Product Release) milestone review occurs – stakeholders assess that the system, including supporting documentation and training, is ready for deployment. That the system can be supported and operated once in production with acceptable expenditures.

Joint Application Development

• JAD is an interactive systems design concept involving discussion groups in a workshop setting.