2
Software Development Activities
• DEFINE the Requirements
• ANALYSE Requirements
• DESIGN the Solution
• DEVELOP the Software
• TESTING the Software
• DEPLOY the Software
• MAINTAIN & MANAGE the Software
6
Incremental Development
• Incorporates customer interaction• Repetitive process that progresses in incremental stages• Maintains focus on manageable tasks• Earlier stages successful before later stages attempted• Spiral model• Prototype – working model of the intended system (or
part of it) – useful to explore an idea• Possible for prototype to develop into the actual
solution over time
7
Roles of Prototypes
• Evolutionary– software adapted gradually as requirements becomes clearer– prototype gradually evolves into end product
• Experimental– Used for evaluating a possible solution e.g. assessing
performance, effectiveness– prototype discarded after evaluation
• Exploratory– Used to help clarify user requirements– Prototype discarded
9
Software Development Methods
• Further divides each stage of the SDLC into a set of steps and rules– Indication detail, nature and order of tasks– Documents needed as input / produced at each stage
• RAD – Rapid Application Development aim:– To shorten development life cycle– Produce systems quicker to respond to rapidly changing
business requirements
• Relies on user involvement & extensively use prototypes to capture requirements
10
Agile Methods
• Philosophy:– Individuals and interactions over processes and
tools– Working software over comprehensive
documentation– Customer collaboration over contract
negotiation– Responding to change over following a plan
• Example RAD
11
Extreme Programming (XP) agile SW development method
• Customer team member
• User stories• Short cycles• Pair Programming• Test-driven
development• Collective ownership
• Continuous integration• Sustainable pace• Open workspace• The planning game• Simple design• Refactoring• Metaphor
12
Choosing a Development Approach
• Avoid a linear (or sequential) approach unless:– requirements are well determined
– design is straightforward and well understood
– development team familiar with area
– project poses little risk
– Project has long-term predictability
– A ‘longer’ delivery time is acceptable
– Cost of changing requirements, design and code is high
13
Choosing a Development Approach
• Incremental (or iterative) development:– Requirements not well understood / unstable
– A need exists to demonstrate feasibility of an idea
– Design is complex and/or challenging
– Development team unfamiliar with area
– Lot of risk
– Long-term predictability NOT important
– Cost of changing requirements, design & code is low
– System evolves in response to developers perception
14
Formal methods- Serious Disadvantages -
• Represents the designer’s understanding of requirements
• Encourage specialization, which lead to poor communication, wasted effort, isolated progress
• Lacks the ability to illustrate a system’s dynamic & adaptable nature
15
Requirements Engineering
• Requirements elicitation– Developer determines client’s needs
• Requirements specification– Developer records requirements
• Requirements validation– Developer checks that requirements are
correctly described and understood
17
Examples of Requirements
• An employee record may be viewed only by a certain group of people.
• A computer-generated identifier must be used to identify each employee.
• The cylinder-head temperature must not exceed the critical value, which varies by engine
• The editor will highlight keywords, which will be selected according to the type of the file being edited.
18
Examples of Requirements
Instead of:• Only personnel can view an employee record
– “requirement” contains an embedded policy– Policies change regularly & should not be hardwired into
requirements– Separate the policy from the requirement
Rather change to:• “Only authorized users may access an employee
record”– Implement access control system where authorized users or
groups can be selected and / or changed
19
Examples of Requirements
• We need a list box to select the loan term– Is it absolutely necessary to use a list box, or– Is a list box used as an example– Discover why they do it rather than it just being
the way that they do it
20
Helpful practices for requirement elicitation
• Become a user – Observe– Build trust– Encourage communication
• Document the requirements– Capture all requirements– Construct use cases and use case diagrams
23
Helpful practices for requirement elicitation
• Don’t overspecify
• Maintain a glossary
• Look to the future
• Manage “feature creep”
• Validate the requirements
24
Helpful practices for requirements change control
• Formal change control board
• Formal change control requests
• Automated change control tools
• JAD (Joint Application Design) sessions
• Requirements inspection for major changes
• Application feature planning
25
Change control considerations
• Evaluate change requirement carefully– Is it merely a nice feature – Does it offer business value
• Ensure everyone knows the cost of changing requirements
• High volume of change request indicates inadequate designs
• Some approaches accommodate changing requirements– Evolutionary-type approaches, e.g. prototypes
28
Changeover to the New System
• Direct changeover– Minimized duplication or work– Thorough planning is required– There are no comparable results
• Parallel Running– Risk is reduced– Results can be compared– Workload is increased
29
Changeover to the New System
• Pilot Running
• Phased Implementation– The System can be released sooner– Client feedback can be obtained– Reduces pressure on the developer– Eases the burden of training-
30
Review and Maintenance
• How satisfied are the clients, with the hardware and software supplied?
• Were the clients happy with their degree of involvement in the development of the system?
• How are staff of the client organization reacting to the new system?
• To what extent does the system fulfill the original client requirements?
• Etc. …
31
Maintenance and Support Guidelines
• Implement change control procedures
• Test and document all changes
• Provide telephone or on-line maintenance support
• Provide on-site maintenance support
32
Team-Oriented Principles and Practices
• Quality is a team issue• A team should communicate effectively and
as one personality• A team should have an identity• Don’t duplicate work.• Monitor the environment for changes• Organize teams around functionality not job
functions
Top Related