Thursday, May 9, 2013

Using SDLC Phases for Status Updates - IT Projects

With RequisitePro you can add SDLC Phases to improve the likelihood of a successful IT project through real-time status updates. This post provides information on RequisitePro attributes and it tells how to add the SDLC Phases and SDLC dates to make IT project management easier. It then provides a detailed overview of the Software (or System) Development Life Cycle, which is the overall processes used to conceive, plan, define, design, build, test and deploy a software application or business system.

In RequisitePro you can use pre-established attributes for each requirement type; or, you can add your own attributes. Attributes provide additional information about requirements so software developers do a better job of developing, testers do a better job of testing, analyst do a better job managing and IT project managers do a better job of monitoring. Below is what some of the the out-of-the-box use case attributes look like in IBM Rational RequisitePro.

Notice, at a glance, you can see the normal flow, alternate flows, includes, extends, etc. for each use case. If you configure RequisitePro to handle all of the attributes included in the Use Case Specification you can then distribute the printouts from RequisitePro instead of creating the Specification.This approach is useful if the IT project manager wants to reduce the time typically spent creating requirements documents. Also, if you look at the title for the RequisitePro view you will see it is called “Developer View”. This is because the Developer View contains the attributes that give the developer the same insight he would have if he were to view the use case specification.

Notice, in the picture below the user interface attribute has been added. In this scenario the images are stored on a web server and the URL to the image is included in the user interface field.The developer can use a web browser to view the mockup image and either store the image locally or continue to use the web browser.

By default, the use case attributes include the priority column. This ensures all requirements associated with a “High” priority are implemented before those associated with a “Medium” priority and so forth. In other words, using this RequisitePro view a software developer can look at the list and identify the requirements that must be implemented first (high), second (medium) and last (low).

The following picture shows additional attributes that can be associated with a requirement such as the SDLC Phase attribute and the SDLC date. These attributes are displayed on the Status Report view created specifically to convey the status of each requirement.

By adding the SDLC (Software or System Development Life Cycle) Phase to RequisitePro, the customer or IT project manager can look at the Status Report view to tell exactly what SDLC phase a requirement is in. In addition, the SDLC Date field defines the date the requirement entered the SDLC Phase. Notice, in the above picture you can tell what requirements are being tested, what requirements are in the design phase and what requirements are still in planning or the requirements analysis phase. The good thing about this view is an IT project manager can tell, at a glance, if certain deliverables will not be developed within the agreed upon time-frame. For example, if the due date for delivering the ability to "add a project" is to be implemented by June 30, 2013 and as of May 29, 2013 the requirement just entered the Requirements Analysis Phase the IT project manager can address the problem. In this scenario, the IT project manager can either renegotiate the deadline or request that everyone work longer hours to meet the timeline initially agreed upon. Lastly, in the above picture, the software being developed is called TMS (Time Management System). A column called TMS Release has also been added. This column allows us to assign a release to each use case (for the IT projects using an iterative approach).

Now, for those of us who like refreshers the following paragraphs include a brief overview of the phases that make up the SDLC. Note that the following phases may vary some across Federal Government agencies. But the overall concept remains the same (i.e., you must plan a project, define the requirements, design the software component(s), build the software components, test the software , deploy it so users have access, and then maintain it).

The following paragraphs present a more detailed view of the the SDLC Phases and it includes information on the objectives of the phases as well. Overall the artifacts developed depend largely on an organization’s implementation of the SDLC.

  • Initiation Phase: During this phase the organization conceives a software idea that addresses a need or problem. The goals of this Phase are to establish project sponsorship, develop a concept proposal, assign a project manager to the project, identify a group that will serve as the planning team, and perform an initial analysis of the associated business process and improvement areas, which may include automating some process steps. The information gathered from this phase is used as a foundation to determine whether or not it is feasible to move on to the next phase.
  • System Concept Development Phase: The primary objective of this phase is to identify the boundaries or scope of the project. If funding is needed, this is the phase in which it is requested. Additional activities associated with this phase include analyzing the business need, assessing the alternatives, identifying project risks, defining the roles and responsibilities of the planning team, developing the initial IT project plan with milestones, defining the project success criteria and writing a high-level statement on how the IT project will meet its success criteria.
  • Planning Phase: The primary objective of the Planning Phase is to create all of the necessary project management plans so the project begins with a structured, implementable plan to increase the likelihood of success. During this phase the project organizational structure is defined (i.e., who fills what role and who reports to whom). In addition, a few of the IT project management plans created include the risk management plan, staffing plan, requirements management plan, communication plan, problem resolution plan, architecture plan, change management plan, configuration management plan, test plan, deployment plan, etc.
  • Requirements Analysis Phase: The Requirements Analyst Phase is used to gather requirements, manage the requirements, write the requirements artifacts, analyze the requirements for gaps and ask the questions necessary to close gaps. If an iterative approach will be used, this phase will be repeated until all requirements have been gathered and added to the requirements management system. In addition, configuration management may be used to ensure the documentation is properly mapped to development releases and controlled releases ensure the promised software functionality is delivered in the proper release. With configuration management version control must be applied.
  • Design Phase: The objective of this phase is to translate the requirements into an implementable design. UML diagrams may be used and/or a design document may be developed. The result should be requirements tied to objects and behaviors that the software development team can implement.
  • Development Phase:  The core activities associated with this phase include coding the software components, performing unit tests and integrating the components to build a solution (partial or whole) that can move into testing. 
  • Integration & Test Phase: This phase is used to perform all required testing to ensure the software works properly and contains the requested functionality. Testing may include user acceptance, functional, system transactional, regression, etc.
  • Implementation Phase: During this phase, the team deploys the software so users can access it. Release notes are distributed to end users to inform them of any updates, known defects, etc. Also a communication is sent to end users informing them of the day/time the new/updated software will be available. If this is the first time users will access the software, the location or URL needed to access the software is also provided. Once the software is deployed, the IT project team may host a meeting to document lessons learned so future implementations will be more concise and correct.
  • Operations & Maintenance Phase: Key activities performed during this Phase include change management and associated activities used to make changes to the software after it has been deployed to users. In addition, a Change Management plan should have been created during the project planning phase. This is the phase in which that plan is executed. If a help desk exists, it is usually the first tier to troubleshoot software problems. If the help desk (or Tier 1) is not able to resolve the problem, the ticket is escalated to the more seasoned analyst team (called Tier 2). If Tier 2 cannot resolve the problem, the ticket is escalated to Tier 3, which is the development team. Tickets solved at Tier 1 are far less costly than those solved at Tier 3. This is one key reason IT project teams try to release software with as few known defects as possible. Also, missing functionality is addressed during this Phase. An end user may submit a change request to ask for functionality not yet implemented. If this occurs a business analyst (or systems analyst) will talk with the end user and other persons, as necessary, to gather the requirements to be implemented.
  • Disposition Phase: The Disposition phase provides structured activities that should be followed if a software or hardware component is outdated; or, for some other reason is no longer needed. There are procedures that should be followed to ensure any data is archived, destroyed or migrated to another system, as necessary.


In this post you learned that you can either use pre-existing attributes in RequisitePro; or, you can add your own attributes. We added the SDLC Phases and then we added the SDLC Date attribute to RequisitePro. As the requirements move through the SDLC, RequisitePro is updated to reflect the SDLC phase the requirement is in and the date in which the requirement entered that phase. This approach makes it easier to support IT project activities surrounding deliverables and timelines. In addition, a Release column can be added to RequisitePro so the requirements can be associated with a specific release to support iterative development activities.