Wednesday, October 3, 2012

Software Configuration Management


Topics being covered
  • What is SCM? & Need of SCM
  • SCM and Productivity
  • Functional Areas of SCM
  • Software Configuration Identification
  • Software Configuration Control
  • SC Status Accounting & Reporting
  • Software Configuration Audits
  • SCM Tools
  • CVS
  • ClearCase
  • VSS
Why do Software Configuration Management?
Some common issues of developers:
  • I want my work back, and I want it back now.
  • The problem occurred because client was running wrong version of the software.
  • Ops! The bug was solved but it suddenly reappeared.
  • The developed and tested feature is suddenly missing.
  • Ops! Some wrong files were complied and sent to client.
What is SCM?
  • Configuration Management is a umbrella activity similar to SPM & SQA.
  • If you don’t control the changes, it controls you.
  • SCM is essential part of Project Management and solid software Engineering Practices.
SCM Definition:
  • Software Configuration Management is a set of engineering procedures for tracking and documenting software throughout its life cycle, to ensure that all changes are recorded and current state of the software is known and reproducible.
SCM answers the following questions!
  • What constitutes the software product at any point in time?
  • What changes have been made to the software product?
Without SCM, we can face following problems:
  • Simultaneous Update
  • Redundant work for maintenance
  • Shared code & work products
  • Common Code
  • No Control on Versions
SCM and Productivity
  • A project that takes one person 12 months is a 12 man-month project. However, the same project is not likely to be completed by 2 people in 6 months, or 3 people in 4 months.
  • The more people get involved, more time is spent on the communication among the staff.
  • SCM reduce the time spend in communication, and more time is available for software development.
Functional Areas of SCM
  • Software Configuration Identification
  • Software Configuration Control
  • SC Status Accounting & Reporting
  • Software Configuration Audits

Software Configuration Identification (SCI)
SCI involves:
  • Identifying the structure of the software
  • Uniquely identifying individual components
  • Making them accessible in some form
Goals of SCI:
  • To create the ability to identify the system components throughout the SDLC
  • To provide traceability between the software & related SCIs.
Identification Activity includes:
  • Selecting items to be placed under SCM control.
  • Developing the software hierarchy.
  • Creating an identification scheme that reflects the software hierarchy.
  • Uniquely identifying the various revisions of the software product.
  • Defining relationships and interfaces between the various software products.
SCI methods primarily address the following issues:
  • Baselines
  • Versions
  • Naming convention
What is Software Configuration Item?
  • Documents
  • Programs (Code)
  • Structures (Model)
Baseline
  • Baseline represents the assignment of a name to each group of SCIs that are related to each other.
  • A baseline can be defined as a milestone in the development of the software that is marked by the delivery after formal technical review.
  • A baseline is a specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development and that can be changed only through formal change procedures.

Version
  • When item is baselined, it become frozen. The term frozen means that the item can only be changed by creating a new version.

Version Control
It ensures repeatability and the ability to produce any version of the software at any given time.

Version Control Automation
Labels for product
Hierarchical Structure
Version Making
Document Labeling
Change Controls Board (CCB)

SC Status Accounting and Reporting
  • Configuration Status Reporting also called Status Accounting is an SCM task that may be viewed as an accounting system.
  • Configuration Status Accounting is defined as an element of configuration management, consisting of recording and reporting of information that is needed to manage a configuration effectively.
Purpose
The purpose of software configuration status accounting is to maintain continuous records of the status of all basedline items.
It is also used as:
  • Management Tool
  • Disaster Insurance
  • Needed Information
  • The time at which baseline were established.
  • When each SCI was included in the baseline.
  • When each change was added to baseline.
  • A description of each software change.
  • Documentation status of each baseline.
  • A description of each SCI.

Planning:
  • Status accounting reports need to be addressed in detail in the SCM plan:
  • Type of information that is needed to be reported.
  • Degree of controls on status reporting required by the customer.
  • Status reporting standards, both internal and customer driven.
Software Configuration Audits
  • Audit should periodically be performed to ensure that the SCM practices and procedures are rigorously followed
  • Ensure the integrity of the software baseline over the product life cycle
  • Should be performed prior to every major baseline change
The phase review process ensures that proper SCM actions are taken as follows:
  • Requirements
  • Functional
  • Design
  • Product
  • Operational
SCM Tools
CVS: open source tool
  • CVS stands for "Concurrent Version System" and is a version control system designed for software projects.
  • The CVS can have multiple users simultaneously online and working on a project, also in a file.
  • The role of the CVS is to make the changes in the source code (including bugs) traceable to make documented.
  • At the same time, older versions are saved and restored.
ClearCase: - Rational Software division of IBM
  • ClearCase forms the base of version control for many large and medium sized businesses and can handle projects with hundreds or thousands of developers.
  • ClearCase was developed by Atria Software and first released in 1992 on Unix and later on Windows.
  • IBM continues to develop and market ClearCase.
VSS: - Microsoft
  • VSS stands for Visual SourceSafe
  • Initial version launched in: 1994
  • source control software package oriented towards small software development projects.


Monday, September 24, 2012

Agile Development Methodology - XP, SCRUM, RUP

Topics being Covered

  1. Agile Development
    1. Need of Agile:
    2. Overview
    3. Agile Manifesto
    4. Agile Values
    5. Difference between Traditional Waterfall and Agile Method
  2. Agile Methods
  3. XP (Extreme Programming)
    1. Extreme Programming Practices
    2. Activities
      1. Coding:
      2. Testing
      3. Listening
      4. Designing
  4. RUP - Rational Unified Process
    1. Building blocks of RUP
    2. RUP Project Life Cycle Phases
      1. Inception Phase
      2. Elaboration Phase
      3. Construction Phase
      4. Transition Phase
  5. SCRUM
    1. Process flow
 
Agile Development
  • Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. 
  • Agile processes use feedback, rather than planning, as their primary control mechanism. 
  • The feedback is driven by regular tests and releases of the evolving software.

Need of Agile:
  • Time-to-Market has become crucial
  • Budgets have shrunk
  • Requirements are not clear upfront or are developed concurrently
  • Increased risk of delivering wrong solution
  • Increase in cost of changes in traditional methods (as SDLC progresses, cost of changes increases)
Agile methodology addresses all these aspects :
  • Close collaboration between programmers and business experts
  • Face-to-face communication
  • Frequent deployable deliveries
  • Self organizing teams
  • Quick response to change


Agile Development: Overview
Agile is more than a “New Process”
It is made up of
  • Agile Manifesto
  • Agile Values
  • Agile Principles

It is an umbrella term for many project management methods
  • Scrum
  • Extreme Programming (XP)
  • Rational Unified Process (RUP)

Agile Manifesto


Agile Values : 

1. Communication: Simple, Fast,Effective
2 Simplicity : Don't look ahead
3. Feedback:Improvement rather than perfection; Use feedbacks to move closure to project goals e.g. Feedback accurately reflects customer need
4. Courage: Truth 
5. Respect: I am important and so are you.

Difference between Traditional and Agile Method


Agile Methods
1 XP (Extreme Programming)
2 RUP (Rational Unified Process)
3 SCRUM

1. XP (Extreme Programming):
  • XP describes software-development discipline that organizes people to produce higher quality software more productively.
  • XP attempts to reduce the cost of changes in requirements by having multiple short development cycles, rather than a long one. 
 
  • Extreme programming also introduces a number of basic values, principles and practices on top of the agile programming framework


Extreme Programming Practices:
  1.   Pair programming:  Two programmers will sit together to write a code. One programmer will write the code and other will verify whether is it correct at same time.
  2.   Planning game- main planning process  
    1.   Release Planning: This is focused on determining what requirements are included in which near-term releases, and when they should be delivered. The customers and developers are both part of this.
    2.   Iteration Planning: This plans the activities and tasks of the developers. In this process the customer is not involved.
  3.   Test driven development: The test cases ( or test function) will be writer first and then actual code under test.
  4.   Whole team: XP says that the customer should be on hand at all times and available for questions. For instance, the team developing a financial administration system should include a financial administrator.

Activities:
XP describes four basic activities that are performed within the software development process:

1. Coding,
2. Testing,
3. Listening, and
4. Designing

1. Coding:
  • Only truly important product of the system development process is code
  • Coding can also be used to figure out the most suitable solution
  • Coding can also help to communicate thoughts about programming problems
  • A programmer dealing with a complex programming problem, or finding it hard to explain the solution to fellow programmers, might code it in a simplified manner and use the code to demonstrate what he or she means
  • Other programmers can give feedback on this code by also coding their thoughts.
2. Testing:
  • Extreme programming's approach is that if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws.
  • Unit Test determine whether a given feature works as intended.
  • A programmer writes as many automated tests as they can think of that might "break" the code; if all tests run successfully, then the coding is complete.
  • Every piece of code that is written is tested before moving on to the next feature.
  • Acceptance tests verify that the requirements as understood by the programmers satisfy the customer's actual requirements.
3. Listening:
  • Programmers must listen to what the customers need the system to do, what "business logic" is needed.
  • They must understand these needs well enough to give the customer feedback about the technical aspects of how the problem might be solved, or cannot be solved.
  • Communication between the customer and programmer is further addressed in the Planning Game.
4. Designing:
  • One question - If coding, testing and listening are performed well, the result should always be a system that works ? NO!
  • By creating a design structure that organizes the logic in the system the complexity and the dependencies of system can be avoided.
  • Good design will avoid lots of dependencies within a system; this means that changing one part of the system will not affect other parts of the system
2. RUP (Rational Unified Process):
  • The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003.
  • RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs.
Building blocks of RUP
1. Roles (who) -
A Role defines a set of related skills, competencies and responsibilities.
2. Work Products (what) –
A Work Product represents something resulting from a task, including all the documents and models produced while working through the process.
3. Tasks (how) –
A Task describes a unit of work assigned to a Role that provides a meaningful result.

RUP Project Life Cycle Phases

1. Inception Phase
  • In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc.), and financial forecast is established.
  • Basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated.
2. Elaboration Phase
  • In this phase the problem domain analysis is made and the architecture of the project gets its basic form.
  • The outcome of the elaboration phase is:
  • A use-case model with use cases actors and description. It should be 80% complete.
  • A description of the software architecture
  • An executable architecture that realizes architecturally significant use cases.
  • Business case and risk list which are revised.
  • A development plan for the overall project.
  • Prototypes that demonstrably mitigate each identified technical risk.
3. Construction Phase
  • The primary objective is to build the software system.
  • In this phase, the main focus is on the development of components and other features of the system.
  • In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments that produce demonstrable prototypes.
  • This phase produces the first external release of the software. Its conclusion is marked by the Initial Operational Capability Milestone.

4. Transition Phase:
  • The primary objective is to 'transit' the system from development into production, making it available to and understood by the end user.
  • The activities of this phase include training the end users and maintainers and beta testing the system to validate it against the end users' expectations.
  • The product is also checked against the quality level set in the Inception phase.
  • If all objectives are met, the Product Release Milestone is reached and the development cycle is finished

RUP Project Life Cycle Phases

3. SCRUM:
  • Project Management Methodology
  • Wrapper for existing engineering practices
  • Advocates small team (7-9)
  • Consists of three roles
1. Product Owner
2. Scrum Master
3. Team
  • Tracks progress regularly
Sprint Planning Meeting
  • Total Duration 4 Hrs.
  • The Product owner and Team decide the items committed in current Sprint
Sprint
  • Timeboxed to 30 days
  • Tracked through Sprint Backlog and Sprint Burndown charts
Daily Scrum Meeting
  • Duration 15 mins
  • What did I do yesterday
  • What will I do Today
  • Barriers if any
  • No problem Solving
Sprint Review Meeting
  • Scrum Master leads the meeting
  • Team demonstrates the product increment to satisfaction of the Product owner
Sprint Retrospective
  • At the End of the Project
  • No Finger pointing
  • Team answers four questions
  • What did we do well
  • What did we learn
  • What should we do differently the next time
  • What still puzzles us


  SCRUM: Process Flow