Software Engineering
Introduction Software engineering Statistics Software Development Process Models Project Management Overview
Situation Before programs were quite small written by one person Today large programs developed by team Introduction programmers are not future users of system have no expert knowledge of application area in question
Software crisis 60 and still Software delivered too late going on Programs did not behave as users expected Programs were rarely adaptable to change requirements Many errors were detected after the software had been delivered to the customer
Software Engineering Designing, building and maintaining software products time cost quality security
Development project (The CHAOS-report, The Standish Group 1994)
Development project (The CHAOS-report, The Standish Group 2001)
Development project (The CHAOS-report, The Standish Group 2003)
Development project (The CHAOS-report, The Standish Group 1994-2003)
Software development process Problem Requirements specification Design Implementation Testing/Integration Maintenance
Idea or problem to be solved Discovery (listen and observe) Who initiate project Refinement (interrogate and clarify) Modelling (suggest and verify) Questions What is the problem? Is it possible? Should we do it? and how? Is it profitable? Outcome is sufficient understanding of the problem desicion continue/cancel
Requirements specification Requrement analysis (intern och extern) Analysis of ev. existing system Need to write down unambigously what the required behaviour is System proposal Structured documents Detaljed project plan Outcome: requirement specification that communicates the required features of the system to the designer
Develop a solution meeting requirements Use past experience Design Often need to innovate at some level Generate possible solutions Select among them Outcome: design document that unambiguously communicates the design to the implementor
Writing code Documenting code Implementation Feedback to designer and/or analyst Outcome: documented and working code ready for testing
Need to check that imlementation matches design Testing Must test individual modules and then complete system Test interaction with existing environment/software/data/etc. Outcome: correctly working system
Undetected problems Changed user requirements Maintenance Further development of the system (additional functionality, further integration with other systems)
Kinds of models Different kinds of models are known and used, for example Waterfall Spiral Prototyping Agile methods (XP)
Traditional watterfall model Classic lifecycle model Sequential development Output of one step is input of another
Traditional watterfall model Advantages Easy to understand and implement Identifies deliverables and milestones Identifies system requirements long before programming begins (define before design and design before code)
Traditional watterfall model Disadvantages Long time between system proposal and delivery of new system Dificult and expensive to make changes Doesn t match reality well
Spiral model Start with critical parts Key idea: on each iteration identify and solve the sub-problems with the highest risk. Each cycle includes Requirement engineering Design Implementation Testing
Advantages Spiral model Realism: the model accurately reflects the iterative nature of software development on projects with unclear requirements Flexible: incorporates the advantages of the waterfall and prototyping methods Comprehensive model decreases risk Good project visibility.
Disadvantages Spiral model Needs technical expertise in risk analysis to really work Model is poorly understood by non-technical management, thus not so widely used Complicated model, needs competent professional management
Prototyping Customers are non-technical and usually don t know what they want/can have. 1. User formulate requirements 2. First version of the system is produced (quick design and build prototype)on the basis of these requirements 3. User starts to work with the system (evaluate), which leads to new/changed requirements 4. Next version is developed After a number of iterations user is satisfied Last version is developed
Advantages Prototyping Reduces risk of incorrect user requirements Users can identify needed changes and refine real requirements Problems are detected earlier Regular visible progress
Disadvantages Prototyping Difficult to know how long project will last An unstable/badly implemented prototype often becomes the final product. The design is of lesser quality Requires extensive customer collaboration
Agile methods XP Programming in pairs Test driven development Continuous planning, change, delivery Emphasises: Individuals and interactions Working software Customer collaboration Responding to change
XP Advantages Suit small-medium size projects Produces good team cohesion Emphasises final product Iterative Test based approach to requirements and quality assurance
Disadvantages XP Difficult to scale up to large projects where documentation is essential Needs experience and skill Requires a great deal of discipline, otherwise project may become chaotic and unfocused
Criteria for Selecting the Appropriate Methodology Clear user requirements Familiarity with technology Complexity of system Reliability of system Time schedule Schedule visibility
Way to success Support from management Involved users Experienced project leaders Clear aim Constraints Standardiserad plattform / infrastructure Stabil fundamental requirements Well-foundedtime/cost estimation
Project management The activity spanning all phases Project must be managed properly Delivered in time (time constraint) Within budget (fixed budget) Well documented