Project Management Intro

Introduction

Project planning and management are required in all software projects, big and small. The larger the project, the more important and the more complicated the planning and management process become.

As part of this course, you will be doing Project Management, including the five states of the SDLC model listed below.)

Whether the application is for a phone, a desktop program or an internet site, there are often requirements for user interactions, data entry, data storage and retrieval, reports, etc. Almost all applications require some type of data storage and retrieval, such as local and/or remote databases. The result of these many requirements and deliverables is that there are many moving parts to manage in the overall process of completing such a project.

The purpose of software project planning and management are to define, guide, and track the progress of the development process. Although they are often parts of a larger application project, database design and development are specialized types of software development.

The broad, overall process of how software is developed, tested, deployed and maintained is called the Software Development Life Cycle (SDLC). The purpose of the SDLC is to describe how organizations plan, generate requirements, prioritize and undertake development, test and fix their products, deploy applications, identity and handle enhancements, and ultimately retire or replace software. This process often varies from organization to organization.

Generally, the SDLC has six basic phases, as outlined below:

  • Planning
  • Defining
  • Designing
  • Building
  • Testing
  • Deploying
Software Development Life Cycle

Figure 1: Software Development Life Cycle (SDLC)

The SDLC is depicted as a cycle because the sub-processes often occur multiple times, and once the overall cycle is complete, if begins again - as the application is upgraded and maintained.

Planning: Involves a wide range of tasks.

  • Who works on the projects. What are the teams for the various phases?
  • Who are major stakeholders?
  • When and d how will meetings be conducted? How are stakeholders kept up-to-date?
  • What is the timeline and budget? What are the major milestones that must be met to be successful?
  • How is progress tracked?
  • Who will gather requirements, design the application and do the coding? Will external firms be hired to complete the coding, for example?
  • What is the project and application scope? Is this an Internet app, intranet app, desktop app, phone app or some mix of these?

Defining: Must provide all the specifications about how everything needs to work.

  • What are the system requirements, performance requirements, security requirements, etc.
  • What does each screen or view look like? What must it do?
  • What are the colors, fonts, and languages that must be used?
  • What is the branding? What images and other graphics should be used?
  • What are the development standards for the user interface, coding, testing, commenting, version control, etc.?

Designing: Translates requirements into features.

  • How will each view be created to meet the look and operation requirements?
  • Develops wireframes to visually illustrate what user interface views will look like.
  • Creates or obtains graphics, logos, fonts, and other visual tools.

Building

  • Creates front-end, middleware, and backend (database) objects and code to fulfill requirements
  • Builds libraries , API's, and other tools, as needed.
  • Performs initial testing for usability, reliability and performance.
  • Documents code, as needed. Maintains version control of all code.

Testing

  • Develops and documents testing plans (in conjunction with Defining and Building)
  • Creates and executes testing, as needed.
  • Simulates both successful tests, AND tries to make the software fail
  • Documents results and provides feedback as needed to other groups.

Deploying

  • Preparing for version upgrades
  • Moving code from Development to Staging to Production
  • Manage version control, backups and restoring code
  • Customer support for issues

Project Management Models

We will consider two basic models of development:

  • The Waterfall model
  • The Cyclical Development Model

Waterfall Model

The Waterfall Model describes a process where each SDLC phase is completed and leads to the next phase beginning. Each phase "falls" to the next phase, with the the work and requirements dropping into the next phase.

Waterfall Development Model

Figure 2: Waterfall Development Model Illustration

The basic idea of the Waterfall Model is that the project is a linear progression of steps, from Planning to Deploying.

The Waterfall Model works well when each process has well known requirements, work loads and outcomes, and/or the project is small and can be delivered quickly. An example might be cloning a simple app to create a very similar version from existing code.

This model was more common during the early days of software development, but often suffered from problems. A large project, for example, might take a year to gather requirements, 6 months to design the application, and year to complete the coding and testing. After two and half years, the product was released, and was often immediately obsolete. Business needs, customer requirements, and technologies often changed over the long development and testing periods.

Cyclical Development

This model describes a process that is highly cyclical. The SDLC still describes the overall process, but within each phase are additional cycles that may continually restart.


Figure 3: SDLC Cyclical Model

The idea behind the Cyclical Model is that each phase has its own cycles, where certain processes may continually restart. There are many variations of this model, such as Rapid Application Development (RAD) and Agile. The important concepts, and differences with the Waterfall Model, are these:

  • Each phase does not necessarily end before the next one starts
  • A phase may backfeed and restart a cycle in a prior phase
  • Parts of the project may move through phases and progress at different rate

Cyclical Development has become favored over the Waterfall Model to avoid problems with changing requirements and other issues where development and deployment fell out of sync with the market and customer requirements.

Consider the following diagram for a simple To-Do application using images. The application concept only involves two features, 1) a list of current tasks, and 2) a way to add a task with an image from the Internet.

Once the planning is complete, each user interface view needs to be defined. The user interface requirements are passed to the Designing group, which creates wireframes and other specifications for how the user interface should look and work. These specifications are then passed to the Building (Coding) group, which creates prototypes to be tested. In this example, the Task List user interface is approved and could be deployed. However, the testing for the Add Task feature fails and goes all the way back to the Defining stage to be reconsidered. Perhaps pulling images was too slow or encountered other issues; perhaps the view was not user friendly. Version 2 (V2) of the user interface is redefined and passed to Designing and then Building groups again , and they complete a new prototype for Testing. Again, testing fails; but this time the problem is with runtime errors and code failures, so it is sent back to Building.

The point, is that in a Cyclical Model, each phase of the SDLC is more independent. The entire design phase does not have to complete before building can begin. Parts of the project can move at different rates. Some parts of the project may recycle between phases.

Versions of the cyclical model place emphasis on different project objectives, such as developing and deploying small features quickly, or maximizing customer involvement in defining requirements and testing.

Example of Cyclical Model Flow

Figure 4: SDLC Cyclical Model Example

When starting a new database project, one of the first questions is “what type of information does the data base need to contain?”

Sometimes, the analysis has already been done by someone else and there exists a very specific set of requirements that can be used to define the database. Other times, we start more or less from scratch, and we have to develop the list of requirements by asking lots of questions and performing other types of analysis.

Databases rarely exist on their own. They are usually part of a larger application, such as a web site. As such, questions about “what does the database need to do” are related to what the larger application needs to do. In these cases, the application designers and developers may provide the requirements for the database as they define the requirements for the application.

Because many projects start and depend on the how the application is defined, we will concentrate on that initially as we discuss the process of gathering information.

A Note of Roles

Depending on the size of a project, a person may participate in many phases of the SDLC - or only a single phase.

For a very large project, there may be web designers that only work on how the views look and work. Or they may only work on reports. Database designers may create tables, but not code. Database developers may only work on code, but not analyze or create tables.

On a smaller project, participants may get involved in most aspects of the project. A developer, for instance, my create the HTML views, write JavaScript for the UI, create middleware code, create and populates tables, write database code, and do testing.

In either scenario, it is helpful to know aspects of all the jobs, because collaboration is always an important aspects of any project. Understanding the strengths and pitfalls of a database design can assist both the web design team, the middleware coders, and the database team, to make the overall application work as effectively and efficiently as possible.