System Development Techniques Individual Assignment
System Development Techniques
Diploma in Information Technology
Lesson 19
Learning outcomes After studying this chapter and the recommended reading, you should be able to:
• Describe the elements of the Unified Process (UP)
• Compare and contrast the features of Extreme Programming and Scrum Development
The Unified Process, Extreme Programming, and Scrum
• The Agile philosophy – has proven to be an effective way to approach software
development in today’s fast-paced, continually changing landscape of computer applications.
– only proposes principles; it isn’t meant to be a complete methodology, with practices and action steps.
• Three methodologies that incorporate Agile principles – The Unified Process, (UP) – Extreme Programming, (XP) – Scrum
The Unified Process, Extreme Programming, and Scrum
• Organizations either mix and match techniques from the three or only adopt a specific set of practices.
• Adoption of these methodologies continues to expand throughout all types of organizations that develop software applications.
The Unified Process
• An object-oriented system development methodology.
• Defines a complete methodology that uses UML for system models and describes a new, adaptive system development life cycle.
• based on an iterative approach – each iteration is like a mini-project, • requirements are defined based on analysis tasks,
system components are designed, and those components are then implemented—at least partially—through programming and testing.
The Unified Process
• The UP divides a project into four major phases.
• Each phases has a different focus. – Inception Phase – Elaboration Phase – Construction Phase – Transition Phase
The Unified Process
• UP Phases – Each phase describes the emphasis or objectives
of the project team members and their activities at that point in time.
– provide a general framework for planning and tracking the project over time.
– Within each phase, several iterations are planned to give the team enough flexibility to adjust to problems or changing conditions.
The Unified Process
• Inception – Develop an approximate vision of the system, – make the business case, – define the scope, – produce rough estimates for cost and schedule. – usually completed in one iteration
The Unified Process
• Elaboration Phase – a high percentage of time is spent on
understanding and analysis. – identify and describe all requirements, – finalize the scope, design – implement the core architecture and functions, – produce realistic estimates for cost and schedule
The Unified Process
• Elaboration Phase – resolve high risks,
• the aspects of the system that pose the greatest risk are identified and implemented first.
• Until developers know exactly how the highest-risk aspects of the project will work out, they can’t determine the amount of effort required to complete the project
– the requirements are expected to evolve and change after work starts on the project.
– usually involves several iterations
The Unified Process
• Construction Phase – Iteratively implement the remaining lower-risk,
predictable, and easier elements and prepare for deployment. • for example, detailing the system controls, such as data
validation, fine-tuning the user-interface design, finishing routine data maintenance functions, and completing the help and user preference functions.
– begins to plan for deployment of the system.
The Unified Process
• Transition Phase – one or more final iterations involve the final user
acceptance and beta tests, and the system is made ready for operation.
– After the system is in operation, it will need to be supported and maintained.
The Unified Process
• UP Disciplines – defines disciplines to use within each iteration. – a set of functionally related activities that contributes to
one aspect of the development project. – include business modelling, requirements, design,
implementation, testing, deployment, configuration and change management, project management, and environment.
– Each iteration usually involves activities from all disciplines.
The Unified Process
• UP Disciplines – each iteration,
typically last four weeks.
– size of the shaded area under the curve for each discipline indicates the relative amount of work included from each discipline during the iteration
The Unified Process
• UP Disciplines – divided into two main categories: • system development activities – business modelling, requirements, design,
implementation, testing, deployment
• project management activities. – configuration and change management, project
management, and environment.
The Unified Process
• UP Phase and Disciplines UP Phase Objective
Inception
Develop an approximate vision of the system, make the business case, define the scope, and produce rough estimates for cost and schedule.
Elaboration
Define the vision, identify and describe all requirements, finalize the scope, design and implement the core architecture and functions, resolve high risks, and produce realistic estimates for cost and schedule.
Construction
Iteratively implement the remaining lower-risk, predictable, and easier elements and prepare for deployment.
Transition
Complete the beta test and deployment so users have a working system and are ready to benefit as expected.
The Unified Process
• UP Phase and Disciplines – All nine UP disciplines are employed throughout
the lifetime of a project but to different degrees. – inception phase, • the project manager might complete a model showing
some aspect of the system environment • the scope of the system is shown by defining many of
the key system requirements and listing use cases (the requirements discipline).
The Unified Process
• UP Phase and Disciplines – inception phase, • To prove technological feasibility, some technical aspect
of the system might be – designed (the design discipline), – programmed (the implementation discipline), and – tested to make sure it will work as planned (the
testing discipline).
The Unified Process
• UP Phase and Disciplines – inception phase, • the project manager – makes plans for handling changes to the project
(the configuration and change management discipline), – working on a schedule and cost/benefit analysis
(the project management discipline), and – tailoring the UP phases, iterations, deliverables, and
tools to match the needs of the project (the environment discipline).
The Unified Process
• UP Phase and Disciplines – elaboration phase • includes several iterations. • the team works on – the details of the domain classes and use cases
addressed in the iteration (the business modeling and requirements disciplines). – complete the description of all use cases to finalize
the scope (the requirements discipline).
The Unified Process
• UP Phase and Disciplines – elaboration phase • the team works on
– The use cases addressed in the iteration are designed by creating design class diagrams and interaction diagrams (the design discipline),
– programmed using e.g. Java (the implementation discipline), – fully tested (the testing discipline). – The project manager works on the plan for the next iteration
and continues to refine the schedule and feasibility assessments (the project management discipline),
– all team members continue to receive training on the UP activities they are completing and the system development tools they are using (the environment discipline).
The Unified Process
• UP Phase and Disciplines – construction phase,
• most of the use cases have been designed and implemented in their initial form.
• focus of the project turns to satisfying other technical, performance, and reliability requirements for each use case, finalizing the design, and implementing the design.
• these requirements are usually routine and lower risk, but they are key to the success of the system.
• the effort focuses on designing system controls and security and on implementing and testing these aspects.
The Unified Process
• UP Disciplines • project management activities. – Configuration and change management • involves setting up processes to support the coding
activities. • includes guidelines as when and how to release code as
well as when and how to manage releases and versions.
– Project management • planning the iterations, assigning work, and verifying
that work has been completed.
The Unified Process
• UP Disciplines • project management activities. – Environment • involves those tasks required to establish the working
environment, – tools to be used by the team. – guidelines about how to work together in an
iterative Agile project.
The Unified Process
• Unified Process – should always be tailored to the project, – tailored to the development team and the specific
project. – choices must be made about which deliverables to
produce and the level of formality, or ceremony, to be used.
– Sometimes, a project requires formal reporting and controls. Other times, it can be less formal.
Extreme Programming (XP)
• An adaptive Agile development methodology • Attempt to take the best practices of software
development and extend them “to the extreme.” • Extreme programming has these characteristics: – Takes proven industry best practices and focuses on them
intensely – Combines those best practices (in their most intense
forms) in a new way to produce a result that is greater than the sum of its parts
Extreme Programming (XP)
• XP core values and practices
Extreme Programming (XP)
• XP core values – communication, – simplicity, – feedback, and – courage
Extreme Programming (XP)
• XP core value: Communication. – One of the major causes of project failure is a lack
of open communication among the right players at the right time and at the right level.
– Effective communication involves not only documentation, but also verbal discussion.
– The practices and methods of XP are designed to ensure that open, frequent communication occurs.
Extreme Programming (XP)
• XP core value: Simplicity. – includes techniques to reinforce this principle and
make it a standard way of developing systems.
• XP core value: Feedback – getting frequent, meaningful feedback is
recognized as a best practice of software development.
– Feedback on functionality and requirements should come from the users, feedback on designs
Extreme Programming (XP)
• XP core value: Courage. – Developers always need courage to face the harsh
choice of doing things right or throwing away bad code and starting over.
– too frequently, they haven’t had the courage to stand up to a too-tight schedule, resulting in bad mistakes.
– XP practices are designed to give developers the courage to “do it right.”
Extreme Programming (XP)
• XP Practices
Extreme Programming (XP)
• XP Practices – Planning – focuses on making a rough plan quickly and then refining it
as things become clearer. – basis of an XP plan is a set of stories that users develop. A
story describes what the system needs to do. – XP doesn’t use the term use case, but a user story and a
use case express a similar idea.
Extreme Programming (XP)
• XP Practices – Planning – Planning involves two aspects: business issues and
technical issues. • business issues are decided by the users and clients, • technical issues are decided by the development team.
– The plan, especially in the early stages of the project, consists of the list of stories (from the users) and the estimates of effort, risk, and work dependencies for each story (from the development team).
– heavily involve the users in the project rather than have them to simply sign off on specifications.
Extreme Programming (XP)
• XP Practices – Testing – tests for each story be written first—before the solution is
programmed. – two major types of tests:
• unit tests : test the correctness of a small piece of code, and • acceptance tests : test the business function.
– The developers write the unit tests, – The users write the acceptance tests.
Extreme Programming (XP)
• XP Practices – Testing – Before any code can be integrated into the library of the
growing system, it must pass the tests. – Automates the test and executes them frequently. – Over time, a library of required tests is created, – when requirements change and the code needs to be
updated, the tests can be rerun quickly and automatically.
Extreme Programming (XP)
• XP Practices - Pair Programming – divides up the coding work.
• one programmer might focus more on design and double-checking the algorithms,
• the other writes the code. – Then, they switch roles; thus, over time, they both think
about design, coding, and testing. – XP relies on comprehensive and continual code reviews. – Interestingly, research has shown that pair programming is
more efficient than programming alone.
Extreme Programming (XP)
• XP Practices - Pair Programming – It takes longer to write the initial code, but the long-term
quality is higher. – Errors are caught quickly and early, two people become
familiar with every part of the system, all design decisions are developed by two brains, and fewer “quick and dirty” shortcuts are taken.
– The quality of the code is always higher in a pair- programming environment.
Extreme Programming (XP)
• XP Practices - Simple Designs – done continually in small chunks. – design must be verified immediately by reviewing it along
with coding and testing. – what is a simple design?
• one that accomplishes the desired result with as few classes and methods as possible
• doesn’t duplicate code. • Accomplishing all that is often a major challenge.
Extreme Programming (XP)
• XP Practices - Refactoring the Code – Refactoring is the technique of improving the code without
changing what it does. – Before and after adding any new functions, XP
programmers review their code to see whether there is a simpler design or a simpler method of achieving the same result.
– Research on Software Design Pattern. – Produces high-quality, robust code.
Extreme Programming (XP)
• XP Practices - Owning the Code Collectively – everyone is responsible for the code. – No one person can say, “This is my code.” – Someone can say, “I wrote it,” but everyone owns it. – Allows anyone to modify any piece of code. – Unit tests are run before and after every change, if
programmers see something that needs fixing, they can run the unit tests to make sure the change didn’t break something.
– This practice embodies the team concept that developers are building a system together.
Extreme Programming (XP)
• XP Practices - Continuous Integration – Small pieces of code—which have passed the unit tests—
are integrated into the system daily or even more often. – Continuous integration highlights errors rapidly and keeps
the project moving ahead. – The traditional approach of integrating large chunks of
code late in the project often resulted in tremendous amounts of rework and time lost while developers tried to determine just what went wrong.
– XP’s practice of continuous integration prevents that.
Extreme Programming (XP)
• XP Practices - On-Site Customer – require continual involvement of users who can make
business decisions about functionality and scope. – Based on the core value of communication, this practice
keeps the project moving ahead rapidly. – If the customer isn’t ready to commit resources to the
project, the project won’t be very successful.
Extreme Programming (XP)
• XP Practices - System Metaphor – “a story that everyone - customers, programmers, and
managers - can tell about how the system works.” – It answers the questions “How does the system work?”
and “What are its major components?”
Extreme Programming (XP)
• XP Practices - System Metaphor – Some metaphors are used repeatedly in software
development. Some common approaches: • Spreadsheet Metaphor • Script Metaphor • Manufacturing Metaphor (e.g. AssemblyLine) • Shopping Cart Metaphor (e-commerce) • Auction Metaphor (e-commerce) • Document Processor (desktop systems where the “model” gets
saved as a file) • Virtual Space Metaphor (eg. VR)
Extreme Programming (XP)
• XP Practices – Small Releases – a point at which the new system can be turned over to
users for acceptance testing and even for productive use. – small and frequent releases provide upgraded solutions to
the users and keep them involved in the project. – Frequent releases also facilitate other practices, such as
immediate feedback and continual integration.
Extreme Programming (XP)
• XP Practices – Forty-Hour Week and Coding Standards – set the tone for how the developers should work. – exact number of hours a developer works isn’t the issue. – issue is that the project shouldn’t be a death march that
burns out every member of the team. – Neither should the project be a haphazard coding exercise. – Developers should follow standards for coding and
documentation.
Extreme Programming (XP)
• XP Project Activities
Scrum
• In Rugby game, a scrum, – is to get a ball back into play after a penalty. – begins quickly, very intense effort, involves the entire team, and
usually only lasts for a short duration.
• Objective is to be quick, agile, and intense and to go the entire distance.
• There are three important Scrum areas to understand: – the philosophy, – the organization, and – the practices.
Scrum
An overview of the Scrum approach
Scrum
• Scrum Philosophy – responsive to a highly changing, dynamic environment in
which users might not know exactly what is needed and might also change priorities frequently.
– Software is developed incrementally, and controls are imposed empirically—by focusing on things that can be accomplished.
– The basic control mechanism for a Scrum project is a list of all the things the system should include and address. • This list—called the product backlog
Scrum
• Scrum Philosophy – product backlog • includes user functions (such as use cases), features
(such as security), and technology (such as platforms). • The product backlog list is continually being prioritized, • Only a few of the high-priority items are worked on at a
time, according to the current needs of the project.
Scrum
• Scrum Organization – product owner
• the client, with additional responsibilities. • maintains the product backlog list. • any function to be included in the final system, it must first
be placed on the product backlog. • any request must first be approved and agreed to by the
product owner. – In a Scrum project, the client controls the requirements. This forces
the client and user to be intimately involved in the project. – Nothing can be accomplished until the product owner creates the
backlog.
Scrum
• Scrum Organization – product owner • In a Scrum project, the client controls the
requirements. This forces the client and user to be intimately involved in the project. • Nothing can be accomplished until the product owner
creates the backlog.
Scrum
• Scrum Organization – Scrum master • comparable to a project manager • enforces Scrum practices and helps the team complete
its work. • hindrance so the team can do its work. • focal point for communication and progress reporting • doesn’t set the schedule or assign tasks, The team
does. • protects the team from any intrusions.
Scrum
• Scrum Organization – Scrum team • a small group of developers—typically five to nine
people • for projects that are very large, the work should be
partitioned and delegated to smaller teams. • if necessary, the Scrum masters from all the teams can
coordinate multiple team activities.
Scrum
• Scrum Organization – Scrum team • sets its own goal for what it can accomplish in a specific
period of time. • organizes itself and parcels out the work to members. • In a small team, it is much easier to sit around a table,
decide what needs to be done, and have members of the team volunteer or accept pieces of work.
Scrum
• Scrum Organization – Scrum team • Team members do talk with users to obtain
requirements, and users are involved in the sprint’s work. • Users can’t change the items being worked on from the
backlog list or change the intended scope of any item without putting it on the backlog list.
Scrum
• Scrum Practices – mechanics of how a project progresses. – basic work process is called a sprint, • all other practices are focused on supporting a sprint.
– A Scrum sprint • a firm period called a time box, with a specific goal or
deliverable.
Scrum
• Scrum Practices – A Scrum sprint • Beginning of a sprint
– the team gathers for a one-day planning session. – the team decides on the major goal for the sprint. – the goal draws from several items on the prioritized product
backlog list. – the team decides how many of the highest-priority items it
can accomplish within the sprint. – Sometimes, lower-priority items can be included for very little
additional effort and can be added to the deliverables for the sprint.
Scrum
• Scrum Practices – A Scrum sprint • After the goal has been agreed and items selected from
the backlog list, it begins work. – The scope of that sprint is then frozen, and no one can change
it—neither the product owner nor any other users. – If users do find new functions they want to add, they put
them on the product backlog list for the next sprint. – If team members determine that they can’t accomplish
everything in their goal, they can reduce the scope for that sprint.
– The time period is kept constant.
Scrum
• Scrum Practices – Scrum planning meeting • Every day the Scrum master holds a meeting with all
members of the team. • Objective is to report progress. • limited to 15 minutes or some other short time period. • Members of the team answer only three questions:
– What have you done since the last daily Scrum (during the last 24 hours)?
– What will you do by the next daily Scrum? – What kept you or is keeping you from completing your work?
Scrum
• Scrum Practices – At the end of each sprint, • the agreed-on deliverable is produced. • A final half-day review meeting is scheduled to recap
progress and identify changes that need to be made for the following sprints. • By time-boxing these activities— the planning, the
sprint, the daily Scrum, and the Scrum review—the process becomes a well-defined template to which the team easily conforms, which contributes to the success of Scrum projects.
Summary
• The Agile philosophy has proven to be an effective way to approach software development in today’s fast-paced, continually changing landscape of computer applications.
• It is only proposes principles; it isn’t meant to be a complete methodology, with practices and action steps.
• Three methodologies that incorporate Agile principles are The Unified Process, (UP), Extreme Programming, (XP) and Scrum.
Summary
• The Unified Process defines a complete methodology that uses UML for system models and describes a new, adaptive system development life cycle.
Summary
• Extreme Programming is an adaptive, Agile development methodology
• An attempt to take the best practices of software development and extend them “to the extreme.” Extreme programming has these characteristics: – Takes proven industry best practices and focuses on them
intensely – Combines those best practices (in their most intense
forms) in a new way to produce a result that is greater than the sum of its parts
Summary
• Objective is to be quick, agile, and intense and to go the entire distance.
• There are three important Scrum areas to understand: – the philosophy, – the organization, and – the practices.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 10