1. Tietojärjestelmien peruskurssi Software engineering Malin Brännback

2. Software Engineering F Use of sound engineering principles F good management practice F applicable tools and methods for SD F Before it was more like ad-hoc

3. SE F More disciplined approach to programming F increase time devoted to program design F increase productivity through savings in testing and maintenance F good design, good documentation, and general control of the project

4. IRACI F Begin with the idea u where do ideas come from? u Don’t ask what should this screen look like or What should this system do? u Turn them into: What can we do to increase sales? How can we improve productivity of our sales force? How can the user best work with this information? u Instead of how can this be done better? Ask how can this be done worse!

5. Idea F Be illogical F try something different - instead of technical journals; try a toy catalogue F visualise the process u form a mental model, walk through the model, diagram the problem on paper F The examples: imagine you are the kid playing the game; contact management system; imagine you are the sales person

6. Idea F Break the bounds - why is there a Save button? F Talk to someone F Brainstorm F Relax F Formalise and evaluate

7. Formalise and evaluate F Does it make sense? F Does it fit with the Enterprise-wide or marketing goals F What risks are involved F What benefits are provided F What are the projected costs F Which idea is best

8. Establish the Requirements F = conceptual design F goal-centred instead of user-centred F create the project team

9. Creating the Project team F The entire definition and direction of the project will come from the project team F significant responsibility F must be carefully selected F teams should include users, because they know the business - they are domain experts

10. Selecting the team members F Too many cooks spoil the broth F too many designers spoil the design F still, when time limits become stressed the problem is solved with adding manpower, like dousing a fire with more gasoline, F keep the team small enough to collaborate effectively

11. The project team F A full team with full responsibility F Then, a core team to do day-to-day work of the project F not more than 5-6 persons F If the project is very large, break it down into smaller pieces with one small team assigned to each pieces

12. The full team F Steering and oversight committee; representatives from all areas that are directly or indirectly affected F regular meetings, responsible for communicating to their departments F access to all project documentation F minimally, users and technical staff F ideally; current and present users, managers of these, support staff, subject matter experts, SW analysts, designers, developers, SW quality control, technical writers, technical support staff

13. Team members and responsibilities F Record keeper; maintains the formal project documents, requirements specifications, architectural design documents F Project manager; directs the project, decides when to bring in specialists, etc. F Decision maker; provides the authority to make final decisions F “Evangelist”; the domain expert with the vision - keeps the project in focus

14. Setting the scope F The scope identifies and limits the business or functional areas affected by the application - application domain F how does the AD inter-operate with other products F when defining the AD keep the project goal in mind. Only those related to the goal should be included - not something for everyone

15. Identifying the needs F What the business needs to achieve and what the user needs to accomplish F task analysis - spend time with the users

16. Specify quality standards F On top of basic business needs u ease of use u conformity to established user interface conventions u maintainability u reliability u performance u acceptable defect level u compatibility with other systems

17. Defining the technical and marketing specifications F Minimal required hardware configurations F Recommended F operating systems F network configuration F language, database F portability, reusability F number of users, volume of data

18. Defining the technical and marketing specifications F Security requirements F interface to other systems F current technical standards F time to market F internationalisation

19. Prioritising the requirements F Quality F schedule F features F Pick two of these. There is a trade-off, e.g. high quality and tight schedule - trade off the features list u “you must have the new accounting system installed by the first quarter”

20. 10 Myths of project planning and scheduling F We have no time to design the application u we will save time and money if we jump into the code  stepping into a train without having time to travel! F Scheduling is for the birds u to plan for a certain amount of time u make sure there is room in the plan

21. 10 Myths of project planning and scheduling F Estimates are certain u estimates are estimates u to help convert numbers on a schedule, define risk factor u add time based on the risk u make room for changes in the plan

22. 10 Myths.. F 8 hours = 1 Day F Keep two sets of schedules F Pump up the pressure u there is a difference between “How can I best implement this?” and “What can I throw together the fastest F If the project is behind, add programmers u if the project falls apart - look at the why and fix the why, Don’t just add resources

23. 10 Myths.. F If we leave Chris alone it will get done u there is always a Chris who can walk on water; only everybody else is keeping Chris busy for technical advise F Interim Releases are a waste of time u how “done” are things F We’ll Catch up!