Archive

Posts Tagged ‘Software Development Life Cycle’

How SCRUM Methodology is different from the traditional methodology?

September 2, 2010 3 comments

This is most frequent question we hear in the arena of SEPG. Will try to address it in the forum to the best and appreciate the viewer’s response.

As part of the engineering position SCRUM is no different from normal traditional methodology of SDLC (Iterative method), but the way the project management is implemented in the SCRUM is interesting and appreciable.

In the traditional methodology the managerial position is done by managers, whereas is in SCRUM it is responsibility of SCRUM team to do that. For example in traditional, estimation is done by head or manager where as in SCRUM it is done by team in conjunction with product owner and SCRUM Master during the SPRINT Planning Meeting.

Assumptions, Constraints and dependencies (ACD) are documented by manager but the implementation rate is very low, whereas it is plugged or enable in the SCRUM through the channel of Daily standup meeting.

Communication Plan / Escalation plan is documented in the traditional methodology but the usage of the same is minimal whereas it is implemented effectively through daily standup meeting here in SCRUM.

Sprint Review meeting is the channel through which the acceptance criteria for the product is met in the SCRUM methodology. Also it’s the responsibility of the SCRUM team to demonstrate the product to the product owner and prove that things are done according to the definition of Done (DOD). We mean to say SCRUM team defines the boundary of acceptance criteria during the Sprint Planning, whereas in the traditional methodology no where the team which is going to develop the product involved to define the criteria for acceptance.

Changes during the SCRUM are not allowed is the Thumb rule in SCRUM.

Configuration Management should be take care during the Zero sprinting or during the Sprint Planning a line item, need to be addressed.

Lessons learned during the project are not documented in formal or informal manner in the traditional whereas here it is reported through retrospective meeting in SCRUM.

Implementation of the Risk Management in the SCRUM will post later.

Process for Software Development

May 23, 2008 Leave a comment

Process for Software Development

 

Purpose:

 

To provide general guidelines to carryout coding phase

 

Process Requirement:

 

1. Coding:

 

Entry Criteria:

Ø      Approved Technical Design Documents

Ø      Approved Project Plan

Ø      Coding Standards

 

Activity:

Ø      Development process begins with the implementation of the Technical Design by the developer assigned.

Ø      Developers design and create source code following SDLC coding standards / guidelines provided by the Development Team Leader

Ø      Completed Code shall be compiled and the errors/ bugs shall be fixed.

 

Exit Criteria:

Ø      Compiled error free Code

 

2. Code Review and Unit Testing

 

Entry Criteria:

Ø      Compiled Error Free Code

 

Activity:

Ø      Developer Team Leader Conducts walkthrough on code at formal or informal agenda based upon the review process.

Ø      Verifies with the checklist and RTM against the working product/code.

Ø      Unit Testing will be done and if any issues are identified then it as to get closed before release to the system or integration test

 

Records Retention:

Ø      Code Review

Ø      Unit testing issue report

 

Exit Criteria:

Ø      Updated baseline code (SCM Plan)

 

Process of Software / System Design (Part 2)

Process of Software / System Design

 

Purpose:

  1. To describe design goals set.
  2. To define system architecture and detailed design of the system.

Process Requirement:

 

1. System Architecture:

 

Entry Criteria: Approved SRS

  

Activity:

Ø     On approval of SRS from internally and externally the team which is involved with design activity start to prepare HLD (High Level Design).

Ø     The same as to be review and approved by Project Head / manager

Ø     Refer: http://en.wikipedia.org/wiki/Software_Design_Description

 

Record Retention: HLD

 

Exit Criteria: Approved HLD

 

2. Detailed Design Document:

 

Entry Criteria: Approved HLD

  

Activity:

Ø     On approval of High Level Design, the team involve in the low level design start to prepare (LLD)

Ø     LLD involves web page design and Usability (Navigation)

Ø     The same as to be review and approved by Project Head / manager

 

Record Retention: LLD

 

Exit Criteria: Approved LLD

 

3. Validation

 

Entry Criteria: HLD & LLD

 

Activity:

Ø     Conducting informal reviews and walkthroughs or inspections of the detailed software and data base designs.

Ø     The Critical Design Review (CDR) that completes the software detailed design phase.

 

Record Retention: HLD & LLD

 

Exit Criteria: Approved HLD & LLD

 

Process for Software Design Phase (Part 1)

May 6, 2008 1 comment

System Overview

 To provide a general description of the software system including its functionality and matters related to the overall system and its design

System Architecture 

  1. To understand how and why the system was decomposed, and how the individual parts work together to provide the desired functionality. At the top-most level, describe the major responsibilities that the software must undertake and the various roles that the system (or portions of the system) must play.
  2. To describe how the system was broken down into its components/subsystems (identifying each top-level component/subsystem and the roles/responsibilities assigned to it).
  3. To describe how the higher-level components collaborate with each other in order to achieve the required results.

 Detailed System Design

  1. To establish a common classification of the component, such as subsystem, module, class, package, function, file, etc.
  2. To know the responsibilities and/or behavior of this component. What does this component accomplish? What roles does it play? What kinds of services does it provide to its clients? For some components, this may need to refer back to the requirements specification.
  3. To know the constraints i.e. any relevant assumptions, limitations, or constraints for this component. This should include constraints on timing, storage, or component state, and might include rules for interacting with this component (encompassing preconditions, post conditions, invariants, other constraints on input or output values and local or global values, data formats and data access, synchronization, exceptions, etc.)
  4. To know the resources utility I.e. a description of any and all resources that are managed, affected, or needed by this entity. Resources are entities external to the design such as memory, processors, printers, databases, or a software library. This should include a discussion of any possible race conditions and/or deadlock situations, and how they might be resolved.
  5. To know the process. I.e. Description of precisely how this component goes about performing the duties necessary to fulfill its responsibilities. This should encompass a description of any algorithms used; changes of state; relevant time or space complexity; concurrency; methods of creation, initialization, and cleanup; and handling of exceptional conditions.

Software Development Lifecycles (Part 6)

April 28, 2008 4 comments

Evolutionary Model

 

As the word evolution states as “The sequence of events involved in the evolutionary development of a species or taxonomic group of organisms”. Similarly in the development of the software products the sequences of events happens to fine tune the product. First develop the core modules of the system.  The initial product skeleton is refined into increasing levels of capability: by adding new functionalities in successive versions.

Successive version of the product:

 

Ø      Functioning systems capable of performing some useful work.

Ø      A new release may include new functionality:

Ø      Also existing functionality in the current release might have been enhanced.

 

 

 

 

 

 

 

Advantages

 

Ø      Users get a chance to experiment with a partially developed system

Ø      Helps finding exact user requirements

Ø      Core modules get tested thoroughly

 

Disadvantages

Ø      Often, difficult to subdivide problems into functional units:

§         Which can be incrementally implemented and delivered.

Ø      Evolutionary model is useful for very large problems,

§         Where it is easier to find modules for incremental implementation.

 

 

When to use such model?

 

  1. As per my knowledge such models are used in the product development companies and applications where from user behavior new requirements are identified.
  2. Even we can give live examples like web-based services companies (yahoo, rediffmail, google and etc). Initially they may state with mailbox services then later they moved to blogs, chatting, photo sharing and etc with the same username and password credentials.
  3. Basic difference between Incremental model and Evolutionary Model is in Incremental or Iterative model requirements are clear and the implementation is in phase wise whereas in evolutionary model the requirements are identified from the business and user scenario’