Download
1 / 70
E N D
The team projects will consist of a series of iterations which are composed of a number of ‘activities’ which we will call work items. A work item is a unit of work and will frequently result in producing an artifact, such as a document like a use case, perhaps a test plan, a source code module, a user interface prototype, or perhaps an executable. Each iteration (deliverable) will also include some project management documents, such as an executive summary and statements of work, plus the development artifacts. The iterations will be realized in a series of what we will call "sprints," an element of the Scrum project management approach, which is agile in nature (discussed later). Each iteration will provide a measurable increment of real application (business) value to the client. Thus our applications will evolve from providing key, risk-driven required core values into a fully functional system. ProjectOverview for CEN 4010
Every iteration will include an Executive Summary. This is to be a single page document and should summarize the contents of the iteration: What work items were undertaken (list) What work items may have been changed from previous iteration Note: revising artifacts is the norm in an iterative approach to software development. Executive Summary is likely developed by team lead and backup. Executive Summary
Each iteration consists of work items undertaken. Each Work Item will be included in your iteration deliverable to me. The Statement of Work (SOW) (ahead) must include the name(s) of the individual(s) primarily responsible for accommodating each work item along with projected and actual time expenditures. (Some work items will be done by individuals; others by more than one team member.) Work Items
You are to include each individual team member’s statement of work (SOW) Develop a document of sequential SOWs and include as a work item. The template for SOW submission is found on my web page. Please fill it in accurately. No grades are dependent on the content, but good project management requires time accountability. Statement of Work
Development Environment • While we will use Scrum as our agile approach to development work, Scrum is not considered a process by some. Rather it is an management approach. • Many will argue this point. That is fine. But it is, together with elements of the Unified Process, oftentimes considered the most popular hybrid approach to software development. • We will undertake the traditional activities in software engineering ranging from gathering requirements and documenting them in use cases that will be used to drive the user interface, database design, architectural design, design, functional programming, testing, and validation. • Your choice of suitable programming language must fit the application component, from interface design and implementation to functional development to database design and implementation. • Under NO circumstances will poor grammar or ill-conceived sentences be considered acceptable work. Remember: you only get one chance to make a first impression. Poorly done work will really hurt your grade and perception of what otherwise might be high-quality work. This is a graduate level course and mature, professionalism is expected.
Under NO circumstances will poor grammar or ill-conceived sentences be considered acceptable work. Remember: you only get one chance to make a first impression. Poorly done work will reallyhurt your grade and perception of what otherwise might be high-quality work. This is a senior-level capstone course and mature, professionalism is expected. EACH work item of EACH iteration must be reviewed While each team will have a Quality Assurance Manager (ahead) please recognize that every deliverable is the overall responsibility of the entire team. I cannot stress too strongly emphasis placed on professionalism in organization, content, presenting and reporting. Grammar, Wording, and Professionalism
Team Formation, Project Identification, Roles, initial Scope, and initial Product Vision Iteration #1due 16 Jan 2013 – Start of Class
Project Title Standard contents (see previous generic description) Project lead (interim or permanent) will develop the Executive Summary Team roles (initial cut) Initial project scope Initial product vision Describe in summary form the work items undertaken for this iteration. Include any issues encountered. Work Item: Executive Summary(Word document)
Risks will be identified, quantifed, and prioritized. See Risk List in the Word Templates links provided. Undertake an initial risk assessment as best you are able at this time. It will change. In the Iteration Assessment, risk mitigation must be addressed. Work Item: Risk List
List the team members by name and the role(s) each will undertake. Use the descriptors on the next slide. Please realize this may change and be modified as individuals take on new roles as the project evolves, but you should make every effort to nail down roles. While we will be developing the applications using agile development and Scrum in particular, one primary precept of agile development is the self-governing characteristic of Agile. Simply put, this means that the team must govern itself from role selection to planning workload distributions, planning meetings, and more. Work Item: Team Formation
Team lead and backup: Team Quality Assurance Manager : (responsible for ensuring all work items are properly reported, formatted, included on time and more; responsible for work item reports to RTC) Functional Analysts (Requirement Specifications) Application Designers (Modelers; architects) Application Programmers (API / IDE specialists) Database Specialists (database designers; interfacing…) Testing and Reporting ( client representative, analysts; others) Team Roles and Responsibilities (sample roles)
See templates on my web page and sample student work. Give this a shot. Will be fully completed on next iteration. Initial Product Vision
Topic must be pre-approved well before it becomes a part of this iteration. Include full write up. Title Description – several paragraphs Need – Significance? Usefulness? Clients? Availability of Resources to Specify Sources of knowledge Overall Software Development Plan (See Software Development Plan in Templates) It is conceivable that you may not have this item thought out yet. But give it a shot. Will change later. Work Item: Approved Project Description
Frank assessment of iteration 0. (5-10 minutes) One or more team members will report on Iteration 0 in classroom setting. (good, bad, and ugly) What can be done to improve this process? Iteration 0 will be graded. Grades: not team grades. Individual Peer Reviews must be submitted no later than class time on the date on which the Iteration Reports are due/presented. Likely accomplished by Team Leader See Iteration Assessment in Templates Work Item: Iteration Assessment
I certify that to the best of my ability all work items have been completed and are included in the iteration report. _____ Quality Manager’s (QMgr) Name _____ Team Leader’s (TL) Name Comments optional. Work ItemQuality Manager’s Certification
Application Modeling and and Process Iteration #2due February 6th
Purpose: To understand the structure and dynamics of the organization within which the application will operate and the process used to guide this devleopment; To ensure customers, end-users, and developers understand the organization; To derive requirements on systems to support the organization; Several of these work items are pretty short. Only a couple are of substance. Iteration #2 Purpose of Application Modeling
Executive Summary Statement of Work (See link on web page) Ensure accuracy. Revisited Work from Iteration 1 (could be a lot of work) Application Glossary – See templates (short assignment) Application Rules – See templates Application Risk List – See templates; quantify risk items using categories. (see Blackboard) (will take some effort) Features List (simple, bulleted list of required features as you see them now) Try to categorize (Think about this one…) Two page summary on the Unified Process (main features). Two page summary on Agile in general (excluding Scrum) Self and Peer Evaluations via Blackboard, please. Iteration 2 – Application Modeling and Process Work Items
See earlier slide. Overview of the iteration from top to bottom. What was done, issues and/problems, changes... No more than one page. Work Item: Executive Summary
Each team member is to include their own statement of work (SOW) in a single SOW. Put these together into a single component / document in this iteration as you have done. Work Item: Statement of Work
Work Item:Revisited Work Items from Iteration 1 • Cite work items you have revised, what you have done and include them in this deliverable. • You may check with me first, if you wish. When I have said ‘fix’ an artifact or revisit it, please do.
Use the Business Glossary template. Definitions of important terms used in the enterprise. (alphabetical) Key words: (sometimes these are called ‘core abstractions.’ ) These are often the ‘things’ the enterprise deals with. Nouns. A Student Registration system might have key words like Course, Schedule, Payment, Registration, Student, Professor, …. What is needed here are acronyms, important definitions, basically the jargon of the organization. These will be heavily referred to when we do use cases! Work Item: The Application Glossary
Use the Business Rules template. See examples on my web page. These are merely samples. Be careful: The samples on my web page are Rules for an Application. In principle, the formal approach is to develop business rules for the entire organization and not for the specific application domain. For our projects this year, you are to develop businessrules for the specific application domain for which we will be developing the application. Business Rules are policy declarations or conditions or guidelines that must be satisfied in running the business. Work Item: The Application Rules
Use Business Risks template. All risk items must fall into a category and must be quantified and prioritized please. See handout in Blackboard for discussion. What are some of the risks that the organization and developers must be constantly assessing: Clients: market share, technology awareness, new statutes from Washington D.C., the state of Florida; trends in the industry; demographics; Developers: Include environmental considerations; personnel risks; technology risks; economic risks; time constraints; give this some thought…. Work Item: Risks
Work Item: Features • This is your first attempt to simply provide a bulleted list of ‘things’ or functional characteristics that the application you are developing must provide. • Try to categorize these by end-user, CIO, etc. as appropriate. • These are typically functional requirements but should also include non-functional requirements. • Again, at this stage, simply a bulleted list is good, but be careful: Be sure what you include or exclude and also be aware of what is ‘in scope’ and what might be out of scope. • We can talk if necessary. • Remember: Be careful what you cite. Think about these.
Work Item: Short Synopses of Unified Process and Agile (without Scrum) • Write up a two page summary on the Unified Process (main features). • Write up a two page summary on Agile in general (excluding Scrum) • This will be useful for you to study for the quizzes and the first midterm coming in February.
Upcoming and Suggestions • Urge you to start the following prototyping: • Initial database design (DBD). • Initial User Interface (UI) prototype using scripting languages (Javascript/ jQuery, etc.). • These will be required next go around. So for those of you who want to get started on the design components, here’s your chance. • If you elect to turn one or both of these in, I will take a look.
Please ensure all self and peer reviews are turned in on time – the day this iteration is due. Reminder
Software Requirements Modeling and Capture. (User Stories / Story Points / Acceptance Criteria) Sprint #3due February 27th
Purpose: To elicit, refine, and document the functional and non-functional requirements of your application using user stories and tasks. To plan your sprints and sprint deliverables. To provide you additional study on course topics for exams upcoming To ensure all stakeholders: customers, end-users, developers, etc. understand the requirements and may validate your development efforts. Sprint 3: Software Requirements Modeling and Capture
Executive Summary to include the Retrospective Statement of Work (See link on web page) Ensure accuracy. Revisited Work from Iteration 2 (could be a lot of work) Application Glossary, Rules, and Risks Lists (correct / update as needed) Categorized Features List (simple, bulleted list of required features) Using the Features List as Primary input, you are to develop (main thrust this sprint) Comprehensive Collection of User Stories and Related Tasks including separate table or index capturing Evaluation of user stories / tasks w/matrix of descending numeric values Tentative assignment of tasks to upcoming Sprints based on user stories. Study materials involving: Two page summary on Software Requirements Engineering Two page summary on Ways of Writing System Requirements Specs Two page summary on Requirements Analysis Two page summary on Requirements Management One page summary of your Database Design and User Interface Prototype Sprint 3Software Requirements Modeling and Capture Work Items
See earlier slide. Overview of the iteration from top to bottom. What was done, issues and/problems, changes... No more than one page. Let this Executive Summary constitute the Sprint Retrospective. Sprint 3Work Item: Executive Summary
Each team member is to include their own statement of work (SOW) in a single SOW. Put these together into a single component / document in this iteration as you have done. Sprint 3 Work Item: Statement of Work
Sprint 3: Work Item:Revisited Work Items from Iteration 2 • Cite work items you have revised, what you have done and include them in this deliverable. • You may check with me first, if you wish. When I have said ‘fix’ an artifact or revisit it, please do.
Sprint 3Work Item: User Stories • This is the main thrust of this Sprint: • Using your list of Features from iteration 2, you are to develop a comprehensive list of user stories and accompanying tasks. Additional notes will be provided in class. • Use the textbook and lecture slides as guides. • You may access the web for alternative templates of user stories if you wish, but you must get concurrence from me on a different format first. • Include in tabular form your team assessment of story points
Sprint 3Work Item: Story Points • You are to develop a table (use Microsoft Word) that names the user story and task with accompanying story points • Story Point Index should list these in descending numeric values based on User Stories. • You may indent the Tasks for readability. • As stated, since you have no idea regarding team velocity, this is quite tentative. It will be adjusted for subsequent sprints. But be aware that all of the functionality captured in the user stories must be accommodated by your application and validated by acceptance criteria.
Sprint #3Work Item: Story Points: Acceptance Criteria • As stated, this Sprint must include specific user stories / task forecast for this sprint. • Each user story / task must include corresponding acceptance criteria. • For user stories, acceptance criteria must map acceptance criteria to stores/tasks • Develop test plan for all stories / tasks in sprint • A burn-down chart is optional – but nice • A Traceability Matrix for mappings above is optional but nice
Sprint 3 Work Item: Short Two Page Synopses of Each of the Following Topics • Software Requirements Engineering • Ways of Writing System Requirements Specs • Requirements Analysis • Requirements Management • Update your Database Design status and User interface Prototype status (one page) • While these represent design activities, you definitely should start to address these topics. • This will be useful for you to study for the quizzes and the next midterm coming in March.
Please ensure all self and peer reviews are turned in on time – the day this iteration is due. Sprint 3: Reminder
Software Architecture Modeling Using Model View Controller (MVC) Sprint #4due March 25th
Purpose: To craft a software architecture to support follow on development and test. To capture major design elements within this architecture and map them (trace) from user stories / tasks to program component, acceptance testing, and the test plan. Understand different architectural models Their strengths and weaknesses Their application domains Ensure traceability between architectural model and requirements specifications Hone UI prototype and Database schema Include subsystems / packages within layers within an MVC layered architecture. Gain more experience with Scrum as an agile development approach Sprint 4: Software Architecture
Executive Summary to include the Retrospective Statement of Work (See link on web page) Ensure accuracy. Revisited Work from Sprint 3 (user stories, acceptance criteria) Several teams need to upgrade their user stories / story points / acceptance criteria This will be looked at carefully. Do include mention of this within your Exec Summary. Graphical Model of your architecture. Use layered approach (Model, View, Controller) unless previously approved by me. Each layer is to consist of subsystems / packages separating areas of concern within the appropriate layer Components within each layer are to be connected both within the layer and to components in lower layers. Traceability and test plan of design components (packages / subsystems) back to user stories / tasks. (matrix) Develop and document your test plan. This should be taken from your acceptance criteria. Sprint 4Software Architecture Modeling and Design Work Items
Overview of Sprint: top to bottom. What was done, issues and/problems, changes... No more than one page. This Executive Summary includes / constitutes the Sprint Retrospective. Sprint 4Work Item: Executive Summary
Each team member is to include their own statement of work (SOW) in a single SOW. Put these together into a single component / document in this iteration as you have done. Please ensure your hour accounting is accurate. Let the entries reflect the work each of you have done. Sprint 4 Work Item: Statement of Work
Sprint 4: Work Item:Revisited Work Items from Sprint 3 • Cite work items you have revised, what you have done and include them in this deliverable. • You may check with me first, if you wish. When I have said ‘fix’ an artifact or revisit it, please do. • I will check previous feedback to you • Again, after grading Sprint 3, several teams need to revisit the user stories, tasks, story points, acceptance criteria, and these mappings.
Sprint 4Work Item: Architecture Model • This is the main thrust of this Sprint: • Using your user stories, tasks, and acceptance criteria from previous sprints, you are to design a layered architectural model (using MVC architectural pattern) to capture your architecture. • I will provide some samples ahead to guide you. • Layers should include • Presentation • Application and/or business and application layers • Services (database, other engines needed) • Operating System / infrastructure support
Sprint 4Work Item: Architecture Model Layer Contents in Architecture Model • Using your user stories, tasks/ acceptance criteria: • Dependencies captures with arrows must flow from individual components within each layer to components to lower layer(s). • All components must be named (and stereotyped if appropriate) • These components will / may have programs / classes, or other components in them that you need to name at this time. Thus you may need to separately graph the individual components (subsystems or packages) to reflect the programs / classes. • Name of component must reflect its function, such as a window (loginWindow, mainWindow….) or whathaveyou in the layer in which it resides.
A package is a general purpose mechanism for organizing like elements into groups A model element which can contain other model elements Uses Organize the model under development A unit of configuration management What is a Package? OO Principle:Modularity Package Name
A combination of a package (can contain other model elements) and a class (has behavior) Realizes one or more interfaces which define its behavior Interface is an abstract class. Subsystem implements (realizes) the interface (interfaces)… Realization <<subsystem>> Subsystem Name Subsystem Interface Interface What is a Subsystem? OO Principles: Encapsulation and Modularity (stay tuned for realization relationship)
Components are the physical realization of an abstraction in the design Subsystems can be used to represent the component in the design <<subsystem>> Component Name Component Interface Subsystems and Components Design Model Implementation Model Component Name Component Interface OO Principles: Encapsulation and Modularity
