PROJECT MANAGEMENT

As part of my Project Management studies, I used the Software Development Life Cycle (SDLC) as a framework for these documents. The headlines provide continuity because the documents themselves are moments from separate projects.

1. Mission, Vision, and Project Management
2. Case Analysis
3. Software Development Life Cycle
4. Work Breakdown Structure (WBS)
5. Descriptions, Specifications, and Design Patterns
6. Project Documentation

Mission, Vision, and Project Management

Project Management  produces deliverables, both tangible and intangible. If a project were a corporation, or a department within a corporation, then it would have a mission, a vision, and a goal: to make products. These document provide links between applied project management theory and the practice of creating products.

Case Analysis

Software Development Life Cycle

The difference between the Software Development Life Cycle (SDLC) and the Information Technology Infrastructure Library (ITIL) is partially philosophical. Are you a programmer that creates software systems, or are you a developer that maintains a library of assets for an overarching organization? Is this the difference between the data systems professional and the information technology worker?

Either way, information storage and retrieval is still a requirement.  Some software that interacts with data storage is object-oriented and intuitive, and other types of software are procedural. 

This document describes the steps associated with defining and developing new software.

The Software Development Life Cycle File Size: 176 kb File Type: pdf Download File

Work Breakdown Structure (WBS)

 The classroom enables the exploration of Project Management while creating a real project. Applied theory and practical applications may result in products that are of use at the college or in the local community. This Work Breakdown Structure is the blueprint for the work associated with an awareness campaign.

Water Bottle Awareness Campaign WBS File Size: 262 kb File Type: pdf Download File

 Descriptions, Specifications, and Design Patterns

If a company receives a Request For Information or Request For Proposal, then it develops a Project Specification document that describes how they would provide a solution. If they win the bid, they customize and implement this solution.

Documents that are based on the Project Specification include Business Requirements and Specifications, Program Descriptions, and design patterns. The level of detail for this set of documents is implied by whether the docs are intended for internal or external clients.  There are occasions where the stakeholders do not need the detail, but their employees do. Likewise, not every business is required to author written documents for every step of the project.

• Business Requirements describe the needs for which this project will provide solutions.
• Specifications describe the solution, possibly at a system level.
• Project Descriptions and Program descriptions are more detailed than specifications.  Sometimes these documents are human-readable procedures that the solution will automate, and sometimes they are the commentary around which the software is generated.
• Design patterns provide guidance as to how to implement the code. They may be best practices that the programmer can use to solve common problems, or they may be non-language-specific outlines of the code that the programmer will author.  Design patterns may work like blueprints, so they are not always project-specific. This increases their re-usability across projects and programs.

Project Documentation

Last, but not least, is the documentation - the English Language Description of the tasks that the software performs.  It is associated with every milestone within the project. It maintains the general flow of information and may serve as a prototype; it is often the first project deliverable that the client has the opportunity to view. There should be a one-to-one correspondence between the documentation, the system design, and the resulting software. Design principles may not be immediately apparent, but should be visible to those who know to look for them. The audience can be the developer who maintains the code, the client who requested the system, or the users of the system.