1. Project Overview for CEN 4010 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.

2. Executive Summary  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.

3. Work Items  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.) 

4. Statement of Work  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.

5.  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.  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.  Development Environment

6. Grammar, Wording, and Professionalism  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 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.

7. Iteration #1 due 16 Jan 2013 – Start of Class Team Formation, Project Identification, Roles, initial Scope, and initial Product Vision

8. Work Item: Executive Summary Work Item: Executive Summary (Word document)  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.

9. Work Item: Risk List  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.

10. Work Item: Team Formation  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.

11. Team Roles and Responsibilities (sample roles)  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)

12. Initial Product Vision See templates on my web page and sample student work. Give this a shot. Will be fully completed on next iteration.

13. Work Item: Approved Project Description  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.

14. Work Item: Iteration Assessment  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

15. Work Item Quality Manager’s Certification  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.

16. Iteration #2 due February 6th Application Modeling and and Process

17. Iteration #2 Purpose of Application Modeling  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.

18. Iteration 2 – Application Modeling and Process Work Items  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.

19. Work Item: Executive Summary  See earlier slide.  Overview of the iteration from top to bottom.  What was done, issues and/problems, changes...  No more than one page.

20. Work Item: Statement of Work  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.

21. 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.

22. Work Item: The Application Glossary  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!

23. Work Item: The Application Rules  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 business rules 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.

24. Work Item: Risks  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….

25. 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.

26. 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.

27. Upcoming and Suggestions Urge you to start the following prototyping: 1.Initial database design (DBD). 2.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.

28. Reminder Please ensure all self and peer reviews are turned in on time – the day this iteration is due.

29. Sprint #3 due February 27th Software Requirements Modeling and Capture. (User Stories / Story Points / Acceptance Criteria)

30. Sprint 3: Software Requirements Modeling and Capture  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.

31. Sprint 3 Software Requirements Modeling and Capture Work Items  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

32. Sprint 3 Work Item: Executive Summary  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.

33. Sprint 3 Work Item: Statement of Work  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.

34. 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.

35. Sprint 3 Work 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

36. Sprint 3 Work 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.

37. 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: Story Points: Acceptance Criteria

38. 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.

39. Sprint 3: Reminder Please ensure all self and peer reviews are turned in on time – the day this iteration is due.

40. Sprint #4 due March 25th Software Architecture Modeling Using Model View Controller (MVC)

41. Sprint 4: Software Architecture  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

42. Sprint 4 Software Architecture Modeling and Design Work Items  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.

43. Sprint 4 Work Item: Executive Summary  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.

44. Sprint 4 Work Item: Statement of Work  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.

45. 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.

46. Sprint 4 Work 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

47. Sprint 4 Work 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.

48. Package Name OO Principle: Modularity What is a Package? 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

49. OO Principles: Encapsulation and Modularity > Subsystem Name Interface Realization Subsystem (stay tuned for realization relationship) What is a Subsystem? 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)…

50. Component Name Design ModelImplementation Model > Component Name Component Interface OO Principles: Encapsulation and Modularity Subsystems and Components Components are the physical realization of an abstraction in the design Subsystems can be used to represent the component in the design

51. Sprint 4 Work Item: Architecture Model Layer Contents - Connectivity Components within these layers are to be connected with dependency arrows if they indeed depend on the services provided by that component or a component within that component. (See examples) Dependencies are captured merely with dashed lines and open arrow heads – the standard UML dependency indicator.

52. … … … Presentation Layer Application Layer Middleware Layer Name each of your layers (probably four…), subsubsystems, packages, classes, etc. etc. See next page. Subsystem name Package name Subsystem name However many Architectural Layers – Basic idea … additional layers as you decide.

53. You need to communicate the interface of each component by taking each component (subsystem) and showing its responsibilities showing the interface. (Note the stereotype below) You will need to show the arguments (as much as possible) that are part of the interface signature. Please note that a package has no specific interface and thus the classes in a package needs to explicitly show its public interface. (name interface) > Maintain Database Addrec(xxxx, xx) bool UpdateRec(xx, xx) int DeleteREc(xxxxxx) etc…… Components and Their Interfaces

54. You may combine this drawing with the previous drawing; otherwise, make this separate. For each component, you should also – as much as possible - include the classes and their properties/methods that are needed to ‘realize’ the interface. Recognize those signatures in the interface must be accommodated by the classes or other components (along with other dependencies ‘they’ might have) in the subsystem. You may also show any dependencies these objects will experience with realizing the interface… (name interface) > Maintain Database Subsystem Addrec(xxxx, xx) bool UpdateRec(xx, xx) int DeleteREc(xxxxxx) etc…… … …… Design Elements in Each Component 1..2 * Add properties, methods, and anything else that will assist in realizing the interface. Showing a dependency between this object (in sub) and an object in another design element (package, here) We are saying that the interface is realized by this combination of objects and dependencies. XXXX Package

55. Sprint 4 Work Item: Architecture Model and Design; Traceability Construct a Traceability Matrix that maps features / user stories/ tasks (the finer the granularity the better) to design components within each layer; that is, the subsystems or packages within those layers. The mapping should extend to components (classes, programs, etc.) within each layer’s components. This may take the form of a simple table with several columns with headers of user story….design component.

56. Sample Traceability Thinking to get you Started. Sample (not complete for this assignment) of Partial Traceability User Story LayerElementComponent PresentationViews Package “PresentationViews Helpers Package “PresentationController Package“ PresentationController Helpers Package“ DomainProject Management Package DomainVersion Management Subsystem InfrastructureBizObjects Package TechnicalUtil Package ServicesPersistence Subsystem ServicesNHibernate Subsystem ServicesNotifications Subsystem ServicesSecurity Subsystem

57. Sprint 4 Work Item: Test Plan and Traceability You are to develop a table (use Microsoft Word / Excel, etc.) that extends the traceability work item to include mapping user stories and tasks and acceptance criteria to program components (within layers) to specific executable tests Each element must name the test, clearly tie it to the items above, and clearly cite what it is designed to test, how it will test it, and expected results. All these activities and their artifacts must tie together.

58. Sprint 4: Reminder Please ensure all self and peer reviews are turned in on time – the day this iteration is due.

59. Sprint #5 due Friday night, April 12 th midnight

60. Sprint 5: Software Design - Purpose  To document the detailed design of application components (subsystems, packages, classes, etc. ) within their respective architectural design. More specifically, document the organization of your source programs and their builds and the data bases, as appropriate within your application architecture framework. (Show me what components you have and where they are located architecturally) To document traceability of user stories and tasks to accreditation criteria and to specific tests in a test plan and test results for each test.

61. Sprint 5 Software Architecture Modeling and Design Work Items  1. Executive Summary to include the Retrospective. Name the Retrospective.  2. Statement of Work (See link on web page) Ensure accuracy.  3. Revisited Work from Sprint 4 (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 Exec Summary  4. Graphical Model of your architecture. Use layered approach (Model, View, Controller) unless previously approved by me. (Resubmit for completeness if yours was good; update if yours was less than very good.) Components within each layer are to be connected both within the layer and to components in lower layers. (Several Sprints did not have the connectivity arrows!) Components within these components (looking for source modules, etc. Name Them.)  5. Traceability and test plan of design components tied back to user stories/ tasks and acceptance criteria (matrix) (more ahead)  6. Develop and document your test plan. This should be taken from your acceptance criteria.

62. Sprint 5 Work Item 1. Executive Summary  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.  Name your Retrospective component within the Exec Summary.

63. Sprint 5 Work Item 2. Statement of Work  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.

64. Sprint 5: Work Item: 3. Revisited Work Items from Sprint 4 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 4, several teams need to revisit a number of artifacts.

65. Sprint 5 Work Item 4. Layered Architecture Model and Layer Contents Within each layer of your MVC design, cite and name your components (e.g. subsystems and packages) and then document (graphically or textually) the components within each of these components. Use the architecture from Sprint 4. Fill in the contents of each component. Descriptions of packages and subsystems are included in previous sprint descriptions. Use them, please. Ensure all connectivity (e.g. dependency arrows, …) are included. (Some did not include these arrows in previous deliverables)

66. Sprint 5 Work Item Traceability: Tests, Acceptance Criteria, Components, and Architecture This is the I have reworded this slide. Here’s what I want. I am after significant traceability mappings. You may need a couple of spreadsheets / column charts to accommodate this. But: Need to show (going backwards) Specific tests (name them) mapped back to Acceptance Criteria – mapped back to Program components (within packages /subsystems, …) mapped back to Software Architecture, mapped back to User stories / tasks. This is (with the last slide) a major effort and must be done well. This is a lot of work!

67. Sprint 5 Work Item: Test Plan This may be also done in matrix format: By functional area, provide your series of named tests mapped only to Acceptance Criteria (see last slide. You may reuse some of it). For each test, do: Name the test Include specific inputs Include anticipated outputs Include the mapped to acceptance criteria End For

68. Sprint 5: Reminder Please ensure all self and peer reviews are turned in on time – the day and time this sprint is due. Please also include (please note that this is very confidential) the grade you think YOU honestly should receive for your effort on the project (not the overall course) and the individual grades each of your team members should each receive for their efforts. Again, confidential to me alone.

69. Sprint 6

70. Sprint 6 Presentation and Final Delivery 15 April: Teams 1, 2 and maybe 3 17 April: Teams 3 and 4 and 5 Final Exam – Week of the 22 nd sometime. Final delivery of product: Friday, 19 April You must provide documentation to me on how to access / run your application. Screen shots would help. I MUST be able to access and run this on my own.