“Phù thủy thường đẳng” chứng chỉ cho webmaster
Những ai yêu thích bộ tiểu thuyết Harry Potter của J.k.Rowling hẳn còn nhớ “Phù thủy thượng đẳng” là 1 chứng chỉ được cấp vào năm thứ 6 khi các học viên của Hogward trải qua 1 số bài test về kiến thức và thực hành các kỹ năng phép thuật. Với ý tưởng như vậy, sau đây Vincent Trần xin đưa ra 1 số tiêu chí khá phổ biến dành cho những bạn đang theo nghề webmaster tham khảo. Hy vọng giúp các bạn định hình thêm 1 số kỹ năng và kiến thức dành cho webmaster, để ngày càng chuyên nghiệp hơn, gặt hái được nhiều thành công trong công việc.
1, Kỹ năng về hệ điều hành
Các bạn đều biết, hệ điều hành là môi trường chung nhất để chúng ta tác nghiệp. Tuy nhiên để đạt được trình độ chuyên nghiệp trong công việc, chúng tôi khuyên bạn nên có hiểu biết, và sử dụng thành thạo hệ điều hành Ubuntu, một phiên bản khá nổi tiếng của Linux.
Lý do: hầu hết các server hiện nay đều sử dụng hệ điều hành Linux, do tính bảo mật cao, phân quyền tốt, và giá thành thấp hơn so với Window(vd bản Centos miễn phí)
Chính vì thế tôi khuyên các bạn nên biết sử dụng thành thạo hệ điều hành Ubuntu, vì khi đó, bạn sẽ có những hình dung tổng thể về linux, biết sử dụng các câu lệnh điều hành(Terminal) từ đó có kỹ năng tốt để có thể quản trị, điều hành server từ xa(thông qua giao thức SSH). Ngoài ra Ubuntu có phần giao diện đồ họa, giúp bạn có thể tiếp cận nhanh và trực quan hơn so với các phiên bản Linux khác.
Việc sử dụng thành thạo Ubuntu cũng đồng nghĩa với việc bạn biết sử dụng các công cụ quản trị website mà Ubuntu hỗ trợ sẵn, như FTP, Putty SSH Client, Netwwork Tool v..v
Thêm nữa, việc cài đặt Ubuntu cũng không quá phức tạp. Tuy nhiên cũng cho bạn thêm nhiều kiến thức về cấu trúc máy tính, các phân chia ổ cứng(partition of hard disk)
2, Kỹ năng về cài đặt và cấu hình server
Trong thời đại mã nguồn mở đang phát triển như hiện nay. Bộ 3 Apache,PHP,Mysql đang là lựa chọn số 1 cho việc thiết lập 1 server hiện nay.
Sau khi có kỹ năng sử dụng Ubuntu(Linux) bạn nên trang bị cho mình thêm kỹ năng cài đặt và cấu hình các Service trên. Trong đó đặc biệt lưu ý đến việc cấu hình tùy biến cho Apache và PHP để có thể tùy biến server phục vụ cho các ứng dụng web(web application) lập trình trên PHP sau này.
3, Kỹ năng sử dụng các chương trình quản trị server
Vì quản trị trực tiếp bằng SSH nhiều khi không thông dụng đối với các khách hàng của bạn, nên các server cần thêm các phần mềm chuyên dụng để quản lý dữ liệu website (hosting)
Hai chương trình phổ biến nhất hiện nay là DirectAdmin(thường miến phí cho người dùng) và Cpanel(có trả phí).
Về hai chương trình quản lý này, đương nhiên Cpanel được đánh giá vượt trội hơn hẳn DirectAdmin, tuy nhiên do chi phí sử dụng Cpamel cho toàn bộ server là khá cao, nên 1 số server để giảm chi phí cho người dùng cuối thường hay sử dụng Direct Admin.
Về cơ bản, bạn nên nắm được các tính năng thông dụng của 2 chương trình này. Như tạo các Account Hosting, Reseller, quản trị các domain, quản trị mysql,quản trị email, quản trị các file, back up dữ liệu v..v
Ở dây, theo tôi các bạn nên dùng Cpanel ngay khi có thể. Vì độ bảo mật cao, vận hành ổn định. Các tính năng quản trị vượt trội như quản trị việc cấp quyền SSH, quản lý bandwidth, các ứng dụng tiện ích cho người dùng như Fantatico v..v Ngoài ra, Cpanel còn cung cấp cho bạn 1 công cụ vô cùng quý giá đó là các Log. Việc đọc các Error Log giúp bạn tìm được những lỗi ngầm của website và khắc phục chúng. Còn Access Log giúp bạn tìm hiểu 1 phần các lỗi bảo mật, và quá trình tấn công của các hacker. Direct cũng hỗ trợ chức năng này nhưng khá phức tạp, và rất khó cho khách hàng hosting(người dùng cuối)
4, Kỹ năng lập trình và quản lý dữ liệu
Những ưu thế mà bộ 3 Apache, PHP, Mysql là mã nguồn mở nên hoàn toàn miễn phí. Độ tùy biến cao, vận hành ổn định. Với Mysql là trình quản lý các dữ liệu mở, hoạt động với tốc độ nhanh. Đáp ứng đầy đủ cho các website hơi lớn, vừa và nhỏ.
Nên tôi khuyên bạn nên có kiến thức và kỹ năng sử dụng ngôn ngữ PHP. Sau khi nắm bắt được php, bạn có thể mở rộng ra nghiên cứu thêm ASP,ASPX, .Net hay JSP thì càng tốt. Việc nghiên cứu thành thạo PHP cũng giúp bạn có tư duy hệ thống, và có thể khi cần sẽ lựa chọn việc sử dụng ngôn ngữ lập trình trên quan điểm hiểu biết về các ưu điểm của ngôn ngữ đó.
Với quản lý MySQL tối thiểu bạn có kỹ năng quản trị dữ liệu bằng 1 trình quản lý có sẵn là PHPmyadmin, nếu biết thêm quản trị Mysql qua SSH thì càng tuyệt vời.
5, Kỹ năng trình bày website
Hiện nay hầu hết các website đều được trình bày bằng CSS. Vì thế bạn nên trang bị cho mình những hiểu biết về quy tắc sử dụng CSS.
Đương nhiên là bạn cũng phải có kiến thức HTML rất vững vàng
Ngoài ra có kỹ năng về sử dụng đồ họa photoshop và flash thì càng tuyệt vời.
6, Kỹ năng sử dụng các Opensource cho website
Ngày này, sử dụng opensource để xây dựng và phát triển website là 1 xu thế tất yếu.
Chính vì thế, tôi khuyên bạn nên có các kỹ năng về sử dụng Opensource. Đặc biệt là các opnesource sau: Joomla hoặc Drupal(CMS) Zencart hoặc Oscommerce(Shoppign cart)hay tuyệt vời nhất hiện nay là Magento. Ngoài ra bạn biết thêm về WordPress hay Liferay, Phpnuke, Xoop thì càng tốt. Đặc biệt là Liferay.
7, Hiểu biết về phương thức mã hóa
Phần này dành cho các bạn chuyên nghiệp. Vì các phương thức về mã hóa và giải mã thường chỉ được dùng cho các hệ thống lớn, có dữ liệu người sử dụng nhiều, và các website có thực hiện giao dịch mua bán chuyển tiền.
8, Kỹ năng về Seo Sef
Đây là kỹ năng về tối ưu hóa từ khóa cơ bản bạn cần nắm được.
Như việc tạo đường linh thân thiện dạng .html cho các page thay cho dạng index.php?option=com_abc v..v
Biết được sơ lược về thuật toán tìm kiếm sắp xếp của Google, các hiệu ứng của Title,Keyword, và Description.
Sử dụng thành thạo, và phân tích các kết quả của công cụ thống kê Google Analytics
9, Kỹ năng cập nhật thông tin và tự nghiên cứu
Kỹ năng này nói thì vô cùng, vì thông tin có thể chẳng có giá trị gì mà cũng có thể là vô giá.
Hy vọng qua bài viết này. các bạn có được những định hướng cơ bản về việc nghiên cứu tự hoàn thiện mình trên bước đường tiến tới Webmaster chuyên nghiệp- webmaster thường đẳng.
Chúc các bạn thành công.
A 6-Step General Process for Producing a Website
A 6-Step General Process for Producing a Website
When it comes to building a website, it helps to have a process to follow, especially if you are just getting started as a web designer. Good guidelines can help you work better by keeping forgetfulness to a minimum.
Every designer or company will develop unique components to their web design process over time, but the basics remain the same: learn, plan, design, code, launch and maintain.
In this article, I will share my process for designing a website.
Before we get into it, let me first share two parallel processes that should be taking place throughout your design process.
The first thing you should be doing continuously is seeking feedback. You’ll save yourself a lot of wasted time and effort by getting feedback at regular intervals.
The second thing you should do continuously is testing. Test the heck out of everything as you go to avoid mega-headaches down the road.
With that said, let’s get started!
1. Learn
What do you think is the most important step of the web design process? Planning? Designing? Coding?
Guess again.
It shouldn’t surprise you that learning — discovering and understanding what you need to build in the first place — is the most important part of the entire website design process.
Why? It’s simple, really. The more you know about what you need to accomplish, the better your chances will be of creating a successful website.
Think of it like this: If you are an archer, don’t you need to know where to aim your arrow? That’s what the target is for. The little red dot in the middle is the bullseye. Since it’s smaller, it’s harder to hit, but even if you aim for it and miss, you’re sure to get closer than if you aimed your arrow up into the air and hoped for a random direct hit.
So how can you score a bullseye as a web designer? Before you go any further, you need to define what hitting the bullseye in your project means.
As a web designer, hitting the bullseye is giving your clients what they want — it’s what they are paying you for.
What clients want varies widely on a case-by-case basis. Since you aren’t a mind reader (no, you’re not), you need to proactively find out what they want.
In some cases, they may not even know what they want, and in other cases, they may have a hard time verbalizing what they have envisioned because they don’t know industry terms and concepts like CSS, Ajax, or relational databases.
The Creative Brief
Fortunately, there’s a tool web designers can use to easily gather this information. It’s called a creative brief. A creative brief is basically a series of questions that you ask your clients so that you can understand the scope and goals of a project.
You can ask these questions during a face-to-face meeting or a phone call — or you can simply make a web form available on your website that handles the answers of your clients.
You should obtain this information in the way you and your clients are most comfortable with — but whatever you do, don’t skip the creative brief because it will become the lifeblood of your project.
What kind of questions should you ask in your creative brief? At the minimum, find out:
* The client’s target audience
* Their primary and secondary goals for the website
* Current branding characteristics
* Budget
* Deadlines they need to meet
I also like asking clients what websites they like and don’t like to give me a visual idea of where I should be heading and what I should avoid.
You might also want to find out if they need an online store, if they already have a logo (if not, you can make one for them), who will be responsible for maintaining the site once it goes live, and so forth.
You might have unique questions that you will want to include; use them and don’t be afraid to tailor your questions on a per-project basis.
2. Plan
Once you’ve learned what you need to build, it’s time to start planning how you are going to make it happen. Before you can start designing a website, you need to know exactly what, and how, to design it in the first place — and it all starts with creating a design strategy.
Your design strategy for each website you make should be handcrafted to fit the client’s vision (if you are designing a site for yourself, then you would qualify as the client).
So what factors will shape your design strategy? The creative brief will act as the foundation of your plan by providing you with some basic information, such as what your timeframes are and who the target audience of the website is.
It’s especially important to know your audience because it will affect where and how the site gets viewed. For example, will you also need to create a mobile version or an iPad-specific version that works with touch?
Research and Note-Taking
Whatever gaps are left in the overall strategic picture will need to be filled by doing some research of your own. Now is the time to visit competing websites and see what types of designs are already out there in the target market so you will know how to differentiate your own design.
See who comes up first in a Google search and try to find out why. Within 10 minutes, you should be able to start piecing together the beginnings of your design plan.
While you are researching, you’ll also start brainstorming about what colors to use, where to place the call(s)-to-action, what kind of fonts you should use and other similar details.
At this point, you should also be taking notes, snapping screenshots and starting a mood board.
Sketching and Mock-Up
Next, it’s time to create a mock-up and start letting your ideas take on more of a tangible state. I like to start by sketching out my ideas on a regular old piece of paper, as do many other web designers.
Other people prefer to use a wireframing tool like OmniGraffle. During this phase, not only will you want to start thinking seriously about the layout of the site, but also the structure of your site and how the navigation will shape up.
This is your chance to see what works best and a good place to experiment with different ideas before actually hitting Photoshop or Illustrator to create something more concrete.
Pick Your Tools
This part of the process is also the perfect opportunity to assess which tools you will need to use. You absolutely should not fall into a pattern of using a predetermined set of tools for each site you create. It’s a potentially hazardous practice for everyone involved, including the site’s end users and the client (not to mention how monotonous your portfolio would look).
Put some real thought into what content management system would work the best considering the site’s goals, whether or not including Flash at all is a good idea, and so on.
3. Design
Now I know there are many web designers out there who like to skip directly to the design stage without giving a second thought to learning or planning, but design is more than just the act of creating. You want to actually create something good and useful and you just can’t do that without first doing some preliminary work before starting to design.
If you’ve already done the legwork of learning and planning, it makes the actual designing much easier. When you don’t have to worry about the little details, it really opens up a whole new level of effectiveness and productivity because you can focus on more important things.
Once you are ready to start designing, keep in mind that you need to design more than just a home page. You’ll need a design for the sub-pages of your site as well. It can sometimes be easy to design a home page concept, slice it up and start coding only to get to sub-pages and have no direction. You may also need to design a mobile or iPad version of your site as well.
The design phase itself is straightforward. Just open up Photoshop (or your graphics creation tool of choice) and start bringing your mock-up to life. Sweat the details. Make it pixel perfect. Even if you feel like the project you are working on is more boring that staring at a wall for 24 hours straight, put your all into it. Your client will notice and you’ll be proud of the work you did.
You’ll have to decide at this point whether you want to use real content in your design or some dummy text (e.g. Lorem Ipsum). There are plenty of fans in either camp, but I personally prefer to use real copy and photos if they are available to make it as close to reality as possible.
During the design phase, it is incredibly important to seek feedback often to make sure all specified requirements have been met. If the client wants to make changes, now is the time to do it before the design is sliced and coded, making it ten times more difficult to make what would be a simple change if you were to do it during the design phase.
4. Code
Once you have a killer design, you’ll need to turn it into a real, live website. A safe bet, no matter what content management system you are going to be working with, is to start with a generic HTML and CSS template.
Start with a Base Template
If you’re like me, you’ve already got a set of starter HTML and CSS files ready to go that are already linked to each other and already contain some basic starter code (such as a CSS reset).
If you’re not like me and don’t have these generic files at the ready, go ahead and create some that you can reuse at this stage in the future.
Before you go any further, it’s a good idea to go ahead and add in your title, descriptions and meta tags, or at least make a note of what they should be if you are going to be using a content management system later on.
Lay Out the Main Sections and Content
Begin carving up your HTML/CSS by inserting the major sections (your main
s) for your header, footer and content area.
Next, begin adding your text and image content. The goal is to keep your markup as semantic as possible so that each element is meaningful.
Avoid divitis — the act of utilizing too many divs. For example, you don’t need a div just to contain the logo. Try using an
or a
instead — it can be styled exactly the same way (e.g. making them into a block elements using the display CSS property).
Validate and Test
Don’t forget to make sure your code validates by using the validation tool provided by the W3C (but also understand that validation tools have shortcomings).
You’ll also need to do some browser testing to make sure the site looks and acts as intended and provides a uniform brand experience no matter how a user accesses it. You can use a tool like Browsershots if you have limited access to different types of computers.
Use Firebug and YSlow to debug your site and make sure your work is running at an optimal speed.
One last thing: don’t forget to implement Google Analytics or your favorite analytics alternative so you won’t miss out on tracking the stats during the big launch.
5. Launch
When you’ve finally perfected the site, it’s time to release it to the public. Launching can mean different things to different people, mostly because there are various content management systems and development circumstances out there.
For instance, if you are redesigning a site that uses a content management system or publishing platform, your launch may be as simple as applying a new theme.
If you are designing a brand new site in a sandbox or local development environment, then “going live” means FTP’ing your files to the production server.
6. Maintain
During your planning phase, you should have determined who will be in charge of site maintenance. If a client is unable to maintain the site, you may want to suggest that they hire you on a regular or as-needed basis to manage and perform maintenance tasks.
During the hand-off/closeout of the project, it might also help to provide some guidelines and basic training to your client to make sure they understand how to properly maintain the site.
Software Project Failure: The Reasons, The Costs — CIOUpdate.com
Software Project Failure: The Reasons, The Costs — CIOUpdate.com
Software project failure is often devastating to an organization. Schedule slips, buggy releases and missing features can mean the end of the project or even financial ruin for a company. Oddly, there is disagreement over what it means for a project to fail.
This article uses economic criteria to define what it means for a project to fail. It then categorizes how projects fail and finally, it examines common traps that contribute or accelerate project failure.
The cost, feature, product spiral
Economics determines the success of any software project and its value to a company. The amount of money spent on development determines the cost of the asset. The return generated by the product is its value. The difference between the return and the cost is the return on investment (ROI).
Economics of Adding Features
Figure 1. The ROI of a product is the difference between its cost of production and its return. If the return is greater than the cost of production then it is said to possess a positive ROI.
Organizations must consider the cost of adding features to a product. Figure 1 shows a software project whose returns outpace the cost of production, thus producing a positive ROI.
Figure 2 depicts a product that initially has a positive ROI, but whose added features cost (marginal cost) more than the amount of return generated by the features. This initially profitable product becomes a drag on the company.
Figure 2. ROI is said to be negative if it costs more to product a product than it generates.
Related Articles
Figures 1 and 2 are deceptive because under most software processes, the cost of changing software is not linear, but exponential. Brooks (1) attributes the exponential rise in costs to the cost of communication. Changes to software include new features, bug fixes and scaling.
The effects of exponential cost of production can be characterized by three properties. First, new projects are successful because the cost curve is flat. Second, once the costs start increasing, they quickly overcome any additional value added from the new features. Finally, if changes are made after the costs become exponential, the additional costs will quickly overwhelm all returns garnered from the product to date. Figure 3 details the effects of an exponential cost of change.
Figure 3. Exponential costs of change can quickly subsume the worth of any product.
Software processes are designed to manage the cost of change. An examination of cost management and processes is beyond the scope this article but will be the topic of a future article. Briefly, processes that follow waterfall and iterative models control costs by reducing need for change as costs increase. In contrast, processes based on the spiral model ensure that the cost of change is fixed. This article assumes an exponential cost of change as most projects are based on waterfall or iterative models.
Changes are often unavoidable because there are no successful medium-sized software projects. Successful projects require a significant amount of development and become a company asset.
Maximizing ROI means expanding the market and the addition of features which, in turn, increase the investment in the product. If the next version is successful, this increased investment leads to an even greater desire to maximize returns. If the cost of change becomes exponential, high cost makes adding features impractical and development must stop. Unfortunately, most companies do not realize this point exists and spend huge sums on dead products.
Software Failure Modes
Exponential costs of change belie a stark reality: Unless the product is shipped before the cost of change becomes exponential, it will very likely fail. Many projects become races to see if enough features can be created to make a viable product before adding the additional required features becomes too expensive.
There are four failure modes that prevent product completion:
Hitting the wall before release: A small team of programmers is making good progress adding features to a product. Before the needed features can be delivered, some event makes the cost of change exponential and all progress stops. These events may include losing a key team member, adding team members to accelerate production, unforeseen difficulties with technology choices, unforeseen requirements, and major changes in target audience/market. Figure 4 shows how the minimum number of features will never be reached.
Figure 4. Teams hit a wall in production when some event causes the cost of change to be exponential so that all progress seems to stop.
90% done: A team of programmers is making steady progress but never finishes the required features because of a gradual rise in the cost of change.
This failure mode is often unavoidable because the riskiest features are often put off until last. These features often require so much complexity that their solutions overwhelm the development process. Proper risk mitigation is essential to avoiding this failure mode.
Figure 5. 90% done is difficult to detect because the cost of change increases slower with no propagating event. The higher the value on delivery and the more required features, the more likely this failure mode.
Endless QA: Endless QA occurs when a product ships with all features completed, but still has too many bugs to make it into production. If the cost curve has become exponential, these bugs will take longer and longer to fix. As the cost of change increases, any given change will likely cause more bugs.
Figure 6 demonstrates how the fixing of bugs once the product is released to QA can ruin ROI. The higher the cost of change before delivery to QA, the larger the number of bugs. Indeed, the number of bugs at QA is a good indirect metric of the cost of change.
Figure 6. A product shipped to QA with a fair number of bugs when the cost of change is exponential is in danger of never being shipped as each attempt to fix bugs will probably produce more, each one costing more to fix.
Version 2.0: Most failures of version 2.0 of any product can be traced to exponential cost of change. During version 1.x, the cost of change has become exponential. The new features will never generate high-enough returns to make up for the costs of producing the version. Figure 7 diagrams this effect. What is most frustrating for many teams is that after a successful first version, the costs of change may have become so high, that it is unlikely the second version will ever ship.
Figure 7. Second releases often fail because the cost of change has become so great it easily overwhelms the value of the second release.
Failure traps
If costs do increase exponentially, development teams must ensure cost is managed until delivery of the product. If they don’t, failure is all but guaranteed.
Unfortunately, there are several traps for developers that accelerate the onset of exponential costs of change. Interestingly, all of these techniques are designed to accelerate development at the beginning of the project, but the costs of using may overwhelms any savings. Here are four of the most common traps:
Prototype trap. Product prototypes are great ways to prove technologies, techniques and reduce risk. However, unless the economics of development are understood, they become liabilities. The problem is how much money is spent on the prototype. If enough resources are spent on any given prototype it becomes too valuable to throw away.
Most developers intend to throw away a prototype once it is completed and the resulting code quickly becomes expensive to change.
The prototype trap can be avoided by ensuring that no significant investment is spent on any given prototype. There are many situations where prototypes are necessary, but they must never endanger a project by reducing the amount of resources available to finish.
4GL trap. 4GLs such as Visual Basic (VB), Forte, 4GL, and Magic allow developers to rapidly develop applications by making assumptions about how data will be accessed and displayed.
The problem with 4GLs is that the code is very hard to modify after it has been created. This accelerates the cost of change. In addition, a language that makes some applications easy to create becomes a hindrance when the problem domain exceeds the design of that language.
Often, the only way around these limitations is to use some other language such as Java or C++ to solve the unsupported problem. The interfaces between multiple languages are notoriously expensive to maintain and extend. Anyone who has tried to make a VB application perform and look like a professional, highly polished standalone application will immediately realize these limitations.
The 4GL trap is easily avoided by understanding the limitations of each language and only using it if all of the features required by the product fit within the assumed model of the language. This is the most insidious part of this trap. Most 4GLs are marketed as being designed for novice programmers with little training. Microsoft has been particularly aggressive in marketing VB to companies as the way to hire ‘cheap’ programmers. Unfortunately, these are precisely the people who should not be making the decision about when a particular language is adequate for solving a given problem. Choosing the wrong language will ensure that the product will never ship.
Scripting trap. Scripting languages allow the easy creation of sophisticated software by sewing together existing applications. Advanced scripting languages such as Perl are very powerful and can be used for a variety of purposes. Operating systems such as Unix are designed to be easily integrated through scripting languages and have far lower cost of ownership than those whose management tools are grafted on with pretty user interfaces.
The trap lies in the sophistication of these languages and the mechanisms that make it easy to write programs. Most scripts are not maintainable or even readable by those people who created them. This does not mean that scripts are bad things. They are the perfect solution for integrating existing tools and making small programs. However, since they are always expensive to maintain, the amount of effort put into any single script should be below the threshold of throwaway code: essentially, it is usually cheaper to rewrite the script than to try to modify it.
A stark example of the scripting trap comes from Excite. Excite built its original search and Web serving infrastructure in Perl on Unix machines. Perl allowed Excite to quickly create products that competed with more mature companies such as Yahoo and Web Crawler. However, by 1998, maintenance expenses made it impossible to add new features. Excite had to stop all production and rewrite its infrastructure in Java. This transition took many months and hindered Excite’s competion in the other markets such as online shopping and video streaming.
Avoiding the trap is relatively easy. There are many applications that are small and will remain small forever. These are perfect for scripting languages. If new features are required, this small size makes it easy to rewrite in an OO language to control cost of change.
Integrated Development Environment (IDE) trap. Many companies product IDEs that allow developers to quickly deploy code that they write. Examples include Microsoft’s Visual Interdev Studio and .NET framework, IBM’s Visual Age and Oracle’s 8i. The problem with these environments is that they make assumptions about the target deployment environment and workgroup configuration.
The problem is that companies do not design these tools to help developers, but lock developers who use their IDE’s into their platforms.
In the real world of changing requirements, platform restrictions are often deadly. These restrictions include limited OS support, limited APIs that may make certain features impossible, or platform bugs. Often, the only way around these restrictions is to rewrite major amounts of code.
The IDE trap is easily avoided by choosing tools that do not lock you into a vendor’s technology. In addition, development teams must deploy to production style systems early in the development process. This allows adequate time to develop the necessary scripts and procedures to ensure proper delivery.
Reengineering trap. Reengineering projects is designed to address exponential cost of change of an existing system. Lessons learned in previous versions can be applied to control the cost of change.
Reengineering almost always fails because the existing code cannot be easily changed because the cost of change is exponential. If the cost of change was not exponential, there would be no reason to reengineer. This makes it extremely expensive to work with the existing code. As a result, reengineering usually takes as long or longer to complete than the original product while producing the same set of features.
If it took 10 man-years to complete the first product, it will probably take 10 man-years to complete the reengineered version with exactly the same features. Ten man-years for a zero-sum gain. This is why reengineering projects are rarely completed.
The reengineering trap is avoided by developing a migration strategy. All new features must be made separate from the original code base to avoid the exponential cost of change and the original code base is mined for completed features.
Whenever a bug is encountered in the original code base or an existing feature needs to be extended, the existing code is removed and refactored into the new code base. These migrations are expensive, but there is no way to avoid them. In this way, an organized reengineering of only those sections that are not currently adequate will be performed. The cost of changing these sections will be exponential, but will hopefully be limited.
Conclusion
In a capitalist economic system, software must possess a positive ROI in order to make sense to an organization.
Many software products fail not because there is no market, but because the cost of creating the software far outstrips any profit. Exponential costs of change exacerbate this problem. Software processes are designed to manage these costs; however, it is crucial that an organization understand how and when the costs of creating software will outstrip the worth of a product.
Fortunately, software products tend to fail in one of four modes. By understanding how these modes organizations can choose the appropriate software process to avoid these failures. Each software process model (waterfall, iterative, spiral) has a different approach of managing costs. How each process attempts to manage costs is beyond the scope of this article. However, understanding how costs contribute to failures is crucial to picking a model and process appropriate for your organization.
Finally, regardless of the chosen software process, there are several traps that can accelerate the exponential cost of software production and must be avoided at all costs. The tools that cause these traps are essential to the existence of any software organization, but inappropriate selection will invariably lead to failure. Fortunately, it is usually possible to avoid these traps.
Carmine Mangione has been teaching Agile Methodologies and Extreme Programming (XP) to Fortune 500 companies for the past two years. He has developed materials to show teams how to move from standard methodologies and non-object oriented programming to Extreme Programming and Object Oriented Analysis and Programming. He is currently CTO of X-Spaces, Inc. where he has created an XP team and delivered a peer-to-peer based communications infrastructure. Mangione is also a professor at Seattle University, where he teaches graduate-level courses in Relational Databases, Object Oriented Design, UI Design, Parallel and Distributed Computing, and Advanced Java Programming. He holds a B.S. in Aerospace Engineering from Cal Poly Institute and earned his M.S. in Computer Science from UC Irvine.
Bibliography
The Mythical Man Month, Brooks, F.P., Addison-Wesley, 1995.
What is software project management? – by Bob Lloyd – Helium
What is software project management? – by Bob Lloyd – Helium
Project management for software development has always relied on the traditional skills of managing the resources required to produce a product. By negotiating agreed schedules with the appropriate people and resources, the aim is to produce software with the right functionality at the right time and at the right cost.
When we plan to build a house, or a car, or some other tangible product, the project management process is well-understood and by and large, we can draw on our past projects to predict reasonable well, how the current project will go. We know that the foundations will go in before the walls, that the windows will go in fairly late, and so on.
And yet the software industry has a long record of late projects, budget overruns, poor functionality, unreliable systems, and cancelled projects. Why should that be? Is it simply that software project managers are doing a poor job? That they are not exerting enough pressure? It’s a little more complicated than that.
The work of a project manager involves steering the development of a product from its inception as a product proposal, perhaps as a vague idea of a product that customers would welcome or a desperate need on the part of key clients, through to the final release and installation. It’s a complex job combining negotiations over resources, plans, skills needed, political influences, financial control, and many other aspects.
The project manager will work with both technical and non-technical people. Among the former group will be technical architects and software designers, programmers, test engineers, installations engineers, security specialists and may include third party companies as well. Amongst the latter group will be project sponsors, business analysts, marketing personnel, sales managers, and senior management. Each will have their own specific agenda and their own vision of what the project should be.
The project manager gets involved when the project has been roughly scoped out but the scope itself, indeed many of the requirements, will change in the course of the project. Any project manager who think that they are dealing with static requirements will quickly realise the dynamic nature of software systems.
The technical people will have a range of tools at their disposal for helping them analyse, design and build the software system and they will be experts in how the system will run and interface with other systems. They will understand the platform in detail and all the relevant technologies and they will be the source of estimates which will be used in plans.
The project manager will liaise with these engineers and receive information from them regularly both about any problems of development, but also progress against the agreed plan. There will always be pressure on the project manager to cut timescales, reduce costs, increase productivity, and perhaps even cut functionality and this will lead to arguments with the developers, even where they are totally committed to the project. Negotiating these differences is a key skill.
Often the generation of an agreed plan is seen as a major priority early in a project because business managers want to know about the resources required, where they are coming from, how much the cost, and which other projects will therefore have to wait. There are political considerations here and project managers may be asked to compromise their own projects for the benefit of others. They are required to defend their ground but also understand the company priorities. So managing stakeholders is also a key skill.
Developers may follow a particular methodology for developing software. Although projects are linear in the sense that the process moves from the first ideas through to a finished, released product, there is inevitably a considerable amount of iteration in software development. Many aspects of software development requires prototyping, iterative testing, integration tests, redesign and rewriting of code.
In a very real sense, it is different from the linear civil or mechanical engineering projects on which much project management training is based. So although methodologies such as PRINCE II and PMBOK may describe linear models of project control, these need significant modification to cope with the complexities of software development. A dogmatic application of these project management methodologies will result in major difficulties and could bring down the project.
Some explanation is needed for claiming a special case for software projects. So what are those special aspects of software that make it so much more difficult for project managers? Why is it that well-established techniques seem to run into so many problems?
When we are building houses, bridges, cars, etc, we are using variations on a design that is known to work. We are working in a well-understood problem domain.
We know a great deal about houses, bridges and cars. It could be said that we also now know a great deal about databases, about websites, about financial systems but there is a deeper structural difference that is often obscured.
In the computing world, the operating system is of critical importance and it changes every year in significant ways. As an example, on the Windows systems there are regular major updates which affect security, the operational context of software, the resources available on the machine, and so on. Any software to be released next year has to take this into account. There is little likelihood that the structural properties of bricks will change so dramatically during the build of a house.
Indeed it goes deeper than this. The very tools used to build the software are themselves changing regularly. Whereas once a great deal of software was written in a language called C++, much of it is now written in C#, and these programs need to interact. The technical aspects of this interaction constitutes a new and less well-understood project risk.
An additional problem for project managers is the means and nature of the testing. For small systems, testing can be relatively simple. But for larger systems, build in layers or large scale modules, the integration becomes a critical problem. If integration is to be done little by little, then the scheduling becomes much more complex with inter-dependencies. Of course critical path analysis can help understand the necessary order of development but sometimes modules or layers require each other for testing to take place.
Sometimes extensive test frameworks, separate software systems, need to be written which is an additional project requirement and cost. Sometimes a software system will behave very differently when it is stressed or fully loaded, scaled up to industrial performance. For example, checking security on 100 users may well appear very fast but if 100,000 users are tested there could be a critical bottleneck rendering the whole system useless.
All of this means that the software project manager cannot simply rely on textbook methodologies, but needs a detailed understanding of the development process itself. It is pointless insisting that an engineer keeps to their planned milestone when they have reached a technical problem that even Microsoft did not foresee.
This structural indeterminacy in software projects has been the subject of study by leading software engineers for many years, particular by Steve McConnell and Steve McGuire. Some develops prefer a more “agile” approach to projects in which the developers themselves determine what is possible on the plan rather than having the involvement of project managers. For projects where customers are willing to negotiate a drip feed of delivered improvements, this can be effective but there are questions about larger more structured projects which have to hit particular commercial deadlines.
Whatever life cycle the project uses, and there are hundreds if not thousands to choose from, they have to be customised to the project to allow the right degree of flexibility to respond to changing requirements and technical problems. But at the same time project managers need to understand that there is a difference in the meaning of the word “quality” when talking about software.
If someone scores 98% in an examination, we say that have achieved an excellent result. If a software engineer scores 98% it means that one line in fifty contains an error and the product cannot be shipped. Pretty good brickwork will not stop a house from being safe and saleable. Just pretty good programming will produce a software disaster.
So although the project manager has to produce a software product that is “good enough”, they have a difficult job scoping the acceptable level of testing. The number of software systems with major problems illustrates the possible consequences of this kind of tactical thinking.
Software project management is a very difficult job. Coping with indeterminacy in the production process, in the technology base, in customer requirements, in a rapidly changing market, together with the constant change in the tools available and the technical knowledge required to understand them, means that it is intellectually challenging and it is no job for the dogmatic or linear thinker.
But at the same time, the achievement in bringing together a complex project which involves people with widely differing skills to solve a unique problem in a way that no-one has ever done before, gives software projects a special appeal.
Giới thiệu WordPress
Giới thiệu WordPress « Vũ Phương
Với khoảng 3 triệu người dùng blog tại WordPress.com (chưa tính số dùng riêng) và khoảng 100.000 bài entry mới mỗi ngày, WordPress đang là một trong những blogging platform mạnh mẽ nhất hiện nay…
WordPress là gì?
WordPress là một blogging platform có mã nguồn mở, một hệ thống quản trị nội dung dành cho cá nhân sử dụng ngôn ngữ lập trình PHP và hệ quản trị CSDL MySQL.
WordPress có từ khoảng năm 2004, tiền thân của nó b2/cafelog. Tuy nhiên đến khoảng tháng 2.2005, với phiên bản 1.5 thì WordPress mới được nhiều người biết đến bởi sự ưu việt và nổi bật trong chức năng của nó.
Phiên bản hiện tại, WordPress 2.5 (ra mắt ngày 29.3.2008 ) thật sự gây được dấu ấn nơi người dùng, nổi trội nhất là Dashboard đã được re-design hoàn toàn, cực kỳ trực quan và thân thiện.
Chức năng nổi bật
Có thể điểm qua một số chức năng của WordPress:
- Hệ thống Template riêng biệt với HTML/CSS. Cho phép người dùng chỉnh sửa, tùy biến giao diện của blog mình ở một mức độ khá thoáng.
- Hỗ trợ các tính năng kèm thêm plugin/widget. Plugin dùng cho WordPress.org, Widget dùng cho WordPress.com
- Hỗ trợ tag. Quá quen thuộc với người dùng blog Yahoo! 360.
- Hỗ chợ tạo chuyên mục. Cho phép một bài viết nằm ở nhiều chuyên mục khác nhau. Kết hợp với tag, đây thật sự là một chức năng đáng giá.
- Hỗ trợ Trackback/Pingback. Đây là một tính năng còn tương đối mới mẻ với những ai đã quen dùng Yahoo! 360. Đây là những phương thức cho phép tác giả nhận được những thông báo khi một ai đó link đến một trong những entry của họ.
- Hỗ trợ link dạng SEO. Ví dụ http://vuphuong87.wordpress.com/2008/04/16/yahoo-360-chia-tay-nguoi-dung-viet-nam/. Tính năng này tăng cường độ thân thiện với người xem và cả máy tìm kiếm như Google, Yahoo…
- Trình soạn thảo tuyệt vời: nhanh và nhẹ. Đổi từ chế WYSIWYG sang HTML Code một cách hoàn hảo chứ không bị thay đổi cấu trúc như Yahoo! 360.
- Và rất nhiều chức năng khác…
WordPress.com & WordPress.org
1. WordPress.com
Có thể hình dùng đơn giản, WordPress.com là một dịch vụ cung cấp blog như Yahoo! 360 vậy. Khi bạn đăng ký, set blog, bạn sẽ sở hữu một blog dạng http://tên_bạn.wordpress.com.
Dĩ nhiên, việc sử dụng “ké” kiểu này mang đến cho bạn một vài hạn chế. Ví dụ, bạn không thể thay đổi file HTML/CSS, không thể cài đặt các plugin, không thể trực tiếp upload nhạc/phim dù WordPress.com hỗ trợ bạn đến 3GB dữ liệu… Mà thay vào đó phải lấy link từ nơi khác, hoặc từ một số nguồn định sẵn của WordPress.com
Tuy nhiên, bạn vẫn có thể sử dụng được tất cả các chức năng trên với điều kiện trả cho WordPress.com một khoảng phí xêm xêm 20 USD/năm cho mỗi chức năng để có thể chỉnh sửa CSS, nâng cấp dung lượng từ 3GB lên 8GB để upload nhạc/phim…
2. WordPress.org
Như đã biết, WordPress là một dự án mã nguồn mở. Do đó, bên cạnh việc cung cấp dịch vụ blog tại WordPress.com thì WordPress.org sẽ cung cấp source cho người dùng.
Có nghĩa là nếu bạn có đủ điều kiện như Domain, Host hỗ trợ PHP/MySQL… bạn hoàn toàn có thể download source do WordPress.org cung cấp và upload lên Host của mình sử dụng. Điều đó đồng nghĩa với việc bạn hoàn toàn tự do với mớ mã nguồn này, từ Source Code đến Template (HTML/CSS) mà không phải trả một khoản phí nào cho WordPress.
Bên cạnh đó, hàng nghìn Plug-in, Template được cung cấp bởi cộng đồng người sử dụng WordPress đang đợi bạn download về sử dụng.
WordPress, sự lựa chọn hoàn hảo
Sử dụng Yahoo! 360 được khoảng 1 năm, WordPress được khoảng gần 1 năm và đặc biệt là trong thời gian gần đây thì thấy rồi Yahoo! 360 chẳng có điểm nào có thể so sánh được với WordPress dù rằng xét về tính chất thì Yahoo! 360 và WordPress có phần khác nhau. Yahoo! 360 là một Social Network, trong khi WordPress chỉ là một Blogging Platform…
Long Bui's Weblog 