Tietojärjestelmien peruskurssi Software engineering

1. Tietojärjestelmien peruskurssiSoftware engineering Malin Brännback

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

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

4. IRACI • Begin with the idea • where do ideas come from? • Don’t ask what should this screen look like or What should this system do? • 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? • Instead of how can this be done better? Ask how can this be done worse!

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

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

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

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

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

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

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

12. The full team • Steering and oversight committee; representatives from all areas that are directly or indirectly affected • regular meetings, responsible for communicating to their departments • access to all project documentation • minimally, users and technical staff • 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 • Record keeper;maintains the formal project documents, requirements specifications, architectural design documents • Project manager;directs the project, decides when to bring in specialists, etc. • Decision maker; provides the authority to make final decisions • “Evangelist”;the domain expert with the vision - keeps the project in focus

14. Setting the scope • The scope identifies and limits the business or functional areas affected by the application - application domain • how does the AD inter-operate with other products • 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 • What the business needs to achieve and what the user needs to accomplish • task analysis - spend time with the users

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

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

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

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

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

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

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

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