Successfully Managing the Software Development Lifecycle

By: Eric Whipple

Abstract: Learn tips on how to successfully manage software projects and how to avoid some common mistakes that too often prevent completion of a project. Topics range from all aspects of the project lifecycle, single and multiple developers, internal vs. external developers, handling geographically dispersed teams, and how to work with difficult clients.

Successfully Managing the Software Development Lifecycle

by

Martin Rudy

How can you ensure a software project is successful? How do you manage the development lifecycle to prevent the project from not being completed? There are many project management techniques and software options to use as a set of tools for managing software projects.

This session is not a text book presentation but a collection of items from experience that can improve the success of a software project. Tips are shared showing how to improve successes for software projects and how to avoid some of the common mistakes that too often prevent completion of a project. Topics range from all aspects of the project lifecycle. For the most part, they are not software product specific, but techniques that can be used for software development with one or more members on the team.

Contents

The major topics covered are:

What is a successful software project?

Contents

How do you measure the success of a software project? The answer: It Depends! There are many viewpoints from which to measure success. A common measurement of on time, on budget and great quality is one yardstick but there are different angles from which to determine success. Some say you can only achieve two of the three. Management, developers, and end-users have a different perspective to success. It also depends on the target audience of the software.

As you start any project, this is an essential question to answer upfront. Define the answer from each perspective and look to include the answer in the lifecycle from the start to final delivery.

Review of common steps in an application lifecycle

Contents

An application lifecycle is essentially the womb to tomb journey of a software project. Definitions of what constitute a software lifecycle vary but to set a base for this session the major components of a lifecycle are as follows:

7        Define what has to be automated  requirements gathering

7        Design  logical and physical models, forms, classes, flow

7        Develop the application  write the code

7        System Testing  unit-level, beta, gamma, production

7        Documentation  technical, system, user

7        Implementation  production release

The application lifecycle components are not necessarily sequential tasks. Some components can be performed simultaneously. Depending upon the user's needs and deadlines, one task might be performed before another. The details of each component and the management of all the components determine the success of the project and how smoothly the lifecycle flows.

There is constant interaction between user and developer during the application lifecycle. In many cases, you can build a prototype of a portion of the application to help determine the best solution. The application lifecycle for any product starts when a client wants to automate a process or needs to update an existing automated application. To determine what type of technology should be used you must collect the user's requirements. From there you determine if and how to proceed.

Define what has to be automated  requirements gathering

Requirements gathering rounds up information and determines the purpose and scope of the application. You must literally ask the user, "What do you want this system to do? What problem do you want the application to solve?" Start your information gathering with the existing system, whether it is manual or automated. Interview users (not just specifiers) of the current system and find out what is working and what isn't. How do they really use their current system? What work-arounds have they created to make it function? What pieces of information and methods have they added to accomplish their business tasks? This interview process gives insight into the real, especially the hidden, requirements of the application. Is the current system adequate, and if not, what changes need to be included in the new application?

The requirements gathering process can be either a one-on-one interview or a survey exercise. The interview/survey assists you in finding the requirements of the application. Following is a partial list of questions.

7        What is the major purpose of the system? (What is the driving question or need that must be fulfilled?)

7        Is the application used by more than one person at a time? (Is it a single or multi-user system?)

o       If multi-user, how many concurrent users?

o       What type of concurrent processing will be done?

o       Does it need to be a two-tier or multi-tier application?

o       Is it a web-only application

7        To what level will there be insertions, updates, and queries?

7        What type and level of security is needed?

7        If this is a database application, has the DBMS already been determined or can there be a selection process?

7        What are the users' interface requirements? How do they want the system to look?

7        What level of Help is required, and how should it be made available?

7        What are the priorities of the application? What information and processes are crucial to the system's success?

7        What kind of performance/response time does the user require?

7        What kind of ad-hoc query and reporting are required? Does the user want the ability to modify the programs?

7        Must the proposed system be integrated with other systems?

7        What kind of data validation and integrity is required? How should validation and integrity be applied?

7        How large is the system? How much data will be stored? For how long will it be maintained? What is the volume of activity? How big are the records, and how many are anticipated at any given time?

7        How is the data input? Data entry? Downloaded from a mini or mainframe system?

7        Does the output need to be sent to other automated systems?

7        Will the system be accessed seven days a week, twenty-four hours a day? Five days a week, eight hours a day?

Whether the current system is manual or automated, you should diagram its sources of input, manipulation of data, and output of information. The diagram provides a great picture of the business, and is very beneficial in analyzing the activities the application must perform. Look at the current input and update forms (or screens), inspect reports, analyze the data interchange occurring with other systems, and dig out current system documentation if it exists. Look for special processing requirements. It is crucial that the developer understand the flows and processing necessary to the business. To implement the system a user wants, you must understand what things are not being addressed in the current process and include those missing items in the new system. You should also ask the users what they don't like about the current system and correct them in the new/updated application. Once you have the system's information requirements (the requirements specification or requirements document), you are ready to create the logical and physical design of the system.

Borlands CaliberRM provides a requirements management system that facilitates the requirement gathering process and communication between team members. Figure 1 shows the CaliberRM user interface.

Figure 1: CaliberRM user interface

Design  logical and physical models, forms, classes, flow

The goal in this component of the application lifecycle is to provide logical and physical designs. For database applications you identify the types of data the user needs and how it is to be grouped. Time should be taken to carefully design a logical model of the data. A good logical database design can save hours of rework later in the development process.

In designing a logical database model there are many design techniques -- entity/relationship models, extended relational analysis, normalization, or other design technique. No matter which technique you choose, the result you want is to create the logical design of the database.

Creating a database's physical design is the beginning of the real hands-on work in the database selected. Tables are created from your logical data model. As with many of today's relational databases, the physical databases may not exactly match the logical model. This is usually due to an absence of certain relational features or known performance enhancements that are gained through a change in the physical design. If limitations are known up front, fewer changes will be required later.

While analyzing the program design, the system is broken up into modules. Identifying the major processes in an application determines the number of modules in a system. Typically, application modules include:

  • Data input
  • Data modification (changes and deletions)
  • Data output (reports, graphs, ad-hoc queries, data export, email)
  • Logging
  • Data backup and recovery
  • Maintenance and/or administrative tasks

Now define the common processes used by each, and decide whether multiple modules can be consolidated. This helps eliminate coding separate modules and duplicate procedures that perform basically the same tasks. In so doing, you decrease the size of code to be created and maintained.

Next, decide on how you plan to handle errors that occur during processing. What do you want to centralize and what error handling is done at the point of execution. Also, determine the type of error recording and presentation to users will be incorporated. You may also want to think about using a standard set of error and informational messages which have a unique id number, standard text message, and description of the potential cause of the error. Documentation of these should be included in the documentation phase.

Form prototypes  paper or electronic greatly remove ambiguity for the developers. If possible, one of the two should be done, or at least include time for screen development, review and approval in the schedule, budget and cycle.

Tools such and ModelMaker and Bold assist in class definitions and make development and maintenance easier.

Report prototypes can be done on paper or mockups electronically. Getting some basic standards or templates up front and inherit from the templates provide consistency. If ad-hoc reporting is required, the tool selected should have some base template reports.

Once the design phase is complete the coding begins. Depending on the size of the project, there may be multiple design and coding phases. While the coding is being done on the first phase, part of the team can be designing the second phase.

Develop the application  write the code

Developing the application is where the design comes to life. The development team takes the design package and methodically turns it into a product. Here the skills of each developer are fully utilized as they create their portion of the executable. Integrating the smaller segments into the various modules becomes higher in the process as more of the foundation is built. Eventually the unit-level testing is complete and the module is ready for the testing phase.

System Testing  unit-level, beta, gamma, production

Testing a system is crucial to a successful implementation of an application. Test plans start with creating good test data. Multiple test scenarios must be created and run. Network applications must test and solve resource contentions. The key to any test plan is knowing what data to test and knowing how to identify when a process is not working correctly. You need a set of tools to assist in determining when results are not correct or are unacceptable.

Creating good test data is an art. You cannot simply take a subset of actual data and use it‑you must ensure that you have anticipated all the situations the data and user will be facing. Create your test scenarios with the user. It is not important or necessary to have large volumes of data in fact, keep the number of records small. Know the expected results of performing each module in the application, then check and recheck your data after each phase of your application testing. Large sets of data can be reserved for performance testing. Testing also verifies your design and determines whether you have included all the features the user requested.

Including the users in the testing phase is highly recommended. Waiting until the product is complete before showing the user can be white knuckle time. You dont want to find out if you did or didn't give your users/customers what they requested at final delivery. This phase of testing shakes out any oversights in the initial system testing and prevents unwanted surprises showing up when the application is put into production. Depending on the size of the project, include multiple beta test cycles where additional modules are added then have a final test phase where all completed modules are tested end-to-end. If replacing an existing automated system, parallel testing may also be warranted.

Documentation  technical, system, user

Documenting an application is often the most overlooked piece of the application lifecycle‑or at the very least, the component that is put off until the last moment. Create the appropriate documentation as pieces of the system are being designed and coded. The major types of documentation are:

7        System documentation

7        Application documentation

7        User documentation

Implementation  production release

The final component of the application lifecycle is implementation. Install the system in the users' actual environment and begin production use of the application.

Part of implementation is training the users to use all aspects of the system. This is where your user documentation is put to use. Training is minimized if your application design includes an interface that is intuitive, complete with a help system that answers most of the users' most common questions. Some of the training should occur during the beta testing phase for testing team members. Full training may also occur before the production switch is turned on.

Once the user accepts the application and the system is put into production, the project becomes one of maintenance, performance tuning, and enhancements.

Rules of engagement  setting expectations

Contents

Independent of the number of steps you define for your lifecycle and what management methodologies you employ, unless you clearly and concisely define how you interact with the client and ensure both sides understand each other, expectations will not be met. Defining these rules of engagement upfront in a manner that is proactive to the project will go a long way in making the process smother and more successful.

These rules are not hard and fast must-do items, but a well-communicated approach so the decision-makers and those in the information exchange side of the project understand how to share knowledge and expectations so progress is not impeded. Some of the critical items to define are:

7        How to communicate with clients and keep them informed

7        A single point of contact

7        Setting up realistic expectations and how to meet them

7        Define project risks and contingencies

7        Include rework as part of the plan

7        Dealing with scope expansion

How to communicate is critical. The point here is to define the type of communication, how formal and what frequency. If the team is centrally located, face-to-face meetings facilitate status and information exchange. Geographically dispersed team members can use phone, email or video teleconferencing technology. The type and frequency may be dependent on the clients comfort zone. Formal reports and email usage should be defined up-front as potential tools.

A single point-of-contact is critical to ensure the flow of information is maintained, and nothing is lost. This also reduces the confusion when trying to determine who is the contact person and the decision maker. Having a focal point on the user side and the development side allows all communication to funnel between the two parties to eliminate miscommunication and eliminates potential confusion on who to contact.

The design/specification document should not be relied upon as the single communication of what clients should expect from the development team. It is beneficial to clearly communicate with the client before the project begins how you manage projects and what you feel are the key elements to a successful project.

In the book, Software Project Survival Guide by Steve McConnell, there is a set of questions that he includes to test the potential success of a project. There are five major areas:

7        Requirements

7        Planning

7        Project Control

7        Risk Management

7        Personnel

In each of these sections the questions provide an excellent set of ideas that can assist you in defining your own rules of engagement. It is a great checklist for you to incorporate into your software project management. The following are samples of the types of questions in the list.

7        Does the project have a clear, unambiguous vision statement or mission statement?

7        Does the project have a detailed, written specification of what the software is supposed to do?

7        Did the project team interview people who will actually use the software (end users) early in the project and continue to involve them throughout the project?

7        Does the project have a detailed, written Quality Assurance Plan that requires design and code reviews in addition to system testing?

7        Was the project plan, including the schedule, approved by the development team, the quality assurance team, and the technical writing teamin other words, the people responsible for doing the work?

7        Has a single key executive who has decision-making authority been made responsible for the project, and does the project have that persons active support?

7        Does the project have well-defined, detailed milestones ("binary milestones") that are considered to be either 100 percent done or 100 percent not done?

7        Does the project have a written plan for controlling changes to the softwares specification?

7        Does the project have a Change Control Board that has final authority to accept or reject proposed changes?

7        Does the project environment include the basic tools needed to complete the project, including defect tracking software, source code control, and project management software?

7        Does the project team have all the technical expertise needed to complete the project?

7        Does the project have a technical leader capable of leading the project successfully?

7        Does everyone work well together?

7        Is each person committed to the project?

McConnell uses the set of questions as a test on how well a project will succeed. He titles the questions Software Project Survival Test. For each question you rate the project from 0  3. The final score is a measurement baseline on the probability for success.

The list is also a good tool to use at the start of a project with a new client. In order for them to get an understanding how a software project should be done successfully, it is critical for them to know about areas such as risk management and change control. You can use this list or something similar to review with clients the critical areas of a successful software project and it communicates how you intend to work and what you feel are the critical areas that need to be implement be ensure success. Too many times clients believe software development is creating the requirements and coding to create the expected results.

The full set of questions and other good software project management suggestions can be found at www.construx.com/survivalguide.

What does done look like?

Contents

This seems like a simple question  what should the final delivery look like? You can start a project by defining all the requirement details which collectively define the end result, but the granularity of the requirements may not give an easy, compact, executive summary type statement of what the client wants.

An alternative approach is to ask the client what done means to them, what should it look like and contain. This could be considered an interviewing technique. By asking this question at the start, you will get the picture from their viewpoint, from which you can start to determine what they believe is critical and what the high-level expectations they have for the project. The hot-spots from their perspective are identified and from there you can drill-down into lower detail. Identifying these items critical to them allows you to build a better foundation to get the project on the right track from the beginning.

What is change control and why is it necessary?

Contents

In any software project there are changes. Changes can be due to many factors: varying markets, different technology, shift in budget, government regulations, new and modified user requirements, plus many more. One of the keys in this area of the project lifecycle is to manage the requested changes and dont let scope expansion take over the project. A common approach to managing this aspect of a project is to define a change control process. This process consists of a change board and a set of procedures to review requested modifications and add or reject the proposed change to the project schedule.

A change board consists of a number of people from the management, user and development groups associated with the project. The number should be limited to keep the group small enough to get the work done. The mission of a change board is to be the clearing house for changes to the project. They review requests made to the application design, determine if the change replaces an existing design item, adds to the design, the need for additional budget and what impact does the change have on the schedule.

The actual request for a change should be submitted in some form of a change request. The content of a change request consists of the following basic information:

7        Description of the change

7        Name of person or dept making the request

7        Estimate on effort required (time and costs)

7        Impact on schedule

7        Modifications to testing, test procedures and test data

7        Benefit of the change

7        Resource impact

7        Budget impact

7        Risk factors to add the change

Some of the areas need to be written by the requestor and others can only be done by one or more members of the team. The person or organization making the request should be able to clearly state the requirements and how they see this change improving the application and its use. If they cannot clearly state the expected benefits of the change then the change is not critical. The estimate, budget and schedule impact, and risks will need to be addressed by the change board or someone they designate.

Each change request should be estimated as to the effort required to complete the task. Some items can be estimated without too much effort to get a ball-park effort assessment. For larger change, you may need to approve some amount of time to investigate the item and create a more informed estimate. At a minimum, the change board approves the initial investigation to get an idea on the time and resource requirements. From these results the schedule, budget and risks are completed. At any stage during this process the change request can be rejected, postponed, or put on hold until the next phase of the project. Once approved, the project manager has to add the change into the schedule, update the project plan and assign resources.

You also dont want to stifle creativity. You also promote requests which should be turned into a wish list which will be considered for future releases. At a minimum, capturing the suggestion will prevent the idea from being lost.

Like most of the areas in managing the application lifecycle, there are commercial products available to assist in controlling the record keeping and status of changes. Borlands StarTeam contains a module for change request management.

Figure 2: StarTeam change request form

Figure 2 shows the change request form in StarTeam. The Synopsis tab is where the Status, Priority, Type, Synopsis (short explanation of the problem) and other primary fields are located. Figure 3 shows the Description tab where a more detailed explanation is entered.

Figure 3: StarTeam Description tab for a change request

StarTeam provides a complete tracking model for change requests. Figure 4 is a copy of the diagram from the StarTeam documentation showing the change request process. After a change request is submitted and assigned, it continues to cycle through the development and testing until the item is closed.

Figure 4: StarTeam change request tracking process

Application requirements are not the only portions of a project that can/should be put under the change control process. The following should be minimally considered as additional items that the change board or some subset of the board be responsible for managing changes:

7        The change control process itself

7        All documentation and style guides

7        Test scripts, test data, QA procedures

7        Change request forms, defect forms, signature document forms

To make a change control process successful, you need commitment from the entire team to change control at the start of the project and a defined, agreeable process that provides tracking and visibility of requested changes and their status.

Using test plans and test data

Contents

Testing is done throughout the project. Developers perform their unit-level testing as coding is worked. Modules are tested as portions are completed then moved into beta testing. The primary purpose of testing is to ensure the quality of the deliverable is as high as possible.

It is highly recommended that the testing topic be included at the beginning of the project. It is important to determine who is responsible for the test plan and the data to be used during the testing phase. Milestones need to be added to create the test plans and good test data. The plans and data need to be updated as change requests are approved and inserted into the project.

The test plans should be a series of tasks that verify the completed module comply with the specification document. Both manual and automated testing should be considered. With automated testing, modifications to a module can quickly be validated with the same suite of test each time they are run. It also reduces the time required to perform the validation. Manual test suites increase the testing timeframe while at the same time they allow for testers to see possible anomalies that automated testing will not find.

In the initial project plan stages, if clients do not want to pay for you to create test plans and test data, you need to force the issue or require that all testing has to be their responsibility. Once the client signs the acceptance document for the module or completed project, they agree that it works correctly. This may also be a decision point for you to reject working with a client that does not believe in this portion of a software lifecycle. If the client is not willing to create or assist in creating test plans/data or willing to add it as a milestone for the development team to create, you still need some type of plan and data to test what you build. If data migration is part of the project, at least there is some live data to use. If the application is automating an existing manual process, you can take copies of the paper system to create a minimum set of data for development testing.

Signature documents  are they really necessary?

Contents

As you deliver milestones for the project it is a good idea to use signature documents. These documents consist of a written acknowledgement of the item or work package delivered. It provides both a communication tool that the milestone/delivery is complete and a written record of acceptance by the user team.

Signature authority needs to be established at start of project. Both sides need to agree to this process, define who is responsible for signatures and what requires signature acceptance. A review of the major areas requiring signatures should be done and insert the signature documents milestones into the project plan.

Signature documents become part of the project audit trail. It ensures both sides that the item was completed, delivered, tested and accepted. This process may add additional tasks and paperwork, but it is a solid part of a sound, methodical software project.

Why the client should be responsible for beta testing and acceptance

Contents

Independent of who writes the test plans, the client needs to be responsible for testing the builds during the beta process. Without the clients involvement in testing, you dont get the validation you need that the delivered product meets the users expected solution.

During the testing phase, you will not only get feedback on defects, but the test users may find ways to improve the product. Even if they were part of the design team they may see the process differently when they touch the product and try to perform their daily tasks. Including users during the testing also gets key employees familiar with the system and trained to assist other employees when full production is started.

An important part of including users is the acceptance document. The intent here is to get the user to accept the modules tested and agree they work as designed. There will be a repetitive process as the defects are corrected but once fixed to the users satisfaction; the acceptance of the test module should be complete. During a multi-module test cycle, testing and accepting a module before including additional modules reduces the final acceptance testing timeframe.

The goal of users testing is to prevent getting to the production release and having the client state the product does not work. The major defects that prevent the product from working should have been found during testing. This is not to say there wont be any defects, but the users should believe, based on their testing, the product works as they expect and have minimal fears about moving into production. The signature document of acceptance is your evidence of that belief.

Defects  tracking, reporting and resolution

Contents

Unless you are writing a simple program such as Hello World, there will be some level of defects during the life of a project. These defects can be design errors, program errors, and problems with components, operating system or some other unexpected problem. Tracking, reporting and resolving the defects is necessary to improve the quality of the final delivery.

Defects should be recorded throughout the lifecycle. Some of the defects will be worked as part of the development rework cycle. This includes typical coding errors that get corrected as unit-level testing is done by the developer. When design defects are encountered during development, they need to be documented and added to the defect list. Defects discovered during the testing phase also need to be recorded and returned to the development team for correction.

Typical items included in a defect report include:

7        Description of the defect

7        Module/form/report that has the defect

7        How to reproduce the problem  what steps can be repeated

7        Build defect found in

7        What is the machine type, OS, memory

7        Who reported defect and on what date

7        Severity of the error (range from crashes machine to spelling error for a label)

7        Screen shot of the defect if applicable

The defect also needs the following information included to track the item:

7        Defect number

7        Status

7        Who defect assigned to

7        Estimate on time to correct

7        Date corrected

7        Developer notes

7        Link to change request as a result of defect

Not all defects are immediately returned to the development team. Any defect which is the result of a coding error or incorrect implementation of the design should go back to the developer for correction. Some defects can be caused by the OS, DBMS, third-party components, etc. These types of defects may require design changes or communication with the vendor for a product update. Other defects may be actual change requests. These items need to be sent to the change board for evaluation and a determination that the reported item is not a defect and is placed into the change order process.

Classifying the severity of a defect is something that is also good to establish upfront with the client. Create a rating system of the severity level and assign the level appropriate for the defect. Determine which levels have to be corrected before shipping the product. Here the review process with the user determines which defects the will live with, if any, before moving to production.

The change request form shown earlier in StarTeam doubles as a defect report. The Type field supports both change requests (Suggestion) and defects (value of Defect). Figure 5 shows the StarTeam Change Request tab where you can see the mixture of change requests and defects.

Figure 5: StarTeam Change Request tab

When the project is delivered, you are done, right?

Contents

Once the team agrees to turn on the production switch and the installation is up and running, it doesnt mean the work is over. There will always be additional defects and changes for the product delivered. If you are an external developer you have to fulfill the warranty and other contractual arrangement you agreed to with the client. You will hopefully be getting additional work from the client and you will be able to start another project. Internal developers get ready for the maintenance release and product enhancements.

Part of the post-implementation is to review the entire project lifecycle. This could be called a post-mortem. Here you want to review the different aspects of the project, learn what worked and what didnt work, what not to do again, how to fine-tune your project plans, how the tools and products you used to code the application worked, team-member perspective, and the interchange with the client. Have a meeting with the development team to share these areas and allow time for free discussion on the project. The results of this review will assist you by sharpening your software project skills and improve your success in managing your next software project lifecycle.

Summary

Contents

There are many aspects of ensuring the success of a software project lifecycle; however you define the major components of the process. You can glean from each technique described in a multitude of books and classes how to improve your success. The key points to the technique you employ are:

7        have a clearly defined written plan

7        communicate to the client your methodology for managing software projects

7        set expectations and risks, get agreement on those expectations and risk contingencies

7        agree to signature documents and what requires signatures

7        a single point of contact

7        solid test plans and test data where the client is participating

7        a change control process

7        a defect tracking, reporting and resolution process

7        get it in writing  definitions, expectations, and acceptance of completed work

7        learn as the project moves through the lifecycle


Published on: 10/11/2004 2:19:56 PM

Server Response from: ETNASC03

Copyright© 1994 - 2013 Embarcadero Technologies, Inc. All rights reserved.