Академический Документы
Профессиональный Документы
Культура Документы
SDLC
SDLC abbreviation stands for software development life cycle
SDLC is a structured methodology used in the development of software products and packages. This methodology is used from the conception phase through to the delivery and end of project delivering software product.
SLDC methodology:
SDLC definition Waterfall SDLC V-Shape SDLC Spiral SDLC RUP SDLC Agile methods
Extreme Programming - XP
For small-to-medium-sized teams developing software with vague or rapidly changing requirements Coding is the key activity throughout a software project Communication among teammates is done with code Life cycle and behavior of complex objects defined in test cases again in code
Release
sof t w are increment proj ect v elocit y comput ed
unit t est cont inuous int egrat ion accept ance t est ing
XP Planning
Begins with the creation of user stories Agile team assesses each story and assigns a cost Stories are grouped to for a deliverable increment A commitment is made on delivery date After the first increment project velocity is used to help define subsequent delivery dates for other increments
XP Design
Follows the KIS (keep it simple) principle Design provides implementation guidance for a story Encourage the use of CRC (class-responsibility collaborator) cards For difficult design problems, suggests the creation of spike solutionsa design prototype Encourages refactoringan iterative refinement of the internal program design
CRC Cards
Class: Class: Descri p tion: Class: Descri p tion: FloorPlan Class: Descrip tion: Responsibility: Descrip tion: Responsibility: Responsibility: Responsibility:
defines floor plan name/type manages floor plan positio ning scales f lo or plan for display scales f lo or plan for display incorporates w alls , doors and w indow s show s position of video cameras Wall Camera
XP Coding
Recommends the construction of a unit test for a store before coding commences Encourages pair programming Integration of work (done by pair programmer) on daily basis Yielding smoke testing helps to uncover errors early
Pair Programming
Pair programming is a dialogue between two people trying to simultaneously programming (analyze and design and test) and understand together how to program better. It is a conversation at many levels, assisted by and focused on a computer -- Kent Beck
XP Testing
All unit tests are executed daily Encourages a regression testing strategy when ever code is modified Acceptance tests are defined by the customer and executed to assess customer visible functionality
3. 4. 5.
Plan by feature -- the development staff plans the development sequence of features Design by feature -- the team produces sequence diagrams for the selected features Build by feature the team writes and tests the code http://www.nebulon.com/articles/index.html
Entry: A brief description of the process, and all preconditions that should hold before the process starts Tasks: A list of all tasks that should be done during the process.
Verification: Conditions which clarify if the process has been completed successfully Exit: A list of all outputs from the process
3.Plan By Feature
4.Design By Feature
5.Build By Feature
Entry Criteria Domain experts, Chief Programmers and the Chief Architect have been selected. Tasks Verification By users & Domain Experts
Tasks Domain decomposed into Major Features Sets Major Feature Sets comprise of Feature Sets Feature Sets comprises Features
Verification Self Assessment of Modeling Team Members Exit criteria Features List
Source: Palmer, SR., Felsing , JM.2002,p.135
Entry Criteria Planning process has completed. Tasks CP, Work Package, Feature Team, Sequence diagram, Update the Object Model. (Next slide) Verification Design inspection is made. Exit criteria Sequence diagram(s). Object model with new/updated classes
Continued (6/8)
Entry Criteria The Design by Feature process has completed. Tasks Class owners implement the classes. Verification Successful Code Inspection & Unit Testing
Disciplines
Model
Understand business & problem domain Identify a viable solution
Implementation
Transform model(s) into executable code
Test
Ensure quality Verify that requirements are met
Disciplines
Deployment
Make system available to end users
Configuration Management
Manage access to project artifacts Control and manage changes
Project management
Managing risks, directing and coordinating people
Disciplines
Environment
Ensuring a proper process, guidance and tools
Releases
SCRUM
Product Owner
Develops and maintains the Product Backlog Prioritizes the Product Backlog Empowered to make decisions for all customers and users Presents and explains Product Backlog to team Scrum Team
Self-organizing Business and technical skills to build an increment of functionality Responsible for estimating and committing to work Full autonomy and authority during a Sprint
ScrumMaster
Responsible for the process Responsible for maximizing team productivity Sets up and conducts meetings Representative to management and team Characteristics of a border collie or sheepdog
Sprints
Inputs
Sprint
Tested Code
Plan sprint durations around how long you can commit to keeping change out of the sprint
Scrum Framework
Roles : Product Owner, ScrumMaster, Team Ceremonies : Sprint Planning, Sprint Review, Sprint Retrospective, & Daily Scrum Meeting Artifacts : Product Backlog, Sprint Backlog, and Burndown Chart
Product Owner
Define the features of the product Decide on release date and content Be responsible for the profitability of the product (ROI) Prioritize features according to market value Adjust features and priority every iteration, as needed Accept or reject work results.
Represents management to the project Responsible for enacting Scrum values and practices Removes impediments Ensure that the team is fully functional and productive Enable close cooperation across all roles and functions Shield the team from external interferences
Scrum Team
Ceremonies
Sprint Planning Meeting Sprint Daily Scrum Sprint Review Meeting
Sprint Planning
Business Conditions Technology Current Product
Meeting
Sprint Backlog
1st Part:
Creating Product Backlog Determining the Sprint Goal. Participants: Product Owner, Scrum Master, Scrum Team
2nd Part:
Participants: Scrum Master, Scrum Team Creating Sprint Backlog
Pre-Project/Kickoff Meeting
A special form of Sprint Planning Meeting Meeting before the begin of the Project
Sprint
A month-long iteration, during which is incremented a product functionality NO outside influence can interfere with the Scrum team during the Sprint Each Sprint begins with the Daily Scrum Meeting
Daily Scrum
Parameters
Daily 15-minutes Stand-up Not for problem solving
Three questions:
1.What did you do yesterday 2.What will you do today? 3.What obstacles are in your way?
Daily Scrum
Is NOT a problem solving session Is NOT a way to collect information about WHO is behind the schedule Is a meeting in which team members make commitments to each other and to the Scrum Master Is a good way for a Scrum Master to track the progress of the Team
Scrum FAQs
Why daily?
How does a project get to be a year late? One day at a time. Fred Brooks, The Mythical Man-Month.
Participants
Customers Management Product Owner Other engineers
Product Backlog
Product Backlog
Requirements for a system, expressed as a prioritized list of Backlog Items Is managed and owned by a Product Owner Spreadsheet (typically) Usually is created during the Sprint Planning Meeting Can be changed and re-prioritized before each PM