Roles

• ScrumMaster: Responsible for facilitating the Scrum process. Directs meetings, enforces rules, keeps team focused, manages artifacts.
• Product Owner: Represents the stakeholders and the business. Articulates their needs.
• Team: Responsible for delivering the product. A cross-functional group that does the analysis, design, coding, testing, communication and documentation.

Artifacts

• User Story: A description of a feature to be implemented, and the acceptance testing criteria for that feature. Typically written by the Product Owner.
• Technical Story: A description of technical work that must to done to support the product. Typically written by the Team.
• Product Backlog: The collection of all stories that have not been completed.
• Sprint Backlog: The collection of stories to be completed in the current Sprint.
• Burndown: A chart that displays remaining work to be done versus time. It is intended to give everyone insight into the progress of the project.

Practices

• Sprint: The period of development, typically lasting 2 to 4 weeks. Scrum uses the term “Sprint” for the Agile concept of “iteration”.
• Sprint Planning Meeting: Prior to the start of the Sprint, this meeting is held to determine which stories from the Product Backlog will be entered into the Sprint Backlog. The Product Owner will prioritize the stories, and the Team will plan the Sprint.
• Daily Scrum: A 15-minute daily meeting for the Team, where each team member describes: what they did yesterday, what they are doing today, and any roadblocks encountered.
• Scrum of Scrums: Used when teams are not co-located. A representative from each team will attend this meeting that occurs after the Daily Scrum.
• Sprint Review Meeting: Review the work that was completed and not completed. Present (demo) the completed work to the stakeholders; incomplete work is not presented.
• Sprint Retrospective: Reflect on the last Sprint, in order to improve the process. Questions to ask: What what well in the last Sprint? What could be done better in the next Sprint?

IID breaks down the development process into short iterations, where each iteration touches all the phases of the software development process: requirements are gathered, architecture and design decisions are made, code and tests are written. At the end of the iteration the customer is able to interact with functional code. By allowing the customer to prioritize the work that is done in each iteration, small increments of functional code are produced according to the customer’s business needs. Iterations are thus able to accelerate the delivery of initial business value; through continuous planning and feedback, that value can be maximized throughout the development process. In a typical Agile project the iterations will last from 2 to 4 weeks, and the number of iterations will be the project length divided by the iteration length.

Although incremental software development methods had been in use for years, Agile became formally described in early 2001 in the Manifesto for Agile Software Development Link. The Manifesto reads:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The following Principles Link underlie the Agile Manifesto.

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Agile is a conceptual framework for lightweight software development. While there are a number of software development methodologies that use Agile methods, two of the most popular are Scrum and Extreme Programming (XP).

Step 1: Install vsftpd
APT (Advanced Packaging Tool) is the software package manager for Ubuntu.

Step 2: Shut down vsftpd
The service will be started immediately after installation. For security reasons, we will shut it down until it is properly configured.

Step 3: Configure vsftpd
Edit /etc/vsftpd.conf and make these suggested changes and additions.

Step 4: Restart vsftpd
Now that anonymous access has been disabled and SSL has been enabled, the FTPS service can be restarted.

Step 5: Create FTPS user
It’s a good idea to create a separate account for updates through the WordPress dashboard. For simplicity, I created a system account with the same username I use for the WordPress admin account. In this example I’m using “ftps”; use whatever username works best for you. The last argument must be the path to the web server directory; ignore the warning about the home directory not belonging to the user. Be sure to give the account a strong password.

Step 6: Add the FTPS user to the www-data group
The new user will need to belong to the www-data group. Again, I’m using “ftps” as the example username.

Step 7: Give the www-data group read/write access
The www-data group will need read/write access to the web server directory.

The phases, and activities performed during the phases, typically consist of the following.

This model is similar to what is often used in manufacturing and engineering, and works well when the requirements gathered at the beginning of the project do not change (or change very little). The model became popular for software development for a number of reasons, including its structured approach, clear delineation of roles and responsibilities, and suitability to estimation and scheduling. Perhaps most importantly, it forces the development team and the business team to agree on the details and scope of the project before any code is written. This last feature is especially important for development teams that are working on a fixed budget or schedule; changes to the documented and signed-off business requirements would necessarily add cost, time or both to the project.

In practice, however, it is seldom the case that the business and project requirements can be correctly captured in the early phases. Frequently the business requirements or processes will change during the course of the project. When the customer finally has a chance to see and interact with the software, near the end of the development phase, it is very common to find that a business requirement was not correctly or adequately documented. The customer may also find that once they have had a chance to interact with the software, that they become aware of a multitude of changes for improvement. Changes at this stage of the project are very costly because the change must start in the requirements phase and then trickle down to the current phase. The Agile Model of Software Development, by comparison, maintains a tight feedback loop with the customer through frequent releases of working software.

1. First, your WordPress site will never be more secure than the server on which WordPress is running. If the server is not secure, then the following advice may do nothing to actually enhance security. See the How-To guides on Securing Linux and Windows for more details.
2. Keep your WordPress software up-to-date. When security holes in WordPress and WordPress modules are found, they will be addressed and new versions released. By using the most recent software versions, you will ensure that your platform is not exposed to known hacks.
3. The default user account that is created with every installation of WordPress is the admin account. Unfortunately everyone, including hackers, know this and can easily launch a dictionary attack on your website to try and guess your password. If a hacker already knows your username that’s half the battle. It’s highly recommended to delete or change the admin account username. You can do this during installation, or by manually changing the user_login value in the wp_users database table.
4. Always use strong passwords for the WordPress administrative and database accounts.
5. Enable SSL on your web server, and then force all logins to be done over SSL. This will encrypt passwords during transmission. You can generate your own or purchase a commercial SSL certificate. Add this line to wp-config.php (before the require of wp-settings.php): define(‘FORCE_SSL_ADMIN’, true);
6. Protect your wp-config file. It should not be accessible from a web browser. Enter these lines into a .htaccess file in the same directory as wp-config.php:
   
<Files wp-config.php>
   Order Allow,Deny
   Deny from all
</Files>


   Then, set the permissions for both .htaccess and wp-config.php to 640.

   > chmod 640 .htaccess
   > chmod 640 wp-config.php

7. Generate unique authentication keys for wp-config.php. The keys provided by WordPress in your configuration file work fine, but your site will be more secure to attacks if you generate your own random keys (the important word being “random”). Visit https://api.wordpress.org/secret-key/1.1/salt/ and copy the 8 generated lines into wp-config.php, overwriting the 4 lines that define AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY and NONCE_KEY.
8. Change the default WordPress database table prefix. This is to secure your installation against hacks, such as SQL injection attacks. Set $table_prefix in wp-config.php. Make sure to add an underscore at the end of the prefix. If you have already installed WordPress, the WP Security Scan plugin can be used to change the database table prefix.
]]> http://www.thirdstone.com/2011/11/howto-secure-wordpress/feed/ 0