This is the third part in continuation to my earlier post Goal
Management -
Goal Management - Goal partitioning for Elaboration phase
The goals that are set in the construction pahse is looking at the business goal of delivering some usable system to the end user or consumer. The goals in this phase are broadly:
* To describe the remaining requirements
* To flesh out the design of your system
* To ensure that your system meets the needs of its users and fits into your organization's overall system portfolio
* To complete component development and testing, including both the software product and its documentation
* To minimize development costs by optimizing resources
* To achieve adequate quality as rapidly as possible
* To develop useful versions of your system (alpha, beta, …)
During the Construction phase, your project team will focus on evolving the technical prototype that you developed during the Elaboration phase into the full fledged system. As a result, your team will:
* Achieve and maintain adequate quality in your work as early as possible
* Develop software models that are sufficient to guide the implementation of your system
* Work closely with your user community to validate that your work meets their needs
* Implement and test the various components of your system
* Develop useful versions of your system as early as is practical
* Baseline the validated components and
* Manage the risks, people, and other project resources effectively.
As you work towards your goals, you will create and/or evolve a wide variety of artifacts:
* Revised requirements model (use cases, supplementary specifications) describing what you intend to build
* Revised project−level software architecture documents (SAD)
* Detailed software design models showing how your system is built
* Executable system ready for beta release to your user community
* Revised project schedule, estimate, and risk list from which to manage your project
* Revised team environment definition (tools, processes, guidelines, standards, etc.) indicating the tools and techniques that your team will use
* User, support, and operations documentation that is ready to be beta tested.
This is the second part in continuation to my earlier post Goal Management - Goal partitioning for Inception phase
While the team identifies requirements in the inception phase and also find out the business risk of the project during the same, the elaboration phase is the time when the technical risks are supposed to be unearthed and mitigated. So definitely the goal in this phase is to elaborate the system technically. This includes:
* To elaborate the system's technical requirements
* To establish the architecture (establish different views of the system).
* To establish the QOS and all non-functional requirements
* To take judgemental approach to meet the non-functional requirements optimally
* To make sure that the change in the mix of the factors of non-functional requirements can be done in future
* To unearth any possible technical bottlenecks or hurdles (by taking up proof of concepts)
The Elaboration phase is the second of six phases -- Inception, Elaboration, Construction, Transition, Production , and Retirement -- that a system experiences throughout its complete lifecycle. This phase has several goals:
* To produce a proven, architectural baseline for your system
* To evolve your requirements model to the "80% completion point"
* To develop a coarse-grained project plan for the entire Construction phase
* To ensure that the critical tools, processes, standards, and guidelines have been put in place for the Construction phase
* To understand and eliminate the high-priority risks of your project
Goal Management in iterative development process is a multi step process. Starting from partitioning the goals into phases and then from phases to iterations is a critical process.
Goal partitioning into phases:
The phases are Inception, Elaboration, Construction and Transition. Now how to partition the goals of the project into these phases? Let discuss it from phase to phase:
1. Goal partitioning for Inception phase
Inception is a phase in which the team basically identifies the requirement for the system. This is the phase in which the feasibility of the project comes up. It gives insight to the complexity of requirements and possible technical challenges. So which goals are to be partitioned into this phase? The primary objective of this phase are:
* To describe the initial requirements
* To develop and justify the business case for the system
* To determine the scope of your system
* To identify the people, organizations, and external systems that will interact with your system
* To develop an initial risk assessment, schedule, and estimate for your system
* To develop an initial tailoring of the Unified Process to meet your exact needs
The primary goal of the Inception phase is to set a firm foundation for your project. To accomplish this, we will need to:
* justify both the system itself and your approach to developing/obtaining the system,
* describe the initial requirements for your system,
* determine the scope of your system,
* identify the people, organizations, and external systems that will interact with your system,
* develop an initial risk assessment, schedule, and estimate for your system, and
* develop an initial tailoring of the Unified Process to meet your exact needs.
So if we look at this, this phase actually adds to the goal of the project itself. It basically provides input and a base for the rest of the phases. The artifacts that might come out of this phase are:
* A vision document
* An initial requirements model (10–20% complete)
* An initial project glossary
* A business case
* An initial domain model (optional)
* An initial business model (optional)
* A development case describing your project's tailored software process (optional)
* An architectural prototype (optional)
So if we try to partition our project goals to this phase, we shall have to take up those goals that are primarily for the achievement in business functionality. But we can not take out rest of them. So we hardly partition the goals in this phase. We on the other hand give concrete form to the project goals in this phase.
Many enterprise IT organizations are tackling large, complex efforts that combine the delivery of software elements, new and changed business models, and overall changes to organizational structure and capabilities. Typically these efforts involve several parallel projects, and managers are finding that "traditional" project management approaches fall short for such undertakings. Consequently, many IT professionals are turning to the substantial body of experience, and the smaller body of documentation, that supports the discipline of program management. This discipline describes principles, strategies, and desirable results for managing large-scale efforts comprising parallel projects.
This article considers five major aspects of program management:
Governance: Defining roles and responsibilities, and providing oversight
Management: Planning and administering both projects and the overall program
Financial management: Implementation of specific fiscal practices and controls
Infrastructure: The program office, technology, and other factors in the work environment supporting the program effort
Planning: Activities that take place at multiple levels, with different goals. The program plan is not a traditional plan
Have a detailed and interesting view available on the following URL:
[
http://www.ibm.com/developerworks/rational/library/4751.html]