Date post: | 15-Dec-2015 |
Category: |
Documents |
Upload: | lacey-marre |
View: | 213 times |
Download: | 0 times |
Methodology
Modeling language Graphical notation used to express
the design Process
Guidelines on what steps to take when developing software
Methodology Goals
Establish rules for applying techniques and notations
Establish heuristics for judging when the different stages are complete
Software Development Lifecycle (SDLC)
Describes each step in the process of developing an application
Sets the course and direction of the project
Software Development Lifecycle (SDLC)
Use case driven Establish the desired behavior of the
system Architecture-centric
For conceptualizing, constructing, managing, and evolving the system under development
Software Development Lifecycle (SDLC)
Iterative Managing a stream of executable
releases Incremental
Continuous integration of the system’s architecture to produce these releases. Each new release embodies incremental improvements over the other.
Waterfall Model Waterfall Model
Regarded as the traditional model for Software development - though only described by Royce in 1970
Clearly defined and delineated steps with time-linear progression
Based on the argument that software development is an engineering discipline and can thus be described similarly to other engineering processes
Waterfall Model
RequirementsAnalysis &Definition
System &SoftwareDesign
Implement-ation & Unit
TestingIntegration& SystemTesting
RequirementsAnalysis &Definition
System &SoftwareDesign
Implement-ation & Unit
TestingIntegration& SystemTesting
Operation&
Maintenance
Software LifecycleBased on
Waterfall Model
Exploratory Programming Exploratory Programming
• Developed from early work in A.I.• Used in situations where a specification cannot be
elicited or is very unclear• Similar to prototyping in that it iterates through a
number of development cycles, but it does not attempt to develop a specification
• Validation and verification are impossible• Tends to result in systems with poorly defined
structure, little or no documentation• Difficult to manage due to lack of definable
milestones in development path
Prototyping Prototyping
• Similar to exploratory programming in that it involves starting with the development of a program
• The aim of the developing prototypes is to elicit and clarify a software specification
• Once a specification is established, a more formal devlopment path is followed
• Currently very much in favour in industry, through RAD and DSDM.
Other Methodologies Formal Transformation
• Used in the development of safety-critical software• Define specification in formal notation (i.e. Z),
thereby preserving all correctness properties• Develop program from formal specification, proving
all components of program through formal correctness proofs.
• Longer time-scale trade-off against higher level of reliability
Software Reuse• Assembly of programs from components• Widely-used for interface design, i.e. Visual Basic,
Visual C++, X-Windows, Delphi, etc.
Managing Software Development Managing Software Development
• Various process models are used• Most common technique is “deliverables”• Ongoing support for waterfall model is explicable
in terms of the ease with which “document deliverables” can be generated at strategic points in the development cycle
• Formal transformation provides the most tightly manageable model
• Prototyping and Exploratory Programming are very difficult to manage in this way, since generating documents at each iteration is uneconomic
• Documentation constrains software reuse
Two “must-have” traits in your project
Strong architectural Vision Well managed iterative and incremental development life cycle.
Strong Architectural Vision
Well Defined Abstractions and Interfaces Clear boundaries between implementation and interfaces Simple architecture: Reuse, Super Classes Given: Good architectures tend to be object-oriented!
Development Life-Cycle
Two ways to “drop the ball”:Dictatorship AnarchyRigid, strictly enforced policies No well-defined life cycleDictate each step Can’t predict anything of development InefficientCreativity punishedBureaucracy Lucky to satisfy customerCustomer’s needs not adhered to
End Result: Unsatisfied Customer
Gathering Requirements
Satisfy Functional RequirementsProblem Statement
Why the System is being CreatedTerse and ConciseFree of Technical Jargon
Gathering Requirements
Use Business Objective not Technical ObjectiveTechnical Objective“We need a Web-based OLTP architecture
for our e-commerce application.”
Business Objective"We would like to increase and efficiently
service our customer base by 25%."
Functional Requirements
Group ProcessIdentify a Champion
True customer of the developers
Identify StakeholdersAnyone who can delay or derail projectAll must buy-in
Functional Requirements
Utilize facilitated sessionsEstablish format and rules
Solicit specifications from stakeholdersPrioritize Functionality
Absolutely RequiredEnhances the productNice to have but not crucial
Assessing Requirements
Identify Domain Experts for each feature
Someone highly knowledgeable in the requirements for the function
Produce first artifactDocument capturing all functional requirementsHigh-level view of the system
• Use Case Diagram
“Success” of a projectSatisfies or exceeds customer’s expectationsDeveloped in a timely fashionResilient to Change
Development ProcessControlled, measured, and disciplinedCreative, Innovative
Iterative, IncrementalControl without affecting creativity
The Role of Process
Diagrams represent concepts in the domain under study Concepts relate to classes but no direct mapping No regard for the software that might implement it Language-independent
Conceptual
UML is process-independent RUP is a development lifecycle
Produce High Quality Software Meet the user’s needs Predictable schedules and budgets
Rational Unified Process
Iterative Maintenance of Models Architecture-Centric Use-Case Driven Object-Oriented Configurable Quality-Control and Risk Management
Rational Unified Process