48471 ICT Analysis

Subject Outline
UTS: Engineering Autumn semester 2010; City Credit points: 6 cp Requisite(s): ( 48240 Design Fundamentals AND 48260c Engineering Project Management AND (120 credit points of completed study in C10061 Bachelor of Engineering Diploma in Engineering Practice OR 120 credit points of completed study in C10062 Bachelor of Engineering Bachelor of Arts in International Studies Diploma in Engineering Practice OR 120 credit points of completed study in C10063 Bachelor of Engineering Bachelor of Arts in International Studies OR 120 credit points of completed study in C10065 Bachelor of Engineering Bachelor of Business OR 120 credit points of completed study in C10066 Bachelor of Engineering Science OR 120 credit points of completed study in C10067 Bachelor of Engineering OR 120 credit points of completed study in C10073 Bachelor of Engineering Bachelor of Science OR 120 credit points of completed study in C10074 Bachelor of Engineering Bachelor of Science Diploma in Engineering Practice OR 120 credit points of completed study in C10075 Bachelor of Engineering Bachelor of Medical Science OR 120 credit points of completed study in C10076 Bachelor of Engineering Bachelor of Medical Science Diploma in Engineering Practice OR 120 credit points of completed study in C10078 Bachelor of Engineering Bachelor of Biotechnology OR 120 credit points of completed study in C10079 Bachelor of Engineering Bachelor of Biotechnology Diploma in Engineering Practice OR 120 credit points of completed study in C10068 Bachelor of Engineering Bachelor of Business Diploma in Engineering Practice)) Result type: Grade and marks

Subject coordinator
Professor David Lowe

Subject coordinator details

Room 1/2220A Phone: (02) 9514-2526 Email: david.lowe@uts.edu.au

Teaching staff
TBA

Subject description
This problem-based subject focuses on the specification and analysis of assigned, complex Information and Communication Technologies (ICT) projects. Formal, plenary sessions of lecture/tutorials are used to teach project theory whereas problem-based learning is used for the specification and analysis of the assigned projects. Problem-based learning requires students to participate and take the initiative in researching topics not necessarily dealt with by formal sessions but required by the project. In this subject, it is the students' responsibility to work out what they need to learn. Students learn to deal with the analysis phase of the ICT project lifecycle planning; specification and analysis; architecture
11 Feb 2010 University of Technology Sydney Page 1 of 12

and high-level design. In the subsequent design subject (48481), students learn to deal with the development phase of the ICT project lifecycle low-level design; implementing/building the product; plus associated testing. Skills gained include: teamwork; the use of technical planning strategies; experience in the use of standards and industry best practices; formal project specification; system performance analysis; reliability analysis; project risk abatement strategies; quality assurance factors including the quality of product and quality of process; system architecture development; system build and integration strategies; formal project development processes; assessment of managerial, financial, ethical and social issues; verification and validation; and user interfacing issues. Students are organised into large groups of typically 15 to 20 students per group. Each group is then usually subdivided into teams of about three or four. A team will focus on one component of the group assignments. Group subdivision, structure and overall project management is decided by the group members. There are usually three group assignments: Assignment 1 is often the draft of the analysis deliverable, which allows students to prepare and plan for the actual deliverable; Assignment 2 is often the actual deliverable. In Assignment 3, students are usually required to review and critique another group's actual deliverable, which may be used in the subsequent design subject, for development and implementation purposes.

Program

Week
1

Dates
01 Mar

Description
Review Subject Guide with aim of understanding : Subject domain. Introduction to ICT and Administrivia. Standardise time of meetings. Assignments 1 through 3 what is required, value, when due. Quiz what is required, what material to review. Set textbooks what to buy, how to use the library and online facilities. Additional resource material. Topic: Subject Overview Introduction to the Lifecycle. Concepts and Definitions. Group structures and Team models. Command and Control/Collaboration and Leadership. Agile technologies. Adaptation. Philosophical basis for engineering design thinking and practice.

Notes
Discussion Cognitive and Conative models Form Projects Groups: Introduce available projects. Students per project group target=15, maximum=20. Formation criteria. Issue Assignment 1

11 Feb 2010

University of Technology Sydney

Page 2 of 12

08 Mar

Topic: Project Development: Plans: ICT Development Projects myths and facts. Planning and estimating. Human Factors. Methods of project estimation. Scheduling resources. Work Packages. Planning strategies. Risk Management. Discussion: Review of Lecture material. Boundary models/context diagrams. Inferences from the models. Questions as arise

Group Work

15 Mar

Topic: Project Development: Testing: Why test. Testing to specification. All path testing. Cyclomatic complexity. Combinatorial complexity/explosion. Boundary analysis. Cleanroom techniques. Objects. Hardware vs Software Discussion: Review of Lecture material. Review of the three major testing mechanisms. Where those mechanisms apply in the lifecycle IEEE Models. Questions as arise

Group Work

22 Mar

Topic: Project Development: Quality Definitions. Tools and methods. QA and standards. Documentation. Process versus Product quality. Quality planning. Reviews and audits. Configuration Management versioning/release control. Risk management policy. Discussion: Product/Process Quality a
University of Technology Sydney

Group Work

11 Feb 2010

Page 3 of 12

manufacturing metaphor. QA/QC issues. Auditing. Configuration Management tools Questions as arise

29 Mar

Topic: System Requirements Specification. Stakeholders. URDs versus SRS. Problem description. Semantics of expression. Functional, Behavioural, Non-functional, Design constraints. Informal Analysis. Formal Analysis. Validation issues/Validation Matrix. Verification and Validation. Validation cross referencing. Discussion: Review of lecture material. Structure of a specification. Questions as arise

Assignment 1 submitted Review of Assignment 2

05 Apr

Topic: Data Management Persistent Mechanisms/Architecture Analysis/Design Questions. DBMS - General. Relational. 1st to 3rd Normal Forms. Object DBMS. Caching. Proxies and Brokers. Discussion: Review of lecture material. Object analysis of the Library problem. Questions as arise

Group work

12 Apr

Topic: Introduction to Systems Architecture. Architecture design and its process. Physical vs Logical vs Architecture models: Repository, Client Server, Model view controller, Abstract Machine, Control.
University of Technology Sydney

Group Work Form ICTA Dinner Committee

11 Feb 2010

Page 4 of 12

 Layering and partitioning layered architecture. Manager, Event based, Real Time Systems. Distributed Systems Architecture. Three/Four/N Tier. Distributed Objects. Discussion: Architecture case study. Review of lecture material. Quality Analysis of the Library problem using a three tier architecture. Questions as arise

8 (Tute)

19 Apr

(no class)

VC Week

26 Apr

(no class)

Assignment 2 due

03 May

Topic: Classical Systems Design. Historical Approach. Structured Approach. Hierarchies and Structured Chart. Module interface & function specification. Specifying logic. Coupling various forms derived from classical/structured approaches. Cohesion - various forms derived from classical/structured approaches. Factoring. Discussion: Review of lecture material. Some examples of coupling/cohesion. Questions as arise

Group Work

10

10 May

Topic: System Design Fundamentals. Key Design Concepts. Components. Decomposition. Schmidts Principles. Modularity Meyers assessment criteria. Meyers five rules of modularity. Qualities of design and
University of Technology Sydney

Group Work ICT Dinner Committee Feedback

11 Feb 2010

Page 5 of 12

tradeoffs. Coupling/Cohesion. Liskov Substitution Principle. OO design concepts. Designing for Persistence and DBMS. Discussion: Review of lecture material. Questions as arise

11

17 May

Topic: Components and Middleware Components. Components versus Objects. Component Architecture/Design. Genealogy of Middleware. RPC, Encina, TP Monitor. N-Tier and CORBA. Observer and Bridge Patterns. Chain of responsibility and Composite. Discussion: Review of lecture material. Questions as arise. Presentation issues. Review of a commercial presentation.

Group Work ICT Dinner Committee Feedback

12

24 May

Topic: Assignments 2/3 Presentation. Time: 20 minutes per group plus another 5 minutes for questions and answers. A total window of 30 minutes per group, which includes setting up time, testing slides, etc. Who presents first, second, etc., shall be determined by the coordinator.

Group Work ICT Dinner Committee Feedback

13

31 May

Topic: Integration Goals of a design review for integration purposes. Nature of integration and problems that may occur. Integration Management, Planning and Testing. The build plan and simulation support. Integration combinations. Integration orders: Top down, Bottom up, Sandwiching and Slicing. Integration Metrics.
University of Technology Sydney

Group Work ICT Dinner Committee presents arrangements

11 Feb 2010

Page 6 of 12

 Case Study. Discussion: Discussion on Final Quiz and Delivery. FAQs Questions as arise.

14

07 June

Quiz : 1.25 hour (on the whole subject)

Assignment 3 submitted

Additional information
Major Assignment ICTA is a project-based subject to be completed in groups. The projects shall vary from semester to semester. In ICT Analysis, you will be dealing with the first three phases of the project life cycle, Planning, Analysis and Design phases. In 48481 ICT Design (ICTD), you will be completing the project, utilising the design (developed in ICTA), completing the Implementation, Integration and the Testing phases of the problem assigned in ICTA. To make the Analysis Task more manageable, project deliverables are divided into three assignments: Assignment 1 is the planning deliverable, which defines the preparation and planning for the main analysis, design and implementation deliverables; Assignment 2 is the main analysis deliverable; and Assignment 3 completes the Architecture and Design (Architecture/Interface Specification/Design), which will be reviewed within 48481 ICTD as design for development and implementation purposes. Group sizes should be around 15 students, and limited to a maximum of no more than 20 individuals. Each group should be subdivided into no more than 5 teams of 3-4 people which focus on one component of the main deliverable. However, enrolment numbers may dictate different sizes of Groups, which may be less than the maximum shown. With guidance from the Lecturer/Tutor(s) each group shall decide for itself, the subdivision and other structures, to be used for analysing and developing the assigned ICT project i.e., the number and size of teams and how the Group and teams are to be managed. Each student should budget time for the project at the beginning of the semester and endeavour to keep productive within that budget. Each student will be expected to participate in the production of fine quality, but reasonable deliverables. Hence each group will need to carefully organise its activities to produce the desired results within a time budget. As well, each group is expected to co-jointly review a monetary budget and ensure the project does not overspend professional engineers manage budgets, small to large. Each project group shall have a budget of $250,000 for developing the assigned project in both this subject and 48481 ICTD labour cost is $80 per developer hour. Apart from the specific assignment documents, other project artefacts from these group-based activities shall include: individual timesheets, budgetary statements, schedules, meeting minutes, action sheets, quality audits reports and reviews, and
11 Feb 2010 University of Technology Sydney Page 7 of 12

 quality audits reports and reviews, and personal, engineering logbooks (you shall create and maintain an individual engineering logbook, which includes a diary of your participation in the group work, based on an assigned project topic). NOTE: Project visibility is required by both Group Project Managers (PM) and the Subject Coordinator. This will be achieved by weekly individual and group project reports (consolidation of the individual reports). There should be individual reports submitted by everybody within the group and one prepared by the PM a consolidated report submitted each week (by COB Friday each week). Individual reports should be sent to managers and placed in a folder (UTSOnline) while the consolidated report must be emailed to the Subject Coordinator. To ensure project visibility, reports should include: clear identification and allocation of task(s); each tasks priority, status: executed/not executed, level of completion, relationship to the budget, and hours spent; issues including show-stoppers and any other material deemed relevant. The task of collecting individual reports and compiling the consolidated report, could be delegated to someone else in the team (a good helper) if project managers are busy with other tasks. Final Assessment: Individual final marks are computed against totalised group marks, using individual quiz marks and marks awarded for logbooks and verification by delivered group project artefacts for every assignment. It is important the quiz is treated with care and individual logbooks plus project artefacts are maintained at a professional engineering level. Individual marks are determined as follows: GroupMark = Assign1 + Assign2 + Assign3 (/65) IndivMark = LogBook + Quiz (/35) FinalStudentMark = IndivMark + GroupMark*(IndivMark/Average IndivMark) In other words, each students group marks will be scaled by the ratio of their individual mark to that of the class average. Team Organisation When you have been formed into a group, elect a contact/spokesperson for the group. The main duty of this person is to act as liaison between the coordinator/lecturer/tutor and the group. UTSonline discussion boards may be used for group discussion. ICTA uses teamwork because the production of an ICT system requires many hands, and because there are a number of roles in which we wish you gain experience (e.g., quality assurer, team leader, tester, reliability analyst, time performance modeller, etc.). However, there can be difficulties with teamwork including: wasting time travelling to meetings concern about other group members - different expectations about a deliverable. some team members do not contribute but benefit from other team members work. Minimise frequency of meetings by meeting only for reviews and work package definitions. Try to restrict meeting venues to UTS before, during or after class time. Identify early in the semester those group members unable to attend all meetings they may need to take on other responsibilities or drop the subject for this semester. Early in the semester gain a commitment from each team member as to how much effort they can or will contribute to the group i.e., form a social contract. Choose balanced teams with a correct mix of skills and abilities. Research on group activities show the most productive groups are formed from
11 Feb 2010 University of Technology Sydney Page 8 of 12

strangers rather than personal friends. Continuously monitor the progress of the group and make adjustments as necessary. Any serious problems should be brought to the attention of the subject coordinator. The subject coordinator or the lecturer/tutor will only make allowance for teaming difficulties if the problems are brought to the coordinators notice, in writing (emails suffice), well before an assignment is due. Contacting staff Primary point of contact for all issues related to this subject is the three-hour weekly plenary session, followed by peer UTSonline discussion boards. Almost all queries are effectively answered by one of these two means, for the following reasons: If youre wondering about something, there is a good chance someone else is too, and will benefit from any answers or discussion. Theres a good chance you will learn as much or more by discussing subject material with your peers, as you will by getting an answer from an instructor. Queries not appropriate for either of these means of contact can be addressed by direct queries with your instructor at LDC1 consultation hours times shall be advised at the beginning of the semester. Points of information about contacting staff associated with the subject (see communication rules outlined in the Subject Information section below): If you wish to discuss your questions or need further assistance in understanding subject concepts please see the lecturer, after lectures, or during consultation (LDC1) hours. Hierarchy of personal contact is, first with your tutor, then the lecturer and finally the coordinator the coordinator may redirect students who bypass this hierarchy. All email queries, related to the subject, must contain the string [48471] (including the square brackets) within the subject line of the email, or they will be ignored. Requests for handouts, returned assignments, assignment marks, and anything else that has been already dealt with in one of the contact sessions, will be ignored. Requests for special consideration will not be handled by email - standard Faculty of Engineering procedures must be used.

Assessment
Assessment item 1: Assignment 1: Plans Intent: In Assignment 1, you are required to analyse the assigned problem and depict the result using a 'boundary/context model' complete with description/s and use that model to formulate project plans. Aim is to prepare for the implementation of Assignment 2. Assignment 1 includes detailed project plans based on your understanding of the assigned problem. You will be marked as one group according to the deliverable created.

Weighting:

15% of subject

Due:

Thursday 12:00PM (midday), 1/4/10, Room CB01.22.21B. Ext. 2526

11 Feb 2010

University of Technology Sydney

Page 9 of 12

Assessment item 2: Assignment 2 Requirements Specification Deliverable Intent: For Assignment 2, teams should work together and produce a detailed Requirements Specification of your assigned problem, as a group. You should manage and implement this portion of the project according to plans created in Assignment 1. You shall be marked as one group according to this deliverable.

Weighting:

25% of subject

Due:

Friday 5:30PM, 30/4/10, Room CB01.22.21B. Ext. 2526

Assessment item 3: Assignment 3 - Architecture/IRS/Design Deliverable Intent: In Assignment 3, you are required to construct and describe the architecture, associated interface requirements specification and the design of the system specified by your Assignment 2. You will be marked as one group according to the deliverable created.

Weighting:

25% of subject

Due:

Friday Midday, 11/6/10 Room CB01.22.21B. Ext. 2526

Assessment item 4: Engineering Logbooks Intent: Every student is required to maintain an engineering logbook over the entire subject's duration. The log must focus on individual contributions to the ICTA project/s. The main aim of keeping a logbook is to develop professional habits (routines) and skills in keeping technical notes, records of decisions and activities undertaken at the individual, team and group levels. Keep your log accurate and tidy. For a quality engineering logbook you may obtain a personal mark of up to 10% of your final mark see UTSOnline for a guideline.

Weighting:

10% of subject

Due:

Friday Midday, 11/6/10 Room CB01.22.21B. Ext. 2526

11 Feb 2010

University of Technology Sydney

Page 10 of 12

Assessment item 5: Quiz Intent: Questions shall be at a general level, testing the individual's understanding of theory taught and it was applied to the group work carried out during the semester. Students not 'involved' in their project may not be able to pass the quiz. You are marked individually.

Weighting:

15% of subject

Due:

Held during final class session

Required texts
Roger Pressman, Software Engineering: A Practitioners Approach, McGraw Hill or Ian Sommerville, Software Engineering, 7th or 8th edition, Pearson/Addison Wesley.

Recommended texts
1. Stephen R. Schach, Classical and Object-Oriented Software Engineering, 5th and/or 6th Edition, McGraw Hill. 2. Steve McConnell, After the Goldrush Creating a True Profession of Software Engineering, Microsoft Press, 1999. 3. Blanchard, B. S and Fabrycky W.J, Systems Engineering and Analysis. Prentice Hall, NJ, 1997. 4. Cady J, Computer Systems Performance, Management and Capacity Planning, Prentice Hall, 1990. 5. SEI SE-CMM, the Systems Engineering CMM (see resource site) Architecture papers 6. Behforooz and Hudson, Software Engineering Fundamentals, Oxford

Indicative references
Standards Set out below is a list of standards that could be of relevance. Note that in ICTA you are not expected to conform fully to any of these professional standards, but you might obtain ideas by reviewing some of these documents. Note: Copies of these standards are available from the UTS library, refer to: http://standards.ieee.org/catalog/software.html ANSI/EIA-632-1998 Processes for Engineering a System 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology (Revision and redesignation of IEEE Std 729-1983) 730-1998 IEEE Standard for Software Quality Assurance Plans 730.1-1995 IEEE Guide for Software Quality Assurance Plannning (Revision and redesignation of IEEE Std 983-1986) 828-1990 IEEE Standard for Software Configuration Management Plans 829-1983 (R1991) IEEE Standard for Software Test Documentation 830-1998 IEEE Recommended Practice for Software Requirements Specifications 982.1-1988 IEEE Standard Dictionary of Measures to Produce Reliable Software 982.2-1988 IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable
11 Feb 2010 University of Technology Sydney Page 11 of 12

982.2-1988 IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software 1002-1987 (R1992) IEEE Standard Taxonomy for Software Engineering Standards 1008-1987 (R1993) IEEE Standard for Software Unit Testing 1012-1998 IEEE Standard for Software Verification and Validation 1016-1987 (R1993) IEEE Recommended Practice for Software Design Descriptions 1016.1-1993 IEEE Guide to Software Design Descriptions 1028-1997 IEEE Standard for Software Reviews 1042-1987 (R1993) IEEE Guide to Software Configuration Management 1044-1993 IEEE Standard Classification for Software Anomalies 1044.1-1995 IEEE Guide to Classification for Software Anomalies 1045-1992 IEEE Standard for Software Productivity Metrics 1058.1-1987 (R1993) IEEE Standard for Software Project Management Plans 1059-1993 IEEE Guide for Software Verification and Validation Plans 1061-1992 IEEE Standard for a Software Quality Metrics Methodology 1062-1993 IEEE Recommended Practice for Software Acquisition 1063-1987 (R1993) IEEE Standard for Software User Documentation 1074-1997 (Approved Draft) IEEE Standard for Developing Software Life Cycle Processes 1074.1-1995 IEEE Standard for Developing Software Life Cycle Processes 1175-1991 IEEE Standard Reference Model for Computing System Tool Interconnections Includes STL Language Interconnection Profile Form in ASCII format. 1209-1992 IEEE Recommended Practice for the Evaluation and Selection of CASE Tools 1219-1998 IEEE Standard for Software Maintenance 1220-1994 IEEE Trial-Use Standard for Application and Management of the Systems Engineering Process 1228-1994 IEEE Standard for Software Safety Plans 1233-1996 IEEE Guide for Developing System Requirements Specifications 1295-1993 IEEE Standard for Information Technology-X Windows System-Modular Toolkit Environment (MTE) 1298-1992 (AS 3563.1-1991) Software Quality Management System, Part 1: Requirements 1320.1-1998 IEEE Standard for Functional Modeling Language--Syntax and Semantics for IDEF0 1320.2-1998 (Approved Draft) IEEE Standard Conceptual Modeling LanguageSyntax and Semantics for IDEF1F1X97 (IDEFobject) 1348-1995 IEEE Recommended Practice for the Adoption of Computer-Aided Software Engineering (CASE) Tools 1362-1998 (Approved Draft)) IEEE Guide for Information TechnologySystem Definition--Concept of Operations Document 1420.1-1995 IEEE Standard for Information Technology--Software ReuseData Model for Reuse Library Interoperability: Basic Interoperability Data Model (BIDM) 1420.1a-1996 IEEE Guide for Information Technology--Software Reuse-Data Model for Reuse Library Interoperability: Asset Certification Framework 1430-1996 IEEE Guide for Information Technology--Software Reuse-Concept of Operations for Interoperating Reuse Libraries 12207.0-1996 IEEE Standard for Industry Implementation of International Standard ISO/IEC 12207: 1995 (ISO/IEC 12207) Standard for Information TechnologySoftware Life Cycle Processes 12207.1-1997 IEEE Standard for Industry Implementation of International Standard ISO/IEC 12207: 1995 (ISO/IEC 12207) Standard for Information TechnologySoftware Life Cycle Processes--Life Cycle Data 12207.2-1997 IEEE Standard for Industry Implementation of International Standard ISO/IEC 12207: 1995 (ISO/IEC 12207) Standard for Information TechnologySoftware Life Cycle Processes--Implementation Considerations J-STD-016-1995 EIA/IEEE Interim Standard for Information Technology Software Life Cycle Processes Software Development Acquirer-Supplier Agreement (Issued for Trial Use)

11 Feb 2010

University of Technology Sydney

Page 12 of 12