Comparison Ms. Word vs Corel WordPerfect

MS Word 6.0 was the first Windows word processor I ever used. At the time, I worked in a Bank, and I was happy that I didn't have to use it very often. I hated that it wasn't WYSIWYG. I found that vexatious (and still do). In later years, I changed careers, moving to I.T. Again, Word was the program I used (and received all my training in). Whereas before I didn't like it, now I hated it. I found that accomplishing (what I believed to be) simple tasks was unnecessarily difficult, and I was often exasperated by its inadequacies. I then moved to a new company; that company used WordPerfect. What a joy! Everything that I hated in Word was suddenly easy to accomplish in WordPerfect. In addition, it was a true WYSIWYG program. I then found Reveal Codes, and my conversion was complete.

Microsoft produced a White Paper (Word 97: Life after Reveal Codes), which tried to explain why you don't need Reveal Codes in Word , but it was nothing more than a lame attempt to justify the fact that Word can't produce the equivalent of Reveal Codes.

"Word is based on a hierarchical formatting system that allows the user to format based on the entire document, a section, a paragraph, or even character. The hierarchical architecture of Word does not allow for stream-based formatting like in WordPerfect".

NOTE: In complete contradiction to this, Word XP subsequently introduced a feature called 'Reveal Formatting' (in response to people decrying the fact that Word lacked a feature similar to Reveal Codes). You can read my thoughts on that in the comparison! :)

Anyway, when I added Reveal Codes to WordPerfect's other features, I became a devotee of WordPerfect; this feature alone is one of the main reasons WordPerfect has obtained such a devoted following.

Personally, I found this program amazing. Instead of wanting to throw my PC out the window, I was actually enjoying working with this program! It made my life easier, and I was continually astounded by the program's power AND ease of use.

I then bought a new PC and wanted Excel, so I purchased MSOffice 97 OEM with it; when I would come home and work on Reports or Assignments for courses I was doing, I would use Word 97. Grrrr. I hated it; Word 97 was just as bad as Word 6.0 and Word 7.0. I wished I could install WordPerfect 6.1 (which I was using at work) and use that instead of Word 97, but at that time, I was unaware that Corel allowed you to install a copy at work and at home. In total frustration, I took the plunge and went out and bought WordPerfect 8.0. Wow! I thought WP6.1 was good? WP8 introduced *so* many fantastic features that I went all-out trying to get my company to upgrade, which they did, but they waited for the soon‑to‑be‑released (at that time) Version 9.

Then, one day, I had a discussion with someone (who worked in the same building) who loved Word. Stunned, I mentally started to go through all the things that WordPerfect could do that Word couldn't (as well as the things that were so much easier in WP). At that point, I resolved to make a website comparing the 2 programs. My first comparison went online approximately 4 years ago, and since then, I've updated it to compare the 2 programs when a new version is released.

That's the background. Hope it wasn't boring! I'm sure you're itching to move on to the actual comparison, so I won't ramble any longer.

Sumber :www.wpvsword.com

Desktop

	Windows	Linux	Notes
Desktop Market Share	As of May, 2007 93%[9]	As of May, 2007 0.7%,[10] often used in dual-boot computers	According to W3C, May 2006, judged by web traffic on a technology site.[11]
Pre-installation	Pre-installed by default on almost all new desktop PCs	Pre-installed by default on very few new desktop PCs. However, Ubuntu Linux is now available on some Dell and System76 computers, and SUSE Linux on some Lenovo ThinkPads[12].	Microsoft's agreement with vendors to sell only the Windows operating system is being challenged in court by French consumer rights groups.[13]
Window Managers/Desktop Environments	Only one available WM per release, parts of which may be modified; third party software such as WindowBlinds is required for some modification; critically required to operate the system (graphics system failure will render the system unusable); remote control not part of original architecture.	GNOME, KDE, Enlightenment, Xfce, Openbox, Fluxbox, etc. may be enhanced with Beryl or Compiz. Not critical to operate the system (reverts to command line operation in case of failure); remote control implicit in design and protocol.	Different Window managers provide users with a uniquely different method of interacting with the computer, though sometimes at the cost of compatibility.
System consoles/Command line interface	The Command Prompt exists for power users. A new .NET based command line environment similar to that provided in Unix-like operating systems called Windows PowerShell has been developed. Currently, Cygwin provides a UNIX-like terminal for Windows.	Strongly integrated with system console. All applications can be scripted through the terminal, there are a lot of small and specialized utilities meant to work together and to integrate with other programs. This is called the toolbox principle. The command line can be used to recover the system if the graphics subsystem fails.	Sumber : www.wikipedia.org

Planning in software project

Planning

Tujuan dari Project planning adalah untuk menghasilkan suatu strategi yang berfungsi untuk mengontrol, menelusuri dan mengawasi kompleksitas dari pelaksanaan project secara teknikal (Aplikasi)

LANGKAH-LANGKAH :

• Ruang Lingkup ; yaitu dengan memahami permasalahan yang dihadapi dan apa yang harus dilakukan, serta batasan-batasan yang harus kita jalani.Estimasi ; yaitu berapa banyak biaya dan waktu yang dibutuhkan
  

• Resiko ; yaitu melihat kesalahan apa yang terjadi, dan bagaimana kita menghadapi serta apa yang harus kita lakukan terhadap kesalahan tersebut ?

• Penjadwalan ; yaitu bagaimana kita mengalokasikan sumber daya selama waktu yang tersedia.

• Kontrol Strategi ; yaitu bagaimana kita mengawasi terhadap kualitas yang kita inginkan dan perubahan yang terjadi

Salah satu software yang dapat membantu untuk melakukan planning pada suatu software project adalah Multi Project Planner 2.1

Iterative Software Project Planning and Tracking

sumber : http://www.jrothman.com/Papers/7ICSQ97.html

Project management can be described as the activity of bringing all participants from within a department to successfully complete a product deliverable. Iterative planning and tracking are techniques used by some project managers to avoid having to choose between reducing the number of features or extending the schedule.

Abstract

Project management can be described as the activity of bringing all participants from within a department to successfully complete a product deliverable. Iterative planning and tracking are techniques used by some project managers to avoid having to choose between reducing the number of features or extending the schedule.

Introduction

Because software is ephemeral, software projects are frequently difficult to plan, track, and assess. Iterative project management techniques help make the obscure clearer.

Most successful project managers know how to set up a project plan. They know what the standard milestones or events for the project need to be (O'Connell, 1996), and they plan the project accordingly. They plan the schedule according to a specific critical path (generally tasks). McConnell (McConnell, 1996) and others have shown that once a project has missed a milestone, the project's staff cannot "make up" the time. Project managers may face the choice between extending the schedule and dropping the features. The management part of project management is required to manage the schedule and include the features.

There is an alternative to the blind choice of extending the schedule or dropping features. As a project manager, if you can "chunk" the features, and give yourself sufficient flexibility in learning about the features and project scheduling, then you can redirect the critical path, and still make the schedule with the planned features. This method of developing a number of small independent features, and frequent replanning is iterative project management.

This paper presents an iterative project scheduling technique together with two example releases from an organization.

Initial Project Planning

Senior management frequently fixes the ship dates without a good knowledge of the features to be produced. Naturally, the engineers decry this as a terrible, awful thing. Planning and expecting to completely meet a fixed schedule project without adequate feature knowledge is truly is a terrible, awful thing. For example, imagine this scenario.

Dan, the project manager, has just talked to senior management. "Those **&&** just did it to me again. They told me to ship this next release in 4 months. Our competition just announced availability in 8 months. Now we need to announce availability in less than 6 months. We don't even know what it's going to take to design this feature, never mind implement it within this architecture. How the heck can I sell this to the engineers? What am I going to tell my project team? They're going to kill me- or what's worse, they'll all walk out. How could senior management do this to us? Don't they know what it's like to develop software?"

It's not that senior management is bad or stupid. Commercial companies have significant market forces that may prevent them from fully understanding what they are requesting of the product developers. Market forces drive companies to make choices before the company is really ready to do so. Iterative project planning allows a company to get started on a project when only the major issues of the feature set are understood, but the ship dates are set in stone.

Critical Paths

There are multiple critical paths in a given project. The tasklist generates a particular critical path. The people working on the project create another critical path. And, hard resource availability creates yet another critical path. The true project critical path is the critical path through all three views: tasks, people, and resources.

During the initial planning phase of many projects, the tasks and events are planned, and with any luck, the task critical path emerges. Many project managers are also aware that people and hard resources (i.e. machines, networks, etc.) have an impact on the critical path, and they plan for using these scarce resources appropriately.(Goldratt, 1997)

In a project where the project manager and the technical staff do not have sufficient knowledge of the full feature set under development, a traditional approach does not guarantee success. The traditional approach assumes the project manager knows and understands the critical paths of tasks, people, and resources. In a less-fully specified project, it is unlikely that the project manager will know all the critical paths. The project manager will probably be surprised by new tasks that arise, unforeseen tasks, or new expertise may have to be developed, and new resources may be required.

When project knowledge is imperfect an iterative approach is more successful:

1. Plan the major milestones. Estimate the feature freeze, code freeze, system test freeze, beta ship and product ship dates. Determine the criteria by which the project staff can agree that these milestones have occurred.
2. Plan each segment of the project as it crystallizes, staying at least four weeks ahead of the current state.
3. As each project segment completes, the project manager and technical staff have a better understanding of the project and the eventual product, so more complete planning can take place. By the time the project has reached the feature freeze milestone, the tasks required to get to code freeze are well understood. By the time code freeze is reached, the rest of schedule can be laid out and planned.

This iterative approach reduces uncertainty for the current project work, and allows replanning of the critical path at a number of points in the project.

Milestone Definitions

This set of milestones is useful for defining software project schedules:

Milestone	Criteria
Feature freeze	The date when all required features are known and the detailed design has uncovered no more. No more features are inserted into the product.
Code freeze	Implementation of the design has stopped. Some testing of the features has occurred.
System test freeze	Integration testing is complete. Code freeze for system test to start.
Beta ship	The date the Beta software ships to Beta customers
Product ship	The date the product ships to the general customer base

For small projects, there may be only one of each freeze and Beta ship. For larger or more complex projects, functionality may be grouped so that part of the product is ready for code freeze while part of the product has still not met feature freeze.

Milestone Planning and Criteria

Effective project managers and software engineers understand that a general approach of

1. Requirements planning
2. Feature definition (leading to feature freeze)
3. Design and implementation (leading to code freeze)
4. Verification and Validation (leading to ship)

is a time-effective and cost-effective way to implement a project. In addition, early and often reviews and inspections will reduce project time (Gilb, 1993). Project managers following this technique can get a better handle on the milestones of feature freeze, code freeze, system test, beta freeze, and ship freeze.

In an iteratively planned project, it is critical that the project team agrees on what each milestone means. The project manager depends on accurate information about the current state of tasks from the project team. How can the project be successful if the project manager and team do not understand what the milestones mean?

To use the iterative planning technique, the project manager plans the major milestones (e.g. feature freeze, code freeze, system test, beta freeze, and ship freeze), and then iterates on the work between the milestones.

Building the schedule only have to be done once

Multi·Project·Planner 2.1

Product Specification

Multi·Project·Planner addresses the multiple project management problem.

As the main purpose of the program is to assist the operating management in the scheduling task and the handling of daily exceptions, the focus is on:

• The puzzle problem of scheduling a number of projects in a scenario of limited resources.

• Handling the ripple or domino effect of one project being delayed upon the others.

• Facilitating a Just in Time kind of planning.

• Accepting that plans do not allways comply with reality.

• The scheduling task is performed with the look and feel of a planning board.

Multi·Project·Planner is very much inspired by the planning problem of the build-to-order production mode charaterized by construction companies.

The minimum time-unit is 24 hours, so Multi·Project·Planner is not feasible for production planning.

Applicability

The program is applicable where several projects are to be realized by a set of shared resources, as is the case for construction companies, software development departments and the like.

The program can be operated and configured by the ordinary user.

Features

Instant overview
The application consists of three boards:

• The Capacity Schedule, which is a model of your company's production facilities upon which your projects are booked. That is the gantt charts of the projects are superimposed upon a schedule, mirroring the capacity.

• The Employee Schedule, showing which employees are present at any given time. The employees man the work teams.

• The Resource Situation Overview, showing the accumulated demand and supply of resources.

Work Team
Every work team supplies a set of competencies.
A project activity has a coresponding set of competence demands.
A best fit between the demands and supplies is the key when edtiting is performed, ie when you drag a projecttemplate or a project,all activities other than the one you control with the mouse, is placed onto the plan acording to this fit.

Template projects
New projects can be scheduled by "drawing" directly in the Work Team Schedule.
Alternatively, predefined projects can be dragged onto the schedule, and the program will try to make a best fit with respect to competence demands and available work teams.
Finaly projects can be stored as templates, ie the other way around.

Handling conflicts
Conflicts may occur because of lack of available work teams with the needed competencies.
Conflicts can either be resolved instantly by overruling, or left to be dealt with late (hot potatoes).
Flags indicate unresolved conflicts.

Progress Tracking
Progress (completion and actual time used) can be calculated automatically from actual time reported, or it may be specified directly.

Weekend modifiers
Weekends and specialdays are respected when editing the plan, ie the number of working days are still the same. This functionality is fully configurable.

PERT chart and relative constrains
Pushing a button will show a timescaled PERT chart for the selected project, leaving the others grayed. In this picture the relative constrains between the activities are edited.
Relative constraints can be given some plasticity, i.e. A must finish before B ± 2 to 5 days f.ex. When moving the project or dragging a template onto the plan, these constrains including their plasticity are respected.

Capacity structure easily modified
The capacity structure is easily modified in mangnitude and order by the mouse. The structure is hierarchical in nature.

Decision points
Decision points can be attached to project activities.
A decision point contains all the decisions which must be taken at a specified interval relative to the execution of the activity.
A project activity can have multiple decision points.
A warning flag is raised if decisions are due today.

Flags
Flags are attached to activities to indicate an exception.
An activity can raise a flag if

• No resources allocated at all.

• Resources only partly allocated.

• Relative constraints violated.

• Notes attached to the activity.

• Activity fixed in time.

• Decisions due.

Notes
Notes may be attached to project activities. If notes are attached to an activity, a yellow flag is raised. The tooltip of the flag will show the first line of text in the last note.

Editing facilities
The editing is done with the mouse.
The editing facilities includes:

• Creating project activities using a "Pen".

• Moving / resizing project activities with the following modularities:

  • Respecting relative constrains or not (ie related avtivities following or not).

  • Respect weekends or not.

• Dragged to other rows. (capacities)

• Spliting an activity into two.

• Turn an activity into a hot potato.

• Overruling or bruteforce editing. If the program denies an activity the right to occupy a space, either becuase its allready occupied, there is not enough room or insufficient competencies, you may overrule it by pushing the "Ctrl" button.

Duty templates
Duties mainly constitues a recurring pattern. Multi·Project·Planner offers a duty template
in which you state duty pattern one and for all.

Workforce Assignment
Resources may be automatically assigned to activities with respect to:

• The competencies needed for a task and the competencies offered by the employees.

• The availability of employees.

• Preferred employees, ie. a distinct set of employees assigned to a distinct set of work teams.

Of course, manual assignment is also possible.
As always: You are in command

Printing facilities
The size of the printout is configurable. It can span multible pages.

Finaly
You may use Multi·Project·Planner without any of the facilities listed, or only part of them as you please.

Multi·Project·Planner 2.1

The problem

Multiple concurrent projects competing for shared resources.

The solution

The project activities are booked on a schedule, common to all work teams, participating in the projects.
I.e. the Gantt charts of the projects are superimposed upon the common schedule, where each row represents a work team.

Main benefits

• A far superior overview, as both resource allocation and the interrelationships between the activities of all projects are handled in one and the same view.

• Unsurpassed control of the planning process.

Highligts from the feature list

• Hot potatoes are unresolved resource conflicts, kept by the program until you are ready to deal with them.

• Manipulation is performed with the look and feel of a planning board.

• Predefined projects (templates) can be dragged onto the schedule, and the program will try to make a best fit.
  Otherwise it will create hot potatoes.

• Just in Time means scheduling the project as close to the delivery date as posible, thereby minimizing your inventory and maximizing your instant maneuverability.

• Brute force handling of resource conflicts, but only if you command it.

• Future resource conflicts that are not solved now, are turned into hot potatoes, for later treatement.

• Decision points attached to project activities, and launching a warning when the decisions are due.

• Timescaled PERT charts, including plasticity on the constrains, which will be respected when dragging projects and templates.

• Progress can be calculated automaticaly from employee reports or manualy stated.

• Extendability, i.e. enhancing features by adding modules.

• Interoperability, i.e. integration with other software.