Rekayasa Perangkat Lunak 2 (IN043): Pertemuan 10 * Construction, Installation and Operations * Agile Method Software Development
Construction Construction is the development of all parts of the system, including the software itself, documentation, and new operating procedures. The Configuration and Change Management workflow keeps track of the state of the evolving system. The evolving information system comprises a set of artifacts that includes, for example, diagrams, source code, and executables.
Designing Tests In object-oriented systems, the temptation is to minimize testing. After all, through the use of patterns, frameworks, class libraries, and components, much of the system has been tested previously. The purpose of testing is not to demonstrate that the system is free of errors. Software testing is similar in that it can only show the existence of errors. As such, the purpose of testing is to uncover as many errors as feasible. There are four general stages of tests: unit tests, integration tests, system tests, and acceptance tests.
Types of Tests (1)
Types of Tests (2)
Error-Discovery Rates for Different Stages of Tests
Class Test Plan Example of a typical unit test plan form of a class.
Class Invariant Test Specification Example of a partial list of the invariant test specifications for a class. Each individual test has a specific objective and describes a set of very specific test cases to examine. In the case of invariant-based tests, a description of the invariant is given, and the original values of the attribute, the event that will cause the attribute value to change, the actual results observed, the expected results, and whether it passed or failed are shown. Test specificationsare created for each type of constraint that must be met by the class. Also, similar types of specifications are done for integration, system, and acceptance tests.
Developing Documentations There are two fundamentally different types of documentation: system documentation and user documentation. System documentation is intended to help programmers and systems analysts understand the application software and enable them to build it or maintain it after the system is installed. User documentation(such as user s manuals, training manuals, and online help systems) is designed to help the user operate the system.
Implementing Change Conversion is the technical process by which a new system replaces an old system. Users are moved from using the as-is business processes and computer programs to the to-be business processes and programs.
Elements of Migration Plan The first step in the conversion plan is to buy and install any needed hardware. Once the hardware is installed, tested, and certified as being operational, the second step is to install the software. The third step is to convert the data from the as-is system to the to-be system. Data conversion is usually the most technically complicated step in the migration plan.
Conversion Strategies
Conversion Style Direct conversion (sometimes called cold turkey, big bang, or abrupt cutover): the new system instantly replaces the old system. Parallel conversion: the new system is operated side by side with the old system; both systems are used simultaneously.
Conversion Location Pilot conversion: one or more locations or units or work groups within a location are selected to be converted first as part of a pilot test. Phased conversion: the system is installed sequentially at different locations. Simultaneous conversion: as the name suggests, means that all locations are converted at the same time.
Conversion Modules A whole-system conversion: in which the entire system is installed at one time, is the most common. Modular conversion: the modules within a system are separate and distinct, organizations sometimes choose to convert to the new system one module at a time.
Selecting the Appropriate Conversion Strategy
Major Factors in Successful Change (1)
Major Factors in Successful Change (2)
Selecting a Training Method
Processing a Change Request
Types of User Documentation Types of user documentation: reference documents, procedures manuals, and tutorials. Reference documents(also called the help system) are designed to be used when the user needs to learn how to perform a specific function (e.g., updating a field, adding a new record). Procedures manuals describe how to perform business tasks (e.g., printing a monthly report, taking a customer order). Tutorials obviously teach people how to use major components of a system (e.g., an introduction to the basic operations of the system).
Organizing Online Reference Documents
Example of Help Topic in MS Word
Guidelines for Crafting Documentation Topics (1)
Guidelines for Crafting Documentation Topics (2)
Agile Software Development (1) The Agile movement proposes alternatives to traditional software development. Agile thought process had started early in the software development and started becoming popular with time due to its flexibility and adaptability. Agile approaches are typically used in software development to help businesses respond to unpredictability. Agile model believes that every project needs to be handled differently and the existing methods need to be tailored to best suit the project requirements. In agile the tasks are divided to time boxes (small time frames) to deliver specific features for a release.
Agile Software Development (2) Iterative approach is taken and working software build is delivered after each iteration. Each build is incremental in terms of features; the final build holds all the features required by the customer. The most popular agile methods include Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM) (1995). These are now collectively referred to as agile methodologies, after the Agile Manifesto was published in 2001.
Illustration of Agile Method
Agile Manifesto Principle Individuals and interactions in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming. Working software Demo working software is considered the best means of communication with the customer to understand their requirement, instead of just depending on documentation. Customer collaboration As the requirements cannot be gathered completely in the beginning of the project due to various factors, continuous customer interaction is very important to get proper product requirements. Responding to change agile development is focused on quick responses to change and continuous development.
Agile vs. Traditional SDLC Methods (1) Agile Agile is based on the adaptive software development methods. Agile uses adaptive approach where there is no detailed planning and there is clarity on future tasks only in respect of what features need to be developed. There is feature driven development and the team adapts to the changing product requirements dynamically. The product is tested very frequently, through the release iterations, minimizing the risk of any major failures in future. Tradition SDLC Model Traditional SDLC models like waterfall model is based on predictive approach. Predictive teams in the traditional SDLC models usually work with detailed planning and have a complete forecast of the exact tasks and features to be delivered in the next few months or during the product life cycle. Predictive methods entirely depend on the requirement analysis and planning done in the beginning of cycle. Any changes to be incorporated go through a strict change control management and prioritization.
Agile vs. Traditional SDLC Methods (2) Customer interaction is the backbone of Agile methodology, and open communication with minimum documentation are the typical features of Agile development environment. The agile teams work in close collaboration with each other and are most often located in the same geographical location.
Pros Agile Methods Pros and Cons Cons Is a very realistic approach to software development Promotes teamwork and cross training. Functionality can be developed rapidly and demonstrated. Resource requirements are minimum. Suitable for fixed or changing requirements Delivers early partial working solutions. Good model for environments that change steadily. Not suitable for handling complex dependencies. More risk of sustainability, maintainability and extensibility. An overall plan, an agile leader and agile PM practice is a must without which it will not work. Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet the deadlines. Depends heavily on customer interaction, so if customer is not clear, team can be driven in the wrong direction. There is very high individual dependency, since there is minimum documentation generated. Transfer of technology to new team members may be quite challenging due to lack of document. Minimal rules, documentation easily employed. Enables concurrent development and delivery within an overall planned context. Little or no planning required Easy to manage Gives flexibility to developers
The Scope of Life Cycles
A Detailed Agile SDLC
Disciplined Agile Delivery (DAD) Framework
DAD Continuous Delivery Life Cycle
The Agile SDLC (High-Level)
The Concept Phase: Pre-Project Planning The Concept Phase, sometimes called Iteration -1, is the preproject aspects of portfolio management, which is focus on: Define the business opportunity. consider the bigger business picture and focus on market concerns. exploring how the new functionality will improve your organization's presence in the market, how it will impact profitability, and how it will impact the people within your organization. Identify a viable for the project. build a new system or buy an existing package and modify it? Assess the feasibility. determine if it makes sense to invest in the potential project.
Inception/Warm Up: Project Initiation The first week or so of an agile project is often referred to as "Iteration 0" (or "Cycle 0") or in The Eclipse Way the "Warm Up" iteration, the goal is to initiate the project by: Garnering initial support and funding for the project. Actively working with stakeholders to initially model the scope of the system. Starting to build the team. Modeling an initial architecture for the system. Setting up the environment. Estimating the project.
The Agile Method Driven Development
Construction Iterations During construction iterations, agilists incrementally deliver high-quality working software which meets the changing needs of our stakeholders, by: Collaborating closely with both our stakeholders and with other developers. Implementing functionality in priority order. Analyzing and designing. Ensuring quality. Regularly delivering working solutions. Testing, testing, and testing.
Testing
Transition During Transition, also known as the "end game" or deployment, solution into production will be released. There are several important aspects to this effort: Final testing of the system. Rework. Finalization of any system and user documentation. Training. Deploy the system.
Production The goal of the Production Phase is to keep systems useful and productive after they have been deployed to the user community. The fundamental goal is to keep the system running and help users to use it. Shrinkwrapped software, for example, will not require operational support but will typically require a help desk to assist users. Organizations that implement systems for internal use will usually require an operational staff to run and monitor systems. This phase ends when the release of a system has been slated for retirement or when support for that release has ended. The latter may occur immediately upon the release of a newer version, some time after the release of a newer version, or simply on a date that the business has decided to end support. This phase typically has one iteration because it applies to the operational lifetime of a single release of your software.
Retirement The goal of the Retirement Phase is the removal of a system release from production, and occasionally even the complete system itself, an activity also known as system decommissioning or system sunsetting. System releases are removed from production for several reasons, including: The system is being complete replaced. The release is no longer to be supported. The system no longer needed to support the current business model. The system is redundant. The system has become obsolete.
Enterprise Unified Process (EUP) Lifecycle
References of Agile Method http://resources.sei.cmu.edu/library/results.cfm http://www.tutorialspoint.com/sdlc/sdlc_agile_model.htm http://www.ambysoft.com/essays/agilelifecycle.html