How Scrum supports the Software Development Life Cycle

Last month I did a blog series on the importance of having a well define Software Development Life Cycle. Today I am going to talk about a methodology which supports the Software Development Life Cycle to keep it on track and humming.

Scrum is an iterative software development framework that employs time boxed “sprints” to deliver software quickly and incrementally. Scrum’s short development cycles offer flexibility to react to change by demonstrating functionality at the end of each iteration, promoting frequent customer interaction, and having the customer as part of the team. Scrum is used for larger efforts where work can be prioritized in batches, with each batch being of a scope and complexity such that it can proceed uninterrupted.

A Scrum team is made up of a number of players with differing roles and responsibilities.

Roles
Responsibility

Scrum Master
Enforces adherence to the Scrum methodology. Responsible for removing impediments for the Delivery Team. Ensures project objectives are met while balancing constraints, budgets, schedules, resources, and risk.

Delivery Team
Responsible for delivering the work. The team is made up of the following roles:

Product Owner: The voice of the customer. Has the responsibility to deliver a successful product in terms of vision and features. The  Project Lead would be the ideal person to fill this role.
Requirements Manager: Elicits, refines, and manages the solution requirements
Architect: Defines the architecture and technologies employed by the software solution
Technical Lead: Oversees software design and development
Developer(s): Codes and integrates the software
Software Test Engineer(s): Validates the software against solution requirements; enforces applicable quality standards and documents identified defects
Configuration Manager: Stages and deploys software changes to Development, Staging, and Production environments
Data Architect: Defines data architecture and allocation of data assets
Database Administrator (DBA): Maintains database; manages data access, import/export processes, and migration […]

  • Permalink

    Part 5: System Development Life Cycle – Release Planning and Deployment

Part 5: System Development Life Cycle – Release Planning and Deployment

The Release Planning and Deployment stage begins upon completion of software testing. During this time, no changes to the software are permitted excepting those explicitly directed by the Customer. Release Planning and Deployment is performed in three phases: Pre-deployment, Deployment, and Post-deployment

Pre-Deployment

The Pre-Deployment Phase addresses three major tasks simultaneously:

Release Planning
Training and Documentation
User Acceptance Testing (UAT)

In most cases, software deployments to the System Users will be transparent to end users.

However, careful release planning and coordination is essential for ensuring that the Customer is consulted on all new or altered code and the decision to release it. Release planning also includes identification of active and standby resources, as well as specification of a roll-back strategy in the event it becomes necessary to revert or roll back the deployed code.

Partnet will collaborate with the Customer and any associated Change Control Board (CCB) representatives to create a release deployment plan, to include:

A cutover schedule, identifying the date and time for the release.
A listing of the features and/or problem reports that will be contained in the release.
Identification of a release coordinator.
A release impact assessment, including impacts to integration partners.
A roll-back plan, outlining a contingency process for removing new changes should it become necessary.

The following tasks can then be performed as part of the pre-deployment phase:

Identify the deployment team, including: Release Project Manager, Change/Configuration Manager, Database Administrator, Technical Lead, Software Test Engineer, End User Tester
Prepare a draft deployment schedule which:

Chronologically outlines required deployment tasks and estimates, including tasks to be performed by external third parties.
Identifies the complexity, timeframe, and task owner of each deployment task.

Execute a mock deployment on the Staging environment, which allows the team to rehearse deployment tasks and validate estimates.
Execute the roll-back plan on the Staging environment […]

  • Permalink

    Part 4: Software Development Life Cycle – Software Development, Testing, and Quality Assurance

Part 4: Software Development Life Cycle – Software Development, Testing, and Quality Assurance

Agile best practices recommend overlapping development and testing cycles. This helps identify and resolve software defects early, while minimizing scenarios where developers are simultaneously trying to fix old bugs and build new features.

Overlapping development and testing cycles also promotes the incremental delivery of working code. This process allows new features and bug fixes to be rapidly promoted, while allowing the Customer to review new features as they are developed, and make decisions about when specific features are ultimately deployed to Production.

Partnet’s software development process is enhanced by the incorporation of continuous delivery methodologies. Continuous delivery is a collection of techniques designed to improve and automate software delivery. These techniques include:

Continuous delivery pipeline
Automated testing
Mainline development
Continuous integration

Continuous delivery allows software to be developed to a high standard, easily packaged, and rapidly deployed to the various environments. Additionally, new features and bug fixes can be rapidly promoted to the Production environment with minimal risk and overhead.

Our developers use a continuous delivery pipeline to implement continuous delivery principles.

The deployment pipeline is like an automated assembly line which the code passes through to ensure it is ready for Production. This assembly line includes:

Building the software
Running unit tests
Building the application deployment
Running automated User-Interface (UI) tests

This method allows functional software to be rapidly promoted to non-Production environments for Customer inspection; or promoted directly to Production in cases where a feature or bug fix is immediately required.  For projects employing the Scrum process, this cycle repeats within each sprint until the Product Owner signifies all requirements have been met and the feature is Production-ready

Automated Testing

Automated testing requires close interaction between software developers and test engineers. The following process is employed within each development cycle (Scrum or Kanban):

Test engineers write test outline(s) for […]

  • Permalink

    Part 1: The Importance of a Defined Software Development Life Cycle

Part 1: The Importance of a Defined Software Development Life Cycle

I’ve been thinking lately about how important it is for a company to have a well-defined process for the Software Development Life Cycle, or SDLC as we like to call it. I’m going to do a series a blogs to share our SLDC process.

Partnet’s SDLC employs industry-best practices in accordance with Agile principles and methods. Our approach ensures that the right product is delivered in the required time frame, while providing visibility into the solution’s development. As part of our Agile Development approach, we employ both Scrum and Kanban methodologies.

Partnet’s SLDC is a multistage process. The first step in the SDLC is to make sure that each development projects start with stable, well-defined requirements. Our Requirement Managers use industry-best requirement management practices as defined by the Business Analysis Body of Knowledge (BABOK).

The requirements manager coordinates and schedules requirements gathering activities with each stakeholder group. These activities may take the form of interviews, video teleconferences, requirement workshops, questionnaires, or other forms of outreach. In some cases, multiple rounds of requirements gathering activities may be required as the results are documented and consolidated.

This step ends with the preparation of a formal requirements package. The requirements package describes desired outcome(s), assumptions, and constraints associated to a given business requirement. A requirements package may be presented in any number of formats, including but not limited to:

Functional specifications
Screen mockups and page wire frames
Flowcharts, sequence diagrams, data flow diagrams and other visual models
Data dictionary
Use cases and scenarios
User Roles
Goal or desired outcome
Benefit to the customers and stakeholders

The Partnet team completes the Requirements Step by meeting with the customer and other stakeholders to conduct a formal System Requirements Review. This involves distribution of the requirements package(s) for stakeholder approval. Signatures are collected […]

Government IT: Looking forward to 2011

A number of predictions are being made about the direction of government IT for 2011. The Obama administration is taking a look at the effectiveness of the “grand design approach.” These costly, massive IT projects aim for sweeping reinvention of agency computer systems and business processes. Unfortunately, these large-scale projects are frequently plagued by cost overruns and schedule delays.

Government watchdogs say there are two critical elements that will make or break the effort to end the grand-design era: the ability to embrace agile development techniques and the creation of a well-trained acquisition and project management corps to oversee the new rapid delivery style.

Nearly 20 years ago, the General Services Administration advocated that government avoid giant, multiyear IT modernization projects and instead deliver new systems in small chunks and solicit user feedback to identify problems early and facilitate frequent course corrections. Few government agencies have taken that advice, but tighter IT budgets in the foreseeable future may cause them to re-think the idea.

In addition, OMB is calling for a number of IT Acquisition reforms including increased training for government IT program managers and increased oversight of IT products with better defined milestones and the use of agile development.

Over the last 10 years, Partnet has been the major developer of the Defense Logistics Agency’s DOD EMALL. Partnet has stressed the importance of agile development within the DOD EMALL program. The DOD EMALL PMO has an outstanding record of continual system improvement over the system life cycle.  Due to the use of agile development, projects have been able to stay within a tightly controlled budget and on schedule.  We hope the rest of the government will embrace the use of agile development as recommended by OMB.

Around And Around With Rounding We Go . . .

No, it’s not the latest Dr. Seuss book.  It’s dealing with rounding of numbers, and in this case currency within  eCommerce websites.

Rounding has been part of computer languages as early as FORTRAN and C, which started back in the 1950s.  Unfortunately for developers during those times, various forms of rounding had to be coded specifically for each instance.  Since then, however, more modern programming languages allow for various rounding options in much easier fashions.

eCommerce sites often integrate with multiple downstream systems.  The DOD EMALL — the largest Government eCommerce site for federal buyers — is no different.  Recent efforts within DOD EMALL have been to compare all uses of currency within the application, as well as to review their uses in downstream systems.

How many versions of rounding can there be?  Well, there are numerous forms of rounding, including round-up, round-down, round-ceiling, round-floor, round-half-even, round-half-up, and round-half-down.  It really depends on how complex you want (or need) things to be.  Software developers may be wondering why their code isn’t acting as expected, and will be seeking answers. As a DOD-contracted IT-provider for the DOD EMALL, Partnet has used several rounding functions, but here are a couple of examples:

The first example is the one you probably learned when you were a child. Round-Half-Up goes to the nearest neighbor —  less than 5 rounds down, equal to or greater than 5 rounds up.

Round-Half-Up Examples

Initial Value
2 Digits of Precision

3.2277
3.23

3.22277
3.22

3.22255
3.22

3.275
3.28

Round-Half-Even is different, as it rounds to the nearest neighbor value (less than 5 rounds down, greater than 5 rounds up), but if it is 5, then it rounds to the nearest even number (either by staying or going up).

Round-Half-Even Examples

Initial Value
4 Digits of Precision

3.22223
3.2222

3.222347875
3.2223

3.222247875
3.2222

So why is rounding a big deal?  If you […]

Google+