Signing in with Google+ for Android

First step is to go to the Google Developers Console (https://console.developers.google.com/project) and create project as well as Client ID.

Second step would be adding some permissions in AndroidManifest.xml to access Google+ API, account name as part of sign in, OAuth 2.0 tokens or invalidate tokens to disconnect. The following permissions should be requested.

<uses-permission android:name="android.permission.INTERNET" />

<uses-permission android:name="android.permission.GET_ACCOUNTS" />

<uses-permission android:name="android.permission.USE_CREDENTIALS" />

Now we're ready to add some codes to initialize GoogleApiClient.
Some might wonder what GoogleApiClient really does, it basically wraps a ServiceConnection to Google Play services, this GoogleApiClient object is used to communicate with Google+ API and becomes functional after the asynchronous connection has been established with the service, and typically GoogleApiClient is managed like this:
- initialize GoogleApiClient in Activity.onCreate()
- invoke GoogleApiClient.connect() during Activity.onStart()
- invoke GoolgeApiClient.disconnect() during Acitivity.onStop()

import com.google.android.gms.common.ConnectionResult;
import com.google.android.gms.common.api.GoogleApiClient;
import com.google.android.gms.common.api.GoogleApiClient.ConnectionCallbacks;
import com.google.android.gms.common.api.GoogleApiClient.OnConnectionFailedListener;
import com.google.android.gms.plus.Plus;

public class PlusActivity extends Activity 
        implements ConnectionCallbacks, OnConnectionFailedListener {

 /* Request code used to invoke sign in user interactions. */
 private static final int RC_SIGN_IN = 0;

 private GoogleApiClient mGoogleClient;

 private ProgressDialog mConnectionProgressDialog;

 /*
  * A flag indicating that a PendingIntent is in progress and prevents us
  * from starting further intents.
  */
 private boolean mIntentInProgress;

 @Override
 protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);

  mGoogleClient = new GoogleApiClient.Builder(this).addApi(Plus.API)
    .addScope(Plus.SCOPE_PLUS_LOGIN).addConnectionCallbacks(this)
    .addOnConnectionFailedListener(this).build();

  mConnectionProgressDialog = new ProgressDialog(this);
  mConnectionProgressDialog.setMessage("Signing in...");
 }

 @Override
 protected void onStart() {
  super.onStart();
  mGoogleClient.connect();
 }

 @Override
 protected void onStop() {
  super.onStop();

  if (mGoogleClient.isConnected()) {
   mGoogleClient.disconnect();
  }
 }

 @Override
 protected void onActivityResult(int requestCode, int responseCode, Intent intent) {
  if (requestCode == RC_SIGN_IN) {
   mIntentInProgress = false;

   if (!mGoogleClient.isConnecting()) {
    mGoogleClient.connect();
   }
  }
 }

 @Override
 public void onConnectionFailed(ConnectionResult connectionResult) {
  Toast.makeText(this, "GoogleAPIClient Failed to Connect", Toast.LENGTH_SHORT).show();

  if (!mIntentInProgress && connectionResult.hasResolution()) {
   try {
    mIntentInProgress = true;
    startIntentSenderForResult(connectionResult.getResolution().getIntentSender(), RC_SIGN_IN, null, 0, 0, 0);
   } catch (SendIntentException e) {
    mIntentInProgress = false;
    mGoogleClient.connect();
   }
  }
 }

 @Override
 public void onConnected(Bundle bundle) {
  Toast.makeText(this, "GoogleAPIClient Connected", Toast.LENGTH_SHORT).show();
  mConnectionProgressDialog.dismiss();
 }

 @Override
 public void onConnectionSuspended(int arg0) {
  Toast.makeText(this, "GoogleAPIClient Connection Suspended", Toast.LENGTH_SHORT).show();
  mGoogleClient.connect();
 }
}

This is it, we done signing in Google+, will try to add some codes for accessing Google+ API to post some comments, retrieving friends list next time.

Add Maps to application (Google Maps)

The key class when working with a map object is the GoogleMap class, models the map object within application. Within UI, a map will be represented by either a MapFragment or MapView object.

Google Map handles the following operations automatically

• connecting to the Google Maps service
• downloading map tiles
• displaying tiles on the device screen
• displaying various controls such as pan & zoom
• responding to pan & zoom gestures by moving the map and zooming in/out

Google Maps provides four types of maps: Normal, Hybrid, Satellite, Terrain.
To set the type of a map, use setMapType() of GoogleMap object.

mGoogleMap.setMapType(GoogleMap.MAP_TYPE_HYBRID);

Basic steps for adding a map to an Android application
1. Add a fragment
Add a <fragment> element to the Activity's layout file to define a Fragment object, and set android:name attribute to "com.google.android.gms.maps.MapFragment. This will attach a MapFragment to the Activity automatically.

<fragment xmlns:android="http://schemas.android.com/apk/res/android"
  android:id="@+id/map"
  android:name="com.google.android.gms.maps.MapFragment"
  android:layout_width="match_parent"
  android:layout_height="match_parent" />

We can also add a MapFragment to an Activity in code like the following:

mMapFragment = MapFragment.newInstance();
FragmentTransaction fragmentTransaction = getFragmentManager().beginTransaction();
fragmentTransaction.add(R.id.my_container, mMapFragment);
fragmentTransaction.commit();

2. Add map code
After setting the layout file as the content view for the Activity, get a handle to the map by calling findFragmentById() to set some initial options for the map.

mGoogleMap = ((MapFragment) getFragmentManager().findFragmentById(R.id.map)).getMap();

3. Verify map availability
Before interacting with a GoogleMap object, we need to make sure that an object can be instantiated.
Check the following example code snippets, this methods can be called from both onCreate() and onResume() to ensure that the map is always available.

private void setupMapIfNeeded() {
  // null check to confirm that the map has not been instantiated
  if (mGoolgeMap == null) {
    mGoogleMap = ((MapFragment) getFragmentManager().findFragmentById(R.id.map)).getMap();
    
    if (mGoogleMap != null) {
       // verified, it's ok to manipulate the map
    }
  }
}

Supporting different layouts & bitmaps

Create different layouts for each screen size you want to support to optimize user experience. Each layout file should be saved into the appropriate resource directory, named with a -<screen_size> suffix.

e.g.
My Project
       - res/
             - layout/                     ==> default portrait
                         main.xml
             - layout-land              ==> landscape
                         main.xml
             - layout-large/            ==> large portrait
                         main.xml
             - layout-large-land     ==> large landscape
                         main.xml

The file names must be exactly the same, but their contents are different in order to provide an optimized UI for the corresponding screen size.


Providing bitmap resources that are properly scaled to each of generalized densities: low, medium, high, etc. will help to achieve good graphical quality and performance on all screen densities.

To generate images, start with raw resources in vector format and generate the images for each density using the following size scales:

• xxxhdpi: 4.0
• xxhdpi: 3.0
• xhdpi: 2.0
• hdpi: 1.5
• mdpi: 1.0 (baseline)
• ldpi: 0.75

If we generate a 200x200 image for xhdpi, we should generate the same resources in 150x150 for hdpi, 100x100 for mdpi, 300x300 for xxhdpi and then place them in the appropriate drawable resource directory:

e.g.

My Project

       - res/
             - drawable-xxhdpi/                  
                         example.png
             - drawable-xhdpi            
                         example.png
             - drawable-hdpi/
                         example.png
             - drawable-mdpi
                         example.png

Controlling App's Availability to Devices

Android supports a variety of features, some of them are hardware-based, some are software-based, and some are dependent on platform version. So app developer may need to control app's availability to devices based on app's required features.

We can restrict app's availability to devices through Google Play Store based on the following device characteristics:

1. Device features
2. Platform version
3. Screen configuration

Device features:

Android defines feature IDs for any hardware or software feature that may not be available on all devices. So we can prevent users from installing app when their devices don't provide a given feature by declaring it with a <uses-feature> element in app's manifest file.

e.g. declaring the compass sensor as required

<uses-feature android:name="android.hardware.sensor.compass"

                       android:required="true" />

Google Play Store compares the features app requires to the features available on user's device to determine whether the app is compatible with each device. If the device does not provide all the features, the user cannot install the app.

In case device features are not required for running app's primary functionality, then set the required attribute to "false"  and check for device feature at runtime.

PackageManager pm = getPackageManager();
if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
  // No compass available on this device, turn off the compass feature
  disableCompassFeature();
}

Platform version:

Different devices may run different versions of Android, which means new APIs of newer Android version may not be available on older versions of Android.

API level allows to declare the minimum version with which your app is compatible using <uses-sdk> element in app's manifest file.

e.g.
<uses-sdk android:minSdkVersion="14"
                 android:targetSdkVersion="19" />

minSdkVersion: declares the minimum version with which app is compatible
targetSdkVersion: declares the highest version on which app has been optimized

We can check the API level at runtime and gracefully degrade the corresponding features when the API level is too low.

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
  // running on something older than API 11, so disable features
  disableSomeFeature();
}

Screen configuration:
Android runs on devices of various sizes from smart phones to TVs. In order to categorize devices by screen type, Android defines two characteristics for each devices: screen size (physical size) and screen density (DPI)

• generalized sizes: small, normal, large and xlarge
• generalized densities: mdpi (medium), hdpi, xhdpi (extra high), xxhdpi (extra-extra high)

By default most apps are compatible with all screen sizes and densities because the system makes all the adjustments to UI layout and image resources as necessary for each screen. However we can optimize the user experience for each screen configuration by adding specialized layouts for different screen sizes and optimized bitmap images for common screen densities.

For more information in detail, check the following developers site:

http://developer.android.com/training/basics/supporting-devices/screens.html

How to use ActionProvider Or ShareActionProvider

ActionProvider can generate action views for use in the action bar, dynamically populate submenus of a MenuItem, and handle default menu item invocations.

Two ways to use an action provider:
- Set the action provider on a MenuItem directly by calling setActionProvider (ActionProvider)

- Declare the action provider in an XML menu resource.   e.g.
  <item
    android:id="@+id/action_search"
    android:title="Search"
    android:icon="@drawable/search_icon"
    android:showasaction="ifRoom"
    android:actionproviderclass="com.my.CustomActionProvider" />

Making a custom action provider is straightforward, simply extend ActionProvider class and implement its callback methods as appropriate. It should be implemented like below code example:

public class MyCustomActionProvider extends ActionProvider {
   private Context mContext;
   private EditText mEditText;

   public MyCustomActionProvider (Context context) {
     super(context);
     mContext = context;
   }

   @override
   public View onCreateActionView() {
     // Make & return View that will be shown when action bar icon pressed
     // Here we have a custom layout that contains EditText for Search

     LayoutInflator layout = LayoutInflator.from(mContext);
     View view = layout.inflate(R.layout.search_layout, null);
     mEditText = (EditText) view.findViewById(R.id.edit_search);
     ...................
   }

   ................
}

public class MainActivity extends Activity {
  private MyCustomActionProvider mActionProvider;
  ...........

  @override
  public boolean onCreateOptionsMenu(Menu menu) {
    getMenuInflater().inflate(R.menu.items, menu);
    MenuItem item = menu.findItem(R.id.action_search);
    mActionProvider = (MyCustomActionProvider) item.getActionProvider();
    ..............
  }
  
  ...........
}

Android also provides an implementation of ActionProvider for Share actions: ShareActionProvider, which facilitates a share action by showing a list of possible apps for sharing directly in the action bar.

To add a share action with ShareActionProvider, just define the tag  for an <item> android:actionproviderclass="android.widget.ShareActionProvider".

The last step left to do is to define the Intent what we want to use for sharing. How we do it? just modify onCreateOptionMenu() method.

// In Activity#onCreateOptionsMenu
 public boolean onCreateOptionsMenu(Menu menu) {
     // Get the menu item.
     MenuItem menuItem = menu.findItem(R.id.my_menu_item);
     // Get the provider and hold onto it to set/change the share intent.
     mShareActionProvider = (ShareActionProvider) menuItem.getActionProvider();
     // Set history different from the default before getting the action
     // view since a call to MenuItem.getActionView() calls
     // onCreateActionView() which uses the backing file name. Omit this
     // line if using the default share history file is desired.
     mShareActionProvider.setShareHistoryFileName("custom_share_history.xml");
     . . .
 }

 // Somewhere in the application.
 public void doShare(Intent shareIntent) {
     // When you want to share set the share intent.
     mShareActionProvider.setShareIntent(shareIntent);
 }

5. Project Scope Management (3)

5.3 Define Scope
Define Scope is the process of developing a detailed description of the project and product. The key benefit of this process is that it describes the product, service, or result boundaries by defining which of the requirements collected will be included in and excluded from the project scope.

Since all of the requirements identified in Collect Requirements may not be included in the project, the Define Scope process selects the final project requirements from the requirements documentation delivered during the Collect Requirements process. It then develops a detailed description of the project and product, service, or result.

The preparation of a detailed project scope statement is critical to project success and builds upon the major deliverables, assumptions, and constraints that are documented during project initiation. During project planning, the project scope is defined and described with greater specificity as more information about the project is known. Existing risks, assumptions, and constraints are analyzed for completeness and added or updated as necessary. The Define Scope process can be highly iterative. In iterative life cycle projects, a high-level vision will be developed for the overall project, but the detailed scope is determined one iteration at a time and the detailed planning for the next iteration is carried out as work progresses on the current project scope and deliverables.

Inputs
1) Scope management plan: a component of the project management plan that establishes the activities for developing, monitoring, and controlling the project scope.

2) Project charter: provides the high-level project description and product characteristics. It also contains project approval requirements. If a project charter is not used in the performing organization, then comparable information needs to be acquired or developed, and used as a basis for the detailed project scope management statement. Organizations that do not produce a formal project charter will usually perform an informal analysis to identify the content necessary for further scope planning.

3) Requirements documentation:  will be used to select the requirements that will be included in the project.

4) Organizational process assets: can influence how scope is defined
- Policies, procedures, and templates for a project scope statements;
- Project files from previous project; and
- Lessons learned from previous phrases or projects.

Tools & Techniques
1) Expert Judgment: used to analyze the information needed to develop the project scope statement. such judgement and expertise is applied to any technical detail.

2) Product Analysis: Each application area has one or more generally accepted methods for translating high-level product descriptions into tangible deliverables. Product analysis includes techniques such as product breakdown, systems analysis, requirements analysis, system engineering, value engineering, and value analsyis.

3) Alternatives Generation: used to develop as many potential options as possible in order to identify different approaches to execute and perform the work of the project. A variety of general management technique can be used, such as brainstorming, lateral thinking, analysis of alternatives, etc.

4) Facilitated Workshops: The participation of key players with a variety of expectations and/or fields of expertise in these intensive working sessions helps to reach a cross-functional and common understanding of the project objectives and its limits.

Outputs
1) Project Scope Statement: description of the project scope, major deliverables, assumptions, and constraints. The project scope statement documents the entire scope, including project and product scope. It describes, in detail, the project's deliverables and the work required to create those deliverables. It also provides a common understanding of the project scope among project stakeholders. It may contain explicit scope exclusions that can assist in managing stakeholder expectations. It enables the project team to peform more detailed planning, guides the project team's work during execution, and provides the baseline for evaluating whether requests for changes or additional work are contained within or outside the project's boundaries.

2) Project Document Updates: may be include
- Stakeholder register
- Requirements documentation and
- Requirements traceability matrix.

How to set/get Meta Data in AndroidManifest

In AndroidManifest.xml


Meta data defined in AndroidManifest.xml can be retrieved with some codes like this:

try {
    ApplicationInfo ai = getPackageManager().getApplicationInfo(activity.getPackageName(), PackageManager.GET_META_DATA);
    Bundle bundle = ai.metaData;
    String myApiKey = bundle.getString("com.myapp.version.api.key");
} catch (NameNotFoundException e) {
    Log.e(TAG, "Failed to load meta data : " + e.getMessage());
} catch (NullPointerException e) {
    Log.e(TAG, "Failed to load meta data : " + e.getMessage());         
}

How to check the package name of current launcher

Intent intent = new Intent(Intent.ACTION_MAIN);
intent.addCategory(Intent.CATEGORY_HOME);
ResolveInfo resolveInfo = getPackageManager().resolveActivity(intent, PackageManager.MATCH_DEFAULT_ONLY);
String packageName = resolveInfo.activityInfo.packageName;

How to take a snapshot in Google Map v2

// Once everything has loaded, cache the map’s image for fast display later
// Note: the map loaded callback is only called once.
mMap.setOnMapLoadedCallback(new GoogleMap.OnMapLoadedCallback() {
    public void onMapLoaded() {
        mMap.snapshot(new GoogleMap.SnapshotReadyCallback() {
            public void onSnapshotReady(Bitmap bitmap) {
                // Write image to disk
            }
        });
    }
});

Reference: http://googlegeodevelopers.blogspot.sg/2013/10/ghost-markers-in-your-neighborhood-new.html

How to change text color of SearchView

int textViewId = mSearchView.getContext().getResources().getIdentifier("android:id/search_src_text", null, null);
TextView textView = (TextView) mSearchView.findViewById(textViewId);
textView.setTextColor(Color.GRAY);

Useful Android Intents

Useful Android Intent List

1. Google Maps - get directions between two points

Uri uri = Uri.parse("http://maps.google.com/maps?f=d&saddr=0,0&daddr=10,10"));
Intent intent = new Intent(Intent.ACTION_VIEW, uri);
intent.setComponent(new ComponentName("com.google.android.apps.maps", "com.google.android.maps.MapsActivity"));
startActivity(intent);

2. Google Maps - show map

Uri uri = Uri.parse("geo:11.899533,-77.036476");
Intent it = new Intent(Intent.Action_VIEW, uri);
startActivity(it);

3. Call

Uri uri = Uri.parse("tel:xxxxxx");
Intent it = new Intent(Intent.ACTION_DIAL, uri);  
startActivity(it); 

OR

with permission 

Uri uri = Uri.parse("tel.xxxxxx");
Intent it = new Intent(Intent.ACTION_CALL,uri);

4. SMS/MMS

Uri uri = Uri.parse("smsto:0800000123");   
Intent it = new Intent(Intent.ACTION_SENDTO, uri);   
it.putExtra("sms_body", "The SMS text");   
startActivity(it); 

Uri uri = Uri.parse("content://media/external/images/media/23");   
Intent it = new Intent(Intent.ACTION_SEND);   
it.putExtra("sms_body", "some text");   
it.putExtra(Intent.EXTRA_STREAM, uri);   
it.setType("image/png");   
startActivity(it);

5. Email

Uri uri = Uri.parse("mailto:xxx@abc.com");
Intent it = new Intent(Intent.ACTION_SENDTO, uri);
startActivity(it);


Intent it = new Intent(Intent.ACTION_SEND);   
it.putExtra(Intent.EXTRA_EMAIL, "me@abc.com");   
it.putExtra(Intent.EXTRA_TEXT, "The email body text");   
it.setType("text/plain");   
startActivity(Intent.createChooser(it, "Choose Email Client")); 


Intent it = new Intent(Intent.ACTION_SEND);     
String[] tos = {"me@abc.com"};     
String[] ccs = {"you@abc.com"};     
it.putExtra(Intent.EXTRA_EMAIL, tos);     
it.putExtra(Intent.EXTRA_CC, ccs);     
it.putExtra(Intent.EXTRA_TEXT, "The email body text");     
it.putExtra(Intent.EXTRA_SUBJECT, "The email subject text");     
it.setType("message/rfc822");     
startActivity(Intent.createChooser(it, "Choose Email Client"));  


// Adding extra
Intent it = new Intent(Intent.ACTION_SEND);   
it.putExtra(Intent.EXTRA_SUBJECT, "The email subject text");   
it.putExtra(Intent.EXTRA_STREAM, "file:///sdcard/mysong.mp3");   
sendIntent.setType("audio/mp3");   
startActivity(Intent.createChooser(it, "Choose Email Client"));

6. Play Music

Intent it = new Intent(Intent.ACTION_VIEW);
Uri uri = Uri.parse("file:///sdcard/song.mp3");
it.setDataAndType(uri, "audio/mp3");
startActivity(it);


Uri uri = Uri.withAppendedPath(
MediaStore.Audio.Media.INTERNAL_CONTENT_URI, "1");   
Intent it = new Intent(Intent.ACTION_VIEW, uri);   
startActivity(it); 

7. Uninstall apk

Uri uri = Uri.fromParts("package", PackageName, null);   
Intent it = new Intent(Intent.ACTION_DELETE, uri);   
startActivity(it);

8. Search application in Google Play Store

Uri uri = Uri.parse("market://search?q=pname:pkg_name");  
Intent it = new Intent(Intent.ACTION_VIEW, uri);  
startActivity(it);  

9. Google Search

Intent intent = new Intent();
intent.setAction(Intent.ACTION_WEB_SEARCH);
intent.putExtra(SearchManager.QUERY,"searchString")
startActivity(intent);

5. Project Scope Management (2)

5.2 Collect Requirements
Collect Requirements is the process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.

The project success directly influenced by active stakeholder involvement in the discovery and decomposition of needs into requirements and by the care taken in determining, documenting, and managing the requirements of the product, service or results of the project. Requirements include conditions or capabilities that are to be met by the project or present in the product, service or result to satisfy an agreement or other formally imposed specification. Requirements become the foundation of the WBS, cost, schedule, quality planning and sometimes procurement are all based upon these requirements. The development of requirements begins with an analysis of the information contained in the project charter, the stakeholder register and stakeholder management plan.

Inputs
1) Scope management plan: provides clarity as to how project teams will determine which type of requirements need to be collected for the project.

2)Requirements management plan: provides the processes that will be used throughout the Collect Requirement process to define and document the stakeholder needs.

3)Stakeholder management plan: used to understand stakeholder communication requirements and the level of stakeholder engagement in order to assess and adapt to the level of stakeholder participation in requirement activities.

4) Project charter: used to provide the high level description of the product, service, or result of the project so that detailed requirements can be developed.

Tools & Techniques
1) Interview: Talking to stakeholders directly, typically performed by asking prepared and spontaneous questions and recording the responses.

2) Focus groups: trained moderator guides the group through an interactive discussion, designed to be more conversational than a one-to-one interview.

3) Facilitated workshop: focused sessions that bring key stakeholders together to define product requirements. Workshops are considered a primary technique for quickly defining cross-functional requirements and reconciling stakeholder differences. Because of their interactive group nature, well facilitated sessions can build trust, foster relationships, and improve communication among the participants, which can lead to increased stakeholder consensus. In addition issues can be discovered earlier and resolved more quickly than in individual sessions.

Joint application development (JAD)

• used in software development industry
• focus on bringing business subject matter experts and the development team together to improve software development process

Quality function deployment (QFD)

• helps determine critical characteristics for new product development
• starts by collection customer needs, also known as Voice of the Customer (VoC)
• collected needs are then objectively sorted and prioritized

4) Group creativity techniques: group activities can be organized to identify project and product requirements.

• Brainstorming - used to generate and collect multiple ideas, not include voting or prioritization.
• Nominal group technique - enhances brainstorming with a voting process used to rank most useful ideas
• Idea/mind mapping - ideas created through brainstorming are consolidated in a single map to reflect commonality and differences
• Affinity diagram - large numbers of ideas to be classified into groups for review and analysis
• Multicriteria decision analysis - utilizes a decision matrix to provide a systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas

5) Group decision making techniques: can be used to generate, classify and prioritize product requirements

• Unanimity - everyone agrees on a single course of action, one way to reach unanimity is the Delphi technique.
• Majority - more than 50%
• Plurality - largest block in a group decides, even if a majority is not achieved
• Dictatorship - one individual makes the decision

** Delphi technique: 

The experts answer questionnaires in two or more rounds. After each round, a facilitator provides an anonymous summary of the experts’ forecasts from the previous round as well as the reasons they provided for their judgments. Thus, experts are encouraged to revise their earlier answers in light of the replies of other members of their panel. It is believed that during this process the range of the answers will decrease and the group will converge towards the "correct" answer. Finally, the process is stopped after a pre-defined stop criterion.

(keywords: experts, questionnaire, anonymous) 

6) Questionnaires and surveys: written set of questions designed to quickly accumulate information from large number of respondents, appropriate with varied audiences, when respondents are geographically dispersed and where statistical analysis is appropriate.

8) Prototypes: obtains early feedback on requirements by providing a working model of the expected product before actually building it. allows stakeholders to experiment with a model of the final product rather than being limited to discussing abstract representations of their requirements.


Outputs
1) Requirements documentation: describes how individual requirements meet the business need for the project. Requirements may start out at a high level and become progressively more detailed as more about the requirements is known.

2) Requirements traceability matrix: a grid that links product requirements from their origin to the deliverables that satisfy them. The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives. It provides a meas to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally it provides a structure for managing changes to the product scope.

Tracing includes Business needs, goals, objectives, project scope/WBS deliverables, etc.

5. Project Scope Management (1)

Project Scope management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. Managing the project scope is primarily concerned with defining and controlling what is and is not included in the project.

In the project context, the term scope can refer to:

• Product scope: the features and functions that characterize a product, service or result
• Project scope: the work performed to deliver a product, service, or result with the specified features and functions. The term project scope is sometimes viewed as including product scope.

The scope baseline for the project is the approved version of the project scope statement, work breakdown structure (WBS), and its associated WBS dictionary. A baseline can be changed only through formal change control procedures and is used as a basis for comparison while performing Validate Scope and Control Scope processes as well as other controlling processes.

Completion of the project scope is measured against the Project management plan. Completion of the product scope is measured against the product requirements. The project scope management processes need to be well integrated with the other knowledge area processes, so that the work of the project will result in delivery of the specified product scope.

5.1 Plan Scope Management

Plan Scope Management is the process of creating a scope management plan that documents how the project scope will be defined, validated, and controlled.

The scope management plan is a component of the project or program management plan that describes how the scope will be defined, developed, monitored, controlled, and verified. The development of the scope management plan and the detailing of the project scope begin with the analysis of information contained in the project charter, the latest approved subsidiary plans of the project management plan, historical information contained in the organizational process assets, and any other relevant enterprise environment factors. This plan helps reduce the risk of project scope creep.

Inputs

1) Project management plan

Approved subsidiary plans of the project management plan are used to create the scope management plan and influence the approach taken for planning scope and managing project scope.

2) Project charter

Project charter is used to provide the project context needed to plan the scope management processes. It provides the high level project description and product characteristics from the project statement of work.

Outputs

1) Scope management plan

Scope management plan describes how the scope will be defined, developed, monitored, controlled and verified. Major input into the Develop Project Management Plan process, and the other scope management processes.

2) Requirements management plan

Requirement management plan is a component of the project management plan that describes how requirements will be analyzed, documented, and managed. 

4. Project Integration Management (6)

4.6 Close Project or Phase
Close Project or Phase is the process of finalizing all activities across all of the Project management process groups to formally complete the project or phase.

When closing the project, Project Manager reviews all prior information from the previous phase closures to ensure that all project work is completed and that the project has met its objectives. Since project scope is measured against the project management plan, the project manager reviews the scope baseline to ensure completion before considering the project closed. Close Project or Phase process also establishes the procedures to investigate and document the reason for actions taken if a project is terminated before completion. In order to successfully achieve this, the project manager needs to engage all the proper stakeholders in the process.

Inputs
1) Project management plan: agreement between the project manager and project sponsor, defining what constitutes project completion

2) Accepted deliverables: include approved product specifications, delivery receipts and work performance documents, Partial or interim deliverables may also be included for phased or cancelled projects.

3) Organizational process assets: OPA that can influence the Close Project or Phase process incl.
- Project or phase closure guidelines or requirements (e.g. admin procedures, project audits etc.)
- Historical information and lessons learned knowledge base (e.g. project records and documents etc.)

Tools & Techniques
1) Expert judgement: applied when performing administrative closure activities, these exports ensure that project or phase closure is performed to the appropriate standards.

2) Analytical technique:examples of analytical techniques used in project closeout are
- Regression analysis
- Trend analysis

3) Meetings: may be face-to-face, virtual, formal or informal. Types of meetings include lessons learned, closeout, user group and review meetings.

Outputs
1) Final product, service or result transition: this output refers to the transition of the final product, service or result that the project was authorized to produce.

2) OPA updates: OPA that are updated as a result of the Close Project or Phase process include project files, closure documents and historical information

4. Project Integration Management (5)

4.5 Perform Integrated Change Control
Perform Integrated Change Control is the process of reviewing all change requests; approving changes and managing changes to deliverables, organizational process assets, project documents, and the project management plan, and communicating their disposition.

This reviews all requests for changes or modifications to project documents, deliverables, baselines or project management plan and approves or rejects the changes.

Changes may be requested by any stakeholder involved with the project. Although changes may be initiated verbally , they should be recorded in written form and entered into the change management and/or configuration management system. Change requests are subject to the process specified in the change control and configuration control system. Those change request processes may require information on estimated time impacts and estimated cost impacts.

Every documented change request needs to be either approved or rejected by a responsible individual, usually the project sponsor or project manager or change control board (CCB)

Approved change requests can require new or revised cost estimates, activity sequences, schedule dates, resource requirements, and analysis of risk response alternatives. These changes can require adjustments to the project management plan and other project documents.

Inputs
1) Project management plan: elements of the project management plan that may be used include
- Scope management plan: contains the procedures for scope changes
- Scope baseline: provides product definition
- Change management plan: provides the direction for managing the change control process

Changes are documented and updated within the project management plan as part of the change and configuration management processes.

2) Work performance reports: include resource availability, schedule and cost data, earned value management (EVM) reports, and burn up or burn down charts.

3) Change requests: all of the Monitoring and controlling processes and many of the Executing processes produce change requests as an output. May include corrective action, preventive action or defect repairs.
However corrective and preventive actions do not normally affect the project baselines.

Tools & Techniques
1) Export judgement: in addition to the project management team's expert judgement, stakeholders may be asked to provide their expertise and may be asked to sit on the change control board (CCB).

2) Meetings: in this case these meetings are usually referred to as change control meetings. When needed for the project, a change control board (CCB) is responsible for meeting and reviewing the change requests and approving, rejecting, or other disposition of those changes. The R&R of these boards are clearly defined and agreed upon by appropriate stakeholders and documented in the change management plan.

3) Chang control tools: in order to facilitate configuration and change management, manual or automated tools may be used. Tool selection should based on the needs of the project stakeholders incl. organizational and environmental considerations and constraints.

Outputs
1) Approved change requests: change requests are processed according to the change control system by the project manager, CCB or by an assigned team member. Approved change requests will be implemented through the 4.3 Direct and Manage Project Work process. The disposition of all change requests, approved or not, will be updated in the change log as part of updates to the project documents.

2) Change log: a change log is used to document changes that occur during a project. These changes and their impact to the project in terms of time, cost, and risk, are communicated to the appropriate stakeholders. Rejected change requests are also captured in the change log.

3) Project management plan updates: any subsidiary plan and baselines that are subject to the formal change control process may be updated.

4) Project documents updates: may be updated as a result of the Perform Integrated Change Control process include all documents specified as being subject to the project's formal change control process.

4. Project Integration Management (4)

4.4 Monitor and Control Project Work
Monitor and Control Project Work is the process of tracking, reviewing, and reporting the process to meet the performance objectives defined in the project management plan.

Monitor and Control Project Work process is concerned with

• comparing actual project performance against the project management plan
• assessing performance to determine whether any corrective or preventive actions are indicated, and then recommending those actions as necessary
• identifying new risks and analyzing, tracking, and monitoring existing project risks to make sure the risks are identified, their status is reported, and that appropriate risk response plans are being executed
• maintaining an accurate, timely information base concerning the project's products and their associated document through project completion
• providing information to support status reporting, progress measurement, and forecasting
• providing forecasts to update current cost and current schedule information
• monitoring implementation of approved changes as they occur
• providing appropriate reporting on project progress and status to program management when the project is part of an overall program

Inputs
1) Project management plan: monitoring and controlling project work involves looking at all aspects of the project, subsidiary plans (Scope, requirements, schedule, cost, quality, etc.) within the project management plan form the basis for controlling the project

2) Schedule forecasts: forecasts are derived from progress against the schedule baseline and computed time estimate to complete (ETC). Forecasts are typically expressed in terms of schedule variance (SV) and schedule performance index (SPI).

3) Cost forecasts: forecasts are derived from progress against the cost baseline and computed cost estimates to complete (ETC). Expressed in terms of cost variance (CV) and cost performance index (CPI). An estimate at completion (EAC) can be compared to the budget at completion (BAC) to see if the project is still within tolerance ranges or if a change request is required.

4) Validated changes: approved changes that results from the Perform Integrated Change Control process require validation to ensure that the change was appropriately implemented. A validated change provides the necessary data to confirm that the change was appropriately executed.

5) Work Performance Information: performance data collected from various controlling processes, analyzed in context, and integrated based on relationships across areas. Work performance information (e.g. status of deliverables, implementation status for change requests, forecasts) is circulated through communication processes.

Tools and Techniques
2) Analytical techniques: applied in project management to forecast potential outcomes based on possible variations of project or environmental variables and their relationships with other variables.
- Regression analysis
- Grouping methods
- Causal/Root cause analysis
- Forecasting methods (e.g. time series, scenario building, simulation)
- Failure mode and effect analysis (FMEA)
- Fault tree analysis (FTA)
- Reserve/Trend/Variance analysis
- Earned value management (EVM)

Outputs
1) Change requests: as a result of comparing planned results to actual results, change requests may be issued to expand, adjust, or reduce project scope, product scope, or quality requirements and schedule or cost baselines. Change requests may necessitate the collection and documentation of new requirements. Changes can impact the project management plan, project documents or product deliverables. Changes that meet the project's change control criteria should go through the integrated change control process established for the project. Changes may include corrective, preventive actions and defect repair.

2) Work performance reports: physical or electronic representation of work performance information compiled in project documents, intended to generate decisions, actions, or awareness.

3) Project management plan updates: changes identified during the Monitor and control project work process may affect the overall project management plan. These changes, after being processed through the appropriate change control process can lead to project management plan updates.

4) Project documents updates: documents such as schedule and cost forecasts, work performance report, issue log, may be updated.

4. Project Integration Management (3)

4.3 Direct and Manage Project Work
Direct and Manage Project Work is the process of leading and performing the work defined in the project management plan and implementing approved changes to achieve the project's objectives.

Direct and Manage Project Work activities:

• perform activities to accomplish project objectives
• create project deliverables to meet the planned project work
• obtain, manage, and use resources incl. materials, tools, equipment, and facilities
• implement the planned methods and standards
• generate work performance data, such as cost, schedule, technical and quality progress, and status to facilitate forecasting
• issue change requests and implement approved changes into the project's scope, plans, and environment
• manage risks and implement risk response activities
• manage sellers & suppliers and stakeholders & their engagement
• collect and document lessons learned and implement approved process improvement activities

Direct and Manage Project Work process also requires review of the impact of all project changes and the implementation of approved changes:

• corrective action: realigns the performance of the project work with the project management plan
• preventive action: ensures the future performance of the project work is aligned with plan 
• defect repair: modify a nonconforming product or product component

Inputs
1) Project management plan: contains subsidiary plans,
- Scope management plan
- Requirements management plan
- Schedule management plan
- Cost management plan
- Stakeholder management plan

2) Approved change requests: outputs of the 4.5 Perform Integrated Change Control Process incl. those requests reviewed & approved by CCB (Change Control Board)
The approved change may be a corrective/preventive/defect repair, it can also modify project management plan or project documents.

Tools & Techniques
2) Project management Information System: part of EEF and provides tools such as a scheduling tools, configuration management system or information collection and distribution system.

Outputs
1) Deliverables: any unique and verifiable product, result. Typically tangible components completed to meet the project objectives and can include elements of the project management plan.

**Flow of deliverable
Defined Deliverable >> Approved Deliverable >> Verified Deliverable >> Accepted Deliverable
(4.2 Project management plan) >> (4.3 Direct and Manage Project Work) >> (8.3 Quality Control) >> (5.5 Verify Scope) >> (4.6 Close Project or Phase)

2) Work Performance Data: raw observation and measurements identified during activities.
data is gathered through work execution and passed to the controlling processes for further analysis
e.g. work completed, key performance indicators, performance measures, start/finish dates of activities etc.

3) Change Requests: formal proposal to modify any document, deliverable or baseline
- corrective action
- preventive action
- defect repair
- updates: changes to formally controlled project documents, plans etc., to reflect modified or additional ideas or content

4. 프로젝트 통합 관리 (2)

4.2 프로젝트 관리 계획서 개발 
Develop Project Management Plan is the process of defining, preparing, and coordinating all subsidiary plans and integrating them into a comprehensive project management plan.

프로젝트 관리 계획서 개발은 모든 보조 계획서들을 정의, 준비, 조정하고 관리 계획서에 통합하는 프로세스로써, 프로젝트가 종료될 때까지 점진적이고 구체적으로 개발되며 4.5 통합 변경 통제 수행을 통해서 승인된 내용도 지속적으로 업데이트 됨.

주요 Inputs
1) 프로젝트 헌장 - 4.1 에서 작성된 헌장에는 프로젝트 목적을 포함한 상위 수준의 정보가 포함되어 있어서 관리 계획서를 개발할 때 반드시 참조해야 함.

2) 다른 프로세스의 산출물 - 5. 범위 ~ 13. 이해관계자 관리의 기획 프로세스 산출물인 기준선 및 보조 관리 계획서들을 통합하여 관리 계획서를 작성함.
4.5 통합 변경 통제를 통해서 승인된 변경 사항을 업데이트하기도 함.

Outputs 
1) Project Management Plan
요약 또는 상세 수준으로 작성되며, 프로젝트의 실행, 감시 및 통제, 종료의 기준 문서로 활용
- 선정된 프로젝트 life cycle 및 각 단계 별 프로세스 포함
- 프로젝트 관리 프로세스, 도구 및 기법 등
- 변경 감시 및 통제를 위한 변경 관리 계획서
- 형상 관리 수행을 위한 형상 관리 계획서
- 이해 관계자들의 의사소통 요구 및 방법 등


프로젝트 수행의 기준 문서는 프로젝트 관리 계획서이고, 기타 다른 문서들은 프로젝트 문서라고 하며, 각각의 문서 예시는 아래와 같음.

4. 프로젝트 통합 관리 (1)

프로젝트 통합 관리는 관리 프로세스 그룹에 속하는 다양한 프로세스와 관리 활동들을 식별, 정의, 결합, 통합 및 조정하는데 필요한 프로세스와 활동들을 포함한다.

4.1 프로젝트 헌장 수립

• 프로젝트를 공식적으로 승인하고 PM에게 권한을 부여함.
• 요구 사항 수집, 상위 수준의 이해관계자/리스크 식별, 일정 및 원가 관리 계획서 등을 개발하기 위한 기준 문서로 활용됨.
• 프로젝트 헌장은 스폰서 조직이 작성하고 승인
• PM은 프로젝트 초기에 선임되어야 하며, 헌장을 개발하는 동안, 반드시 기획 프로세스를 시작하기 전에 선임되어야 함.

주요 투입물 (Inputs):

1) 작업 기술서 (Project Statement of Work ) - 프로젝트의 겨과로 제공해야 할 제품이나 서비스를 상세하게 기술한 문서, 승인된 프로젝트에서 할일에 대한 상위 수준의 요구 사항을 기록

- 비즈니스 요구 사항, 제품 범위 명세서, 조직 전략적 계획을 포함.

- 내부 프로젝트의 경우: 착수자나 스폰서가 비즈니스 요구, 제품 또는 서비스 요청 사항을 토대로 작업 기술서를 제공.

- 외부 프로젝트의 경우: 고객이 RFP, RFI, RFB와 같은 입찰/계약 서류의 일부로 작업 기술서 제출

2) 비즈니스 케이스 (Business Case)

조직의 비즈니스 관점에서 투자할 가치가 있는지 검토한 판단 근거를 기록한 문서 

- Cost-Benefit Analysis 를 통해서 제공

3) 협약서 (Agreements)

외부 고객을 위한 프로젝트를 수행할 때, 구매자/공급자 사이 자율적으로 협약한 내용이 포함된 광범위한 문서

4) 기업 환경 요인 (Enterprise Environmental Factors: EEF)

- 조직 외부 환경: 정부/산업 표준, 시장 여건

- 조직 내부 환경: 조직 문화/구조

5) 조직 프로세스 자산 (Organizational Process Assets: OPA)

- 프로세스와 절차: 조직의 표준 프로세스/정책, 프로젝트 헌장 개발 템플릿

- 조직 지식 기반: 선례 정보 및 습득한 교훈 지식 기반

도구 및 기법 (Tools & Techniques : T&T)

1) 전문가 판단 (Export Judgement: EJ)

해당 업무나 유사 업무에 대한 지식을 보유한 인적자원/전문가 시스템 활용

2) 촉진 기법 (Facilitation Techniques)

Facilitator (촉진자)가 주체가 되어 프로젝트 팀과 팀원이 활동을 수행하는 것을 돕는 기법

- Brainstorming

- 갈등/분쟁 해결 (Conflict Resolution)

- 문제 해결 (Problem Solving)

- 미팅/회의 관리 (Meeting management)

**산출물 (Outputs)

1) 프로젝트 헌장 (Project Charter) 

- 프로젝트의 시작을 알리는 공식적인 문서

- 시작 승인 및 재정을 지원할 수 있는 프로젝트 착수자 (Initiator)/스폰서 (Sponsor) 가 작성

- PM을 선임하고 조직의 자원을 투입할 수 있는 권한 부여

- 주요 이해 관계자들의 서명을 마지막에 받음

- 상위 수준의 프로젝트 목적, 요구사항, 제약 사항, 가정 사항 등 포함

3. 프로젝트 관리 프로세스

프로세스란 사전에 정의되어 있는 제품이나 서비스, 결과를 생성하고자 수행하는 관련 조치나 활동들로서 투입물, 적용할 수 있는 도구나 기법, 그리고 결과로 생성되는 산출물로 구성됨.

프로젝트 관리 프로세스 그룹 (또는 프로세스 그룹)은 아래와 같이 5개 그룹으로 구성됨.

1. 착수 (Initiating): 기존 프로젝트의 새로운 단계 또는 새 프로젝트 정의/승인 받아 시작
2. 기획 (Planning): 프로젝트의 범위 설정, 목표 구체화, 목표 달성을 위한 활동 계획/관리
3. 실행 (Executing): 프로젝트 명세서/관리 계획서에 정의된 작업 수행
4. 감시 및 통제 (Monitoring & Controlling): 진행 성과 추적/검토/조정/변경 등
5. 종료 (Closing): 모든 활동을 종료하는 과정에서 수행되며 프로젝트/단계 공식적으로 종료

프로세스 그룹의 특징:

1. 하나의 프로세스에서 수행된 조치는 해당 프로세스 및 다른 프로세스에도 영향을 미침
2. 프로세스 그룹은 각각의 산출물을 통해 서로 연결됨
3. 프로세스 산출물은 다른 프로세스의 Input/Output이 됨
4. 프로세스 그룹은 산업 전반에 적용되며 What만 정의해주고 How 등 가이드 제공은 하지 않음.

감시 및 통제 프로세스 그룹은 전체 실행 영역과 지속해서 상호 작용 함.

각 프로세스 그룹 및 지식 영역 별 프로세스의 관계는 아래 표에서 확인 가능.

* 착수 프로세스 그룹에서는 4.1 프로젝트 헌장 개발, 그리고 13.1 이해관계자 식별 프로세스가 중요.

* 종료 프로세스 그룹에서는 4.6 프로젝트 또는 단계 종료, 그리고 12.4 조달 종료 프로세스가 중요.

각 지식 영역 별 프로세스는 PMBOK 4장부터 설명이 되어 있으며, 위표에 표시되어 있는 각 프로세스 번호가 PMBOK의 장임.

[Binder] Native Service Example 2

I'll try to finish off Client part

class BpLcdService : public BpInterface
{
public:
 BpLcdService(const sp& impl): BpInterface(impl) {}

 virtual void LcdOn()
 {
  Parcel data, reply;
  remote()->transact(LCD_ON, data, &reply);
 }

 virtual void LcdOff()
 {
  Parcel data, reply;
  remote()->transact(LCD_OFF, data, &reply);
 }
};
IMPLEMENT_META_INTERFACE(LcdService, "android.app.lcdcontrol")

sp<ILcdService> LcdService()
{
sp<IBinder> binder = defaultServiceManager()->getService(String16("LcdService"));
return interface_cast<ILcdService>(binder);
}


This client does not have main() as I intended to make this as shared library file (.so) so I can call LcdOn/Off methods from Java application with Java Native Interface.

[Binder] Native Service Example 1

Here I'm going to make a native service for turning on/off LCD screen, and a client that make a request to the native service. At the end I will try to install a client application to my Android phone and see whether it actually work as intended.

Basically the flows looks like this:

Android uses some prefixes like Bp, Bn,
Bp stands for Binder Proxy (client side) whereas Bn stands for Binder Native, this one is for service server side. That's why we have BpLcdService, BnLcdService.

ok .. firstly in order to communicate between client and server, there should be some sort of protocol
so we define ILcdService that contains only two virtual methods. Whoever that use this protocol must provide LcdOn/Off methods.

class ILcdService : public IInterface
{
public:
       DECLARE_META_INTERFACE(LcdService)
       enum { LCD_ON = 1, LCD_OFF };

       virtual void LcdOn() = 0;
       virtual void LcdOff() = 0;
};

IInterface (in Android F/W) provides asBinder() method to convert the type of ILcdServce to IBinder. Why we need this conversion is that during IPC , IBinder type object will be stored in RPC data and sent to Binder driver. In other words say when registering LcdService to the System, Service Manager needs to send RPC data with service object (BBinder type) to Context Manager. In this process service will be converted to IBinder type and sent to Binder Driver.

What's Binder?

Everyone including app developers in Android world  may have heard about Binder, but I was wondering what exactly binder is and how that works. the following is what I've found so far.

Brief History of Binder?
Binder was originally made by George Hoffman as OpenBinder project for BeOS (I do not know why that lived for short time, will appreciate if anyone go find out and share some ideas/opinions)
Anyway OpenBinder project was carried out by Dinnie Hackborn after Be Inc. was acquired by Palm... and Dinnie moved to Google >>>> developed Binder in Android what we're using now.

Why use Binder? We can still use Inter Process Communication like sockets and pipes. Answer for this question would be performance. In Android all system functions are provided as server processes that means an optimized and fast communication method is required. Binder use a kernel memory, that's shared between all processes to minimize memory copy overhead, and provides Remote Procedure Call as well.

Benefits of adopting Binder mechanism seems very similar to those of Microkernel OS.
- It's easy to add a new service or remove an existing function
- It's not necessary to test the entire services, only limited components => easy to test
- Communication between processes is handled through Binder, so it guarantees transparency between components.


The following diagram depicts how Binder works in Android system, as previously mentioned two processes communicates through Binder

How to Copy & Paste in Android (Clipboard)

When we run applications like Google Drive, Gmail, or any text editing apps, it's easy to copy and paste something. it's possible to grab an image from browser and paste it in memo app as well.

how does this work?
If you go through Android Developers site, you can find ClipBoard Framework.
Basically Android provides ClipBoard Framework for specifially Copy & Paste.
The following digram (taken from Android Developers site) shows flow and how this works.

Google provides basic fundamental framework and I believe manufacturers like LG, Samsung did some customization this framework, for example on my LG phone, custom UI appears when copying some images & texts on browser (allowing max. 10 items to be stored in clipboard)

 

Anyway it's really easy to use ClipBoard Framework

The text that's being copied to Clipboard here is CopyText, the selected & copied text from TextView or EditText. The code snippets is really simple and clear.

ClipboardManager clipboard = (ClipboardManager) getSystemService(Context.CLIPBOARD_SERVICE);

ClipData clip = ClipData.newPlainText("Clip",CopyText);
Toast.makeText(mContext, "Copied to Clipboard", Toast.LENGTH_SHORT).show();
clipboard.setPrimaryClip(clip);

In order to paste, firstly check if  there exist a clip then get Item from clip. That's all.
I'm ready to paste.. done.

ClipboardManager clipboard = (ClipboardManager) getSystemService(Context.CLIPBOARD_SERVICE);

if(clipboard.hasPrimaryClip()== true){
 ClipData.Item item = clipboard.getPrimaryClip().getItemAt(0);
 pasteText = item.getText().toString();
 pasteTxt.setText(pasteText);
}

2. 조직의 영향력과 프로젝트 생애 주기

2. Organizational Influences and Project Life cycle

프로젝트를 진행할 때, 조직 문화/스타일/의사 소통 방법/조직 구조/조직 프로세스 자산 (Organizational Process Assets: OPA)/기업환경요인 (Enterprise Environmental Factor: EEF) 같은 항목들이 부정적 또는 긍정적으로  프로젝트에 영향을 준다..

1. 조직 구조
 조직의 유형은 기능, 매트릭스, 프로젝트 조직으로 나누어 볼 수 있다


기능 조직은 전통적인 조직 구조로 각 부서별로  장이 있는 것과 비슷하며,
프로젝트 조직은 프로젝트 특징과 분야 별로 조직을 구성하는 형태이며, SI 업체와 비슷하다
매트릭스는 기능과 프로젝트 중간 단계임..

*여기서 중요한 것은 균형 매트릭스 조직으로, 예산 관리 담당의 주체, PM/PMO의 전임/시간제 등을 눈여겨 봐야 한다...

2. 조직 프로세스 자산 (OPA)
프로젝트를 수행하는 조직에 지정되어 사용되는 계획, 프로세스, 정책, 절차, 지식 기반
- 각종 템플릿 (e.g. WBS)
- 조직 표준, 절차 등(e.g. 품질 정책)
- 프로젝트 종료 지침 및 요구 사항
- 형상 관리 지식 기반
- 선례 정보와 교훈 지식 기반
- 과거 프로젝트의 프로젝트 파일 등등

3. 기업 환경 요인 (EEF)
프로젝트 팀의 통제관 범위 밖에 있으며 프로젝트에 영향을 주고, 제약을 주며, 방향을 제시하는 조건...
- 조직 문화/구조, 인사 행정
- 정치 풍토, 정부/산업 표준
- 인프라/시스템 등등

4. 이해관계자
프로젝트 전반에 걸쳐서 긍정적/부정적으로 영향을 미칠 수 있는 개인/조직

* 스폰서: 주로 경영층이 담당자, 프로젝트 재정적 자원을 제공하는 개인/그룹으로 프로젝트를 공식적으로 승인하며, 중요 의사 결정에 참여할 수 있음.

5. 프로젝트 생애 주기
- 예측형 (Predictive): 요구 사항 명확하며, 프로젝트 시작 시점에 모든 계획 확정 (e.g. Waterfall)
- 적응형 (Adaptive): 초기 요구 사항 불분명하나 갈수록 명확해지며, 시작 시점에는 대략적인 계획만 수림하며 단계별로 세부 계획 수립 (e.g. Agile)

* 이해관계자의 영향력,리스크, 불확실성은 프로젝트 초기에 높으며 갈수록 낮아짐..
* 변경 및 오류 정정 비용은 반대로 프로젝트 초기에 낮으나 갈수록 높아짐..

프로젝트 생애 주기와 프로세스 그룹은 다름
프로젝트 생애 주기는 개시, 구성/준비, 작업 수행, 종료로 구분되지만
프로세스 그룹 (착수, 기획, 실행, 감시/통제, 종료)은 전체 프로젝트에서 한번만 실행될 수도 있고, 프로젝트 단계별로 수행될 수도 있음...

1. PMP Intro

첫 번째 장인 서론은 아래와 같은 항목들을 소개하는 것으로 내용을 이해하는 데는 큰 문제가 없어 보인다...

• 프로젝트 정의 및 특징
• 프로젝트 관리
• 포트폴리오 관리, 프로그램 관리, 프로젝트 관리 등 연관 관계
• 프로젝트 관리자(PM)의 역할
• 프로젝트 관리와 운영 관리의 차이점 등등

1. 프로젝트란 무엇인가?

고유한 제품, 서비스 또는 결과물을 창출하기 위해 한시적으로 투입하는 노력이다..

- 한시성/일시성 (Temporary): 프로젝트의 시작과 끝이 정해져 있음

- 유일성 (Unique): 고유한 제품, 서비스 또는 결과물을 산출한다.

- 점진적 구체화 (Progressively elaboration): 프로젝트에서 산출되는 제품이나 결과물들은 반복적이며 점진적인 방법으로 갱신되면서 구체화된다는 의미이다..

2. 포트폴리오 & 포트폴리오 관리

포트폴리오는 전략적 목표를 달성하기 위해 하나의 그룹으로 관리되는 프로젝트, 프로그램, 하위 포트폴리오 및 운영업무의 집합체이며, 포트폴리오 관리란 조직의 전략적 목표를 달성하고자 포트폴리오를 중앙 집중 방식으로 관리하는 것을 말한다...

- 프로젝트나 프로그램들이 서로 의존 관계에 있지 않아도 됨.

- 조직의 전략과 우선순위를 기반으로 생성

3. 프로그램 & 프로그램 관리

개별적으로 관리해서는 실현할 수 없는 혜택을 얻기 위해 통합으로 관리하는 관련 (하위) 프로젝트, 프로그램 등으로 구성된 그룹

프로그램 관리는 프로그램 요구 사항을 충족하고 개별적인 관리로는 달성되지 않는 혜택과 통제를 실현하고자 지식, 기량, 도구 및 기법을 프로그램에 적용하고 관리하는 방식이다..

4. 프로젝트 관리?

프로젝트 요구 사항을 충족시키기 위해 지식, 기술, 도구, 기법 등을 프로젝트 활동에 적용하는 것을 프로젝트 관리라고 한다...

- 5개 프로세스 그룹 (착수, 기획, 실행, 감시 및 통제, 종료)

- 47개 프로젝트 관리 프로세스

프로젝트/프로그램/포트폴리 관리 비교

5. 프로젝트 관리 오피스 (PMO)

프로젝트 관련 거버넌스 프로세스를 표준화하고, 자원, 방법론, 도구, 기법 등의 공유를 촉진하는 관리 조직

- 지원형 (Weather station): 다른 프로젝트에서 얻은 교훈/정보 등을 제공, 통제력 낮음

- 통제형 (Coach): 다양한 수단을 통해 지원하고 준수 사항 요구, 통제력은 보통

- 지시형 (Control tower): 프로젝트를 직접 관리, 통제 지휘, 높음

6. 프로젝트 관리자 (PM)

조직에서 프로젝트 목표 달성 책임을 갖는 팀의 리더/책임자

조직의 구조에 따라 기능 관리자에게 보고할 수도 있음. 

- 기능 관리자: 기능 또는 사업 부분의 관리 감독에 집중

- 운영 관리자: 비즈니스 운영의 효율을 유지하는 책임

PM은 작업/팀 요구 사항, 개인별 요구 사항을 충족시켜야 할 책임이 있으며, 프로젝트에 필요한 해당 분야의 기술 역량, 관리 능력도 요구됨.

PM은 프로젝트의 책임을 지는 사람으로, 대인 관계 기술도 필요함...

- 리더십, 팀 빌딩, 코칭, 의사소통, 동기 부여, 협상, 갈등 관리 등등등

0-0. What's PMP? Why PMP?

학교 졸업 후 단독으로 개발 업무도 해 보고 다른 사람들과 같이 협업도 많이 해 보았다..
그런데 가끔은 협업하는 게 너무나도 힘들 때가 있다.. 나만 그런건가?
특히 커뮤니케이션 ㅠ 그리고 같은 눈높이에서 정상을 바라보기도 너무 힘들더라...

암튼 그러던 중 PMP (Project Management Professional)이라는 자격증이 있다는 것을 알았다..
궁금해서 이것 저것 찾아보았고.. 자기 개발 차원에서 한번 도전해 보기로 했는데..공부해야 하는 범위가 장난이 아니네.. 허허..


PMP는 무엇? 도움이 되나?
PMP는 앞에 언급했듯이 Project Management Professional 이란 용어를 그대로 해석하자면 프로젝트 관리 전문가? 정도 되겠다..

PMI (http://www.pmi.org/) 협회에서 주관하는 자격 시험으로 전세계적으로 그 공신력을 인정 받는 자격임에는 틀림이 없는 듯하다.. LG CNS나 삼성 SDS 같은 프로젝트를 주업무로 하는 회사들에서는 PM이 되기 위해서 필수로 따는 자격증인가 보다..

PMP의 목적은 단순하다 프로젝트 업무에 종사하는 사람들이 프로젝트 관리의 전문성을 배양하면서 체계적인 PM 기법을 갖추도록 하는 것이다..

PMP는 일종의 프로젝트 관리 프레임워크를 제공하는 것으로 IT를 비롯해, 조선, 건설, 제조 등 거의 모든 산업 분야에서 사용될 수 있다.. 일부 회사에서는 PMP 교육 과정 및 취득 비용을 모두 지원하기도 하고, 승진 등에 많은 도움이 된다고 하니..

그럼 누구나 시험 신청이 가능한 건가?
공신력 있는 자격증이니 만큼.. 기본 요구 사항을 만족해야 하지 않을까 싶다..
학사 학위 이상인 경우에는 최소 4,500 시간 (36개월) 이상의 프로젝트 실무 경험이 필요하고
전문대나 고졸 이하 인경우에는 최소 7,500 시간 (60개월) 이상의 경험이 필요하다..
그리고 공통으로 35시간 이상의 PM 교육이수가 필요하다..

비용은?
PMI 비회원인 경우 $555
PMI 유료 회원인 경우 $405불 (회원비: $129) 이니, 유료회원이 싸네..

PMP 취득 이후에도 자격 유지를 위해서는 3년 주기로 60 교육 학점 (PDU)를 채워야 한다네..
한번 자격증 따면 그만이 아니었네...


참고 사이트: PMI (http://www.pmi.org/)

0-1 PMBOK 5th edition + 책?

PMP 공부를 위한 수험 가이드를 한번 살펴 보았다..시중에 나와 있는 책들이 좀 됨...

• PMP Pride (원지호 저)
• PMP Pass (한동환 저)
• Headfirst PMP (제니퍼 그린, 앤드류 스텔만 저) 등등

그럼 어떤 책을 봐야하나? 음...
이 수험서들은 PMI에서 publish하는 PMOBOK Guide 를 기반으로 만들어졌기 때문에 사실 내용면에서는 큰 차이가 없지 않을 까 싶고,, 아마도 기출 문제와 해설이 약간씩 다르지 않나 싶다..

암튼 PMBOK 5th edition을 먼저 보고 가장 최근에 출판된 PMP Pride를 한번 참고해 보기로..


PMBOK 5th edition의 기본 구성은 아래와 같으며, 참고 교재인 PMP Pride도 동일하게 구성되어 있다... 이제 본격적으로 각 챕터별로 공부를 시작해 봐야 겠다.

1. 서론
2. 조직의 영향력과 프로젝트 생애주기
3. 프로젝트 관리 프로세스
4. 프로젝트 통합 관리
5. 프로젝트 범위 관리
6. 프로젝트 일정 관리
7. 프로젝트 원가 관리
8. 프로젝트 품질 관리
9. 프로젝트 인적 자원 관리
10. 프로젝트 의사 소통 관리
11. 프로젝트 리스크 관리 
12. 프로젝트 조달 관리
13. 프로젝트 이해관계자 관리