Project Definition: Key Points

Milestone 2 and Group  Product Name

Management Issues  System Description
 A high level description of the system from a
business and user perspective.
 Business Case
 Describe the business opportunity for the product,
and why it differs from what currently is in the
marketplace (if possible).
 What problems it will solve for the target audience?
 What competitive advantages does it offer?
 How can it improve efficiency, effectiveness or
workers?

Project Definition: Key Points Project Definition: Key Points

 User-level goals for the system
 State the main expectations and requirements the user will
have for your system
 User scenarios
 For every main user task that involves your system, describe
a realistic scenario that shows when the user will use the
system and what for
 Scope document
 Describe what your system will and will not do when it is
finished. Be careful to make the scope match with what your
estimated budget.
3 4
 Project Plan/Rough Estimates
 Break down the project into individual tasks, and
 For each task, provide a rough estimate of the number of
hours it will take to complete.
 User involvement plan
 Write a plan for how you intend to involve users
 Including which users you will involve, how much of their
time you will need, when you will need it, and why

Project Definition: Key Points Project Definition: Key Points

 Low fidelity prototypes
 For each of the main interfaces, provide a pencil or
whiteboard drawing of it showing your approach to design
 Consider these UI designs preliminary, for discussion
purposes, and by no means final
 Project management report
 Include the number of hours that group members have spent
on various tasks
 Including meetings and all overhead and administrative time
 Identify any risks that may affect project success (on time,
on budget, with all in scope features included). 5 6
 Project Plan
 Provide a list of who did what for this milestone, and who
will work on what for the next milestone
 If work is done in group, just write “done by group”
 At this stage, most activities will be group activities
 Provide expected dates of completion and expected
effort in hours

1
 Project Definition: Key Points Manage your own project
 Quality Assurance Plan  Consider your own project
 How will you ensure that you produce a quality product?  Need to manage it properly if you are to be successful
 Usability. (e.g., Meetings with key stakeholders. Review of  What are the keys?
product requirements with primary stakeholders.  Using good group management techniques
Walkthroughs of paper prototypes. Testing of product.)‫‏‬  Good planning
 Maintainability.  Defining appropriate scope
 Robustness.  Estimating costs (measured in time in this case)‫‏‬
 Correctness.  Constant care throughout the project
 Flexibility
 Agile response as deviations to the plan occur
 Let’s look at some of these issues since they occur in all
software projects
7 8

Necessity of Working in
Groups Group Management Models
 All large software systems are built by groups  Democratic decentralized
 Too much for any one person to do  no permanent leader, but task coordinators for
important tasks
 Group management thus becomes a critical
determiner of success  decisions made by consensus

 Basic trade-off  Controlled decentralized

 there is a defined overall leader
 Must agree on the need for coordination and
 group problem solving
cooperation  but responsibility for subtasks assigned by the team leader
to keep the whole project on track with the need to separate
Controlled centralized


tasks and goals to allow the various parts of the project to get
done  one overall leader
 coordination at all levels managed by this leader
9 10

Choosing an Appropriate Group

Management Model for Your Project Proven Coordination Techniques
 Which of these models is most suitable given the  Formal group meetings
constraints on your project?  can be virtual
 Since we want everybody to practise as many aspects  but more value in physically collocated meetings
of the software engineering processes discussed in the
class as possible and since all team members are  Frequent reviews
equal, it must be democratic decentralized  requirements
 Such a decision itself has implications, even as to  design
the architecture of the system  code
 want to foster what Herb Simon has called “near  Frequent discussions
decomposability” in the system design  short, frequent meetings (15 minutes - don’t exceed)‫‏‬
 recent progress, immediate next goals
 can sometimes use technology such as e-mail and
11 moodle 12

2
 How to Avoid Difficulties when
Problems with Working in Groups Working in a Group
 Bad characteristics of group members (from surveys of previous  Personal responsibility
years’ students in u/g software engineering courses at U. of S.)‫‏‬
 Project architecture that allows

Lazy or apathetic people – 84%
 Fewer person to person interactions
 Unorganized, irresponsible, unreliable people – 57%  Clear identification of each person’s responsibilities/
 People who are always right: selfish, pushy people – 37% accountability
 Uncooperative, disruptive, obnoxious, negative people – 25%  Communication, communication, communication, …
 Inflexible, close-minded, unimaginative people – 21%  Good planning
Unintelligent people, people lacking skills or knowledge – 19%

 A sharing/caring attitude
 People with low ethical standards, dishonest people – 18%  no prima donnas, no massive egos
 Shy, scared, uncommunicative, unsociable people – 12%  everybody must do their share: can’t have people hog the entire
 People unwilling to share information and work in groups – 10% project or avoid their duties
 People with no interest in high quality work - 9%  Don’t let problems fester
 Do any of these characteristics describe you ???  talk out problems
13 if necessary seek help from peer, tutor, or professor
 How do you know ???-I believe NOT!! 