Project Management Development or a crash course in

+ Project Management & Development …or a crash course in Software Engineering Solange Karsenty Hadassah Academic College January 2019

+ Agenda n Project management, planning n Requirements specifications n Visual Modeling (UML) n Development, Agile methods n Test and Evaluation (TDD) n Git (separate lecture)

+ Project Management Objective n Achieve the project goal n Do a great project– on time n Keep customers (e. g. , supervisors) happy n Keep the team focus on the goal n Make sure that team members work well n Everyone shares the load n … Scope, Resources, Schedule & Customers

+ Concerns about Project Management n My work is research so that I can’t plan it n How can I commit to a schedule if I don’t know how it will work out n I don’t have time to plan – got to get it done • Project plan is a map and a guide - No map, most likely to get lost - Plan: understand risks and trade-offs - Basis for systematic plan modification - Mechanism for efficient communications - It’s ok to update your plan every 2 weeks! (extreme programming)

+ Framework: Project Cycle Project ideas Project proposal Project completed Concept • Tech. Foundation • Capabilities • Goal System Design (Architecture) • Systems analysis/ Synthesis • Project planning • project proposal Detailed design/ Implementation Demo/test/ Documentation • Project tracking • Plan modification • Communicate • report submission

+ How to Get Started n Before anything find about the users, needs, context: understand the problem you are trying to solve n write down requirements n Draw a block diagram of your system n n Do a high level flow chart of your software n n User interface, typical use scenarios List all possible tasks that needed to be done n n Detailed logic of a business process: identify modules Define the end result of your prototype n n “Architecture” Organize tasks Do some or all of above

Requirements n User requirements n Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. n System requirements n A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. n techniques for requirements elicitation: interviews, scenarios, use-cases and ethnography. n Define a glossary of terms 7

Finding out about users n Do-it-yourself: n n Introspection: n n Place yourself in the user’s shoes (probably the worst) Questionnaire: n n n Observation: n Watch users in field situations n Watch users in pre-arranged settings Distribute questions to many users Use for example google forms and publish the questionnaire by email Interviews: n Ask individual users probing questions

Question styles n choices I can easily manage my email n n n Strongly Disagree Neutral Agree n Ranking Rank the following functions in order of usefulness ___ Blind copy ___ Automatic copy to a distribution list ___ Automatic to myself n Open questions Describe how you use electronic mail.

Functional and non-functional requirements 10 n Functional requirements n Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. n May state what the system should not do. n Non-functional requirements n Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. n Often apply to the system as a whole rather than individual features or services. n Domain requirements n Constraints on the system from the domain of operation

11 Metrics for specifying nonfunctional requirements Property Measure Speed Processed transactions/second User/event response time Screen refresh time Size Mbytes Number of ROM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems

12 Requirements discovery: interviews n Interviews are good for getting an overall understanding of what users do and how they might interact with the system. n Interviews are not good for understanding domain requirements n n Requirements engineers cannot understand specific domain terminology; Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t worth articulating.

Requirements discovery: Scenarios n Scenarios are real-life examples of how a system can be used. n They should include n A description of the starting situation; n A description of the normal flow of events; n A description of what can go wrong; n Information about other concurrent activities; n A description of the state when the scenario finishes.

14 A ‘prescribing medication’ story

15 Examples of task cards for prescribing medication

Design: storyboards n Goal Illustrate the design scenario, n emphasizing the details of the interaction with the system being designed n Procedure Divide the design scenario into a series of interaction points Create a series of images and text to illustrate each point n VALIDATE the storyboard with the client/user!

Storyboards n Borrowed from cinema to illustrate a scenario n n Key images Framing (shots) Subtitles Flow n Overview of the action n Key interaction points n Coherent order n Relevant details

Functional table n At this point it is recommended to build a functional table n This is not about implementation! n It looks like OOP n n Objects Properties Functions For example n n n Document Name, type, owner Can create, modify, delete, duplicate

Visual Modeling: UML Diagrams n UML: a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems n Goals: n n n Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. Provide extensibility and specialization mechanisms to extend the core concepts. Be independent of particular programming languages and development processes. Provide a formal basis for understanding the modeling language. Encourage the growth of the OO tools market. Support higher-level development concepts such as collaborations, frameworks, patterns and components. Integrate best practices.

UML Diagrams n Use Case Diagram n Class Diagram models class structure and contents using design elements such as classes, packages and objects. It also displays relationships such as containment, inheritance, associations and other n State Diagram displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli, together with its responses and action http: //en. wikipedia. org/wiki/Class_diagram http: //en. wikipedia. org/wiki/Use_Case_Diagram

21 Use cases n Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself. n A set of use cases should describe all possible interactions with the system. n High-level graphical model supplemented by more detailed tabular description n Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

22 Use cases for the MHC-PMS Once interactions between the system and its environment have been understood, you use this information for designing the system architecture.

+ Flowchart Examples

+ Project Management Process n Planning n Project Definition, Scope n Mechanics of putting together a plan n Tools: Work Breakdown Structure (WBS) n GANTT, PERT, etc. charts - computerized n Tracking plan progress n Communicate and follow-up: weekly reports, update and use the GANTT

+ Mechanism of Planning n Define project objective n Define work breakdown structure (WBS) n n Identify tasks and subtasks -- deliverables Lowest element – stand alone work package n Identify tasks relationship (e. g. learn Android then create UI) n Identify possible risks (requirements may change, some library does not fit our needs) and alternate plans n Estimate work packages (time, equipment) n Create initial schedule n Iterate plan n Document

+ 26 Planning: Gantt Charts n Expected in the project proposal – can be refined later. n Graphical way of showing task durations, project schedule n Graphical way of showing task durations, and schedule n Does not explicitly show relationships between tasks n Limited use for project tracking n Easy to understand 11/24/2020

+ 27 Example Gantt 11/24/2020

Software Architecture n Software View of the problem = requirements (functional) n Components and Connections = architecture (non functional) n When you take the time to properly design, implement, document, and evaluate a software architecture, you can n n n n predict, achieve, and control quality attribute behavior and make practical tradeoffs early greatly reduce the failure rates of software projects produce a rationale for certain architectural decisions made or not made communicate with your customer reason about and manage change enable more accurate cost and schedule estimates create evolutionary prototypes predict and mitigate risks understand the tradeoffs inherent in the architectures of software-intensive systems

Software Architecture n Components: define the focus of computation n n Connectors: mediate interactions of components n n Database, objects, client, server Procedure calls, events broadcast Properties: specify info for construction and analysis n Signatures, pre/post conditions

Examples n Client-server: 3 -tiers, 2 -tiers, peer-to-peer n Event-driven architecture

+ Architecture Diagram Example

Coding

33 Extreme programming n Perhaps the best-known and most widely used AGILE method. n Extreme Programming (XP) takes an ‘extreme’ approach to iterative development. n n n New versions may be built several times per day; Increments are delivered to customers every 2 weeks; All tests must be run for every build and the build is only accepted if tests run successfully. Chapter 3 Agile software development

34 Extreme programming involves a number of practices 1. Incremental development is supported through small, frequent system releases. 2. Customer involvement means full-time customer engagement with the team. 3. People not process through pair programming, collective ownership and a process that avoids long working hours. 4. Change supported through regular system releases. 5. Maintaining simplicity through constant refactoring of code. Chapter 3 Agile software development

35 The extreme programming release cycle

36 Extreme programming practices (a) Principle or practice Description Incremental planning Requirements are recorded on story cards and the stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development ‘Tasks’. See Figures 3. 5 and 3. 6. Small releases The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release. Simple design Enough design is carried out to meet the current requirements and no more. Test-first development An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented. Refactoring All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable. Chapter 3 Agile software development

37 Extreme programming practices (b) Pair programming Developers work in pairs, checking each other’s work and providing the support to always do a good job. Collective ownership The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers take responsibility for all of the code. Anyone can change anything. Continuous integration As soon as the work on a task is complete, it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Sustainable pace Large amounts of overtime are not considered acceptable as the net effect is often to reduce code quality and medium term productivity On-site customer A representative of the end-user of the system (the customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation. Chapter 3 Agile software development

Scrum: Agile in practice n A product owner creates a prioritized wish list called a product backlog. n During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces. n The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum). n Along the way, the Scrum. Master keeps the team focused on its goal. n At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder. n The sprint ends with a sprint review and retrospective. n As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

39 Refactoring: redesigning or rewriting code while preserving its behavior n Programming team look for possible software improvements and make these improvements even where there is no immediate need for them. n Candidates: duplicate code, long methods, etc n This improves the understandability of the software and so reduces the need for documentation. n Changes are easier to make because the code is wellstructured and clear. n However, some changes requires architecture refactoring and this is much more expensive. Chapter 3 Agile software development

40 Examples of refactoring n Re-organization of a class hierarchy to remove duplicate code. n Tidying up and renaming attributes and methods to make them easier to understand. n The replacement of inline code with calls to methods that have been included in a program library. Chapter 3 Agile software development

+ Netbeans

+ Eclipse

+ Jet. Brains (Web. Storm, Intelli. J) n Look for the menu “Refactor”

Coding facts n averaging over the lifetime of the project, a programmer spends about 10 -20% of his time writing code, and most programmers write about 10 -12 lines of code per day that goes into the final product, regardless of their skill level. Good programmers spend much of the other 90% thinking, researching, and experimenting to find the best design. Bad programmers spend much of that 90% debugging code by randomly making changes and seeing if they work. n Programming is hard work. It’s an intense mental activity. Good programmers think about their work 24/7. They sometimes write their most important code in the shower! Because the most important work is done away from a keyboard, software projects cannot be accelerated by spending more time in the office or adding more people to a project n It’s easier to throw away bad code and start over than to change it. Reference: http: //automagical. rationalmind. net/2010/08/17/some-lesser-known-truths-about-programming/

45 Test-first Development or Test Driven Development (TDD) n Writing tests before code clarifies the requirements to be implemented. n Tests are written as programs rather than data so that they can be executed automatically. The test includes a check that it has executed correctly. n n Usually relies on a testing framework such as Junit. All previous and new tests are run automatically when new functionality is added, thus checking that the new functionality has not introduced errors.

Unit testing n Help reduce the number of bugs, hours spent on debugging, and contribute to healthier, more stable software n ensure the performance of your code doesn't degrade over time n create a set of tests for each software component n When you uncover a problem in your code, write a test that exposes this problem before fixing the code n write tests for each other's code, fun is guaranteed n Java: Junit (http: //www. junit. org), tutorial (http: //www. vogella. com/articles/JUnit/article. html) n Javascript: https: //mochajs. org

Unit testing example n n Test a package to handle orders n Place a regular order n Place an order for a non existent item n Place an order for a non valid date n Place an order for a non existent client n Cancel an order n Cancel a non existent order n Etc… Demo Netbeans

+ Example n describe() is simply a way to group tests in Mocha. n can nest our tests in groups as deep as we deem necessary. n describe() takes two arguments, n the name of the test group n a callback function. n it() is used for an individual test case. it() should be written as if you were saying it out loud: “It should equal zero”, etc. it() takes two arguments n a string explaining what the test should do n a callback function which contains our actual test var assert = require('assert’); describe('Array', function() { describe('#index. Of()', function() { it('should return -1 when the value is not present’, function() { assert. equal([1, 2, 3]. index. Of(4), -1); });

Evaluation n n What are the qualities of your system? List them and explain. n robustness, n reliability, n extensibility, n portability, n efficiency, n usability, next time we’ll talk about this n interoperability, n scalability n portability Qualities must be measurable!

+ Summary n Planning: GANTT, PERT, n Design / Document: requirements, system architecture, UML diagrams (classes, state charts…) n Build, test and iterate –XP!! n Test and Evaluation n n Build test suites that cover all system scenarios n Sample input n Scenarios of use Give us numbers/graphs! n Interactive applications: usability (error rates, time to perform tasks, time to learn) n Algorithm complexity Expectations vs. Reality Conclusions: success, failures (why)