Archive

Posts Tagged ‘SDLC’

Tailoring Vs Waivers / Exceptions

April 13, 2011 2 comments
S.No Tailoring Exceptions / Waivers

1

Accounting of an SDLC activity in an alternate method. Justification and approval for required SDLC activities to not be performed on a project.

2

Allows the standard guidelines to be modified to fit the need of the individual project.

 Provides flexibility in standard processes.

A formal exemption from the specific activities beyond standard guidelines.

Allow software development processes to be adapted to meet the needs of individual projects.

3

Example of Process tailoring

Project request document is not documented in the standard SDLC template, instead documented in project inventory repository or part of the scope document.

Example of process waivers

 Unit test plans and cases will not be documented for the project. Team accepts the risk of not documenting the test plans and cases.

Advertisements

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.

Requirement Management

May 2, 2008 5 comments

Requirement Management

 

Purpose

1.      To establish a common acceptance criteria between the Customer and the Project Team on the features and functionalities that are been developed and delivered.

2.      To translating the customer requirements into documented Software Requirements Specification.

 

Process Requirements:

The following are the process of the requirement management:

 

1. Elicitation – Identify the Requirements:

 

Entry Criteria: Business Proposal

 

Procedures:

  • Activity or Task: On approval of business proposal, the team will have to transform the client needs and expectations captured into formal System/ Software requirements

 

Mode of Contact:

 

By Direct Customer Interaction

Record the Customer requirements

Collect necessary materials from the customer

Get clarification on doubts

 

Customer provided requirement document

Analysis the Customer requirement

Comfortable with the requirement

 

Requirement against existing Project / Product

Arrange a demo and record the gaps

Feasibility Study

Prepare Gap Analysis document

  • Record Retention: Draft version of SRS

 

Exit Criteria: Established Requirement

 

2. Analysis

 

Entry Criteria: Established Requirement

 

Procedure:

  • Activities or Task: To identify the requirements in a complete, accurate, consistent, and unambiguous manner.
  • Record Retention: Revised version of SRS

 

Exit Criteria: Analyzed requirements

 

3. Prepare Software Requirement Specification (SRS)

 

Entry Criteria: Analyzed requirements

 

Procedure:

 

Exit Criteria: Software Requirement Specification

 

4. Validation:

 

Entry Criteria: Software Requirement Specification

 

Procedure:

  • Activity or Task

1.      The completed SRS document shall be reviewed. The details of the review shall be recorded in the Review Report-Work Product

2.      On closing all the review comments, SRS shall be approved.

  • Record Retention: Review Report (Software Requirement Review (SRR) – Work product

 

Exit Criteria: Approved Software Requirements Specification

 

Implementation of process in SDLC

April 29, 2008 1 comment

Implementation of process in SDLC

 

As all our previous post is about Software Development Life Cycles, so this is the time to have next few posts is on process implementation in SDLC’s.

 

Different Phases of SDLC:

  1. Requirement
  2. Design & Coding
  3. Testing
  4. Implementation

Requirement Management:

 

A requirement is a “function or characteristic of a system that is necessary…the quantifiable and verifiable behaviors that a system must possess and constraints that a system must work within to satisfy an organization’s objectives and solve a set of problems”.

 

 Similarly, “requirement” has the following definitions [IEEE 90]:

 

  1. A condition or capability needed by a user to solve a problem or achieve an objective
  2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents
  3. A documented representation of a condition or capability as in (1) or (2).

 

Different authors will present different definitions, but there are clearly nonfunctional requirements as well as functional requirements. Requirements are classified as follows

 

  1. Functional requirements

 

Functional requirements define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs.  These are generally listed, as “shall” statements starting with “The system shall… 

 

These include:

 

·        Validity checks on the inputs

·        Exact sequence of operations

·        Responses to abnormal situation, including

·        Overflow

·        Communication facilities

·        Error handling and recovery

·        Effect of parameters

·        Relationship of outputs to inputs, including

·        Input/Output sequences

·        Formulas for input to output conversion

 

     2.  Nonfunctional requirements

 

 In systems engineering and requirements engineering, non-functional requirements are requirements, which specify criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that specify specific behavior or functions. Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are “constraints”, “quality attributes”, “quality goals” and “quality of service requirements”. Non-functional requirements can be divided into two main categories.

 

                                             i.            Execution qualities, such as security and usability, are observable at run time.

                                           ii.            Evolution qualities, such as extensibility and scalability, embody in the static structure of the software system.

Key aspects of the process are:

Requirement Process

 

a.      Requirement Elicitation

 

This concerned with where software requirements come from and how the software engineer can collect them. It includes requirement sources and elicitation techniques.

                 

                 Activities

                                                               i.      Elicit requirements from various individual sources;

                                                             ii.      Insure that the needs of all users are consistent and feasible; and

                                                            iii.      Validate that the requirements so derived are an accurate reflection of  user

 

                   b. Requirement Analysis

 

The very purpose of the analysis is to identify the requirements in a complete, accurate, consistent, and unambiguous manner.

 

Activities

                                                           i.          Detect and resolve conflicts between requirements

                                                          ii.          Discover the bounds of the software and how it must interact with its environment

                                                        iii.          Elaborate system requirements to software requirements

 

                  c. Requirement Specification

 

Requirements specification typically refers to the production of a document, or its electronic equivalent, that can be systematically reviewed, evaluated, and approved. For complex systems, particularly those involving substantial non-software components, as many as three different types of documents are produced:

1.      System definition,

2.      System requirements specification, and

3.      Software requirements specification.

 

    Activities

                                                           i.          Preparation of SRS from the requirements collected

 

 

                       d. Requirement Validation

 

Requirements validation is concerned with the process of examining the requirements documents to ensure that they are defining the right system (that is, the system that the user expects). It is subdivided into descriptions of the conduct of requirements reviews, prototyping, and model validation and acceptance tests.

 

      Activities

                                                          ii.          Conduct Review Meetings

                                                        iii.          Closing Issues identified in the review meeting

                                                        iv.          Approval & Kick off

 

                  e. Changes Request Management

 

On receive of any change list from the client or stakeholders that has to be discussed and reviewed with the team.

 

Activities

                                                           i.          Analysis major and minor changes

                                                          ii.          Made corrections in the SRS on approval of CCB

                                                        iii.          Version updated

                                                        iv.          Moved to production