|
Team |
Max Grade |
Details |
|
OCD |
30 |
|
|
1. Introduction |
|
|
|
2. Domain Description |
10 |
|
|
3. Proposed System |
11 |
|
|
4. Domain Description CDL |
3 |
|
|
5. Appendix |
|
|
|
Overall |
6 |
|
|
SSRD |
30 |
|
|
1. Introduction |
|
|
|
2. Project Requirements |
5 |
|
|
3. Capability Requirements |
10 |
|
|
4. System Interface Requirements |
2 |
|
|
5. Level of Service Requirements |
4 |
|
|
6. Evolution Requirements |
2 |
|
|
7. Requirements CDL |
1 |
|
|
8. Appendix |
|
|
|
Overall |
6 |
|
|
SSAD |
50 |
|
|
1. Introduction |
|
|
|
2. Architectural Analysis |
14 |
|
|
3. System Design |
20 |
|
|
5. Architecture and Design CDL |
2 |
|
|
6. Appendix |
|
|
|
Overall |
6 |
|
|
FRD |
30 |
|
|
1. Introduction |
|
|
|
2. Product Rationale |
7 |
|
|
3. Process Rationale |
7 |
|
|
4. Project Risk Assessment |
7 |
|
|
4. Analysis Results |
3 |
|
|
5. Appendix |
|
|
|
Overall |
6 |
|
|
LCP |
45 |
|
|
1. Introduction |
|
|
|
2. Milestones and Products |
15 |
|
|
3. Responsibilities |
10 |
|
|
4. Approach |
10 |
|
|
5. Resources |
5 |
|
|
6. Appendix |
|
|
|
Overall |
5 |
|
|
Prototypes |
15 |
|
|
Quality and Integrity |
25 |
|
|
ARB Presentation |
15 |
|
|
Client Evaluation |
20 |
|
|
LCA Total |
260 |
|
Detailed grading criteria
OCD
1. Introduction
1.1 Purpose of the Operational Concept Description
1.2 References
2. Domain Description
2.1 Organization Background (1)
No abbreviations, identify history and description. Identify all sponsoring stakeholders clearly
2.2 Organization Goals (1)
Only high level goals and missions, M and R required. Numbering required
No mixing with project goals.
2.3 Current System (2)
Block diagram required, only top two level blocks to be identified. Description of all the interacting systems required.
2.4 Entity Model (2)
Class diagram with appropriate associations and description of the classes required. No tabular descriptions needed.
Few important attributes OK, no types allowed. No operations allowed.
Entire systems cannot be considered entities, only entities about which info is stored in the system.
High level classes or aggregated classes are enough, not too many classes.
2.5 Interaction Model (2)
Use case diagram which is syntactically correct.
No aggregation, cardinality allowed, no classes allowed
Identification and description of the users of the system required, identification of the interacting external systems required
2.6 Organization Activity Model (1)
Activity diagram required, syntactically correct
Does not have to show all life cycle activities in one diagram.
2.7 Current System Shortfalls (1)
Clear description of the shortfalls with link to organization activities and org. goals
3.
Proposed System
3.1 Project Goals and Constraints (2)
Schedule, legacy systems, client availability, budget and tech constraints.
M, R. S. details clearly identified
No mixing with levels of service or capabilities
3.2 Capabilities (2)
Only functional elements, 5 top level enough
No mixing with level of service or project goals
3.3 Levels of Service (1)
Availability, speed, evolvability, portability, correctness, auditing, security, etc.
M, R, S required
3.4 Proposed System Description
3.4.1 Statement of Purpose (1)
Block diagram with two top levels of nesting required
Clear identification of system boundary
3.4.2 Proposed Entities
Same guidelines as 2.4, but only newly introduced entities and their relations with the other existing entities
3.4.3 Proposed Interactions (2)
Only 5-7 top level interactions, screen shots for each
Structured use case descriptions reqd.
3.4.4 Proposed Activities (1)
Correct syntax required
Identification of the proposed workflow and roles
3.5 Redressal of Current System Shortfalls
3.6 Effects of Operation
3.6.1 Operational Stakeholders +
Users, administrator, backup operator, data entry person, no customer or maintainer
3.6.2 Organizational Relationships = 1
Only organization chart required. Should not start too high up, and have only relevant levels of detail
3.6.3 Operational Policies and Constraints +
Operating hours, lateness allowed, usage characteristics
3.6.4 Operational Impacts +
New personnel required
3.6.5 Organizational Impacts = 1
Should be organization wide
4. Common Definition Language (4)
Plenty of terms from the domain described, abbreviations, jargon and customer’s language should be captured.
5. Appendix
Overall: (6)
Good prototype in the appendix
Version should be more than 1 but less than or equal to 2
Proper use of UML
Effective diagrams
Avoided the common pitfalls
Proper linkage between sections of the document.
SSRD
1. Introduction
1.1 Purpose of the System and Software Requirements Definition Document
1.2 References
2. Project Requirements
2.1
Budget and Schedule
(1)
Consistent with LCP and FRD
Exact numbers should be identified
2.2 Development Requirements (2)
Development platform and tools for development
COTS required for integration and testing
Versions of prog. languages
Resources provided by ISD, CSE and other sources
Standards of development for hardware and software to be adhered to
Test data sources
2.3 Packaging Requirements +
Install and uninstall clearly identified
Format and media for packaging and distribution
2.4 Implementation Requirements +
Training, manuals and guides
Data preparation
2.5 Support Environment Requirements = (2)
3. Capability Requirements
3.1 System Definition (1)
System boundary, interacting users and systems identified
3.2 System Requirements
3.2.1 Nominal Requirements (7)
Identification of modes of operation and classes of users
Use case diagram for the entire system requirements set
No levels of service reqs here, no screens
Related to OCD 3.2
Details should identify inputs and outputs, related capability
Should be testable
Titles should accurately reflect requirements which are described as use cases
3.2.2 Off-Nominal Requirements (2)
All extra ordinary situations are identified and handling them is described
4. System Interface Requirements
4.1 User Interface Requirements (1)
4.1.1 Graphical User Interface Standards
No more than one screenshot
Only standards of UI development
4.1.2 Command-Line Interface Requirements
4.1.3 Diagnostics Requirements
4.2 Hardware Interface Requirements
If scanner, bar code reader or printer interface is reqd.
4.3 Communications Interface Requirements
4.3 Other Software Interface Requirements (1)
If interaction with another system required, then identify the interfaces e.g. SIRSI, OCLC, QTVR, browser
5. Level of Service Requirements (4)
M, A, R and S required
Related to OCD 3.3
Desirable and acceptable levels should be clearly identified
Short titles desirable
No mixing with nominal requirements
6. Evolution Requirements
6.1 Capability Evolution Requirements (1)
Clear detailed description of the future features.
6.2 Interface Evolution Requirements
Any possible change in the user interface such as specialized client to browser
6.3 Technology Evolution Requirements
Browser, server, database upgrade strategy
6.4 Environment and Workload Evolution Requirements (1)
Growth profile of number of users, traffic, storage and workload.
7. Common Definition Language for Requirements (1)
Description of the terms introduced in the document such as hardware specifics
8. Appendices
A. Standards Specifications
B. Interface Specifications
Overall: (6)
Precision of the requirements
Well identified evolution requirements
Version should be more than 1 but less than or equal to 2
Avoided the common pitfalls
Proper linkage between sections of the document.
SSAD
1. Introduction
1.1 Purpose of the System and Software Architecture Description Document
1.2 Standards and Conventions
1.3 References
2. Architectural Analysis
2.1 Component Model (7)
Class diagrams for each block and entity from OCD
Each Component in Component Model can derived from
1) OCD Proposed System Entity Model (All Object)
or
2) OCD Block Diagram (Some Object, Some Process)
Each Component can consist of only all Objects or only all Process at a time. Each Component can not consist of some Objects and some process.
Internal structure of OCD entities provided
No tables, UML package and component diagrams
2.2 Behavior Model (6)
Names of use cases should start with a verb
Exception and alternate courses of action identified
Use case diagram consistent with OCD and SSRD
Uses, extends and includes relations to discover internal use cases.
Sequence diagrams for important and complex behaviors
2.3 Enterprise Model (7)
Elaboration of the entities in the OCD
Classes describe in a few lines of text
Associations should be named
No actors allowed in the model, WinWin tool should not be shown as a class in the Enterprise model.
Proper data types required, design types such as int, string and real not allowed. If not provided it is OK
Proper cardinality based on WinWin understanding
Adequate and proper use of association types such as navigation, aggregation and generalization
Role names desirable
3. System Design
3.1 Architectural Views
3.1.1 System Topology (3)
Collaboration diagram
Clear identification of blocks to be built vs bought
Further breakdown of components. Identification of the interaction protocols
3.1.2 Component Specifications (3)
Specification of the component in terms of the services provided and required by each.
3.1.3 Framework and Protocol Specifications (2)
Java VM, HTTP, JDBC, ODBC, OLE, CGI, JSP, AWT, Swing, MFC, TCP/IP, FTP and any other protocols required with versions and vendors
3.1.4 System Deployment View (2)
Correct syntax of the diagram
As few nodes as possible
Correctly identified devices as described in SSRD 4.2, disks
3.1.5 Logical Component View (1)
A package diagram showing how design classes are grouped.
3.2 Class Model (4)
Should identify all classes used in the operations model.
The design should be enough for someone to start coding on that basis, but not necessarily complete as the actual code would be.
Class model should not be humongous, it should be partitioned for proper organization and understanding
Classes should be described in at least a couple of lines.
All the attributes required to be printed out should be identified.
Attribute types should either be standard design types such as string, list, tree, etc or explicitly modeled in the class model
The accessibility of classes (public, private and protected) should be properly designed
Use of role names desirable
Database schema clearly identified
3.3 Operations Model
3.3.1 Critical Algorithms (2)
Identification of critical algorithms to be implemented
Pseudo code, flowcharts or activity diagram for each one
3.3.2 Operation Specifications (3)
The sequence diagram should be one continuous flow.
All objects should belong to some class in the class model
Return flows are not necessary
The message names should be method calls that are described in the appropriate classes of the class model.
Message names may include parameter types
Should start with an actor, system is not a correct actor
Only most important required
3.4 Configuration Model (1)
Identify directory structure for development including data, text, images, programs, tools
Not a copy of the team web site directory structure
4. System Design Common Definition Language (2)
Definition of jargon or terminologies identified in this document
5. Appendices
5.1 Reference
5.2 Vendor documents
Overall: (6)
No repetition of information
Version should be more than 1 but less than or equal to 2
Avoided the common pitfalls
Proper linkage between sections of the document.
Design addresses all the aspects of system behavior
LCP
1. Introduction
1.1 Purpose of the Life Cycle Plan Document
1.2 References
1.3 Assumptions (2)
Relevant project related assumptions specified
2. Milestones and Products
2.1 Overall Life Cycle Strategy (3)
Overall Gantt chart needed
Clear and correct identification of stages and phases
Description of each phase correctly done along with an overview of the internal milestones
2.2 Phase Milestones and Schedules
2.2.1 Engineering Stage (2)
Detailed milestone plan as is
Listing of all the deliverables
2.2.2 Production Stage (5)
Detailed feature lists to be constructed
Tasks to be performed during construction phases
At least one build and integration in the middle of the semester
Increments logically arranged, sufficient parallelism
Milestones and deliverables identified
2.2.3 Support Stage (3)
Tasks and deliverables identified
Future release dates and features to be included identified
3. Responsibilities
3.1 Stakeholder Responsibilities
3.1.1 Stakeholder Representatives (2)
Identified all stakeholders and their detailed roles in each phase
Representatives of stakeholders identified
3.1.2 Engineering Stage
3.1.2 Production Stage (2)
Identified responsible stakeholders for review, testing and training
Identified stakeholders providing technical know how
3.1.3 Support Stage (1)
Maintenance and administration stakeholders identified and responsibilities described
3.2 Development Responsibilities
3.2.1 Development Organization Charts (1)
Org chart for roles not persons. Identify only the developers in the production phase
3.2.2 Staffing (3)
Identify the staff profile, skill requirements and availability dates and levels. Exact numbers of each kind should be identified. Specify how the positions would be filled and who would be responsible for it.
3.2.3 Training (1)
Special skill needs that would be satisfied by on-the-job or specialized training. Identify resources required for that
4. Approach
4.1 Risk Management and Monitoring Procedures (1)
Only approach not the same risk descriptions as the FRD
4.2 Quality Management (1)
Identification of quality standards and plan for achieving those
4.3 Reviews (2)
When are reviews held, how are they organized and what is the result of their outcome? How are these related to the milestones? Inspections for peer reviews
4.4 Configuration Management (1)
Mechanism used for CM and version control
Policy to be followed
4.5 Project Communications (1)
Team web site usage, mail, email, telephone and other mechanisms
Frequency of meetings and protocols
4.6 Status Monitoring and Control (1)
How and when prepared? Who submitted to? How reviewed and acted upon? What is the format?
4.7 Facilities and Related Concerns (2)
Development tools, infrastructure and admin personnel needs
ISD, CSE and other sources identified
Accounts for developers and development locations
4.8 Support Environment, Methods, and Tools (1)
How to be continued into the support phase, which tools are required?
5. Resources
5.1 Work Breakdown Structure (2)
Based on architecture
Modification of the base MBASE WBS
5.2 Budgets (3)
Costs of development
Costs of tools and COTS
Costs of training and transition
Costs of support
Appendices
A. COCOMO Results
B. Gantt Charts
Overall: (5)
Version should be more than 1 but less than or equal to 2
Avoided the common pitfalls
Proper linkage between sections of the document.
At least two forms of COCOMO estimates – SLOC and function points
Estimates less than 20 PM
Detailed Gantt Charts in the appendix
Proper tailoring of guidelines for the project
FRD
1. Introduction
1.1 Purpose of the Feasibility Rationale Document
1.2 References
2. Product Rationale
2.2 Business Case Analysis
2.2.1 Development Cost Analysis (2)
Based on LCP budget for schedule and time
2.2.2 Implementation Cost Estimate (1)
Cost of data entry, new equipment, COTS licenses
2.1.3 Operational Cost Estimate (1)
Cost of administrator, operators
2.1.4 Maintenance Cost Estimate (1)
Cost of upgrading system, fixing bugs, providing new features
2.1.5 Estimate of Value Added and Return on Investment (1)
Benefits analysis and comparison with total costs
2.2 Requirements Satisfaction
2.2.1 Operational Concept Satisfaction (1)
Activities in Ops con are supported by the architecture
2.2.2 Project Requirements Satisfaction (1)
Plan and architecture consistent with SSRD 2
2.2.3 Capability Requirements Satisfaction (1)
How SSAD covers all system requirements of the SSRD
2.2.4 Interface Requirements Satisfaction
SIRSI, BRS, etc are linked to the system?
2.2.5 Level of Service Requirements Satisfaction (1)
How does the SSAD address the levels of service req.
How close to the desirable level can the architecture get?
2.2.6 Evolution Requirements Satisfaction (1)
How does the SSAD allow future satisfaction of the evolution reqs?
How does the LCP plan for future expansion?
2.3 Stakeholder Concurrence
3. Process Rationale
3.1 System Priorities (2)
Identifying features in the increments
At least two priority levels
Grouping high priority reqs into the first increment
How is the construction approach parallel?
3.2 Process Match to System Priorities (1)
Increments consistent with LCP and Project requirements
3.3 Consistency of Priorities, Process and Resources (2)
Staffing, training and tools/facilities related to the increments
4. Project Risk Assessment (4)
Project specific life cycle risks both technical and social
Complete description of risks in terms of desc, risk exposure, risk reduction leverage, contingency plan
5. Analysis Results
5.1 Product Features
5.1.1 Advantages +
Shortfall satisfaction + what else
5.1.2 Limitations = (1)
What does the SSAD not allow, or makes difficult?
How does this not severely affect the stakeholders
5.1.3 Tradeoffs Considered (1)
Architectural. Ops concept and prioritization tradeoffs made
Cost of development tradeoffs made
5.1.4 Changes Not Included
5.2 Commercial-Off-The-Shelf Solutions (2)
List of COTS being investigated or chosen.
Why those chosen are the most appropriate?
6. Appendices
A. Cash Flow Statement
Overall (6)
Version should be more than 1 but less than or equal to 2
Avoided the common pitfalls
Proper linkage between sections of the document.
Risks are described at a fine level of granularity
Numbers and calculations properly presented.